Building your own carts

[Tursi]

The Super Space II uses CRU-based bank switching. I assume that the cartridge ripper must modify the code of non-CRU banked cartridges. If I wanted to start playing with cartridge building using the Super Space, then I would have to worry about differences in bank switching and compatibility with emulators. Without me asking any specific questions, what are your thoughts on this?

I am not sure what cartridge ripper you are talking about.... nor am I familiar with the status of Super Space emulation on other emulators. Someone else, maybe?

[+OLD CS1]

I am not sure what cartridge ripper you are talking about.... nor am I familiar with the status of Super Space emulation on other emulators. Someone else, maybe?

 

Super Space I and II include a program which will rip a cartridge ROM, provided you can insert the cartridge without resetting the computer. The instructions recommend either a piece of tape over pin 1 or a switcher like the Navarone. Once it rips the cartridge, you can load it into the Super Space and it will present in the menu like the original cartridge. It has either 8k or 32k, the latter using a CRU-based bank switching mechanism. So ripping a cartridge with more than 8k ROM would require some kind of bank switching, though I doubt the ripper anticipates that and may have a maximum ROM size of 8k.

 

That notwithstanding, I suppose (thinking out loud, kind-of) that if I wanted to create cartridges using the Super Space as a development platform I would have to either write code which can detect which bank-switching system it resides, or have a section of code specifically for each environment. Of course, that is assuming anything I create would require more than 8k.

[matthew180]

... Did he also design a boat? Where do you plug it in? Seriously, did you buy assembled boards or did you have to solder them? Where did you get the 379 chips from? Which EPROM did you use? ...

When I did cart boards they came assembled, but I used the same company that Jon originally used. However, they are not very complicated to assemble yourself if you are comfortable soldering through-hole parts.

 

For the 379 chips I had to order a quantity of 300 from one of those "part suppliers" that dominate any Google search of part numbers. I found one with some "new old stock" and I had to buy all of them. I have about 200 left and sell them on my web store. Anyone who orders has received about triple the quantity they paid for...

 

