Grom Address wrapping

[Tursi]

What is the "next" GROM address 0x2000? I did not switch the GROM base. Or do you think of the next GROM, i.e. the counter is 0x4000? Then why does it return 0x2000?

 

Without having exact details on the GROM internals, it seems to me that the address counter in the GROM holds all 16 bits, and the respective GROM only responds on the bus when its ID matches the first three bits of the address.

Right.. but the upper three bits are latched (they can only be changed by an address load), which is why the address wraps around from >3FFF to >2000, and not to >4000.

[Gazoo]

I just had Ciro run a test on his TI-99/8, and I suppose it is using "real" GROMs. My test program set the GROM counter to 37FF. After a read, the next address is 3800 (read from the address counter). Also, the next address after 3FFF is 2000, as the address counter shows.

 

If you are interested and if you can transfer a D/F 80 file to a real TI, I can upload that tool here.

 

Hi, Michael.

 

I would like a copy of the tool. I've just had an 'Aha!' moment. I believe everybody's observations are correct, conflicting as it may seem.

The tool should prove my theory.

 

Gazoo

[RXB]

I suppose a very compact way to store files for RXB would be to use my CALL USER as it loads DV80 Text TI Writer format files.

The only reason for TI Writer format is the CR is needed at the end of each like to tell the KSCAN that just like when you type in a program that that is the end of the line input.

 

RXB subprogram CALL USER can run hundreds of XB programs one after the other from one single text file on disk or from a device. Example:

CALL USER("SCS1.VOLNAME.SUBVOLNAME.PRGRM")

or

CALL USER("CS1")

or

CALL USER("DSK9.THISPRGM")

or A$="device.name" :: CALL USER(A$)

 

The text file could be hundreds of sectors long....

 

http://www.youtube.com/watch?v=QC_Hn8_WlO4

Edited November 16, 2013 by RXB

[Gazoo]

 

Hi, Michael.

 

I would like a copy of the tool. I've just had an 'Aha!' moment. I believe everybody's observations are correct, conflicting as it may seem.

The tool should prove my theory.

 

Gazoo

 

Since I haven't gotten a response to this post, I'll lay out my theory although there exists no real hardware to prove it.

 

The GPL MOVE command is independent of the Grom counter according to my reading of the console rom code. The GPL MOVE command uses an independent Grom address counter. Anyone care to look at the console rom code and verify this?

 

What does this mean? It means that a Grom emulation device that 'rolls around' at the end of a Grom will probably not break most existing software created by GRAM PACKER or similar Grom packs created 'by hand' or by means of any other similar programs that move programs stored in Grom to CPU memory for execution.

 

Many such Grom packs cross the boundaries across Groms when they are moving data, and if they were dependent on the Grom counter emulation that does NOT continue across Grom boundaries, they would be broken.

 

This was my concern with the creation of this new cart, but as there are few (the only one being currently known is SUPER EXTENDED BASIC) Grom programs that actually execute code across the Grom boundaries, there should be little 'breaking' of existing software if the device 'rolls around' at the end of a Grom instead of continuing execution into the next Grom.

 

Gazoo

Edited January 15, 2014 by Gazoo

[Gazoo]

 

Since I haven't gotten a response to this post, I'll lay out my theory although there exists no real hardware to prove it.

 

The GPL MOVE command is independent of the Grom counter according to my reading of the console rom code. The GPL MOVE command uses an independent Grom address counter. Anyone care to look at the console rom code and verify this?

 

What does this mean? It means that a Grom emulation device that 'rolls around' at the end of a Grom will probably not break most existing software created by GRAM PACKER or similar Grom packs created 'by hand' or by means of any other similar programs that move programs stored in Grom to CPU memory for execution.

 

Many such Grom packs cross the boundaries across Groms when they are moving data, and if they were dependent on the Grom counter emulation that does NOT continue across Grom boundaries, they would be broken.

 

