acadiel

I'm making this into an actual cart :-)

Hey all - I am assisting the MESS team with getting proper dumps from the CC-40, so we can get a MESS emulation for it operational. We have dumped the eight existing carts (and verified those dumps with a second source who already had them), and have dumped the 2K on processor ROM. What remains is the 32K bank switched system ROM. The CC-40 has 64K address space, much like the TI-99/4A. What's cool is that it exposes half of that space directly to the cartridge slot (>5000 to >CFFF). That cartridge slot also has a bank switch line, so you can get a 64K image in there. Probably because of this design decision, that leaves 32K open for the rest of the memory map, including RAM (18K), system ROM (8K bank switched) and other (6K). So, the system ROM is bank switched in 8K increments, controlled by the routines in the 2K of processor ROM. TI did add a nice "system ROM page select" in the built in debugger, CALL DEBUG. However, they protected it to where it does not actually bank switch (probably to prevent me from trying to do exactly what I'm doing). So, here are my thoughts: My only alternative (other than desoldering the ROM and sending it to someone) is to figure out which register controls the ROM bank switch, write a small assembly program in CALL DEBUG and execute it from the 18K CC-40 RAM, and copy the ROM in 8K segments to a 32K constant memory cartridge, then dump it from the cartridge space. That should be the easiest way to do this without harming any hardware, but I need someone's help. This is where you assembly people come in who can help write a small bank and copy loop, probably not much different conceptually than the cartridge copy to 32K RAM deal we've been doing on the 4A. The difference here is that I'm entering in assembly hex pneumonics on CALL DEBUG and executing them. Any volunteers? This is one of the last things we need for CC-40 emulation!

Tapatalk dupe

The three screw revision is printing out as we speak. Should have it in the next several days. Attached are the files if someone wants to poke around. ticart.pdf tishellv2.zip

I've honestly never tried a powerup header in a ROM cart... Let me know what you find out if you try. Will TI Intern tell us if it scans ROM for auto start as well as GROM?

I can put you in charge of the "hap" person who's going to be working on this. Look for an email.

Found something really interesting while dumping these CC-40 carts (after converting to binary). I essentially dumped the entire 32K memory for each cart, from >5000 to >CFFF in the memory map (straight through). Lee, I believe, dumped the cartridges with an actual programmer. The first 12K of my dumps (out of the 32K) were actually at the BOTTOM of Lee's dumps. In essence, the CC-40 is placing a small bit of primitive copyright protection against using the memory dump method I used to do cartridge dumps by relocating the last 12K of the cartridge to the beginning of the cart memory space when you do a CALL PEEK. Easy solution; take the first 12K of the memory dump method and cut it, and paste it on the end of the ROM image. Then mine matched Lee's dumps. I've attached all of the CC-40 files in my Dropbox if anyone wants them. I have dumps of all of the known cartridges: Advanced EE EA Finance Games 1 Mathematics Memo Processor Pascal Statistics I also have the 2K Mask ROM that lived on the TMS CPU from >F800->FFFF in the archive. The only remaining item is the actual CC-40 32K ROM (which is why I need a halfway functioning one to send to someone to dump). Then, the MESS/MAME people can do their magic and try to get us CC-40 emulation. https://dl.dropboxusercontent.com/u/19597743/ti-99-4a/CC-40%20DUMPS.zip Enjoy! My dump (1K offset) Lee's dump (1K offset) CC-40 Memory Map >0000->0FFF >5000->5FFF >5000->5FFF >1000->1FFF >6000->6FFF >6000->6FFF >2000->2FFF >7000->7FFF >7000->7FFF >3000->3FFF >0000->0FFF >8000->8FFF >4000->4FFF >1000->1FFF >9000->9FFF >5000->5FFF >2000->2FFF >A000->AFFF >6000->6FFF >3000->3FFF >B000->BFFF >7000->7FFF >4000->4FFF >C000->CFFF

