FlashROM99 vs FinalGROM99

[cbmeeks]

Forgive my ignorance. I've only been able to browse on my phone for the last couple of days and it's hard to research this stuff with my old eyes.

 

Anyway....I have the FlashROM99 and love it. Then I discover there is a new FinalGROM99 that appears to be similar.

 

I never really understood what GROM is on the TI.

 

So, what's the difference? Should I upgrade? I mostly play games but want to start developing on the TI.

 

Thanks.

[+arcadeshopper]

Read the pinned post for more info on grom.

 

The flashgrom99 has more memory space for larger images and supports grom. And it supports subdirectories for multiple groups of programs. It's the next step from Flashrom99. It also is the same board size as an original Ti cartridge board.

 

Sent from my LG-H830 using Tapatalk

[+arcadeshopper]

pinned post: http://atariage.com/forums/topic/267055-new-to-the-group-ti-994a-hardware-and-software-resources/

[cbmeeks]

Awesome. Thanks for the info.

 

So, if I bought this, would I need my 32K RAM expansion from JediMatt (that I also own)?

 

I would hate for something like this to hurt his sales.

[+arcadeshopper]

Sure for less than before but still for the homebrew stuff

 

Sent from my LG-H830 using Tapatalk

[blackbox]

Awesome. Thanks for the info.

 

So, if I bought this, would I need my 32K RAM expansion from JediMatt (that I also own)?

 

I would hate for something like this to hurt his sales.

 

With FG99 the intent is that you use the module code with all its original requirements. TI sold TI Logo, Editor Assembler and USCD Pascal as requiring 32k ram and that will still apply.

 

Also some images of unreleased modules still require 32k ram to run- these are in the "32k" section of the big FinalGROM99 zip file on WHTECH.

 

And Extended Basic has additional capabilities with 32k ram.

 

So 32k ram is not entirely without merit.

 

A few mostly newer programs written for specific third party hardware may experience problems when a 32k ram is attached so be prepared to unplug the 32k from time to time.

 

Stephen

[Asmusr]

Cartridge RAM is using another address range than expansion RAM. One cannot replace the other.

[cbmeeks]

So you guys are saying that TI released some cartridges (modules) that contained RAM/ROM on the cartridge itself and that RAM/ROM was in a different address space than the 32K RAM side expansion?

 

So they compliment each other rather than compete?

 

So how would the address space work with all the bank switching in the cartridge space? That wouldn't conflict with the side expansion right?

 

How much contiguous memory would there be with the FG99 and the 32k side expansion?

 

Thanks

[Asmusr]

So you guys are saying that TI released some cartridges (modules) that contained RAM/ROM on the cartridge itself and that RAM/ROM was in a different address space than the 32K RAM side expansion?

 

So they compliment each other rather than compete?

 

So how would the address space work with all the bank switching in the cartridge space? That wouldn't conflict with the side expansion right?

 

How much contiguous memory would there be with the FG99 and the 32k side expansion?

 

Thanks

 

