Jump to content
IGNORED

.BIN Repository - Images for cartridges that require "burning" - (NO LONGER UPDATED OR SUPPORTED)


Omega-TI

Recommended Posts

It is a little more complicated than that. Even though the Blue UberGROM boards have a flash chip in them, it is not possible to flash them in system--you have to do that in an EPROM burner. The second important thing to know about the 512K of flash in the UberGROM is that it is bank-switched ROM. TI cartridges have always been a mix of ROM-only (most of the third-party cartridges), GROM only (mostly TI cartridges), or cartridges with both GROM and ROM on them (mostly TI cartridges). The flash chip uses the same bank-switching system TI did (from the software standpoint), but significantly extended. TI used a maximum of four banks, the 512K Flash chip uses 64 banks.

 

In addition to the flash chip on the UberGROM board, you can install an ATMEL 1284P. Using the initialization code Tursi created for that, this chip is now capable of emulating up to 120K of GROM and 12K of GRAM. The GPL programs in the various 8K GROM slots CAN be reprogrammed in system using his loader software--but note, this is for GPL programs, not Assembly programs. These programs may also use ROM code (programmed into the 512K flash chip), creating the same style of hybrid programs TI did back in the day.

 

The capabilities of the cartridge thus allow it to reproduce any cartridge ever designed for the TI with the exception of the MBX cartridges, which also required 1K of on-board RAM. It also allows distribution of completely new software designed to take advantage of its expanded capabilities.

 

For development, the entire cartridge is emulated in the CLASSIC99 emulator, so it is possible to build and test new software in a PC environment and only transfer it to a physical cartridge once development is complete. There are many development tool sets available on the PC side. Read through the Developmental Tools thread to see which items are best suited to the way you program.

 

Also note: Black, RED, and Yellow boards use standard EPROMs of various sizes, and are excellent choices for ROM-only cartridge programs. They are also emulated in CLASSIC99. Black boards use Type 3 cartridge images, Red, Yellow, and Blue UberGROM boards (for the 512K flash) use Type 8 images.

  • Like 2
Link to comment
Share on other sites

Currently, there don't seem to be many ready-made images available for the Atmel 1284P. Now there is a growing list of stuff available for the ROM chip, and you'll discover that buying a burner is actually cheaper than buying a couple of used cartridges off of Ebay, so it will not take long to 'pay for itself'. When you get tired or bored, just reprogram the chip for $0.00 and you're off with something new.

 

<< HERE >> are a few Ebay purchasing options. Some with, some without sockets.

  • Like 1
Link to comment
Share on other sites

sml_gallery_35324_1027_12686.jpgto the .BIN Repository

 

This thread is for EVERYTHING where it comes to burning cartridges and chips for the TI-99/4A.

 

As things are added, message #2 will be updated with links to the specific programmable item(s) and links to manuals regarding programming, all questions and discussion will probably be free-flowing like always. Let's have some fun and see where this takes us!

 

Hopefully this will make it easy for people to find what they are looking for.

 

 

Examples of the new generation of TI cartridges

 

sml_gallery_35324_1001_31366.jpg

(32 or 28 pin) 128K addressable. Space for two switches for four 128K "banks"

Uses: 2764, 27128, 27256, 27512, 27C010, 27C020 or 27C040

 

sml_gallery_35324_1001_272929.jpg

28pin (Hackable to 128K)

Uses: 2764, 27128,27256 or 27512

 

sml_gallery_35324_1001_104292.jpg

Atmel 1284P (for GROM based software and extended features)

Also uses: 49F040 for 512K ROM

 

sml_gallery_35324_1027_205054.jpg

(32 or 28 pin), fully addressable 512K

2764, 27128, 27256, 27512, 27C010, 27C020, 27C040

 

sml_gallery_35324_1027_101519.jpg

Up to 2M

Uses 27C1100, 27C2100, 27C400, M27C800 and M27C160

 

gallery_35324_1027_2190280.gif

Great work, Keep it up. I need to start learning this very interesting skill.

  • Like 1
Link to comment
Share on other sites

It is a little more complicated than that. Even though the Blue UberGROM boards have a flash chip in them, it is not possible to flash them in system--you have to do that in an EPROM burner. The second important thing to know about the 512K of flash in the UberGROM is that it is bank-switched ROM. TI cartridges have always been a mix of ROM-only (most of the third-party cartridges), GROM only (mostly TI cartridges), or cartridges with both GROM and ROM on them (mostly TI cartridges). The flash chip uses the same bank-switching system TI did (from the software standpoint), but significantly extended. TI used a maximum of four banks, the 512K Flash chip uses 64 banks.

 

