Can the FinalGROM 99 and 32K Sidecar be used together?

[cbmeeks]

I have (and love) the 32K sidecar for my '99. I also have the FlashROM 99. I'm wanting to buy the FinalGROM 99 and read that it also has RAM expansion. So my question is, will I still need the 32K Sidecar if I get the FinalGROM 99?

 

If I use them both, do I get the 512K from FG99 and an additional 32K from the Sidecar?

 

I'm still trying to understand how the TI maps all of this memory (GROM still confuses me...lol).

 

Thanks!

 

[Opry99er]

The FG99 and 32k memory expansion are a lovely pair.

 

There are many cartridges that require the 32k memory expansion, and your sidecar will do perfect in that task.

 

The FG99 is basically the same as the FR99, except it emulates GROM which was the proprietary "Graphics Read Only Memory" TI used in their 1st party cartridges.

 

With the FG99, you can load just about every cartridge ever produced. The cart itself doesn't add any CPU RAM, so that's why the sidecar 32k is important to have in your setup.

[Omega-TI]

Yes. Many of the programs require memory expansion.

[cbmeeks]

Ah, then I guess I'm confused on the 512K of RAM on the FG99. What is that for?

 

Thanks!

[+arcadeshopper]

Ah, then I guess I'm confused on the 512K of RAM on the FG99. What is that for?

 

Thanks!

 

it's for cartridge emulation.. not system ram

Greg

[cbmeeks]

OK, maybe I'm a thousand miles off on this...but please let me know if I have this right.

 

The FlashROM 99 (FR99) could only work with binary files and not true "cartridges". Even though it plugs into the cartridge port. These binary files are simply loaded into the stock 16K of an unmodified '99 and/or they could be loaded into the 32K Sidecar RAM as well.

 

Real cartridges you bought back in the day contained some ROM and/or GROM. The ROM on these carts usually stored the actual machine code the game/app ran. The CPU ran this code directly. The GROM of the cartridge contained graphics and, IIRC, some proprietary graphics language (can't remember what it's called).

 

So, getting back to the FinalGROM 99 (FG99), the 512K RAM chip on that card is used to emulate ROM and/or GROM depending on what cartridge you loaded from SD.

 

Is that correct?

 

Furthermore, I've read about GRAM and RAM being on some carts (can't remember which) that the CPU could write to but not directly like RAM. I believe it had to go through the VDP?? If so, does the FG99 support that as well?

 

Sorry for the detailed questions. I'm really trying to understand how the TI works at a hardware level. I want to start asm programming for it and building some cards.

 

Oh, and I just purchased a FG99 so hopefully that will arrive sometime soon. :-)

 

Thanks!

[Asmusr]

The FR99 and FG99 are doing essentially the same thing when it comes to emulate ROM cartridges. The difference is that the FR99 can emulate ROMs up to 32K while the FG99 can emulate ROMs up to 1024K.

 

GROM/GRAM is accessed in a similar way as VDP RAM through a couple of memory addresses, but the memory addresses are different and it's two independent systems.

[PeteE]

Sorry for the detailed questions. I'm really trying to understand how the TI works at a hardware level. I want to start asm programming for it and building some cards.

Glad to hear you want to learn at the hardware level and learn assembly programming.

 

First read about the TI 99/4a architecture. Pay attention to how the 16K VDP memory is connected to the video chip, not the CPU. The 32K memory expansion is 8K at addresses >2000 to >3FFF and 24K at addresses >A000 to >FFFF. The cartridge memory space is 8K at address >6000 to >7FFF.

 

The FlashROM99 supports cartridges up to 4 banks of 8K ROM (32K max cart size)

 

The FinalGROM99 supports cartridge up to 128 banks of 8K ROM/RAM (1MB max cart size) The RAM mode uses the upper half of the cartridge address space: >7000 to >7FFF. Writing to the lower address >6000 to >6FFF is how to switch banks.

[HOME AUTOMATION]

Easy to forget... always messes me up when I'm tired.

Writing to even addresses between >6000 - >60FE Bank switch >6000 - 6FFF(512K CPU ROM).

Writing to even addresses between >6800 - >68FE Bank switch >7000 - 7FFF(512K CPU RAM).

This is on the CPU ADDRESS BUS, ...same as the 32K expansion at >2000 - >3FFF, >A000 - >FFFF.

Both run at the same apparent speed.

512K + 32K = 544K CPU RAM... Directly accessible(w/paging)!

I for one am a satisfied customer.

 

 

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

[HOME AUTOMATION]

