Gigantic bankable carts (from CiE)

[brpocock]

How long a lead time is there on this kind of design work?

A difficult question. I don't have a good answer to that. Most people here are hobby designers. Depends on when they have time and if your design is similar to something they have already done.

 

Which is easier/cheaper: doing arbitrary slots or something more like the 2k/4×256/1k scheme?

Arbitrary slots consume more internal logic resources and smaller banks need more pins. Not easy to compare. I don't think either of the two methods is especially difficult.

 

are we talking about gate kit chips or a PIC/FPGA level of complexity?

The logic chip internals would be more complex (serial EEPROM writing algorithm and control of a bus transceiver and some way of doing a complete page dumb with just one command) It would most likely not fit into a cheap Xilinx device and that means the boards can't be easily produced anymore ... Not to speak of the development time needed for a thing like that.

I'm curious whether crossing the 256k mark with 1k banking regions is a limit on bankswitching via register writes or if 16b latches could exist?

The withs of the latch is only limited by the amount of resources on the Logic Chip. There actually is no limit for one special aspect. Its the complete design that has to fit into the device.

 

and keep the mfg. costs under $15..20?,

That is realistic, if you skip the serial EEPROM idea and keep to standard banked flash-rom together with RAM.

1013994[/snapback]

 

To save anyone joining in late in the game some reading, here would be a dream board for doing something like RPG's or other "huge" games...

 

4k addressing space split into 4×1k "bank slots"

 

Each bank slot individually selected from either 256k ROM or 16k RAM... or more of either...

 

Ideally, programmer just stores a (1k-based) address into a 16b latch register, presumbaly hidden under traditional bankswitching "trigger" addresses (e.g. under F7 method). Since it seems we're into FPGA turf, ideally, have something like four 16b registers, each controlling one banking slot, triggering the switch after the high byte has been written (assuming low byte, high byte ordering). While (initially) we'd onyl have the 256k ROM and 16k RAM, this would potentially allow 64M of addressable storage, in 1k chunks. (2**16×1k)

 

As a fair alternative, use four pairs of latch registers, one each for ROM and RAM. Write a (1k-based) ROM address to a latch to engage a the related ROM into that slot, write to the other latch to select a RAM bank into the same slot.

 

However, if the "magic writes" (RAM that can be accessed read-write using a single addressing range) can't be used, then instead RAM banks should automatically be switched based on 512B boundaries, with read and write regions to fill the 1k slot.

 

If at all possible, leaving a space to slip in a serial EPROM or other persistent storage, like the AVox/MemCard -- or a smaller one, or something like that -- would be a great option to have, even if not all carts needed it.

 

Based on the prior discussion, a $15 manufacturing cost seems to be the target area...

[CPUWIZ]

I am confused, how are you involved in this at all, to warrant another thread?

 

Maybe I should start a thread about "Big Sexy" in the 2600 forum.

 

[vdub_bobby]

I am confused, how are you involved in this at all, to warrant another thread? 

Huh?

[djmips]

This is a thread branched from this thread 2600 RPG - codename, "CiE"

[CPUWIZ]

This is a thread branched from this thread 2600 RPG - codename, "CiE"

1014068[/snapback]

 

I see. Thanks.

[supercat]

Based on the prior discussion, a $15 manufacturing cost seems to be the target area...

1014019[/snapback]

 

On the other thread, I described my 4A50 bank-switching cart. You can also read more about it in my blog. My design philosophy was (1) figure out the cheapest way to add ANY amount of RAM to a 2600 cart using new chips; (2) figure out the maximum amount of addressing flexibility I could get for that price.

 

The only aspects of my design that could be cheaper are (1) It could use a smaller flash than 64Kx8, but the cost differential there is very slight; smaller flash parts do unfortunately use a different footprint, so they're not drop-in compatible. (2) There's a serial EEPROM which could be omitted if not needed (or if I can't get it to work usably); (3) there are a few resistors which were included in the design to provide versatility; the cart could be designed so as not to require some of them; (4) I used an oscillator module instead of a crystal and logic gate because such modules WORK and I always seem to get into trouble when I design oscillator circuits.

 

Otherwise, I figured since (1) the smallest readily-available RAM is 32Kx8; (2) there is almost no price difference between a Xilinx 9536XL and anything smaller, it made more sense to use the 9536XL than try to squeeze the design into a 22V10 (which is the smallest thing I can working reliably for even a 16K SuperChip game--and even that would be pushing it).

[supercat]

BTW, while I'd suggest you look at the 4A50 blog entries, I should mention a couple of other cool features:

 

-1- LOTS of hotspots for maximum bank-switching flexibility and efficiency. Unlike 3E bank switching which often requires five cycles and a register to perform a bank switch (LDA #xx / STA $3E), the 4A50 cart allows any bank to be switched in four cycles with no register usage (just use a "NOP abs" instruction), three cycles if the proper bank is already in either a register or one of twelve special zero-page memory locations, or--in a couple of special cases--ONE cycle (accessing zero-page memory locations at IIRC $64xx will toggle one banking bit; accessing them at $65xx will toggle a different bit--if you're already accessing one of those locations for some other purpose, adding $6400 or $6500 to the address will cost just one extra cycle).

 

-2- Hotspot validation logic, to ensure that hotspots only trip at the proper addresses. On the 6502, it's common for people to use the "BIT" opcode ($2C) to skip over other two-byte intructions. Doing this will cause a memory read to be performed at the address listed in the instruction (e.g. using a "bit" opcode to skip over an "ORA #16" instruction ($09 $10)would cause a read of address $1009 which could be disastrous on a SuperChip or SuperCharger game). The hotspot validation logic won't recognize hotspots at addresses outside the range $6000-$7FFF, thus avoiding this hazard (except for instructions whose second byte fell within that range).