GPL Disassembly

[HOME AUTOMATION]

I am trying to figure out what GPL opcode >87 is(not FMT subinterpreter opcodes).

 

I can find no listing for >86, >87. I am not using a GPL assembler, or disassember. but instead, using a HEX-EDITOR and reference docs.

 

...this has become quite frustrating to me, this morning!

 

...anything???

[+Lee Stewart]

2 minutes ago, HOME AUTOMATION said:

I am trying to figure out what GPL opcode >87 is(not FMT subinterpreter opcodes).

 

I can find no listing for >86, >87. I am not using a GPL assembler, or disassember. but instead, using a HEX-EDITOR and reference docs.

 

...this has become quite frustrating to me, this morning!

 

...anything???

 

>86 is CLR (CLeaR byte) and >87 is DCLR (Double CLeaR 2 bytes).

 

...lee

[+Lee Stewart]

6 minutes ago, Lee Stewart said:

I can find no listing for >86, >87.

 

I cannot tell for sure, but it looks like you were having trouble with >88, too? That is FETCH. Opcodes >86 – >89 are shown on page 87 of Heiner Martin’s TI-99/4A Intern.

 

...lee

[HOME AUTOMATION]

Thanks so much... now I can see it in "GPL Programer guide", unsearchable .pdf.

 

Thierry's page has a typo >88. I didn't notice.

 

BTW, I'm looking into, incorporating the games for Scott Adams' Adventure module, into FG99.

[+Lee Stewart]

7 minutes ago, HOME AUTOMATION said:

Thierry's page has a typo >88. I didn't notice.

 

Yeah, I just noticed that in my edited copy of that information. I will post it an a bit after I correct it.

 

...lee

[+Lee Stewart]

24 minutes ago, Lee Stewart said:

 

Yeah, I just noticed that in my edited copy of that information. I will post it an a bit after I correct it.

 

...lee

 

I misspoke. My “edited copy of [Thierry’s] information” was actually a compilation by Mark Wills (@Willsy). I do not have his original to edit, but here it is with the typo:  GPL Manual.pdf

What I edited was the documentation for the RAG GPL Assembler, which follows:  RAG_GPL_Manual.pdf

 

...lee

[HOME AUTOMATION]

For the moment, I am on pages 3-9, 3-10, 3-11, of TI's "GPL Programer's guide". Funny how each inconsistancy seems to make it more difficult to follow. 3-9 refers to 3-10(should be 3-11). CLR claims to be Format 6, GS, but which "form" of GS, 1,2,3,4,5, or how to determine this is still unclear to me. Format 6 on page 3-10 claims to be GS, but CLR uses GD!

 

The code I'm reviewing, goes: >06(CALL) 72 DB(Grom Addr.), at G72DB is: >87(DCLR) 16 BE (can't be a GROM or ROM addr.), "D opcodes can affect 2 bytes if a leading D is added (e.g. DINC instead of INC).". I assume this to mean, 2 bytes at the dest, addr.. Is the default GD or GS, VRAM?

Edited February 8, 2020 by HOME AUTOMATION

[+Lee Stewart]

2 hours ago, HOME AUTOMATION said:

The code I'm reviewing, goes: >06(CALL) 72 DB(Grom Addr.), at G72DB is: >87(DCLR) 16 BE (can't be a GROM or ROM addr.), "D opcodes can affect 2 bytes if a leading D is added (e.g. DINC instead of INC).". I assume this to mean, 2 bytes at the dest, addr.. Is the default GD or GS, VRAM?

 

Too bad Tony is gone from this plane. I would think >16 after >87 is DCLR @>8316 and that >BE is the next instruction (DST).

 

...lee

[+TheBF]

This makes me think about a GPL "Forth-like" REPL that would use names for the various byte codes and send them to the GPL interpreter.

I know nothing about the bowels of GPL but this could be very handy for debugging stuff (finding the true meaning of these opcodes) especially when coupled with an emulator like Classic99 that let's you watch things happen at the lowest level.

I am dreaming in technicolor Lee?

It sounds like byte coded Forth on the surface.

 

[+Lee Stewart]

1 hour ago, TheBF said:

This makes me think about a GPL "Forth-like" REPL that would use names for the various byte codes and send them to the GPL interpreter.

I know nothing about the bowels of GPL but this could be very handy for debugging stuff (finding the true meaning of these opcodes) especially when coupled with an emulator like Classic99 that let's you watch things happen at the lowest level.

I am dreaming in technicolor Lee?

It sounds like byte coded Forth on the surface.

 

Interesting idea, but getting it to the GPL interpreter and back might be dicey, since, I believe, only GROM/GRAM can contain executable code (not positive about VRAM, but definitely not RAM/ROM).

 

...lee

[HOME AUTOMATION]

Thanks again, Lee!

Yes, I'm sorry about Tony too. Perhaps more than I'll ever know!

 

But at least I have you!

 

I think you got it right, though!

 

I was considering that maybe PAD was the dest.. I had watched CPU RAM with Classic99's debugger, while this code executed, but most locations were already cleared, and the GPL interpreter makes them dance too.

 

Now I set a breakpoint on writes to >8316, sure enough, it did trap the opcode's operand address, after auto-incrementing once or twice more!

 

 

This is only the first few instructions after the program's entry point, not the part I hope to modify. But I needed to find some way to follow along, in order to try to find the exact point or points to breakout(XML) to my "loader code" and back again.

 

My plan is rather simplistic... I'll replace an opcode that executes just before or after the "Where is the database?" message... then I'll  cue the user to enter the game's name with or without a device name, reload FG99's RAM/ROM with a snapshot of the game, and perhaps CPU RAM as well... then I'll use VMBR to load the game to VRAM... reload an unaltered copy of the ADVENTURE GROM into the FG99, and return! If the user includes a "." in the name, I'll kick them back to the module's loader.

 

...or somethin' like that!

 

      Alex

 

 P.S. Hopefully this will go easily, otherwise I may have to surrender it to life's other burdens.