Forums

Sorry for the cryptic title, maybe admin will change it. I was browsing eBay recently and spotted something interesting. It’s a HES 4Pak All Action which I’ve seen many times, and own, but this one had a different manual - usually just a single sided folded white sheet with brief text. The one in this auction had a cover matching the game, which I instantly assumed was hand made. Anyway with my interest piqued I had a look at the other photos and noticed this extra sheet stapled in - I’ve never seen it before and I don’t understand it.

Here is the eBay item number for the curious although really the interesting bit is just the sheet - 155508123311

IMG_0870.jpeg (101.59 KB)

Loop

Wow, it is exactly what your title says :) the loop could be a cheaper option than a switch on the cartridge to choose between some options for how it works, but I can’t think of any reason why the Sonic BIOS would be affected in a way that this might help with. Is the loop there on all of the cartridges or maybe they added this in a later run after finding some compatibility issues?

The photo of the cartridge on the auction doesn't show a loop.

Presumably cutting the loop modifies the mapper in some way so that the checksums run differently.

The thing I can't wrap my head around is why it wasn't possible to release a cartridge that always works in that respect. Presumably cutting the loop doesn't compromise the game functionality in any way? Perhaps they found that there were two versions of BIOS with mutually incompatible checksum behaviours as far as that cartridge is concerned, hence the warning about not cutting the loop unless you really have to 😂

Very curious!

checksum routines should be the same as the previous BIOS so I suspect there's something else going on here. but it's really weird, honestly I can't think of anything that would make sense.

Quote

The thing I can't wrap my head around is why it wasn't possible to release a cartridge that always works in that respect. ...

I imagine if we find an incompatibility issue after they have manufactured the board and/or mask rom they would have to consider a hack of that sort.

Posting full pictures for references.

sms-4_pak_all_action-with_loop_mention_in_manual-08.jpg (312.96 KB)

sms-4_pak_all_action-with_loop_mention_in_manual-09.jpg (434.58 KB)

sms-4_pak_all_action-with_loop_mention_in_manual-01.jpg (392.63 KB)

curiously, the dump we have of this cartridge has $4A (export, 8KiB) both at loctions $3FF0 and $7FF0 but no "TMR SEGA" there :|

So possibly late SMS IIs have a revision that causes this incompatibility issue. In 1994 only ~8,000 were manufactured (serial numbers beginning with "24"), all going to Ozisoft (Sega Europe still had a lot of unsold inventory after 1993). ~120,000 were manufactured in 1995 (serial numbers beginning with "25"), 60,000 of which were PAL-I for the UK, and the rest PAL-G for mainland Europe and Oceania. I would very roughly guestimate that around a third of those show up in AU/NZ, so something like 20,000. So maybe 30,000 units manufactured for Ozisoft from 1994 onwards.

By late 1994 Ozisoft said 650,000 SMS had been sold in Australia (which serial number analysis agrees with), add another 20k for 1995 and we get only ~4% of Australian SMS units were manufactured from 1994 onwards (actually a bit lower when taking into account some of those went to NZ). It's easy to see how they may have missed this prior to release, a similar thing happened to Codemasters with the VDP revision.

sverx wrote

curiously, the dump we have of this cartridge has $4A (export, 8KiB) both at loctions $3FF0 and $7FF0 but no "TMR SEGA" there :|

Wow ok this is interesting.
Without a TMR SEGA header in theory this shouldn't run on real hardware, yet my dump spawned the data we have.

It is possible the cartridge could have some special mechanism returning different data?

sverx wrote

curiously, the dump we have of this cartridge has $4A (export, 8KiB) both at loctions $3FF0 and $7FF0 but no "TMR SEGA" there :|

What about location $1FF0?

The BIOS with Sonic built in is the only BIOS to be 256K. I don't immediately see how that would be a factor though.

Bock wrote

sverx wrote

curiously, the dump we have of this cartridge has $4A (export, 8KiB) both at loctions $3FF0 and $7FF0 but no "TMR SEGA" there :|

Wow ok this is interesting.
Without a TMR SEGA header in theory this shouldn't run on real hardware, yet my dump spawned the data we have.

It is possible the cartridge could have some special mechanism returning different data?

I suspect something like that too. On the other hand, maybe our dump is not 100% good? I have no idea and no way to tell.

asynchronous wrote

What about location $1FF0?

No, nothing interesting there. Just $FFs.

edit: the ROM dump doesn't seem to contain neither the "SEGA" nor the "TMR" strings anywhere.

I found a copy of the dump.

There is a partial header at the end of every 16kB for the first 16 pages as pointed out by Bock back in the day where "TMR SEGA" is replaced with FF bytes. I'm guessing the custom mapper circuit puts the bytes on the bus for the license string because the export BIOS uses the license string to physically detect a cartridge. But I can't say for sure without probing it. Interesting.

