Forums

Following on from the port 0x3E thread, I soldered up a gender changer cable for the SMS 1 expansion port, and was thus able to dump Maxim's Micro Machines cart to a 256k rewritable cartridge.

This is the first time I've dumped a Codemasters cart without having to desolder the ROM... :-)

Here's the code I used to do the dumping.

Mike

Thats great news! Do you think that method is more reliable then the previous dumping method of yours.... any plans of a new copier or anything? :).
-Jason Starr-

Quote

> Thats great news! Do you think that method is more reliable then the previous dumping method of yours.... any plans of a new copier or anything? :).

Well, it's the only way of reading Codemasters games "properly" at present. It still needs the SMSReader, though, to read the SRAM cartridge the game is dumped to! :-)

A proper parallel interface for the SMS, with a BIOS written to support it (so data can be transferred to and from the PC), is a project I may think about...

(On that subject, what ports are known to be "spare" and unused, on the standard SMS?)

Mike

Hah... spare and unused. As Eric pointed out to me a lil while ago only bits 0,6 and 7 of the ports are actually read or written. So..... taking that into consideration there can be a possible maximum of 8 different ports.
On the read these are taken..., bit7,bit6,bit0 in brackets
$7e(010) Current Scanline
$7f(011) Hpos
$be(100) VDP data read
$bf(101) VDP Status(mirrored at $bd, but its the same)
$dd(111) COntrol Pad 2
$dc(110) Control pad 1
$3e(000) can this be read?
$3f(001) I guess this is spare...

On write
$7e(010) Sound
$7f(011) Sound
$be(100) VDP data
$bf(101) VDP addr
$3f(001) Nationilization/Lightgun
$3e(000) Bios stuff
$dd(111) Control pad 2 Writing has no effect
$dc(110) Control pad 1 Writing has no effect

So i guess there is none spare for writing, maybe if you could interpret a read to $3f you could use that... maybe, heh.
On the JAP SMS with the FM chip it has a different port setup to allow for the FM registers so thats a different story that no one here currently knows due to no schematic on it. Hope ive helped.
-Jason Starr-

Quote

> Hah... spare and unused. As Eric pointed out to me a lil while ago only bits 0,6 and 7 of the ports are actually read or written. So..... taking that into consideration there can be a possible maximum of 8 different ports.

Yes, the 315-5216 chip decodes port addresses using only bits 7,6 and 0. However, devices could be created that use more of the address bits to do a port address decode (all the address bits are available at the expansion port). The trick is to prevent the 315-5216 and a new device from both decoding a port address and latching the data (a port "collision").

For example, it appears that port 0x3F doesn't do anything when read. So we can suspect, then, that the 315-5216 chip doesn't decode reads of ports with the following addresses: 00xxxxx1(binary). Consequently, if an external device wanted to provide "readable" ports, it could map them to these port addresses. If the device used all 8 port address bits, it could supply up to 32 readable ports.

Similarly, for writable ports, it appears that both 0xFE and 0xFF (the control pad ports, note that 0xFE fits the 7,6,0 bit pattern for 0xDC and 0xFF fits the 7,6,0 bit pattern for 0xDD) are available. Writing these ports has no affect since (it seems that) the 315-5216 doesn't decode these port addresses for writes (and even if it does we know the data doesn't affect any other devices, so who cares). So an external device could provide "writable" ports at addresses matching 11xxxxx0 and 11xxxxx1, for up to 64 additional writeable ports. In fact, the FM unit does exactly that, and (I suspect that) is precisely why the FM units ports are in the 0xF0-0xF2 range and why they're only writable (as reading them would be decoded by the 315-5216 and the control pad status would be returned. Anyone want to try it?)

Its unfortunate that the undecoded read port and undecoded write port addresses are not in the same range, but it's not impossible to overcome. Also, I should mention that the Z80 places the contents of register B on the address bus during certain port operations. Therefore, it's possible to have 64K different port addresses. This feature could also be used by external devices to decode their port addresses.

