acadiel

Thanks, guys! I'll revise the documentation based upon your recommendations and send it over to Ksarul I'll also add the part about the D4/D5 lines and another set of tables for the non inverted outputs.

I think that Ksarul put an invert jumper in there for the new GAL, if I'm not mistaken, but he'll have to chime in.

Legacy use. I found that most of the 16K ROM carts out there (i.e. DataBiotics) used it, so that's what I used.

I'm working to write a description of how the bank switching scheme works in the 512K cart. I wanted to run this by everyone to make sure I'm understanding it correctly so that there are no mistakes... (I've attached a 74LS379 block diagram for reference, so we'll use it. I'll add the extra D4 and D5 lines to my final description for the 512K bank switch cart when I'm done.) 1) When we set up TI A0-A15 (the address lines) to read/write to the cartridge address space (>6000->7FFF), cartridge board pin #34 (ROMG*) is made LOW). If we are not read/writing from that space, it is HIGH by default. This is connected to E* (pin #1) on the 74LS379. 2) E* (pin #1) on the 74LS379 is enabled by bringing it LOW. Since ROMG* is connected to E*, when ROMG* is made LOW (i.e. cartridge ROM space is being accessed), this enables the 74LS379. 3) When enabled, the 74LS379 is now outputting data on it's *Q0 - *Q3 outputs (pins #3, #6, #11, and #14). By default (this behavior is not defined and there is no standard here), we get 1111 on those inverse outputs. (These are hooked up to A14, A13, A12, and A11 on the TI. A15 is not used because ??) 74LS379 (Active, Enabled, Power-up [Typical)] Any write from 0110 0000 0000 0000 (>6000) to 0111 1111 1111 1111 is valid to bring *E low. *ROMG A11 A12 A13 A14 A15 (TI PINS) || || || || || || L 0 0 0 0 0 (TI PIN VALUES) || || || || || || |==============================| | /\ /\ /\ /\ /\ /\ | |*E D3 D2 D1 D0 n/a |(74LS379 PIN INPUTS) | || || || || || || | |n/a *Q3 *Q2 *Q1 *Q0 LSB |(74LS379 PIN OUTPUTS) | \/ \/ \/ \/ \/ \/ | |==============================| || || || || || || n/a 1 1 1 1 n/a (74LS379 OUTPUT VALUES) || || || || || || n/a A16 A15 A14 A13 n/a (EPROM address lines) 4) When we *write* to the cartridge ROM address space, cartridge board pin #32 (WE*) is made LOW (It's normally active high). This is hooked up to the CP pin (#9) on the 74LS379. (Can someone explain how this whole CP thing works?) 5) When CP is LOW, this "clocks" the 74LS379. Whatever the 74LS379 is seeing on its D0-D3 (pins #4, #5, #12, #13) inputs (which is't getting from TI A11-A15), out puts the inverse output on EPROM A13-A16. So, on a 128K EPROM, writing to the following addresses will do the following: Address TI A11-A14 379 output, EPROM A13-A16 >6000 0000 1111 >6002 0001 1110 >6004 0010 1101 >6006 0011 1100 >6008 0100 1011 >600A 0101 1010 >600C 0110 1001 >600E 0111 1000 >6010 1000 0111 >6012 1001 0110 >6014 1010 0101 >6016 1011 0100 >6018 1100 0011 >601A 1101 0010 >601C 1110 0001 >601E 1111 0000 6) Let's look at this from an EPROM point of view with the above outputs from step #5: 128K EPROM has address space >0000->1FFFF A16 A15 A14 A13 A12-A0 8K #1 1 1 1 1 1111111111111-0000000000000 (>1E000->1FFFF) 8K #2 1 1 1 0 1111111111111-0000000000000 (>1C000->1DFFF) 8K #3 1 1 0 1 1111111111111-0000000000000 (>1A000->1BFFF) 8K #4 1 1 0 0 1111111111111-0000000000000 (>18000->19FFF) 8K #5 1 0 1 1 1111111111111-0000000000000 (>16000->17FFF) 8K #6 1 0 1 0 1111111111111-0000000000000 (>14000->15FFF) 8K #7 1 0 0 1 1111111111111-0000000000000 (>12000->13FFF) 8K #8 1 0 0 0 1111111111111-0000000000000 (>10000->11FFF) 8K #9 0 1 1 1 1111111111111-0000000000000 (>0E000->0FFFF) 8K #10 0 1 1 0 1111111111111-0000000000000 (>0C000->0DFFF) 8K #11 0 1 0 1 1111111111111-0000000000000 (>0A000->0BFFF) 8K #12 0 1 0 0 1111111111111-0000000000000 (>08000->09FFF) 8K #13 0 0 1 1 1111111111111-0000000000000 (>06000->07FFF) 8K #14 0 0 1 0 1111111111111-0000000000000 (>04000->05FFF) 8K #15 0 0 0 1 1111111111111-0000000000000 (>02000->03FFF) 8K #16 0 0 0 0 1111111111111-0000000000000 (>00000->01FFF) This means that the "low bank" (>6000) is actually your upper 8K. and the "high bank" (>601E) is at the very bottom of the EPROM address map. 7) (Not sure): When our read/write to the cartridge ROM address space is finished (i.e. the TI is talking to something else not in the cart space), E* (pin #1) on the 74LS379 is disabled by bringing it HIGH. Since ROMG* is connected to E*, when ROMG* is made HIGH (i.e. cartridge ROM space is not being accessed), this disables the 74LS379 from putting anything on its outputs to the EPROM address lines. (What exactly DOES happen, then, to those EPROM address lines?) Hope this helps those who need help understanding bank switching, and hope that I can get some of the clarifications that I need in here (like how CP works, and my other questions I put in parenthesis). Thanks, all!