Here's what I had to do: 1) I had to get the second ASCII Field by itself: cat cc40_2k_raw.txt | cut -f2 d, >cc40_2k.txt 2) I had to remove the ^M from the newfilename: sed -e "s/^M//" cc40_2k.txt >cc40_2k_noM.txt 3) Ran a convert script on it to concatenate the ASCII: ./convert.sh cc40_2k_noM.txt >cc40_2k.bin Convert script (does all three steps): sh-3.2$ more convert.sh # get rid of first field cat $1 | cut -f2 -d, >${1}.edited sed -e "s/^M//" ${1}.edited >${1}.noM for i in $(cat ${1}.noM) do printf \\$(printf '%03o' $i) done So, did this on the 2K TMS7xxx ROM (yeah, that thing has 2K MASK ROM in it, very easy to get to), and the carts. It also helped someone emailed me copies of the carts to validate what I was doing was correct. EPROM cartridge images for the CC-40 coming soon. The last thing we need is the actual machine's 32K ROM. Then, people can work on emulation

Here's a couple more.... cc40_memoprocessor_5000-cfff-copy1.txt cc40_finance_5000-cfff_copy2.txt cc40_mathematics_5000-cfff.txt Pascal.bin.txt cc40_advanced_electrical_engineering_5000-cfff.txt

I'll plug that in and see what I get... thanks!!! I figured out the 64K E/A cart. I simply have to do a CALL DEBUG, hit "R" for paging, and change to cart page #1 to get the second 32K of the E/A cart. However, this is not persistent once you leave DEBUG (it went back to bank 0). Also, those turds (I'm using a Marc euphemism here) at TI decided to neuter the ROM bank switching in DEBUG. Even though you can page ROM in CALL DEBUG on the CC-40 by hitting R for paging, and hitting the spacebar to get to "Cartridge Page" and even put in a 0-3, you still get the same 8K. I guess they didn't want folks dumping the ROM. The only alternative is assembly on this beast to trigger a bank switch (and copy to a RAM cartridge), or sending it to a ROM guy (which I don't mind, because I really don't feel like learning how to get into this system.) :-) I've attached a good copy of an example output, BTW... in case you get a chance to test it before I do cc40_statistics_5000-cfff_copy1.txt

Thanks, Michael! The guy who's helping me also figured out a way to do it, but he didn't share it with me (yet). He managed to create a binary file directly for me; it looks pretty equivalent to the CALL PEEK and PRINT #1 statements I've been doing (with the exception that the PRINT #1 statements I've been doing have had CR/LFs and some other "record" character in them, so it made a 2048 file to be 8192 bytes.) It's taking approximately 40 minutes to dump a 32K CC-40 cartridge in this manner (with the comma delimited file.) most all of them I've verified so far have been 32K (in the 32K space), with the exception of the E/A one... that one has a 64K EPROM in it. I've been scratching my head on where that one lives, because the entire CC-40 memory map is 64K, and that cart doesn't have a bank switch chip in it... it has to be banking somehow.

Hey guys - Dumping some CC-40 stuff here. For some reason, I'm getting varied results with PuTTY, RealTerm, and ProComm when it deals with RAW ASCII transfers. (For example, I dumped what was supposed to be 2048 bytes as raw, and got 2091. Wasn't CR/LF - so it must have been a terminal translation issue or something.) So anyway, I'm dumping the memory like this: location,ASCII_value So, for the 2K that I dumped, I get something like this: 63488,16 63489,2 63490,193 63491,166 63492,180 63493,10 I can very easily lob the first part off (I did it for sanity purposes) with a "cat file | cut -f2 -d,". So that leaves me with 2048 lines of ASCII values. I'd like to use my Mac/Linux box to essentially go through that file, and do the equivalent of this: for i = 1 to lines in file print chr$(i) >>filename.bin next i So, at the end, I'll have a nice 2048 byte binary image. Anyone have a Perl or Shell script that they can whip up to do this? Thanks!

How are you guys creating these animated GIFs? Built into Classic 99? (I really don't know; I haven't tried looking....)

Yay!! Let me know when you have a test ROM; I'll burn it and try it out

Ok, I will edit it and see how it turns out :-)

Anyone have objections to two more screw holes instead of snaps? :-) Those snaps are a pain....