FF FF FF FF FF FF FF FF FF FF 32 CE 32 70 00 4A

Maybe it’s trying to avoid having TMR SEGA returned by the cartridge at all, for legal reasons, so it is doing something tricky to maybe rewrite the code of the BIOS check to make it read from the BIOS instead, or some other hack to the routine. Somehow this routine is not invoked when the Sonic BIOS runs, but is OK on all the other ones, so they put in a cheap hardware switch to enable the “newer” routine.

This seems a bit implausible to me, I don’t see how they could have managed compatibility with every other BIOS but one, unless there’s something they all have in common - like the location in RAM of the checking code.

I don't think it's implausible - it fits the observations!

If there's some kind of "trigger" to tell the cart to inject TMR SEGA presumably that Sonic BIOS isn't making it happen. My next question would be what might the trigger be? Could be something like writes to port $3e when the various slots are checked, for example? Or maybe the implicit Sega mapper initialisation?

It would have to be something relatively simple and inexpensive to implement in hardware.

The BIOS has to run code from RAM to do the cartridge checks. This code is at a known location for each BIOS, and a simple modification to RAM could change it to make the bad header pass the necessary checks. For example, the TMR SEGA check has a “ret nz” which could be changed to a “nop”. There’s also TMR SEGA in RAM for comparison purposes, so it could change the pointer in hl to that. I’m sure there’s more options.

The tricky part is how the hardware can know when to make its hack (eg writing to RAM), what to do (eg where to write), and how it does it. This could be by monitoring for writes to port $3E and then maybe injecting an instruction onto the bus at that time, but I think that might mess up the executing code as it’d skip instructions. It’s really hard to guess.

For the 1.3 BIOS, the detection routine is loaded to RAM at $c700. It’s the same for the Alex Kidd and Sonic BIOSes. The Sonic BIOS RAM code is identical to the 1.3 BIOS for the TMR SEGA check.

Having a quick look at the PCB in in the other forum post, /IORQ is not used by the cartridge. So monitoring writes to I/O Port 3E is looking less likely.

/CSRAM is not used by the cartridge either. So disabling DRAM at the right time, such as for the RET NZ instructions during the license string comparison, is looking less likely.

Interesting that they went to the effort of not having the license string in the ROM but the case has the Sega and Master System trademarks all over it. :)

Perhaps it's just a timer - if the cart monitors #RST it could respond with TMR SEGA only within the first x milliseconds, say, and maybe that BIOS is taking too long. Or even count clock pulses or #M1s or something. For that matter something could just monitor #M1 and only respond with TMR SEGA if instructions look like they're being executed (dumping hardware presumably wouldn't touch #M1)

The other thing I wondered is whether there is a 3 bit counter that's decoding on a mask of $01F8 and overriding 3 higher bits of the address bus so that every time the BIOS attempts to read the TMR SEGA string it's actually fetching a byte from a different memory location - that would save on storing the string in the mapper itself as it would be hidden in ROM. The mapper already has hardware to switch A14 and above too. The characters could be spread around the banks?

asynchronous wrote

Having a quick look at the PCB in in the other forum post, /IORQ is not used by the cartridge. So monitoring writes to I/O Port 3E is looking less likely.

P.S. where is the PCB post out of interest? Couldn't immediately find it on the forum.

But mostly I have no idea why they couldn't just put the right header there... or they thought SEGA would sue them if the phrase "TMR SEGA" was found in the ROM? Would that be a strong case? If so, why they didn't just write "THIS IS NOT TMR SEGA" at the right location? ;)

Yeah it's strange isn't it.
Are the ROM and the mapper separate devices on the board?

I'm wondering if there was some kind of cockup in production and they accidentally had all the ROMs made up without headers, necessitating a workaround in hardware.

Note the discussions in 2012:

https://www.smspower.org/forums/13548-Sega8BitWinterOfDumpsPart24PAKAllAction#69...
RetroRalph pointed out that the lack of header was odd, but the mystery went unresolved and we forgot about the thread.unresolved.

Photos of the board:
https://www.smspower.org/forums/13548-Sega8BitWinterOfDumpsPart24PAKAllAction#69...

Tests on varying BIOSes;
https://www.smspower.org/forums/13548-Sega8BitWinterOfDumpsPart24PAKAllAction#69...

Testing the cartridge on different consoles:

SMS1 1.3 BIOS : Software Error
SMS1 Hang On : Works
SMS1 Hang On & Safari Hunt BIOS : Works
SMS1 Missile Defense 3-D : Missile Defense runs (no software error)
SMS2 Alex Kidd : Works
SMS2 Sonic The Hedgehog : Software Error

(Missile Defense 3-D BIOS test was maybe erroneous)

When I have time I'll investigate this further with real cartridge.

Thanks both async & bock for the forum link.

willbritton wrote

Perhaps it's just a timer...

