Identify This Board?

[GrahamN]

Hi

I am starting to work my way through a lot of Atari ST parts, and have come across the board in the attached photograph. I've tried looking up the part number on the board, but with no luck. Can anyone identify the board for me?

Many thanks

Graham

IMG_5061-1600.jpg

[MiggyMog]

It's a Floppy controller board from an ancient STFM I have the same one which came with a machine I bought at year

[ijor]

Interesting. (Apparently) It is not exactly a floppy controller, but an internal adapter found on the some of the oldest ST models. Searching found some description here: https://groups.google.com/forum/?hl=en# ... -daqn1N6IQ

The board has a microcontroller (Intel MCS-48) with its own internal ROM. It would be nice if one of you could dump the ROM. Just for historical, preservation (and curiosity) reasons.

[czietz]

I guess it's basically the same circuit that was built into some (but not all!) SF354:
https://www.nightfallcrew.com/wp-conten ... G_9773.jpg
Must do some kind of translation between computer and floppy drive, but I don't know its exact purpose.

[tzok]

Similar boards were mounted also on early SF345 drives.

viewtopic.php?t=32094

[sety]

I have one too except it doesn't have any Atari PCB markings. I found it stuffed inside a rather butchered 520STF with 1mbRAM. I have no idea what it is for.

48HC.jpg

I don't have the equipment/knowledge to read from this rom but I'll happily post it free for keeps to anyone who does.

[Zippy]

