The FinalGROM 99

[ralphb]

29 minutes ago, Asmusr said:

Would it be possible to add a new cartridge type to the FG99 where you could page in 4K pages of the ROM at >6000 and >7000 independently? So, for instance, you could page in >0000->0fff of the ROM at >6000 and >2000->2fff of the ROM at >7000? Or even the same 4K at both >6000 and >7000? 

 Hmm, that sounds a lot like a SAMS! ?  I think this is difficult to achieve.

 

The problem is that you'd need to two additional registers of 7 bits each, and there may not be enough resources in the CPLD left.  Also, I noticed that the CPLD IDE (which also does the synthesis)  no longer works on my current Linux version, so future modifications really need some effort (like a VM).

[+InsaneMultitasker]

9 hours ago, ralphb said:

I think ExtBASIC was just an example.  But obviously when you add RAM/GRAM to it, you need to adapt the bank switching as well!  I assumed he wrote a cart from scratch, and there I don't see the difference.

If you are referring to me, I did not write a cartridge, I was hoping that I could enable RAM at 0x7000 regardless of what cartridge loaded my program. It doesn't seem like this is possible so I am not pursuing it any further.  Although it seems the program could be rolled into a cartridge that moves itself into 32K memory, with RAM mode enabled, so I might onsider that in the future. For now, I'll just rely upon old fashioned program load sequence.

 

[RXB]

I can provide the code of XB ROMS that could be re written to page upper 4K pages of RAM instead of ROM in XB cartridge.

  0207            ************************************************************
  0208 6000              AORG >6000   
  0210                
  0211            * PAGE SELECTOR FOR PAGE 1  
  0212      6000  PAGE1  EQU  $                 >6000   
  0213 6000 0002  C2     DATA 2                 0   
  0214            * PAGE SELECTOR FOR PAGE 2  
  0215      6002  PAGE2  EQU  $                 >6002   
  0216 6002   00  C7     BYTE >00   
  0217 6003   07  CBH7   BYTE >07               2   
  0218 6004   0A  CBHA   BYTE >0A   
  0219 6005   94  CBH94  BYTE >94               4   
  0220 6006 0028  C40    DATA 40                6   
  0221 6008 0064  C100   DATA 100               8   
  0222 600A 1000  C1000  DATA >1000             A   
  0223 600C 0000         DATA 0                 C   
  0224 600E 4001  FLTONE DATA >4001             E   
  0225            ************************************************************
  0226            * XML table number 7 for Extended Basic - must have   
  0227            *     it's origin at >6010  
  0228            ************************************************************
  0229            *           0      1      2      3      4      5     6  
  0230 6010 619C         DATA COMPCG,GETSTG,MEMCHG,CNSSEL,PARSEG,CONTG,EXECG  
       6012 61A2  
       6014 72CE  
       6016 6070  
       6018 6470  
       601A 64C4  
       601C 6500  
  0231            *           7      8    9     A    B    C      D  
  0232 601E 61BA         DATA VPUSHG,VPOP,PGMCH,SYMB,SMBB,ASSGNV,FBSYMB   
       6020 6C2A  

 99/4 ASSEMBLER