From preliminary glances at the PCB, I reckon it's this.

The IC top left (presumably U3) is a dual flip-flop with preset and clear.
Looks to me as if the clear of both flip-flops is connected to a basic RC voltage divider with C1 and the resistor next to it, fed from +5V.

The D input of the first flip-flop comes from the GAL, and I presume that the Q output of the first flip-flop feeds into the D input of the second since I can't see any other traces - they must be on the top side and under the IC.

Looks to me like Q of the second flip-flop feeds pin 1 of the ROM which, assuming it's a JEDEC pinout device, would likely be A18.

I haven't done much more tracing than this, but already it feels to me like "something" needs to happen in the window before the capacitor fills up, before which point I think maybe A18 is forced to 0.

All speculation of course!

So the upper 128KB is used just to hide “TMR SEGA”? It seems like a bad solution - the TMR string is still on the cartridge, if that would be any kind of defence if it were not. Hiding it in the upper half of the ROM doesn’t seem helpful.

Isn’t the flip flop implementing the multi game selection mechanism?

Maxim wrote

So the upper 128KB is used just to hide “TMR SEGA”?

No, I don't think so, I agree that does seem bonkers! But seems like there is some kind of timing element happening here, which might explain why the dump didn't find TMR SEGA but clearly the hardware must be capable of producing one somehow at boot time, if it doesn't hack the BIOS routine as you suggest.

Maxim wrote

Isn’t the flip flop implementing the multi game selection mechanism?

That does seem likely, although seems to me that U3 is only driving A18 unless I'm not seeing some other tracks properly - some could definitely be running under the chips. I'm not even sure that is A18 by the way. Looking again, pin 2 of the ROM, U1, doesn't appear to be connected and I would have assumed that was A16 so maybe the pinout isn't standard.

U4 is a 4-bit register which is likely being used to implement paging.

One other thing I'd note is that the dump I'm looking at (not sure if the same as others are) is 1MB big but that's a 32 pin ROM so does it have enough pins to address that much space?
There are lots of FFs in the file - could it be that it's mapping a sparsely filled space?

EDIT2:

willbritton wrote

Maxim wrote

So the upper 128KB is used just to hide “TMR SEGA”?

No, I don't think so, I agree that does seem bonkers!

I think I might retract that. The dump is almost entirely FF from 0x00000 to 0x40000 which indeed corresponds to A18 (and A19) being 0. There's a little code in page 0, then after that it's just the "stub" headers that Bock refers to.

At the very least it could be that the lower 256KB is dedicated to the game switching menu.

P.S. looks like the ROM data pins are directly connected to the bus, so no sign of logic external to the ROM chip injecting instructions or data.

Okay, this is too juicy a problem, I'm going to have to stop getting distracted by it :)

Here's where I am with it, having spent some more time, and also much helped by the helpful annotated photos from DMEnduro on the other thread:

- On further thought, perhaps the RC timeout is to attempt to allow the cart to reset stably to page 0. As Bock astutely points out, there is some code which appears to try to force the CPU to reset the paging, although I do wonder what good this would be since the BIOS would presumably run before any code on the cart would get a look in. The timeout may still be relevant though, depending on what the exact purpose of the header "hiding" really is. Read on!

- I think the ROM is directly connected to D7:0 of the cart slot, and so I don't think any logic drives the data bus, either to inject TMR SEGA or to inject code into RAM to hack the BIOS routine.

- I think A13:0 of the ROM are connected directly to the cart slot, and so I don't think the external logic is capable of mangling the address lines to any less granularity than 16KB pages.

- There is no instance of "T" (ascii 0x54) at an offset of 0xff0 anywhere in the dumped ROM, so my theory of the external logic potentially mangling the upper address lines to generate TMR SEGA also seems unlikely.

- The dump does look like it is using more than 512KB of actual unique data, and so we presume that there are 20 address pins into the ROM. The pinout is not JEDEC standard, but close. Also we can presume there really are 20 external address pins and not some complicated latched multiplexing facility within the ROM, assuming it is a mask ROM.

- Again assuming this is mask ROM one possibility is that some internal logic has been added which reports TMR SEGA under certain conditions. This seems unlikely, not least because it would require some kind of control mechanism which would need to multiplex the pins somehow, given that there is no slack in the pinout as per above.

- My best remaining theory then, is that TMR SEGA is actually stored in the ROM in situ, but that AFTER the BIOS routine has finished, the external circuitry is intercepting any read to certain addresses and overriding the address, resulting in FF being returned instead.

- Looking at the dump, and as Bock points out too, it would appear as if the 16 addresses from 0x3ff0 to 0x3fff0 at 16KB byte steps return FF for the first 10 bytes at least, and thereafter a similar but not quite identical 6 bytes. Looking further, I think the pattern actually repeats for blocks of 512 bytes - see below.

