Jump to content
IGNORED

Classic99 & SXB Quirk/Bug


Torrax

Recommended Posts

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

Link to comment
Share on other sites

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 by RXB
Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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 by Tursi
Link to comment
Share on other sites

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 by Torrax
  • Like 1
Link to comment
Share on other sites

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??

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

Yes its the interpreter :roll:. 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).

 

---

Link to comment
Share on other sites

Yes its the interpreter :roll:. 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?

Link to comment
Share on other sites

"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

Link to comment
Share on other sites

"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?

Link to comment
Share on other sites

"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).

Link to comment
Share on other sites

"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

Link to comment
Share on other sites

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.

 

post-12959-0-47506500-1311108154_thumb.gif

 

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.

 

post-12959-0-17254300-1311111410_thumb.gifpost-12959-0-87649500-1311110003_thumb.gif

 

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:

 

post-12959-0-34119000-1311110120_thumb.gif

 

(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 by Tursi
Link to comment
Share on other sites

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?

Link to comment
Share on other sites

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 by RXB
Link to comment
Share on other sites

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.

Link to comment
Share on other sites

  • 8 years later...

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.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...