Grom Address wrapping

[Gazoo]

<sigh>

 

Is this topic discussion really worth it? Does it really add value?

 

For the most parts I would think so. GROM reconstruction, compatibility and emulation seems to be important to the TI.

 

It is valuable to at least me, one who has been involved in Grom emulation since the late 80's. A new idea recently surfaced as to what happens when the end of a Grom is reached (g>1FFF, g>3FFF, g>5FFF, g>7FFF, g>9FFF, g>BFFF, g>DFFF, and g>FFFF). It was always believed that the code execution would continue until recently. The idea was introduced that the code would start over at the beginning of the Grom. The discussion and examples provided so far indicate that it doesn't really matter as the exact scenario of code executing across boundaries would be an extreme rarity. Data Moves across Grom boundaries, however, are quite common and that function should not be suppressed by a new device since it is part of the normal function of the TI.

 

This is just a curiosity for me, as I (and probably others) would like to understand what really happens with Groms and Grom emulation. Groms are fascinating devices. Anyone not interested in the discussion doesn't have to read it or participate if they don't want to. It would be nice if the discussion could continue in a mature manner without anyone taking offense if their delicate ego is bruised, so how about we continue in that manner?

 

Gazoo

[Omega-TI]

[+Ksarul]

Another thought on this subject that Tursi touched on a while back: real GROMs have to wrap. All GROMs have an internal address counter that advances continuously as the GROM bus is polled by the system. Only the one being selected actually places information on the data bus--but all of them advance in lockstep. The fact that the counters advance in lockstep is what forces us to wrap instead of to advance, as to advance, the chip has to be at the first address, and the only way to get there is to wrap. This actually has some interesting implications--and it actually makes both camps 100% correct in their assumptions, as the behavior of the chips can be interpreted either way. Each GROM advances to the end of its counter and wraps, but the GROM selected by the external system doesn't wrap, it advances. The external system thus forces the appearance of a linear advance of the address, but each individual GROM is actually in a circular loop, advancing forward and looping to the beginning in lockstep with the other seven GROMs in a single GROM base. This behavior fits both sets of observations--and as Tursi noted, it matches his observations when testing individual GROM chips.

 

I'm all for civilized discussion--and this one, though it does get heated at times, is making me think, so I find it a stimulating discussion. I do think we need to make the thread title a little bit more peaceful though!

[Gazoo]

Another thought on this subject that Tursi touched on a while back: real GROMs have to wrap. All GROMs have an internal address counter that advances continuously as the GROM bus is polled by the system. Only the one being selected actually places information on the data bus--but all of them advance in lockstep. The fact that the counters advance in lockstep is what forces us to wrap instead of to advance, as to advance, the chip has to be at the first address, and the only way to get there is to wrap. This actually has some interesting implications--and it actually makes both camps 100% correct in their assumptions, as the behavior of the chips can be interpreted either way. Each GROM advances to the end of its counter and wraps, but the GROM selected by the external system doesn't wrap, it advances. The external system thus forces the appearance of a linear advance of the address, but each individual GROM is actually in a circular loop, advancing forward and looping to the beginning in lockstep with the other seven GROMs in a single GROM base. This behavior fits both sets of observations--and as Tursi noted, it matches his observations when testing individual GROM chips.

 

I'm all for civilized discussion--and this one, though it does get heated at times, is making me think, so I find it a stimulating discussion. I do think we need to make the thread title a little bit more peaceful though!

 

Per your wish, man of great wisdom.

 

Gazoo

[RXB]

 

 

It is valuable to at least me, one who has been involved in Grom emulation since the late 80's. A new idea recently surfaced as to what happens when the end of a Grom is reached (g>1FFF, g>3FFF, g>5FFF, g>7FFF, g>9FFF, g>BFFF, g>DFFF, and g>FFFF). It was always believed that the code execution would continue until recently. The idea was introduced that the code would start over at the beginning of the Grom. The discussion and examples provided so far indicate that it doesn't really matter as the exact scenario of code executing across boundaries would be an extreme rarity. Data Moves across Grom boundaries, however, are quite common and that function should not be suppressed by a new device since it is part of the normal function of the TI.

 