- My hypothesis then...is that the GAL intercepts - if and only if it's paging in the bottom 16 pages AND only after the BIOS has finished booting - addresses where A13:9 are 1, and A3 is 0, and in that case it sets A19:14 to be 0x000, effectively forcing the return of whatever is in the ROM at address 0x3ff0, which is a string of FFs. We can confirm that tracks for A13:9 as well as A3 do indeed seem to be consumed by the GAL, so I think that's quite compelling evidence for this indeed! I also think the dump bears this out at first glance although I haven't checked exhaustively.

- The question remains: why does it bother? Hiding TMR SEGA from Sega is certainly one possibility, but I agree that it does seem like a lot of trouble to go to. I was wondering also whether it's a by-product of the attempt to initialise the paging post-boot, although I can't quite see how that would work.

- So back on topic (!) on the loop, it's really hard to guess what it might be for, but I wonder if it's connected to the 3 pin jumper pads which can be seen just north of ROM pins 26 and 27 on the reverse of the board. One end of that jumper is connected to 0V, the other end to a pull-up resistor and the middle pad goes to a pin on the GAL. In models with the loop I wonder if the loop replaces the connection between 0V and the middle pad, so that snipping it pulls the GAL pin high.

- If the GAL does indeed decode those addresses I mentioned above as well as driving the mapper addresses, I reckon there's not an awful lot more it could be doing, so I would suggest that snipping the loop somehow affects the exact way in which the GAL masks the address ranges I mentioned, possibly even just disabling the whole shebang.

Apologies if the address masking stuff above doesn't make sense, I got a bit turned around with the intricacies, but my gut says I'm somewhere close on this!

EDIT - okay, how about this for another theory: could this be an anti-piracy measure? By removing TMR SEGA after boot, attempts to dump the ROM wouldn't be playable in a real system, but since only the header is hidden, the game code in the "real" cartridge is unaffected, so long as the boot check passes.

willbritton wrote

okay, how about this for another theory: could this be an anti-piracy measure? By removing TMR SEGA after boot, attempts to dump the ROM wouldn't be playable in a real system, but since only the header is hidden, the game code in the "real" cartridge is unaffected, so long as the boot check passes.

I second this. I suspect the "SEGA TMR" string is indeed written in the ROM chip, but it's possible to access it only for a short amount of time, or until some other ROM location has been read. So someone dumping this cartridge accessing ROM addresses sequentially will end up reading $FF instead of the header, making the reproduction cartridge spit out the 'software error' message. Unfortunately then they realized the newer BIOS would mess with this and they had that wire added as a switch to a 'second mode' where, probably, more time is allowed to access the header.

So we should probably dump 16 bytes from $7FF0, turn off, dump 16 bytes from $3FF0, turn off, then dump 16 bytes from $1FF0 just to be sure and paste those onto the ROM dump we already have, and we should get to the real contents of the ROM chip.

Author	Message
james costello Joined: 17 Dec 2005 Posts: 537 Location: England	Cut loop on “ HES 4Pak All Action” cartridge? Posted: Sun Jun 18, 2023 8:57 pm
	Sorry for the cryptic title, maybe admin will change it. I was browsing eBay recently and spotted something interesting. It’s a HES 4Pak All Action which I’ve seen many times, and own, but this one had a different manual - usually just a single sided folded white sheet with brief text. The one in this auction had a cover matching the game, which I instantly assumed was hand made. Anyway with my interest piqued I had a look at the other photos and noticed this extra sheet stapled in - I’ve never seen it before and I don’t understand it. Here is the eBay item number for the curious although really the interesting bit is just the sheet - 155508123311 IMG_0870.jpeg (101.59 KB) Loop

Maxim Site Admin Joined: 19 Oct 1999 Posts: 14745 Location: London	Posted: Sun Jun 18, 2023 9:22 pm
	Wow, it is exactly what your title says :) the loop could be a cheaper option than a switch on the cartridge to choose between some options for how it works, but I can’t think of any reason why the Sonic BIOS would be affected in a way that this might help with. Is the loop there on all of the cartridges or maybe they added this in a later run after finding some compatibility issues?

james costello Joined: 17 Dec 2005 Posts: 537 Location: England	Posted: Sun Jun 18, 2023 9:28 pm
	The photo of the cartridge on the auction doesn't show a loop.

willbritton Joined: 06 Mar 2022 Posts: 671 Location: London, UK	Posted: Mon Jun 19, 2023 7:15 am
	Presumably cutting the loop modifies the mapper in some way so that the checksums run differently. The thing I can't wrap my head around is why it wasn't possible to release a cartridge that always works in that respect. Presumably cutting the loop doesn't compromise the game functionality in any way? Perhaps they found that there were two versions of BIOS with mutually incompatible checksum behaviours as far as that cartridge is concerned, hence the warning about not cutting the loop unless you really have to 😂 Very curious!