XML359                                                       PAGE 0005
       6022 6410  
       6024 61B4  
       6026 61A8  
       6028 61AE  
       602A 618C  
  0233            *             E     F   
  0234 602C 6EE2         DATA SPEED,CRNSEL  
       602E 6076  
  0235            ************************************************************
  0236            * XML table number 8 for Extended Basic - must have   
  0237            *     it's origin at >6030  
  0238            ************************************************************
  0239            *           0   1      2    3      4  5     6      7  
  0240 6030 74AA         DATA CIF,CONTIN,RTNG,SCROLL,IO,GREAD,GWRITE,DELREP   
       6032 65CC  
       6034 6630  
       6036 7ADA  
       6038 7B48  
       603A 7EB4  
       603C 7ED8  
       603E 7EF4  
  0241            *           8    9    A      B      C      D      E   
  0242 6040 7F7E         DATA MVDN,MVUP,VGWITE,GVWITE,GREAD1,GWITE1,GDTECT  
       6042 6F98  
       6044 7FC0  
       6046 7FDA  
       6048 7EA6  
       604A 7ECA  
       604C 6050  
  0243            *           F   
  0244 604E 7C56         DATA PSCAN   
  0245                
  0246            * Determine if and how much ERAM is present   
  0247 6050 D80B  GDTECT MOVB R11,@PAGE1        First enable page 1 ROM   
       6052 6000  
  0248            *-----------------------------------------------------------
  0249            * Replace following line      6/16/81   
  0250            * (Extended Basic must be made to leave enough space at   
  0251            * top of RAM expansion for the "hooks" left by the 99/4A  
  0252            * for TIBUG.)   
  0253            *      SETO R0                Start at >FFFF  
  0254            * with  
  0255 6054 0200         LI   R0,>FFE7          Start at >FFE7  
       6056 FFE7  
  0256            *-----------------------------------------------------------
  0257 6058 D40B         MOVB R11,*R0           Write a byte of data  
  0258 605A 940B         CB   R11,*R0           Read and compare the data   
  0259 605C 1306         JEQ  DTECT2            If matches-found ERAM top   
  0260            *-----------------------------------------------------------
  0261            * Change the following line   6/16/81   
  0262            *      AI   R0,->2000         Else drop down 8K   
  0263 605E 0200         LI   R0,>DFFF          Else drop down 8K   
       6060 DFFF  
  0264            *-----------------------------------------------------------
  0265 6062 D40B         MOVB R11,*R0           Write a byte of data  
  0266 6064 940B         CB   R11,*R0           Read and compare the data   
  0267 6066 1301         JEQ  DTECT2            If matches-found ERAM top   
  0268 6068 04C0         CLR  R0                No match so no ERAM   
  0269 606A C800  DTECT2 MOV  R0,@RAMTOP        Set the ERAM top  

 99/4 ASSEMBLER
XML359                                                       PAGE 0006
       606C 8384  
  0270 606E 045B         RT                     And return to GPL  

 

[HOME AUTOMATION]

15 hours ago, RXB said:

I can provide the code of XB ROMS that could be re written to page upper 4K pages of RAM instead of ROM in XB cartridge.

I'm pretty sure all that needs to change is... Every time >6000 is written to, >6800 also needs to be written to. the same goes for... >6002 and >6802.

 

I guess the big questions are... is there enough space to add the extra 1 or 2 instructions, and will that be hampered by a lot of code that needs to remain at fixed addresses?

 

I don't know if this is of any use to you, or if it will help insane' in any way though.

Edited September 3, 2020 by HOME AUTOMATION

[HOME AUTOMATION]

16 hours ago, InsaneMultitasker said:

I did not write a cartridge, I was hoping that I could enable RAM at 0x7000 regardless of what cartridge loaded my program.

I'm still less than certain what the constraints to your task might be. If you do or don't need to save the state of or return to the image(for example XB), from where you started your program, or both.

 

Saving the state seems a bit problematic, since most existing images are loaded as ROMs.

 

Loading your own image.bin, containing 1 or more pages of RAM @>7000, should be easy, and does not require any programming to be present within the image itself, just a properly named empty/preloaded file of the desired size, be present in the same directory as the image you started from within the FG99, with the 4th byte set to >52.

 

The >52, need not be present in the ROM image, if you load a GRAM image as well, as doing so will also set >7000, to RAM mode.

Edited September 3, 2020 by HOME AUTOMATION
better!!!

[RXB]

7 hours ago, HOME AUTOMATION said:

I'm pretty sure all that needs to change is... Every time >6000 is written to, >6800 also needs to be written to. the same goes for... >6002 and >6802.

 

I guess the big questions are... is there enough space to add the extra 1 or 2 instructions, and will that be hampered by a lot of code that needs to remain at fixed addresses?

 

I don't know if this is of any use to you, or if it will help insane' in any way though.

XB ROM 1 has >7FF8 to >7FFD is empty (6 bytes), XB ROM 2 has >7FFA to >7FFD is empty (4 bytes).

So both XB ROMs have bytes at top empty.

 

Thing is if you look at the code they do some neat tricks, but also so really bad code that wastes space.

There is no reason you could not have a better page switch of 4K ROM at top or even RAM.

 

