3 Slot Expansion Card Comments Requested

[brain]

Trying to fill a small gap, I'm working on a 3 slot expansion port solution ala EX-3 or FB-EX3. Here is a first cut of the PCB design:

http://www.jbrain.com/vicug/gallery/xpansion/ext3_d

Comments are appreciated. Some things I'm curious about:

• Is the switch location OK, or do people need them off to the side?
• Does anyone want a top slot for the 3rd slot? or is the back entry desired?
• Any other features besides the existing ones that are desired?

Jim

 

[carlsson]

I'm not sure if multiple C64 cartridges can co-exist on the bus and what kind of benefit could be had from it, but if there exists a setup which can use two or more cartridges at the same time, you may consider switches that toggle each slot on/off rather than select which slot to currently use. I suppose some Ethernet cartridges only using I/O might co-exist with a ROM only application cartridge.

On the VIC-20 this is way more obvious that you could have a 8K ROM cartridge in block 5 and a 8-16K RAM cartridge in blocks 1-2 at the same time.. or something that uses I/O lines. Now I clearly see your expander at the moment is meant for the C64. Perhaps your MasC=uerade device would be able to take this expander too?

As a side note, for a short while I had a Navarone expander. It comes with an extention cord (!) that goes between the computer and the expansion board. The cable is perhaps 15-20 cm long, and I found a couple of the more complex cartridges refused to work at all in this one, e.g. Action Replay Mk 6 would not start while Final Cartridge III might and traditional ROM game cartridges had no problems. It was mentioned on the cbm-hackers mailing list and Bil Herd made a comment that the cartridge bus never was designed to handle such expansion devices, at least not without buffers I suppose. However Commodore clearly produced some expanders on their own, but those sit right next to the cartridge slot, not a few decimeters away.

Even more as a side note, when trying various cartridges on my C64, C64C, C128, C128D and SX-64, I found some are more compatible than others. For example the SX-64 did not like the built-in disk turbo in the AR6, but happily loads TFC3. It could also be due to my SX is a NTSC model while the AR6 is a PAL cartridge. IIRC on the C128D the opposite was found. It has not so much with your expander to do, except for if you planned it to fit also those C64 compatible machines. In the case of a C128D you just need a very wide table to connect an expander on the back. The SX-64 would pose a bigger problem since its cartridge port points right up into the air.

 

[cbm]

I'm not sure if multiple C64 cartridges can co-exist on the bus and what kind of benefit could be had from it

There's no problem with multiple carts as long as they don't use the same memory region. It's not uncommon to mix and match things like a 1541Ultimate, 64NIC+, REU, etc. I currently use a vintage Aprosand cartridge expander for this.

 

[BilHerd]

Hell I would argue they didn't design the bus for the first cartridge depending on what your expanding.

None the less, many people got cartridges to work in many ways, so again it depends on what it is your expanding. The biggest problem about the expansion bus IMHO is the lack of a concrete strobe with enough time to tack on a TTL delay to latch address and data and to hold data long enough (or strobe earlier to make datahold longer). Had the original design brought out Phi0 instead of Phi2 that would have made things work better on paper at least. Most cartridge live with a slight negative margin. This is what keeps peripherals like the 6551 from working without recreating a Phi signal on cartridge (TED brought out Phi0 specifically for 6551 type expansion)

I saw companies solve this in ways I would probably not thought to try, the Curah Speech cartridge used to use a glitch on the IOSEL to latch the R/W line, consequently we had to put the glitch back in for the 128. (I tried to strobe the IOSEL's so they could act as early indication of end of cycle)

As far as buffers, most of the time it was about time/delay. Buffers slowed things down even worse in some places (Tprop), others the RC load of an unbuffered line would slow down Trc. Sometimes the capacitive load would actually hang onto the last data longer and slightly improve things. (Cold spray would usually detect someone trying to do this in the lab)

Bil