Forums

I've only recently taken an active interest in SMS cart hardware, since I've been chomping at the bit for an SMS devcart. My experience with electronics and building stuff from components has been just about nothing, but since I've been collecting parts and researching building an eprom burner I've built up enough general understanding and confidence in the subject to at least have a look at bank switching roms and chips.

For some reason I had never really paid attention to bank switching hardware, and only now do I understand that (nearly) all the bankswitching logic is on the cart rom. well well.

I'd been wondering what would need to be done to be able to interface with a 128k+ [ep]rom, short of ripping up a sms cartridge (especially considering I think it'd be seven shades of awesome to acutally publish a homemade game with a real cart and all that).

Starting with the 315-5208 chip (128k bank switcher found in mike G's 'The Ninja' cart), I see that the following pins are used, and I'll speculate on the uses:

a0-a14 [IN]: address line from the z80. This is the 16 bit (minus one bit) address that the mapper uses will translate to a 17 bit (128k addressable) address to fetch from the rom, depending on the contents of the FCR's (Which are on the bank switching chip itself).

M0-7: Best I can tell this is just a-15 [in], inverted..? Since apparently this cart doesn't connect to the a15 on the cart slot.

a14-16 [OUT]: when mapper translates the address from the z80 these are the 'translated' upper bits, that is, these select the proper frames. Note that there are no a0-a13 [out]s, so it's assumed the chip only monitors the address lines coming in, and are otherwise connected directly to the rom unfiltered (untranslated). Hence the 16k frames.

d0-d2 [I/O?]: Used to monitor values written to the FCR's. Because they will only be in the range 0-7 (16k x 8 frames) only three data lines are needed to receive FCR changes, and the upper bits are 'masked' implicitly. I suppose the rom also detects reads from the FCR registers and 'answers' them itself, also in the 0-7 range. Like the lower address lines, these are also wired directly to the rom.

WR: Write request. Only used for FCR's I guess, to determine the difference between FCR reads and FCR writes, since this chip is not intended to drive sram equipped carts. Thus there is not WR [out] to the rom or elsewhere, only WR [in].

CE[IN] and CE[OUT]: I'm not sure what CE is.. is it a clock signal?

plus the usual voltage and ground.

That gives 25 i/o pins necessary to emulate this bank switching chip.

Something that occurs to me is that since the chip does not intercept the address lines a10 - a13, I don't see how it can insure that the first 1024 bytes are never swapped out. It could refuse to swap the first frame, but not 1024 bytes in particular. So I guess it just insures that the FCR's are initialized to 0, or else it doesn't swap the first frame at all. We could write some tests and put them on an eprom to try with that bank switcher in a real sms, if we were dying of curiousity.

So I've been looking into programmable (& cheap) MCU's that could
replace the functionality of the bank switching chip. I've had a look at the PIC MCU's from Microchip (www.microchip.com). I've had a preference for them because they're quick, cheap, affordable to program, widely used and have excellent documentation available form the manufacturers. However, I don't see many with the amount of IO pins I'd like to see (Except certain 68pin ones, which need special programmers that I can't afford, ain't so cheap, and seem like extreme overkill), so I'd consider other models if someone else knows of good ones to use. (Atmel maybe?).

I suppose a PIC with 20 i/o pins might be enough, if the address lines a2-a7 didn't need to be monitored. It could probably be safely assumed that something written to or read from $ffxx that made it to the cart interface was a paging register, and a0 & a1 could be used to determine which register it is...

Another mystery is: What about timing and latency? PICs can be pretty speedy, some of them (still very cheap, too) run as fast as 20mhz, and execute each instruction in just one cycle (except branches, which throw off the pipeline and thus take two). That could be enough to keep up with those pokey z80's, but I'm not sure how speed-sensitive the memory architecture is, and I still need the logic that scans for frame register changes...

I've been studying up on PIC assembly language, as well as electronics in general and SMS cart design, maybe one of these months I'll experiment with dev carts and memory mapping chip replacements, but right now I don't have a pic writer or eprom burner so I'm just tossing out ideas.

Of course, ideally one could design a 'perfect' backup unit/devcart with 4 (or more?) megabits of sram, a fast controller which intercepts -all- data and address lines, as well as a connection to a PC host for programming the rom and maybe even live debugging.

But in the meantime I need to find a few more bits and pieces for the eprom burner.

Quote

> CE[IN] and CE[OUT]: I'm not sure what CE is.. is it a clock signal?

_CE is Chip Enable, active low. When the SMS needs to read or write to RAM, for example, the _CE line on the cart port will be made high, and when it needs to read or write to ROM or FCRs it will be made low...

if(address<0xC000 || address>0xFFFB)
ce=low;
else
ce=high;

Something like that anyway.

For the CE output from the 5208 itself...

if(address<0xC000)
ce=low;
else
ce=high;

Quote

> plus the usual voltage and ground.

> That gives 25 i/o pins necessary to emulate this bank switching chip.

> Something that occurs to me is that since the chip does not intercept the address lines a10 - a13, I don't see how it can insure that the first 1024 bytes are never swapped out. It could refuse to swap the first frame, but not 1024 bytes in particular. So I guess it just insures that the FCR's are initialized to 0, or else it doesn't swap the first frame at all. We could write some tests and put them on an eprom to try with that bank switcher in a real sms, if we were dying of curiousity.

My guess is that, because commercial 128k games only use frame 2 for banking, the 5208 doesn't actually contain the logic to page the other two frames at all, so frames 0 and 1 will *always* be mapped to 0x0000 and 0x4000 in the ROM respectively, regardless of what is written to FFFD or FFFE. This makes implementing the logic a heck of a lot simpler.

The more advanced chips (5235/5365) will probably swap pages depending on what part of 0000-3FFF is being accessed.

Quote

> I suppose a PIC with 20 i/o pins might be enough, if the address lines a2-a7 didn't need to be monitored. It could probably be safely assumed that something written to or read from $ffxx that made it to the cart interface was a paging register, and a0 & a1 could be used to determine which register it is...

I'd say you'd need to determine -

Is FFFF being accessed? Read or write?

Is (0000 to 7FFF) being accessed? (_M0-7 can be used for this, it serves the exact same function as A15 as far as I can see.)

Is (8000 to BFFF) being accessed? (Hence page in the appropriate frame.)

You could use external logic to decode the addresses, rather than have the MCU handle this. This reduces the number of inputs you'd need.

Zoop mentioned a pirate GG cart of Dead Angle, where it seems the pirates used a programmable array logic device of some kind to duplicate the functions of the banking chip. This would be another possible approach to the same problem.

Mike

Actually, thinking about it further, if _CE on the cart is low then *anything* read or written above BFFF should be a paging register. You only need a0,a1 to determine which one.

Mike

Quote

> My guess is that, because commercial 128k games only use frame 2 for banking, the 5208 doesn't actually contain the logic to page the other two frames at all, so frames 0 and 1 will *always* be mapped to 0x0000 and 0x4000 in the ROM respectively, regardless of what is written to FFFD or FFFE. This makes implementing the logic a heck of a lot simpler.

Aside from what it says in the SMSARCH document, can anyone confirm that 128K games only use frame 2 for banking, (and that the 5208 only supports mapping through frame 2)? I know this is the current theory, and I could not copy 128K games unless I only used frame 2, but my copier wasn't that reliable. Mike G., would it be possible to write a quick test to run on you EPROM cart? I could write the test for you, if necessary.

Quote

> Aside from what it says in the SMSARCH document, can anyone confirm that 128K games only use frame 2 for banking, (and that the 5208 only supports mapping through frame 2)? I know this is the current theory, and I could not copy 128K games unless I only used frame 2, but my copier wasn't that reliable. Mike G., would it be possible to write a quick test to run on you EPROM cart? I could write the test for you, if necessary.

No problem Eric - if you can write a suitable test program, I'll run it on my 5208 based cart and see what happens.

Mike

Quote

> > CE[IN] and CE[OUT]: I'm not sure what CE is.. is it a clock signal?

> _CE is Chip Enable, active low. When the SMS needs to read or write to RAM, for example, the _CE line on the cart port will be made high, and when it needs to read or write to ROM or FCRs it will be made low...

..so the banking chip intercepts CE so it can 'swallow up' any read/write requests to the bankinbg registers to make sure the rom won't answer it with anything? (and thus it can be assumed that the data lines will be all zero coming from the rom, and the mapper can respond with the currently used bank in d0-d2 without any 'noise' on the other pins.. I was wondering how that was done).
I suppose if I took the microcontroller approach I could make sure I set it last so that if setting all the pins that go to the eprom takes multiple instructions I can wait until they're all in place before I trigger it.

Quote

> if(address<0xC000 || address>0xFFFB)
> ce=low;
> else
> ce=high;

Intersting about the Chip Enable thing, I'm starting to see how the data/address bus works (it all goes out over the same path, but some sort of logic on the bus sends _CE or equivelant only to the ram or rom, depending on the address...? )

Quote

> For the CE output from the 5208 itself...

> if(address<0xC000)
> ce=low;
> else
> ce=high;

as mentioned above, I assume the ce out is also high/disabled if the address is greater than $fffb

Quote

> My guess is that, because commercial 128k games only use frame 2 for banking, the 5208 doesn't actually contain the logic to page the other two frames at all, so frames 0 and 1 will *always* be mapped to 0x0000 and 0x4000 in the ROM respectively, regardless of what is written to FFFD or FFFE. This makes implementing the logic a heck of a lot simpler.

Probably so. I suppose the external mappers provide only a subset of the functionality of the integrated banking roms.
And I also suppose that sega were aware that they'd have to use standard roms on occasion and told the programmers not to depend on all the features that the full banking roms provide (such as the guarantee that the first 1024 bytes wouldn't be translated, and the use of all three FCR's.) in case they'd need to make a run of carts with external mappers.

Quote

> The more advanced chips (5235/5365) will probably swap pages depending on what part of 0000-3FFF is being accessed.

>

> I'd say you'd need to determine -

> Is FFFF being accessed? Read or write?

> Is (0000 to 7FFF) being accessed? (_M0-7 can be used for this, it serves the exact same function as A15 as far as I can see.)

> Is (8000 to BFFF) being accessed? (Hence page in the appropriate frame.)

> You could use external logic to decode the addresses, rather than have the MCU handle this. This reduces the number of inputs you'd need.

you're probably right, I tend to favor using MCU's for everything I can because it's a paradigm I understand. I do love the idea of a little one-chip computer with memory, opcodes, and i/o in a plastic DIP. and I can control ALL IO PINS! BEHOLD YOUR MASTER, PINS!

FPGA's, logic gates, too close to the electronic engineering, and that spooks me. But I'm getting better.

Quote

> Zoop mentioned a pirate GG cart of Dead Angle, where it seems the pirates used a programmable array logic device of some kind to duplicate the functions of the banking chip. This would be another possible approach to the same problem.

probably so, at least a simple one register banking system might not be so hard to pull off.

While sketching out a pseudocode outline for an MCU 'main loop' I got to wondering if there's anyway to test if the cartridge is 'done' reading the result of a rom request (does _CEin return high between requests, or does it stay high until it moves into RAM territory?)
that'll affect the programming strategy I'd take.

Author	Message
Heliophobe Site Admin Joined: 25 Oct 1999 Posts: 2029 Location: Monterey, California	Bank switching chip replacements... Posted: Wed Jul 19, 2000 11:27 pm
	I've only recently taken an active interest in SMS cart hardware, since I've been chomping at the bit for an SMS devcart. My experience with electronics and building stuff from components has been just about nothing, but since I've been collecting parts and researching building an eprom burner I've built up enough general understanding and confidence in the subject to at least have a look at bank switching roms and chips. For some reason I had never really paid attention to bank switching hardware, and only now do I understand that (nearly) all the bankswitching logic is on the cart rom. well well. I'd been wondering what would need to be done to be able to interface with a 128k+ [ep]rom, short of ripping up a sms cartridge (especially considering I think it'd be seven shades of awesome to acutally publish a homemade game with a real cart and all that). Starting with the 315-5208 chip (128k bank switcher found in mike G's 'The Ninja' cart), I see that the following pins are used, and I'll speculate on the uses: a0-a14 [IN]: address line from the z80. This is the 16 bit (minus one bit) address that the mapper uses will translate to a 17 bit (128k addressable) address to fetch from the rom, depending on the contents of the FCR's (Which are on the bank switching chip itself). M0-7: Best I can tell this is just a-15 [in], inverted..? Since apparently this cart doesn't connect to the a15 on the cart slot. a14-16 [OUT]: when mapper translates the address from the z80 these are the 'translated' upper bits, that is, these select the proper frames. Note that there are no a0-a13 [out]s, so it's assumed the chip only monitors the address lines coming in, and are otherwise connected directly to the rom unfiltered (untranslated). Hence the 16k frames. d0-d2 [I/O?]: Used to monitor values written to the FCR's. Because they will only be in the range 0-7 (16k x 8 frames) only three data lines are needed to receive FCR changes, and the upper bits are 'masked' implicitly. I suppose the rom also detects reads from the FCR registers and 'answers' them itself, also in the 0-7 range. Like the lower address lines, these are also wired directly to the rom. WR: Write request. Only used for FCR's I guess, to determine the difference between FCR reads and FCR writes, since this chip is not intended to drive sram equipped carts. Thus there is not WR [out] to the rom or elsewhere, only WR [in]. CE[IN] and CE[OUT]: I'm not sure what CE is.. is it a clock signal? plus the usual voltage and ground. That gives 25 i/o pins necessary to emulate this bank switching chip. Something that occurs to me is that since the chip does not intercept the address lines a10 - a13, I don't see how it can insure that the first 1024 bytes are never swapped out. It could refuse to swap the first frame, but not 1024 bytes in particular. So I guess it just insures that the FCR's are initialized to 0, or else it doesn't swap the first frame at all. We could write some tests and put them on an eprom to try with that bank switcher in a real sms, if we were dying of curiousity. So I've been looking into programmable (& cheap) MCU's that could replace the functionality of the bank switching chip. I've had a look at the PIC MCU's from Microchip (www.microchip.com). I've had a preference for them because they're quick, cheap, affordable to program, widely used and have excellent documentation available form the manufacturers. However, I don't see many with the amount of IO pins I'd like to see (Except certain 68pin ones, which need special programmers that I can't afford, ain't so cheap, and seem like extreme overkill), so I'd consider other models if someone else knows of good ones to use. (Atmel maybe?). I suppose a PIC with 20 i/o pins might be enough, if the address lines a2-a7 didn't need to be monitored. It could probably be safely assumed that something written to or read from $ffxx that made it to the cart interface was a paging register, and a0 & a1 could be used to determine which register it is... Another mystery is: What about timing and latency? PICs can be pretty speedy, some of them (still very cheap, too) run as fast as 20mhz, and execute each instruction in just one cycle (except branches, which throw off the pipeline and thus take two). That could be enough to keep up with those pokey z80's, but I'm not sure how speed-sensitive the memory architecture is, and I still need the logic that scans for frame register changes... I've been studying up on PIC assembly language, as well as electronics in general and SMS cart design, maybe one of these months I'll experiment with dev carts and memory mapping chip replacements, but right now I don't have a pic writer or eprom burner so I'm just tossing out ideas. Of course, ideally one could design a 'perfect' backup unit/devcart with 4 (or more?) megabits of sram, a fast controller which intercepts -all- data and address lines, as well as a connection to a PC host for programming the rom and maybe even live debugging. But in the meantime I need to find a few more bits and pieces for the eprom burner.

Mike G Joined: 21 Apr 2000 Posts: 598 Location: Newcastle upon Tyne, England	Posted: Thu Jul 20, 2000 10:04 am
	Quote > CE[IN] and CE[OUT]: I'm not sure what CE is.. is it a clock signal? _CE is Chip Enable, active low. When the SMS needs to read or write to RAM, for example, the _CE line on the cart port will be made high, and when it needs to read or write to ROM or FCRs it will be made low... if(address<0xC000 \|\| address>0xFFFB) ce=low; else ce=high; Something like that anyway. For the CE output from the 5208 itself... if(address<0xC000) ce=low; else ce=high; Quote > plus the usual voltage and ground. > That gives 25 i/o pins necessary to emulate this bank switching chip. > Something that occurs to me is that since the chip does not intercept the address lines a10 - a13, I don't see how it can insure that the first 1024 bytes are never swapped out. It could refuse to swap the first frame, but not 1024 bytes in particular. So I guess it just insures that the FCR's are initialized to 0, or else it doesn't swap the first frame at all. We could write some tests and put them on an eprom to try with that bank switcher in a real sms, if we were dying of curiousity. My guess is that, because commercial 128k games only use frame 2 for banking, the 5208 doesn't actually contain the logic to page the other two frames at all, so frames 0 and 1 will always be mapped to 0x0000 and 0x4000 in the ROM respectively, regardless of what is written to FFFD or FFFE. This makes implementing the logic a heck of a lot simpler. The more advanced chips (5235/5365) will probably swap pages depending on what part of 0000-3FFF is being accessed. Quote > I suppose a PIC with 20 i/o pins might be enough, if the address lines a2-a7 didn't need to be monitored. It could probably be safely assumed that something written to or read from $ffxx that made it to the cart interface was a paging register, and a0 & a1 could be used to determine which register it is... I'd say you'd need to determine - Is FFFF being accessed? Read or write? Is (0000 to 7FFF) being accessed? (_M0-7 can be used for this, it serves the exact same function as A15 as far as I can see.) Is (8000 to BFFF) being accessed? (Hence page in the appropriate frame.) You could use external logic to decode the addresses, rather than have the MCU handle this. This reduces the number of inputs you'd need. Zoop mentioned a pirate GG cart of Dead Angle, where it seems the pirates used a programmable array logic device of some kind to duplicate the functions of the banking chip. This would be another possible approach to the same problem. Mike

Mike G Joined: 21 Apr 2000 Posts: 598 Location: Newcastle upon Tyne, England	Posted: Thu Jul 20, 2000 10:16 am
	Actually, thinking about it further, if _CE on the cart is low then anything read or written above BFFF should be a paging register. You only need a0,a1 to determine which one. Mike

Eric R. Quinn Joined: 18 Sep 1999 Posts: 498 Location: Portland, Oregon USA	Posted: Thu Jul 20, 2000 3:55 pm
	Quote > My guess is that, because commercial 128k games only use frame 2 for banking, the 5208 doesn't actually contain the logic to page the other two frames at all, so frames 0 and 1 will always be mapped to 0x0000 and 0x4000 in the ROM respectively, regardless of what is written to FFFD or FFFE. This makes implementing the logic a heck of a lot simpler. Aside from what it says in the SMSARCH document, can anyone confirm that 128K games only use frame 2 for banking, (and that the 5208 only supports mapping through frame 2)? I know this is the current theory, and I could not copy 128K games unless I only used frame 2, but my copier wasn't that reliable. Mike G., would it be possible to write a quick test to run on you EPROM cart? I could write the test for you, if necessary.

Mike G Joined: 21 Apr 2000 Posts: 598 Location: Newcastle upon Tyne, England	Posted: Thu Jul 20, 2000 5:19 pm
	Quote > Aside from what it says in the SMSARCH document, can anyone confirm that 128K games only use frame 2 for banking, (and that the 5208 only supports mapping through frame 2)? I know this is the current theory, and I could not copy 128K games unless I only used frame 2, but my copier wasn't that reliable. Mike G., would it be possible to write a quick test to run on you EPROM cart? I could write the test for you, if necessary. No problem Eric - if you can write a suitable test program, I'll run it on my 5208 based cart and see what happens. Mike

Heliophobe Site Admin Joined: 25 Oct 1999 Posts: 2029 Location: Monterey, California	Posted: Fri Jul 21, 2000 12:46 am
	Quote > > CE[IN] and CE[OUT]: I'm not sure what CE is.. is it a clock signal? > _CE is Chip Enable, active low. When the SMS needs to read or write to RAM, for example, the _CE line on the cart port will be made high, and when it needs to read or write to ROM or FCRs it will be made low... ..so the banking chip intercepts CE so it can 'swallow up' any read/write requests to the bankinbg registers to make sure the rom won't answer it with anything? (and thus it can be assumed that the data lines will be all zero coming from the rom, and the mapper can respond with the currently used bank in d0-d2 without any 'noise' on the other pins.. I was wondering how that was done). I suppose if I took the microcontroller approach I could make sure I set it last so that if setting all the pins that go to the eprom takes multiple instructions I can wait until they're all in place before I trigger it. Quote > if(address<0xC000 \|\| address>0xFFFB) > ce=low; > else > ce=high; Intersting about the Chip Enable thing, I'm starting to see how the data/address bus works (it all goes out over the same path, but some sort of logic on the bus sends _CE or equivelant only to the ram or rom, depending on the address...? ) Quote > For the CE output from the 5208 itself... > if(address<0xC000) > ce=low; > else > ce=high; as mentioned above, I assume the ce out is also high/disabled if the address is greater than $fffb Quote > My guess is that, because commercial 128k games only use frame 2 for banking, the 5208 doesn't actually contain the logic to page the other two frames at all, so frames 0 and 1 will always be mapped to 0x0000 and 0x4000 in the ROM respectively, regardless of what is written to FFFD or FFFE. This makes implementing the logic a heck of a lot simpler. Probably so. I suppose the external mappers provide only a subset of the functionality of the integrated banking roms. And I also suppose that sega were aware that they'd have to use standard roms on occasion and told the programmers not to depend on all the features that the full banking roms provide (such as the guarantee that the first 1024 bytes wouldn't be translated, and the use of all three FCR's.) in case they'd need to make a run of carts with external mappers. Quote > The more advanced chips (5235/5365) will probably swap pages depending on what part of 0000-3FFF is being accessed. > > I'd say you'd need to determine - > Is FFFF being accessed? Read or write? > Is (0000 to 7FFF) being accessed? (_M0-7 can be used for this, it serves the exact same function as A15 as far as I can see.) > Is (8000 to BFFF) being accessed? (Hence page in the appropriate frame.) > You could use external logic to decode the addresses, rather than have the MCU handle this. This reduces the number of inputs you'd need. you're probably right, I tend to favor using MCU's for everything I can because it's a paradigm I understand. I do love the idea of a little one-chip computer with memory, opcodes, and i/o in a plastic DIP. and I can control ALL IO PINS! BEHOLD YOUR MASTER, PINS! FPGA's, logic gates, too close to the electronic engineering, and that spooks me. But I'm getting better. Quote > Zoop mentioned a pirate GG cart of Dead Angle, where it seems the pirates used a programmable array logic device of some kind to duplicate the functions of the banking chip. This would be another possible approach to the same problem. probably so, at least a simple one register banking system might not be so hard to pull off. While sketching out a pseudocode outline for an MCU 'main loop' I got to wondering if there's anyway to test if the cartridge is 'done' reading the result of a rom request (does _CEin return high between requests, or does it stay high until it moves into RAM territory?) that'll affect the programming strategy I'd take.

Forums

View topic - Bank switching chip replacements...