sverx Joined: 05 Sep 2013 Posts: 3828 Location: Stockholm, Sweden	Posted: Mon Jun 19, 2023 9:28 am
	checksum routines should be the same as the previous BIOS so I suspect there's something else going on here. but it's really weird, honestly I can't think of anything that would make sense.

Bock Site Admin Joined: 08 Jul 2001 Posts: 8652 Location: Paris, France	Posted: Mon Jun 19, 2023 10:08 am
	Quote The thing I can't wrap my head around is why it wasn't possible to release a cartridge that always works in that respect. ... I imagine if we find an incompatibility issue after they have manufactured the board and/or mask rom they would have to consider a hack of that sort. Posting full pictures for references. sms-4_pak_all_action-with_loop_mention_in_manual-08.jpg (312.96 KB) sms-4_pak_all_action-with_loop_mention_in_manual-09.jpg (434.58 KB) sms-4_pak_all_action-with_loop_mention_in_manual-01.jpg (392.63 KB)

sverx Joined: 05 Sep 2013 Posts: 3828 Location: Stockholm, Sweden	Posted: Mon Jun 19, 2023 10:21 am
	curiously, the dump we have of this cartridge has $4A (export, 8KiB) both at loctions $3FF0 and $7FF0 but no "TMR SEGA" there :\|

BKK Joined: 01 May 2011 Posts: 469	Posted: Mon Jun 19, 2023 11:22 am
BKK Joined: 01 May 2011 Posts: 469	So possibly late SMS IIs have a revision that causes this incompatibility issue. In 1994 only ~8,000 were manufactured (serial numbers beginning with "24"), all going to Ozisoft (Sega Europe still had a lot of unsold inventory after 1993). ~120,000 were manufactured in 1995 (serial numbers beginning with "25"), 60,000 of which were PAL-I for the UK, and the rest PAL-G for mainland Europe and Oceania. I would very roughly guestimate that around a third of those show up in AU/NZ, so something like 20,000. So maybe 30,000 units manufactured for Ozisoft from 1994 onwards. By late 1994 Ozisoft said 650,000 SMS had been sold in Australia (which serial number analysis agrees with), add another 20k for 1995 and we get only ~4% of Australian SMS units were manufactured from 1994 onwards (actually a bit lower when taking into account some of those went to NZ). It's easy to see how they may have missed this prior to release, a similar thing happened to Codemasters with the VDP revision.

Bock Site Admin Joined: 08 Jul 2001 Posts: 8652 Location: Paris, France	Posted: Mon Jun 19, 2023 11:51 am
	sverx wrote curiously, the dump we have of this cartridge has $4A (export, 8KiB) both at loctions $3FF0 and $7FF0 but no "TMR SEGA" there :\| Wow ok this is interesting. Without a TMR SEGA header in theory this shouldn't run on real hardware, yet my dump spawned the data we have. It is possible the cartridge could have some special mechanism returning different data?

asynchronous Joined: 14 Aug 2000 Posts: 742 Location: Adelaide, Australia	Cut loop on “ HES 4Pak All Action” cartridge? Posted: Mon Jun 19, 2023 11:53 am
	sverx wrote curiously, the dump we have of this cartridge has $4A (export, 8KiB) both at loctions $3FF0 and $7FF0 but no "TMR SEGA" there :\| What about location $1FF0? The BIOS with Sonic built in is the only BIOS to be 256K. I don't immediately see how that would be a factor though.

sverx Joined: 05 Sep 2013 Posts: 3828 Location: Stockholm, Sweden	Posted: Mon Jun 19, 2023 12:46 pm
	Bock wrote sverx wrote curiously, the dump we have of this cartridge has $4A (export, 8KiB) both at loctions $3FF0 and $7FF0 but no "TMR SEGA" there :\| Wow ok this is interesting. Without a TMR SEGA header in theory this shouldn't run on real hardware, yet my dump spawned the data we have. It is possible the cartridge could have some special mechanism returning different data? I suspect something like that too. On the other hand, maybe our dump is not 100% good? I have no idea and no way to tell.

sverx Joined: 05 Sep 2013 Posts: 3828 Location: Stockholm, Sweden	Posted: Mon Jun 19, 2023 12:47 pm
	asynchronous wrote What about location $1FF0? No, nothing interesting there. Just $FFs. edit: the ROM dump doesn't seem to contain neither the "SEGA" nor the "TMR" strings anywhere.

asynchronous Joined: 14 Aug 2000 Posts: 742 Location: Adelaide, Australia	Cut loop on “ HES 4Pak All Action” cartridge? Posted: Mon Jun 19, 2023 1:15 pm
	I found a copy of the dump. There is a partial header at the end of every 16kB for the first 16 pages as pointed out by Bock back in the day where "TMR SEGA" is replaced with FF bytes. I'm guessing the custom mapper circuit puts the bytes on the bus for the license string because the export BIOS uses the license string to physically detect a cartridge. But I can't say for sure without probing it. Interesting. FF FF FF FF FF FF FF FF FF FF 32 CE 32 70 00 4A

