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?
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.
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.
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.
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
https://atariage.com/forums/topic/25998 ... 835-modem/
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.
If you pm me your address I'll pop it in the post box.
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.
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.
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.
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.
Thanks Zippy and Sety.
What might be important is the frequency of the crystal. Can you read it or measure it?Couple of hi-res pics of the board here, might help:
Good work. Must be something like that.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.
- 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.
- 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
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
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