The probable reason(s) you are getting so many seemingly mixed messages here is because of the many MODES the FG99 has... without detailing and comparing each one... a new user must work around certain assumptions. Also some developers may be using emu vs. hardware.

I am using >52 in byte 4(>03) of the xxxxxxxG.BIN image file.
I am using >00 in byte 4(>03) of the xxxxxxxC.BIN image file.

The size of an image file determines how many banks are available when that image is loaded.

For the xxxxxxxG.BIN image file :

>0000 thru >1FFF are synonymous to >page 1 >6000 - >6FFF.
>2000 thru >3FFF are synonymous to >page 2 >6000 - >6FFF.
>4000 thru >5FFF are synonymous to >page 3 >6000 - >6FFF.
...up to.. >7FFFF(524287).

For the xxxxxxxC.BIN image file :

>0000 thru >1FFF are synonymous to >page 1 >7000 - >7FFF.
>2000 thru >3FFF are synonymous to >page 2 >7000 - >7FFF.
>4000 thru >5FFF are synonymous to >page 3 >7000 - >7FFF.
...up to.. >7FFFF(524287).

Total >100000(1048576).

 

The RAM mode is esp. handy because... w/o having to make such heavy use of PAD and structured memory usage like stacks. Now assembled .obj code can run from directly from ram in cart. Paging routines are required for images longer than 4096.

[kl99]

Hi cbmeeks,

 

the cartridge slot is hardware wired to the Cpu memory location >6000 to >7FFF (8192 bytes).

So a cartridge can either provide 8K Rom or 8K Ram to this memory location. Or nothing. Then that memory area is unused.

 

Most third party cartridges did just provide 8K Rom (or 16K via bank switching) and that was it, the stored software is pure Tms9900 machine code.

If the Rom contains a certain header, the program name will show up in the Master selection screen after the Title screen.

 

For the TI-99 there is in addition another memory type, the Grom. It is not directly accessable by the Cpu. Therefore it is memory mapped. A certain fixed address (port) in Cpu Ram is used to see the value of the current active address of the Grom. There is another fixed address (port) to set the active Grom address. Each Grom chip contains 6K of memory, even though the Grom memory map occupies 8K for each. There are a maximum of 8 Grom chips active, the first 3 being installed in your mainboard, and up to 5 more coming via the cartridge slot. Then TI even have a mechanism for up to 16 Grom Banks.

 

A Grom can store data or Gpl assembled code. It can store Tms9900 machine code, however the Cpu can not process a program directly from Grom, because it is memory mapped.

If a Grom contains a certain header, the program name will show up in the Master selection screen.

 

Gpl assembled code is not the same as Tms9900 machine code! Gpl assembled code still needs to be interpreted, byte by byte. The interpreter for this sits partely in the TI-99 System rom [>0024 - >08FF], which is then finally Tms9900 machine code.

 

Any Tms9900 machine code needs to go to a Rom, any Gpl assembled code is best suited on a Grom. For general data you decide on your own.

 

Most cartridges, released by TI were written in Gpl and were a Grom only release.

When speed was critical, it was a combination of Rom (speed) and Grom (costs, size).

 

If you were a software company and wanted to release carts for TI-99, either you bought the full license, got access to the very restricted Gpl Documentation and software and were then able to order Groms to be produced by TI.

Or you wrote your software in pure Tms9900 machine code, which was fully documented and you burned your Eproms on your own. TI didn't see a penny then.

 

At one point TI only produced mainboards with an updated System Rom [v2.2] which removed the check for Rom headers when loading the Master selection screen. This means, a cartridge with only Roms will not show up on such a TI. This essentially locked out Atari games from being loaded.

 

Software companies started to use a cartridge schematic, where some controller made some of the Eproms appear as a Grom to the TI.

This then even allowed 8K Groms instead of the usual 6K.

 

Further to our luck, the v2.2 mainboards are not wide spread.

 

Enjoy!

[kl99]

The Tms9900 Cpu can address up to 64KB of memory.

 

Certain spots in the computer are hardware wired to certain addresses of the Cpu Memory.

This can not be changed, even if you would have 1 GB of memory available at one of the spots.

 

1. Bank #1 >0000 - >1FFF

 

This goes to two 4K Rom chips which define the System Rom and make the first 8K of memory.
In our case this is read only memory.

So not usable to store anything.

 

A bank switching project at this spot would still keep all the total memory within the Cpu Memory area of >0000 to >1FFF.

You can not move to other memory locations.

 