This was my concern with the creation of this new cart, but as there are few (the only one being currently known is SUPER EXTENDED BASIC) Grom programs that actually execute code across the Grom boundaries, there should be little 'breaking' of existing software if the device 'rolls around' at the end of a Grom instead of continuing execution into the next Grom.

 

Gazoo

 

 

The code in console rom regarding the GPL MOVE command is referenced below, just in case someone was interested in looking at it but did not have access to the source. It appears to me that the the GPL MOVE does it's own incrementing of the Grom address that it uses so that it would be immune to 'rollback', except of course when it gets to g>FFFF.

GPL MOVE:
061E D14E MOVB 14,5
0620 0999 SRL 9,9 Test on IMM value
0622 1804 JOC >062C Jump, if number immediate value
0624 06A0 BL @>077A Fetch number
0626 077A
0628 C200 MOV 0,8 In R8
062A 1004 JMP >0634
062C D21D MOVB *13,8 Fetch number
062E 0AF4 SLA 4,15 Time loss
0630 D81D MOVB *13,@>83F1 Complete number in R8
0632 83F1
0634 04C4 CLR 4
0636 0AC9 SLA 9,12
0638 06A0 BL @>0758 Determine destination
063A 0758
063C C081 MOV 1,2
063E B249 AB 9,9
0640 1702 JNC >0646
0642 0224 AI 4,>0003 Set VDP flag
0644 0003
0646 C1C4 MOV 4,7
0648 04C4 CLR 4
064A 06A0 BL @>0758 Determine source
064C 0758
064E A104 A 4,4 R4 *2
0650 C1A4 MOV @>0CCE(4),6 Source routine in R6
0652 0CCE
0654 A1C7 A 7,7
0656 C1E7 MOV @>0CD4(7),7 Destination routine in R7
0658 0CD4
065A 06A0 BL @>0864 Push GROM address on substack
065C 0864
065E 0456 B *6 Execute source
Source ROM or RAM:
0660 D2F1 MOVB *1+,11 Fetch
0662 0457 B *7 Execute destination
Source VDP RAM:
0664 D7E0 MOVB @>83E3,*15 Write address
0666 83E3
0668 D7C1 MOVB 1,*15
066A 0581 INC 1
066C D2EF MOVB @>FBFE(15),11 Fetch data
066E FBFE
0670 0457 B *7 Execute destination
Source GROM:
0672 DB41 MOVB 1,@>0402(13) Write GROM address
0674 0402
0676 DB60 MOVB @>83E3,@>0402(13)
0678 83E3
067A 0402
067C 0581 INC 1
067E D2DD MOVB *13,11 Fetch data
0680 0457 B *7 Execute destination
Destination RAM:
0682 DC8B MOVB 11,*2+ Write
0684 1022 JMP >06CA Go on
Destination GROM:
0686 DB42 MOVB 2,@>0402(13) Write GROM address
0688 0402
068A DB60 MOVB @>83E5,@>0402(13)
068C 83E5
068E 0402
0690 0582 INC 2 Next address
0692 DB4B MOVB 11,@>0400(13) Write into GRAM
0694 0400
0696 1019 JMP >06CA Go on
Destination VDP register:
0698 93A0 CB @>83E5,14 R2 Lbyte >01?
069A 83E5
069C 1607 JNE >06AC
069E 23A0 COC @>0012,14 Version?
06A0 0012
06A2 1602 JNE >06A8
06A4 026B ORI 11,>8000 Set 16k bit
06A6 8000
06A8 D80B MOVB 11,@>83D4 Register value 1
06AA 83D4
06AC D7CB MOVB 11,*15 Write
06AE 0262 ORI 2,>0080 VDP register
06B0 0080
06B2 D7E0 MOVB @>83E5,*15 Write from Lbyte R2
06B4 83E5
06B6 0582 INC 2 Next register
06B8 1008 JMP >06CA Go on
Destination VDP RAM:
06BA D7E0 MOVB @>83E5,*15 Write address VDP
06BC 83E5
06BE 0262 ORI 2,>4000 Writing
06C0 4000
06C2 D7C2 MOVB 2,*15
06C4 0582 INC 2 Next address
06C6 DBCB MOVB 11,@>FFFE(15) Write data
06C8 FFFE
06CA 0608 DEC 8 End ?
06CC 15C8 JGT >065E No, go on
06CE 0460 B @>083E Return GPL interpreter, set condition bit and
06D0 083E GROM address from substack