Does anyone have all the op codes documented in order of op code?

That would read: it looks like there are several 74LS logic chips, a GROM, two 2114 (512 byte) RAMs, and the ROM (can't find any specs on it.) Where is the GROM located ? I'm guessing the CD5256 chip is GROM. The other five on the right are 74LS logic chips, and on the left is the ROM and the 512byte x 2 RAM.

Apparently, it looks like there are several 74LS logic chips, a GROM, two 2114 (512 byte) ROMs, and the ROM (can't find any specs on it.) Look at page 8, here. It states how MBX carts work: http://pdf.textfiles.com/zines/MICROPEDIUM/mp970304.max.pdf "The MBX method is a semaphore method to switch the ROM bank. You write the bank number directly to location >6FFE. In any MBX module, you will find a RAM of 256 bytes. (Why is there 1K in this one?) This is decoded to ROM location >6C00 through >6FFF. So you can read back the bank number from this RAM, because it will be written in parallel to the switching register. Nice feature, but incompatible with all other banking methods. This is the reason, other programs will not correctly read out the ROM banks of MBX modules. You have to write 00, 01, 02, or 03 to the banking register." Also, here: http://tech.groups.yahoo.com/group/ti99-4a/message/3078?threaded=1&var=1&p=2 MBX banking seems to keep >6000-6FFF static, while banking >7000-7FFF. The Gramulator accomplishes this with 20K of RAM, which I take to mean byte 1 values of >0B-0E make bytes 4,5 the value >7000. I am not sure how MBX banking works. BTW, here are all the MBX carts dumped (HSGPL format) as well as some example code used to generate the headers for them. There aren't any other places on the 'net that have these, so I'm sharing the wealth... All of the carts are here except 3154 (Terry Turtle's Adventure). Also, PHM 3149 (Space Bandits) doesn't work. I don't think it has the proper header, because it loads as an autostart cartridge. I haven't tried these in MESS with the HSGPL yet, but on a real HSGPL, to get these to work, all I did was this: Load the files into bank >10 reset Go into TI BASIC CALL GRAM CALL MBXON bye mbx.zip

They don't show under emulation (I tried Ambulance), suggesting it's not a pure software approach. Does anyone have pictures of inside one of these carts? I think they eventually were licensed to use GROMs (were they the only "official" one other than Parker Brothers?) Lobster Bay and some of their non released games are in GROM format (not ROM) - I tried putting some of these in a ROM cart, that's why I know. They did include this letter with some games, which makes me wonder if they re-did some games to run from GROM: http://www.videogamehouse.net/funwarenotice.jpg

Can a dead 99/4A non 2.2 console have the GROM0 taken out of it and put in the V2.2 one?

Arcturus (sidecar) did that. When I dumped it, I found it actually lived in the Powerup DSR space and in the >A000 memory expansion space. The power up DSR took over at the title screen. Tursi helped with converting it into an EA/5 executable which we dumped in a module with the "copy to >A000 RAM and run routine". I think it helped that it was already coded to run in >A000. Attached is the original dump, including the >4000-5FFF DSR ROM. Maybe it'll have something you could use. arcturus-dump.zip

Yep, 128K (and the current layout) keeps things nice, neat, and on one page for each "Multicart" No new coding needed! <g> I'll make the changes you noted above and give it a try and see how it works with the 512K flash once I get the new board in, get the GAL programmed, etc. The only thing I'm scratching my head over - 5FFE? (It's probably right in front of me, but I'm kind of stumped about the -2). Edit: Can Classic99 bank switch 512K yet? I can just put the modified code in there before I get the board to make sure it works like I want...

Well, what I was thinking is just daisy chaining Multicart as a workaround just to make sure the banking is working properly for testing the new board (until you get time to recode). You start by scanning all banks starting at >601E (I think) and working your way down to >6000. A simple change to the source, and I can tell the power up Multicart to include another Multicart at the bottom of that first "128K segment" (instead of ignoring it) as the last menu item on the show up on Multicart. The second Multicart would simply scan the next 128K range, and have a Multicart at the bottom for the third one, and so on. I would have have to change the >AA71 header on subsequent MultiCart programs so that they show up, and just change the range (starting at >601E and below, >603E, >605E, and >607E). First 128K segment: >6000 Multicart (modified header so shows up, points to Multicart at >603E) >6002 .... >601C >601E Multicart (power up bank) Second 128K segment: >6020 Multicart (modified header, points to Multicart at >605E) >6022 .... >603C >603E Multicart (modified to scan this 128K range, >603E to >6020) Third 128K segment: >6040 Multicart (modified header, points to Multicart at >607E) >6042 .... >605C >605E Multicart (modified to scan this 128K range, >605E to >6040) Fourth 128K segment: >6060 Multicart (modified header, points back to Multicart at >601E) >6062 .... >607C >607E Multicart (modified to scan this 128K range, >607E to >6060) Thoughts?

Can Multicart be enhanced to use the RAM to buffer the whole 40 something 8K ROM carts without switches now? (I think you said it was tight with the VDP scratchpad, so can we can offload it to the AVR now?)

Ah, that explains things - the RAM is for the AVR itself, not for our usage Still, GROM/GRAM and EEPROM probably would give us a whole heck of a lot. Imagine Owen making a super mega Beryl RPG :)

(The Atmel chip, that is)

Oh yeah, and it does have 16K of RAM for those of you who have been requesting it. 4K of EEPROM and 128K of flash as well. Not sure how it all will be implemented yet though. Tursi's working on that part

Here's the latest revision that Ksarul has been working on. This is still prototype stuff, guys, and yeah, I don't think you can cram much more on that cart board. Onboard, there is a Lattice GAL16V8, that takes the place of the 74LS379, but lets us bank switch 512K (adds two more sets of I/O lines) in the 49F040 flash ROM. Thanks to Matthew, we have the code needed to burn these, but haven't actually burned one yet. No worries, it should work. Ksarul took the pin output that Matthew provided and used it, so as long as we don't make any changes, the pins should be fine. The ATMega 1284 is the GROM emulation, and you can thank Tursi for that work, he's done a great job, and proved it at last year's TI Faire with his demo. There's a bunch of I/O jumpers to interface with the ATMega, so just about anything is possible. That's a pretty powerful AVR [8 bit RISC] for the machine it's interfacing with! We can do GROM, GRAM, the thing has some EEPROM as well as Flash, you name it... And, also thanks to Ksarul, we have a boatload of 49F040 Flash and GAL16V8's for parts. I'm anxiously awaiting the next prototype board run to see how well it works

I have what was on the WHTech site, plus a lot more I added, including all the ROM ports, such as Arcturus, etc. (Sort by date to see what's new.) rpk.zip Caveat is that they all should be distributed freely, all copyrights belong with the authors, etc. fredcarts-cf2k-dm2k-du2k.rpk cf2k20-final.rpk Miner.rpk Espial.rpk Killer.rpk DU2K20-final.rpk DM2K24-final.rpk Arcturus.rpk tiworkshop.rpk tris2.rpk spacepatrol.rpk facechase.rpk mancala.rpk greatwordrace.rpk dragonflyer.rpk supermodul.rpk pitfall.rpk neverlander.rpk

I'll defer some answers to Tursi and Ksarul. About the F chip - Ksarul got a large (and I mean large) lot for dirt cheap. So that's the story behind that. Don't know Tursi's plan for programming the AVR, but he's got those pins in the front for something. I know that most of the AVR pins needed for programming are being brought to the front of the board. As for jumpers, it's a 512K chip. That's what you get. 512K. Don't know if there are any plans in the prototype to change it. Since Ksarul got such an amazing price on those 49F040's, you can simply fill up the part you need andnleave the rest available. Anyway, I've spilled all the info (or misinformation) that I have right now. And unless I'm wrong, apparently (?) with GROM emulation and the banked ROM, we might be able to use these boards for a new XB. I'll shut up now and let the experts chime in.

Marc, you can thank Matthew for the 512K GAL. He adapted his 379 replacement and just extended it with two more sets of I/o pins. Anyone for making a TI megademo?

You know, Marc... I owe you a few beers in Chicago. JP1 was the culprit. (they didn't have a facepalm smiley) I've been banging my head on this board for quite a many months (try late last year), even sent it home with Tursi from Chicago. +1 for crowdsourcing help on the Internet!!! I soldered Tursi's cap back on, put two switches, reinstalled the 22pf caps, and the thing works beautiful now. You can thank Ksarul for remapping the board and putting a 512K chip on it. The next iteration has a GAL slot instead of the 74LS379 along with the 512K ROM flash. Yes, 512K of bank switchable cart space (not 128k x 4 like this one). I need to buy an ATMega 128 now and have Tursi put E/A and some other GROM-only stuff on it (Demo, whatever - how many can I cram on there with REVIEW MODULE LIBRARY?) and test it out with the ROM installed now. Tursi, do you recommend a particular programming kit for the ATMega stuff for a hobbyist? I found the Mouser URL for what I think is the chip here. I'm excited!!!! (And I need a long vacation. Work is killing me, so I'm surprised I'm still sane.)

Man.. I leave for work this morning and there are no replies, and then come back home from work, and wow.... OK. Here's the deal: No Microcontroller on it right now. Just the 49F040 FEEPROM and the 74LS379. Tursi thinks it might be power draw. As soon as I get more time tonight, I'll reply a little more in depth.

I'm going to try a little crowdsourcing here for the last version of the cart board that Ksurl, Tursi, and myself have been working on. I've attached a zip file with two ExpressPCB files in it - a v4a (which is what the 512K Multicart working version is made from), and a V6d, which makes it a PLCC FEEPROM instead of a DIP EPROM. The V4A board works great - I made around 10 prototype carts with it and an EPROM that Tursi and I worked on (has almost all 8K ROM carts ever made for the TI in it). It works by bank switching 128K x 4 with the help of two switches and Tursi's Multicart program (runs on an unexpanded TI, too!) The V6D board - well, it's been kind of a bear. I've looked at it, Tursi's looked at it, and I don't think we've gotten far in the past year on it. I've flashed multiple AT49F040s on the V6D board with the same binaries that I burned into the 27C040 on the V4A. Verified them multiple times. When I power up the V6D, I can now usually get MULTICART to show up (which means it's doing the right thing and powering up in the last bank), however, I am still getting quite a few lockups. Sometimes, Tursi's MULTICART logo (and "Made by Tursi") show up, and nothing else. Sometimes, I get a lockup and blank screen. Sometimes, I get the MULTICART logo and Made by Tursi as well as a list of around 7 or less programs and then a lockup. Anyone want to take a stab at looking at these files and see what's going on? To me, it seems like a timing issue (something is being taken high/low too fast/slow or possibly data is being delivered too fast/slow). I have a V6D board here, so I'm open to trying whatever with it. The only jumper I have is the one between pins #1-2 of JP2. Also, the AT49F040 has a different pinout in the PLCC32-DIP32 adapter so I can't try the flash chip on a V4A board; however, like I said, it verified multiple times in my 844USB programmer. Thanks, guys! v6d-v4a.zip

Got the replacement jack in from Mouser. The through hole pattern and jack size was spot on. However, the through pins were a little large for the hole in the MBX PCB. Nothing a 3/32" drill wouldn't fix. A quick desolder job, followed by the drill, and then the soldering of the new jack seems to have worked great. I have a spare now too, since they were so cheap (I do have a second MBX somewhere in a box.) I also had to take a cm or so off of the ribbon cable that comes from the keypad matrix on the front of the MBX with some scissors. The contacts weren't making great contact with the board once inserted, even after a good pencil erasing. Still have plenty of slack. The only other thing that I might wind up having to do to get this thing completely working (100%) is make a new cable for it - I think there's a short in one of the DB9 connectors. For right now, the kids are playing "I'm Hiding" again and are ecstatic that it's working properly for once!! I suppose it's time to play with the hybrid GROM/ROM cartridge board now.... :-) Tursi, I'll burn another flash chip and make sure it works and see what happens on the board again. Jon

Man, I am stoked about this... awesome job, Matthew!