Talking about GROM

[+OLD CS1]

The talk about GROMs in the Bricks thread got me to thinking, but I did not think it belonged there. Hence, a new thread.

 

As I understand it, I could take GROM1 and GROM2 out of the console and upon starting up the menu will show "Insert module." I should also be able to put two GROMs from game modules into the console to replace the BASIC GROMs and both games should show up.

 

Lastly, I though I could make a TI BASIC module by taking GROMs 1 and 2 and putting them into a GROM module. But, does GROM1 expect GROM2 to be at a certain address or port, since GROM2 is headerless and essentially a continuation of GROM1?

[RXB]

The talk about GROMs in the Bricks thread got me to thinking, but I did not think it belonged there. Hence, a new thread.

 

As I understand it, I could take GROM1 and GROM2 out of the console and upon starting up the menu will show "Insert module." I should also be able to put two GROMs from game modules into the console to replace the BASIC GROMs and both games should show up.

 

Lastly, I though I could make a TI BASIC module by taking GROMs 1 and 2 and putting them into a GROM module. But, does GROM1 expect GROM2 to be at a certain address or port, since GROM2 is headerless and essentially a continuation of GROM1?

 

 

Not really any GPL programmer with source code can move TI Basic to somewhere else. Not hard to do, but there are some hard coded routines that would not work anymore as the address of these would be changed.

 

I do not see many problems in the Source code of Basic being moved. >2417 in GROM Execute a Basic Program from GROM could even be installed into the same module so you get some Basic programs on power up of Basic.

 

Those game modules you want to put there have to have a address of >2000 - >3FFF and >4000 - >5FFF and I know of zero Games that reside at that address. You would have to again use GPL to move them.

Edited July 26, 2011 by RXB

[+OLD CS1]

Bummer. Forget TI BASIC out of the console and games in the console (without hardware mods,) but can multiple game GROMs be combined into a single module?

 

In essence, code in GROMs do expect to live at certain addresses, and are therefore not the ultimate in relocatable programs, correct?

[RXB]

Bummer. Forget TI BASIC out of the console and games in the console (without hardware mods,) but can multiple game GROMs be combined into a single module?

 

In essence, code in GROMs do expect to live at certain addresses, and are therefore not the ultimate in relocatable programs, correct?

 

Yea on my TI PGRAM I have many games in the same Page of GRAM. Zero Zap was moved to >E000 so I could add it to some other modules that all 5 banks have a game in them.

 

5 games was the most I ever got into on cart, >6000 ROM had a game and 4 GRAM games all in one Page of GRAM.

 

I recently moved all the Editor Assembler Assembly Support into the Basic GROMs so would not be hard to move all that into a single module with a EA cart.

[Tursi]

I think there is some confusion here. If I am repeating known information, please ignore me.

 

All GROM sockets, whether on the motherboard or in a cartridge, are electrically identical. This means you can take any GROM and insert it in any position, and it will work correctly. You can even run GROM0 from a cartridge, if you want. This feature is how external GRAM devices are able to override the internal GROMs.

 

In a standard ROM or RAM arrangement, you usually have limited size memory chips, and external logic to decode which chip you want to access at any given address. In this scheme, which memory socket you use matters, because external hardware has mapped each socket to a particular address in memory.

 

GROMs don't have an address bus, however, they decode the address internally. Every GROM in the system tracks the current GROM address internally, for every single GROM operation. However, they only output data when the address matches their internal, built-in memory range.

 

This means when you take out GROM1 for instance, internally GROM1 knows that it responds to the addresses >2000->3FFF. No matter where you put it on the GROM bus, this remains true, so you can happily mount it and GROM2 on a cartridge beside the Editor/Assembler GROM, and it will all function happily.

 

However, cartridge GROMs respond starting at >6000. So you can't put two cartridge GROMs on the standard GROM bus and have it work, because when the address reaches >6000, they will both respond, causing corrupt data (at best - at worst they may damage each other. But this is not likely as they are weak drivers). To make this work, you again need external circuitry, to put them on different GROM bases so they respond individually.

 

