stevetb Posted October 29, 2016 Share Posted October 29, 2016 Hi All, I am interested in putting together a No-Intro.org romset for the TI-99/4A. To do this, I need to redump all of the cartridges in a raw format such as .bin. Since a lot of the files on the internet cannot be verified I wanted to reach out to everyone here to see if there was any interest in helping me make this happen. Here is what I have: 1. EEPROM Reader 2. TI-99/4A Computer 3. Approximately 75 cartridges What do I need? 1. I need advice on how to most accurately redump these cartridges into .bin format 2. People to verify my redumps by posting their .bin files so we can compare 3. Volunteers to help bring this collection together for preservation 4. List of all known and released cartridges: no hacks / no custom / no homebrew. What is No-Intro.org? http://no-intro.org/ No-Intro.org TI-99/4A Discussion Thread: http://forums.no-intro.org/viewtopic.php?f=2&t=2789 Please reply to this thread or No-Intro if interested, Steve Quote Link to comment Share on other sites More sharing options...
+arcadeshopper Posted October 29, 2016 Share Posted October 29, 2016 1: they are already all dumped in lots of formats 2: most carts from TI are GROM which you can't read with any burner most 3rd party carts are ROMS which are all available already 3: see 1 4: http://atariage.com/forums/topic/241978-ti-994a-resources-lists-updated-full-cartridge-list/ Greg Quote Link to comment Share on other sites More sharing options...
+Ksarul Posted October 29, 2016 Share Posted October 29, 2016 (edited) Your set is short a lot of information. I don't see the Scott Foresman cartridges in your list, nor do I see any of the smaller software houses in the US (there were several you missed here), European releases (yes, there were quite a few of these), and Argentine releases (yes, there were a few of these too). I'm still trying to determine if there were any actual Japanese-only releases as well, since I have found hardware configured for that market. I maintain one of the most complete lists of what is out there from the time TI was still available in the commercial market (up until the middle of the 1990s). Klaus and Ciro also have excellent references that cover things in Europe along with a lot of the US material, and there is a eautiful site down in Argentina that covers much of what was available there (Antiquario Digital, IIRC). Edited October 29, 2016 by Ksarul 3 Quote Link to comment Share on other sites More sharing options...
stevetb Posted October 29, 2016 Author Share Posted October 29, 2016 The problem with the current roms I see for the TI-99/4A is that they are all unverified and are not consistent. The No-Intro team will not accept these previous dumps. There should also be one standardized file format used in their preservation. -Steve Quote Link to comment Share on other sites More sharing options...
stevetb Posted October 29, 2016 Author Share Posted October 29, 2016 (edited) What is the best way to extract the GROM cartridges? Is there a device I could purchase or make for this? If I could find such a device, I could then verify against images I find to confirm. Then we may be able to submit to No-Intro. Thank you for your help! Edited October 29, 2016 by stevetb Quote Link to comment Share on other sites More sharing options...
Tursi Posted October 29, 2016 Share Posted October 29, 2016 You'll have trouble with the standardized ROM format, we've all taken a few stabs at coming up with a consensus there. The two most common would be raw files (usually with extensions like "C.BIN", "G.BIN", etc, which reflect the contents) and MESS RPKs (which are ZIPs, sometimes with additional info inside). One of the MESS formats is probably your best bet, since it's documented and a single file. GROMs are similar in concept to modern serial EEPROMs -- they have an internal address counter and are read by setting an address and then reading back sequential bytes. (The biggest difference is they have a parallel 8-bit bus). I don't think there are any standard chip readers than can do them, though they are very simple and a reader is not terribly complicated. I'm not sure about unverified - we have a few historians like Ksarul who work to ensure the data they are collecting is valid. What defines "unverified" in this syntax? 2 Quote Link to comment Share on other sites More sharing options...
stevetb Posted October 30, 2016 Author Share Posted October 30, 2016 The lack of a standard could be a problem. For similar systems on No-Intro I have seen the .bin format used. The previous files I have found here are all in .bin format. But you are probably more versed in what is the best format possible so the MESS RPK in ZIP may be best. But........I'm open to the advice of the masters here! On the matter of unverified. The No-Intro team has a set of standard tools & devices used to extract roms and place them into romsets. This allows "Joe Blow" to pickup hardware and the cartridge and then receive the same hashes as someone on the other side of the world with the same cartridge version. It's repeatable and accurate. Hopefully someone can chime in here about how best to extract the information on each cartridge for preservation. Quote Link to comment Share on other sites More sharing options...
+Ksarul Posted October 30, 2016 Share Posted October 30, 2016 The biggest problems you will run into are the significant differences between the ROMs and the GROMs in various cartridges. The ROMs are generally 8K each, but there could be up to four banks in a cartridge (and I believe one even had eight banks off the top of my head). Then the cartridges could have up to five GROMs (sometimes alone, and sometimes in a mix with the ROMs). Groms were almost always only 6K, but a few of them were also 8K. Sideport cartridges were even stranger, even though they only used ROM. Some occupied the 32K memory space mormally used for system RAM, and others were partially in that space and partially in the DSR (Device Support Routine, basically plug-and-play) space. Note also that several of the sideport commercial releases are rarer than any of the homebrews, but they were actually released. Several of us have most of them. As noted, the best standard for cartridge dumps are the MESS libraries, as Michael Zapf has gone to great lengths to make sure he has valid dumps of the cartridges there (this is a work in progress, as not all of them are right yet). Quote Link to comment Share on other sites More sharing options...
+arcadeshopper Posted October 30, 2016 Share Posted October 30, 2016 "Joe Blow" is going to have to build something to do that with GROM carts.. GROMS are the size of a 16k RAM chip physically btw.. The only EASY way to pull ROM and GROM images from carts that go into a cart port is with a GRAM KRACKER which produces a standardized format for both types of images. It however is quite rare and I know about 3 of us that have one, and it hasn't been manufactured since the mid80s. And some carts have both ROM and GROM such as Extended Basic. Greg 1 Quote Link to comment Share on other sites More sharing options...
+jedimatt42 Posted October 30, 2016 Share Posted October 30, 2016 "Joe Blow" is going to have to build something to do that with GROM carts.. GROMS are the size of a 16k RAM chip physically btw.. The only EASY way to pull ROM and GROM images from carts that go into a cart port is with a GRAM KRACKER which produces a standardized format for both types of images. It however is quite rare and I know about 3 of us that have one, and it hasn't been manufactured since the mid80s. And some carts have both ROM and GROM such as Extended Basic. Greg The Geneve tool CSAVE works as well, and from a Navarone cartridge expander, you load the CSAVE utility with Editor Assembler, slide the expander switch to the cartridge to dump, and tell it to save. Mainbyte.com suggests they dump cartridges the same. And then there is this schematic for a grom reader that is used from a PC, don't know if it was ever applied by anyone: http://www.unige.ch/medecine/nouspikel/ti99/gromread.htm Regarding finding mostly .bin files here... Most of those are for new era ROM cartridge designs. Many of the .bin files that seem to be for old titles are indeed the opposite of what something like no-intro.org would want, as many are repacked to run classic titles in different address spaces. A .bin doesn't distinguish what kind of hardware the data was supposed to reside in. For that the .rpk format seems like the best thing we've got, as it contains raw binary dumps, and a meta-data file to describe those devilish details. -M@ Quote Link to comment Share on other sites More sharing options...
+Ksarul Posted October 30, 2016 Share Posted October 30, 2016 Note that CSAVE has one disadvantage from the standpoint of No-Intro's mission: it overdumps. All of the output is in 8K blocks, padded to the full 8K if the code inside the chip is less than that. You'd have to take a hex editor and remove the overdump pieces, which pretty much defeats the pristine, unmodified characteristics they are looking for. 1 Quote Link to comment Share on other sites More sharing options...
+jedimatt42 Posted October 30, 2016 Share Posted October 30, 2016 Note that CSAVE has one disadvantage from the standpoint of No-Intro's mission: it overdumps. All of the output is in 8K blocks, padded to the full 8K if the code inside the chip is less than that. You'd have to take a hex editor and remove the overdump pieces, which pretty much defeats the pristine, unmodified characteristics they are looking for. Good to know! Thanks... -M@ Quote Link to comment Share on other sites More sharing options...
+mizapf Posted October 30, 2016 Share Posted October 30, 2016 Hi there, I'm back ... I was AFK for a week on Lanzarote - and now I have to catch up with all postings here. I already started with a response, but I got a bit confused by the relation of no-intro.org and clrmamepro. We have the dumps (many of them verified by CRC16 checksum) with the checksums and SHA1 fingerprints inside MAME. Can't this be taken from the ti99_cart.xml file? 2 Quote Link to comment Share on other sites More sharing options...
RickyDean Posted November 1, 2016 Share Posted November 1, 2016 "Joe Blow" is going to have to build something to do that with GROM carts.. GROMS are the size of a 16k RAM chip physically btw.. The only EASY way to pull ROM and GROM images from carts that go into a cart port is with a GRAM KRACKER which produces a standardized format for both types of images. It however is quite rare and I know about 3 of us that have one, and it hasn't been manufactured since the mid80s. And some carts have both ROM and GROM such as Extended Basic. Greg Count mine, that might be "4". Quote Link to comment Share on other sites More sharing options...
atrax27407 Posted November 1, 2016 Share Posted November 1, 2016 The HSGPL card works as well. 1 Quote Link to comment Share on other sites More sharing options...
+mizapf Posted November 1, 2016 Share Posted November 1, 2016 Dump preservation as done in MAME means to keep one dump file per chip, together with crc16 and sha1. Thus a GROM has a 6 KiB file, not 8 KiB (we still do not know the internal organisation precisely). The ROMs in the TI console are given as two files, one for the even addresses, one for the odd addresses. As an example, for Extended Basic we have one file of 4 KiB, one file of 8 KiB (containing the two 4K banks), and 4 GROM files with 6 KiB each. The advantage is that we can now verify the ROMs for their integrity by the CRC16 checksum that is added at the end of many ROM chip contents (not all). This is the way the Extended Basic cartridge is specified in MAME right now: <software name="exbasic"> <description>Extended Basic</description> <year>1981</year> <publisher>Texas Instruments</publisher> <info name="serial" value="PHM 3026"/> <info name="version" value="110"/> <info name="comment" value="Common version"/> <part name="cart" interface="ti99_cart"> <feature name="pcb" value="paged12k"/> <dataarea name="grom" size="0x8000"> <rom name="phm3026g3.bin" size="0x1800" crc="ce50e197" sha1="afd414eb29531de9411a959e3641534b8ac7faa5" offset="0x0000" /> <rom name="phm3026g4.bin" size="0x1800" crc="71f702c4" sha1="39224e621e227b1d491c1502437801c20bff33cd" offset="0x2000" /> <rom name="phm3026g5.bin" size="0x1800" crc="5510d76e" sha1="035477a5ca09b0efe0dfa051d815f60db9962fc2" offset="0x4000" /> <rom name="phm3026g6.bin" size="0x1800" crc="8621e071" sha1="6c9b195322f068c1529bbe9dfdab969d2bcc5712" offset="0x6000" /> </dataarea> <dataarea name="rom" size="0x4000"> <rom name="phm3026c.bin" size="0x1000" crc="ac56064f" sha1="d4a6afa628adf45f585b1368bd682d91d223e838" offset="0x0000" /> <rom name="phm3026d.bin" size="0x2000" crc="95ed1f1a" sha1="1accb0e4d071ba8f47b6f5d4c21a0a6a030fac9d" offset="0x2000" /> </dataarea> </part> </software> This format is superior to the RPK description that we've been using until now, and my plans are to replace the RPK format by this one also for homebrew and WIP cartridges. 2 Quote Link to comment Share on other sites More sharing options...
RXB Posted November 2, 2016 Share Posted November 2, 2016 Note that CSAVE has one disadvantage from the standpoint of No-Intro's mission: it overdumps. All of the output is in 8K blocks, padded to the full 8K if the code inside the chip is less than that. You'd have to take a hex editor and remove the overdump pieces, which pretty much defeats the pristine, unmodified characteristics they are looking for. Many years ago we had a Standards meeting and even in 1990 I said the standard for GROM should be 8K and just have 2K just unused or can be modded. When you set a standard for 6K then all the 8K versions are screwed like XB or many other modifed carts were back when Miller Graphics modded many carts for user preferences. A perfect example is Boot used to be a common feature stuffed into that extra 2K space. 2 Quote Link to comment Share on other sites More sharing options...
+jedimatt42 Posted November 2, 2016 Share Posted November 2, 2016 Many years ago we had a Standards meeting and even in 1990 I said the standard for GROM should be 8K and just have 2K just unused or can be modded. When you set a standard for 6K then all the 8K versions are screwed like XB or many other modifed carts were back when Miller Graphics modded many carts for user preferences. A perfect example is Boot used to be a common feature stuffed into that extra 2K space. I think the motive here is for the standard to be truthful... If it is a 6k grom, produce a 6k file, if it is an 8k grom, produce an 8k file. -M@ Quote Link to comment Share on other sites More sharing options...
RXB Posted November 2, 2016 Share Posted November 2, 2016 (edited) I think the motive here is for the standard to be truthful... If it is a 6k grom, produce a 6k file, if it is an 8k grom, produce an 8k file. -M@ Hmm the idea was to have a Standard. What if you have two sizes for the same thing? Give me a medium Coke, but it is 20% larger then the cup! See now you have a problem just like 8K will not fit into 6K of space. Again STANDARDS keep you out of trouble. The larger size should be the standard as wasted space is less of a hassle then NO SPACE LEFT! Edited November 2, 2016 by RXB 1 Quote Link to comment Share on other sites More sharing options...
+jedimatt42 Posted November 2, 2016 Share Posted November 2, 2016 Hmm the idea was to have a Standard. What if you have two sizes for the same thing? Give me a medium Coke, but it is 20% larger then the cup! See now you have a problem just like 8K will not fit into 6K of space. Again STANDARDS keep you out of trouble. The larger size should be the standard as wasted space is less of a hassle then NO SPACE LEFT! Our program-image file standards are nice in that they all have bytes that describe the length of the data. A standard that included meta-data removes assumptions. That keeps you out of even bigger trouble. -M@ Quote Link to comment Share on other sites More sharing options...
RXB Posted November 2, 2016 Share Posted November 2, 2016 (edited) Our program-image file standards are nice in that they all have bytes that describe the length of the data. A standard that included meta-data removes assumptions. That keeps you out of even bigger trouble. -M@ So wasted space is a bigger problem then not enough space? This thinking has led to a real lack of new GROM modules that can utilize 8K and also why all the versions of 8K are not in use. Basically your way of doing this has resulted in a minimization view that leads to older only modules and newer being restricted in use. That is fine for ROM as hardly any use 4K or 6K but 90% use 8K, meanwhile GROM has been handicapped on purpose to 6K only. Edited November 2, 2016 by RXB Quote Link to comment Share on other sites More sharing options...
+Ksarul Posted November 2, 2016 Share Posted November 2, 2016 Rich, what is being done by No Intro has nothing to do with Standards for day-to-day use. It has everything to do with reading the contents of a ROM or a GROM and outputting exactly what is in there, without padding empty space that people like you can use for modifications and enhancements. It is all about the true contents of the cartridge, as manufactured by the original OEM. If you want to use an expanded version for modding, that is perfectly fine--but that modded version is no longer the OEM version, and can no be validated as such by the hash On Intro provides publicly. It is all about keeping track of the original code. . . 2 Quote Link to comment Share on other sites More sharing options...
stevetb Posted November 5, 2016 Author Share Posted November 5, 2016 Ksarul, you are exactly right. The No-Intro team is all about standardization and preservation. They want everything redumped and verified so we can accurately preserve this platform. 1 Quote Link to comment Share on other sites More sharing options...
stevetb Posted November 5, 2016 Author Share Posted November 5, 2016 Hi there, I'm back ... I was AFK for a week on Lanzarote - and now I have to catch up with all postings here. I already started with a response, but I got a bit confused by the relation of no-intro.org and clrmamepro. We have the dumps (many of them verified by CRC16 checksum) with the checksums and SHA1 fingerprints inside MAME. Can't this be taken from the ti99_cart.xml file? The relationship between No-Intro.org and ClrMamePro is that the No-Intro DAT files are created and maintained for each platform. ClrMamePro was simply the best tool to use this DAT to compare against the romset. It is such a versatile and powerful tool for preservation. Quote Link to comment Share on other sites More sharing options...
stevetb Posted November 5, 2016 Author Share Posted November 5, 2016 I think the motive here is for the standard to be truthful... If it is a 6k grom, produce a 6k file, if it is an 8k grom, produce an 8k file. -M@ Exactly, no underdumps or overdumps. Just perfect redumps. Quote Link to comment Share on other sites More sharing options...
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.