I thought a lot of BYTES with DATA in them like >0007 or >0A08 could be changed to address using command bytes.

Edited September 3, 2020 by RXB

[majestyx]

This relates to Insane Multitasker's topic on the Infocom interpreter.

 

Is there an easy way to get The FinalGROM to act like a Supercart? I tried hex editing the E/A cart by placing placing R in the 4th byte for the first try (enable RAM), then X for the second try (enable both RAM and GRAM). Same result - the E/A cart loads, choose option 5, enter DSK1.SAMPLER1A . It starts to load, then dumps me back to the FG99 DEV menu, but the menu is not functional. In fact, if I press any keys on the keyboard, it beeps and eventually gives a long BEEEEEEEEP until I turn the system off due to it being locked up.

 

So if there is a way to either create a Supercart image or get the E/A cart image to act like one, please let us know. Thanks~!

[+arcadeshopper]

No there is not.. already hashed over in another topic

Sent from my LM-V600 using Tapatalk

[majestyx]

46 minutes ago, arcadeshopper said:

No there is not.. already hashed over in another topic

Sent from my LM-V600 using Tapatalk
 

Can you please point me to this topic (or topics)? I've done a search to include finalgrom and supercart and get nothing that discusses in detail.

[+arcadeshopper]

Can you please point me to this topic (or topics)? I've done a search to include finalgrom and supercart and get nothing that discusses in detail.

Course now that I said that I can't find it either but I'll find it and get back to you sooner or later

Sent from my LM-V600 using Tapatalk

[+DuaneAL]

I think this is the same issue as when I tried to run Leather Goddesses of Phobos from dusk using the FG.  It requires a Supercart and AFAIK no one figured out how to do that.  That is in the ti99 Infocom games thread.

[ralphb]

Oh dear, oh dear, it has come to my attention (thanks, @HOME AUTOMATION) that the Mini Memory image fgminimem-2.zip with SAVE option published here doesn't work as intended.

 

