Sega Master System / Mark III / Game Gear|
SG-1000 / SC-3000 / SF-7000 / OMV
Home - Forums - Games - Scans - Maps - Cheats
Music - Videos - Development - Translations - Homebrew
SF-7000 I/O Cassette repairedPosted: Wed May 09, 2012 6:45 pm
Just a couple of pictures of my repaired SF-7000 I/O Cassette. This is my first one I bought at a garage sale back around 1999 or so. It worked a couple of times then I started to get memory errors. And after bringing it out of storage years later the I/O Cassette was dead too.
I finally got around to socketing and replacing both the SN74LS244s and the SN74LS367. And I also replaced the cable by desoldering the original cable and soldering a right angle 34-pin male IDC floppy connector in place.
This I/O cassette had had repairs before I got it, and IC27 had already been replaced once.
Looks like it was the LS367 that was dead. I really should have replaced that before doing the cable, but I wanted to try the cable replace out of interest as a friend of mine did earlier in the year when I helped him troubleshoot his SF-7000.
Note how I've just used a standard floppy cable to replace the original one. That looks a bit ugly, so I have a nice 45cm round cable with just a single connector each end coming in the post to replace it.
There is one other odd feature of the SF-7000 I/O Cassette - the ground wire. There is usually a thick wire running from the ground line of the SC-3000 to the CASE of the SF-7000. I had originally assumed this was to ensure that the SF-7000 and SC-3000 have a common ground. However I tried a continuity test and it looks like there is no direct link from the SF-7000's ground signal to the SF-7000's case.
So I'm really not sure what the purpose of that is. In any case, the SF-7000s always seem to run happily without that connected. Anyone have an idea why they put that in?
Now I just have to chase down what is causing the memory errors I'm getting as they came back again :) You can see more about the test EPROM I'm using for that in an older thread here:
I'm pretty sure it isn't the RAM itself, so I may have to start replacing the various control ICs one at a time until it works reliably. But at least the test EPROM lets me know which bits are failing which helps work out what parts of the circuit to attack first.
||Posted: Wed May 09, 2012 6:55 pm|
|Regarding the ground strap; in the US the FCC has silly rules for RF interference so it's common to see ground straps on things that have no real purpose or in fact make it worse and introduce noise (a good example is the Vectrex). It's also the reason for the silly excess RF shielding as well.|
||Posted: Fri May 11, 2012 2:57 pm|
I'm curious about this, so are you seeing errors in the same bit across all bytes (e.g. a single DRAM is failing) or multiple errors across different bits? Does it use 4-bit or 1-bit DRAMs? (I think you posted pictures of the SF7000 board, but for the life of me I can't find them :)
To keep these things running forever, I wonder how practical (in terms of labor) a modification to replace the DRAM with static RAM would be. Probably pretty gross to actually do.
It would be kind of cool to make a modern SF-7000 PCB that fit in the old case but had newer, more reliable chips. I'm just daydreaming here. :D
||Posted: Fri May 11, 2012 7:26 pm|
From memory it is mostly bits 6 and 7 (MSB), but there may have been the odd failure in another bit. In any case, replacing the DRAMs for bits 6 and 7 didn't fix the problem. The information in the old thread is still mostly accurate as I haven't had time to do much with it since then (I was going hard out trying to get the SC-3000 multicart released at the time).
I think these are what you are looking for.
It uses eight 64K x 1 DRAMs, with each DRAM responsible for a single bit, from memory. From reading my notes in the above thread, if you follow the traces from the 34-pin SF-7000 I/O cassette connector on the motherboard to the DRAM data inputs, you will see that IC12 handles bit 7 for every byte (the most significant bit) and IC5 handles bit 0 (the least significant bit).
I've been lucky enough to pick up spare replacement DRAMs so not an issue for me personally as yet. The SC-3000 works fine with static RAM in general. eg. for the multicart I just bought a pile of old 32KB static RAM cache chips that would have been used in 486 cache memory back in the day. I've used both MCM6206 and WINBOND W24257AK-20. They are both 20-25ns / 28 pin DIPs and work great. However I think it would be a pain to try to rewire a couple of those or a larger one onto the SF-7000 board. Possible you could design a plug in PCB to make it easier, but probably still lots of spaghetti wires for the control lines.
Yes, I've thought the same things in my crazier moments, late at night :) Saverio has actually rebuilt most of the SC-3000 AND SF-7000 functionality using an FPGA (it reads .SF7 images fine). We discussed the possibility of working together to design a PCB for a plug-in SF-7000 unit on a cart sized PCB with an SD-Card about a year ago. But I think the fine pitch surface mounting of the FPGA is beyond my soldering skills, and the SC-3000 multicart was taking all my time. Very cool project though - he's put a lot of work into that over the past few years.
Here is his blog site about it