+Torrax Posted July 16, 2011 Share Posted July 16, 2011 Noticed an odd quirk in Classic99 with Super Extended Basic. It seems that the auto-load bypass check is completely skipped. I set a couple of breakpoints in GROM to see what was happening - g>63C2; g>63C5; and g>DFFE. 63C2: 06 68 c3 CALL G@>68C3 * Same in XB & SXB 63C5: 06 A0 18 CALL G@>A018 * XB 63C5: 06 DF FE CALL G@>DFFE * SXB - changed to call the new AUTO-LOAD * bypass check. DFE8 to DFFF * List of branch routines for SXB, including the one we want * at the end. * This should jump to the routine, but * doesn't. As Classic99 sets the grom DFFE: 51 F7 BR G@>D117 * pointer to g>E000, and skips/ignores this * GPL command. Everything from g>E000 on is * executed. ** Auto-Load Bypass check routine ** D117: 06 A0 18 CALL G@>A018 * Moved call from XB D11A: 03 SCAN * SCAN the keyboard D11B: D6 75 FF CEQ @>8375,>FF * is any key held down?? D11E: 71 23 BS G@>D123 * no, jump and exit D120: 86 A3 71 CLR V@>0371 * clear the auto-load flag D123: 00 RTN * exit When there is no module in the last Grom-G7, g>E000, everything seems to work. But SXB will still try to do a DSK1.LOAD no matter what key is held down. With a relocated EA module at g>E000 the system will reset back to the main title screen in an endless loop, when SXB (2) is selected. This doesn't allow you to select SXB, but a selection of Basic (1) or E/A (3) works. Not sure why this is happening in Classic99 as everthing works on my real TI with SXB, and also in MESS v1.39. Looks like a GROM address problem with the GPL interpreter when reading an instruction at the end of an 8K GROM?!?! You can get the AUTO-LOAD bypass check to work with the following patches. Use the Hex Offset to find the proper position in your <filename>G.bin (ex. SXBG.bin) file to modify. * AUTO-LOAD Fix 63C5: 06 DF FE CALL G@>DFE6 * Original 63C5: 06 DF E6 CALL G@>DFE6 * New Hex Offset: 03C5 DFE6: 00 00 * * Original DFE6: 51 71 BR G@>D171 * New Hex Offset: 7FE6 * Fixes "CALL EA" to work properly D106: 06 80 12 CALL G@>8012 * Original (wrong pointer) D106: 06 E0 12 CALL G@>E012 * New Hex Offset: 7106 Quote Link to comment Share on other sites More sharing options...
RXB Posted July 16, 2011 Share Posted July 16, 2011 (edited) What version are you running. I have also been getting some very strange behavior and maybe this it is. I am running Qi352 and some GPL I have written is crashing but what is really wierd is it is turning off the AMS card. I am in no way accessing the AMS at all yet a program I just used for the heck of it AMS-TEST would not work. My CALL ONKEY does not access AMS at all but after I run it the AMS can no longer be accessed? I can show the code and there is absolutly no access to the AMS card. ******************************************************************** * CALL KEY(string,keyunit,Nvarible,Nvariable...) ******************************************************************** ZKEY CALL SPAR GET KEY UNIT * RXB PATCH LABEL ************ XML SPEED Insure in range BYTE RANGE * of 0 - 5 BYTE 0 DATA 5 CALL KEYJOY Get variables for code and st * and scan keyboard * KEYJOY returns key status BS KEY1B KEY STATUS = 1 DNEG @FAC Assume status = -1 CEQ >FF,@RKEY But correct if = 0 BR KEY1B DCLR @FAC KEY STATUS = 0 KEY1B XML ASSGNV Assign value in variable DST >4001,@FAC Re-store F.P. 1 in FAC CZ @RKEY If key-code = 0 BS KEY2 CEQ >FF,@RKEY No key depressed, BS KEY1C key code assigned to -1 * FORMAT FOR KEYCODES ABOVE 99 ADDED FOR 99/4A HIGHEST * KEYCODE (OTHER THAN >FF) IS >C6=198 * 5/7/81 CHE 100,@RKEY BR GAC04 INC @FAC SUB 100,@RKEY ST @RKEY,@FAC2 FLOATING FORMAT (>4001__00000 B GAC07 GAC04 ST @RKEY,@FAC1 FLOATING FORMAT (>40__0000000 GAC07 BR KEY2A KEY1C DNEG @FAC KEY CODE ASSIGNED TO -1 BR KEY2A KEY2 DCLR @FAC (>000000000000000) KEY2A XML ASSGNV ASSIGN VALUE TO VARIABLE * RXB PATCH CODE ************* * BR LNKRTN CEQ GOZ,@BYTE1 BS GKEYRT CEQ ONZ,@BYTE1 BS GKEYRT CEQ COMMAZ,@CHAT BS ZKEY BR LNKRTN GKEYRT RTN ******************************************************************** KEYJOY ST @FAC1,@VAR0 Keyboard selection CALL NUMVAR Get variable for key-code CEQ COMMAZ,@CHAT If not comma - error BR ERRSYN XML PGMCHR Get next character CALL NUMVAR Get variable for key-status ST @VAR0,@KEYBD Keyboard selection MOVE 8,G@FLT1,@FAC Set up float CALL KEYSTR * RXB KEY STRING COMPARISON * ST @STATUS,@VARY Save status RTNC Return scan condition co *********************************************************************** KEYSTR DCEQ >994A,@>8310 Flag set? BR RSCAN3 No. DST @>8304,@>8308 String address. DST @>8306,@>8302 Copy length. CLR @BYTE3 RSCAN CEQ GOZ,@BYTE1 GO FLAG? BR RSCANO SCAN B RSCAN1 RSCANO CEQ ONZ,@BYTE1 BR RSCAN0 SCAN B RSCAN1 RSCAN0 SCAN Any key? BR RSCAN No. RSCAN1 DCZ @>8306 Length 0? BS RSCAN4 Yes. RSCAN2 INC @BYTE3 CEQ V*>8308,@RKEY Same? BS RSCAN5 Yes. DINC @>8308 Address +1 DDEC @>8302 Length -1 BR RSCAN2 No matcth. CEQ GOZ,@BYTE1 GO FLAG? BS RSCAN4 CEQ ONZ,@BYTE1 BS RSCAN4 B RSCAN Restart. RSCAN3 SCAN Normal key scan. RSCAN4 CLR @KEYBD DCLR @>8310 Clear flag. RTNC RSCAN5 CALL RSCAN4 CEQ @0,@0 Force condition bit on. RTNC ************************************************************************ * CALL JOYST ************************************************************************ ZJOYST CALL SPAR KEY UNIT GAC16 XML SPEED Insure in range BYTE RANGE * of 1 - 4 BYTE 1 DATA 4 CALL KEYJOY GET VARIABLES FOR X, Y * AND SCAN KEYBOARD ST @JOYY,@VAR0 JOYSTICK Y POSITION CALL JOYXY -4 to +4 DST >4001,@FAC Re-store F.P. 1 in FAC ST @JOYX,@VAR0 JOYSTICK X POSITION * FAC IS SET UP WITH F.P. 1 JOYXY ST @VAR0,@FAC1 -4 to +4 JOYXY CZ @VAR0 If <>0 BR GA995 CLR @FAC (>0000000000000000) BR GA99D GA995 CGE 0,@VAR0 Greater? BS GA99D ST >BF,@FAC GA99D XML ASSGNV Assign the value JOYAGN CEQ COMMAZ,@CHAT BR LNKRTN CALL CPAR2 CALL GAC16 BR JOYAGN ******************************************************************************** * CALL ONKEY(string,keyunit,variable,variable)GO line#,line#,line#... ******************************************************************************** LINK28 DATA LINK29 STRI 'ONKEY' DATA ZONKEY ZONKEY ST ONZ,@BYTE1 CALL GONKEY CLR @BYTE2 ONLP INC @BYTE2 XML PGMCHR CEQ LNZ,@CHAT BR ERRSYN XML PGMCHR ST @CHAT,@FAC XML PGMCHR ST @CHAT,@FAC1 XML PGMCHR CEQ @BYTE3,@BYTE2 BR ONKEY1 DST @FAC,@VARY ONKEY1 CEQ COMMAZ,@CHAT BS ONLP DST @VARY,@FAC CEQ ONZ,@BYTE1 BS GKEY1 CALL RETURN ******************************************************************************** * CALL GOKEY(string,keyunit,variable,variable)GO line# ******************************************************************************** LINK29 DATA >C010 STRI 'GOKEY' DATA ZGOKEY ZGOKEY ST GOZ,@BYTE1 Set GO flag CALL GONKEY BR GOKEY0 ******************************** GONKEY CZ @PRGFLG Program mode? BS ERRLNF ERROR LINE NOT FOUND CALL ZKEY GET KEY UNIT CZ @VARY Was a key pressed? BR GON0 no CLR @BYTE1 CLEAR GO FLAG GON0 CEQ RPARZ,@CHAT ) BR ERRSYN ERROR SYNTAX XML PGMCHR SKIP ) CEQ GOZ,@CHAT GO? BR ERRSYN ERROR SYNTAX RTN ******************************** GOKEY0 XML PGMCHR SKIP GO CEQ LNZ,@CHAT LINE TOKEN? BR ERRSYN ERROR SYNTAX XML PGMCHR Get high line# byte ST @CHAT,@FAC Save it XML PGMCHR Get low line# byte ST @CHAT,@FAC1 Save it CEQ GOZ,@BYTE1 GO FLAG? BS GKEY1 YES XML PGMCHR Get EOL >00 CALL RETURN RETURN TO XB ******************************************************************************** GKEY1 DST @ENLN,@FAC2 LAST ADDRESS DSUB 3,@FAC2 Point to first LINE # GKEY2 CALL GRSUB3 Read from VDP/RAM BYTE FAC2 DCEQ @EEE1,@FAC SAME? BS GKEY3 YES, FOUND LINE DCH @STLN,@FAC2 NO LINE # LEFT BR ERRLNF ERROR LINE NOT FOUND DSUB 4,@FAC2 NEXT LINE # BR GKEY2 Loop GKEY3 DST @FAC2,@EXTRAM Got LINE # DADD 4,@EXTRAM DINCT @EXTRAM Point to ADDRESS DST @EXTRAM,@PGMPTR Get pointer DINCT @PGMPTR Point to tokens CALL RETURN ******************************************************************************** END Seems to be some kind of memory leak as this program works fine in smaller programs. But when i start using the >E000 and up with larger program, it crashes and has to be Classic99 as even the debugger gets locked in a loop. It keeps looking for >1B00 and looping back. On a smaller program that never uses >E000 on up it does not crash? I should not jump to conclusions so I will keep testing. Edited July 16, 2011 by RXB Quote Link to comment Share on other sites More sharing options...
+Torrax Posted July 16, 2011 Author Share Posted July 16, 2011 I'm using the latest version QI356. SXB has had this problem with Classic99 for sometime. Just starting to use the debugger more so recently. And got the urge to sit down and step through the startup process of SXB to see what was happening. I think the GK Extended Basic may have the same problem, as it uses the same Auto-Load bypass code. Quote Link to comment Share on other sites More sharing options...
Tursi Posted July 16, 2011 Share Posted July 16, 2011 (edited) That is odd. I extensively use the upper 2k of GROM space in my MPD program without any issues. Are you saying that the CALL G@>DFFE statement is actually setting a GROM address of >E000? Did you trace into that statement to see why? I don't have access to most of my usual tools and won't until late September, but it's a curious bug you've found. edit: seems my copy of Super XB doesn't even work, guess I have a bad dump. Is your dump available anywhere? Edited July 16, 2011 by Tursi Quote Link to comment Share on other sites More sharing options...
John Doe Posted July 16, 2011 Share Posted July 16, 2011 (edited) Edited February 22, 2014 by Tony Knerr Quote Link to comment Share on other sites More sharing options...
+Torrax Posted July 17, 2011 Author Share Posted July 17, 2011 (edited) Just checked XB25 and the Auto-Load by pass works. Been single stepping through SXB, and noticed that it actual makes it to DFFE (51F7). But messes up in the "GLP BR" calculation of the high bit. So the instruction BR G@>D117 (51F7) is re-calculated to BR G@>F117. Tursi, what are you using to display the GPL address in the debugger? As it is very inconsistant on the data in the Hbyte & Lbyte. Any data that is read or write is affecting the GROM address. Do you have the address and read/write ports separate? Attached is my original dumped module -- used V9T9's Trans utility back in the mid 90's. sxb-multimod.zip Edited July 17, 2011 by Torrax 1 Quote Link to comment Share on other sites More sharing options...
+Torrax Posted July 17, 2011 Author Share Posted July 17, 2011 Okay, just looked at Classic99's source code, and noticed that there is a hack for GRAM devices. The description is that the prefetch is different and the write address goes to the GROM address minus one. Super Extended Basic is a similar device, and has the same prefetch problem. It looks like we need both read and write addresses going to the GROM address minus one. This would clear up the problem SXB is having with the GPL code at DFFE: B G@>D117. The GROM address would not auto increment into the >E000 range. Also does a GROM read/write destroy the Hbyte of the GROM address?? Quote Link to comment Share on other sites More sharing options...
RXB Posted July 17, 2011 Share Posted July 17, 2011 Okay, just looked at Classic99's source code, and noticed that there is a hack for GRAM devices. The description is that the prefetch is different and the write address goes to the GROM address minus one. Super Extended Basic is a similar device, and has the same prefetch problem. It looks like we need both read and write addresses going to the GROM address minus one. This would clear up the problem SXB is having with the GPL code at DFFE: B G@>D117. The GROM address would not auto increment into the >E000 range. Also does a GROM read/write destroy the Hbyte of the GROM address?? OMG my CALL GOKEY and ONKEY are in the >A000 to >BFFF range of the RXB module. Why is my Classic99 Debugger geting stuck at >1B00 in the ROM all the time? Could this be the bug my code is accessing via the XB ROMs? The ROMs XMLs that I use are called from my code at >BF3D to >BFEC and only crashes when it hits that last line CALL G@>0012 is called. But works fine if the XB program size is under 2K and crashs if over. Now as XB programs load from >FFFF to >A000 this would makes sense as a 2K program crosses that boundry from >E000 to >C000 as XB loads backwards from highest to lowest address. And the line number table woud be first to cross that boundary as it is always at the lowest address as the program grows larger. I am loading Windows 7 and moving away from XB 64 so will have to test this out. Also updating Classic99 to newest version also. Quote Link to comment Share on other sites More sharing options...
+Torrax Posted July 17, 2011 Author Share Posted July 17, 2011 Found it!! The problem is with how the GPL interpreter forms its GPL address. Commands that are masked with a GPL address (i.e. 5117 - B G@>D117) can become malformed when they are adjunct or split across an 8K boundary. To keep the explanation short, check out the source code for the interpreter in the "TI Intern" book. Try to step through the GPL command, >5117 at an address of >DFFC. And slowly increase the address till the data is split across the boundary. You will see the instruction change from "B G@>D117" to "B G@>F117". This seems to be an aparant bug in our interpreter when using GROMS bigger than 6K. There is no easy solution for this, but careful coding in the affected area. Quote Link to comment Share on other sites More sharing options...
Willsy Posted July 17, 2011 Share Posted July 17, 2011 Ok, so, to be clear, its not a bug in classic99 per se, its an issue with the design of the original TI GPL interpreter, yes? Quote Link to comment Share on other sites More sharing options...
RXB Posted July 17, 2011 Share Posted July 17, 2011 Ok, so, to be clear, its not a bug in classic99 per se, its an issue with the design of the original TI GPL interpreter, yes? LOL ok so now when I write GPL programs I have to look at the listings and look for this? No wonder some projects just crashed and no debugging in the world would fix them. This also explains why when I was just moving subroutines or subprograms they suddenly started to work correctly. Quote Link to comment Share on other sites More sharing options...
+Torrax Posted July 18, 2011 Author Share Posted July 18, 2011 Yes its the interpreter . Remember they designed it with 6K GROMS in mind. Just follow TI's standard where they used the last two bytes for a CRC checksum (leave it blank). And remember to use the long form of instructions to access other GROM banks. ie. "BR G@>ABDE"; not "B G@>ABCD". Classic99 seems to emulate true 8K GROM operation. Tursi's MPD program and board might be the first TRUE GROM device for the TI-99. I think the GramKracker/SXB have something in their hardware that makes the GROM/GRAM address a pending auto increment till the next read/write. The read/write address ports may be using only a flip-flop and not connected to the auto increment. This could explain how we can get a proper GPL command in the last two bytes of an 8K GROM, with TI's Interprerer. Correct me if I'm wrong here. So try to avoid GPL code there. Storing DATA such as an EA Program across the boundaries works. As long as the first byte at the GROM start doesn't contain an >AA (Program) or a negative value (Auto-Start Program). --- Quote Link to comment Share on other sites More sharing options...
Tursi Posted July 18, 2011 Share Posted July 18, 2011 Thanks for all your work digging into this! I have learned a couple of things myself, which is much appreciated! Quote Link to comment Share on other sites More sharing options...
RXB Posted July 18, 2011 Share Posted July 18, 2011 Yes its the interpreter . Remember they designed it with 6K GROMS in mind. Just follow TI's standard where they used the last two bytes for a CRC checksum (leave it blank). And remember to use the long form of instructions to access other GROM banks. ie. "BR G@>ABDE"; not "B G@>ABCD". Classic99 seems to emulate true 8K GROM operation. Tursi's MPD program and board might be the first TRUE GROM device for the TI-99. I think the GramKracker/SXB have something in their hardware that makes the GROM/GRAM address a pending auto increment till the next read/write. The read/write address ports may be using only a flip-flop and not connected to the auto increment. This could explain how we can get a proper GPL command in the last two bytes of an 8K GROM, with TI's Interprerer. Correct me if I'm wrong here. So try to avoid GPL code there. Storing DATA such as an EA Program across the boundaries works. As long as the first byte at the GROM start doesn't contain an >AA (Program) or a negative value (Auto-Start Program). --- As a GPL programmer I have never run into this till now, I wonder how many Cartridges are buggy becuase of this? Just RXB, SXB, and others that use the extra 2K there in the 5 GROMs, that is a lot of space as 10K in a TI in not a little amount or GRAM. So the solution is the ROM 0 that sets the boundry at 6K or is the problem somewhere else? Quote Link to comment Share on other sites More sharing options...
John Doe Posted July 18, 2011 Share Posted July 18, 2011 (edited) Edited February 22, 2014 by Tony Knerr Quote Link to comment Share on other sites More sharing options...
jacquesg Posted July 18, 2011 Share Posted July 18, 2011 "The person to ask about this would be Michael Becker, and perhaps a test of the SXB bypass of DSK1.LOAD capability would be in order (Jacques?). I don't know if I've got a dump of it on my 4P system, so it might take a little work for me to test it. But I will try unless someone beats me to it." I am not sure what I should be testing. I have an HSGPL card and SXB is installed in the 1st bank. I also have the Winkler GROM0 installed mainly so that I can load TurboForth from one of the HSGPL banks. I modified SXB so that it looks for DSK3.LOAD instead of DSK1.LOAD to load Funnelweb. Since I also use an HRD memory card I usually access Funnelweb by entering CALL FW from TI BASIC. RXB and XB v2.5 will go to command mode if I press the space bar when starting. Mechatronic XB and SXB do not and will continue to load either DSK1.LOAD or DSK3.LOAD as appropriate. Jacques Quote Link to comment Share on other sites More sharing options...
RXB Posted July 19, 2011 Share Posted July 19, 2011 "The person to ask about this would be Michael Becker, and perhaps a test of the SXB bypass of DSK1.LOAD capability would be in order (Jacques?). I don't know if I've got a dump of it on my 4P system, so it might take a little work for me to test it. But I will try unless someone beats me to it." I am not sure what I should be testing. I have an HSGPL card and SXB is installed in the 1st bank. I also have the Winkler GROM0 installed mainly so that I can load TurboForth from one of the HSGPL banks. I modified SXB so that it looks for DSK3.LOAD instead of DSK1.LOAD to load Funnelweb. Since I also use an HRD memory card I usually access Funnelweb by entering CALL FW from TI BASIC. RXB and XB v2.5 will go to command mode if I press the space bar when starting. Mechatronic XB and SXB do not and will continue to load either DSK1.LOAD or DSK3.LOAD as appropriate. Jacques That is only for one thing, the Autoload, this problem is major for any subroutines that may reside at that boundry. It is not like when I started with GRAM devices any of these devices had this problem, none of them did. It would explain why I have a couple of RXB programs that crash for unkown reasons. Perfect example is CALL HEX would crash for no reason at all, it calls a subroutine NGOOD (NumberGOOD) that starts at >B5FF and this routine assigns numeric variables. So now having to go thru the GPL code to fix this means a rewrite and some routines on this boarder will have to be split up. How did PC99 get away with this not being a problem? Quote Link to comment Share on other sites More sharing options...
+Torrax Posted July 19, 2011 Author Share Posted July 19, 2011 "The person to ask about this would be Michael Becker, and perhaps a test of the SXB bypass of DSK1.LOAD capability would be in order (Jacques?). I don't know if I've got a dump of it on my 4P system, so it might take a little work for me to test it. But I will try unless someone beats me to it." I am not sure what I should be testing. I have an HSGPL card and SXB is installed in the 1st bank. I also have the Winkler GROM0 installed mainly so that I can load TurboForth from one of the HSGPL banks. I modified SXB so that it looks for DSK3.LOAD instead of DSK1.LOAD to load Funnelweb. Since I also use an HRD memory card I usually access Funnelweb by entering CALL FW from TI BASIC. RXB and XB v2.5 will go to command mode if I press the space bar when starting. Mechatronic XB and SXB do not and will continue to load either DSK1.LOAD or DSK3.LOAD as appropriate. Just keep the same key pressed down on your initial selection, or any other when starting. This works properly with my SXB module (Silver TI-99/4A). That is only for one thing, the Autoload, this problem is major for any subroutines that may reside at that boundry. It is not like when I started with GRAM devices any of these devices had this problem, none of them did. It would explain why I have a couple of RXB programs that crash for unkown reasons. Perfect example is CALL HEX would crash for no reason at all, it calls a subroutine NGOOD (NumberGOOD) that starts at >B5FF and this routine assigns numeric variables. So now having to go thru the GPL code to fix this means a rewrite and some routines on this boarder will have to be split up. How did PC99 get away with this not being a problem? >B5FF should work. Its the 7FFE, 9FFE, BFFE, CFFE, and FFFE boundaries. Could be the use of GPL "BS" and "BR" instructions, as they can only be used within the same GROM (Ref in TI Intern). Quote Link to comment Share on other sites More sharing options...
jacquesg Posted July 19, 2011 Share Posted July 19, 2011 "Just keep the same key pressed down on your initial selection, or any other when starting. This works properly with my SXB module (Silver TI-99/4A)." No, this does not work for me. I am also using a Silver TI-99/4A. I have tried holding down a variety of keys including #2 that loads XB and with SXB, Funnelweb pops up after a second or two from DSK3. With Mechatronic XB I get the same result but it takes a bit longer because it is loading from a floppy in DSK1. This is not a problem for me because I can get to XB command mode by selecting XB RETURN from the Funnelweb XB menu. We seem to be getting OT from helping RXB solve his problem. Jacques Quote Link to comment Share on other sites More sharing options...
Tursi Posted July 19, 2011 Share Posted July 19, 2011 (edited) I've been thinking about this for a while now. My first thought is, "that's a good question, how /do/ the other emulators get around this issue?" I suspect that the answer is that they do not emulate the GROM prefetch, or that they do it after the instruction is complete. Unlike the VDP, the GROMs prefetch doesn't need accurate emulation to work correctly -- or so I previously thought. It seems this case has revealed an edge condition. A proper GROM prefetches immediately after a byte is read. It can't do it before an instruction is emulated since it doesn't know that instructions are being read. However, TI emulation, as far as my experiments have gone, works correctly if you do not emulate the prefetch. As far as I know, most GRAM devices don't prefetch, which lends strong support to that. Without the prefetch, a BR instruction at >5FFE would leave the address pointer at >5FFF, which would allow the BR to work correctly in the GROM. With the prefetch, though, the address increments up to >6000, and so the branch happens in the next GROM (which is not the expected behaviour). Edit: Another possibility I just thought of, covered by test case 2 below, is that the GROM address wraps around to >4000, not up to >6000, which would be both a Classic99 bug and allow the expected operation to succeed!) I think the operation of the GRAM devices is pretty easy to understand. They maintain a single address counter and so increments and the like happen as you'd expect for a block of 64k of memory. However, GROMs themselves operate differently. They are 6k devices (at least, nobody has shown me a manufactured 8k GROM yet). Because of the 2k gap between GROMs, official software never just runs from one GROM into the next - it won't work. Data read from the upper 2k of a GROM's address space is technically undefined (I've seen a couple of suggestions, though). Classic99's goal is to reproduce the hardware of the system, with a de-emphasis on add-on hardware. So that means I'm inclined to properly understand the operation of real GROMs better, first. To do that, I guess I'll need to run some tests on real hardware (which, unfortunately, I won't have access to until September - unless someone is in British Columbia's Okanagan Valley with a console and a MiniMem?) Specifically, the tests I want to run against real GROMs are: 1 - Read GROM data from >1800 - >1810 (or so) and compare with the data at >0000 - >0007, >0800 - >0807, and >1000 - >1007 (to validate some theories). This could be done quickly using EasyBug. 2 - Read GROM data from >3FFE - >4003 using auto-increment only. This can't be done using Easybug, it will require a small piece of assembly. Need to see if the GROM pointer rolls to the GROM at >4000, or if it wraps around inside the second GROM back to >2000. This is really the most important one. Point 2 will give me the correct operation for real GROMs. We already know the correct operation for GRAM devices, as noted above, and I am thinking that the fact that one version of SXB relies on this means that I should probably code an exception in Classic99 for it, and probably just assume 8k GROMs will run in that mode. If someone is willing to help me out (on hardware with NO GRAM device, please), all you need is the MiniMem cart for EasyBug. For test one, enter "G1800", and just hit enter 8 times, and record the data. Press period (.), then G0000, and repeat. Repeat for >0800 and >1000, too. For test 2, you need to execute a small assembly program, and then collect the data, something like this will work (tested in emulation): 1 AORG >7100 2 7100 0300 LIMI 0 * no interrupts (they will mess up the address) 2 7102 0000 3 7104 0200 LI R0,>1FFE * address to start 3 7106 1FFE 4 7108 D800 MOVB R0,@>9C02 * write address LSB 4 710A 9C02 5 710C 06C0 SWPB R0 6 710E D800 MOVB R0,@>9C02 * write address MSB 6 7110 9C02 7 7112 0201 LI R1,>7200 * where to store the result 7 7114 7200 8 7116 0200 LI R0,6 * number of bytes to read 8 7118 0006 9 LP 10 711A DC60 MOVB @>9800,*R1+ * get a byte of GROM data 10 711C 9800 11 711E 0600 DEC R0 * count down 12 7120 16FC JNE LP 13 14 7122 0420 BLWP @>0000 * reboot 14 7124 0000 15 16 7126 0000 END To enter it, in EasyBug enter M7100 to start entering data. The third column is the data to enter, one byte at a time (the first row is 0300, and you must type 03, press enter, then 00, press enter to put them in). It's kind of a pain but still reasonably quick. When done, press period (.) for command mode, then E7100 to run it. It should reset pretty much immediately. Go back into Easy Bug. Then using almost the same technique as for test 1, we dump the results, by viewing CPU memory at >7200, and also dump from GROM >3FFE to compare: (This is all as much for my own reference as anything, but if anyone is willing to run those tests for me and knows a bit around EasyBug, I'd appreciate it). Did I miss anything? (edit: fix asm entry instructions) Edited July 22, 2011 by Tursi Quote Link to comment Share on other sites More sharing options...
Tursi Posted July 19, 2011 Share Posted July 19, 2011 Perfect example is CALL HEX would crash for no reason at all, it calls a subroutine NGOOD (NumberGOOD) that starts at >B5FF and this routine assigns numeric variables. But why would >B5FF be a problem address? Even a real 6k GROM would work up till >B7FF, and the wrap bug described here wouldn't be an issue until >BFFF. The operation of the BR command is software inside the GPL interpreter, and not in the hardware itself. I'm not sure if it honors the upper 2k memory range, but I'm pretty sure it does! I think my MPD code uses it a lot there... So now having to go thru the GPL code to fix this means a rewrite and some routines on this boarder will have to be split up.How did PC99 get away with this not being a problem? This may be valid, but it may be overreacting. Is it /only/ Classic99 in everyone's experience that has this issue? Quote Link to comment Share on other sites More sharing options...
RXB Posted July 19, 2011 Share Posted July 19, 2011 (edited) Perfect example is CALL HEX would crash for no reason at all, it calls a subroutine NGOOD (NumberGOOD) that starts at >B5FF and this routine assigns numeric variables. But why would >B5FF be a problem address? Even a real 6k GROM would work up till >B7FF, and the wrap bug described here wouldn't be an issue until >BFFF. The operation of the BR command is software inside the GPL interpreter, and not in the hardware itself. I'm not sure if it honors the upper 2k memory range, but I'm pretty sure it does! I think my MPD code uses it a lot there... So now having to go thru the GPL code to fix this means a rewrite and some routines on this boarder will have to be split up.How did PC99 get away with this not being a problem? This may be valid, but it may be overreacting. Is it /only/ Classic99 in everyone's experience that has this issue? Sorry ment >B7FF thanks. I am rebuilding my MacPro on the Windows side so if no one else has helped you with this I will. Edited July 20, 2011 by RXB Quote Link to comment Share on other sites More sharing options...
RXB Posted July 22, 2011 Share Posted July 22, 2011 Turns out I only have a PGRAM Mini Memory so I do not think that would be the results of what you need to the test you posted. I have DATABIOTICS 32K Supercart but the battery circut does not function. Quote Link to comment Share on other sites More sharing options...
Willsy Posted July 22, 2011 Share Posted July 22, 2011 I'll check my cart box tonight and see if I have a mini-mem in there. I'm 99% sure I do. Of course, being a British console, all our GROMS are PAL, therefore results may differ from NTSC GROMS (joke!) Quote Link to comment Share on other sites More sharing options...
+Torrax Posted April 14, 2020 Author Share Posted April 14, 2020 (edited) Bump for Classic 99 & SXB problems. Also my SXB zip pack for the emul. SXBC/D/G (SXB fix); SXB-EAC/D/G (SXB fix with EA); SXBGKEAC/D/G; (SXB fix with GK-EA); SXB-MM (SXB Multi-Mod for 2nd GROM Library) SXB_fix-vers-and-multimod.7z Edited April 14, 2020 by Torrax Updated 7-zip 1 Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.