GIF Source Code - Need Help to convert to Geneve and/or SAMS usage

[+9640News]

OK folks, I need some help and maybe this will also help some TI-99/4A'ers with SAMS and 9938's as well.

 

I found someone that wrote a GIF viewer for the Mechatronics Gram Kart for the TI-99/4A to be used with 9938 VDP processors and they released the source code.  They are using the GRAM/GROM not as GRAM/GROM, but as memory storage.  They are just reading and writing to the grom/gram ports to store the decompressed data into the 128K storage of the gram device.

 

I don't understand the usage of gram/grom to the point I do not know how convert that for use on the Geneve in GPL mode, or for that matter, for the Geneve in 9640 mode.  My intent is to have workable source for the Geneve in MDOS mode so that anyone else can use GIF images.  I believe there is also the possibility this code could also be converted to work with the SAMS and TI-99/4A users with a 9938 device to support the graphics modes for the display.  I don't know if it could even be converted to be used with a F18A.

 

I have attached two files, GIF_S which is code I am converting to run from MDOS on the Geneve, and GIF_S.txt which I copied off a website which is the source code that used the 128K Mechatronics Gram Card.  The only information I have on the Gram Card is in the pdf attached as well.

 

The Gram Card is being used as memory storage as the file is being read during the decompression/processing of the image.  I believe once the entire file is read and decompressed (not 100% sure of this), it is then read back and sent to VDP for display. 

 

What I am trying to figure out and understand is how to store the data in Geneve Ram on an 8K boundary.  Let's assume I have RAM at >6000 to >7FFF and it is multiple pages.  I have a pagelist of >00, >01, >02, ... >80 where I can write that byte to >F113 to change to another 8K bank.  I am unable to understand the gram paging/banking for writing/retrieval/paging to put it into something I can understand. Thus, I do not really need to turn on the CRU for the Gram Card with those routines and manipulate bits, etc.  All I really need to do is understand to be able to write 8K of data to a CPU RAM memory range (>6000 to >7FFF), and when I hit the end of that 8K page, map the next page of my list into >6000 to >7FFF and continue writing until all the data is decompressed.  Once it is decompressed, I can then write the data to VDP for the display.  At least that is my understanding how the memory storage is being used within the code.

 

If anyone has the time to look at the code, and potentially comment in the GIF_S.txt file (original TMS 9900 assembly source file), it would be appreciated.  As I said before, the GIF_S is my rewrite and I have commented out pieces for the GPL banking and added other pieces to use for MDOS mode.

 

For a bit more detail, to give you an idea, here is a short piece of code that gives me multiple pages (up to >EF) in the >6000 to >7FFF range.

 

          CLR R0

          MOVB   R0,@>F113             New 8K page(>00) at >6000 to >7FFF

          AI        R0,>0100

          MOVB   R0,@>F113             New 8K page (>01) at >6000 to >7FFF

          AI        R0,>0100

          MOVB  R0,@>F113              New 8K page (>02) at >6000 to >7FFF

 

Between each MOVB instruction, I can write whatever I want to the page at >6000 to >7FFF

 

I just need to have routines that write the data this way, rather than using Gram Card GRAM reads/writes and all the CRU bit manipulation of the Gram Cart.

 

If anyone is able to assist, it would be much appreciated.

 

Beery

 

GIF_S GIF_S.txt gramcard.pdf

[+9640News]

I am hoping someone can explain this code a bit for me............

 

GRMCRU EQU  >1700
GBASIS EQU  >9838
PREFIX EQU  >0000
SUFFIX EQU  >6000
 
GRMRD  EQU  GBASIS
GRMRA  EQU  GBASIS+2
GRMWD  EQU  GBASIS+1024
GRMWA  EQU  GBASIS+1026

 

       CLR  R12

       CLR  @GRMWA            !
       CLR  @GRMWA            !
UNBLLP BL   @NEXTCH           ! Retries next character from buffer
       MOVB 5,2               !
       JEQ  DEKOMP            ! end of file, time to decompress
       SRL  2,8               !
UNLOOP BL   @NEXTCH           !
       MOVB 5,@GRMWD(12)      !
       INC  10                !
       JNC  NOCAR             !
       AI   12,4              !
       LI   3,11              ! ERROR-CODE 11
       MOV  12,11             !
       AI   11,GBASIS         !
       CI   11,>9840          !
       JEQ  BYEBYE            !
       CLR  @GRMWA(12)        !
       CLR  @GRMWA(12)        !
 

This code is using the Mechatronics Gram Cart and I don't quite follow the GRAM writes here.  What is also confusing to me, is  what is >9840 representing?

 