------------------------------------------------------------------

PUSH actual GROM address on subroutine stack
0864 05E0 INCT @>8373 Increase stack pointer
0866 8373
0868 D120 MOVB @>8373,4
086A 8373
086C 0984 SRL 4,8
086E D92D MOVB @>0002(13),@>8300(4) Address GROM on stack
0870 0002
0872 8300
0874 D92D MOVB @>0002(13),@>8301(4)
0876 0002
0878 8301
087A 0624 DEC @>8300(4) Correct address
087C 8300
087E 045B B *11 Return

Takers? ... Anyone?

 

... or should I continue urinating into the breeze?

 

Gazoo

Edited January 15, 2014 by Gazoo

[+Ksarul]

I've been reading this, Gazoo. I just haven't had anything to add to your analysis. I still have to look to see if the documents I got from Mike Bunyard a few years ago included the functional spec for GROM chips.

[RXB]

The GPL Stack and VDP Stack and Registers need to be separate.

Otherwise a use of a XML would crash the system every-time.

GROM/GRAM is auto incrementing for this reason.

 

If GPL was not auto incrementing it would be almost impossible to use as the management would over ride and features it would have.

[+Lee Stewart]

I've been reading and thinking, as well, @Gazoo. I've been preoccupied as you probably know.

 

I think this would be easy enough to check out—easy, but painful. I did something like this (walking through GPL interpreter code in the console) when I was figuring out how the ATN routine worked a year or so ago (http://atariage.com/forums/topic/201887-turboforth-v12-beta-evolution-arcana/?do=findComment&comment=2590341). I will try to do it soon.

 

...lee

[Tursi]

GPL MOVE sets the GROM (or VDP) address for every byte read and written. The behavior of increment on the hardware doesn't affect it.

[Gazoo]

GPL MOVE sets the GROM (or VDP) address for every byte read and written. The behavior of increment on the hardware doesn't affect it.

 

That's what I read also. Thank you.

 

So, in essence, the 512k cart's Grom implementation should have no effect on 99.99% of existing Grom software.

 

Gazoo

[Tursi]

 

That's what I read also. Thank you.

 

So, in essence, the 512k cart's Grom implementation should have no effect on 99.99% of existing Grom software.

 

Gazoo

 

Not to mention the fact that I conceded to you and added a configuration option to operate in either mode at the user's choice the last time we brought this up.

[Gazoo]

 

Not to mention the fact that I conceded to you and added a configuration option to operate in either mode at the user's choice the last time we brought this up.

 

"I don't want to throw away all my testing at this point." is a concession?

 

The GPL MOVE code has not been discussed previously. And it was your belief that it would not cross Grom boundaries, as evidenced by your PC program which is functionally very similar to GRAM PACKER, but is coded instead to make multiple GPL MOVES of 8k or less instead of just one (24k high ram) or two (both 24k high ram and 8k low ram) so as to avoid crossing Grom boundaries.

 

So this has nothing to do with a concession, it is new information as to the behavior of a very specific TI function. My interest in this is finding out EXACTLY how the Grom system within the TI works, it's been a fascination of mine ever since I got my first Pgram card. And perhaps a new Grom device can benefit from our combined efforts to discover that information. (and hopefully without this distasteful bickering, but I'm not holding my breath as far as that's concerned )

 

And now that this particular function has been resolved, the question of how the different Grom emulators handle the boundaries is still up in the air. They may or may not rollback at the boundaries between Groms. To the best of my knowledge all the Grom emulators with the exception of the HSGPL require that a real Grom be present. This was explained by Gary Bowser when describing the SOB. The SOB eprom containes the contents of Groms 0 & 1, and Grom 2 must be present for it to function correctly. It is likewise with the Pgram and other Grom emulation devices other than the HSGPL. So does the real Grom that's present control the auto-incrementation of the Grom address, or is that a function of the Grom emulator device? And does the HSGPL mimic the other devices in it's 'boundary behavior' or not? Michael's test program can probably answer these questions, but it is not yet available to us (the masses). After the test program is available I can test the HSGPL behavior and maybe the SOB (I'll have to find a console to put it in). Can someone else test the other devices at that time - Gram Kracker, Pgram, Mechatronic, others?

 

