Jump to content
IGNORED

Assembly on the 99/4A


matthew180

Recommended Posts

9 hours ago, GDMike said:

<snip>  Was it just intended to write to ROMs and package up that way?

Interpreters have always been used to save program space. They do this many times, as GPL does, by making all instructions only one byte in size. (byte code interpreter). This method also allows you to assign special bytes as higher level instructions meaning they enable more complicated routines. All this applies to the stock 99 console which only 256 bytes of CPU memory and all the rest living in the video processor! That's a very constricted system. :-)

 

I can't prove this but it is possible that the GPL authors were influenced by Forth as it has a data stack AND a program return stack.  Using stacks can conserve program space as well in a byte code interpreter by not requiring arguments in the instruction stream. This is because all arguments are known to be on the data stack. In this respect I don't know enough about GPL to know if they took advantage of this idea.

 

My 2 cents.

  • Like 2
  • Thanks 1
Link to comment
Share on other sites

25 minutes ago, TheBF said:

Interpreters have always been used to save program space. They do this many times, as GPL does, by making all instructions only one byte in size. (byte code interpreter). This method also allows you to assign special bytes as higher level instructions meaning they enable more complicated routines. All this applies to the stock 99 console which only 256 bytes of CPU memory and all the rest living in the video processor! That's a very constricted system. :-)

 

I can't prove this but it is possible that the GPL authors were influenced by Forth as it has a data stack AND a program return stack.  Using stacks can conserve program space as well in a byte code interpreter by not requiring arguments in the instruction stream. This is because all arguments are known to be on the data stack. In this respect I don't know enough about GPL to know if they took advantage of this idea.

 

My 2 cents.

 

P-code interpreters probably influenced the GPL designers, as well. The idea of p-code predates Forth by several years, though the popular use of p-code interpreters (notably, the UCSD Pascal P-System) brackets Moore’s invention of Forth.

 

...lee

  • Like 3
Link to comment
Share on other sites

16 hours ago, Tursi said:

Sorry Rich.. you know I think GPL is okay and definitely has its place, but you made the challenge. ;)

 

challenge.lst 13.39 kB · 10 downloads

 

No support code needed, 342 bytes.

 

But I don't think the GPL code provided takes anywhere near 1073 bytes... what were you including?

 

The biggest chunk is support for character definitions: 

605D: MOVE  >03CC BYTES FROM GROM@>61B7 TO VDP@>1002

The rest is just GPL setting up VDP, again Assembly takes up tons of memory in comparison.

Example in Assembly you need VMBW to move from ROM or RAM to VDP.

The above "MOVE >03CC,G@>6187,V@>1002"  takes 7 GROM bytes, I know Assembly is no where that compact.

 

My article from Micropendium "Comparing Languages" explains the differences between XB, GPL and Assembly.

With out support routines loaded like VMBR or VMBW or VSBR or VSBW or DSR assembly can not do anything easy, these take up space (Just a fact).

Unlike GPL that already has those built into the OS. If the above support routines were built in then things would be different.

  • Like 2
Link to comment
Share on other sites

18 hours ago, Tursi said:

Sorry Rich.. you know I think GPL is okay and definitely has its place, but you made the challenge. ;)

 

challenge.lst 13.39 kB · 11 downloads

 

No support code needed, 342 bytes.

 

But I don't think the GPL code provided takes anywhere near 1073 bytes... what were you including?

 

(Full disclosure I don't know that the original GPL program actually did)

 

But if in some alternate reality ? ... we made a set of ROMS for TI-99 with Forth instead of GPL... and we put the workspace and two Forth stacks in scratchpad

(32+64+64 bytes) ...

You could add CHARSET to the system and it uses 178 bytes which includes labels and a re-usable routine GVMOVE that reads GROM and writes to VDP.

Mea culpa but I hard-coded the PDT and GROM font address here for my own system but they could be variables fed by a two other routines and it would still be small.

HEX
: GROM   ( addr -- ) DUP 9C02 ! 9C02 C! ;       \ set the GROM address
: GC@+   ( -- c)     9800 C@ ;                  \ read & auto-increment address
: ]PDT   ( char# -- 'pdt[n] )  8* 800 + ;       \ VDP pattern Descriptor table
: ]GFONT ( ascii -- grom_adr) BL -  7 * 6B4 + ; \ GROM array of TIFont data