[HOME AUTOMATION]

2 hours ago, 9640News said:

what is >9840 representing?

You'll be much older then...?

 

Let's see... I'm an ?...

 

>9840 = GBASIS+2 = GRMRA.

 

also...

 

VGER is that which seeks the CREATOR = the CREATOR is that which VGER seeks.?

[+InsaneMultitasker]

On 4/16/2022 at 8:24 PM, 9640News said:

This code is using the Mechatronics Gram Cart and I don't quite follow the GRAM writes here.  What is also confusing to me, is  what is >9840 representing

The address >9840 is a grom base, in the case of this hardware I believe it would represent the upper limit of available bases.  In the snip, the code is assuming a CRU address of >1700 and starting grom base of >9838.  The next grom base is >983C, then >9840.

 

Thierry's page has some good information about the GramKarte. 

 

https://www.unige.ch/medecine/nouspikel/ti99/gramkart.htm

[+9640News]

11 hours ago, InsaneMultitasker said:

The address >9840 is a grom base, in the case of this hardware I believe it would represent the upper limit of available bases.  In the snip, the code is assuming a CRU address of >1700 and starting grom base of >9838.  The next grom base is >983C, then >9840.

 

Thierry's page has some good information about the GramKarte. 

 

https://www.unige.ch/medecine/nouspikel/ti99/gramkart.htm

Thanks for that information and link.  I'm going to try and digest its contents and hopefully understand the mapping.

 

Beery

[+InsaneMultitasker]

2 hours ago, 9640News said:

Thanks for that information and link.  I'm going to try and digest its contents and hopefully understand the mapping.

 

Beery

It seemed as if the program sets the card to override the console GROMs so that the entire 64K grom window (8k x 8 banks) is available for two iterations, first at base >9838 then again at >983C, for a total of 128K.   To convert this segment for Geneve use, you would ask the OS for 16 pages of RAM then fill the ram by copying the decompressed byte from R5.  What I don't quite understand with a quick read is how GRAM is being used in a few of the other routines like READPG. You'll have to walk through the routines to sort out what each one is doing with GRAM.

 

 

[+9640News]

42 minutes ago, InsaneMultitasker said:

It seemed as if the program sets the card to override the console GROMs so that the entire 64K grom window (8k x 8 banks) is available for two iterations, first at base >9838 then again at >983C, for a total of 128K.   To convert this segment for Geneve use, you would ask the OS for 16 pages of RAM then fill the ram by copying the decompressed byte from R5.  What I don't quite understand with a quick read is how GRAM is being used in a few of the other routines like READPG. You'll have to walk through the routines to sort out what each one is doing with GRAM.

 

Yeah, with the link you provided, I came to the same conclusion as you. That weblink cleared up some details and I now understand with the grom bank test at >9840, indicates 128K storage was completed.

 

Now, got to figure an 8K rolling bank of pages without messing corrupting other registers.

[+9640News]

Made some progress, or so I think, in converting the GPL read/write routines into mapping code for the Geneve.

 

File loads, but somewhere in the LZW decompression and/or writing out to the VDP, something isn't hitting just right as I am not getting any vdp writes.  Need to go through the code a bit more to see if I can find the issue.

[+9640News]

Making more progress, but not there yet.

 

Got an odd piece of code.

 

LI   R12,>0400

SBO  0      Comment RAM UP >0000 to >1FFF for prefix

SBO  2      Comment RAM UP >6000 to >7FFF for suffix

 

In other code:

 

LI  R12,>0400  All 16-bit memories off

SBZ  0

SBZ  1

SBZ  2

 

Not sure what is happening with that CRU address.  Is this something custom that may have been on the bus?

 

[+9640News]

17 hours ago, 9640News said:

Making more progress, but not there yet.

 

Got an odd piece of code.

 

LI   R12,>0400

SBO  0      Comment RAM UP >0000 to >1FFF for prefix

SBO  2      Comment RAM UP >6000 to >7FFF for suffix

 

In other code:

 

LI  R12,>0400  All 16-bit memories off

SBZ  0

SBZ  1

SBZ  2

 

Not sure what is happening with that CRU address.  Is this something custom that may have been on the bus?

 

Just for a reference, I found some details on this subject in another thread at Internal memory mod - TI-99/4A Computers - AtariAge Forums .  Looks like there was a modification to add 16-bit ram in other memory spaces on the TI console.

[apersson850]

Yes, that's the CRU base address I used to toggle RAM banks in my internal memory expansion. I couldn't find any documentation listing them as used by anything else at that time.