2. Bank #2 >2000 - >3FFF

 

Lower Expansion Memory. This is wired to the optional Memory Expansion that is going via Sidecar. It doesn't matter whether in a PEB or not.

If you have no memory expansion, you can not write here.

If you have a memory expansion, then 8K of its 32K go here.

This is meant to store user data/programs.

 

A bank switching project at this spot would still keep all the total memory within the Cpu Memory area of >2000 to >3FFF.

You can not move to other memory locations.

 

3. Bank #3 >4000 - >5FFF

 

This goes to the maximum of 8K of Rom chips of the active Device. The CRU chip is involved in setting active Devices and is similar like IRQ.

That memory is meant to define the DSR, the Device Service Routines.

In case of the Disk Controller it is the Routines to format, read, write,...

In case of the RS232 it is the routines to open, close, read, write from that device...

In most cases this is read only memory.

In case of the RS232 HDX and the Ramdisk we have Ram chips with batteries for updates.

Anyhow not meant for storing your data.

As soon as another device is active its DSR is now "blended" in that >4000 - >5FFF spot.

 

A bank switching project at this spot would still keep all the total memory within the Cpu Memory area of >4000 - >5FFF.

You can not move to other memory locations.

 

4. Bank #4 >6000 - >7FFF

 

This is connected to the cartridge port.

Some cartridges contain a Rom chip, some a Ram chip, many don't have anything.

Only when a Ram chip is connected to these address lines you can use this memory to store stuff.

 

A bank switching project at this spot would still keep all the total memory within the Cpu Memory area of >6000 - >7FFF.

You can not move to other memory locations.

 

5. Bank #5 >8000 - >9FFF

 

This is the most complicated one. The TI-99/4A comes with 2x 128 bytes Ram chips, making 256 bytes total Cpu Ram.

You can access it from >8300 to >83FF.

There are many not connected memory areas here, meaning unless you hardware modify the mainboard, you can not make use of those.

This is further the area where the memory mapping ports are: for Grom, Speech, Video Ram and Sound.

 

A bank switching project at this spot would still keep all the total memory within the Cpu Memory area of >8000 - >9FFF.

You can not move to other memory locations.

 

6. Bank #6 >A000 - >BFFF

7. Bank #7 >C000 - >DFFF

8. Bank #8 >E000 - >FFFF

 

The last 3 banks (24KB) can be adressed via the Sidecar bus and therefore are meant for the 32K memory expansion, again not relevant if in a PEB or not.

If you have no memory expansion, nothing can be written to here.

If you have a memory expansion, this is your 2nd data/programs spot.

 

A bank switching project at this spot would still keep all the total memory within the Cpu Memory area of >A000 - >FFFF.

You can not move to other memory locations.

[HOME AUTOMATION]

Because FG99's memory pages cannot "see each-other" 32K is a fast way to pass arguments between pages. VDP or GRAM(when paged alone) could also be used, but would be slower.

[+Lee Stewart]

The Tms9900 Cpu can address up to 64KB of memory.

 

Certain spots in the computer are hardware wired to certain addresses of the Cpu Memory.

This can not be changed, even if you would have 1 GB of memory available at one of the spots.

 

1. Bank #1 >0000 - >1FFF

.

.

.

8. Bank #8 >E000 - >FFFF

 

This is a very good explanation, Klaus, but I think the use of “bank” to label 8-KiB blocks of CPU memory space can be misleading vis-à-vis bank-switched space in isolated ROM, RAM, GROM, etc. I think the addresses are sufficient labels:

1. >0000 - >1FFF
 .
 .
 .
8. >E000 - >FFFF

...lee

[cbmeeks]

@Klaus

 

First of all, thanks so much for the very detailed explanation! That helped tremendously!

 

 

 

>> Each Grom chip contains 6K of memory, even though the Grom memory map occupies 8K for each.

 

 

What was the purpose of them being 6K? I assume they still were on some type of masked ROM chip from TI. Was the 6K limit artificial or hardware specific?

 

 

>> Most cartridges, released by TI were written in Gpl and were a Grom only release.

>> When speed was critical, it was a combination of Rom (speed) and Grom (costs, size).

 

I assume the GROM chips were cheaper to produce. In a world where bytes cost more money, companies could save money by using the cheaper (although slower) GROM. A game like Tic-tact-toe didn't need expensive ROMS for speed. Correct?

 

 

>> If you were a software company and wanted to release carts for TI-99, either you bought the full license, got access to the very restricted Gpl Documentation and software and were then able to order Groms to be >> produced by TI. Or you wrote your software in pure Tms9900 machine code, which was fully documented and you burned your Eproms on your own. TI didn't see a penny then.

 