In addition to the flash chip on the UberGROM board, you can install an ATMEL 1284P. Using the initialization code Tursi created for that, this chip is now capable of emulating up to 120K of GROM and 12K of GRAM. The GPL programs in the various 8K GROM slots CAN be reprogrammed in system using his loader software--but note, this is for GPL programs, not Assembly programs. These programs may also use ROM code (programmed into the 512K flash chip), creating the same style of hybrid programs TI did back in the day.

 

The capabilities of the cartridge thus allow it to reproduce any cartridge ever designed for the TI with the exception of the MBX cartridges, which also required 1K of on-board RAM. It also allows distribution of completely new software designed to take advantage of its expanded capabilities.

 

For development, the entire cartridge is emulated in the CLASSIC99 emulator, so it is possible to build and test new software in a PC environment and only transfer it to a physical cartridge once development is complete. There are many development tool sets available on the PC side. Read through the Developmental Tools thread to see which items are best suited to the way you program.

 

Also note: Black, RED, and Yellow boards use standard EPROMs of various sizes, and are excellent choices for ROM-only cartridge programs. They are also emulated in CLASSIC99. Black boards use Type 3 cartridge images, Red, Yellow, and Blue UberGROM boards (for the 512K flash) use Type 8 images.

Thanks for the elaborate and clear explanation.

Link to comment
Share on other sites

It is a little more complicated than that. Even though the Blue UberGROM boards have a flash chip in them, it is not possible to flash them in system--you have to do that in an EPROM burner. The second important thing to know about the 512K of flash in the UberGROM is that it is bank-switched ROM. TI cartridges have always been a mix of ROM-only (most of the third-party cartridges), GROM only (mostly TI cartridges), or cartridges with both GROM and ROM on them (mostly TI cartridges). The flash chip uses the same bank-switching system TI did (from the software standpoint), but significantly extended. TI used a maximum of four banks, the 512K Flash chip uses 64 banks.

 

In addition to the flash chip on the UberGROM board, you can install an ATMEL 1284P. Using the initialization code Tursi created for that, this chip is now capable of emulating up to 120K of GROM and 12K of GRAM. The GPL programs in the various 8K GROM slots CAN be reprogrammed in system using his loader software--but note, this is for GPL programs, not Assembly programs. These programs may also use ROM code (programmed into the 512K flash chip), creating the same style of hybrid programs TI did back in the day.

 

The capabilities of the cartridge thus allow it to reproduce any cartridge ever designed for the TI with the exception of the MBX cartridges, which also required 1K of on-board RAM. It also allows distribution of completely new software designed to take advantage of its expanded capabilities.

 

For development, the entire cartridge is emulated in the CLASSIC99 emulator, so it is possible to build and test new software in a PC environment and only transfer it to a physical cartridge once development is complete. There are many development tool sets available on the PC side. Read through the Developmental Tools thread to see which items are best suited to the way you program.

 

Also note: Black, RED, and Yellow boards use standard EPROMs of various sizes, and are excellent choices for ROM-only cartridge programs. They are also emulated in CLASSIC99. Black boards use Type 3 cartridge images, Red, Yellow, and Blue UberGROM boards (for the 512K flash) use Type 8 images.

Can you kindly point me to good documentation to better understand the difference between ROM, GROM, GRAM, SRAM. I mean why does assembly run only from ROM? Isn't data stored as 1 and 0 good for the TI 99/4a CPU or did TI do something that the CPU cannot address the GROMs and that these are only accessible via the video chip and it's weird mid level language?

Link to comment
Share on other sites

A GROM is a 16-pin packaged ROM with 6 KiB usable space. It does not offer address bus pins but only 8 bidirectional data lines. Each GROM contains a private address counter. You can set an address via the data lines when the MODE pin is set to 1. When set to 0, you can read the contents at this location via the data lines, and by each read operation, the counter is advanced by 1 automatically. Hence, you have to set the address first, then you can stream out the data starting at this address.

 

The GROM memory divided in four parts of 2 KiB each. The first three blocks are usable. The fourth block is a kind of bytewise OR of the second and third block (supposedly, both blocks get activated).

 

GRAMs are GROM circuits that are writable. They're a bit like Unicorns, never seen in the wild.

  • Like 1
Link to comment
Share on other sites

A GROM is a 16-pin packaged ROM with 6 KiB usable space. It does not offer address bus pins but only 8 bidirectional data lines. Each GROM contains a private address counter. You can set an address via the data lines when the MODE pin is set to 1. When set to 0, you can read the contents at this location via the data lines, and by each read operation, the counter is advanced by 1 automatically. Hence, you have to set the address first, then you can stream out the data starting at this address.

 

The GROM memory divided in four parts of 2 KiB each. The first three blocks are usable. The fourth block is a kind of bytewise OR of the second and third block (supposedly, both blocks get activated).

 