This is just a curiosity for me, as I (and probably others) would like to understand what really happens with Groms and Grom emulation. Groms are fascinating devices. Anyone not interested in the discussion doesn't have to read it or participate if they don't want to. It would be nice if the discussion could continue in a mature manner without anyone taking offense if their delicate ego is bruised, so how about we continue in that manner?

 

Gazoo

 

Gazoo is correct there is code in GPL written that does cross the >?FFF boundary mind you not more then a few of these programs exist and were written for GRAM.

 

As a GPL programmer I can see zero advantage for auto wrap back to the beginning of the same page of memory.

 

This would leave no allowance for any memory other then that single page of memory.

 

Can you imagine VDP doing this at >2000 and in order for you to cross that >1FFF to >2000 boundary you have to write special code to just do that?

[Gazoo]

Another thought on this subject that Tursi touched on a while back: real GROMs have to wrap. All GROMs have an internal address counter that advances continuously as the GROM bus is polled by the system. Only the one being selected actually places information on the data bus--but all of them advance in lockstep. The fact that the counters advance in lockstep is what forces us to wrap instead of to advance, as to advance, the chip has to be at the first address, and the only way to get there is to wrap. This actually has some interesting implications--and it actually makes both camps 100% correct in their assumptions, as the behavior of the chips can be interpreted either way. Each GROM advances to the end of its counter and wraps, but the GROM selected by the external system doesn't wrap, it advances. The external system thus forces the appearance of a linear advance of the address, but each individual GROM is actually in a circular loop, advancing forward and looping to the beginning in lockstep with the other seven GROMs in a single GROM base. This behavior fits both sets of observations--and as Tursi noted, it matches his observations when testing individual GROM chips.

 

I'm all for civilized discussion--and this one, though it does get heated at times, is making me think, so I find it a stimulating discussion. I do think we need to make the thread title a little bit more peaceful though!

 

After reading this post several times to digest it, I went back and looked at the GPL Interpreter code. It's true that the GPL Interpreter code forces the Grom address to increment at the end of a Grom into the next Grom. Therefore GPL code execution at the end of a Grom MUST continue into the next Grom. So the entire discussion of whether the Grom address wraps back to the beginning of a Grom is irrelevant (at least for me at this point), because code executing at g>9FFF is going to continue at g>A000 in all cases (as long as there's a Grom at g>A000, otherwise you'll probably get a lockup or reset). Therefore a Grom emulator can behave either way, wrap or not, and it has NO effect on the end result of Grom code execution.

 

My Grom Wrap Test Program (in another thread here) should prove this theory. The program is constructed by actually executing code across Grom boundaries. The header code is at the beginning of Grom 3 and sets up the VDP registers and character set so we can produce a message on the screen. The code then branches to address g>9FFE (the end of Grom 4) and executes the code >0720 which is 'fill screen with spaces'. If the Grom code execution continues at address g>A000 (the beginning of Grom 5), the code there displays the message 'Continues into next GROM'. If the Grom execution wraps back to adress g>8000 (the beginning of Grom 4), the code there displays the message 'Wraps around same GROM'. The result should ALWAYS be 'Continues into next GROM' whether the Grom Emulator presents a Grom with address wrapping or not, unless someone has altered the GPL Interpreter code.

 

Hopefully we're done with this at this point.

 

Gazoo

 

 

[Willsy]

Nice one. I'd day that puts the tin lid on it!

[marc.hull]

 

After reading this post several times to digest it, I went back and looked at the GPL Interpreter code. It's true that the GPL Interpreter code forces the Grom address to increment at the end of a Grom into the next Grom. Therefore GPL code execution at the end of a Grom MUST continue into the next Grom. So the entire discussion of whether the Grom address wraps back to the beginning of a Grom is irrelevant (at least for me at this point), because code executing at g>9FFF is going to continue at g>A000 in all cases (as long as there's a Grom at g>A000, otherwise you'll probably get a lockup or reset). Therefore a Grom emulator can behave either way, wrap or not, and it has NO effect on the end result of Grom code execution.

 