Maxim Site Admin Joined: 19 Oct 1999 Posts: 14745 Location: London	Posted: Mon Jun 19, 2023 2:01 pm
	Maybe it’s trying to avoid having TMR SEGA returned by the cartridge at all, for legal reasons, so it is doing something tricky to maybe rewrite the code of the BIOS check to make it read from the BIOS instead, or some other hack to the routine. Somehow this routine is not invoked when the Sonic BIOS runs, but is OK on all the other ones, so they put in a cheap hardware switch to enable the “newer” routine. This seems a bit implausible to me, I don’t see how they could have managed compatibility with every other BIOS but one, unless there’s something they all have in common - like the location in RAM of the checking code.

willbritton Joined: 06 Mar 2022 Posts: 671 Location: London, UK	Posted: Mon Jun 19, 2023 4:41 pm
	I don't think it's implausible - it fits the observations! If there's some kind of "trigger" to tell the cart to inject TMR SEGA presumably that Sonic BIOS isn't making it happen. My next question would be what might the trigger be? Could be something like writes to port $3e when the various slots are checked, for example? Or maybe the implicit Sega mapper initialisation? It would have to be something relatively simple and inexpensive to implement in hardware.

Maxim Site Admin Joined: 19 Oct 1999 Posts: 14745 Location: London	Posted: Mon Jun 19, 2023 10:31 pm
	The BIOS has to run code from RAM to do the cartridge checks. This code is at a known location for each BIOS, and a simple modification to RAM could change it to make the bad header pass the necessary checks. For example, the TMR SEGA check has a “ret nz” which could be changed to a “nop”. There’s also TMR SEGA in RAM for comparison purposes, so it could change the pointer in hl to that. I’m sure there’s more options. The tricky part is how the hardware can know when to make its hack (eg writing to RAM), what to do (eg where to write), and how it does it. This could be by monitoring for writes to port $3E and then maybe injecting an instruction onto the bus at that time, but I think that might mess up the executing code as it’d skip instructions. It’s really hard to guess. For the 1.3 BIOS, the detection routine is loaded to RAM at $c700. It’s the same for the Alex Kidd and Sonic BIOSes. The Sonic BIOS RAM code is identical to the 1.3 BIOS for the TMR SEGA check.

asynchronous Joined: 14 Aug 2000 Posts: 742 Location: Adelaide, Australia	HES 4Pak All Action” cartridge? Posted: Tue Jun 20, 2023 2:38 am
	Having a quick look at the PCB in in the other forum post, /IORQ is not used by the cartridge. So monitoring writes to I/O Port 3E is looking less likely. /CSRAM is not used by the cartridge either. So disabling DRAM at the right time, such as for the RET NZ instructions during the license string comparison, is looking less likely. Interesting that they went to the effort of not having the license string in the ROM but the case has the Sega and Master System trademarks all over it. :)

willbritton Joined: 06 Mar 2022 Posts: 671 Location: London, UK	Posted: Tue Jun 20, 2023 8:09 am
	Perhaps it's just a timer - if the cart monitors #RST it could respond with TMR SEGA only within the first x milliseconds, say, and maybe that BIOS is taking too long. Or even count clock pulses or #M1s or something. For that matter something could just monitor #M1 and only respond with TMR SEGA if instructions look like they're being executed (dumping hardware presumably wouldn't touch #M1) The other thing I wondered is whether there is a 3 bit counter that's decoding on a mask of $01F8 and overriding 3 higher bits of the address bus so that every time the BIOS attempts to read the TMR SEGA string it's actually fetching a byte from a different memory location - that would save on storing the string in the mapper itself as it would be hidden in ROM. The mapper already has hardware to switch A14 and above too. The characters could be spread around the banks? asynchronous wrote Having a quick look at the PCB in in the other forum post, /IORQ is not used by the cartridge. So monitoring writes to I/O Port 3E is looking less likely. P.S. where is the PCB post out of interest? Couldn't immediately find it on the forum.

sverx Joined: 05 Sep 2013 Posts: 3828 Location: Stockholm, Sweden	Posted: Tue Jun 20, 2023 9:09 am
	But mostly I have no idea why they couldn't just put the right header there... or they thought SEGA would sue them if the phrase "TMR SEGA" was found in the ROM? Would that be a strong case? If so, why they didn't just write "THIS IS NOT TMR SEGA" at the right location? ;)

willbritton Joined: 06 Mar 2022 Posts: 671 Location: London, UK	Posted: Tue Jun 20, 2023 9:30 am
	Yeah it's strange isn't it. Are the ROM and the mapper separate devices on the board? I'm wondering if there was some kind of cockup in production and they accidentally had all the ROMs made up without headers, necessitating a workaround in hardware.

