So, the shell has to be on the calculator for running from homescreen to function?  I guess I'm not deleting calcutil yet after all...

Also, a bug report.  Somehow, zStart disables the TIOS APD.  I left the calc for like an hour at the homescreen and when I came back, it was still on.

Yes, the shell still has to be there. It's just easier that way because to re implement all the libraries would take almost the entire app. Also, programs that don't need shell calls will work without a shell selected.

And for the APD, it's not zStart that is disabling it, but instead the program. zStart just doesn't turn it back on, so I'll have to fix that.

Massive Update!!!! I've spent a solid 4hrs per day for about 4 days on this, so it's pretty impressive.

Updates:

• Option to use classic ram clear screen
• Hooks now run in all menus of homescreen
• I threw out the CursorHook and replaced it with a temporary getCSC hook
• I put a space before all of the homescreen messages
• Ability to run assembly programs with or without a shell
• [ON] + [Enter] in program menu - run program
• [ON] + [ * ] in program or edit menu - archive/unarchive program
• [ON] + [number] in program or apps menu - run that program/app with that shortcut on home screen
• [ON] + [negate] in program or apps menu - run this program when the calculator turns on
• [ON] + [ . ] in program or apps menu - run this program/app on ram clears
  
• [ON] + [number] in menu or catalog - set this as a shortcut token
• [ON] + [number] at homescreen - run the shortcut associated with this action

 .
Running programs:
    There's an option in zStart to set the shell of your choice, but you don't have to if you know that all of your programs don't use shell calls. What I do is I copy the program to $9D95 just like the shell would, then I swap the shell in and bcall() $9D95. So the program runs its course and returns back to me, not the shell. I basically tried to do the file copying like mirage does, except I fixed its glitches. So that means programs in ram are moved - not copied, and programs in flash are written back only if they actually changed.

     Also, zStart does actually handle the program different if it's header allows it to be run at the homescreen. So remember that. It will let a homescreen program modify the homescreen, but for shell programs, it will clear the homescreen before it quits. Also, unlike Ti-OS you still get the actual shell routines with whatever header you use, even if it is no-stub.

Shortcuts:
    The shortcuts are pretty straight forward, the number you set is the number you get. Press it once in a menu and it will say "Confirm," press it again and it will set it. You might need to disable omnicalc if you are going to set an app though because onmicalc will send you into mirage the moment you press ON in the apps menu. And for the tokens, it's kinda fun to see what tokens will actually work. I've noticed that none of the tokens that open up new contexts work, so I guess that's too bad. And just so you know, finding what the option the calculator is actually highlighting is really a pain.

Running on startup:
    This gets run every time you turn the calculator on. You can pretty much do whatever you want here, it even runs your program inside the shell. Just don't bcall(_jForceCMDNoChar) because the program is running on borrowed space.

Running on ram clear:
     Here it is, have fun. For max compatibility, you should put this as a homescreen program that doesn't touch the screen or textShadow, but you don't have to do that. If you do run a shell program, just understand it's going to mess up the homscreen. And I don't really recommend you run an app, but I'm not going to stop you. Honestly, if you run an app, a person watching wouldn't even know your ram cleared.

     Don't forget, hold [Vars] while booting to abort. You might need that if your ram clear program crashes.


It's a little too late for me to make a screen shot, but I think everything I put here is self explanatory.

Well, the source and the latest version I released are exactly the same. And luckily, the little glitch I talked about doesn't really affect the program at all, so I won't put up another version until I make some more changes.

Well, the reason that the full program isn't crashing is because it never actually calls the routine in question. I just does clearGBuf, lineDraw, fastCopy and checks for quit.

I would call it myself, but I have no idea what to call.

Not yet, I hope there will be soon though. I have my last 2 AP tests tomorrow, so after that, I am down from 6 classes to 2.

I have some things I want to do like: better AI (duh), fine tuning grayscale, maybe piece sets, speed increases, maybe the mode where you can choose what pieces to play with, and lastly I might try to make a better title screen.

But for right now this isn't on my priority list. I tend to work a bunch on one thing at a time, and right now, that is zStart. So when I get board with that, I'll probably be back here.

When I first made zStart, I did not know much about the OS, but now I do. So it was time for a change.

Updates:

• New OS entry point (Both elegant and early)
• Solver++ and Long tokens are gone
• Toggling options actually changes things during the current ram session (as opposed to waiting until a ram clear)

On page 0, there is a huge list of unofficial bcalls. You can't use them though because their location changes from OS to OS. What is interesting about them though is that their format is
call constantAddress
.dw address
.db page
which means that you can actually change where they jump to! So, I took the call that displays "RAM Cleared" and redirected it over to page $75 where I call the zStart app and install everything. Then when I'm done, I call the original call and it displays "RAM Cleared."

But what makes this so cool is that I actually install everything before the homescreen starts, so the Safe Cleared message is no longer a flash too late, and, custom fonts actually affect the "RAM Cleared" message.

Willrandship, that isn't the slow part, that's actually the really easy part.

Here's my code: (commented for the non asm'ers.)


bitFinal: ;label
ld a, c ;variable transfer, A now equals the number of live cells around the current one
jr nz, checkDeath ;if it's living, go to checkDeath
;>>asm: most often, we will come through here with a non-living pixel
; so the fall through for jr is the fastest way to do this
cp 3 ;act like we are subtracting 3 from A
jp nz, activeRet ;if A != 3, go find the next pixel
;>>asm: most often will not be birthing a new cell, so jp is fastest
jp setIt ;go to setIt
checkDeath:
cp 2 ;act like we are subtracting 2 from A
jp c, activeRet ;if A < 2, go find the next pixel
;>>asm: this is first because most pixels that won't survive will have
; 0 or 1, not >= 4
cp 4 ;act like we are subtracting 4
jr nc, activeRet ;if A >= 4, go find the next pixel
;>>asm: 2 and 3 are more likely than 4+
setIt:
ld a, d ;if you don't know asm, stop reading
or (ix+3)
ld (ix+3), a
push hl
ld hl, activeRet
ex (sp), hl
ld d, setJPHigh
push de
ret

This is the fastest way to do these checks. There is one spot where I could shave off 10 t-states, but that would involve duplicating the setIt routine. And 10 t-states doesn't really apply here because most paths through that routine right there average to about 40 t-states, the routine that leads here takes on average 300 t-states, and the routine it runs if it is setting a live pixel is 200 t-states.

So 550 t-states is pretty good for a worst case scenario where we are making a live cell. At that worst rate, I can handle about 27,000 pixels per second.

Freyaday, I think this one is actually hardware specific. I can't be positive, but I remember there was another topic about this and no one could replicate the glitch. I for one, could not get this to work in wabbitEmu on 2.55 or on my calc on 2.53.

So, when you get the chance, we kinda need you to test this on wabbitEmu. Or even another calculator for that matter.