RXB, on Fri Aug 12, 2011 4:08 PM, said:
I am confused about one thing though, with my GRAMULATOR or PGRAM or GRAMKRACK I could put a module in any page and it would always come up on the menu even if nothing was in page 0 at all. (ROM or GROM)
Why do I need to put something in page 0 for Classic99 when every other GRAM device I have ever used does not, or is it just the way Classic99 works vs real TI GRAM devices?
I don't have a GRAMULATOR or PGRAM or GRAMKracker to check for sure, all I can tell you is that they /must/ expose some difference between pages 0 and 1, because the OS completely skips scanning otherwise. I spent a fair bit of time in that section of the GPL code when I was testing my GROM simulator, to make sure I understood the multiple banks. Classic99 isn't attempting to emulate a GRAM device, so none of those little variants show up. I guess you could call that part an emulator behaviour, but if you did the same thing on a real TI (without a GRAM device), it would behave the same way.
If nothing else, Rich, you've been teaching us all a ton about how the GRAM devices work and the way GPL programmers are used to interacting with them.
This clip (from TI Intern) shows the block of code I'm talking about (I've replaced the comments with my own):
01BE : CLR @>83FB Set GROM page to 0 (base address >9800)
01C1 : MOVE >001E TO VDP@>0400 FROM GROM@>6000 Read >1E bytes from GROM >6000 into VDP buffer 1
01C8 : ST @>83FB,>04 Set GROM page to 1 (base address >9804)
01CC : MOVE >001E TO VDP@>0420 FROM GROM@>6000 Read >1E bytes from GROM >6000 into VDP buffer 2
01D3 : CLR @>8358 Zero byte counter MSB
01D5 : CLR @>8359 Zero byte counter LSB (why not use DCLR?)
01D7 : B GROM@>01DC Jump into loop ahead
01DA : INC @>8359 Increment byte counter
01DC : CGT @>8359,>1D When we reach >1E, we are done the buffer
01DF : BS GROM@>01ED Jump ahead and out of loop if so (double branch ultimately to >01FD)
01E1 : CEQ VDP@>0400(@>8358),VDP@>0420(@>8358) Compare buffer 1 to buffer 2, using >8358 as a byte index
01E8 : BR GROM@>01EF If they differ, jump out of the loop
01EA : B GROM@>01DA Loop around again
01ED : BR GROM@>01FD We only get here from >01DF, so this jump is taken (condition is reset after the BS!)
01EF : INCT @>8372 Increment stack pointer by 2
01F1 : DCLR *>8372 Clear data at stack
01F4 : INCT @>8372 Increment stack pointer by 2
01F6 : DST *>8372,>12A1 Store literal value >12A1 (pointer to 'Review Module Library')
01FB : INC @>836C Increment count of programs on stack
01FD : CEQ @>6000,>AA All paths come here, check for ROM cart (different instruction in 2.2 GROM)
So basically, this code checks the first two pages, and adds 'Review Module Library' to the menu list if the first two differ. The next block of code checks for ROM carts (except in 2.2, where that's just deleted). Finally, it checks for GROMs. As this order might suggest, the list is displayed in reverse order.
The actual GROM search is done by an XML assembly subroutine (XML >1A). This subroutine searches all GROMs for one name each time it's called. I have to admit I find this subroutine really confusing, and I had to spend a lot of time in it when I did my fake 99/8 GROM for the MPD. It does too many things! But this is the function largely responsible. If I read it right again, it returns condition set if it found a name, and reset otherwise. The GPL loop that calls it loops until a name is not found, then it stops (thus filling in all the information for one page). If there's nothing on pages 0 or 1, then you don't get Review Module Library, and if there's nothing on page 0, you also don't get a GROM cartridge entry. (My confidence level in this is only about 80% - the actual GROM name search routine is complex, and I didn't take enough notes last time I went through it.)
Testing matches this description, though. If there is /anything/ in bank 0 /or/ 1, then every other base will be scanned for the menu. Note that it's a binary compare, not any kind of header test, so even if it's just random noise in bank 0 that doesn't match bank 1, every other bank is searched for headers.
Maybe sometime, you could write a little program that dumps the first 32 bytes of pages 0 and 1 to the screen on the real machine (when there's nothing loaded in them!), and just see if you can see any differences?