If you are going to make carts for sale, I recommend you DO NOT use a UV EPROM. They are expensive and problematic. You can get a One-Time Programmable (OTP) version of the EPROM without the UV window (which is why it is "one time", you can't erase it) in a plastic package (vs the ceramic package) for a fraction of the cost. The OPT PROMs are still being made which is also a good thing.

 

http://www.digikey.com/product-detail/en/AT27C256R-70PU/AT27C256R-70PU-ND/1008551

 

Maybe you can find this part from a European distributor.

 

... I have read the the 379 chips can start up in any state, which is why you need the header and start up code in every bank. This is really annoying if you data segments are exactly 8K. Is there anything you can do about that?

It is annoying, as is a cart board that requires obsolete parts. I developed an alternative called the "Bank Switch MINI" (http://codehackcreate.com/archives/208), but never went into production with it (I started working on the F18A.) I used a programmable logic IC to replace the 379 and also used a more modern EEPROM (flash-based) chip so you do not have to go through the trouble of using UV EPROMS.

 

After making the F18A I've been kicking around cart ideas since I still think there is a need for an inexpensive way for people to distribute software in cartridge format.

[+acadiel]

 

Thank you for the answer. It's really exciting that I could improve the game by putting it in a cartridge. I have read the the 379 chips can start up in any state, which is why you need the header and start up code in every bank. This is really annoying if you data segments are exactly 8K. Is there anything you can do about that?

 

Yes, the startup code is very annoying. However, I've only used it for >8K projects, and it probably isn't required if you can figure out what a particular "batch" of logic chips is using as its normal power up bank (even though it isn't defined).

 

I've found that although the 379's do not have a defined startup state, most of them typically will either start in the first or last bank, depending on the batch. In the 49F040 512K cartridge board, the 378's likely also start in one particular bank, usually the first (startup is in a certain state because of either all 0's or 1's on the outputs). Since the LS379 is using inverted outputs, then, typically the last bank that comes online (all 1's probably), and the 378 is non inverted, so the first bank comes online (all 0's probably). This is how the multicart that Tursi and I worked. We had the multicart logic in the bank where the logic chip appeared to power up and then it was always the first option in the menu selection screen. We had the 8K ROM games in the different banks without any additional headers or such, because the Multicart program logic took care of all the copying, branching, etc.

[Tursi]

 

Super Space I and II include a program which will rip a cartridge ROM, provided you can insert the cartridge without resetting the computer. The instructions recommend either a piece of tape over pin 1 or a switcher like the Navarone. Once it rips the cartridge, you can load it into the Super Space and it will present in the menu like the original cartridge. It has either 8k or 32k, the latter using a CRU-based bank switching mechanism. So ripping a cartridge with more than 8k ROM would require some kind of bank switching, though I doubt the ripper anticipates that and may have a maximum ROM size of 8k.

 

That notwithstanding, I suppose (thinking out loud, kind-of) that if I wanted to create cartridges using the Super Space as a development platform I would have to either write code which can detect which bank-switching system it resides, or have a section of code specifically for each environment. Of course, that is assuming anything I create would require more than 8k.

 

Ah, I understand now! I'm not qualified to say much, but it seems likely that it's intended to rip 8k ROMs -- still, 16k ROMs (like XB (which was technically 12k, yes)) existed and may have been supported if they worked out how to mod the bank switching. One problem I see is that CRU switching takes more code than rom-write switching, since it requires you to change R12, load a work register, do the CRU operation, then restore the original data (if you are changing someone else's program). The Super Space programs I modded to go the other way usually used a subroutine, which made that easier, but XB and many rom-write programs just do it inline, all over the place, since it's just one instruction and usually requires no preparation.

 

I like your idea of autodetect. Assuming that you choose a spot somewhere in memory where data is different between banks, you can just try each method and see which one makes the ROM change.

[Asmusr]

Is it possible to make a 64K battery backed RAM cartridge where you change banks the same way as for the ROM cartridges?

[Tursi]

The 379-based ROM cartridges are bank changed by writing to ROM -- if you put RAM there, you would need a mechanism to differentiate bank switching from RAM writes. Not impossible, and plenty of ways to do it, they all need a little more hardware though. The Super Space uses CRU to switch banks, so it's fine with RAM or ROM.

[Asmusr]

It is annoying, as is a cart board that requires obsolete parts. I developed an alternative called the "Bank Switch MINI" (http://codehackcreate.com/archives/208), but never went into production with it (I started working on the F18A.) I used a programmable logic IC to replace the 379 and also used a more modern EEPROM (flash-based) chip so you do not have to go through the trouble of using UV EPROMS.

Fascinating project. For some reason it made me think of this:

 

 

But I guess it's the other way around. BTW, Did you know that the future in Back to the Future II is 2015? And the present is almost as old as the TI.

[RXB]

GPL would be able to switch ROM or RAM banks without stepping on the RAM in those banks ever.

 

Just write a dinky Assembly program to sit in FAC and ARG RAM from >834C to >836C

 

My SAMS Assembly is only 32 bytes to swap to any bank of SAMS RAM and resides in RXB so this my be a good solution.

[Tursi]

The 379 hardware doesn't support switching banks of RAM without also modifying the content of the RAM, it doesn't matter what language you do it from. You need some additional hardware.

 

You could work around the overwrite by giving up one word per bank in every bank, and always writing your switch commands to the same set of addresses. However, you would /also/ have to deal with the understanding that every write to RAM would also cause a bank switch based on the address -- and I don't think we can even predict which bank your write would end up in, it would depend on the speed of the 379 versus the speed of the RAM chip versus the exact line timing on the cart port.

 

So, you need a little extra circuitry, one way or another.

Edited October 17, 2013 by Tursi

[Asmusr]

What I mean is that it should only switch banks when you write to the first 4 or 8 words that are probably occupied be the header anyway.

[+acadiel]

Here's a great description by Stuart of how the whole process works.

 

http://www.avjd51.dsl.pipex.com/ti/ti.htm#bank_switching

 

Selecting a ROM Bank

To select a ROM bank, a word of data (any data, it doesn't matter) has to be written to a specific address in the >6000 - >7FFF address range. At circuit level, this is what happens:

1. The processor sets up the write address on its address bus A0 - A15. (It also sets the data up on the data bus but that is irrelevant at the moment.) It also brings its MEMEN* signal low - this is not shown in the circuit diagram, but that action in the console brings the ROMG* signal low (assuming the write address is an address in the cartridge address space), so the 74LS379 latch is now 'enabled' - meaning it is outputting signals on its Qx and Qx* outputs and will respond to the clock input.
2. With the address bus now set up, the processor pulses WE* low. This clocks the 74LS379, so whatever binary code the device is seeing on its Dx inputs it presents on it Qx outputs, with inverted signals on the Qx* outputs. Each time the 74LS379 is enabled in the future, this same binary code will be presented on the outputs again until the device is clocked again to latch a (possibly) different binary code.
3. The processor now brings MEMEN* high, which brings ROMG* high to disable the 74LS379, and performs the next instruction.

[Tursi]

What I mean is that it should only switch banks when you write to the first 4 or 8 words that are probably occupied be the header anyway.

 

Yes, but you need a way to write protect those words if it's a RAM chip behind them.

[RXB]

A CRU address would not have all these problem. This discussion is like the one before the SAMS came out.

The opted for a CRU address access as this made for a expandable amount of memory.

[Tursi]

I don't personally like CRU but it does solve the problem. That's probably why Super Space uses it.

[Asmusr]

Yes, but you need a way to write protect those words if it's a RAM chip behind them.

Of course, but I thought the real problem was that the 379 reacts to the lower bits (11-14) of any address. If it was only an issue of write protecting the first words you could just decide to write identical words, like MOV @>6004,@>6004, when you switch banks. In order to prevent bank switching when writing to other addresses you would need logic to determine if any of the other address lines (3-10) are set, and if so prevent the latching.

 

Edit: I see the problem now, when you actually did want to change the first words it would also switch banks, which would make it difficult to set up a cartridge header.

[matthew180]

If you have a RAM bank in a cartridge, *and* you want bank switching, you are simply going to lose part of the RAM that overlaps the addresses used to bank switch. It is not that much really.

[+Ksarul]

Actually, thinking about it--the Wiesbaden Supermodul II does have 4 banks of RAM (and 5 banks of GRAM). It lets you load your code with the memory unprotected and uses a physical switch to write protect it when you want to run it without overwriting it. I may have to ask Sven Dyroff if he'll let me make more of them, as they are a really good development tool. The board isn't too hard, as I have printouts of the original layouts and can redo them in Express PCB. I may want to eliminate the stack of 32Kx8 chips and replace it with a 128Kx8 chip though to make assembly a bit easier. . .even if that does waste a bit of the space because it isn't set up to use additional GROM bases.

[Asmusr]

Actually, thinking about it--the Wiesbaden Supermodul II does have 4 banks of RAM (and 5 banks of GRAM). It lets you load your code with the memory unprotected and uses a physical switch to write protect it when you want to run it without overwriting it. I may have to ask Sven Dyroff if he'll let me make more of them, as they are a really good development tool. The board isn't too hard, as I have printouts of the original layouts and can redo them in Express PCB. I may want to eliminate the stack of 32Kx8 chips and replace it with a 128Kx8 chip though to make assembly a bit easier. . .even if that does waste a bit of the space because it isn't set up to use additional GROM bases.

Yes that would be a really great development tool. I for one would be very interested.

[RXB]

Well a GPL option that no one has mentioned is to load a GPL program that does the CRU switching of RAM then return.

 

It would be easy to use just 64 bytes of the video on screen area for this and not affect the program as it could copy and replace what was used from RAM or Fast RAM.

 

GPL is very compact and can run from VDP or GRAM or GROM with no effects on any bank of RAM and combined with a CRU switch using the IO command in GPL would be dinky and fast.

 

This is the code for CRU on the SAMS in RXB that GPL loads in Fast RAM then does a XML :

******************************************************
<0173>               * CPU PROGRAM FOR >8300 SCATCH PAD SUBROUTINE AMSCPU *
<0174>               ***********************************************************
<0175>               *                 *        AORG >8300
<0176> D2A5 83,02    AMSCRU DATA >8302 * CPUPGM DATA >8302      * First address.
<0177> D2A7 04,20           DATA >0420 *        BLWP @AMSCPU    * Switch contex
<0178> D2A9 83,0C           DATA >830C *
<0179> D2AB 04,E0           DATA >04E0 *        CLR  @>837C     * Clear for GPL
<0180> D2AD 83,7C           DATA >837C *
<0181> D2AF 04,5B           DATA >045B *        RT              * Return to GPL.
<0182>               ******************************************************
<0183>               *                 * AMS CPU SUBPROGRAM
<0184> D2B1 83,4A           DATA >834A * AMSCPU DATA >834A
<0185> D2B3 83,10           DATA >8310 *        DATA AMSCRU
<0186> D2B5 02,0C           DATA >020C * AMSCRU LI   R12,>1E00
<0187> D2B7 1E,00           DATA >1E00 *
<0188> D2B9 1D,00           DATA >1D00 *        SBO  0
<0189> D2BB 03,80           DATA >0380 *        RTWP
<0190>               ***********************************************************
<0191>               *                 *        END
<0192>               ******************************************************

Here is the GPL program that loads and runs that Assembly:

<0166> D294 06,D2,9E AMSON  CALL AMSSUB
<0167> D297 BF,14,1D        DST  >1D00,@STORE
       D29A 00
<0168> D29B 0F,F0           XML  >F0
<0169> D29D 00              RTN
<0170> D29E 31,00,18 AMSSUB MOVE 24,G@AMSCRU,@>8300
       D2A1 00,D2,A5
<0171> D2A4 00              RTN

I forgot the variable STORE:

STORE EQU >8314

>1E00 in STORE puts AMS card in Off mode so 32K is like normal TI memory with mappers off.

>1D01 in STORE puts AMS card in Map mode default map of RAM

>1E01 in STORE puts AMS card in Pass mode so acts like normal TI memory but the card is on

>1D00 in STORE puts AMS card in On mode so Map pages can be loaded.

Edited October 18, 2013 by RXB

[Asmusr]

I received a small shipment of 64K boards today from http://imall.iteadstudio.com/

 

 

Beautifully made with perfect fit, blue finish, silk screen layer and plated though holes. And at $35 for 12 PCBs I think it was a real bargain (the cost was more like $100 including shipping, customs and tax, but you can't blame the company for that).

 

I don't have any EPROMS yet, but hope to get some within a few days. Can't wait to insert my first command module...

[Stuart]

I received a small shipment of 64K boards today from http://imall.iteadstudio.com/

Rasmus, did they produce it from the ExpressPCB format files, or Gerber?

[Asmusr]

Rasmus, did they produce it from the ExpressPCB format files, or Gerber?

 

From Gerber. Only thing I had to do was change the file name extensions of Jon Guidry's files.

[RXB]

If you have a RAM bank in a cartridge, *and* you want bank switching, you are simply going to lose part of the RAM that overlaps the addresses used to bank switch. It is not that much really.

 

 

That is 100% correct and why I suggest GPL run from VDP as that way you can switch and not sacrifice any RAM .

 

This accomplishes two things:

1. No RAM needed to be used to switch banks.

2. CRU based so you get a write protect on or off and you can use the same thing for switching banks with no sacrifice of RAM or BANKs wasted.

[Stuart]

 

From Gerber. Only thing I had to do was change the file name extensions of Jon Guidry's files.

Are all your boards spoken for, or is there a chance of acquiring one? Happy to pay the going rate plus shipping to the UK. Either a built-up board if you've already bought all the parts, or a bare board.

 

Stuart.