So I proudly present fgminimem-3.zip , which has now been confirmed to work (thanks, @HOME AUTOMATION)!  To use it, you might have to revert the CPLD firmware contained in fgminimem-2 (I didn't test it); if so, use the latest version published on the homepage instead.

 

If you don't plan to use Minimem with SAVE feature, you don't have to change anything at all.

[Shift838]

On 9/4/2020 at 2:35 PM, majestyx said:

This relates to Insane Multitasker's topic on the Infocom interpreter.

 

Is there an easy way to get The FinalGROM to act like a Supercart? I tried hex editing the E/A cart by placing placing R in the 4th byte for the first try (enable RAM), then X for the second try (enable both RAM and GRAM). Same result - the E/A cart loads, choose option 5, enter DSK1.SAMPLER1A . It starts to load, then dumps me back to the FG99 DEV menu, but the menu is not functional. In fact, if I press any keys on the keyboard, it beeps and eventually gives a long BEEEEEEEEP until I turn the system off due to it being locked up.

 

So if there is a way to either create a Supercart image or get the E/A cart image to act like one, please let us know. Thanks~!

I was thinking about the same thing to see if we could get other supercart programs to work with the FG99. 

 

If you are looking to get these to work within FG99.  I emailed back and forth on this topic with Ralph and here is what he had to say based on the supercarts referenced on mainbyte (which I have)

 

http://www.mainbyte.com/ti99/supercart/supercart.html

http://www.mainbyte.com/ti99/supercart/supercart_4bank.html

 

"The carts linked above feature not only RAM, but battery-backed RAM, somewhat like the Minimem cart.  If you turn on RAM in the FinalGROM, it is still not battery-backed.  Thus, for the Minimem, I created a patched version where you could save the contents manually to SD card, so that they are not lost.

 

But the FinalGROM RAM mode also adds RAM to the upper half-banks of each bank only, i.e., addresses >7000 to >7FFF for each bank.  If I understood correctly, the Supercarts are all RAM, which differs from the FinalGROM.

 

That means you sadly cannot use the FinalGROM as a Supercart."

[+9640News]

16 hours ago, Shift838 said:

But the FinalGROM RAM mode also adds RAM to the upper half-banks of each bank only, i.e., addresses >7000 to >7FFF for each bank.  If I understood correctly, the Supercarts are all RAM, which differs from the FinalGROM.

 

That means you sadly cannot use the FinalGROM as a Supercart."

That is what I gather as well.  I was wanting to use the FinalGrom as a SuperCart as well as I needed RAM from >6000 to >7FFF as a program had grown too large.  Unfortunately, only >7000 to >7FFF is available.

 

What I don't know is if that is a hardware limitation from the design, or if the FinalGrom can be reprogrammed to open up the lower 4K.

 

Beery

 

[HOME AUTOMATION]

I think the big issue here is ...how to control the page switching, for larger than 8k supercarts.

Edited September 11, 2020 by HOME AUTOMATION

[Asmusr]

34 minutes ago, HOME AUTOMATION said:

I think the big issue here is ...how to control the page switching, for larger than 8k supercarts.

Using the imaginary switches, of course.

[wierd_w]

Use a small GROM image, (say, E/A as GROM), and use "Write on GROM" as the signal.  Would allow you to catch an 8 bit value as the page to switch to.  I even made a silly thread about the idea.

 

The requirement for such a supercart would be a GROM image, and then a RAM image that is some multiple of 8k, and a new byte designator in the reserved byte of the header. Maybe "S".

 

Specifically, the "Switch page!" signal, would be putting Grom Select high, combined with M and MO being forced low.  (The same combination that already gets trapped by the finalgrom when it is emulating GRAM, to know when it is being written to.)  In this case, since the GROM image is read only, instead of overwriting the GROM at the stack address held in the emulated GROM, it would trigger the page switch. The data written would be assumed to be the page number to switch to. This would switch out the whole 8k cartridge space to the page designated by the byte written.

 

 

Edited September 11, 2020 by wierd_w

[HOME AUTOMATION]

Sounds workable, However, I think some multi-bank Supercarts already employ CRU switching... not too sure if there's a way to detect that w/o some hardware in that CRU base, though if you could, perhaps a translation could be made, allowing compatibility with preexisting software!

[wierd_w]

8 minutes ago, HOME AUTOMATION said:

Sounds workable, However, I think some multi-bank Supercarts already employ CRU switching... not too sure if there's a way to detect that w/o some hardware in that CRU base, though if you could, perhaps a translation could be made, allowing compatibility with preexisting software!

Perhaps a trap routine set in the TIPI?

[HOME AUTOMATION]

I don't think TIPI has access to any CRU bits either(other than the dipswitches). I couldn't remember what base Supercart might use for switching. I was thinking of Superspace II, just found it in an older thread...

 

 

 

[+arcadeshopper]

Perhaps a trap routine set in the TIPI?

Tipi doesn't do anything like that

Sent from my LM-V600 using Tapatalk

[wierd_w]

No no, I mean, since it is sitting on the sidecar, and is an intelligent device, it could be given a program to DO that.  Not that it DOES do that.

[+jedimatt42]

Many era-similar systems use the same simple memory mapped mapper latch for bank switching a small address space. The difference is that all the ones I've seen are smart enough to put that mechanism as the last address of the bank, instead of the first. By being the last.. it isn't in the way of platform headers for ROMs etc... 

 

Just map an 8 bit latch to 7FFF, or a 16 bit latch to 7FFE-7FFF, and keep it simple... Yes, that means your banks aren't 8k, they are 8k - 1 byte. But when writing code that runs from bank switched memory, this is not an actual issue. For data streams, it is a bit more of an issue, but your writing custom code to copy in or out of them... so it is easy enough to navigate around.

 

Bam, tons of memory... 

[jrhodes]

Does anyone have .pld file of the CPLD firmware that does not have the minimemory save patch applied?

I purchased my finalgrom99 from ebay, it came with AVR v1.3 installed already, but i was unsure about whether the builder of the unit had also installed the minimemory save patch.

Having said that, i have installed the newest minimemory .BIN's and can confirm they work... but i am still unsure if my finalgrom99 has the save patch or not (it does not bump up the version number, so i am unsure).

 

If anyone has the original CPLD firmware, i would like to install that just to make sure.

Edited September 12, 2020 by jrhodes

[HOME AUTOMATION]

https://endlos99.github.io/finalgrom99/