Forums

Sega Master System / Mark III / Game Gear
SG-1000 / SC-3000 / SF-7000 / OMV
Home - Forums - Games - Scans - Maps - Cheats - Credits
Music - Videos - Development - Hacks - Translations - Homebrew

View topic - SC-3000: can bad sw damage the hw?

Reply to topic
Author Message
  • Joined: 25 Feb 2013
  • Posts: 384
  • Location: Osaka
Reply with quote
SC-3000: can bad sw damage the hw?
Post Posted: Mon Sep 05, 2022 10:27 am
From analyzing the schematic, it seems possible to have software that damages the hardware.

For instance, the keyboard PPI has only A5==0 as the condition for the chip select. The VDP has its enable generated from the gate array, which takes as inputs only A7 and A6. This means that when you read from port 0b100xxxxx both the PPI and the VDP will try to write on the bus.

Unless anything is in open collector configuration (and I do not think this is the case) it should be possible to damage either of the devices by repeatedly read until something gets hot enough to break.
  View user's profile Send private message
  • Joined: 06 Mar 2022
  • Posts: 593
  • Location: London, UK
Reply with quote
Post Posted: Mon Sep 05, 2022 10:49 am
Last edited by willbritton on Mon Sep 05, 2022 11:05 am; edited 1 time in total
Not an expert on the SC-3000 specifically, but generally speaking, yes bus contention is a design issue for any microcomputer system without a bus arbiter. It was very common for discrete logic address decoders to implement only partial decoding, and with that comes the possibility for overlapping address ranges, as in your example.

In practice, bus contention isn't necessarily as catastrophic as you might initially think. For one, chip manufacturers designed devices to be relatively robust as it would be a shame if a single software bug fried a chip the first time it exhibited. You also have to consider that a near short-circuit condition only occurs if the two devices contending for the bus are both attempting to write to the bus and also both attempting to write different symbols (i.e. a 1 and a 0 or a 0 and a 1). Lastly consider that the period of time for which the high current might be flowing is naturally limited as the machine will only be asserting the addresses and control signals for a limited number of clock cycles before it moves onto other business (like reading the next instruction from RAM, for example).

So could you write some software which damaged the hardware? Probably, but you might have to try quite hard to actually destroy something, e.g. repeatedly simulating the bus contention in a tight loop or something.

(P.S. you wouldn't expect a data bus to be open collector. Although you're right that open collectors would limit the current flow, there would still be a significantly larger current draw than with a conventional totem pole, so it's not great for general power consumption. Also, and probably more significantly for older hardware, the additional resistance coupled with the capacitance of the outputs would significantly slow the signal rise times. Lastly, in order to provide protection from high currents you'd need every device on the bus to be open collector, otherwise you protect in one direction but not the other.)
  View user's profile Send private message Visit poster's website
  • Joined: 25 Feb 2013
  • Posts: 384
  • Location: Osaka
Reply with quote
Post Posted: Mon Sep 05, 2022 11:03 am
I agree with all your points. What I am imagining is some malicious (or buggy!) code doing a simple

loop:in a,($80)
jp loop
  View user's profile Send private message
  • Joined: 06 Mar 2022
  • Posts: 593
  • Location: London, UK
Reply with quote
Post Posted: Mon Sep 05, 2022 11:19 am
Haha, well only one way to find out!
I've got a few Z80s kicking around, perhaps I'll experiment one day :)

Assuming we use a jr instead of a jp to make it even quicker, and assuming the hardware doesn't assert ~WAIT at all, and if I've done my sums right, I think your example repeats every 23 T states, or roughly 6.4us @3.58MHz, and scanning down the timing diagrams in the datasheet I think the time during which the bus would be in contention is just over 3 T states, or around 0.34us. So your high current draw would have a duty cycle of around 13%. I'm sure we could take this further and figure out the actual power and therefore heat dissipated by such a cycle...
  View user's profile Send private message Visit poster's website
  • Joined: 25 Feb 2013
  • Posts: 384
  • Location: Osaka
Reply with quote
Post Posted: Mon Sep 05, 2022 11:31 pm
Indeed. Or even in a more straightforward manner, It would be nice to see is the current*duty cycle is out of specs (unfortunately the output resistance is not reported in the PPI's datasheet).

I would bet, even considering the duty cycle, that the current is out of the specifications, but in practice neither the tms9918 nor the 8255 die under such conditions.
  View user's profile Send private message
  • Joined: 05 Sep 2013
  • Posts: 3757
  • Location: Stockholm, Sweden
Reply with quote
Post Posted: Tue Sep 06, 2022 9:05 am
willbritton wrote
Assuming we use a jr instead of a jp to make it even quicker [...]


well, no. JP is quicker. Anyway you could avoid the loop and have a block of IN operations and that would be probably the fastest you can get.
  View user's profile Send private message Visit poster's website
  • Joined: 06 Mar 2022
  • Posts: 593
  • Location: London, UK
Reply with quote
Post Posted: Tue Sep 06, 2022 9:20 am
sverx wrote
well, no. JP is quicker.

Ah, right you are! JP is 10 T States vs. JR's 12, well I guess it's really true that you learn a new thing every day ;)
  View user's profile Send private message Visit poster's website
Reply to topic



Back to the top of this page

Back to SMS Power!