GRAMs are GROM circuits that are writable. They're a bit like Unicorns, never seen in the wild.

Thanks for the superb explanation. I actually understood it all :)

Link to comment
Share on other sites

... these are only accessible via the video chip and it's weird mid level language?

 

Adding some more facts here.

 

The GROMs are not accessed via the VDP, but as memory mapped devices by the CPU. The base address in the TI console is 0x9800. Bit 14 (value 2^1, TI counts from left to right) is connected to the MODE pin. Bit 5 is combined with DBIN (Data bus direction) and connects to the DIR pin of the GROMs (input or output). That means you get four addresses: 9800 for reading data, 9802 for reading the address counter, 9c00 for writing data, and 9c02 for setting the address counter.

 

By "mid-leveI language" you refer to the Graphics Programming Language (GPL), right?

 

If you know Java or C#, the easiest way to think about the GROM/GPL concept is to realize that TI actually created a virtual machine in the console. GPL is the machine code of that virtual machine, which looks like an 8-bit architecture. GPL is surprisingly expressive; you have memory block copy commands and commands dedicated for formatted screen output.

 

So when you have a virtual machine, it does not matter what kind of access is required for the real chips, since you usually employ a hardware abstraction. Hence, the indirect access of the GROMs, which prevents them to be used in a normal architecture (with address and data bus), is transparent to the GPL program running in the virtual machine.

 

TI was killing two birds with one stone (in German, we do that with flies): The GROMs were exclusively manufactured by TI, comparably small for their capacity, and therefore easy to be packed into a cartridge. Maybe they were also cheaper than mask ROMs or (E)PROMs of the same capacity. Also, with GPL, they had their proprietary language.

 

---

 

As for the GRAMs, they were never available, as far as I know. Everything claiming to offer GRAM or GROM functionality today is emulating it by a special circuitry that makes a standard ROM or RAM look like a GROM/GRAM to the TI console. Usually, the simulation differs by offering the full 8 KiB space per emulated GROM/GRAM. This, by the way, forced me to add another cartridge type "gromemu" to MAME/MESS to take this difference into account.

  • Like 1
Link to comment
Share on other sites

 

Adding some more facts here.

 

The GROMs are not accessed via the VDP, but as memory mapped devices by the CPU. The base address in the TI console is 0x9800. Bit 14 (value 2^1, TI counts from left to right) is connected to the MODE pin. Bit 5 is combined with DBIN (Data bus direction) and connects to the DIR pin of the GROMs (input or output). That means you get four addresses: 9800 for reading data, 9802 for reading the address counter, 9c00 for writing data, and 9c02 for setting the address counter.

 

By "mid-leveI language" you refer to the Graphics Programming Language (GPL), right?

 

If you know Java or C#, the easiest way to think about the GROM/GPL concept is to realize that TI actually created a virtual machine in the console. GPL is the machine code of that virtual machine, which looks like an 8-bit architecture. GPL is surprisingly expressive; you have memory block copy commands and commands dedicated for formatted screen output.

 

So when you have a virtual machine, it does not matter what kind of access is required for the real chips, since you usually employ a hardware abstraction. Hence, the indirect access of the GROMs, which prevents them to be used in a normal architecture (with address and data bus), is transparent to the GPL program running in the virtual machine.

 

TI was killing two birds with one stone (in German, we do that with flies): The GROMs were exclusively manufactured by TI, comparably small for their capacity, and therefore easy to be packed into a cartridge. Maybe they were also cheaper than mask ROMs or (E)PROMs of the same capacity. Also, with GPL, they had their proprietary language.

 

---

 

As for the GRAMs, they were never available, as far as I know. Everything claiming to offer GRAM or GROM functionality today is emulating it by a special circuitry that makes a standard ROM or RAM look like a GROM/GRAM to the TI console. Usually, the simulation differs by offering the full 8 KiB space per emulated GROM/GRAM. This, by the way, forced me to add another cartridge type "gromemu" to MAME/MESS to take this difference into account.

Thanks for the detailed explanation.

  • Like 1
Link to comment
Share on other sites

  • 5 weeks later...

These rom images that Gazoo put together are the bomb, except, I can never remember which chip I want for which game... My eproms are all labelled things like G1, G2, EDU etc.. and I use a 512k red board with a zif socket. So, this morning I decided I would create a searchable index document... ( searchable, as in ctrl-f in the browser with the page loaded. )

 

In case this helps anyone else:

 

https://docs.google.com/spreadsheets/d/1uBiaDrJav8g-Yjk7w2wfVE5CKHGKCZidBE3W7tVGBWQ/edit?usp=sharing

 

This is what happens when I want to play Q-bert.

 

I plan to update the publisher details incrementally...

 

-M@

  • Like 6
Link to comment
Share on other sites