Gazoo

Edited January 18, 2014 by Gazoo

[Tursi]

I added a configuration option as a concession. Sorry if that was confusing.

[Tursi]

I'm also sorry that you choose to consider all this bickering.

 

The fact is that I designed this device to operate like the console GROMs do, and I have numerous years of coming to understand their operation via test programs, circuit analysis, and emulation.

 

There are no MOVE commands in TI-supplies GROMs that cross boundaries. My choice to make my program behave the same was to be compatible with that observation.

 

The problem with wrapping the address counter to the next GROM is that the original GROMs in the system will wrap their address around, resulting in a conflict when the GROM address is read back by the system. All GROMs respond to the address read command, so the console GROMs will return the wrapped address, and if the GROM simulator honors the command, it will return the incremented address. If both drive the bus at the same time, with different values, this can and does lead to problems.

 

The simulator that I offered for use in this cartridge does not honor the address read command, so will not cause the line driver issue. Thus I decided - some months ago - that it was okay to resolve the debate by adding an option.

 

That is the last I will say on this topic.

[Gazoo]

I'm also sorry that you choose to consider all this bickering.

...

There are no MOVE commands in TI-supplies GROMs that cross boundaries.

...

All GROMs respond to the address read command

...

That is the last I will say on this topic.

 

1. Not my choice.

 

2. No, that's in the GPL interpreter part of the Console ROM, as I showed by my code example. When one stores a memory image in Grom to be moved into CPU memory such as the nearly identical programs GRAM PACKER and MakeCart do, the Grom code for the move is executed from Console ROM's GPL Interpreter, regardless of boundaries real or not, in Groms.

 

3. Yes they do, or the Gram emulators I mentioned wouldn't work.

 

4. Good. The debate should have ended in message #106 after you finally admitted the behavior of the GPL MOVE command and I stated that the emulation as to whether Groms continued execution across boundaries was all but moot, as long as the emulator honors the original behavior of the GPL MOVE command

 

Gazoo

Edited January 20, 2014 by Gazoo

[+acadiel]

This is the new home for the GROM Discussion

[RXB]

We should specify that Miller Graphics pretty much invented GRAM and GROM does not behave like GRAM.

 

GROM had 6K boundaries and GRAM was designed to have 8K boundaries or 6K.

 

So realistically we are talking about GRAM not GROM. I think this would clear up much of the confusion.

 

GROM SUCKS as it has 6K boundaries. GRAM is much better as it has 8K boundaries per page. (or as Trusi wants to call the Slots, Miller Graphics called them a page)

Edited January 23, 2014 by RXB

[+Ksarul]

I have to disagree there, Rich. TI designed and built two different GRAM devices long before MG did. I have one of the Pizza-Box GRAM devices, more properly known as a GSIM, and I've seen and used the original PEB GRAM card designed by the TI Labs at Almelo Holland. There are about 15-20 GSIMs out there and there are exactly four of the Almelo cards left in existence. There were also several devices that TI designed to simulate GROMs for testing--I have three different devices, the earliest of which was assembled and tested in 1979. Lastly, TI prototype cartridges are very often on an EGROM cartridge board. It too simulates GROM--and is available in two variants: one for GROM cartridge files only and one for both ROM and GROM cartridge files. I have several prototypes using each variant of these boards, and I have two blank circuit cards for them (TI sold these to developers so that they could test their cartridge code in a GROM-type environment).

