Jump to content
majestyx

GRAM? What exactly is this? re: Classic99 & RXB

Recommended Posts

Posted (edited)

I understand there was a product called the GRAM Kracker which was used to copy cartridges to diskettes, in addition to some other features. However, I'm not understanding its usage, or at least the GRAM piece of it, particularly in RXB and Classic99.

 

I see an RXB subprogram called POKEG with the following description:

 

Quote

 

The POKEG command writes the data in the numeric variable
list to GRAM at the specified address. It functions identical
to the EXTENDED BASIC command LOAD page 115. Except that it
writes to GRAM. GROM or GRAM addresses above 32767 must be
converted to a negative number by subtracting 65536 from the
desired address.

 

What I'm not getting is that the CALL LOAD subprogram states

 

Quote

 

The LOAD subprogram is used, along with INIT, LINK, and PEEK, to access Assembly Language subprograms. The LOAD subprogram loads an Assembly Language object file or direct data into the Memory Expansion for later execution using the LINK statement.

 

 

 

...while the POKEG appears to simply place a value in a memory location, such as a POKE command does on a C64 or Apple ][ and is not loading any assembly object. I guess that "direct data" covers individual values, but it's not really explained much further than the above in the XB manual, with not even one example given.

 

To further muddy the waters, the GRAM... option in Classic99 states

 

Quote

Enabling write to GRAM can cause the system to crash. This is not a GRAM device emulator, it only makes writes work.

So let's start at the beginning - what is GRAM?

 

Second - "it only makes writes work" in Classic99. Does this mean it's not actually storing what being written to GRAM?

 

Third - what addresses are "safe" to write to of those that are listed in 4 KB chunks? >0000 >2000 >4000 etc.

 

I'm still attempting to figure a way of using additional memory as storage for table data and am having a hard time understanding all the different types of memory the TI uses - program, stack, VDP, SAMS, GRAM, GROM and any others I may have missed. What locations store program data, variable data, and the like? Is there a good book/article/publication that explains this in layman's terms?

 

There is also a POKEV subprogram that discusses placing values in VDP memory. Since I'm still unclear as to what memory is what, and what is "safe" to use - such as with CALL POKEG/V - without messing up other data that may be stored in those memory locations, I'm really struggling to understand memory management on the TI.

Edited by majestyx

Share this post


Link to post
Share on other sites
I understand there was a product called the GRAM Kracker which was used to copy cartridges to diskettes, in addition to some other features. However, I'm not understanding its usage, or at least the GRAM piece of it, particularly in RXB and Classic99.
 
I see an RXB subprogram called POKEG with the following description:
 
 
The POKEG command writes the data in the numeric variable
list to GRAM at the specified address. It functions identical
to the EXTENDED BASIC command LOAD page 115. Except that it
writes to GRAM. GROM or GRAM addresses above 32767 must be
converted to a negative number by subtracting 65536 from the
desired address.
 
What I'm not getting is that the CALL LOAD subprogram states
 
 
The LOAD subprogram is used, along with INIT, LINK, and PEEK, to access Assembly Language subprograms. The LOAD subprogram loads an Assembly Language object file or direct data into the Memory Expansion for later execution using the LINK statement.
 
 
 
...while the POKEG appears to simply place a value in a memory location, such as a POKE command does on a C64 or Apple ][ and is not loading any assembly object. I guess that "direct data" covers individual values, but it's not really explained much further than the above in the XB manual, with not even one example given.
 
To further muddy the waters, the GRAM... option in Classic99 states
 
Enabling write to GRAM can cause the system to crash. This is not a GRAM device emulator, it only makes writes work.
So let's start at the beginning - what is GRAM?
 
Second - "it only makes writes work" in Classic99. Does this mean it's not actually storing what being written to GRAM?
 
Third - what addresses are "safe" to write to of those that are listed in 4 KB chunks? >0000 >2000 >4000 etc.
 
I'm still attempting to figure a way of using additional memory as storage for table data and am having a hard time understanding all the different types of memory the TI uses - program, stack, VDP, SAMS, GRAM, GROM and any others I may have missed. What locations store program data, variable data, and the like? Is there a good book/article/publication that explains this in layman's terms?
 
There is also a POKEV subprogram that discusses placing values in VDP memory. Since I'm still unclear as to what memory is what, and what is "safe" to use - such as with CALL POKEG/V - without messing up other data that may be stored in those memory locations, I'm really struggling to understand memory management on the TI.
In the FAQ there's a good link to all you want to know about gram and grom

Sent from my LM-G820 using Tapatalk

  • Thanks 1

Share this post


Link to post
Share on other sites

Unless you have a device with GRAM attached to your console--you have none. You do have GROM (the permanent version of GRAM), but you can't write to it without weird consequences. It is a TI specific storage medium for program data, and each GROM chip provides 6K of self-incrementing memory at a single presentation address on the data bus (in an 8K space). GRAM allows you to use the entire 8K of the space.

  • Like 1
  • Thanks 1

Share this post


Link to post
Share on other sites
Posted (edited)

Looks like I overlooked the link to Thierry's article. Thanks for the nudge in the right direction, Greg!

 

Also, Ksarul, what you're saying made me realize that on a physical system there wouldn't really be many people who have GRAM - certainly less than those who have a SAMS card - so this is a no-go. I did know about the difference between GROM and GRAM, along with the 6K/8K oddity, but was completely forgetting the fact that there isn't any GRAM in a TI itself, thus the need for a GRAM Kracker/Karte.

Edited by majestyx
  • Like 2

Share this post


Link to post
Share on other sites

Sounds like you got most of it, but just to clarify my parts:

 

Second - "it only makes writes work" in Classic99. Does this mean it's not actually storing what being written to GRAM?

 

Almost all utilities meant to load into GRAM expect that you have a GRAM Kracker or a GRAMUlator or other device which may or may not offer additional facilities. Since I don't have any of those nor did I have programming documentation for them, all I added to Classic99 was the ability to make the GROM writable, thus, GRAM but without any extra hardware support. My comment in the manual was just disclaiming any support for GRAM-Kracker (etc) specific software. It turns out the loaders worked anyway, as far as I know, but I had no interest in deeper support.
 

Third - what addresses are "safe" to write to of those that are listed in 4 KB chunks? >0000 >2000 >4000 etc.

 

The GROM memory map is similar to the main memory map, in that it's a 64k address space. For every 8k block (ie: starting at >0000, >2000, >4000, >6000, >8000, >A000, >C000 and >E000), original TI GROMs only provided 6k of data. However, it appears there is no requirement for this to be true, and nearly all GRAM and GROM emulation devices provide the full 8k space.

 

The range from >0000 to >1FFF is reserved for the TI operating system - it boots the console, gives you the color bars page, enumerates and starts cartridges, etc. From >2000 to >5FFF contains TI BASIC in the stock console. From >6000 to >FFFF is reserved for plug-in cartridges.

 

Of course, it can get more complicated, as there is a method to provide pages of GROM by accessing through different CPU addresses, or 'bases'. The standard console actually searches 16 bases, and the memory map allows for a potential of 256 bases. However, the base console also doesn't decode the base (so the OS and TI BASIC appear to be present in all of them), and cartridges likewise need extra hardware to recognize the concept. Some of the GRAM devices do.
 

I'm still attempting to figure a way of using additional memory as storage for table data and am having a hard time understanding all the different types of memory the TI uses - program, stack, VDP, SAMS, GRAM, GROM and any others I may have missed. What locations store program data, variable data, and the like? Is there a good book/article/publication that explains this in layman's terms?

 

They don't make it easy, do they?! :) 

 

There's memory directly attached to the CPU, or CPU memory. This is a 64k address space with a lot of it pre-reserved in 8k chunks: >0000->1FFF is the boot OS (mostly an interpreter for the GPL code stored in GROM), >2000->3FFF is RAM space in the 32k expansion, >4000->5FFF is reserved for peripheral cards to map in their DSR ROM while they are being used, >6000->7FFF is reserved for plug in cartridges, >8000->9FFF is reserved for interfacing to the various pieces of hardware and other memories in the system, and the last 24k at >A000->FFFF is the rest of the 32k RAM expansion. Assembly code can only be executed from CPU memory.

 

Cartridges can of course bank-switch their 8k memory block, and the largest ROM carts so far are up to 128MB. The largest commonly available ROM carts are 2MB, though. Cartridges can also contain GROM or GRAM, and I believe the largest so far are up to 120KB, with 40K being the stock, un-paged size. The two memories can exist side by side.

SAMS (and other versions of AMS) is a replacement for the 32k card that allows you to map more than 32k memory into the console (though still a maximum of 32k at a time). It's very flexible with a 4k resolution on pages, and allows megabytes of total RAM.

 

Unlike most systems, the TI CPU doesn't actually have a hardware stack, so any discussion about a stack is a software concept specific to whatever you're talking about.


VDP RAM is the 16k of memory attached to the Video Display Processor. It can only be accessed a byte at a time through the video chip. Replacement video chips have the ability to add more video RAM, depending on their capabilities, but are reasonably uncommon.

 

Just to confuse a little further, there's also the CRU memory space. This isn't actually data memory, but a 4k-bit virtualized I/O space that the CPU recognizes and the 9901 chip provides (some of). It's used to interface with the keyboard, joysticks and cassette, manage the video interrupts, and interact with peripheral expansion cards (in most cases only to turn them on and off, but many cards use additional bits). This space is also pre-allocated to specific functions, with a few reserved slots that user-designed cards usually fit into.

 

  • Like 3
  • Thanks 2

Share this post


Link to post
Share on other sites
Posted (edited)

Have there ever been GRAMs? I mean, as circuits, some TMCxxxx? The only thing I heard of are GRAM emulations with normal RAMs and an address counter circuitry. I guess TI may have planned for such circuits but never manufactured them.

Edited by mizapf

Share this post


Link to post
Share on other sites

I have never seen one. Even the TI produced GRAM devices all used simulated GRAMs (and a lot of their GROm devices used the same emulation circuitry to allow testing).

Share this post


Link to post
Share on other sites

I seem to remember that we once discussed a problem in the GROM design that would appear when we had GRAMs, possibly concerning the prefetch. There is an assumption that all GROM address counters are updated in parallel, and in case of GRAMs, things would go wrong somehow.

Share this post


Link to post
Share on other sites

By stack, I meant the amount of memory that the SIZE command returns. I wasn't sure if this was separate, but based on Tursi's explanation, it's not. According to the XB Manual

 

Quote

 

If the Memory Expansion peripheral is attached, the number of bytes available is given as the amount of stack free and the amount of program space free.

 

If the Memory Expansion is attached, the space available in the stack is the amount of space left after the space taken up by string values, information about variables, and the like is subtracted. Program space is the amount of space left after the space taken up by the program and the values of numeric variables is subtracted.

 

 

So I guess I'm back to what I was discussing in a separate thread, which is a way of accessing AMS memory in order to store table/variable data, which there doesn't seem to be except for loading an entire page of memory at a time, i.e. not even a POKE command to place data into a memory location in an AMS memory bank, what's more a feature like Rasmus mentioned such as special arrays that exclusively use AMS memory. The reason I'm so wanting something like this is because I'm having a difficult time tracking all the stats I'd like to in my statistical baseball simulation I'm developing - the woes of attempting this with a 32K computer. Having access to all that extra memory would make it so much easier.

Share this post


Link to post
Share on other sites
9 hours ago, mizapf said:

I seem to remember that we once discussed a problem in the GROM design that would appear when we had GRAMs, possibly concerning the prefetch. There is an assumption that all GROM address counters are updated in parallel, and in case of GRAMs, things would go wrong somehow.

The GramKracker got around this by just using the console GROM address registers.  That's why you'll see "synchronize GROM addresses" code written into the GramKracker built-in software to assure that all three of the registers are sync'd to the same and expected address that was then used by the GK.  Also, the GK utility disk had a routine that allowed the user to re-configure the MG Explorer for two different architectures of GRAM simulators.  One selection forces the EXP to do a DECrement before GRAM address write and the other selection does not perform the DEC.  Back in the 80's this could be a problem depending on which simulator you happened to have.  So, that might be the problem you're referencing?

Share this post


Link to post
Share on other sites
12 hours ago, mizapf said:

I seem to remember that we once discussed a problem in the GROM design that would appear when we had GRAMs, possibly concerning the prefetch. There is an assumption that all GROM address counters are updated in parallel, and in case of GRAMs, things would go wrong somehow.

To make GRAM work in Classic99, I had to make sure writes went to the address that was /latched/, not the address stored in the GROMs post-prefetch. So yeah, it's not a perfect 1:1, but since you can ignore prefetch for 98% of operations, the GramKracker solution solves the other 2% by letting the GROMs handle read-back.

  • Like 1

Share this post


Link to post
Share on other sites

Yes, I think this was the point, and maybe a reason why we never saw genuine GRAMs. Could also be that normal RAM became cheaper.

  • Like 2

Share this post


Link to post
Share on other sites

GROM/GRAM port on the TI99/4A can access (with the right device interface) 640K of GRAM/GROM and as many pages of RAM/ROM >6000 to >7FFF as you could design into that device say 2Meg.

 

Add in a 1Meg RAM SAMS or 10Meg RAM  SAMS and we could do a hell of lot.

 

Now we just need 8Meg of VDP RAM and 640x320 pixel screens and we could kinda emulate a mouse OS like Mac or Windows PC.

  • Thanks 1

Share this post


Link to post
Share on other sites
On 8/15/2019 at 10:49 AM, mizapf said:

Yes, I think this was the point, and maybe a reason why we never saw genuine GRAMs. Could also be that normal RAM became cheaper.

I think it was always cost, plus the market needed a very different kind of RAM.

 

TI touted the advantages of masked ROM, chiefly manufacturing cost.  Making ROM or GROM to order was much easier than making a RAM--there was a final lithography mask added to connect the desired 0 bits in an otherwise standard ROM production line.   The GROM had fewer pins thanks to a TI invention of latching the address in 2 bytes--an idea that became an industry standard in DRAM pinouts.  SRAM was a relatively expensive technology process involving a charge capture layer and more pins.

 

Compare 18K of GROM to the cost of 16K true RAM.

 

In late 1982, the 3x6K GROMs in the console cost $3.96, while 16K of VDP RAM still cost $9.20.

 

Adding an extra 16K of DRAM to the console, an idea that was seriously considered, would cost $9.20 plus a refresh controller at $1.25.

 

DRAM required constant refresh cycles, complicating any other use of the address pins. I think that adding the GROM address emulation to a DRAM was not worth the effort of solving this problem on a single chip. It was really nobody's problem.. GROM was supposed to be cheap ROM. You might as well have the GPL interpreter keep its own address pointer and read from DRAM.

 

Meanwhile, Karl Guttag took TI in the direction of dual-port VRAM:  a very useful innovation to give the CPU full read/write control of the DRAM, while the DRAM had one serial output going to the VDP display circuitry, over which it streamed pixels one full row at a time. (In the 9918, the VDP reserved a lot of available memory cycles to get what it needed to refresh the display.)

 

The Dual-port VRAM in turn evolved into DDR and the memory technology used today.


 

Returning to the topic of GROM cost:

 

In 1982, normal RAM or even ROM did not become cheaper than GROM. For use in TI consoles, it was judged more useful to put in 1K SRAM to populate >8000->83ff, or even 16K of paged DRAM.  Even so, the number of cheap GROMs for the console ballooned into at least 7 for the console successors (how many in the 99/8?)

 

Below are some late 1982 prices. TI's internal costs were falling.

 

4732 4k ROM from $3.70 to $2.50

6k GROM from $1.35 to $1.32

4116 DRAM from $1.65 to $1.15

single voltage 8117 DRAM from $1.40 to $1.15

DRAM controller $1.25

6810 SRAM (128 bytes) from $2.06 to $1.25 (use two for 16 bit words)

TMS2114 SRAM (256 bytes) I don't have a cost for (use one with 8 bit words for the TMS9995)

 

My figure for the extra 16K of console RAM is based on 8x8117 plus DRAM controller.


 

In late 1982:

 

Total IC cost in the 4A was falling from $91.63 to $64.95

Total component cost for the 4A was falling from $207.24 to $152.46 (In 1983 this would have to be negotiated below $100 in the QI or V2.2 to keep fighting the price wars.)

 

Source of prices: personal notes of Ron Wilcox, 99/4B/4C/5 engineer.

 

Edited by FarmerPotato
  • Like 5

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...

  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...