Cart Design Questions

[themrcul]

Hi all,
I am hoping to get some feedback on the design of card needed for a commercial game.

I am not ready to produce something, but I am the kind of person who likes to have most questions answered before starting something!

I have more than a decade of programming experience, in pure C (Wii/PS2/PC/SDL), C# (unity), but comparitively very little experience in hardware.

The cart board design I am thinking of would be a DSP chip or Microcontroller connected to the address and data lines of the cart. It would obviously need to be 5V tolerant for address lines, even if powered by 3.3V.
Is it enough to have a resistor bewteen the 5V coming from the MD to the 3.3V to the Microcontroller? Or would I need a more complex circuit or capacitor as well to filter the power a bit? Does anyone have experience with that?
Additionally, I have read that the address lines from the MD can be a bit noisy. Would ~70ohm resistors on each of the address lines to the Microcontroller help with that?

The other question is to do with data storage. Looking at Mouser/Digikey and other suppliers, serial based EEPROM is cheap, and can have far more storage on the chip. Parallel (like in the era of MD carts), and especially 5V or large storage parallel eeproms are comparively rarer and more expensive.
If I were to choose a serial based EEPROM, how do I know if it would be fast enough to get the data needed from the EEPROM to the Microcontroller and then onto the data lines? Does anyone have any advice to offer there?

So the plan at the moment is data and address lines connected to a Microcontroller/DSP. The Microcontroller/DSP is also connected to serial storage for game data. When requests come through the MD for data, the Microcontroller requests the data from the serial storage and then pipes the answer through the data lines then asserts dtack.
The Microcontroller/DSP is most likely going to be 3.3V with 5V tollerant lines. What is the usual process for mating a 3.3V system to the 5V MD?

Thanks everyone. I'm new to hardware and having a fun time thinking through this, but some expert advice would be really appreciated!
-TheMrCul

[TmEE co.(TM)]

You need full level conversion, resistors aren't going to do anything but current limiting. For single direction stuff you could get away with voltage dividers but signal edges will get poor. For bidirectional signals you'll definitely want actual chips doing the thing. And for power rails you need at least diode drops based thing, zener or an actual voltage regulator. Linear 3.3V reg will cost almost nothing and is more convenient than other solutions. A resistor will not work as voltage will wildly depend on load.

Serial memory > DSP/MPU > MD is never gonna work unless you can do things at speeds of a typical bus cycle which are couple hundred nanosecond level but at that point you're using up all the processing power emulating a CPLD or something, leaving no room for anything useful. Also there's 3 kinds of bus cycles (DMA, 68K and Z80) and all have different timings to them.
I don't think there will be any chance getting a serial to parallel conversion work even through a CPLD, even multibit IO memories have long latency on actual random access cycles.
You could have a small bootloader that updates SDRAM or PSRAM with content from a NAND or something else and that DSP working next to it.
Also MD side cannot be stalled so it must always get priority and if you cannot get stuff out in time you'll be having a crash.

[themrcul]

Thanks very much for taking the time to help TmEE.
I have done hours of learning since, and hope to post what I've learned plus a question or two later on, but it's not ready yet.
But I have found 5V 32MBit Flash/Eeproms available, and a suitable DSP for augmenting the sound system of the MD. Just need to compose the thoughts, and post something when more of the pieces are together.
But this is just to say thanks!

[themrcul]

Hi Tiido (and others!),
I have done lots of research about possible cart design options, but I have a few more questions that could help me immensely!
I think I have found the memory chip for code, graphics and music assets: the M27C322. Available for ~$1 on aliexpress, 32megabit, parallel, 5v, < 100ns access time.

My design goals for this cartridge is to allow up to 4MB of space to put a game in, and have a co-processor on-board to perform the actions of reading and writing save game data, and also to play the sound effects from the game. This would have several benefits:
1) On the original MD sound data is large and not compressable.
2) Quality of playback is poor (8-bit, mono, max 14kHz). A secondary sound device could play 16-bit, stereo, ADPCM compressed samples.
3) Sound effect data could be located on a separate EPROM, to free up space on the main EPROM for other things.

