Add feature to a cart

[KanedaFr]

Hi,

It's something I really like to be able for a long time but I lack knowledge : how to add feature to a cart ?
Don't worry, I don't want to create a game with 32Mo rom, mp3 support or whatever, it's for debugging purpose.

From db-elec, I know I should not consume more than 100ma
(viewtopic.php?f=13&t=1931)
From an old post, I know I could power the extra 'layer' if ground is shared
(viewtopic.php?p=15138#p15138)
From current SRAM thread, I learnt more details
(viewtopic.php?f=2&p=28229)
From an old post by Eke, it seems we can, in fact, write to any address. The write signal is used to make the diff between ROM and others .... but read isn't possible in that case, right ?
(viewtopic.php?p=12645#p12645)

What I miss is how to communicate with my extra layer ?
Let see severals level of 'feature'

- SRAM:
* doesn't need extra power
* direct connection
* 8bit (odd or even from the 16 bit data bus)
* use VA21, so limit max ROM size


- SRAM (serial):
* doesn't need extra power
* serial comm on an unique adress (0x200001 for ex)
* direct connection
* use VA21, so limit max ROM size

J Cart
* eeprom and additionnal io share the same adresse
(https://github.com/ekeeke/Genesis-Plus- ... i2c.c#L809)


- SSF2
* mapper to switch part of memory

- lock on
* CPLD ?

- Virtua Racing
* doesn't need extra power
* add a dedicated IC
* use its own memory map


- UMDK :
* add an IC
* powered by usb
* no communication
* data protection using buffer (so no direct connection)
* no memory shared (IC can't access to MD memory)

- SMD
* add a CPLD
* powered by cart
* share memory

- Channel / X Band
* complex sys on a cart !

- 32X
* ....WOW


So, if I want to add an AVR on a cart and to control, from it, several others modules (ex: bluetooth for faster serial transfert)
how could I power it ?
how could I communicate with it , with a minimal of GPIO pin use and a small address map ?
how could the AVR access to MD memory (joy included) ?
To avoid the 3.3v / 5v debate, I'll use a 5V avr, don't know if I'll use 3.3V modules yet...

I think an AVR powered from its own (smartphone usb) adapter using the SRAM comm and address could be used but what if I need more ?

any project to share ?

(another way was to use the ext port, like the modem, but it's slow and even more limited)

[Charles MacDonald]

So, if I want to add an AVR on a cart and to control, from it, several others modules (ex: bluetooth for faster serial transfert)
how could I power it ?

It's OK to just use the +5V from the cartridge port directly, it seems unlikely what you are adding will use more current than is available. Otherwise adding a second +5V power supply (even from a USB cable connected to a PC) is something of a complex problem

how could I communicate with it , with a minimal of GPIO pin use and a small address map ?

It depends if you want bidirectional or unidirectional communication, and what speed you want to transfer data at. To use minimal GPIO you will probably want to send data serially.

For a simple example here's a schematic for unidirectional communication from the 68000 to the AVR. I made this quickly so it's probably got errors, but I just want to illustrate the concept:

https://www.dropbox.com/s/n4r4tx9fssjfh ... m.png?dl=1

This scheme uses five GPIOs on the AVR (perhaps that can be reduced) and the /TIME region of the 68000 as follows:

Code: Select all

$A130F1 : Read to input communication busy status in D0
$A130F1 : Write to load shift register with 8 bits of data for the AVR to read

The 68000 can write to any offset in the TIME region ($A130Fx) to load 8 bits of data into a shift register and set a flip-flop to '1', which is normally cleared when the 68000 is reset such as on power-up. The AVR can poll the flip-flop output (AVR_STAT) and wait for it to get set to '1', at which point it knows there is data in the shift register. It can then transfer the data from the 68000 side to the AVR side by strobing AVR_LOAD and read out data serially using AVR_DATA and strobing AVR_SHIFT each time to get another bit. Finally, it can strobe AVR_ACK to clear the flip-flop to '0'.

During this time the 68000 can wait for the AVR to finish reading data by reading an offset in the TIME region to get the state of the flip-flop in D0.

Here's the code:

Code: Select all

68000 code:

void com_send(uint8 data)
{
	volatile uint8 *comreg = (volatile uint8 *)0xA130F1;
	
	// Load data into shift register and set flip-flop to tell AVR data is ready
	*comreg = data;

	// Wait for flip-flop to be reset by AVR strobe
	while(*comreg & 1)
		;
}

AVR code:

uint8 com_read(void)
{
	uint8 data = 0;
	
	// Wait for flip-flop to be set by 68K write
	while(!(AVR_STAT & 1))
		;

	// Transfer data from storage register (68000 side)
	// to shift register (AVR side)
	AVR_LOAD = 1; 
	AVR_LOAD = 0;

	// Shift out 8 bits of data
	for(int i = 0; i < 8; i++)
	{
		data = (data << 1) | AVR_DATA;
		AVR_SHIFT = 1;
		AVR_SHIFT = 0;
	}	

	// Clear flip-flop
	AVR_ACK = 1; 
	AVR_ACK = 0;

	return data;
}

You can modify the circuit to use a specific (single) address in the 68000 memory map rather than the entire TIME range. I wanted to keep the address decoding simple for the sake of this example.

how could the AVR access to MD memory (joy included) ?

It can't, unfortunately. There is no mechanism on the cartridge port to gain control of the system. The 68000 will always control the data, address, and control bus.

[KanedaFr]

wow !

Charles did it again !
i didn't ask about /time because i was afraid to use it (Read/write using VA/VD is a lot easier!) but thanks !

undirectional is clearly my first goal.
In fact, i though to use a EA game and hook the eeprom pin but I didn't know how to handle the ACK...

so...thanks !!!!

[Charles MacDonald]

Sometimes you see communication methods where there is no handshaking (acknowledgement or status indicators) and I don't know how they are supposed to work reliably.

I realized since the circuit has a 74HCT74 there's a 2nd flip-flop we can use, so I expanded the schematic a little. Now when you write to $A130F1 or $A130F3 the location accessed is saved in a flip-flop, which you can read out through AVR_C/D. This way one location ($A130F1) can be the 'command' port, and the other ($A130F3) can be the 'data' port.

https://www.dropbox.com/s/8sqwlouczfb5e ... 2.png?dl=0

The AVR can read the state of AVR_C/D to determine which address was accessed. Communication is still just one byte at a time, but now data bytes can be categorized as being command bytes or data bytes. It can be helpful for synchronization, the 68000 can write some specific command byte to tell the AVR to restart an operation.

For example you could use this to send a string to the AVR and perhaps have it transmit it over the AVR's UART.

Code: Select all

#define CMD_PUTS 0x8A
void com_puts(char *str)
{
	volatile uint8 *cmd_reg = (volatile uint8 *)0xA130F1;
	volatile uint8 *dat_reg = (volatile uint8 *)0xA130F3;
	volatile uint8 *stat_reg = (volatile uint8 *)0xA130F1;

	/* Send command byte (tell AVR to accept a string) */
	*cmd_reg = CMD_PUTS;

	/* Wait for command to be read */
	while(*stat_reg & 1)
		;

	/* Transfer string */
	for(int i = 0; i < strlen(str); i++)
	{
		/* Send string a byte at a time */
		*dat_reg = str[i];

		/* Wait for each byte to be read */		
		while(*stat_reg & 1)		
			;
	}		
}

i didn't ask about /time because i was afraid to use it (Read/write using VA/VD is a lot easier!) but thanks !

I think I had posted on spritesmind a while back about safe places to map extra hardware, and for example you can put things in $Bxxxxx if you don't want to conflict with 32X, Sega CD etc. But if you don't need to worry about such things the circuit can fit anywhere in memory, like $200000, etc.

EDIT:

I couldn't resist, sorry. Here's full bidirectional. It uses 7 AVR GPIOs but you could remove the command/data feature to make it 6 GPIOs. With this method every unit of data transfer is an exchange of bytes between the 68K and AVR which keeps the hardware simple.

https://www.dropbox.com/s/ntrx6q1g2ggyw ... 3.png?dl=0

Code: Select all

volatile uint8 *cmd_out  = (volatile uint8 *)0xA130F1;
volatile uint8 *stat_in  = (volatile uint8 *)0xA130F1;
volatile uint8 *data_out = (volatile uint8 *)0xA130F3;
volatile uint8 *data_in  = (volatile uint8 *)0xA130F3;

uint8 gen_xchg_byte(char type, char data)
{
	// Send data to AVR as a command or data byte
	if(type)
		*cmd_out = data;
	else
		*data_out = data;	

	// Wait for AVR to read byte and write new one
	while(*stat_in & 1)
		;

	// Get new byte		
	return *data_in;
}

#define AVR_STAT	P0.0	// 1= 68K wrote byte, 0= No data written
#define AVR_DOUT	P0.1	// Output to shift register
#define AVR_DIN 	P0.2	// Input from shift register
#define AVR_SHIFT	P0.3	// Common shift flock for input/output shift registers
#define AVR_LOAD	P0.4	// Load AVR register with 68K data output
#define AVR_ACK	 	P0.5	// Strobe to clear status flag and load AVR data output into 68K register
#define AVR_CD	 	P0.6	// 68K byte was 0=cmd, 1=data

uint16 avr_xchg_byte(char data, bool &is_cmd)
{
	uint8 result = 0;
   
    // Wait for flip-flop to be set by 68K write
    while(!(AVR_STAT & 1))
       ;

    // Transfer data from storage register (68000 side)
    // to shift register (AVR side)
    AVR_LOAD = 1;
    AVR_LOAD = 0;

    // Shift out 8 bits of data
    for(int i = 0; i < 8; i++)
    {
       /* Output data bit */
       AVR_DOUT = (data & 1);

       /* Input data bit */
       result = (result << 1) | AVR_DIN;

       /* Shift bit positions */
       AVR_SHIFT = 1;
       AVR_SHIFT = 0;
    }   

	// Get byte type (command or data)
    is_cmd = (bool)AVR_CD;

    // Clear flip-flop and load output byte into 68000-side storage register
    AVR_ACK = 1;
    AVR_ACK = 0;

    return result;
}

I'll stop now. There are many other ways to do this like put the design in a CPLD, or change the data size to 16 bits or even 4 bits.

[KanedaFr]

again, awesome !

Based on this and some others google search, i found 7 ways to add hardware on a cart.
Let me know if I made a mistake and jump to my questions on the end

1/ the Xin1 way :
using a counter, each reset give access to a dedicated address range
for ex:
http://blog.naver.com/mami0071/80204397043 (B27 is /RESET)

2/ the SRAM-for-less-than-16M way :
between (rom size) and 0x3FFFFF, address is decoded using some 74xxx to toggle between ROM and SRAM
for ex :
?? did I read NBA Jam used this way ??

3/ the bad way :
same than 2/ but using the reserved address too
0x400000 - 0x7FFFFF => MCD/32X won't work anymore
0x800000 - 0x9FFFFF => 32X definitly out
for ex :
?? I remember I read on this forum some chineses games are mapped this way ??

4/ the dtack-missing way
using the reserved but never used address range
Charles found (viewtopic.php?t=1283) 0xBxxxxx to be the only address range not used.
But it need DTACK signal and I clearly don't know how to achieve this
for ex:
none example known

5/ the time-is-ce way
Like Mike told me on twitter yesterday, you can use /TIME like a Chip Enable signal
With a nand gate, simply disable CE on ROM at the same time
using this way give you own 256 addresses (from $A13000 to $A130FF) to write a byte
(see below for question about byte / word)
it's up to you to combine /TIME with addresses and, thanks to some logic gates, set an memory mapper (see 7)
Ex:
See Charles first sample on this same thread

6/ the time-data way
When writing to 0xA130xx, D0-D7 is the ID of the hardware you want to talk with
the classic way to handle SRAM uses this since you have to write
0 - to enable ROM
1 - to enable SRAM
we will avoid 2 and 3,because of the WriteProtect bit but you could use 4 to 0xF to define access to another hardware
Ex:
every SRAM based game ! when remap 0x200000 to SRAM / ROM according TIME & DO value
(see http://forums.nesdev.com/viewtopic.php?f=23&t=11615 for Tiido's way)

7/ the time-address way
Like 6 but it's not D0-D7 which define the hardware ID but A7-A1
Ex:
Sega Mapper (SSF2)
Extended everdrive mapper (http://krikzz.com/pub/support/mega-ed/d ... ssf-v2.txt)
32X
SVP
Sega Channel (https://github.com/ekeeke/Genesis-Plus- ... rt.c#L1865)


Time 101

Code: Select all

volatile uint8 *hw_address  = (volatile uint8 *)0xA130F1;
*hw_address = 0x2F;

- set /TIME to low (does anything append to /CE at the same time ?)
- set A7-A1 to 0xF1
- set /LWR to low (we write a byte)
- set D7-D0 to 0x2F

Code: Select all

volatile uint8 *hw_address  = (volatile uint8 *)0xA130F1;
data = *hw_address;

- set /TIME to low (does anything append to /CE at the same time ?)
- set A7-A1 to 0xF1
- set /CAS0 to low (we write a byte)
- get data from D7-D0


Questions
- how is it possible to generate DTACK ? I understood it means address is available on the address bus but who defined it (when it's ready) ?
- you need to use /UWR and /LWR for write, /CAS0 for read.... does it mean you could write byte/word but read word only ?
- how to you set /UWR to low ? using

uint16 *hw_address = (volatile uint8 *)0xA130F2; *hw_address = 0xDEAD;

? but it will set /LWR to low too no ?
- I found several several cart pinouts. Can you confirm /CAS0 is B16 (and not B21) ?
- on every info I read about SRAM, I never found detail about the D1 (WriteProtect) bit .... Does even one game use it (I mean on the cart, not on the code) to really avoid write error ?
- how do you know which 74xxx to use based on a truth or Karnaugh table ( like on http://blog.naver.com/mami0071/80204397301) ? it's perhaps a stupid question because the table define the nor/nand/and/... rules but how do you a 74138 or 74139 will handle these with just one chip ? a perhaps the question is "what the most used 74xxx ?"
- I didn't see a mention of the battery saving chip (or what ever it must be called), I see some reference like the BA6162 on http://jazz-disassemblies.blogspot.fr/2 ... g.html?m=1 or the MM1026 on PStar2 at http://blog.naver.com/mami0071/220335772170 but I never see someone adding it on a schematic ?
- could I use nvsram to avoid the additional chip and battery ? or similar since it costs a lot again, even a 8x8bit one
- to finish with additional chip, I assume buffers should be used (like on dual comm defined on previous post). What is the rule ? buffer on 2 ways line (like VD) ? or shared lines (every!) ?

Thanks
To Charles every important thread on this subject is flooded by his very useful info
(viewtopic.php?p=12650#p12650 is the best)
To Tiido because he add useful info (like on this old post viewtopic.php?t=235) and draw easy to read schematic (!!)

[KanedaFr]

It's OK to just use the +5V from the cartridge port directly, it seems unlikely what you are adding will use more current than is available. Otherwise adding a second +5V power supply (even from a USB cable connected to a PC) is something of a complex problem

where did I read you only have to be sure Ground is shared .......?

[Charles MacDonald]

- how is it possible to generate DTACK ? I understood it means address is available on the address bus but who defined it (when it's ready) ?

You assert DTACK when you detect the address range you want is being accessed, meaning /AS is low and the address lines match the address range you want. For example if you wanted to generate DTACK for 0x800000-0x9FFFFF, you could drive DTACK low when /AS is low, A23 is high, A22 is low, and A21 is low. Normally you will do this as soon as possible, but you can delay asserting DTACK if you want to use slower memory.

Remember that DTACK is shared with other components in the system so you need an open collector buffer (or similar) to drive it. For example 74LS07 or 74LS125.

you need to use /UWR and /LWR for write, /CAS0 for read.... does it mean you could write byte/word but read word only ?

Yes, all reads are word only. But the 68000 will ignore the extra data on the data bus when reading memory, so it doesn't cause a problem. This is a very common design choice, but rarely you'll find hardware that really does decode lower and upper read strobes. It just isn't necessary.

- how to you set /UWR to low ? using

uint16 *hw_address = (volatile uint8 *)0xA130F2; *hw_address = 0xDEAD;

? but it will set /LWR to low too no ?

If you write byte data to an even address it asserts UWR
If you write byte data to an odd address it asserts LWR
If you write word data to an even address it asserts both LWR and UWR

In some designs where you intend to access word data only, you can just check UWR. This is a simplification, it isn't really needed to check both LWR and UWR for detecting word writes.

- I found several several cart pinouts. Can you confirm /CAS0 is B16 (and not B21) ?

Just go by the service manuals or the schematic (linked blow), they are all accurate
http://emudocs.org/Genesis/mega1.png

CAS0 is B16.

- on every info I read about SRAM, I never found detail about the D1 (WriteProtect) bit .... Does even one game use it (I mean on the cart, not on the code) to really avoid write error ?

I don't think any cartridges which discretely implement SRAM and the ROM banking at A130F1 support that bit, it's for games (which, maybe only SSF2?) that have a custom chip to handle that.

- how do you know which 74xxx to use based on a truth or Karnaugh table ( like on http://blog.naver.com/mami0071/80204397301) ? it's perhaps a stupid question because the table define the nor/nand/and/... rules but how do you a 74138 or 74139 will handle these with just one chip ? a perhaps the question is "what the most used 74xxx ?"

That's a complicated issue because it comes down to understanding digital logic design which is a very broad topic. In general when you determine the combinations of signals you want, you look at a TTL reference manual to find the chip that best supports those functions (AND, OR, etc.). You'll find the 74138 and 74139 used often as they perform decoding in a generic way, which is useful for address decoding purposes in microprocessor systems. Using a K-map helps you simplify complex logic so you can use less parts. There's a Windows tool called "Logic Friday" which is helpful for experimenting with logic optimization.

- I didn't see a mention of the battery saving chip (or what ever it must be called), I see some reference like the BA6162 on http://jazz-disassemblies.blogspot.fr/2 ... g.html?m=1 or the MM1026 on PStar2 at http://blog.naver.com/mami0071/220335772170 but I never see someone adding it on a schematic ?

There are two approaches for write-protecting SRAM during the time the system is powered up or powered down.

1. Small SRAMs have a second active-high chip select. It is common to connect these to a reset generator chip. You see this a lot in SMS and NES games. You also need two diodes to route 5V and 3V from the battery to the SRAM.

2. Large SRAMs only have a single chip select, so you an IC that controls the chip select based on battery power being available or not. This is what that BA6162 is for. In modern times this functionality is included in a "microprocessor supervisor" IC and they often include a reset generator and a built-in switch for handling SRAM power so you don't need to use diodes. ADM691 is such a chip.

For the curious, BA6162 datasheet: http://pdf1.alldatasheet.com/datasheet- ... A6162.html

- could I use nvsram to avoid the additional chip and battery ? or similar since it costs a lot again, even a 8x8bit one

You could, but they are very expensive. Some people like using FRAM but since Cypress bought out Ramtron it's hard to find FRAMs that are cheap.

- to finish with additional chip, I assume buffers should be used (like on dual comm defined on previous post). What is the rule ? buffer on 2 ways line (like VD) ? or shared lines (every!) ?

For a very small or simple cartridge maybe you can get away without using buffers. If you make a large cartridge with many components you probably want to buffer the data and address bus. So it depends on your design. If you use a chip that drives the data bus that does not have an output enable control then you definitely need a buffer to make up for that.

If you use buffers on the data bus you need to be careful about remembering when to turn them on; for example if you map ROM to the 000000-3FFFFF area and also use the TIME area at A130xx, you need to enable the buffers for both memory ranges.

where did I read you only have to be sure Ground is shared .......?

Hmm, well I didn't know if you meant to augment the +5V from the two regulators in the Genesis with +5V from an external source to help power the extra hardware in your cartridge. If you aren't doing that, don't worry about it and just make sure your grounds are all connected together.

[KanedaFr]

- how do you know which 74xxx to use based on a truth or Karnaugh table ( like on http://blog.naver.com/mami0071/80204397301) ? it's perhaps a stupid question because the table define the nor/nand/and/... rules but how do you a 74138 or 74139 will handle these with just one chip ? a perhaps the question is "what the most used 74xxx ?"

That's a complicated issue because it comes down to understanding digital logic design which is a very broad topic. In general when you determine the combinations of signals you want, you look at a TTL reference manual to find the chip that best supports those functions (AND, OR, etc.). You'll find the 74138 and 74139 used often as they perform decoding in a generic way, which is useful for address decoding purposes in microprocessor systems. Using a K-map helps you simplify complex logic so you can use less parts. There's a Windows tool called "Logic Friday" which is helpful for experimenting with logic optimization.

oh, useful tool !
I was looking how to make it by hand (http://drstienecker.com/tech-332/3-logi ... th-tables/) but this one will help a lot
and the C export is just awesome, could be used for game logic too, (to avoid if-else nightmare)

now I need a logic to 74xx list export tool !

- to finish with additional chip, I assume buffers should be used (like on dual comm defined on previous post). What is the rule ? buffer on 2 ways line (like VD) ? or shared lines (every!) ?

For a very small or simple cartridge maybe you can get away without using buffers. If you make a large cartridge with many components you probably want to buffer the data and address bus. So it depends on your design. If you use a chip that drives the data bus that does not have an output enable control then you definitely need a buffer to make up for that.

If you use buffers on the data bus you need to be careful about remembering when to turn them on; for example if you map ROM to the 000000-3FFFFF area and also use the TIME area at A130xx, you need to enable the buffers for both memory ranges.

so a good idea would be to drive a data bus.
-Set the address
-Set the data
-let the logic magic do the mapping
-open flow

where did I read you only have to be sure Ground is shared .......?

Hmm, well I didn't know if you meant to augment the +5V from the two regulators in the Genesis with +5V from an external source to help power the extra hardware in your cartridge. If you aren't doing that, don't worry about it and just make sure your grounds are all connected together.

yes, the goal is to have an uC (like AVR, teensy, arduino, whatever) powered by an external source (usb or DC adapter) talking with a powered genny, on TTL 5V level of course.
So ground connected does the trick ?
The same way you connect an embed device with a PC using USB-to-Serial (TX<->RX, RX<->TX, GND<->GND).
In the meantimes, I read it is to avoid with class II device (https://en.wikipedia.org/wiki/Appliance ... s#Class_II)

[doragasu]

Unless you need some kind of insulation (most circuits do not need it) the grounds of all subcircuits must be connected. If you use an external power source, make sure you do NOT connect both 5V rails (the one on the Megadrive and the external one). In fact, if you use an external power source, the best you can do is not using the Megadrive 5V rail at all.

There are lots of ways of connecting a peripheral to the Megadrive. For my WiFi cartridge I was balancing using a CPLD or a UART to connect the WiFi chip to the 68k bus. I finally went for the UART mainly for cost reasons.

[KanedaFr]

So you design an "external" system, connected with the genny only by the GND and the data/address/signal pins.
It makes sense...like UART

[troudki]

hi
i found this..
Sega Genesis YM2017 homebrew LED Visualizer
It's look great and open some feature to the futur homebrew games..
https://www.youtube.com/watch?time_cont ... YLJYL6sCgU

[Munkyears]

Sorry to necro this but wanted to explore this YM2017 cartridge

I found the creator
https://catskullelectronics.com/YM2017

Now this is fascinating, I dropped him an email to see if he could send me a pinout or schematic of this as I am interested to get some idea on how this is mapped

Anyone have any ideas/speculation on this?
Cheers!

[Chilly Willy]

Looked at the YT video - half the LEDs are covered by the console when plugged in! That wasn't thought out very well. He should have made the cart taller to compensate.