My Grom Wrap Test Program (in another thread here) should prove this theory. The program is constructed by actually executing code across Grom boundaries. The header code is at the beginning of Grom 3 and sets up the VDP registers and character set so we can produce a message on the screen. The code then branches to address g>9FFE (the end of Grom 4) and executes the code >0720 which is 'fill screen with spaces'. If the Grom code execution continues at address g>A000 (the beginning of Grom 5), the code there displays the message 'Continues into next GROM'. If the Grom execution wraps back to adress g>8000 (the beginning of Grom 4), the code there displays the message 'Wraps around same GROM'. The result should ALWAYS be 'Continues into next GROM' whether the Grom Emulator presents a Grom with address wrapping or not, unless someone has altered the GPL Interpreter code.

 

Hopefully we're done with this at this point.

 

Gazoo

 

 

I'll preface with I don't know GROM/GRAM from sicum....

 

What I think I now know is this (and please correct my mistakes.)

 

GROM is a ROM chip that has it's own address counter internally (a data sheet would be nice at this point.)

GROM is a 6K device but only because of die size or available IC PINS. Theoretically it could be as large a device as desired and free pins allow ?

 

I understand what Mike is saying about the address wrapping back to zero on a GROM chip. Makes sense that this would happen when the internal address counter maxes out.

 

Tony is putting forth that the system has an additional counter that acts like a *CE line which is used to select a particular GROM IC from a set. This counter advances when the address wraps ? If so then when a GROM maxes out it will roll over to 0 but the IC counter will advance ?

 

Now some real confusion takes over....

 

Since TI groms are 6K then what the hell is the range for base 0 and the range for base 1 ? 6144 is >1800 so it would seem that base 0 runs from >0000 to >1800 does this imply that base 1

runs from >2000->3800?

[Tursi]

Since TI groms are 6K then what the hell is the range for base 0 and the range for base 1 ? 6144 is >1800 so it would seem that base 0 runs from >0000 to >1800 does this imply that base 1

runs from >2000->3800?

 

It's a valid question! The address space for a GROM chip is still 8k (>0000->1FFF).. the last 2k (from >1800 to >1FFF) contains essentially garbage. The data is predictable, though, the MESS code notes that it's an OR of the bytes at two related address in the chip (the exact mapping escapes me at the moment, but I seem to remember confirming that on hardware). Of course, GROM simulators usually permitted the use of all 8k, which has no downside that I can see.

 

You are also correct that each GROM chip starts at an 8k offset, so as far as valid data in the original chips goes, GROM0 runs from >0000->17FF, GROM1 runs from >2000->37FF, and GROM2 runs from >4000->57FF - as you surmised.

 

I've looked for datasheets as well, years ago when I started working on them, but I never found anything. Based on descriptions of behaviour, both official and unofficial, and testing against the hardware itself, it seems to have a 16-bit address built in which is divided into two parts - the lower 13 bits (which is 8k of space) is auto-incrementing, and the upper 3 bits only change when a new address is written. This is why when you read from (for instance) >1FFF, then read back the GROM address, you get >0000 instead of >2000 (the upper 3 bits did not change).

 

Existing GROM /simulators/ do not work exactly like this. It takes fewer chips to implement a 16-bit counter than a 13-bit counter with a 3-bit latch, and so they will increment the entire address, and so reading from >1FFF will increment to >2000. Due to the way that the GPL interpreter works, in that it doesn't rely on a continuous address space between chips anyway, this doesn't break anything that was originally written for TI GROMs.

 

The tricky part of a simulator is that all GROMs attached to the bus respond to all accesses. The upper three bits are used as a sort of chip select to choose which one will return data on a read command, but they all go through the motions of setting the busy line, accepting any writes, and incrementing their internal address.

[Gazoo]

...

I understand what Mike is saying about the address wrapping back to zero on a GROM chip. Makes sense that this would happen when the internal address counter maxes out.

 

Tony is putting forth that the system has an additional counter that acts like a *CE line which is used to select a particular GROM IC from a set. This counter advances when the address wraps ? If so then when a GROM maxes out it will roll over to 0 but the IC counter will advance ?

...

 