You /can/ put cartridge GROMs in the sockets reserved for GROMs 1 and 2 in the console, and it WILL work. However, for the same reason I just described, they will conflict with any cartridge GROM in the cartridge port, unless you also add a way to disable them.

[Tursi]

I should add that Rich is talking about modifying the actual code on the GROMs - which is necessary if you want to run it at a different address. This is not the same as taking physical GROMs and moving them around.

[RXB]

I should add that Rich is talking about modifying the actual code on the GROMs - which is necessary if you want to run it at a different address. This is not the same as taking physical GROMs and moving them around.

 

Tursi, could he not move the code and put that in the chips?

 

I thought that is what he wanted to do.

Edited July 26, 2011 by RXB

[RXB]

I think there is some confusion here. If I am repeating known information, please ignore me.

 

All GROM sockets, whether on the motherboard or in a cartridge, are electrically identical. This means you can take any GROM and insert it in any position, and it will work correctly. You can even run GROM0 from a cartridge, if you want. This feature is how external GRAM devices are able to override the internal GROMs.

 

In a standard ROM or RAM arrangement, you usually have limited size memory chips, and external logic to decode which chip you want to access at any given address. In this scheme, which memory socket you use matters, because external hardware has mapped each socket to a particular address in memory.

 

GROMs don't have an address bus, however, they decode the address internally. Every GROM in the system tracks the current GROM address internally, for every single GROM operation. However, they only output data when the address matches their internal, built-in memory range.

 

This means when you take out GROM1 for instance, internally GROM1 knows that it responds to the addresses >2000->3FFF. No matter where you put it on the GROM bus, this remains true, so you can happily mount it and GROM2 on a cartridge beside the Editor/Assembler GROM, and it will all function happily.

 

However, cartridge GROMs respond starting at >6000. So you can't put two cartridge GROMs on the standard GROM bus and have it work, because when the address reaches >6000, they will both respond, causing corrupt data (at best - at worst they may damage each other. But this is not likely as they are weak drivers). To make this work, you again need external circuitry, to put them on different GROM bases so they respond individually.

 

You /can/ put cartridge GROMs in the sockets reserved for GROMs 1 and 2 in the console, and it WILL work. However, for the same reason I just described, they will conflict with any cartridge GROM in the cartridge port, unless you also add a way to disable them.

 

Well there is ussually some code space so my solution for duplicate cartidges would be to change the header slightly so you would get 2 TI BASIC or 2 EA carts on the menu and change the string in the modified one so you can tell which one is which.

 

I screwed around with EA and put it in every slot. GRAM 1,2,3,4,5,6,7 and it worked. Do you think you guys need a TI BASIC that resides in every 4K slot?

 

You know 1&2, 3&4, 4&5, 5&6, 6&7 as I could just make the Source code and you put in the GROM >#000 and use GPL Assembler.

Edited July 27, 2011 by RXB

[+OLD CS1]

Rich,

 

I was actually just talking about physical swaps. The idea of modifying GROMs is interesting, but not physically practical at this juncture since we cannot make new GROMs -- or at least, not without unreasonable emulation hardware.

 

I appreciate the responses. They have all been enlightening, and I might have missed the answers to my questions in other threads.

[Tursi]

The idea of modifying GROMs is interesting, but not physically practical at this juncture since we cannot make new GROMs -- or at least, not without unreasonable emulation hardware.

 

Do you mean that my AVR solution is unreasonable, or the older discrete logic approach? If mine, what could I do to improve it? Except for the pinout being different I thought it was a nice compromise, and you can get the smaller AVRs pretty cheaply.

[+OLD CS1]

The idea of modifying GROMs is interesting, but not physically practical at this juncture since we cannot make new GROMs -- or at least, not without unreasonable emulation hardware.

 

Do you mean that my AVR solution is unreasonable, or the older discrete logic approach? If mine, what could I do to improve it? Except for the pinout being different I thought it was a nice compromise, and you can get the smaller AVRs pretty cheaply.

 

