Extracting program from old tape

[andrewh]

I bought a UK101 (similar enough to the OSI 600) tape from eBay which is labelled Clock. I used the Java tool from https://uk101.sourceforge.net/docs/samples.html to try and extract the contents from it, but unsurprisingly the BASIC it produces is corrupted. If anyone would like to try and "fix" it, I have uploaded the WAVs:

https://drive.google.com/file/d/1wqT6Vf ... share_link
https://drive.google.com/file/d/1smC8Ef ... share_link

There are two files because it seems there is a different clock program on each side of the tape. Please let me know if you make any progress!

[bxdanny]

Well, I can tell you that these files were intended to be monitor-load files, rather than straight BASIC. I can't give you clean decodes of them, but perhaps what I did find could help you get cleaner copies that could be successfully decoded.

I used the OSIKCS.exe utility (at http://marks-lab.com/osi/software/tools/osikcs.zip) to try to decode the files. The results clearly showed there was machine code in checksum-loader format present, with the loader itself at the start, but both files were quite corrupted, the second one worse than the first. I'm uploading what I decoded, along with a copy of the interaction with the decoder program (very slightly edited to avoid blank lines and to include the appropriate ".lod" extension for the output). and also a copy of what happens when the partly-decoded output of the clock1 file is run on the (emulated) UK101. (It doesn't get far at all with CEGMON, but it does load some of the checksum-loader portion with NEWMON or with MONUK01. Likewise, on the emulated C1P, it gets to the same point with the standard SYN600 monitor, but not with CEGMON.) The second program is too corrupted to even try this with.

The levels of the audio samples reported by the OSIKCS program for the clock1.wav file are just about at the clipping point, so perhaps you'd get better results for that by turning the playback volume down just a drop. The levels reported for the clock2.wav file, on the other hand, are quite low, so perhaps the volume should be turned up somewhat for that one. I'm guessing that the maximum absolute value of the samples should be in the neighborhood of 30,000 for best results.

[andrewh]

I crossposted this on https://stardot.org.uk/forums/viewtopic ... 45&t=26361 and there was some significant progress. It looks like it depends on a RTC card to do anything. If anyone has one, it would be interesting to give it a try.

[bxdanny]

Based on the final comments in the thread you linked, it sounds like there is no real RTC card involved, just a jumper from the vertical sync signal to the NMI line. Probably with a switch on it so that the interrupts can be enabled only when the software to handle them is loaded. Since NMI is an edge-triggered input, the pulse width and polarity shouldn't matter, just the frequency.

[Mark]

I managed to load the files based on the data posted on stardot. They did a really nice job with the WAV conversion.
I reconstructed the whole thing filling, in a glitch and made an assembler version.

As Danny stated it is a no-hardware RTC, which consisted of a switch connecting the 6502 NMI line to a 50Hz time base.
The program uses RAM from $0228 to $0440 for initialization, afterwards it fits between $0228 and $02FF so it will coexist with BASIC.
However since it uses these memory addresses I don't think it is compatible with the more advanced monitor ROMS like CEGMON, however NEWMON seems to work fine.

Included in the archive is the source, a ".lod" file consisting of a checksum loader and clock program. A WAV file created from the .lod file, as well as the assembler source & listing.
-Mark

Screen after loading

Clock initialization

clock1.gif (1.59 KiB) Viewed 13730 times

Clock after entering last seconds digit

Clock RESET

clock2.gif (1.28 KiB) Viewed 13730 times

Clock after starting BASIC

Clock & BASIC

clock3.gif (2.18 KiB) Viewed 13730 times