If the code is of interest to anyone (and assuming the MCU isn't code protected to prevent reading) I have the tools to desolder the chip from the board and a programmer that can read it.

[ijor]

If the code is of interest to anyone (and assuming the MCU isn't code protected to prevent reading) I have the tools to desolder the chip from the board and a programmer that can read it.

As far as I can see on the datasheet, this MCU doesn't have hardware protection to prevent you from reading the ROM. But note that it has masked ROM and not EPROM, and then the ROM must be read "indirectly" because there is no builtin interface to burn and verify the (EP)ROM. This means that most EPROM burners can't read the ROM.

I found a description for how to read here: https://www.sbprojects.net/projects/8049spy/index.php

[ijor]

There are a couple of thread at Atariage that mention some Programmers that can read the 8048:

https://atariage.com/forums/topic/25998 ... 835-modem/

[Zippy]

I have a professional Elnec universal programmer that lists support for the 8048 so it should be no problem. When I select the 8048 the only note for "Device info" is "Read only" , obviously as it's a mask ROM device, size automatically changes to 1K ($400 x 8 ) so all seems good.

This one :

https://www.elnec.com/en/products/unive ... /beeprog2/

you can use the "Device search" at the top of the page if you ever want to check device support.

Have been using various Elnec programmers for over 20 years, would recommend them. They support more devices than many similar programmers, older programmers still get software updates much longer than usual and they'll even add support for new devices for you on request.

[sety]

If the code is of interest to anyone (and assuming the MCU isn't code protected to prevent reading) I have the tools to desolder the chip from the board and a programmer that can read it.

If you pm me your address I'll pop it in the post box.

[MiggyMog]

I could send you the one I have too if you want to check it out Zippy

[Zippy]

Cool, will PM you both.

Thanks.

[Zippy]

Got the board from "sety" today and have just removed and dumped the chip. No problem with reading and verifying it with my Elnec programmer so seems to be a 100% good dump.

It has 1K of ROM but only about 256 bytes used so can't be doing much. Anyone care to look at the code? I checked IDA and it doesn't specifically mention the 8048 but maybe it would work as some other Intel 8 bit architecture?

Binary file dump is attached.

MiggyMog, did you get my PM? Can also dump the chip from your board if you can send it.

Thanks to sety for the board, hope this dump is of use to someone.

[czietz]

ROM loads fine in Ghidra and it looks like sensible 8048 code. It's a bit hard to tell what it is doing, though, without someone tracing the schematic of the thing. I.e. I can see that it's reading stuff from port 1, setting and clearing bits on port 2 and using the external interrupt. But what are these pins wired to?

[czietz]

The PCB might be doing something with step handling, i.e., seeking to a track. I can see that it counts events on the external interrupt pin. Depending on the state of a pin on port 1 (perhaps connected to the direction signal?) it increments or decrements a variable which it checks against the limits 0 and 85. The main loop uses this variable to output some signals on port 2.

Theory: The drive needs differently timed step pulses than the ST/WD1772 can output. This PCB creates the correct step pulses. To prove the theory, a schematic would be needed.

[Zippy]

Couple of hi-res pics of the board here, might help:

https://ufile.io/kaxwjva4

some pins on the 8048 were bent and broken on the solder side and as the board was being scrapped I wasn't all that careful with the desoldering , so as you can see some pads got lifted, but you can maybe still see the layout well enough.

[czietz]

Couple of hi-res pics of the board here, might help:

Thank you! Although, unfortunately, there are a lot of traces (actually, the most interesting ones) going under ICs; in particular under the 74LS04/05 inverters. So, it's next to impossible to reverse-engineer the schematics without actually having the board, i.e., without being able to find connections with a continuity tester.

But from photos of a different board (from an SF354) with the same 8048 µC, I can at least say that the circuit is indeed sending step pulses to the drive, presumably based on the step pulses received from the Atari.

[Zippy]

Try this one, with those 2 IC's removed :

https://ufile.io/48r80x85

[ijor]

It has 1K of ROM but only about 256 bytes used so can't be doing much. Anyone care to look at the code? I checked IDA and it doesn't specifically mention the 8048 but maybe it would work as some other Intel 8 bit architecture?
Binary file dump is attached.

Thanks Zippy and Sety.

Couple of hi-res pics of the board here, might help:

What might be important is the frequency of the crystal. Can you read it or measure it?

Theory: The drive needs differently timed step pulses than the ST/WD1772 can output. This PCB creates the correct step pulses. To prove the theory, a schematic would be needed.

Good work. Must be something like that.

[Zippy]

What might be important is the frequency of the crystal. Can you read it or measure it?

Is that the green box thing? It's a Fujitsu part, marked 6000 then NMZ below.

[czietz]

There are still too many traces obscured for a full reverse-engineering (without actually having the PCB to probe). Here's what I figured out, though:

8048 outputs:
- P2.0 is presumably (not traced!) somehow controlling the drive select.
- P2.4 is connected via two inverters to the step line of the floppy drive.
- P2.5 no idea.
- P2.6 is connected to the /SET input of the flip-flop and re-arms it.
- P2.7 is connected via the open-collector inverter to the direction line of the floppy drive.

8048 inputs:
- P1.0 is connected to the direction line coming from the computer.
- P1.1 and T1 are both connected to track 0 sensor of the floppy drive. (This means that the SW can also use the event counter of the 8048 to detect that track 0 has been reached.)
- P1.2 not certain, could be connected to the index line of the floppy drive.
- INT is connected to the Q output of the flip-flop.

74LS74 flip-flop: Again not traced (because I cannot see the traces), but presumably this is clocked by the step line coming from the computer, but only if the drive is selected. Its output will cause an interrupt in the 8048 -- see above.

74LS38 NAND gate: Can't see all the traces. Presumably this combines some signals. E.g., both the computer and the 8048 need to be able to control the floppy's drive select line.

Pseudo-code of the interrupt handler in the 8048:

Code: Select all

rearm_flipflop
if direction_input == seek_to_higher_track:
    if target_track < 85:
        target_track = target_track + 1
if direction_input == seek_to_lower_track:
    if target_track > 0:
        target_track = target_track - 1
    else: # i.e., target_track is already 0
        if current_track == 0:
            select_drive
            if not track_0_sensor:
                # we should be on track 0 but aren't: reseek
                current_track = 85
            deselect_drive

Pseudo-code of the initialization:

Code: Select all

if track_0_sensor:
    for j = 1 to 12:
        step_one_track_higher
        delay

do:
    step_one_track_lower
    delay
until track_0_sensor

current_track = 0
target_track = 0

Pseudo-code of the main loop in the 8048:

Code: Select all

if target_track > current_track:
    step_one_track_higher
    delay
elseif target_track < current_track:
    step_one_track_lower
    delay
    if track_0_sensor:
        current_track = 0
else: # target_track == current_track:
    # some delay code involving P2.5 and P1.2 that I do not understand

The "step_one_track_higher" and "step_one_track_lower" routines select the drive (via P2.0), set the respective direction (via P2.7), do a step pulse (via P2.4) and update the "current_track" variable. They also do something with P2.5. EDIT: And, if the direction has changed compared to the last step, they will add an additional delay before switching the direction pin and doing the step.

[czietz]

As for the timing: Let's assume the crystal (or ceramic resonator) marked "6000" is a 6 MHz model, which is plausible, because this is the maximum clock frequency of a 8048. In that case, one instruction cycle takes 2.5 µs (=15 clock cycles). If I didn't miscount, the "delay" routine referenced above takes slightly less than 2400 cycles. Add to that the cycles spent in the main loop and other routines and you get roughly a minimum time between two step pulses sent to the drive of 6 ms.

[czietz]

I can't be sure because I cannot see all the PCB traces. But P2.5 seems to gate the "read data" line, i.e., the line where data is being transmitted from the floppy to the computer/controller, by using the NAND gate. If I understand it correctly, the "step_one_track_higher" and "step_one_track_lower" routines block "read data" and (re-)start a countdown. If this countdown expires in the main loop (after ca. 20 ms after the last step command, assuming 6 MHz), "read data" is unblocked again. This effectively introduces a head-settle delay.

[Zippy]

Great work, I think that pretty much solves the mystery of this board.

I can send you the PCB if you want to do further analysis on it?