Some experimentation is required, but it seems that using other port address for additional external devices is a possibility. Perhaps, a "SMS/GG Port Registery" should be created so people can request specific port addresses for their own SMS/GG "peripherals". (I'm mostly kidding about that last one, but who knows, maybe enough people will design external SMS/GG devices that it becomes necessary...)

--
Eric Quinn

Some very helpful info, Eric! I was particularly interested in this "undocumented" feature you mentioned:

Quote

>Also, I should mention that the Z80 places the contents of register B on the address bus during certain port operations. Therefore, it's possible to have 64K different port addresses. This feature could also be used by external devices to decode their port addresses.

So if we were to do, say:

ld b, $40
out ($3F), a

... then $403F will be present on the address bus during the I/O write?

If so, that's *very* useful, I had no idea that was the case!

Quote

> Some experimentation is required, but it seems that using other port address for additional external devices is a possibility. Perhaps, a "SMS/GG Port Registery" should be created so people can request specific port addresses for their own SMS/GG "peripherals". (I'm mostly kidding about that last one, but who knows, maybe enough people will design external SMS/GG devices that it becomes necessary...)

That's not a bad idea at all, actually :-)

It's strange that Sega didn't allow a "spare" port range by default, though, especially since the Master System was evidently designed to be used with external peripherals (judging by the signals available on the cartridge and expansion connectors).

Mike

[..]

Quote

>devices, so who cares). So an external device could provide >"writable" ports at addresses matching 11xxxxx0 and 11xxxxx1, >for up to 64 additional writeable ports. In fact, the FM unit >does exactly that, and (I suspect that) is precisely why the FM u>nits ports are in the 0xF0-0xF2 range and why they're only >writable (as reading them would be decoded by the 315-5216 and >the control pad status would be returned. Anyone want to try >it?)

Port 0xF2 is both read and written, it is needed by the program to be able to autodetect the FM hardware.

Quote

> So if we were to do, say:

> ld b, $40
> out ($3F), a

> ... then $403F will be present on the address bus during the I/O write?

I'm not sure. It might only work with instructions that use register C for the port address: IN reg, (C) or OUT (C), reg

I will check my various Z80 references to determine how register B can be used for port operations and post back here.

Quote

> If so, that's *very* useful, I had no idea that was the case!

Yes, it should be understood, though, that the 315-5216 will still use bits 7, 6 and 0 to decode port addresses, so the limits to available port addresses I mentioned in my previous post still apply. We would still need to stick addresses matching xxxxxxxx00xxxxx1 for reads and xxxxxxxx11xxxxx0 or xxxxxxxx11xxxxx1 for writes.

Quote

> It's strange that Sega didn't allow a "spare" port range by default, though, especially since the Master System was evidently designed to be used with external peripherals (judging by the signals available on the cartridge and expansion connectors).

Yes, I agree.

--
Eric Quinn

Quote

> Port 0xF2 is both read and written, it is needed by the program to be able to autodetect the FM hardware.

That sure throws a bug into my speculations. Two new thoughts come to mind:

1.) Perhaps when 0xF2 is read both the FM hardware and the 315-5216 (or is it 315-5218?) drive values onto the address bus (this is electrically "safe" depending on the implementation of the bus). The FM unit could force the lines for mutually exclusive control pad directions (UP/DOWN, LEFT/RIGHT) indicating settings that could never happen with a real control pad. The software could then deduce that a FM unit was present. Does anyone know how the commercial SMS software detects a FM unit? (What values are written to or read from 0xF2?)

2.) There's more to the 315-5216 (315-5218?) than we know, and it can be disabled, preventing it from decoding port accesses.

As you can tell, I'm just guessing blindlly here, but after examination of the schematics and the currently known operation of ports in the SMS, I'm still convinced that the mechanisms for port addressing I discussed in my original post are accurate, and that adding devices with new port addresses is a real possibility.

--
Eric Quinn

Author	Message
Mike G Joined: 21 Apr 2000 Posts: 598 Location: Newcastle upon Tyne, England	Micro Machines dumped natively! Posted: Sun Mar 11, 2001 3:08 pm
	Following on from the port 0x3E thread, I soldered up a gender changer cable for the SMS 1 expansion port, and was thus able to dump Maxim's Micro Machines cart to a 256k rewritable cartridge. This is the first time I've dumped a Codemasters cart without having to desolder the ROM... :-) Here's the code I used to do the dumping. Mike

PolestaR Guest	Posted: Mon Mar 12, 2001 1:04 am
PolestaR Guest	Thats great news! Do you think that method is more reliable then the previous dumping method of yours.... any plans of a new copier or anything? :). -Jason Starr-