I can see the advantage of GROM. With RAM/ROM space being super expensive (relatively speaking) in 1979, GROM was a way to map more space in that narrow 8 KiB window that ROM carts were restricted to. Sort of like another cartridge inside the main cartridge. However, the benefits really dwindle when you factor in that you can only access this window through a small hole for the address and data. And with TI making the GPL code expensive and obscure, they really put the nails in that coffin. This is the kind of crap large mainframe companies (IBM) do...but at a micro level. :-)

 

So now I wonder, in 2019 with all of the resources we have now, what is the need for GPL code in our titles? Seems like storing data in that area and just swapping it out is the thing to do.

 

 

 

>> At one point TI only produced mainboards with an updated System Rom [v2.2] which removed the check for Rom headers when loading the Master selection screen. This means, a cartridge with only Roms will not >> show up on such a TI. This essentially locked out Atari games from being loaded.

 

 

Wow. That is a dirty trick. LOL. So this means that only GPL games (which cost companies real money to license) would work in those machines. Shame on you TI.

 

Are those v2.2 machines the "QI" boards I've heard about?

 

 

 

>> Software companies started to use a cartridge schematic, where some controller made some of the Eproms appear as a Grom to the TI.

>> This then even allowed 8K Groms instead of the usual 6K.

 

 

By doing this, it now becomes possible to have huge amounts of banked out ROMS in that small "window" of GROM space? The TI and the cart thinks there is only 8K in ROM. But by using the port into GROM, you could switch out the GROM address and use traditional ROM for much more storage. Very clever. You would just need to copy the data from the GROM into somewhere accessible by the CPU. Would be convenient for holding things like tile maps and sprite data.

 

So, I assume this port into GROM's address bus is 8 bits. Does that mean there can be 256 pages of 8 KiB for a total 2 MiB?

 

 

 

Because FG99's memory pages cannot "see each-other" 32K is a fast way to pass arguments between pages. VDP or GRAM(when paged alone) could also be used, but would be slower.

 

 

This makes sense. Each page in the FG99's memory cannot directly access the other pages. So by placing data in the "global" 32K area, they can pass information to each other.

 

Thanks everyone for their explanations!

 

It's going to take me a few passes to get things down. I've spent most of my time learning the ins/outs of C64, Apple II and VIC-20. So this is quite a bit different than those worlds.

[HOME AUTOMATION]

This subject has a lot of similar figures... sometimes this even confuses me!

The probable reason(s) you are getting so many seemingly mixed messages here is because of the many MODES the FG99 has... without detailing and comparing each one... a new user must work around certain assumptions. Also some developers may be using cross assemblers or emu vs. hardware.

I am using >52 in byte 4(>03) of the samenamG.BIN image file.
I am using >00 in byte 4(>03) of the samenamC.BIN image file.

The size of an image file determines how many PAGES or GROMs are available when that image is loaded.

For the samenamG.BIN image file :

>0000 thru >1FFF are synonymous to >GROM 3 >6000 - >7FFF.
>2000 thru >3FFF are synonymous to >GROM 4 >8000 - >9FFF.
>4000 thru >5FFF are synonymous to >GROM 5 >A000 - >BFFF.
...up to... >9FFF(40959) ???

GROMs 0, 1, 2 being in the console.

There is no 6K limit.

 

For the samenamC.BIN image file :

>0000 thru >0FFF are synonymous to >page 1 >6000 - >6FFF.

>1000 thru >1FFF are synonymous to >page 1 >7000 - >7FFF.

>2000 thru >2FFF are synonymous to >page 2 >6000 - >6FFF.

>3000 thru >3FFF are synonymous to >page 2 >7000 - >7FFF.

>4000 thru >4FFF are synonymous to >page 3 >6000 - >6FFF.

>5000 thru >5FFF are synonymous to >page 3 >7000 - >7FFF.

...up to... >FFFFF(1048575).
The even numbered 4K blocks are ROM(>6000 - >6FFF).

The odd numbered 4K blocks are RAM(7000 - 7FFF).

 

The RAM mode is esp. handy because... w/o having to make such heavy use of PAD and structured memory usage like stacks. Now assembled .obj code can load and run directly from ram in the FG99 cartridge. Paging routines are required for images longer than 4096.

I had to make a few corrections in red above :dunce:

Whew!

Edited January 17, 2019 by HOME AUTOMATION