Forums

Many of you will be aware of port $3E on the SMS, which is written to by the BIOS to select the slot to be enabled:

Writing $EB followed by $E3 selects the BIOS ROM (_CE0)
Writing $EB followed by $CB selects the card slot (_CE2)
Writing $EB followed by $AB selects the cartridge slot (_CE3)
Writing $EB followed by $6B selects the expansion port (_CE4)

This effectively maps the stated slot into the Z80 address space. Given that the user RAM is always enabled at $C000-$FFFF, some address decoding must be performed inside the cartridge (or card).

Of course, all of the above writes must be done from a program running in user RAM, or a program could end up paging itself out! :-)

(There may be a means of doing things like disabling user RAM, mapping user RAM to the lower address space, or enabling specific 16K frames for a particular slot, but I don't know about that yet - some experimentation is needed!)

Anyway I was able to write a short program to dump the BIOS ROM inside the Master System. It relocates to user RAM at $D000 then performs the following: enables the BIOS slot, reads 1K from the BIOS into RAM at $C000, enables the cart slot, writes 1K from $C000 into the ROM area starting at $0000, and so on.

The (uncommented) source is here.

(Since the dev cartridge is writable it's possible to write to the "ROM area", overwriting the original program.)

Mike

SMSReader Project

Excellent! I was actually thinking about such program no later than yesterday.

Something that would be very interesting would be to see if once the BIOS is enabled, removing/plugging a cartridge doesnt hang the system.
If it doesnt, I don't think I need to explain the possibilities (you can throw away your soldering tools when dumping Codemasters cartridges :)

I'll do the test tonight.

Quote

> Many of you will be aware of port $3E on the SMS, which is written to by the BIOS to select the slot to be enabled:

>
> Writing $EB followed by $E3 selects the BIOS ROM (_CE0)
> Writing $EB followed by $CB selects the card slot (_CE2)
> Writing $EB followed by $AB selects the cartridge slot (_CE3)
> Writing $EB followed by $6B selects the expansion port (_CE4)

Allow me speculate a little here (some of this may already be obvious to some of you), but here goes:

The bits in the byte have the following meaning:

7	6	5	4	3	2	1	0
_CE4#	_CE3#	_CE2#	_CE1#	_CE0#	Unknown (must be 0?)	Unknown (must be 1?)	Unknown (must be 1?)

It seems that writing 0xEB first simply disables all the slots and puts the all bits into a known state (except _CE1# for some reason). The
next write disables one of the _CE?# lines, thus enabling one slot.

Three questions come to mind:

1.) Is the first 0xEB write always necessary? For example, if you (the program) knows that BIOS is mapped (0xE3)
would a single write of 0xAB be sufficient to map the cartridge slot? Perhaps the first 0xEB write is
necessary to prevent race conditions that could result when more then one bit changes in the byte (resulting in
more than one slot being enabled for a split second). Maybe someone with a dev-cart could try an experiment?

2.) Does bit 4 (_CE1#) have to be 0, what happens if it's set? I couldn't find _CE1# after a quick look at the SMS schematics. Can anybody else find a use for this signal?

3.) What are bits 0, 1 and 2 for? Do bits 1 and 0 need to be set? Does bit 2 always need to be reset?
Again, perhaps a quick test could be written and tried by someone with a dev-cart.

One last thing is the port itself, 0x3E. According to current information, port 0x3E should be equivalent to any even-numbered port between 0x00 and 0x3E. Another experiment could be to try to map different slots by writing to different ports, like 0x00, 0x0E, 0x30, 0x3C, etc.

Any takers?

--
Eric Quinn

Quote

> Allow me speculate a little here (some of this may already be obvious to some of you), but here goes:

> The bits in the byte have the following meaning:

>
>

7 6 5 4 3 2 1 0
>
_CE4# _CE3# _CE2# _CE1# _CE0# Unknown (must be 0?) Unknown (must be 1?) Unknown (must be 1?)
>

This is correct as far as I can see. The lower three bits don't seem to be significant; I tried setting them in different ways but the outcome wasn't affected.

It may be the case that they control other signals from the 315-5216/5237 - some further investigation might be needed.

Quote

> It seems that writing 0xEB first simply disables all the slots and puts the all bits into a known state (except _CE1# for some reason). The
> next write disables one of the _CE?# lines, thus enabling one slot.

> Three questions come to mind:

> 1.) Is the first 0xEB write always necessary? For example, if you (the program) knows that BIOS is mapped (0xE3)
> would a single write of 0xAB be sufficient to map the cartridge slot? Perhaps the first 0xEB write is
> necessary to prevent race conditions that could result when more then one bit changes in the byte (resulting in
> more than one slot being enabled for a split second). Maybe someone with a dev-cart could try an experiment?

I've done some more tests, and it appears that writing $EB first isn't necessary after all! As you suggest, it was possibly done to avoid race conditions, but in practice there don't appear to be any problems.

Quote

> 2.) Does bit 4 (_CE1#) have to be 0, what happens if it's set? I couldn't find _CE1# after a quick look at the SMS schematics. Can anybody else find a use for this signal?

_CE1 is Chip Enable for the user RAM. When this bit is 0, the 8K of user RAM is mapped into addresses 0xC000-0xDFFF and 0xE000-0xFFFF.

I tried setting this bit to 1 (from a program running in the ROM area) and it disabled user RAM, so by setting this bit the entire 64K address space could in theory be used for ROM. (This also works on the Mega Drive with Power Base Converter, by the way.)

Quote

> 3.) What are bits 0, 1 and 2 for? Do bits 1 and 0 need to be set? Does bit 2 always need to be reset?
> Again, perhaps a quick test could be written and tried by someone with a dev-cart.