Mike G Joined: 21 Apr 2000 Posts: 598 Location: Newcastle upon Tyne, England	Posted: Mon Mar 12, 2001 10:31 am
	Quote > Thats great news! Do you think that method is more reliable then the previous dumping method of yours.... any plans of a new copier or anything? :). Well, it's the only way of reading Codemasters games "properly" at present. It still needs the SMSReader, though, to read the SRAM cartridge the game is dumped to! :-) A proper parallel interface for the SMS, with a BIOS written to support it (so data can be transferred to and from the PC), is a project I may think about... (On that subject, what ports are known to be "spare" and unused, on the standard SMS?) Mike

PolestaR Guest	Posted: Mon Mar 12, 2001 12:29 pm
PolestaR Guest	Hah... spare and unused. As Eric pointed out to me a lil while ago only bits 0,6 and 7 of the ports are actually read or written. So..... taking that into consideration there can be a possible maximum of 8 different ports. On the read these are taken..., bit7,bit6,bit0 in brackets $7e(010) Current Scanline $7f(011) Hpos $be(100) VDP data read $bf(101) VDP Status(mirrored at $bd, but its the same) $dd(111) COntrol Pad 2 $dc(110) Control pad 1 $3e(000) can this be read? $3f(001) I guess this is spare... On write $7e(010) Sound $7f(011) Sound $be(100) VDP data $bf(101) VDP addr $3f(001) Nationilization/Lightgun $3e(000) Bios stuff $dd(111) Control pad 2 Writing has no effect $dc(110) Control pad 1 Writing has no effect So i guess there is none spare for writing, maybe if you could interpret a read to $3f you could use that... maybe, heh. On the JAP SMS with the FM chip it has a different port setup to allow for the FM registers so thats a different story that no one here currently knows due to no schematic on it. Hope ive helped. -Jason Starr-

Eric R. Quinn Joined: 18 Sep 1999 Posts: 498 Location: Portland, Oregon USA	Posted: Mon Mar 12, 2001 5:15 pm
	Quote > Hah... spare and unused. As Eric pointed out to me a lil while ago only bits 0,6 and 7 of the ports are actually read or written. So..... taking that into consideration there can be a possible maximum of 8 different ports. Yes, the 315-5216 chip decodes port addresses using only bits 7,6 and 0. However, devices could be created that use more of the address bits to do a port address decode (all the address bits are available at the expansion port). The trick is to prevent the 315-5216 and a new device from both decoding a port address and latching the data (a port "collision"). For example, it appears that port 0x3F doesn't do anything when read. So we can suspect, then, that the 315-5216 chip doesn't decode reads of ports with the following addresses: 00xxxxx1(binary). Consequently, if an external device wanted to provide "readable" ports, it could map them to these port addresses. If the device used all 8 port address bits, it could supply up to 32 readable ports. Similarly, for writable ports, it appears that both 0xFE and 0xFF (the control pad ports, note that 0xFE fits the 7,6,0 bit pattern for 0xDC and 0xFF fits the 7,6,0 bit pattern for 0xDD) are available. Writing these ports has no affect since (it seems that) the 315-5216 doesn't decode these port addresses for writes (and even if it does we know the data doesn't affect any other devices, so who cares). So an external device could provide "writable" ports at addresses matching 11xxxxx0 and 11xxxxx1, for up to 64 additional writeable ports. In fact, the FM unit does exactly that, and (I suspect that) is precisely why the FM units ports are in the 0xF0-0xF2 range and why they're only writable (as reading them would be decoded by the 315-5216 and the control pad status would be returned. Anyone want to try it?) Its unfortunate that the undecoded read port and undecoded write port addresses are not in the same range, but it's not impossible to overcome. Also, I should mention that the Z80 places the contents of register B on the address bus during certain port operations. Therefore, it's possible to have 64K different port addresses. This feature could also be used by external devices to decode their port addresses. Some experimentation is required, but it seems that using other port address for additional external devices is a possibility. Perhaps, a "SMS/GG Port Registery" should be created so people can request specific port addresses for their own SMS/GG "peripherals". (I'm mostly kidding about that last one, but who knows, maybe enough people will design external SMS/GG devices that it becomes necessary...) -- Eric Quinn