I researched possible candidates for microcontrollers with DACs onboard but consistently ran up issues with lack of input/output lines to work with, and lack of RAM for decent sound mixing.
I am now leaning towards an ARM cortex -m4 based chip - 64/128/256KB of RAM, 256/512KB of program memory, 33 user general I/O lines, 5V tolerance.

My design is as follows:
All data and address lines are hooked up to the M27C322 EPROM as usual. B17 is hooked up to the EPROM chip enable.
To integrate the ARM chip:
/TIME (B31) is hooked up to an external interrupt of the ARM chip, along with B28 and B29 to two general I/O inputs (to determine if the MD is reading or writing). No flip-flop should be needed on the external interrupt, as the ARM interrupt line can be configured to interrupt on a rising and/or falling edge (handy!)

All 16 data lines can therefore be linked to the ARM's general I/O lines, along with the first 8 address lines (to be able to capture the whole /TIME range as different commands to the ARM to perform). The MB9B160L ARM chip I am looking at has 33 I/O lines. 16 data + 8 address + 3 control + 2 DAC + 4 ext. data storage = perfect.

This leaves me with two questions:
1:
Firstly, does putting two devices on the data lines introduce any electrical problems? Since B17 is unset when B31 is set (due to being different data ranges), only one device should be using the data lines at once (whenever /TIME is not asserted, the general I/O pins on the data range will be configured as inputs). Or do I still need a multiplexer on the lines with /TIME selecting which one to be routed? Fewer parts needed is better of course, I am hoping I can just put the two devices on the same lines without a multiplexer!

2:
All the information I am reading seems to suggest the MB9B160L ARM chip I am looking at is a 5V device. But if it is a 3.3V device with 5V tolerant inputs, when the device is outputting 3.3V to the MD is that a high enough voltage for the MD to latch with? Or will 3.3V not be high enough/reliable enough for the MD to latch to and I will need a bidirectional level shifter? I have tried looking high and low to see what voltage is acceptable for the MD to latch to but could not find an answer. Again if a level shifter could be avoided that would be best, fewer parts, lower cost and easier fabrication.

Thanks again for your very knowledgeable help!

[TmEE co.(TM)]

That EPROM will work but availability might be limited if you intend to make lot of cartridges. They are also likely to be pulls rather than new parts. To save a looooot of time make sure the parts you order are erased before hand. It takes half an hour at least to erase an EPROM.

If the MCU has 5V power supply and not 3.3V then it will have 5V outputs, if supply is 3.3V then output will be 3.3V. I have not seen a MD that wasn't able to respond to 3.3V output so that part should be safe.

Your only complication as far as data transfers go is possibility of not capturing the data fast enough when interrupt happens. this is especially dangerous for reading from the MCU as if you keep data on the bus too long you cause a bus fight with the EPROM and result is a most probably crash due to CPU getting garbage data. Other than that things should work.

Another problem is that Only MD1 and MD2 have sound lines connected on the cartslot, Nomad and Genesis3 don't have them. X'eye, Wondermega and CDX/MultiMega do have the lines connected also.

[Chilly Willy]

Sounds like you didn't download the datasheet.

http://www.cypress.com/file/278416/download

According to the datasheet, you can run this chip at 5V (up to 6.5V!), at which point IO levels become moot.

EDIT: Ninja'd!

Also, that's a cool chip to put in a cart. Dual DACs that run fast enough to do time-multiplexed channels, DMA, up to 512KB of flash... and cheap!

[themrcul]

Thanks guys,
Re: Chilly Willy, I did read the datasheet, but didn't understand that would happen. I scoured the doc for mentions of what voltage it would output at but didn't realise it would output at generally what is input. Fantastic!
With 512KB of flash I hope that will be enough to hold all the compressed sound I need, then I won't even need external storage for sound data. Double win.

