Classic99 CPU bug?

[matthew180]

Interestingly, the game Slymoids uses IDLE, although in emulation I can't see that it relies on it, as Classic99 does not implement the halt and the game still seems to run fine. It may be accidental, or the author may have tried it then never got around to removing it.

 

I thought I read somewhere that almost all TI-produce software for the 99/4A was written on one of their mini-computers. Maybe IDLE was a way to trap or break-point the code being developed and the programmer forgot to remove it in production (which luckily did not have any affect on the 99/4A). Just a guess as to why it might be in there.

 

But since illegal opcodes have no effect on the 9900 you never notice.

 

And I still can't decide if that is a good thing or not. :-)

[Tursi]

Yeah, I think I remember reading that too. And in theory, IDLE should halt execution until the VDP interrupt occurs, which would actually be kind of useful! On a console with nothing else going on and no expansion, it might even work. But I wouldn't recommend it, it'd suck to drop it into a machine and wipe someone's RAMdisk. All depends what's on the rest of the bus, if I follow it right at 4am

 

[RXB]

Hi I am writing a new version of Editor Assembler for RXB and REA that has a better menu system and a configure setup for Editing and Assembly.

 

I have been using Classic99 and the issue is when I step through the Rich Editor Assembler the GROM address it returns are crazy.

 

I fully understand when it goes to GROM 0 for address >0012 for like a DSR, but what the hell it showing address >DFDF or >B6B6 or >DFE6 when nothing is even loaded there?

 

Not a single thing in the GROM code in the EA cart address that address nor is any code in my cart even reference those address.

 

Something has to be wrong with the Classic99 Debugger to give such goofy addresses to me when I attempting to debug GROM code.

 

It makes using the Classic99 Debugger very very hard to use when suddenly it returns a valid address in GROM after reporting all these other unused addresses.

[Tursi]

You are looking at the address after a GROM Address Read. Address reads are destructive, they shift the address from one byte to the other, causing the repeated bytes that you see. That is in fact the address that the GROMs have stored in their registers -- and it will shortly be corrected when the interpreter writes the new address.

 

That said, I think the displayed address is often one or two higher than expected, but debugging GPL is a bit of a pain with a CPU debugger. :/

Edited December 15, 2014 by Tursi

[RXB]

I was just expecting a address somewhere in the area of where it is running.

Not some address that is not even remotely possible to be running.

The GROM address it returns are virtually impossible.

 

It returns address with nothing there at all just Zeros yet shows it executing them????

 

Maybe I am the only one that noticed as how many other GPL programmers are there?

[Gazoo]

 

Maybe I am the only one that noticed as how many other GPL programmers are there?

 

I haven't noticed because I use Hex Workshop for GPL programming, and MESS to test the images I create (and sometimes Classic99).

But I've never used a Debugger, wouldn't know how. If you just run the code you've written, you should know where it turns left by the results.

 

Gazoo

[Tursi]

The displayed address is correct for what is stored in the GROMs. Reading the GROM address corrupts it. That is why you are seeing impossible addresses - the GPL interpreter frequently reads back the address.

[RXB]

 

I haven't noticed because I use Hex Workshop for GPL programming, and MESS to test the images I create (and sometimes Classic99).

But I've never used a Debugger, wouldn't know how. If you just run the code you've written, you should know where it turns left by the results.

 

Gazoo

The issue was using the debugger to where it was going wrong.

The reason I posted this was I was getting address that had nothing there at all loaded.

Tursi explained it best.

 

I had a new version of REA (Rich Editor Assembler) only loaded at >E000 to >FFFF yet was getting address like >B6B6 or >77FE or >7756 and those are empty.

 

Stepping through the GPL program would be BR @>ED78 but the Debuggers would say the next address was >B6B6 so I was perplexed as this made no sense at all.

[lucien2]

Maybe I am the only one that noticed as how many other GPL programmers are there?

I spent a lot of time debugging GPL with Classic99, and I never had problems.

 

Here's how I do it:

1. Type the address where you want to stop (Type "G<XXXX" in the breakpoints list)

2. Wait for the debugger to stop

3. Add "<7A" in the breakpoints list

4. Press F1 to continue until >007A

5. The next GPL instruction code to be executed is in R9H. The GROM address points 2 bytes after this instruction

6. Press F1 to step in GPL code

[RXB]

I spent a lot of time debugging GPL with Classic99, and I never had problems.

 

Here's how I do it:

1. Type the address where you want to stop (Type "G<XXXX" in the breakpoints list)

2. Wait for the debugger to stop

3. Add "<7A" in the breakpoints list

4. Press F1 to continue until >007A