I probably missed your solution. All I recall seeing are the discrete stuff, gobs of TTL and blah to emulate GROM, and then not very stably. The best being the GRAM stuff already out of production... nothing like a weekend hobby for the electronically doofused.

 

Personally, I am more inclined to approach expanding the physical system via ROM and bank switching -- damn the v2.2 consoles. After working with various memory-mapped and banked designs using standard ROM and RAM, GROM just seems insulting to hobbyists who are not interested in cracking a code but just having things that work without jumping through a series of hoops. In competing computers of the era one could easily design expansions using the existing expansion ports. In particular, the Commodore 64 cartridge port has access to the entire CPU bus.

 

The cartridge port on the TI has a limited address space allocated to it. The side port has a greater expansion capability, as one would expect, but I do not see it as practical for heavy cart swapping. Though, I suppose one could create a cartridge port expansion for the side port which still allowed for permanently attached accessories. Making it compatible with existing modules would be redundant, and defining a new module interface would seem academic at best as it would need to have a standardized following. Just throwing brain barf around, here.

 

If I read correctly, every GROM is "on" during addressing, and each analyzes the address and compares it to its base, responding if it should. This seems to be a lot more power-hungry than the *CS (chip-select) method used in regular memory-mapped architecture used for 6500/6800/68k/etc-based systems, where the chip sleeps until its CS line is engaged by some kind of address decode.

 

And this is where I am trying to wrap my head around CRU addressing. Perhaps my experiences with memory-mapped stuff has clouded my mind. Between various other work-related projects over the next couple of weeks before classes being again, I will hang out in the TI Tech Pages.

[Tursi]

I probably missed your solution. All I recall seeing are the discrete stuff, gobs of TTL and blah to emulate GROM, and then not very stably. The best being the GRAM stuff already out of production... nothing like a weekend hobby for the electronically doofused.

 

Yes, I released it better than a year ago, but it didn't get much attention. It's being used (in large 120k form) in the new Jon/Jim bank switch cartridge, and it's the core technology behind my MPD project. Once programmed, it's a single-chip solution running on an AVR, and should port to any other 5v tolerant microcontroller.

 

In competing computers of the era one could easily design expansions using the existing expansion ports. In particular, the Commodore 64 cartridge port has access to the entire CPU bus.

 

In fairness, so does the side port of the TI-99/4A. Though Commodore published the pinout and specifications in the user manual, while TI made it all proprietary and confidential.

 

The cartridge port on the TI has a limited address space allocated to it. The side port has a greater expansion capability, as one would expect, but I do not see it as practical for heavy cart swapping. Though, I suppose one could create a cartridge port expansion for the side port which still allowed for permanently attached accessories. Making it compatible with existing modules would be redundant, and defining a new module interface would seem academic at best as it would need to have a standardized following. Just throwing brain barf around, here.

 

That's okay, we all do a lot of that! hehe. Keeps it fun.

 

If I read correctly, every GROM is "on" during addressing, and each analyzes the address and compares it to its base, responding if it should. This seems to be a lot more power-hungry than the *CS (chip-select) method used in regular memory-mapped architecture used for 6500/6800/68k/etc-based systems, where the chip sleeps until its CS line is engaged by some kind of address decode.

 

Probably. But at the same time it's a smaller chip and has less circuitry on the die since it doesn't have to manage a parallel array. But I've no idea what the current figures look like. Useful or not, it's a part of the console, so it has some value. It's also ridiculously easy to jump onto that bus without confusing any other hardware.

 

And this is where I am trying to wrap my head around CRU addressing. Perhaps my experiences with memory-mapped stuff has clouded my mind. Between various other work-related projects over the next couple of weeks before classes being again, I will hang out in the TI Tech Pages.

 

At the lowest level, CRU still an addressable memory scheme. It has an address bus, and a single bit data bus. It's seriously that basic (and that dumb. )