\ transfer directly from GROM to VDP
: GVMOVE  ( grom_addr vdp_addr cnt -- )
          ROT GROM   BOUNDS DO  GC@+ I VC!  LOOP ;

: CHARSET ( -- )
        [CHAR] ~ 1+  BL                \ all ASCII chars
        DO
           I ]GFONT                     \ get GROM address for char I
           I ]PDT                       \ get PDT address for char I
           0 OVER VC!                   \ store 1st zero in VDP
           1+                           \ inc PDT address
           7 GVMOVE                     \ write 7 bytes GROM->VDP
        LOOP ;

GVMOVE is like Tursi's GPL2VDP routine (albeit slower) and it would be used like this which took another 116 bytes.

So 178+116= 294 bytes

HEX
: MOVESTUFF
   6077 0C80 10 GVMOVE
   6087 0AE0 32 GVMOVE
   60B7 0B40 30 GVMOVE
   60E7 0B80 10 GVMOVE
   60F7 0BC0 B8 GVMOVE
   61AF 0CC0 08 GVMOVE
   6077 0384 08 GVMOVE
;

All that to say that 1073 bytes does seem a bit weighty so there must be more going on.

 

 

 

Edited by TheBF
Wrong number of bytes for workspace
  • Like 1
Link to comment
Share on other sites

2 hours ago, TheBF said:

(Full disclosure I don't know that the original GPL program actually did)

 

But if in some alternate reality ? ... we made a set of ROMS for TI-99 with Forth instead of GPL... and we put the workspace and two Forth stacks in scratchpad

(32+64+64 bytes) ...

You could add CHARSET to the system and it uses 178 bytes which includes labels and a re-usable routine GVMOVE that reads GROM and writes to VDP.

 

I want this. I want a 4A that has nothing but FORTH on it. Then it would be a 99/4thA.

 

Seriously, I would use this.

  • Thanks 1
  • Haha 1
Link to comment
Share on other sites

I'm reviewing a piece of assy code from R.A.Green which sets up keyboard input and Display architecture. It looks interesting. Not a BLWP Kscan,Vmbw, etc...In it I think. 

I was hoping I could assemble this but I just found this! I know what he's saying, but my editor assembler doesn't..

IMG_20190727_164830903_HDR.jpg

IMG_20190727_164825945_HDR.jpg

Edited by GDMike
Link to comment
Share on other sites

2 hours ago, FarmerPotato said:

I want this. I want a 4A that has nothing but FORTH on it. Then it would be a 99/4thA.

 

Seriously, I would use this.

It would be a big undertaking and keeping it compatible would be impossible I think.

Which Forth system are you using now?

  • Like 1
Link to comment
Share on other sites

Just now, TheBF said:

It would be a big undertaking and keeping it compatible would be impossible I think.

Which Forth system are you using now?

Doesn't have to be compatible. Just let it be an instant-on FORTH prompt. Graphics and sound. It would have to be able to call the disk controller DSR (or rewrite it) and have its own RS232 primitives. Having fast internal 32K would be a nice complement. 

  • Like 1
Link to comment
Share on other sites

14 minutes ago, FarmerPotato said:

Doesn't have to be compatible. Just let it be an instant-on FORTH prompt. Graphics and sound. It would have to be able to call the disk controller DSR (or rewrite it) and have its own RS232 primitives. Having fast internal 32K would be a nice complement. 

I want one too!

 

I will noodle on it. Maybe It could be tested by swapping ROM files on an emulator ????

That would be soooo much better.

  • Like 1
Link to comment
Share on other sites

6 hours ago, GDMike said:

I'm reviewing a piece of assy code from R.A.Green which sets up keyboard input and Display architecture. It looks interesting. Not a BLWP Kscan,Vmbw, etc...In it I think. 

I was hoping I could assemble this but I just found this! I know what he's saying, but my editor assembler doesn't..

 

Perhaps the code was written for Green’s Macro-Assembler, RAGASM, which code would likely not be compatible with the TI E/A Assembler.

 

...lee

  • Like 1
  • Thanks 1
Link to comment
Share on other sites

On 7/25/2019 at 6:21 PM, arcadeshopper said:

wrong.  Many grom games were converted to run from ram with a little code to copy the grom image to ram then execute.. runs great..from disk or rom cart.. needs 32k tho if your copy needs 32k, that's what it's doing.

Looking at the GPL interpreter in INTERN, it's hard for me to see how this could work. The GPL interpreter is hard coded in the ROM. At >0078 is MOVB *R13,R9 which fetches the GPL byte into R9. Assuming you set up R9 to point to the byte in RAM, to fetch it would have to be MOVB *R13+,R9. There are lots of places in the interpreter with JMP >0070 or B @>0070. So hard wired in the ROM are instructions that send the microprocessor to an instruction that doesn't do the right thing.  I believe you could rewrite the GPL interpretor so it can deal with RAM instead of groms - that would be 8K of assembly code, unfortunately on the 8K bus so performance would be slower.

 

Many cartridges used GPL and ROM. The GPL was used to load the screen, character definitions and other set up tasks, then control would be transferred to the assembly portion of the program. The GPL portions could be duplicated in assembly, but then you're not running GPL from RAM; you're running straight assembly.

 

Although I can't see how you could run GPL from RAM, that doesn't mean it can't be done. Some of the cartridges that are pure GPL are BLASTO, CAR WARS, AMAZING, HUNT THE WUMPUS, THE ATTACK, and many others. If they have been converted to run from RAM that shows that it can be done.

 

The real subject was RAGASM and whether it was written in GPL. RAGASM consists of two files: one loads into >2000 to >3FFF; the other loads from >A000 to >BE16. I disassembled this code and found that it is straight assembly code from >2000 to >3FFF. >A000 to >B2C8 is also assembly. >B7C8 to >BE16 is assembly and character definitions. The section of code from about >B2C8 to >B7C8 is not assembly instructions and it doesn't look like GPL code either. It looks like some sort of table. There what seem to be evenly spaced numbers often separated with multiple >0000 and >2000 and others. The bottom line is that RAGASM is either all assembly code or almost all assembly. If any of it is written in GPL is is a small fraction of the total code.

 

 

 

  • Like 1
  • Thanks 1
Link to comment
Share on other sites

2 hours ago, senior_falcon said:

Looking at the GPL interpreter in INTERN, it's hard for me to see how this could work. The GPL interpreter is hard coded in the ROM. At >0078 is MOVB *R13,R9 which fetches the GPL byte into R9. Assuming you set up R9 to point to the byte in RAM, to fetch it would have to be MOVB *R13+,R9. There are lots of places in the interpreter with JMP >0070 or B @>0070. So hard wired in the ROM are instructions that send the microprocessor to an instruction that doesn't do the right thing.  I believe you could rewrite the GPL interpretor so it can deal with RAM instead of groms - that would be 8K of assembly code, unfortunately on the 8K bus so performance would be slower.

 

Many cartridges used GPL and ROM. The GPL was used to load the screen, character definitions and other set up tasks, then control would be transferred to the assembly portion of the program. The GPL portions could be duplicated in assembly, but then you're not running GPL from RAM; you're running straight assembly.

 

Although I can't see how you could run GPL from RAM, that doesn't mean it can't be done. Some of the cartridges that are pure GPL are BLASTO, CAR WARS, AMAZING, HUNT THE WUMPUS, THE ATTACK, and many others. If they have been converted to run from RAM that shows that it can be done.

 

The real subject was RAGASM and whether it was written in GPL. RAGASM consists of two files: one loads into >2000 to >3FFF; the other loads from >A000 to >BE16. I disassembled this code and found that it is straight assembly code from >2000 to >3FFF. >A000 to >B2C8 is also assembly. >B7C8 to >BE16 is assembly and character definitions. The section of code from about >B2C8 to >B7C8 is not assembly instructions and it doesn't look like GPL code either. It looks like some sort of table. There what seem to be evenly spaced numbers often separated with multiple >0000 and >2000 and others. The bottom line is that RAGASM is either all assembly code or almost all assembly. If any of it is written in GPL is is a small fraction of the total code.

 

Here is a link to post#287 of FlashROM 99 & FinalGROM 99 - Repository in which I posted the linker docs for the RyteData GPL Linker, which can run GPL cartridge code from the 32 KiB expansion RAM by loading a GPL simulator into the lower 8 KiB to interpret the GPL object code loaded with it into the upper 24 KiB. I am not aware of any source code for this GPL simulator, but that would sure be nice.

 

...lee

  • Like 2
  • Thanks 1
Link to comment
Share on other sites

9 hours ago, senior_falcon said:

 I believe you could rewrite the GPL interpretor so it can deal with RAM instead of groms - that would be 8K of assembly code, unfortunately on the 8K bus so performance would be slower.

 

 

6 hours ago, Lee Stewart said:

 

Here is a link to post#287 of FlashROM 99 & FinalGROM 99 - Repository in which I posted the linker docs for the RyteData GPL Linker, which can run GPL cartridge code from the 32 KiB expansion RAM by loading a GPL simulator into the lower 8 KiB to interpret the GPL object code loaded with it into the upper 24 KiB. I am not aware of any source code for this GPL simulator, but that would sure be nice.

 

...lee

So it is as I thought-a new GPL interpreter in RAM. Do you know if it uses all 8K of low memory? Maybe they were clever enough to use some of the GPL interpreter in ROM.

Looks like you'd have to adjust address pointers in the GROM code to deal with the new location. For example, GROM at >G0C7E is CALL GROM >11F2 which is >0611F2. 

  • Like 1
Link to comment
Share on other sites

1 hour ago, senior_falcon said:

So it is as I thought-a new GPL interpreter in RAM. Do you know if it uses all 8K of low memory? Maybe they were clever enough to use some of the GPL interpreter in ROM.

Looks like you'd have to adjust address pointers in the GROM code to deal with the new location. For example, GROM at >G0C7E is CALL GROM >11F2 which is >0611F2. 

 

Well, the first six bytes of UTIL1 are FFFF 0B96 2A00, which means 2966 (>0B96) bytes are loaded at >2A00. The GPL simulator that the linker generates to run the GPL object code it processes for you is actually a copy of UTIL1 with the name as the first of two E/A5 files produced by the linker and its header modified as necessary.

 

...lee

  • Thanks 1
Link to comment
Share on other sites

  • 2 months later...

Something for the 9900 experts

 

I saw this cool routine for Intel86 CPUs that determines if a number n is greater than or equal to a low limit and less than a higher limit.

The did not use jumps but did use a final SBB instruction  (subtract with borrow)

It was used in a Windows Forth system and the code is shown below in a Forth RPN format.

For clarity: 

   hi is in BX

   lo is in AX

  n is in CX

Output is returned in BX.

 

I tried doing this in 9900 code and I can't seem to emulate the SBB instruction correctly. 

I tried jumping on the carry flag to change the output register but no luck?

Anybody know how?
 

CODE within    ( n lo hi -- flag )  \ clever version is taken from Win32For. No JUMPS!
                ax pop.
                cx pop.
                bx ax sub.
                cx ax sub.
                cx bx sub.
                bx bx sbb.
                next.
end-code

Edit:

I got it to work this way. Is this as good as it gets?

 

By way of translating Forth Assembler:

pop is a macro:  *SP+ Rx MOV, 

 NC IF,  assembles:   JOC ELSE, +2 

 ELSE,  assembles:   JMP ENDIF, 

             \  cx ax  bx
             \  R1 R0 tos
CODE WITHIN   ( n  lo  hi -- flag )
               R0  POP,
               R1  POP,
               R0  TOS SUB,
               R0  R1  SUB,
               TOS R1  SUB,
               NC  IF, TOS SETO,
               ELSE, TOS CLR, ENDIF,
               NEXT,
               ENDCODE

 

Edited by TheBF
Link to comment
Share on other sites

You might be slightly faster if you always CLR TOS, and then conditionally SETO, to avoid the extra unconditional JMP.  CLR doesn't modify the flags.  Something like this (guessing at the syntax):

             \  cx ax  bx
             \  R1 R0 tos
CODE WITHIN   ( n  lo  hi -- flag )
               R0  POP,
               R1  POP,
               R0  TOS SUB,
               R0  R1  SUB,
               TOS R1  SUB,
               TOS CLR,
               NC  IF, TOS SETO, ENDIF,
               NEXT,
               ENDCODE

 

Link to comment
Share on other sites

2 hours ago, TheBF said:

I tried doing this in 9900 code and I can't seem to emulate the SBB instruction correctly. 

 

@mizapf said something some time ago about the subtraction instruction and the carry flag. ISTR that it was always(?) set because how the microcode performed the operation. Maybe he will be along shortly to clarify.

 

...lee

  • Like 1
Link to comment
Share on other sites

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