These rom images that Gazoo put together are the bomb, except, I can never remember which chip I want for which game... My eproms are all labelled things like G1, G2, EDU etc.. and I use a 512k red board with a zif socket. So, this morning I decided I would create a searchable index document... ( searchable, as in ctrl-f in the browser with the page loaded. )

 

In case this helps anyone else:

 

https://docs.google.com/spreadsheets/d/1uBiaDrJav8g-Yjk7w2wfVE5CKHGKCZidBE3W7tVGBWQ/edit?usp=sharing

 

 

"I like it!"

In fact I like it so much I made it a favorite in my browser and also linked to your post

from the index entry at the bottom of message #2. :thumbsup:

Link to comment
Share on other sites

  • 4 weeks later...

Adding a small contribution to the repository ...

 

... based on the UberGROM / relocation conversation I've been having with Tursi elsewhere in this forum, I've put together an UberGROM multi-GROM/ROM cart that seems to work okay.

 

Included are TI LOGO, TI LOGO II, and Microsoft Multiplan ... i.e., the useful language and/or productivity modules that aren't available on disk or other collections. There are three GROM slots left over, and I couldn't find a suitable language / utility to put in there that hadn't been done better elsewhere.

 

So, on to the specifics:

 

* This cartridge must be built from the recovery bootloader on the UberGROM itself,

* I had intended to provide a complete GROM ^L image, but the HxC utility doesn't seem to want to convert from .hfe -> .dsk,

* Therefore, this needs to be laid out as follows with the files on multicart.dsk:

* First, skip 9800 and 9804 entirely. Using them triggers the console GROM scanning bug as discussed elsewhere. Leave them unmapped.

* The base files are separated into 8k chunks prefixed with (base + 2). Therefore, 1XAA goes into 9808 slot 0, 1XAB into slot 1, 2XAC into 980C slot 3, and so forth.

* The EEPROM should be programmed with the contents of multicart1-eprom.bin

* NB: multicart.dsk is 80-track DSSD. If your gear can't handle that, please use Fred's TI99Dir or xdm99.py to transmogrify the files into something useful for you.

* Multiplan keeps its GROM base location data on disk. Included is phm3113.dsk which has the necessary modifications.

 

This has only been lightly tested. There are more occurrences of "98 00" lying around, especially in LOGO II, but I wasn't able to trigger crashes. Bug reports are welcome.

 

For those interested in how this put together, I've included my build and patch scripts. They expect to be run on something UNIX-like (MacOS or Linux or *BSD). Hopefully someone can take this and improve on what I've done.

 

Cheers!

ck-multi1v1.zip

  • Like 2
Link to comment
Share on other sites

Thanks for the nice work, Ckoba. You can build the data on an Atmel and save the EEPROM and DATA sections of the chip to disk with your EPROM device. That will give you a pair of pre-built files that can be directly loaded by anyone with a programmer for the Atmels.

Link to comment
Share on other sites

Thanks for the nice work, Ckoba. You can build the data on an Atmel and save the EEPROM and DATA sections of the chip to disk with your EPROM device. That will give you a pair of pre-built files that can be directly loaded by anyone with a programmer for the Atmels.

Doh.

 

I'll post a file as read from my TL866 later today. Didn't even think about that, got distracted following the HxC conversion problem down the rabbit hole ...

 

... edit: attached. It's only the stuff needed to burn the cartridge, plus Multiplan's .dsk. Set fuses the same way as documented elsewhere, or you can try to use the included config file (read from the 1284P)

 

Thanks for reminding me that I could just read the whole thing with the TL866. Should have thought of that ...

ck-multi1v1-binonly.zip

Edited by ckoba
  • Like 2
Link to comment
Share on other sites

Thanks for that. That's one of the methods that I tried (others being CLI via Linux and heavy cursing). The resulting .dsk is filled with 0xF6 and only 0xF6. I'm debugging the source of the Linux utility, which is a convoluted mess of interdependent libraries and non-POSIXy CLI flags. Unpleasant.

 

Edit: attach the .hfe, because why not.

broken_hfe.zip

Edited by ckoba
Link to comment
Share on other sites

Actually the way I do it is with DSK2PC. I 'upload' the virtual disk (HFE) to my PC. It comes out in my DOAD directory as as a perfect DSK image on the PC.

One of these days I'll HDX-ify my RS232 card. I have the boards, but need to get a few parts the next time I go into town. I only run emulated Windows (VMWare for the EPROM programmer, Crossover for classic99 and the rest); I suppose I'd need to write a HDX server in C or Python to satisfy my no-Windows-unless-necessary compulsion. Nice that Fred's server implementation has a protocol debug window icon_smile.gif Edited by ckoba
  • Like 2
Link to comment
Share on other sites

Guest
This topic is now closed to further replies.
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...