New ColecoVision PCB design project

[Pixelboy]

Next questions...

 

When using a CPLD or FPGA to control a serial EEPROM, what is the typical method to access the memory, from the homebrewer's perspective? Is there a lot of overhead required, or is it a simple task to access? The reason I'm asking is because...

 

A fairly simple way (for someone like me, who doesn't fully understand FPGAs and CPLDs) to add memory would be to add a parallel EEPROM, and "chip-select" it into the upper portion of memory. Access to the memory should be easy, but it would reduce the available ROM space by the amount of space allocated to the EEPROM. I might have to try this... .

 

Thanks,

5-11under

You may want to send a PM to PkK to find out how he does it in his L5 MegaCart. Perhaps he's doing something similar to what you're proposing.

[+batari]

Next questions...

 

When using a CPLD or FPGA to control a serial EEPROM, what is the typical method to access the memory, from the homebrewer's perspective? Is there a lot of overhead required, or is it a simple task to access? The reason I'm asking is because...

 

A fairly simple way (for someone like me, who doesn't fully understand FPGAs and CPLDs) to add memory would be to add a parallel EEPROM, and "chip-select" it into the upper portion of memory. Access to the memory should be easy, but it would reduce the available ROM space by the amount of space allocated to the EEPROM. I might have to try this... .

 

Thanks,

5-11under

You may want to send a PM to PkK to find out how he does it in his L5 MegaCart. Perhaps he's doing something similar to what you're proposing.

He posted a pic of the L5 Megacart. That is an FPGA and a serial EEPROM. There is also a parallel flash but I don't think that's where he writes high-score data (it's socketed PLCC so most likely it's programmed separately and holds game binaries.)

[yuppicide]

I have nothing useful to help you guys with, but just wanted to say thumbs up. Can't wait to see new product.

[+5-11under]

Hi Pixelboy,

 

Me again. Looking at figures 4 and 5 from post #2, I just want to be clear on a couple of things...

 

1. The PCB sits on top of the red lines, right? So these are keep-away zones for components, but no routed slots in the PCB are required.

 

2. The blue line would directly interfere with the PCB, and absolutely require a routed slot in the PCB in that area?

 

Thanks,

5-11under

[+batari]

Question #5 is also especially important, because it impacts on the entire design: If it's possible to fit a 32K ROM chip with auxiliary savegame chip on the small PCB pictured in Figure 3, then it's definately a solution we will be looking at.

You have to at least say what the approximate dimensions of the existing boards are before anyone can begin to evaluate this question.

[Pixelboy]

1. The PCB sits on top of the red lines, right? So these are keep-away zones for components, but no routed slots in the PCB are required.

That's almost correct. The red lines represent extrusions in the front half of the casing (the PCB itself rests on the back half), so they are located above the PCB. So yes, those are keep-away zones for components, but no holes need to be cut in those zones on the PCB.

 

2. The blue line would directly interfere with the PCB, and absolutely require a routed slot in the PCB in that area?

That's correct, yes.

 

Question #5 is also especially important, because it impacts on the entire design: If it's possible to fit a 32K ROM chip with auxiliary savegame chip on the small PCB pictured in Figure 3, then it's definately a solution we will be looking at.

You have to at least say what the approximate dimensions of the existing boards are before anyone can begin to evaluate this question.

Point well taken. I'll try to provide some approximate dimensions later today or tomorrow. Not knowing much about the various components required is a handicap for me...

[Pixelboy]

Alright, see the image below for all the approximate dimensions. In case you're wondering, the holes are approximately 2 mm in diameter, and they are placed approximately 10 mm from the top edge of the board.

 

Hope this helps.

[GroovyBee]

A 28 pin DIP (.1" pitch device) footprint for a 32K OTP is approx 37.4mm x 17.5mm so that is most of the space between the two holes taken up. If you went to a 28 pin SOIC package (surface mount) the space taken would shrink to 12.5mm x 18.5mm.

[newcoleco]

I did read some parts of the messages here. I would like to make a Coleco game with a save option, and I would like to make a game more than 32K at the same time. I did have a Coleco project idea long time ago, and I did try a map test one time. The concept is to move around and figure out by yourself what you can do, there is no guide or storyline, you explore and try... during monts if you want.

[+batari]

The small board (fig B, without the wings) could accommodate a 28-pin EPROM on the top and an 8-pin DIP serial EEPROM and a 20-pin 16v8 PLD between the pins of the EPROM on the bottom of the board. A 27c512 EPROM will physically fit and is 64k.

 

I can think of a few ways to bankswitch and control the serial EEPROM with the 16v8. They all involve limited address decoding so we can use the full RAM mirror space as hotspots. That is, this method relies on the address space between 7000H and 7FFFH be unused (I assume RAM is normally accessed at 6000H-63FFH and the mirrors are usually not used? If this is not the case, someone please comment.) So A0-A9 will not be connected to the PLD at all.

 

The programming model for the serial EEPROM will be a little funky but the L5 cart creator said his was a well.

 

That is my cheapest DIP proposal anyway. If you want to go SMT, I suggest going with a microcontroller.

Edited July 16, 2009 by batari

[Pixelboy]

The small board (fig B, without the wings) could accommodate a 28-pin EPROM on the top and an 8-pin DIP serial EEPROM and a 20-pin 16v8 PLD between the pins of the EPROM on the bottom of the board. A 27c512 EPROM will physically fit and is 64k.

 

I can think of a few ways to bankswitch and control the serial EEPROM with the 16v8. They all involve limited address decoding so we can use the full RAM mirror space as hotspots. That is, this method relies on the address space between 7000H and 7FFFH be unused (I assume RAM is normally accessed at 6000H-63FFH and the mirrors are usually not used? If this is not the case, someone please comment.) So A0-A9 will not be connected to the PLD at all.

Adress space in the ColecoVision is divided as follows:

0000h to 1FFFh = BIOS

2000h to 5FFFh = reserved for expansion port

6000h to 7FFFh = RAM (real RAM is at 7000h to 73FFh)

8000h to FFFFh = ROM (game cartridge)

 

I'm not sure if the ColecoVision offers the possibility of reusing the mirrored RAM address ranges for other purposes, since we're talking about a range that lies outside the cartridge ROM adressing range. I'm hoping Daniel Bienvenu will comment.

 

The programming model for the serial EEPROM will be a little funky but the L5 cart creator said his was a well.

As long at it works, it's not problem as far as I'm concerned.

 

 

Thanks!

[newcoleco]

Adress space in the ColecoVision is divided as follows:

0000h to 1FFFh = BIOS

2000h to 5FFFh = reserved for expansion port

6000h to 7FFFh = RAM (real RAM is at 7000h to 73FFh)

8000h to FFFFh = ROM (game cartridge)

 

I'm not sure if the ColecoVision offers the possibility of reusing the mirrored RAM address ranges for other purposes, since we're talking about a range that lies outside the cartridge ROM adressing range. I'm hoping Daniel Bienvenu will comment.

 

Inside the ColecoVision, the 1K RAM is mirrored like you said... nothing more to say, and there is no way inside the console to use more RAM, except with an expansion module.

 

Inside the Coleco Adam computer, you have options of bank switching to even more RAM than you may need.

 

http://drushel.cwru.edu/atm/atm.html

 

2.1 Lower Memory Options ( 0000 - 7FFF )

 

SmartWRITER Word Processor ROM - This memory option consists of 32K of SmartWRITER ROM code. A small part of this code, EOS_BOOT, is responsible for system initialization during power up and reset. EOS ROM can also be accessed when this option is selected. See Subsection 4.1, EOS, for further details.

 

32K Intrinsic RAM - This option is the lower half of the 64K RAM included with every ADAM. DMA transfers to AdamNet can take place only in intrinsic RAM. SmartBASIC and most Programs stored on data pack reside in this memory.

 

32K Expansion RAM - This option is the lower half of the 64K Memory Expander, an optional feature not included with the ADAM system. The 64K Memory Expander increases ADAM's memory to 144K of read/write memory (64K intrinsic, 64K expansion, 16K VRAM).

 

OS-7 (ColecoVision bios) and 24K Intrinsic RAM - This option contains OS-7 and 24K of ADAM's intrinsic RAM. OS-7 is the 8K ROM installed in ColecoVision and ADAM. In Expansion Module #3, this ROM is in the ColecoVision. The description of the 32K Intrinsic RAM also applies to this 24K intrinsic RAM.

 

2.2 Upper Memory Options ( 8000 - FFFF )

 

32K Intrinsic RAM - This option is the upper half of the 64K intrinsic RAM included with ADAM. DMA transfers to AdamNet can take place only in intrinsic RAM. SmartBASIC and most programs stored on data pack reside in this memory.

 

Expansion ROM - This memory is provided by an expansion ROM, an optional feature not included in the ADAM system. The expansion ROM is installed in Connextor #2 on the Memory and I/O Board. EOS_BOOT checks this connector for valid data before initializing EOS. If valid data is found, the EOS_BOOT code jumps to this ROM.

 

32K Expansion RAM - This is the upper half of the optional Expansion RAM described for lower memory.

 

32K Cartridge ROM - This memory option is the cartridge slot on ADAM or ColecoVision, used to execute game cartridges or other cartridge-based software.

 

By using a Coleco Adam standalone or expansion module you have access to plenty of RAM outiside the cartridge. You can somehow detect on which system you run your cartridge by writing and reading some data, switching the memory banks if you want, before starting the execution of your game in the cartridge.

 

So, by default, the ColecoVision is using a mirrored 1K of RAM like you said. But you can use more RAM when using an expansion module like the Coleco Adam computer.

Edited July 16, 2009 by newcoleco

[+batari]

I wasn't suggesting trying to map the mirrored RAM to a cart, just confirming that it was mirrored there. If the normal location is 7000H-73FFH, I could use 6000H-6FFFH provided that area isn't used for anything else, as I was not suggesting adding RAM, ROM or anything else there but merely putting hotspots there to trigger bankswitching and EEPROM access. No data pins will be driven.

 

So the real question is whether the address range 6000H-6FFFH is ever used.

[newcoleco]

So the real question is whether the address range 6000H-6FFFH is ever used.

The address 6000 gives the same access to the 1K memory we normally access to 7000... so in theory you can use the address 6000 instead of 7000, but not as more ram, but as the same ram space... again in condition of using a standard ColecoVision without expansion module that may provide more ram like the module #3 coleco adam computer.

[+batari]

So the real question is whether the address range 6000H-6FFFH is ever used.

The address 6000 gives the same access to the 1K memory we normally access to 7000... so in theory you can use the address 6000 instead of 7000, but not as more ram, but as the same ram space... again in condition of using a standard ColecoVision without expansion module that may provide more ram like the module #3 coleco adam computer.

Thanks, but that's not what I wanted to know.

 

I wanted to know if any games try to use one of the RAM mirrors at any location other than 7000H-73FFH.

[Pixelboy]

So the real question is whether the address range 6000H-6FFFH is ever used.

The address 6000 gives the same access to the 1K memory we normally access to 7000... so in theory you can use the address 6000 instead of 7000, but not as more ram, but as the same ram space... again in condition of using a standard ColecoVision without expansion module that may provide more ram like the module #3 coleco adam computer.

Thanks, but that's not what I wanted to know.

 

I wanted to know if any games try to use one of the RAM mirrors at any location other than 7000H-73FFH.

Well, even if other (past) games do try to write in the 6000h to 6FFFh range, who cares? The important thing is that the games that will use this proposed PCB must not try to. So if you want to use the 6000h to 6FFFh range for your own special purposes, don't let anyone stop you.

[+batari]

So the real question is whether the address range 6000H-6FFFH is ever used.

The address 6000 gives the same access to the 1K memory we normally access to 7000... so in theory you can use the address 6000 instead of 7000, but not as more ram, but as the same ram space... again in condition of using a standard ColecoVision without expansion module that may provide more ram like the module #3 coleco adam computer.

Thanks, but that's not what I wanted to know.

 

I wanted to know if any games try to use one of the RAM mirrors at any location other than 7000H-73FFH.

Well, even if other (past) games do try to write in the 6000h to 6FFFh range, who cares? The important thing is that the games that will use this proposed PCB must not try to. So if you want to use the 6000h to 6FFFh range for your own special purposes, don't let anyone stop you.

Sure, but it would be nice to know. Some may wish to use the boards to create repros of a rare or prototype game, for example. I suppose one could just use a different PLD program and a 32k EPROM for that, though.

 

I'll just go with 6000H-6FFFH hotspots and see what can fit on a 16v8.

[+batari]

Here is a proposal that meets the following criteria:

 

• Smallest board size
  
• All through-hole parts
  
• Inexpensive, common parts
  
• No special PCB cuts
  
• 8k, 16k, 32k, or 64k size (27c64, 27128, 27c256, or 27c512 devices)
  
• Optional serial EEPROM for saving data
  

 

The 28-pin EPROM goes on top of the board. The 20-pin PLD and 8-pin serial EEPROM abut and go on the bottom between the rows of EPROM pins.

 

The EEPROM, two resistors and a cap may be omitted if no game saving is needed.

 

If no bankswitching is needed, an additional resistor and cap may be omitted. The PLD program is the same.

 

Bankswitchng and EEPROM access uses 4 hotspots - a read or write to the below will do the following:

Typical access locations are:

6000: EPROM A15 latched high (second 32k bank), EPROM A14=EEPROM SDA out (nonlatched), EEPROM selected, EEPROM clock low (latched).

6400: EPROM A15 latched high (second 32k bank), EPROM A14=EEPROM SDA out (nonlatched), EEPROM selected, EEPROM clock high (latched).

6800: EPROM A15 latched low (first 32k bank), EPROM A14=cart slot A14 (nonlatched), EEPROM deselected (latched).

6C00: EPROM A15 latched high (second 32k bank), EPROM A14=cart slot A14 (nonlatched), EEPROM dselected (latched).

 

Toggling A8 and/or A7 by placement of code may also be necessary to help read or write the EEPROM, as they perform both the /WE and SDA input. SDA output is "read" on EPROM A14.

 

(I can use address pins other than A7 and A8 if that is better. I could also use address pins other than A11-A10 for hotspot decoding as above, and can bridge something other than A14 to read a bit from the EEPROM.)

 

I agree that the code to read and write the EEPROM will be funky (and I don't know z80 well enough to actually write it yet), but once done, it could be included as a function that others could use in their code and not need to reinvent it.

 

Anyway: here is the schematic, and logic equations and pin map of the PLD.

	capout =   /addr_12 * addr_13 * addr_14 * cs_0 * cs_1 * cs_2 * cs_3 
cerom =  cs_0 * cs_1 * cs_2 * cs_3 
csee.D =  addr_11 
csee.C =  capin 
ea14 =  addr_14 * csee.Q	 + /csee.Q * sda 
/ea15.D =  /addr_10 * addr_11 
ea15.C =  capin 
scl.D =  addr_10 
scl.C =  capin

								 C16V8C
			 __________________________________________
	  capin =| 1|								  |20|* not used	   
	  cse_0 =| 2|								  |19|= scl			
	  cse_1 =| 3|								  |18|= ea15		   
	  cse_2 =| 4|								  |17|= csee		   
	  cse_3 =| 5|								  |16|= ea14		   
	addr_10 =| 6|								  |15|= addr_14		
	addr_11 =| 7|								  |14|= addr_13		
	addr_12 =| 8|								  |13|= cerom		  
		sda =| 9|								  |12|= capout		 
   not used *|10|								  |11|* not used	   
			 __________________________________________

Open to suggestions, improvements, etc.

 

One thing I tried to do is align the pins of the 16v8 with a standard logic chip (e.g. 7421) so one could that in place of a PLD if you don't need EEPROM access or bankswitching. I couldn't figure out a way to do it (I did figure out a way to use 4 Schottky diodes and a resistor in place of a PLD, however, but that didn't make it to the design above if anyone thinks that's a good idea.)

[Pixelboy]

First and foremost, I would like to thank you, batari, for all your hard work. If anyone with the appropriate knowledge could validate these schematic, it would be very appreciated as well.

 

Secondly, I would like to state in an official manner that this is a totally open project, in the sense that there is nothing private about it, especially where I'm concerned.

 

If all those components can be placed on a PCB that small, then surely they can also be placed on a PCB of the same shape as the Pixels Past PCBs. So even if we eventually run out of Activision-style casings, the 32/64K cart with savegame EEPROM could still be available, with regular Coleco-style casings, with just a little more work.

[opcode]

Looks good. I would give it a try, but I need to get more acquainted with EEPROMs first. The data access sequence seems quite complicated.

[Pixelboy]

I have a couple of general questions:

 

How will the bankswitching work? Will 16K be fixed, and the remaining 16K be bankswitchable? Or will it be more like 24K fixed and 8K bankswitchable?

 

Also, can this setup accommodate EEPROMs of different memory sizes? Some homebrewers may need less than 1K to store a simple high score table, while others may need more space (to store levels made by the player with a level editor for example). I haven't checked yet, but I would guess that EEPROMs with larger memories are more expensive...

[+batari]

I have a couple of general questions:

 

How will the bankswitching work? Will 16K be fixed, and the remaining 16K be bankswitchable? Or will it be more like 24K fixed and 8K bankswitchable?

As presented, bankswitching swaps the entire 32k at a time.

 

There is probably enough spare logic in the PLD to allow something like 16k fixed+16k switchable among 3 banks, however. Would that be better? It would require a couple more hotspots in the 7800-7FFF range but that's still outside of normal RAM.

Also, can this setup accommodate EEPROMs of different memory sizes? Some homebrewers may need less than 1K to store a simple high score table, while others may need more space (to store levels made by the player with a level editor for example). I haven't checked yet, but I would guess that EEPROMs with larger memories are more expensive...

I think compatible EEPROMs are available in sizes ranging from around 128 bytes to around 512k, and prices aren't too bad even on the high end.

[Pixelboy]

As presented, bankswitching swaps the entire 32k at a time.

 

There is probably enough spare logic in the PLD to allow something like 16k fixed+16k switchable among 3 banks, however. Would that be better?

Definately better, yes. That's the kind of setup most homebrewers expect. PkK and Opcode's designs both have fixed ranges (24K and 16K respectively). Usually, game logic goes into the fixed range, and data goes into the bankswitched upper range, so that would leave three full banks to put data in. If the entire 32K is bankswitched, then game logic will have to be duplicated in all banks, which would be wasteful.

 

It would require a couple more hotspots in the 7800-7FFF range but that's still outside of normal RAM.

As long as it works.

 

Also, can this setup accommodate EEPROMs of different memory sizes? Some homebrewers may need less than 1K to store a simple high score table, while others may need more space (to store levels made by the player with a level editor for example). I haven't checked yet, but I would guess that EEPROMs with larger memories are more expensive...

I think compatible EEPROMs are available in sizes ranging from around 128 bytes to around 512k, and prices aren't too bad even on the high end.

Okay... And the PLD will work with all EEPROM memory sizes without any internal modification required?

Edited July 23, 2009 by Pixelboy

[Pixelboy]

Hello people.

 

First of all, I would like to use this opportunity to mention that my wireless modem at home broke down last Monday, and I will be unable to access the internet in the evenings until I get a replacement modem (sometime next week, if all goes well). Also, I've been working at client buildings these past three days, so I wasn't even able to access the internet from the office. No internet at all for three whole days... I was starting to feel withdrawal symptoms.

 

Anyhow, we are now at a point where we need to have precise measurements taken from the original Motocross Racer or Tournament Tennis PCBs, so that further progress can be made following batari's schematics. If you own a micrometer or caliper, and are interested in taking all the required measurements for us, please contact Albert and give him your postal address, and he will ship a few of the carts to you so you can measure them. We would prefer to send these sample carts to someone in Texas, or in a US state near Texas.

 

Thanks.

[Pixelboy]

5-11under has generously offered his services for taking the measurements. Pending Albert's consent, we'll resume progress on this project after Harvey has done his work.

 

Thanks!