Have some stuff I need to do... Small error on top half (fixed), and certain parts (clasp) don't hold well, or fall off easily.

We can... but I kind of like Tursi's font, title, joystick selection, etc, in MultiCart. Tursi did use scratchpad and some creative engineering to get it to bank switch and then reset the console (and thus, you saw the selection on the cart screen.) We'd just have to figure out if we could add the copy to 32K functionality in the same constraints, like you mentioned. Tursi, is that on Harmless Lion somewhere? Or do you mind me attaching that to this thread (the source zip)?

Obviously, I'm not paying close enough content to the best practices of websites of today... I just implemented Website compression on http://www.hexbus.com (including the pictures, TI book archive, etc.) The site is markedly more speedy now. Enjoy!

Well, Tapatalk triple posted, and the mods must have accidentally deleted the last remaining thread... Looking for a dead CC-40 (or mostly dead, bad LCD is OK) to send to someone to try and dump the 32K ROM. Please PM me if you have one. Thanks.

I think several of us have "driven the bus" with external GROM devices (aka Gram Kracker, Gromulator, HSGPL, etc) at one time or another to override the console GROMs. I remember someone telling me this is was because the internal GROM 0, 1, and 2 could easily be overridden, although they didn't get into specifics.

We can probably use the MultiCart software (with some defined data statements for the programs instead of the bank n read subroutine) to launch these same EA/5 programs, and put it in one of the first banks in place of the XB ROMs (for powerup), and have an uber EA/5 cartridge too, for those folks using 512K ROM-only carts. I'll have to check out Tursi's source code for MultiCart to see if I can adapt it or not.

Hey everyone. I've let the Internet Archive mirror Ernie's book archive as well. This gives our books a mirror somewhere and puts them out to a wider audience. From what I'm understanding about Archive.org, they probably have leeway as they are an archival site to have them up. The main archive of everything is here: https://archive.org/details/2014-texas-instruments-book-collection They will eventually live here with book covers and everything; https://archive.org/details/tibooks

Also, saw this on ninerpedia: Parsec has some hard coded values and it is expecting to loaded at memory address x9800, which is where GROM base 0 is. You can get Parsec working by loading it into GROM base 0. Buck Rogers and Facemaker have the same problem so you would not be able to load all three into the HSGPL. If you are adenturous you could edit the programs and remove the hard coding. This information came from the SNUG FAQ

I've attached the Gramulator and GramKracker file headers. As you can see, the HSGPL header is a tad different. Credits comes from their respective manuals. Gramulator: ----------- Byte # Description 0 >FF = more to load >00 = last file 1 Destination indicator >00 or >FF Memory Expansion >01 GRAM 0 >02 GRAM 1 >03 GRAM 2 >04 GRAM 3 >05 GRAM 4 >06 GRAM 5 >07 GRAM 6 >08 GRAM 7 >09 RAM Bank 0 >0A RAM Bank 1 >0B RAM Bank 0 (MBX) >0C RAM Bank 1 (MBX) >0D RAM Bank 2 (MBX) >0E RAM Bank 3 (MBX) 2,3 Length of data 4,5 CPU and GROM/GRAM address to move file to and begin execution from (execute EA/5 files only) Gram Kracker: ------------- Byte # Description 0 >FF = more to load >80 = Load UTIL Option next >00 = last file 1 Destination indicator >00 or >FF PROGRAM IMAGE - Load to Memory Expansion >01 GRAM 0 >02 GRAM 1 >03 GRAM 2 >04 GRAM 3 >05 GRAM 4 >06 GRAM 5 >07 GRAM 6 >08 GRAM 7 >09 RAM Bank 0 >0A RAM Bank 1 2 Bytes to load (0000) 4 Address to start loading at (0000) See example in image for XB. HSGPL: ------ Byte # Description 0 Target address (256 byte increments) 1 Load information and additional load bit 2,3 Length of the file (bytes ignored, always loads >2000) 4..>2003 Used data Read information on on how target address is in byte 0 and 1, but additional info is in byte 1. Pretty cool way to use two bytes to determine bank