Re Tiido: I didn't realise those parts may not be new. That kind of takes me back to square one with the EPROM situation. What would you guys recommend for EPROM then? Everything I've found that is new is 3.3V, which means linear power regulators and line shifters, more components, more cost and more time taken to solder everything together...
I have no idea how popular the game I make would be, but having a solid supply of chips at a good price is ideal of course.

And another question. Quite a while ago Tiido you kindly posted a schematic for a circuit that would correctly amplify the output of an on-chip DAC to have the correct volume for Model 1 and 2 Mega Drives, seeing as they have differing impedances. It was here: viewtopic.php?f=2&t=2592&p=31188&hilit=paprium#p31188

Would that circuit be needed for the output of a DAC like on the chip I posted? If so, what parts are they exactly? I can see there are a few diodes and resistors, but I have no idea what rating the resistors should be or their value, or what diode should be used either. If it was just one more part to solder that wouldn't be bad, but the circuit you posted seems to have lots of parts! A single drop in part, if it exists, would be ideal.
I saw some parts on digikey which promise to be able to take in 5V supply and audio input and output a line level audio output. Something like this: http://www.analog.com/media/en/technica ... 5_8656.pdf. However, it while I have a single line of DAC output for each channel from the ARM chip, which is supposed to go to a single line of audio input to the MD for each channel (B1 and B3), the audio op-amps I have found all have a +V input (that would be 5V from the MD), then a -V input (is that ground?), and a +audio input (obviously the outputs from the ARM DAC) and -audio input for each channel. Are the -audio inputs ground as well? Or am I looking at completely the wrong device?

Re bus fighting, I hope that 160MHz is fast enough to get the interrupt, place data on the lines and then set a callback to set the lines to input again in a time-slice that works for the MD. I'm guessing 100ns or so? If callbacks aren't available, perhaps the 68K clock could also be fed into the ARM chip on an interrupt, and the lines could be reverted to inputs (to avoid bus fights) at the end of each 68K data cycle.

[TmEE co.(TM)]

EPROMs have not been produced for years, if you're lucky you can get new-old-stock but you're very likely to get pulls.
Your only option is 3.3V parts, having the level shifters and then exclusively using 3.3V parts will cost less than trying to get 5V stuff together. There's far more options and most are all cheaper too.

Exact values all depend on what parameters you want on the amp aswell as what parts are going to be used. Ideally you have a positive and a negative power rail in the cartridge but since that's not possible without some extra DC-DC converter you'll have to create a virtual ground that sits at half the power rail and use it as VREF. -V sits at GND, +V at 5V or higher and VREF at half the voltage. Ideally you get a negative rail and use GND as VREF instead. You'll want to look at some opamp tutorials or something, they all work exactly the same way.

You're completely at the mercy of interrupt latency aswell as limitations the pipeline imposes and due to these factors you never know exactly at what point your code picks up in the middle of the bus cycle, complicating presenting or receiving data from the 68K side. More than likely this is not going to work reliably and you need to add some sort of a buffering mechanism that responds to bus cycles like a real logic device. You will most probably need a CPLD anyway to arbitrare things so that can do such stuff.

[themrcul]

Thanks again Tiido for your advice. IT appears this setup is no-where near as simple as I was hoping it could be! But I thank you for taking the time to advise me, I really appreciate it.
You are correct about the sellers on AliExpress - it turns out they are not new parts, but pulls. However there are close to hundreds of thousands of units in stock. That should be enough for me I hope!

I have also done some preliminary studying on audio op-amps, and setting the op-amp up as a non-inverting buffer appears to be what I need to do. I need to do further research into exactly how much amplification is needed when amplifying sound from the ARM-M4, and how to design the circuit so that differing Mega Drives play sound at the same volume.

