Rev2 Game PCB with RAM option

[+5-11under]

The first batch of Rev2 production PCBs arrived today (yellow solder mask). I assembled one by hand, just to make sure they're good. Once they're assembled, they'll be ready for sale for anyone who needs any (Rev1 is available now).

 

 

[+DZ-Jay]

Can you share the memory map available for ROM and cartridge RAM?

 

I'm working on adding support to all platforms available in P-Machinery v2.0. Right now, it supports the original Mattel memory map, CC3, JLP/LTO Flash!, and HIVE/Bee3.

 

The idea is that the programmer can choose the target platform and the framework will configure itself with appropriate defaults and defined constraints.

 

dZ.

[+5-11under]

Can you share the memory map available for ROM and cartridge RAM?

 

I'm working on adding support to all platforms available in P-Machinery v2.0. Right now, it supports the original Mattel memory map, CC3, JLP/LTO Flash!, and HIVE/Bee3.

 

The idea is that the programmer can choose the target platform and the framework will configure itself with appropriate defaults and defined constraints.

 

dZ.

 

Here's the details...

 

Rev2 PCB (this one):

64K x 16 ROM pretty much anywhere you want that works.

64K x 16 RAM pretty much anywhere you want that works. Note that the RAM is an option that adds to the cost of the PCB if it's installed.

When I say "pretty much anywhere" I should note that the CPLD which controls the memory has finite space/power, so there is a limit to the number of locations and their size. For normal/reasonable memory maps I haven't run into any limit, but if you went crazy and split up the memory into very small and varying sizes of RAM and ROM all over the place, you could run into difficulty. Standard 16K and 42K (cart.mac) maps fit very easily, as has any other scheme I've tried so far.

ECS style bankswitching is not available in this revision because the external latch is handling the upper addresses (and therefore the CPLD has no control over the upper addresses).

One of the maps I created is an "ECS-safe" (doesn't get in the way of the ECS) map as follows:

ROM at:

$4800 to $4FFF

$5000 to $5FFF

$6000 to $6FFF

$A000 to $AFFF

$B000 to $BFFF

$C040 to $CFFF

$D000 to $DFFF

$F000 to $FFFF

RAM at:

$8040 to $9FFF

I'm kind of hoping IntyBasic users will stick to this, unless they need additional space. I can also use this scheme (because it's safe - please anyone correct me if I'm wrong) for the PCB even if only the $5xxx, $6xxx, $Dxxx, and $Fxxx memory is used. As mentioned, though, pretty much any reasonable map is do-able.

 

Soon I hope to create a Rev3 PCB which will allow ECS style bankswitching (by re-wiring the latch/CPLD). The ROM size is 128K x 16, so there is a fair bit of available space. At some point I may also try to bankswitch the RAM. Details to follow, of course, but the plan is to have at least one 4K x 16 block of ROM to have 16 banks available to it (for instance at $Axxx or $Bxxx might work nicely, although it'd be simple enough to pick any 4K x 16 block). This would be fairly simple to incorporate, and wouldn't "waste" too much space. In summary, you would still have the 64K x 16 ROM (and RAM) space available (pretty much anywhere you want that works), plus 16 (actually 15 additional, I guess) 4K x 16 banks in any one of the blocks. Other schemes are possible, but perhaps not required. When the Rev3 PCB is working, there should be no need to have the Rev2 (or Rev1) PCBs anymore.

 

The Rev1 PCB, which shouldn't be required much longer, has the same capability as the Rev2 PCB, but does not have RAM. It does have full control of the ROM chip (well, at least 64K of it), so in theory it could have bankswitching capability. I haven't tried that yet, but may at some point, just for posterity (and testing prior to creating the Rev3 PCB).

[+5-11under]

A shorter answer...

 

It would be nice to have a few memory maps available for these Rev2 and Rev3 PCBs, to be used 95% of the time, anyway. The odd extreme case is still fine, of course. For example:

 

- 42K (with or without RAM) from cart.mac

- ECS-Safe as described above

- 16K from cart.mac (redundant? - might as well just use the ECS-Safe map)

- Bankswitch option (Rev3 only) for any of the above with 15 additional ECS style banks at $A000 (or other location?) (write $AA5y to $AFFF to switch range $Axxx to bank y - I think I have that correct)

[+DZ-Jay]

Thanks for the very detailed answer.

 

I'll probably then use the CART.MAC 42K map. It seems to be turning into the de facto standard.

 

The awesome thing is that, since most home-brewer target platforms (even the emulator) support "cartridge RAM," the framework can default to nice and expansive data structures for the system event queue, timers, and animation/interactive objects.

 

My intention is to let starting developers concentrate on the functional aspects of the game program and not have to think about mundane technic details, like the size of the stack, or how many timers are enough--at least until the program matures enough (presumably along with the programmer's familiarity with the platform), and the limits become apparent.

 

Practical default values afford this.

 

dZ.