Bock Site Admin Joined: 08 Jul 2001 Posts: 8652 Location: Paris, France	Posted: Tue Jun 20, 2023 2:02 pm
	Note the discussions in 2012: https://www.smspower.org/forums/13548-Sega8BitWinterOfDumpsPart24PAKAllAction#69... RetroRalph pointed out that the lack of header was odd, but the mystery went unresolved and we forgot about the thread.unresolved. Photos of the board: https://www.smspower.org/forums/13548-Sega8BitWinterOfDumpsPart24PAKAllAction#69... Tests on varying BIOSes; https://www.smspower.org/forums/13548-Sega8BitWinterOfDumpsPart24PAKAllAction#69... Testing the cartridge on different consoles: SMS1 1.3 BIOS : Software Error SMS1 Hang On : Works SMS1 Hang On & Safari Hunt BIOS : Works SMS1 Missile Defense 3-D : Missile Defense runs (no software error) SMS2 Alex Kidd : Works SMS2 Sonic The Hedgehog : Software Error (Missile Defense 3-D BIOS test was maybe erroneous) When I have time I'll investigate this further with real cartridge.

willbritton Joined: 06 Mar 2022 Posts: 671 Location: London, UK	Posted: Tue Jun 20, 2023 2:12 pm
	Thanks both async & bock for the forum link. willbritton wrote Perhaps it's just a timer... From preliminary glances at the PCB, I reckon it's this. The IC top left (presumably U3) is a dual flip-flop with preset and clear. Looks to me as if the clear of both flip-flops is connected to a basic RC voltage divider with C1 and the resistor next to it, fed from +5V. The D input of the first flip-flop comes from the GAL, and I presume that the Q output of the first flip-flop feeds into the D input of the second since I can't see any other traces - they must be on the top side and under the IC. Looks to me like Q of the second flip-flop feeds pin 1 of the ROM which, assuming it's a JEDEC pinout device, would likely be A18. I haven't done much more tracing than this, but already it feels to me like "something" needs to happen in the window before the capacitor fills up, before which point I think maybe A18 is forced to 0. All speculation of course!

Maxim Site Admin Joined: 19 Oct 1999 Posts: 14745 Location: London	Posted: Tue Jun 20, 2023 2:51 pm
	So the upper 128KB is used just to hide “TMR SEGA”? It seems like a bad solution - the TMR string is still on the cartridge, if that would be any kind of defence if it were not. Hiding it in the upper half of the ROM doesn’t seem helpful. Isn’t the flip flop implementing the multi game selection mechanism?

willbritton Joined: 06 Mar 2022 Posts: 671 Location: London, UK	Posted: Tue Jun 20, 2023 3:00 pm
	Maxim wrote So the upper 128KB is used just to hide “TMR SEGA”? No, I don't think so, I agree that does seem bonkers! But seems like there is some kind of timing element happening here, which might explain why the dump didn't find TMR SEGA but clearly the hardware must be capable of producing one somehow at boot time, if it doesn't hack the BIOS routine as you suggest. Maxim wrote Isn’t the flip flop implementing the multi game selection mechanism? That does seem likely, although seems to me that U3 is only driving A18 unless I'm not seeing some other tracks properly - some could definitely be running under the chips. I'm not even sure that is A18 by the way. Looking again, pin 2 of the ROM, U1, doesn't appear to be connected and I would have assumed that was A16 so maybe the pinout isn't standard. U4 is a 4-bit register which is likely being used to implement paging. One other thing I'd note is that the dump I'm looking at (not sure if the same as others are) is 1MB big but that's a 32 pin ROM so does it have enough pins to address that much space? There are lots of FFs in the file - could it be that it's mapping a sparsely filled space? EDIT2: willbritton wrote Maxim wrote So the upper 128KB is used just to hide “TMR SEGA”? No, I don't think so, I agree that does seem bonkers! I think I might retract that. The dump is almost entirely FF from 0x00000 to 0x40000 which indeed corresponds to A18 (and A19) being 0. There's a little code in page 0, then after that it's just the "stub" headers that Bock refers to. At the very least it could be that the lower 256KB is dedicated to the game switching menu. P.S. looks like the ROM data pins are directly connected to the bus, so no sign of logic external to the ROM chip injecting instructions or data.