With signal timings, ARM M4 promises that it takes 12 cycles from the beginning of the interrupt to when your interrupt code can start running.
Since the chips run at 160MHz, each cycle is 6.25ns, so total wait time would be 75 nano seconds.
I have read that the MD data bus runs at 5MHz (200 nano seconds). The vast majority of communication between the MD and the ARM will be "play sound" requests. For this to work, all data lines on the ARM M4 would be inputs, and I would attempt reading the data upon interrupt and then setting the data for the main program loop to mix the next sound into the stream. In my naive view, having 200ns - 75ns = 125ns to read the data lines coming in should be enough to at least receive a command from the Mega Drive. The more complicated process is getting data from the ARM M4 to the MD, for the purpose of loading a save game from long term storage. If I can't get the save-load game system working, I will just need to work out some other battery backed SRAM or EPROM system.
But this is how I see it could work (I would need to build the circuit and do lots of testing of course!)
MD data bus cycle is 200ns. So from what I understand data would need to be ready on the data lines before that 200ns is up. 75ns is taken with setting up the interrupt. All save-game data storage will be stored locally in 68K RAM, and then transferred to the ARM M4 when the player saves their game. The ARM M4 will write the save data, byte by byte to it's own RAM on each interrupt. When complete, the ARM can safely transfer that data to it's own permanent storage.
If I am incorrect about the data bus being 5MHz (200ns per cycle) and in fact the communication must be timed to the 68K or the Z80, that means I would have 185ns or 560ns respectively (two cycles from 68K @ ~130ns each cycle, or two cycles from the Z80 @ 280ns per cycle). Even with 185ns - 75ns that is still 110ns to be able to access the data on the M4 ARM lines and then write a value to RAM, or change the data lines to be output and then set their states. I hope that will work... Anyway, I will likely need to build a circuit and give it a test!

I have a question about the /TIME line (B31). Can the Z80 drive the /TIME low? If I set the banking register to the area of memory that is for /TIME and I read or write to that part of memory, will the /TIME line be driven low?
The reason I ask is that I would like to write a music driver that plays the song but can talk the ARM M4 to play sounds as well.
If the Z80 can't drive the /TIME line low and I have to do so from the 68K, how can the Z80 talk to the 68K? I have read that the Z80 cannot modify any part of the 68K RAM, and it appears only the 68K can halt the Z80, change it's memory and then allow it to continue, but the Z80 can't talk to the 68K to request it to do stuff. Am I correct? If that is so, then my music driver would need to run on the 68K, which would be disappointing!

Anyway, thanks again for your advice so far guys, it is really fun to theorise and try to make this cart design to work, and with the minimal parts and lowest cost.

[TmEE co.(TM)]

You'll be up for plenty of manual work. I have worked with pulls in past and you absolutely have to verify them all, out of 700 chips, around 100 were dead or damaged (i.e parts of it not programmable etc.). Also pins way not be in the best shape, causing difficulties when soldering. Those stocks can also be vastly overstated. Sometimes when talking to some sellers who list many hundreds or thousands end up having only few tens of actual stock...

Normal opamp will not be able to drive 75ohm without help from a power buffer (the two transistors) on output, their output voltage will drop with such a load and you get back to the original issue where things would sound different depending on model.

Writes from 68K or Z80 are not much of a problem, the data is on the bus for the entire duration of the cycle but reads are a problem, the data is latched by the CPU at the end of the bus cycle and you got to hit it pretty exactly and also remove stuff from the databus or it'll interfere with the coming read from ROM etc. and that's where the interrupt + pipeline latency causes uncertanities. You will need to read in some other signal too to let you know where exactly you are during the cycle and it will not be instant due to pipeline latency either. This is the one area i think you'll experience problems with while rest is relatively easy.

Any read/write in A130xx will pulse !TIME, that includes 68K, Z80 and VDP accesses. But timings will differ depending on who did the access.

[Chilly Willy]

What I'd do is put some cheap latch chips on the board. There's a number of cheap TTLs that would be suitable, and it doesn't add much to the board. Then latencies won't matter as long as you read/write the latches before the next access by the 68000 or Z80.

[themrcul]

Thanks guys, your help is invaluable.

Great news on the Z80 also pulling /TIME low when accessing the /TIME data range. That means that the Z80 can send "play sound" and "play instrument" commands to the ARM chip!