5. The next GPL instruction code to be executed is in R9H. The GROM address points 2 bytes after this instruction

6. Press F1 to step in GPL code

I think you mean F2 as F1 is pause. And I have looked at this.

 

What is the point of putting the incorrect address in the GROM Address in the debugger, it does not do that for CPU address or VDP?

I mean when I step through a GPL program loaded in VDP it does not do this?

I do not get crazy address that have nothing to do with the GPL program in VDP.

 

I kind of realize that GPL does not rank high on the list of needed things for debugging. I mean how many are there?

[Gary from OPA]

I kind of realize that GPL does not rank high on the list of needed things for debugging. I mean how many are there?

 

Only you and me.

[lucien2]

I think you mean F2 as F1 is pause. And I have looked at this.

No I mean F1 (continue to next breakpoint, which is at >007A, in the GPL interpreter).

F2 is stepping into assembly.

If you debug it like that, the GROM address is always correct.

 

I kind of realize that GPL does not rank high on the list of needed things for debugging.

There is a real GPL debugger in the Ti994w emulator from Fred Kaal, but the memory viewer is better in classic99.

Edited December 17, 2014 by lucien2

[RXB]

No I mean F1 (continue to next breakpoint, which is at >007A, in the GPL interpreter).

F2 is stepping into assembly.

If you debug it like that, the GROM address is always correct.

 

 

There is a real GPL debugger in the Ti994w emulator from Fred Kaal, but the memory viewer is better in classic99.

That would be great if I could load GPL that I just wrote into GRAM but as far as I know that is impossible.

None of the Emulators except PC99 and Classic99 allow me to use the GPL*LOADER to load Compressed GPL Object Code into GRAM.

 

As far as I know you can not directly load GRAM into Ti994w but just Carts that have been previously converted.

 

By the way I do not want to step to next breakpoint as if I knew what was broken I would not need breakpoints at all.

One breakpoint is before the problem so I single step (F2) until I see where it is going wrong.

I did the same thing on a Real TI994/A but using MG Explorer but that does not work when creating a new Editor Assembler cart.

Edited December 17, 2014 by RXB

[RXB]

That would be great if I could load GPL that I just wrote into GRAM but as far as I know that is impossible.

None of the Emulators except PC99 and Classic99 allow me to use the GPL*LOADER to load Compressed GPL Object Code into GRAM.

 

As far as I know you can not directly load GRAM into Ti994w but just Carts that have been previously converted.

 

By the way I do not want to step to next breakpoint as if I knew what was broken I would not need breakpoints at all.

One breakpoint is before the problem so I single step (F2) until I see where it is going wrong.

I did the same thing on a Real TI994/A but using MG Explorer but that does not work when creating a new Editor Assembler cart.

 

I run into the same issue when writing RXB as when it goes to XB ROMs it can really get complicated as to what crashed.

[lucien2]

As far as I know you can not directly load GRAM into Ti994w but just Carts that have been previously converted.

I made an utility to convert FIAD compressed objects to a GPL cartridge file to be loaded into Ti994w: GPL objects conversion.zip

You need .NET framework 3.5 (or higher?) to run it.

 

It only converts GPL objects. Here are the steps to run a mix of assembly and GPL:

1. From E/A cartridge, load your assembly objects (it even loads at >6000)

2. From the Ti994w cartridge menu, run the converted GPL cartridge generated by "GPL objects conversion.exe"

 

(I didn't write this utility because I prefer the Ti994w debugger, but because it's the only TI99 emulator that respond to the virtual keyboard of my iPod, with the "LogMeIn" remote desktop app)

Edited December 17, 2014 by lucien2

[Tursi]

What is the point of putting the incorrect address in the GROM Address in the debugger, it does not do that for CPU address or VDP?

It depends on what you define as incorrect.

 

As Classic99 is emulating the hardware, it is reproducing what the real hardware does -- if you stopped at that point on hardware and read out the address, you'd get the same value. It's just the way GROMs work.

 

The VDP /sort/ of does it - if you breakpoint in between the two bytes when setting a VDP address, you will see what looks like the "wrong" address in the VDP register, because it's only half there.

 

Emulating these things is important for making sure that software that "breaks the rules" still works. There is software that abuses the 9918 address register like that, if you don't emulate it correct, it doesn't work. I'm not aware of any software that deliberately abuses the GROM address, but there was no harm in doing it right.

 

The other reason for emulating it is software development -- developers need to be able to see what happens at every instruction of their program - this can help find bugs and see where they went wrong.

[Tursi]

Only you and me.

And Lucien and myself, and several others have at least expressed interest.