Mike G Joined: 21 Apr 2000 Posts: 598 Location: Newcastle upon Tyne, England	Posted: Mon Mar 12, 2001 9:31 pm
	Some very helpful info, Eric! I was particularly interested in this "undocumented" feature you mentioned: Quote >Also, I should mention that the Z80 places the contents of register B on the address bus during certain port operations. Therefore, it's possible to have 64K different port addresses. This feature could also be used by external devices to decode their port addresses. So if we were to do, say: ld b, $40 out ($3F), a ... then $403F will be present on the address bus during the I/O write? If so, that's very useful, I had no idea that was the case! Quote > Some experimentation is required, but it seems that using other port address for additional external devices is a possibility. Perhaps, a "SMS/GG Port Registery" should be created so people can request specific port addresses for their own SMS/GG "peripherals". (I'm mostly kidding about that last one, but who knows, maybe enough people will design external SMS/GG devices that it becomes necessary...) That's not a bad idea at all, actually :-) It's strange that Sega didn't allow a "spare" port range by default, though, especially since the Master System was evidently designed to be used with external peripherals (judging by the signals available on the cartridge and expansion connectors). Mike

Zoop Joined: 24 Jun 1999 Posts: 1732 Location: Paris, France	Port 0xF2 Posted: Mon Mar 12, 2001 10:04 pm
	[..] Quote >devices, so who cares). So an external device could provide >"writable" ports at addresses matching 11xxxxx0 and 11xxxxx1, >for up to 64 additional writeable ports. In fact, the FM unit >does exactly that, and (I suspect that) is precisely why the FM u>nits ports are in the 0xF0-0xF2 range and why they're only >writable (as reading them would be decoded by the 315-5216 and >the control pad status would be returned. Anyone want to try >it?) Port 0xF2 is both read and written, it is needed by the program to be able to autodetect the FM hardware.

Eric R. Quinn Joined: 18 Sep 1999 Posts: 498 Location: Portland, Oregon USA	Posted: Mon Mar 12, 2001 10:05 pm
	Quote > So if we were to do, say: > ld b, $40 > out ($3F), a > ... then $403F will be present on the address bus during the I/O write? I'm not sure. It might only work with instructions that use register C for the port address: IN reg, (C) or OUT (C), reg I will check my various Z80 references to determine how register B can be used for port operations and post back here. Quote > If so, that's very useful, I had no idea that was the case! Yes, it should be understood, though, that the 315-5216 will still use bits 7, 6 and 0 to decode port addresses, so the limits to available port addresses I mentioned in my previous post still apply. We would still need to stick addresses matching xxxxxxxx00xxxxx1 for reads and xxxxxxxx11xxxxx0 or xxxxxxxx11xxxxx1 for writes. Quote > It's strange that Sega didn't allow a "spare" port range by default, though, especially since the Master System was evidently designed to be used with external peripherals (judging by the signals available on the cartridge and expansion connectors). Yes, I agree. -- Eric Quinn

Eric R. Quinn Joined: 18 Sep 1999 Posts: 498 Location: Portland, Oregon USA	Re: Port 0xF2 Posted: Mon Mar 12, 2001 11:19 pm
	Quote > Port 0xF2 is both read and written, it is needed by the program to be able to autodetect the FM hardware. That sure throws a bug into my speculations. Two new thoughts come to mind: 1.) Perhaps when 0xF2 is read both the FM hardware and the 315-5216 (or is it 315-5218?) drive values onto the address bus (this is electrically "safe" depending on the implementation of the bus). The FM unit could force the lines for mutually exclusive control pad directions (UP/DOWN, LEFT/RIGHT) indicating settings that could never happen with a real control pad. The software could then deduce that a FM unit was present. Does anyone know how the commercial SMS software detects a FM unit? (What values are written to or read from 0xF2?) 2.) There's more to the 315-5216 (315-5218?) than we know, and it can be disabled, preventing it from decoding port accesses. As you can tell, I'm just guessing blindlly here, but after examination of the schematics and the currently known operation of ports in the SMS, I'm still convinced that the mechanisms for port addressing I discussed in my original post are accurate, and that adding devices with new port addresses is a real possibility. -- Eric Quinn

Forums

View topic - Micro Machines dumped natively!