The 32K is in address space >2000->3FFF and >A000->FFFF. Cartridge space (whether it's ROM or ROM) is in >6000->7FFF.

 

In RAM mode the FG99 can page in RAM at >7000->7FFF. But note that the FG99 is currently for all existing cartridges except the Mini Memory and a demo cart using it's RAM to simulate ROM. You don't get more RAM by using a FG99 unless you use cartridges that support it.

[FDOS]

After reading the final doc on the FG99, it's bit of a disappointment to me, as it is not a replacement for my MG 80K GramKraker. Most all of my software development requires alternate TIOS (G0) and TI Basic (G1&2). I use Tony Knerr's HSGPL GROM 0, and Grom's 1&2 enhancements by Rich Gilbertson with fixes to the EA CALLs for Basic (allows use of these CALLs from BASIC programs running in GRAMs 3 - 7) by Tursi.

[blackbox]

So you guys are saying that TI released some cartridges (modules) that contained RAM/ROM on the cartridge itself and that RAM/ROM was in a different address space than the 32K RAM side expansion?

 

So they compliment each other rather than compete?

 

So how would the address space work with all the bank switching in the cartridge space? That wouldn't conflict with the side expansion right?

 

How much contiguous memory would there be with the FG99 and the 32k side expansion?

 

Thanks

The TI-99/4a is unlike any other computer in its memory usage. Not too straightforward. Memory mapping to some extent will depend upon what module you have plugged in, whether you have a disk system, and lots of other variables.

 

At the risk of overwhelming you - you don't really need to know all this for most purposes-

 

There is CPU RAM/ROM space and there is VDP ram/rom space- entirely different areas. We also have GROM.

 

Mapping is to an extent dynamic. On its own the Console has mostly ROM with a very tiny amount of CPU ram and a specialist VDP ram. The three types of memory are differently used, however note that the 32k ram, module ROM and Console ROM site in one mapped area. A module could contain RAM within this map, and a module could use bank switching.

 

Sometimes memory expansion peripherals could have more RAM than 32k by being bank switched- but the use of the extra memory was then limited by whatever software was written for it- if any was.

 

VDP ram is NOT directly addressed by the CPU, it holds screen and graphic information and BASIC programs. It is used by the Visual Display Processor.

 

CPU addressable ram and rom usage can be found at

http://atariage.com/forums/blog/628/entry-12631-ti-994a-memory-map/

 

Note that the 32k expansion ram is not contiguous but split into two sections (high and low) of 24k and 8k.

 

The cartridge ROM memory is at >6000->7FFF and is extended by bank switching (usual maximum used is 12k).

 

Then we have GROM - this is where the FG99 comes in. Modules usually contain GROM, using 6k of 8k chips. The contents of GROM are read using CPU >9800-9802 and >9C00-9C02. Most consoles worked with modules with no GROM but Vn 2.2 consoles required a GROM chip in the module (purely to reduce third party modules)..

 

A GROM has... a multiplexed address and data port, which means you must tell the GROM which address you want to access and then reach data in there. The GROM has an internal counter that is automatically incremented each time you access data, so that you don't need to re-enter the address each time. The standard TI-GROM size is >1800 bytes, which means any address can be expressed as a 13-bit number. The remaining 3-bits are used as GROM identifier: only the GROM with a matching internal ID will respond to such an address.

 

The FG99 has an emulation of GROM chips- that is, it uses standard RAM which is then processed by a specialist logic array which to the console appears to be TI GROM.

 

They really tried to make this a complex machine.

 

Stephen

[cbmeeks]

Holy crap Batman! That is complicated. The TI was my first computer and I will always be fond of it but that is complex. I knew some of it. Like the VDP because I've been studying the TMS9918 for a long time (in relations to Coleco).

 

I'm going to have to wrap my head around all of this. After I received my TI as a kid, I then moved on to the C64 and became pretty good at 6502 assembly. But I'd love to do some TI development. Anyway, lots to learn.

 

BTW, I cannot get used to > for hexadecimal addresses when the world uses $. Lol.

[ralphb]

After reading the final doc on the FG99, it's bit of a disappointment to me, as it is not a replacement for my MG 80K GramKraker. Most all of my software development requires alternate TIOS (G0) and TI Basic (G1&2). I use Tony Knerr's HSGPL GROM 0, and Grom's 1&2 enhancements by Rich Gilbertson with fixes to the EA CALLs for Basic (allows use of these CALLs from BASIC programs running in GRAMs 3 - 7) by Tursi.

 

I tried supporting GROMs 0-2 for a GROM-less machine, but in the end the FG99 wouldn't start up fast enough before the TI would crash.

 

I then shifted to using the FG99's GROMs 0-2 with a normal console, but (a) I didn't like the idea of overriding the built-in GROMs, and (b) having a GROM console only to override the GROMs seemed kind of pointless to me.

 

System GROMs are simply out of scope (for now, anyway).

[FDOS]

I tried supporting GROMs 0-2 for a GROM-less machine, but in the end the FG99 wouldn't start up fast enough before the TI would crash.

 

I then shifted to using the FG99's GROMs 0-2 with a normal console, but (a) I didn't like the idea of overriding the built-in GROMs, and (b) having a GROM console only to override the GROMs seemed kind of pointless to me.

 

System GROMs are simply out of scope (for now, anyway).

I understand the difficulties, but all my TI development work (except for X4th99) depends on having an enhanced TI Basic with the EA TI Basic Calls added in the extra 4K of space that can be provided by the 8K GROM/GRAM externally to the TI Console. Early on I removed the 6K GROM chips to avoid any conflict with the GK cart. Later I found out that it was not necessary as the GK "out shouted" the TI GROM. Maybe there could be away to replace all 3 TI Console GROMS with and easy plug in 24K device to emulate the TI OS and TI Basic or other alternative versions? I stay away from doing hardware mods any more due to fingers not working as well as they once did, except for installing such items; like, F18A and USB adapters in my TI Consoles.

 

Bill R Sullivan

[ralphb]

Maybe there could be away to replace all 3 TI Console GROMS with and easy plug in 24K device to emulate the TI OS and TI Basic or other alternative versions?

 

I think it's possible to program the FG99 so that it can emulate GROMs 0-2 on a GROM-less system. For example, the FG99 could pull GR low right at the start and then do proper initialization afterwards. That way the TI 99 will be held as long as the FG99 isn't ready yet.

 

But this is something to try in fall, when hardware season starts. Right now I'm busy with xdt99.

[FDOS]

I think it's possible to program the FG99 so that it can emulate GROMs 0-2 on a GROM-less system. For example, the FG99 could pull GR low right at the start and then do proper initialization afterwards. That way the TI 99 will be held as long as the FG99 isn't ready yet.

 

But this is something to try in fall, when hardware season starts. Right now I'm busy with xdt99.

Thanks, please keep me posted on this solutions. I will, however, go ahead and purchase one FG99 at this time.

[Airshack]

On 8/11/2017 at 11:11 AM, cbmeeks said:

BTW, I cannot get used to > for hexadecimal addresses when the world uses $. Lol.

$ = USD

> = Hex

[cbmeeks]

When I look at old programming books from the early 80's (which was my primary source of education back then), they all used $ for Hex.  At least the ones I saw.

 

I guess it's just what you get used to.

 

 

[HOME AUTOMATION]

...and I thought a T on top of an S meant "STRING" $, hmm, Doesn't look the same. (Where's the TI font on this FORUM anyway!)

[PeteE]

At least the hex prefix isn't two characters like in QBASIC: &H

[GDMike]

In forth you can just say Hex and all values are considered hex. If you say decimal then all values are considered dec. Also $ is used in forth for hex values if needed.  

The cent mark is NOT used to determine decimal numbers. Bhwahaha

Edited August 14, 2019 by GDMike