Okay; thanks for considering putting this in!

Maybe you could make that it just chains hooks and not kills the other ones?

Um, it chains hooks, it just happened to have a small glitch with hook chaining. If you read back a page or two, ThePenguin77 requested that I fix the glitch, and it has already been fixed.

I am working on BatLib and I have a way to chain DoorsCS7+Grammer+BatLib+Omnicalc just by installing BatLib. This means programs can use the parser hook of all these apps, if they are on your calculator, but the apps need to have a slight modification in the header. There is one little problem, though, and I hope you can fix it. DoorsCS7 and Omnicalc conflict with the real( tokens. If you could run a check before parsing real tokens to see if it is not supported by DoorsCS7, that would be great (and return the registers in the state they were passed). The way I think I would do this is by checking OP1+2 and compare it to a value. You will also need to check OP1+1 for the number of digits.

Also, if you could change the header in DoorsCS7 at 406Ch, that would be very awesome. The syntax BatLib looks for is:

Code:

For DCS7, I did some looking around and found the hook was on the last page, so pageoffset was 2.

If you could do this, I would release a modified Omnicalc and BASIC users could use DoorsCS7+Omnicalc+Grammer+BatLib in their programs, just by installing BatLib!

I think it would be better for the X,T,0,n button to be used for "Up one level along with F2 since its current function does no good. Plus, taking into account the way people place their middle finger on 2nd and 3rd finger on Alpha, I think it would be a lot easier to reach over with the 3rd finger (which is in charge of right clicking), instead of the 2nd finger (which is in charge of left clicking).

Someone tell me if I'm overthinking this, because for my sake, I think this would be a LOT more convenient when browsing through folders. DCS7β2

To be honest, I think you're overthinking it. The XT0n key is in the middle of nowhere, and I was shocked when I was using MirageOS, pressed it by accident, and discovered it actually made the shell do something. I want keys to be as intuitive as possible, and since F2 is right under the "<<" symbol, I feel like it's the intuitive choice. As far as why not to also use XT0n, (a) I have very little space for non-essential features left and (b) I don't want people to hit it by accident and not understand why their desktop changed.

I think using F2 is a good idea, but that the ◀◀ could be modified a bit so it looks like a button (the way the DoorsCS main menu icon (Start icon? what do you call it?) looks like a button so that pressing F1 to open it feels intuitive).

I've always called it the Doors CS Menu Button (not very original, I know). I could try doing that; it wouldn't really incur any extra space in Doors CS 7.2.

Hi

I've noticed that sometimes, when using the DCS7 GUI with ASM (Axe in fact, with my AxeDCS axiom), the GUIRByteIn was slowing down when memory is getting busy. So, as I pointed out KermM on SAX, I think that it could be a good idea to add a step to the input field, so it would look like this :


Code:


Of course, same goes for GUIRWordIn.

What does "when memory is getting busy" mean? Do you mean when RAM is full?

In fact, in my program I'm setting 768 bytes from appBackUpScreen to 0, and then I start the GUI ; the GUIRByteIn-s work fine. But during the program (when I fill appBackUpScreen with bytes) the GUI is being more and more slow.

Sorry but I don't want to post code nor screenshots for the moment =/

And I have approximately 19K of free RAM when running the prgm.

I'm not really sure what topic to put this in, since I saw no thread explicitly about Cn2 suggestions, and DCS8 seems to be only for the color screen:

As of now, CALCnet only supports packets that are 255 bytes long. This works for many games, where only a few bytes of data need to be sent at a time, but I remember talk about gCn moving to support file downloads, and what about games/utilities that want the ability to phone home for updates. Having to create a routine where you are loading in 255 bytes at a time for a 2k plus byte program is tedious...plus, what if the connection drops mid-transfer?

Perhaps, a feature that could be added is an enable-long frames option. A long frame can have a size word that is two bytes large, and carry up to 65,536 bytes of data. A developer enables this by calling "Cn2_Enable_Long", commences the long transfer, and then calls "Cn2_Disable_Long" to return to normal mode.

just a thought.

There are 2 reasons for the limited frame size.

1: The size byte is only one byte long and changes to that now will break compatibility with old/future releases.

2: Anything larger then 255 starts to push the limit of what we can fit inside the interrupts timing span and to much more craziness will make the interrupt monopolize the cpu time more which would make your programs not even run.

The routine to send larger packet sizes is really not that complicated , and if the connection drops it errors out and marks the packets as invalid/not sent and will continue to retry till it is sent.


Eg its not really feasible or needed based on the current structure of the cn2.2 protocol.

ah ok. there are somethings you mentioned that i was not aware of.

Here's another idea: like in how a program can use the 5 byte special string to send a packet to a hub, maybe support a string, containing a server name and a hub id or something of that name. if server name is given, then the program connects to cemetech's server which could host some sort of DNS style lookup table for the server names, gets redirected to the correct server and then looks for the hub. The server name cannot be omitted, and if 0, defaults to hub on cemetech, like the Chat or Gossamer.

The fact that Sandpaper exists and can easily send large programs and files across CALCnet should demonstrate that having large frames is quite unnecessary indeed. All the reasons that geekboy mentions are exactly why I don't have them: (1) Longer virtual frames can be decomposed into smaller physical frames at the sender and recomposed at the receiver (2) Long frames would make the interrupt take too long (3) Long frames would not allow fine enough division of the sharing of the token (ie, the clock line) among the calculators on the network (4) Long frames would require a bigger buffer. (5) Long frames would require a size word

I've considered something like a CALCnet 3 that is backwards compatible with CALCnet 2 but implements something like Layer 4/5 of the OSI model. However, unless everyone suddenly starts writing CALCnet programs, it's unfortunately not worth my time.

what about:

cursor or mouse-based option.
Grayscale cursor
smaller icon (8x8) option (and a DCSB feature for that.)
ability to edit BASIC programs if there is an error (right to editor screen, no error message)

I'll edit if there is more.

Nice ideas. And stop typing that! That's my line!

That's my signature. Edit it through your profile.

I kinda like the 8x8 icon, but something nags me that we allready can do that, though I am not sure.

grayscale cursor? forget it. we dont look at the cursor enough for that, and it would only slow the cursor down. besides take up more space.

Ability to edit directly without displaying errors....uhm, then how would you know what the error is? I find this rather silly.

It'll display it under the editor for a while (one line), then disappear for the 8-line editor functionality. It could just display "syntax" or something.