Doors CS [Cur: 5.8 Beta]

Jim e · Post by **Jim e** » Thu 26 Jan, 2006 1:35 pm

Straying from the 257 byte table really breaks compatibilty, especially when it comes to emulators. And besides thats how it's defined for the z80. Anyway saferam2 should large enough to handle the table and a somewhat robust interrupt routine. MirageOS puts most of it's interrupt routine there as well, and it's less used than other saferams due to it's awkward size.

KermMartian · Post by **KermMartian** » Thu 26 Jan, 2006 2:53 pm

Ah, clearly I didn't entirely elucidate myself about the whole GUIStack premise. As you know, the version that this is supposed to be in will be an app. Hence, ASM programs will be able to bcall into any routines I decide to use, further hence leaving most safeRAM free for developers. In fact, I plan to leave all the safeRAM available, except of course for the Ion vector table, by storing any variables DCS needs in an appvar that's set up when the shell initializes. For this whole GUIStack thing, programs push stuff onto the GUIStack (which is stored in the unarchived, ie RAM-located appvar). When the program wants to turn over control to the user, it bcalls a certain routine within Doors CS that reads the GUIStack, renders all elements of the stack onto the screen, and sets up the hotspot system for mouse clicks and mouse cursor image changes (eg pointer, text, hand, custom, etc). It then jumps over to its own mouse routine, still within the App, and does everything there. As necro (?) proposed, I will also have an optional GUIStack entry type to make the mouse routine itself call into RAM to the program's idle routine, wait for it to finish and return, check the keyboard again, do the idle routine, and so on. When the user actually does get around to do something such as clicking an onscreen button that's meant to indicate the user is done with the current screen and values need to be returned to the program, Doors CS will close up the hotspot table, figure out any stuff that needs to be returned to the program, set up pointers to the data being returned, and then quit the bcall so the program regains control again. The interrupt that CALCnet2 will use is an entirely different beast, and will be handled as such. It's the only thing that will use the safeRAMs to store stuff, ie its read/write buffers, and even those will probably take up no more than 128+128 bytes total. In addition, programs will have the option to enable or disable CALCnet2 via a bcall at any time, and part of the program header will have a bit indicating whether the program would like to use CALCnet2 if a connection is available so that those that don't need it won't be bogged down by it at all.

Keep 'em coming.

KermMartian · Post by **KermMartian** » Mon 30 Jan, 2006 5:49 pm

(Just wanted to revive this and post some updates)
ATM I have 3 bugs I'm trying to work out so I can release 5.4 and get on with the app process. To wit:
1. VAT corruption when attempting to move certain items between folders. I believe this may have to do with a malformed VFAT entry.
2. Certain Ion programs crash after the programs hand control back to Doors CS. I believe this may have to do with the associated program routines.
3. TI-Freak8x has reported that his BASIC program Pokemon Purple causes a RAM leak roughly equal to the size of ZDCS. Not sure about this one...

KermMartian · Post by **KermMartian** » Mon 06 Feb, 2006 10:25 pm

I am frickin happy right now. At long last I fixed a bug that made Doors CS crash when trying to scroll up. I knew within which 100 bytes the error was occuring, but try as I might I could find no typos or conceptual errors. Finally I spent a painstaking hour tracing the program execution byte by byte in TiLem, only to discover that my mistake was a SINGLE one-byte command reversed: I was substracting two variables instead of adding them because the IDIOTS at Texas Instruments made the VAT work @#%^@#%^#%^%$^ing BACKWARDS. GAR.. *sob* Anyway, it works now, so I'm really happy. Only really one more major bug to root out and DCS5.4 will be ready.

Timendus · Post by **Timendus** » Mon 06 Feb, 2006 10:27 pm

Hahaha

I'm curious to see the result

kalan_vod · Post by **kalan_vod** » Mon 06 Feb, 2006 10:29 pm

Cool, glad you worked it out. Btw 1hour is nothing...I spent 2 hours finding a bug and didn't find it. Then the next day I spent 15 min and found out it was stupidy on my part

.
Was
[A](A+1,B+P
needed to be
[A](E+1,F+P
....

DJ_O · Post by **DJ_O** » Mon 06 Feb, 2006 10:53 pm

Timendus wrote:the result

a shell %)

KermMartian · Post by **KermMartian** » Tue 07 Feb, 2006 2:10 am

@ Kevin. Well, if I can get that other bug resolved in a reasonable amount of time, you'll have a hugely bloated, 6.5K ASM prog; soon thereafter, with any luck, it will be a single-page app with 9.5 k for fun networking and GUI features.

KermMartian · Post by **KermMartian** » Wed 08 Feb, 2006 1:13 am

So now I'm trying to find this final bug, which appears to be some kind of corruption of the VAT table. Since I can't seem to replicate it well in an emu, I'm going to try to make it happen on my calc, then manually copy out the VAT via CalcSys onto a piece of paper, analyze it, and find the error. Then I'll be able to trace it back. Is there a better way?

Post by **tr1p1ea** » Wed 08 Feb, 2006 7:31 am

You cant replicate it in PindurTI? Ive worked with the VAT a bit and PindurTI seemed to work fine?

KermMartian · Post by **KermMartian** » Wed 08 Feb, 2006 1:41 pm

Yeah, but I'm still having problems with PTI and getting it to turn on. *sob* I'm using ROM 1.12 if that makes a difference.

kalan_vod · Post by **kalan_vod** » Wed 08 Feb, 2006 3:48 pm

Your using windows? If so then you may be doing something wrong. Try and make a list of things you are doing so we can help you better.

KermMartian · Post by **KermMartian** » Wed 08 Feb, 2006 5:05 pm

Directory listing:

e:\calc\vti\pti\
++pindurti.exe
++pti.conf
++send.exe
++ti83p_112.rom
++ti83p_112.rom.pti

I run pindurti.exe, then leftclick and release on the left-hand screen. I've tried closing pti, deleting the .rom.pti and pti.conf files, then opening pti and dragging the ROM back onto PTI and left-clicking, but still nothing.

Oh, and my PTI.conf contains this:

Code: Select all

0:E:\Calc\vti\pti\ti83p_112.rom
1:
2:
3:
4:
5:
6:
7:
8:
9:
10:
11:
12:
13:
14:
15:

I've tried left-clicking, power-left-clicking, left-hold-for-ten-seconds-and-release clicking, et al.

CoBB · Post by **CoBB** » Wed 08 Feb, 2006 5:16 pm

I simply can't reproduce that error. I've heard it from a number of people, but I just never ever have experienced anything like that during development... If I start with a clean state and left-click for a reasonably long time (say half a second), then it works.

Jim e · Post by **Jim e** » Wed 08 Feb, 2006 5:37 pm

Could be a bad rom, one got speard around sometime ago.