I have looked now at using 3.3V flash on the cart pcb extensively. It seems that if the 3.3V flash is implemented into the board, the fabrication of the pcbs could be fully automated (with 5V EEPROMS I would need to wipe/program then solder them all myself). However, if it is implemented correctly it would add around $10-$15 in costs, for orders of less than 1000 units.
Calculation is as follows for if anyone is interested:
All lines connected to the 3.3V flash need 5V<->3.3V steppers. Cypress recommends a SN74LVCH16245A for the data lines (that will do all 16), and then 2x SN74LVCH16244A for all the address lines (22 of them) and control lines (1 or 2 lines).
A linear regulator would also be needed to power the flash chip, something like a LT1117 or LT1121. The flash unit itself is ~$2.5.
That is between ~$6.7-$8.2 in parts. Once the capacitors/resistors are added, and the extra cost at pcb manufacture time that would be ~$10-$15, whereas EEPROMs would be $1.2 per chip.
If I am miscalculating this please correct me.

However I trust your experience Tiido, and hand soldering 1000+ EEPROMs is probably not a great way to spend a couple of weeks! Or finding out that the vendors selling them are lying about their stock levels. Or having dozens of them being DOA.
So in the end, going 3.3V is probably best, even with the loss of profit and added PCB complexity. It's a shame that no-one is manufacturing those EEPROMs anymore, but I guess technology marches on...

I now need to research what kinds of op-amps would work well to drive between 75ohm and 10Kohm without volume loss.

Also, with reads from the ARM chip for the purposes of loading save games, I think I have come up with a solution.
My current idea is to route the data lines from the MD like this:
1) data lines 0-7 from cart go to the outputs of a multiplexer
2) those lines also get routed to general I/O pins on the arm chip all configured as INPUTs.
3) data lines 8-15 go straight through a 5V <-> 3.3V stepper and from there to the 3.3V flash chip.
4) lines 0-7 from the flash chip go through a 3.3V <-> 5V stepper and then to input A of a multiplexer
5) lines 0-7 from ARM chip go to input B of the multiplexer. These lines are configured on the ARM chip as OUTPUTs.
6) /TIME signal chooses which input to route to output on the multiplexer. /TIME is also connected as an interrupt on the ARM chip.

When /TIME goes low, the multiplexer changes data lines to set B which is on the ARM chip. These lines go to a set of 8 general I/O on the ARM pre-configured as outputs. The ARM chip receives the interrupt, sets the data pins as they should be, and returns to normal code execution. All this, including the cool-down to return to normal operation should all be possible within 200ns.
When /TIME goes high, the multiplexer changes back to use the data lines connected to the flash chip, within ~3.3ns.

For writes sent to the ARM chip, the lines the interrupt code will read from to determine which command was sent are a different set from the lines used to output save game data above and are pre-configured as inputs to read the data as quickly as possible.

Having two sets of the D0-D7 lines to the ARM means I don't need to change their configuration depending on the interrupt received. They are always ready to go.

To load or save a game, first the MD sends the right command to say "I want to save" or "I want to load".
When the ARM gets this interrupt, it sets the global pointer to the save game data in it's own RAM to 0.
Then the MD enters a for loop to load the data into it's local in-ram array. It sends a "read next byte" or "write next byte" to the ARM chip.
On interrupt for loading data from the ARM to the MD, the ARM code loads the next byte from RAM for the save data and sets the output data pins to be 1s or 0s, whatever they should be, then increments the global counter for the save game data and returns from the interrupt. When saving the game, the ARM checks what the input pins are set to and set the in-RAM save data to the correct byte, increment the global save game data counter and release.
Once the game is fully saved, the MD can send a "commit save game" command to the ARM, and then the ARM will write the whole save game to it's permanent storage.

This all makes sense in my head. I hope I've made sense and that this idea isn't pure madness! Also, I hope that 160MHz is fast enough. It might not be and I might need 200MHz! Either that or the MD code will need to do a dummy instruction in between each read/write byte of save game data to ARM, to give it time to recover from the last interrupt.