See above. They don't seem to affect how slots are configured, but they could be used to control other signals.

Quote

> One last thing is the port itself, 0x3E. According to current information, port 0x3E should be equivalent to any even-numbered port between 0x00 and 0x3E. Another experiment could be to try to map different slots by writing to different ports, like 0x00, 0x0E, 0x30, 0x3C, etc.

Well, I tried writing to $00 and it had exactly the same effect as writing to $3E (on both Master System and Mega Drive/PBC). Trying other even ports in that range also gave the same results.

Mike

Excellent work!

Would you mind if drafted a small document describing some of this new information? I will, of course, credit your contributions.

--
Eric Quinn

Quote

> Excellent! I was actually thinking about such program no later than yesterday.

> Something that would be very interesting would be to see if once the BIOS is enabled, removing/plugging a cartridge doesnt hang the system.
> If it doesnt, I don't think I need to explain the possibilities (you can throw away your soldering tools when dumping Codemasters cartridges :)

> I'll do the test tonight.

Well, I tried it, and it doesn't hang the console at all... :-)

I must admit I hadn't thought about the Codemasters possibility before, but you're right! By hooking up the Codies cart to the expansion port of the SMS 1 (via a gender changer) and the dev cart to the cart slot, it should easily be possible to dump them.

Mike

Does any one know if any 3-D games write to port 0x3E in order to enable the card port for the 3-D glasses adapter?

--
Eric Quinn

Quote

> Excellent work!

> Would you mind if drafted a small document describing some of this new information? I will, of course, credit your contributions.

That would be superb Eric - I don't think any of this stuff has been documented before.

Mike

Quote

> Well, I tried it, and it doesn't hang the console at all... :-)
> I must admit I hadn't thought about the Codemasters possibility before, but you're right! By hooking up the Codies cart to the expansion port of the SMS 1 (via a gender changer) and the dev cart to the cart slot, it should easily be possible to dump them.

Why even bothering with the expansion port ?
Once the program is copied into RAM, cartridge can be disabled and let the user change it with the one we want to copy.

Quote

> Does any one know if any 3-D games write to port 0x3E in order to enable the card port for the 3-D glasses adapter?

I just did a quick trap test:

Zaxxon 3D writes dec 12 to port 0x3E twice at initialization.
Blade Eagle 3d: 12, 12
Poseidon Wars 3D writes: 172, 168
Space Harrier 3d: 20, 16

I can't seem to find a ROM of Outrun 3D.

I'll leave it to someone else to try to interpret these values. ^_~

-vecna

I seem to recall someone some months ago posting port settings that control the l/r shutters on the glasses directly (presumably the port was updated every vretrace). Does anyone recall what those were, or anyone with a dev cart and 3d glasses able to confirm them? They should probably find a place in the technical documents section, if anyone still knows what it was. I suppose it might not be too hard to figure it out if no one remembers or has it written down.

- vecna

Quote

> > Well, I tried it, and it doesn't hang the console at all... :-)
> > I must admit I hadn't thought about the Codemasters possibility before, but you're right! By hooking up the Codies cart to the expansion port of the SMS 1 (via a gender changer) and the dev cart to the cart slot, it should easily be possible to dump them.

> Why even bothering with the expansion port ?
> Once the program is copied into RAM, cartridge can be disabled and let the user change it with the one we want to copy.