Yes, the 'additional counter' is part of the GPL interpreter. Ksarul described this in his post and I confirmed it by reviewing the GPL Interpreter code and writing a test program.

 

Check this thread for the test program: http://atariage.com/forums/topic/221152-grom-wrap-test-program-and-results/

 

Gazoo

Edited January 28, 2014 by Gazoo

[Gazoo]

...

Since TI groms are 6K then what the hell is the range for base 0 and the range for base 1 ? 6144 is >1800 so it would seem that base 0 runs from >0000 to >1800 does this imply that base 1

runs from >2000->3800?

...

 

Yes, although the word 'base' is not appropriate as Groms can be wired to respond to different 'bases' (or 'Pages' or 'Banks') as memory mapped devices. The first base being >9800, next one being >9804, next one being >9808, and so on. Theirry's site has a description of how to modify a Widget to have sockets 2 & 3 respond to different Grom bases. I know you own a Widget, so you might be interested in this.

 

A more appropriate and the traditional way of describing Grom memory from g>0000 to g>1FFF (or g>17FF in a 6k Grom) is Grom 0. Grom memory from g>2000 to g>3FFF (or g>37FF in a 6k Grom) is Grom 1, and so on in that manner up to Grom 7 (g>E000 to g>FFFF).

 

TI Groms are all 6k, but could have been the full 8k. Probably a cost/size of chip factor.

 

Gazoo

[+mizapf]

 

It's a valid question! The address space for a GROM chip is still 8k (>0000->1FFF).. the last 2k (from >1800 to >1FFF) contains essentially garbage. The data is predictable, though, the MESS code notes that it's an OR of the bytes at two related address in the chip (the exact mapping escapes me at the moment, but I seem to remember confirming that on hardware).

 

The scheme implemented in MESS is what I inherited from the previous developer, but which can also be observed with the real GROMs, so this should be appropriately emulated.

 

The behavior also reveals a bit of the internal organization. As it seems to me, a GROM is composed of three 2K ROM areas which are selected by the address counter in the following way:

• When the counter is iii00xxxx (offset 0000-07FF), the first 2K area is connected to the outputs.
• When the counter is iii01xxxx (offset 0800-0FFF), the second 2K is visible.
• When the counter is iii10xxxx (offset 1000-17FF), the third area is visible.
• When the counter is iii11xxxx (offset 1800-1FFF), both second and third area are visible, combined by a bitwise OR.

(that is, grom[0x1800+x] = grom[0x0800+x] | grom[0x1000+x])

 

where iii is the three-digit ID of that GROM. If the ID does not match, the outputs are high impedance. However, the address counter of a GROM is always readable, regardless of the ID, so all counters must stay in sync, otherwise we'd get garbage when reading the address.

 

GROM simulators as seen in many third-party hardware do not fully adhere to the TI GROM behavior, which forced me to introduce another cartridge type in MESS called "gromemu". The "worst" one in that respect is the GRAMKracker which does not even have a readable address counter (hence you need the console GROMs).

[Willsy]

There is so much good GROM related information in the Bunyard Manual, that I decided I would upload it just in case anyone (who is interested in GROM) doesn't have it.

 

The Bunyard manual even shows how to build a GROM simulator.

 

Please download it if you don't have it, as I'll remove it in a few days, probably. It's too large to attach to a message here on Atariage.

 

Mark

 

[+retroclouds]

There is so much good GROM related information in the Bunyard Manual, that I decided I would upload it just in case anyone (who is interested in GROM) doesn't have it.

 

The Bunyard manual even shows how to build a GROM simulator.

 

Please download it if you don't have it, as I'll remove it in a few days, probably. It's too large to attach to a message here on Atariage.

 

Mark

 

 

Is this document something we could/may add to the Development Resources thread ?

Edited January 28, 2014 by retroclouds

[Willsy]

Go for it!

[RXB]

Much information is in the GPL manual that is not explained in the EA Manual. Matter of fact the EA manual does a terrible job of explaining memory use in GPL.

 

Also after looking over the GPL manual you will see how may cart do work more thoroughly. Especially the GROM carts like EA and XB or Mini Memory.