Anyway, this is a very fun journey to be on, at least in the design phase. I'm sure I'll be pulling my hair out once I get a test PCB going with some components on it though!

[themrcul]

Hey fellas,
I am gearing up to purchase a few discovery boards for an ARM to test some code with, and hopefully get it playing sound as a first step.

What I am wondering is how best to hook the DAC outputs from the ARM chip up to the MD cart side on B1 and B3.

From what I have read is the MD expects 1vpp @75ohm loading on the audio lines - that is what the 32x puts out as well over those lines.
The ARM chip can nicely take in positive and negative voltage inputs as reference voltages for the DAC to output at. It appears to output at 4k ohms impedance.

I'm not sure if that impedance value is an issue, however I am having trouble working out how to provide +1V and -1V to the ARM chip from a single 5V supply.

I have looked at charge pumps, but the minimum voltage any reasonably priced units support is 1.5Vpp.
I have also looked at op-amps that only need a single positive power supply rail, such as the LM358 op-amp. However as an amp, it can't make the signal smaller.
Would a good solution be to use a linear power regulator to get the 5V power supply from the MD down to 1V, feed that as the positive power supply to the DAC input, and ground as the reference negative, and then feed the DAC output to the LM358 op-amp with a gain of 1.0? Or could possibly get a linear regulator to reduce 5V down to 0.5V, and use the op-amp to amplify 2x to get back to 1.0Vpp?

Is that a good idea or should I be looking at something else? I'm hoping that whatever is proposed works with both the MD1 and MD2 knowing the MD1's input impedance is 75 ohms and the MD2's input impedance being 10k ohms and aiming for a similar volume on both models for the same audio input.

Once this problem is solved, I can begin work on the sound engine of the ARM chip.

Thanks in advance!

[themrcul]

Ok, so I just learned that the LM358 op-amp can't create negative voltages from nowhere, so the signal will simply clip when attempting to drive it lower than 0V. Back to the drawing board on that plan at least!
The best I can come up with now is some sort of linear regulator to get +1V from the +5V source, then a charge pump to get -2V from the +5V source, then finally a voltage divider using two resistors on the -2V to get -1V. Those can then be fed into the ARM chip. The result may need to be fed into an op-amp to get the right impedance output necessary to drive both 75ohms and 10kohms.
Is that an ok idea? Or a stupid one?

[TmEE co.(TM)]

First of all signal from the DAC etc. is not gonna have a negative components so it is already biased above 0V. You will have to bias it exactly to 2.5V for best dynamic range with most opamps and also bias the opamp to that voltage also. You can use a small linear reg for that or some resistors+cap+buffer to create the bias voltage or perhaps use a dedicated voltage reference part. You'll have a pair of capaciors on the input and later on the output also. In theory you could do without the output ones but then you massively increase power use as the amp will have to fight that 75ohm load in idle condition too. 2.5V biased signal into 75ohm load is 33mA * 2 for stereo. Then you make sure your signal only swings +/-1.5V or less around the bias point so it stays in the +4...+1V range that a regular opamp can pass. You can increase it to +5...0V by using rail to rail in and/or out opamps. There will be further losses from the power buffer so you absoltuely want a rail to rail output type. LM358 has the advantage that its input and output both can touch 0V so your only complication is loss on the upper side of the range.
But if you want to avoid all the biasing stuff you'll absolutely need a negative rail that spans at least 3V below ground so it can handle the losses from opamp and power buffer, and more is merrier. You only need a pair of capacitors on input and bias the DAC output to 0V. A charge pump is probably not gonna work so well unless you can make it do much higher voltage (ideally -15V) because they cannot give out much current and will droop a lot. Inverting DC-DC conversion solution will be a far better idea. Also you absolutely cannot feed any negative voltage into the ARM chip (or most DACs for that matter), you will fry it, their outputs and DACs are all 0V to power supply based, and AGND cannot go below 0V.
Negative rail creation when you have none will take more parts and more expensive parts than all the bias stuff and you can see from the schematic there's not much to it.

Your two options :