But to copy a cart, you need simultaneous access to the cart and the SRAM cart, right? So you put the copying code on the SRAM cart in the cart slot, put the source cart on the expansion port, and it automatically copies the code to RAM and overwrites the SRAM cart with the source cart's ROM. Then you use an SMSReader to read the SRAM cart, and hope all went well. That's how I understand it, anyway.

It's kind of annoying that this has come up right after Mike dumped a whole load of (well, 4) Codemasters games the hard way. I presume this method could be used to dump GG carts via the SMS, as the fact that they won't run is immaterial, it's just copying raw data.

Maxim

With this new information it might be possible to correctly emulate the bios's, altho I still havnt had a disassembled look at them :( so Im not too sure, good work tho Mike!!!.
-Jason Starr-

Quote

> But to copy a cart, you need simultaneous access to the cart and the SRAM cart, right? So you put the copying code on the SRAM cart in the cart slot, put the source cart on the expansion port, and it automatically copies the code to RAM and overwrites the SRAM cart with the source cart's ROM. Then you use an SMSReader to read the SRAM cart, and hope all went well. That's how I understand it, anyway.

It is a bit of pain, but the program can copy data in, let's say, 7 kb chunks, by storing them in RAM, then writing them back to the SRAM cartridge. That without even connecting anything to the expansion port.

Quote

> > Well, I tried it, and it doesn't hang the console at all... :-)
> > I must admit I hadn't thought about the Codemasters possibility before, but you're right! By hooking up the Codies cart to the expansion port of the SMS 1 (via a gender changer) and the dev cart to the cart slot, it should easily be possible to dump them.

> Why even bothering with the expansion port ?
> Once the program is copied into RAM, cartridge can be disabled and let the user change it with the one we want to copy.

You're right, it's not really necessary at all, it just means swapping the cartridges over 32 or 64 times - or however many times are needed to dump the cartridge "piecewise" using user RAM as storage.

If you use the expansion port to hold the Codies cartridge, you can dump the cartridge in 8 x 32KB chunks; only 8 swaps are needed.

Mike

Quote

> Writing $EB followed by $E3 selects the BIOS ROM (_CE0)
> Writing $EB followed by $CB selects the card slot (_CE2)
> Writing $EB followed by $AB selects the cartridge slot (_CE3)
> Writing $EB followed by $6B selects the expansion port (_CE4)

You mentioned in another post that this works on the Mega Drive with the Power Base Converter. Do you know what the results are of enabling the expansion port or BIOS ROM, considering it doesn't have either?

Also, could the Majesco GG BIOS be dumped using this method?

My Homepage

Quote

>
> > Writing $EB followed by $E3 selects the BIOS ROM (_CE0)
> > Writing $EB followed by $CB selects the card slot (_CE2)
> > Writing $EB followed by $AB selects the cartridge slot (_CE3)
> > Writing $EB followed by $6B selects the expansion port (_CE4)

> You mentioned in another post that this works on the Mega Drive with the Power Base Converter. Do you know what the results are of enabling the expansion port or BIOS ROM, considering it doesn't have either?

I tried it, but it doesn't seem to do anything (i.e. the cartridge slot remains enabled).

Quote

> Also, could the Majesco GG BIOS be dumped using this method?

Possibly - I'm not sure! Unfortunately I don't have my Majesco here at the moment, so it will have to wait a short while...

Mike

Quote

> With this new information it might be possible to correctly emulate the bios's, altho I still havnt had a disassembled look at them :( so Im not too sure, good work tho Mike!!!.

Thanks Jason!

Actually, the BIOSes don't seem to do anything "unusual" beyond what's been described here, so you probably already know what's needed to emulate their functions...

Mike

Quote

> > But to copy a cart, you need simultaneous access to the cart and the SRAM cart, right? So you put the copying code on the SRAM cart in the cart slot, put the source cart on the expansion port, and it automatically copies the code to RAM and overwrites the SRAM cart with the source cart's ROM. Then you use an SMSReader to read the SRAM cart, and hope all went well. That's how I understand it, anyway.

> It is a bit of pain, but the program can copy data in, let's say, 7 kb chunks, by storing them in RAM, then writing them back to the SRAM cartridge. That without even connecting anything to the expansion port.

Unfortunately it seems my SMS 1 is less tolerant of swapping than my SMS 2 - the SMS 1 seems to hang about 75% of the time when swapping, while the SMS 2 never hangs.

I don't know if it's due to the design of the cartridge slot, or whatever, but it could be a problem if you're using the SMS 1 with the swap trick.

Mike

Forums

View topic - BIOS dumper for SMS (using port 3E)