BLuRry wrote:
I was trying to leave the stack completely alone if at all possible. Since I'm about to replace rwts with a modified version of this I want it to run very lean. The only reason the read/write serial functions are subroutines is because of their frequent use (so to keep size down) and so they can be reimplemented more easily should someone be using a different slot or a different card that uses an alternate I/O mapping to memory.
Pushing on a return address and then returning *does* leave the stack pointer alone (not that it matters), and clobbering the two bytes of junk ahead of the pointer won't matter either. -michael
Michael J. Mahon wrote:BLuRry wrote:Hey, I liked my little jump table thank you very much. It kept the code smaller and prettier. And to do an indirect store operation I had to shove a zero into one of the registers so I could use a supported 6502 addressing mode. YUCK.You don't like the "standard" approach of pushing the target address -1 on the stack and RTS? It's particularly easy if all entry points are on one page. ;-)Michael J. Mahon wrote:BLuRry wrote:I should have put a counter on that page. Oh well. All I can figure is that I pulled off a good google whack for the term "Apple Game Server". ;-) I should probably continue to improve it now that I have a few emails suggesting it isn't as compatible as I thought it was. If anyone has a //e with SSC please feel free to test the version I'm releasing in the next 24 hours (you'll see a notice about "enhanced script support" or something on the page once it's tested and uploaded -- all baud rate changes are scripted so you can change them without editing the java program) And also, for the die-hard 6502 people that were miffed a while back, I've removed all 65c02 instructions so it will work on any apple // as long as you have 48kb of ram and your ssc is in slot 2.Yay! (Now, that wasn't so hard, was it?) The myth that the 65C02 instruction set is a significant improvement over the 6502 instruction set is just that--a myth. ;-)