willbritton Joined: 06 Mar 2022 Posts: 671 Location: London, UK	Posted: Thu Jun 22, 2023 10:26 am
	Okay, this is too juicy a problem, I'm going to have to stop getting distracted by it :) Here's where I am with it, having spent some more time, and also much helped by the helpful annotated photos from DMEnduro on the other thread: - On further thought, perhaps the RC timeout is to attempt to allow the cart to reset stably to page 0. As Bock astutely points out, there is some code which appears to try to force the CPU to reset the paging, although I do wonder what good this would be since the BIOS would presumably run before any code on the cart would get a look in. The timeout may still be relevant though, depending on what the exact purpose of the header "hiding" really is. Read on! - I think the ROM is directly connected to D7:0 of the cart slot, and so I don't think any logic drives the data bus, either to inject TMR SEGA or to inject code into RAM to hack the BIOS routine. - I think A13:0 of the ROM are connected directly to the cart slot, and so I don't think the external logic is capable of mangling the address lines to any less granularity than 16KB pages. - There is no instance of "T" (ascii 0x54) at an offset of 0xff0 anywhere in the dumped ROM, so my theory of the external logic potentially mangling the upper address lines to generate TMR SEGA also seems unlikely. - The dump does look like it is using more than 512KB of actual unique data, and so we presume that there are 20 address pins into the ROM. The pinout is not JEDEC standard, but close. Also we can presume there really are 20 external address pins and not some complicated latched multiplexing facility within the ROM, assuming it is a mask ROM. - Again assuming this is mask ROM one possibility is that some internal logic has been added which reports TMR SEGA under certain conditions. This seems unlikely, not least because it would require some kind of control mechanism which would need to multiplex the pins somehow, given that there is no slack in the pinout as per above. - My best remaining theory then, is that TMR SEGA is actually stored in the ROM in situ, but that AFTER the BIOS routine has finished, the external circuitry is intercepting any read to certain addresses and overriding the address, resulting in FF being returned instead. - Looking at the dump, and as Bock points out too, it would appear as if the 16 addresses from 0x3ff0 to 0x3fff0 at 16KB byte steps return FF for the first 10 bytes at least, and thereafter a similar but not quite identical 6 bytes. Looking further, I think the pattern actually repeats for blocks of 512 bytes - see below. - My hypothesis then...is that the GAL intercepts - if and only if it's paging in the bottom 16 pages AND only after the BIOS has finished booting - addresses where A13:9 are 1, and A3 is 0, and in that case it sets A19:14 to be 0x000, effectively forcing the return of whatever is in the ROM at address 0x3ff0, which is a string of FFs. We can confirm that tracks for A13:9 as well as A3 do indeed seem to be consumed by the GAL, so I think that's quite compelling evidence for this indeed! I also think the dump bears this out at first glance although I haven't checked exhaustively. - The question remains: why does it bother? Hiding TMR SEGA from Sega is certainly one possibility, but I agree that it does seem like a lot of trouble to go to. I was wondering also whether it's a by-product of the attempt to initialise the paging post-boot, although I can't quite see how that would work. - So back on topic (!) on the loop, it's really hard to guess what it might be for, but I wonder if it's connected to the 3 pin jumper pads which can be seen just north of ROM pins 26 and 27 on the reverse of the board. One end of that jumper is connected to 0V, the other end to a pull-up resistor and the middle pad goes to a pin on the GAL. In models with the loop I wonder if the loop replaces the connection between 0V and the middle pad, so that snipping it pulls the GAL pin high. - If the GAL does indeed decode those addresses I mentioned above as well as driving the mapper addresses, I reckon there's not an awful lot more it could be doing, so I would suggest that snipping the loop somehow affects the exact way in which the GAL masks the address ranges I mentioned, possibly even just disabling the whole shebang. Apologies if the address masking stuff above doesn't make sense, I got a bit turned around with the intricacies, but my gut says I'm somewhere close on this! EDIT - okay, how about this for another theory: could this be an anti-piracy measure? By removing TMR SEGA after boot, attempts to dump the ROM wouldn't be playable in a real system, but since only the header is hidden, the game code in the "real" cartridge is unaffected, so long as the boot check passes.

sverx Joined: 05 Sep 2013 Posts: 3828 Location: Stockholm, Sweden	Posted: Mon Jun 26, 2023 9:40 am
	willbritton wrote okay, how about this for another theory: could this be an anti-piracy measure? By removing TMR SEGA after boot, attempts to dump the ROM wouldn't be playable in a real system, but since only the header is hidden, the game code in the "real" cartridge is unaffected, so long as the boot check passes. I second this. I suspect the "SEGA TMR" string is indeed written in the ROM chip, but it's possible to access it only for a short amount of time, or until some other ROM location has been read. So someone dumping this cartridge accessing ROM addresses sequentially will end up reading $FF instead of the header, making the reproduction cartridge spit out the 'software error' message. Unfortunately then they realized the newer BIOS would mess with this and they had that wire added as a switch to a 'second mode' where, probably, more time is allowed to access the header. So we should probably dump 16 bytes from $7FF0, turn off, dump 16 bytes from $3FF0, turn off, then dump 16 bytes from $1FF0 just to be sure and paste those onto the ROM dump we already have, and we should get to the real contents of the ROM chip.

Forums

View topic - Cut loop on “ HES 4Pak All Action” cartridge?