[+Ksarul]

One last note: it was a very simple conceptual jump from the EGROM cartridge to the GRAM Kracker, as all of the circuitry to recreate the auto-incrementing features of GROM were there--and the EGROM cartridges were available to businesses designing TI software for quite some time while TI was still selling their systems actively and looking for additional programs to market.

[RXB]

I have to disagree there, Rich. TI designed and built two different GRAM devices long before MG did. I have one of the Pizza-Box GRAM devices, more properly known as a GSIM, and I've seen and used the original PEB GRAM card designed by the TI Labs at Almelo Holland. There are about 15-20 GSIMs out there and there are exactly four of the Almelo cards left in existence. There were also several devices that TI designed to simulate GROMs for testing--I have three different devices, the earliest of which was assembled and tested in 1979. Lastly, TI prototype cartridges are very often on an EGROM cartridge board. It too simulates GROM--and is available in two variants: one for GROM cartridge files only and one for both ROM and GROM cartridge files. I have several prototypes using each variant of these boards, and I have two blank circuit cards for them (TI sold these to developers so that they could test their cartridge code in a GROM-type environment).

 

From the only 2 I have seen they were 6K boundaries. The GRAM KRACKER used 8K boundaries.

So again 6K boundaries SUCK and 8K boundaries are much better.

TI threw away 2K space per page 2x8=16K of GRAM not used.

Miller Graphics did a better job and did a standard of 8K just like everyone else in the world but Texas Instruments!

 

The idea of 6K boundaries in GRAM was a bad and goofy idea to begin with was it not?

 

Next would be that between each page is a 2K space of empty address not used so you get >77FF and the next valid address is >8000?

That even looks like a stupid design to anyone.

Edited January 25, 2014 by RXB

[TI-Sissy]

 

From the only 2 I have seen they were 6K boundaries. The GRAM KRACKER used 8K boundaries.

So again 6K boundaries SUCK and 8K boundaries are much better.

TI threw away 2K space per page 2x8=16K of GRAM not used.

Miller Graphics did a better job and did a standard of 8K just like everyone else in the world but Texas Instruments!

 

The idea of 6K boundaries in GRAM was a bad and goofy idea to begin with was it not?

 

Next would be that between each page is a 2K space of empty address not used so you get >77FF and the next valid address is >8000?

That even looks like a stupid design to anyone.

 

from all your whining it's a standard and should be kept, no matter how stupid.

[+Ksarul]

Rich, you completely missed the point of my post--the first GRAM devices were made by TI, and not by Millers Graphics. The limitations of the chip's die size were likely more important to the designers of GROM than filling the entire available 8K space. They had to fit both the memory and the addressing logic on the chip, in a time where the biggest available chips had only 8K. A 2K reduction to add the auto-incrementing feature--and keep all of the remaining 6K off of the system bus was a major bonus. The fact that someone else was able to replicate the hardware used in their GRAM simulators several years later and decided that they didn't want to "waste" the extra address space wasn't anything new--TI could have done the same in their GRAM devices--but it would have been counterproductive, as the resulting code wouldn't fit into a GROM. Trying to second guess or deprecate the skills of a set of engineers because someone else did it differently later is not a way to carry on a civilized discussion. Each set of enginners had a set of goals--and those goals were targeted to different solutions. No more--no less. Do I like my GRAM Kracker, GRAMulator, GRAM Karte, HSGPL, Wiesbaden Supermodul, and PGRAM+? Definitely. Do I also like my GSIM? Also, definitely. They are all excellent GRAM devices.

[+Lee Stewart]

That was a joy to read, Jim!

 

...lee

[+acadiel]

<sigh>

 

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

[sometimes99er]

<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.

 

Another thing is if one thinks that this is fact, this is false, this is inappropriate and what not. As such I think the present thread title, "Arguing, Hollering, and Accusations regarding Grom Address wrapping", is a bit of bad karma for the forum, but then we can't all agree on everything.