Archiving OSI Disks with a Kryoflux

[exidyboy]

Hi,

I'm starting this thread to document the workflow for imaging OSI format floppy disks using a Kryoflux which some members have used successfully.

I have imaged a number of sample OSI format disks for the Rabble65 OSI compatible computer that was developed in the town of Shepparton in Australia. I believe they are OS-65D.

I am using a Kryoflux and a known good Mitsubishi M4853 5.25 inch floppy drive.

The workflow thus far has been:

1. Create Kryoflux Preservation Streams of the disks.


2. Visualise those disks in the HxC Floppy Emulator software. A highly useful utility for manipulating disk images to they run on Gotek solid-state floppy replacement devices that use the HxC frmware.
https://hxc2001.free.fr/floppy_drive_em ... index.html

3. Using HxC to convert those preservation streams to a .hfe file.

4. Using the OSIHFE utility https://osi.marks-lab.com/software/tools.html to create images compatible with the WinOSI emulator http://osi.marks-lab.com/

5. Also scan those disk images using Simon Owen's samdisk. Another essential utility in the disk preservation arsenal https://simonowen.com/samdisk/

The majority of the disks have some visible mould and squealed when being read which indicates surface problems. Nevertheless a few disks looked clean and sounded fine when being read. One disk in particular, rabble7, a games disk, looks like a good candidate for developing a worflow because when visualised in HxC you can see FM encoded data (blue) between the empty tracks (red) on every alternative track of side 0 which makes sense given my understanding of the format.



However I have not been to create a .hfe that WinOSI wants to load, nor preview of the contents of, in the way it does for sample disks that are included with the download of the emulator.

I have loaded the preservation stream into HxC and exported a .hfe


OSIHFE complains that:

Code: Select all

HFE file has too many tracksUnable to determine target format from HFE file.

This is fair enough as the Kryoflux tests how far the drive can seek and images as far as it can. In the case of my Mitsubishi floppy drive this is 84 tracks.
(Note that using OSIHFE might be an unnecessary step as when I ran the emulator it purports to be able to load .hfe directly).

Samdisk also shows all tracks as empty when reading the preservation streams.

So for people who have done this please let me know what steps you took to take a physical floppy and get an image from which you could
1. extract files
2. potentially write back to physical media
3. mount successfully in an OSI emulator.

It may be that additional specialised help is required. This is an arcane field but I have been fortunate in the past to get help for preserving obscure disk formats from a variety of specialists including the developer of HxC, from the Kryoflux team and from Simon Owen. In the first instance however if we can document steps that have definitely worked in the past then that would be a good first step.

Dave has kindly made the Preservations Steams of the test floppy available here and Ray Gardiner, the co-designer of the Rabble65, has agreed to share the file with forum members. https://osiweb.org/t/rabble7.zip

[dave]

I think part of the problem is that you are using a 360k drive with double the number of tracks. I am not certain what happens when you read a regular single-density floppy. It's possible that every other track will have good data, but perhaps no tracks will read properly, depending on how the tracks are aligned.

Do you have access to a 40-track drive? I believe either single- or double-density will work for reading the flux streams.

Good luck

Dave

[bxdanny]

A 360k drive IS a 40-track drive. The 360k format (used ever since MS-DOS 2.0) is double-sided, double density. Under MS-DOS 1.x, the same drives and diskettes were called 320k, or four times the 80k capacity of OSI's (non-standard) single-sided, single-density format.

3.5" drives and high-density (1.2 MB) 5.25" drives use 80 tracks.

[Mark]

OSI 5.25" floppies as shipped are 48TPI 40 track single sided FM encoded disks. Back when OSIHFE was created there was a limited set of flux sample images. In order to be compatible with the Gotek floppy hardware HFE files were created from OSIDumps in a format that seemed to work best at the time, which is 2bits/flux transition 250Kflux per second.

Over the years OSIHFE has been updated to handle a much greater variety of input formats including "SCP" SuperCopyPlus flux format, a format supported by the GreaseWeazle floppy imager as well as others. SCP files can contain multiple rotations of sampled flux data at 25ns (and other) sample rates. The tracks themselves are stored as a list of times between flux transitions so on a bank disk an image may only be a few bytes long.

In order to be compatible with Apple II, Commodore GCR and other floppy formats all 40 track SCP files are stored as 96TPI even if they are only 48TPI, so at a minimum there will be 80 tracks of data, half of which can be safely ignored (or are not actually in the image -- 0 bytes).

So the rabble7 flux dump is 96TPI 2 sided, with 168 tracks of data! Using HxC floppy Emulator to process the files generates a target that is 168 tracks single sided... WTF? In addition some of the other flags in the SCP file incorrectly identify the file as 360RPM. Unfortunately much of the possible helpful header information in SCP and HFE files are incorrect but you can help OSIHFE with some additional parameters. (80 track 2 sided disk images look a lot like OSI 8" 77 track dumps with the incorrect file headers present in many conversions.)

OSIHFE v2.2 has been updated to allow for skipping tracks in the case above, delete the last 3 tracks from the raw data, and save the data as an "SCP" file. Use the -k4 parameter to skip by 4 tracks when processing.

Using the data from Rabble7 after conversion to SCP with HxC Floppy Emulator, you can see the contents with the command
"osihfe -k4 -d -i rabble7.scp" (skip ahead 4 tracks at a time, show directory and file/disk information)

You should get the following:

Code: Select all

osihfe -k4 -d -i rabble7.scp

SCPFile: tracks 0 to 159, 1 sides, 3 revs, bitrate:246.91Kfps, 96TPI, 360RPM (header) 295RPM actual
File type OS65D5
OS65De File       Track range
-----------------------------
 OS65D V3.3          00 - 13
 COMPDOS 1.3         15 - 15
 BEXEC*              14 - 14
 Copier              16 - 17
 WORM                18 - 19
 INVADERS II         20 - 20
 INVADERS.CODE       22 - 24
 NEW 3D MAZE         25 - 27
 BASEBALL            28 - 30
 SAUCER              31 - 33
 LE PASSE            34 - 35
 BREAKTHRU           36 - 37

20 entries free out of 32

Nice!


I've been using a GreaseWeazle F7+ to read flux images in SCP format and load/manipulate them with OSIHFE etc. as well as the HxCFloppy Emulator software. Processing disks with GreaseWeazle is quick and painless. The whole process takes just a minute or two.

Unlike other platforms, although possible, I have never encountered OSI floppies that relied on special flux patterns on the disk. I'm more astounded that these disks even read! Everything I've seen has been either a variation of OS65D track format or standard OS65U files. The OSIDump format is similar to the Apple II .DSK format in that just sector data is stored, not the underlying flux pattern. This makes for the smallest disk format that preserves content. It is fine to store flux copies, but a 90K OSIDump requires 9-40MB to store as a flux image! Flux images may be better for marginal disks that require some processing to extract meaningful data. But don't store 2nd sides & half tracks if possible as they are just noise.

As a test I used GreaseWeazle to image OSI Dos 3.3 Tutorial 5 for C1P using a 360K/48TPI drive .
(Note using a 96TPI drive is fine for READS by adding a step=2 parameter to the tracks command)

HxC Floppy Emulator shows this:

HxC OS65D 3.3 Tutorial #5

osi-c1p-disk.jpg (152.03 KiB) Viewed 3726 times

The process for archiving disks is pretty simple.

#1 Image the disk as an SCP file

Code: Select all

C:\greaseweazle\win>gw read --tracks="c=0-39:h=0" --drive 0  osi-c1p.scp

Reading c=0-39:h=0 revs=3
T0.0: Raw Flux (123690 flux in 648.57ms)
T1.0: Raw Flux (127971 flux in 622.47ms)
T2.0: Raw Flux (154863 flux in 797.15ms)
T3.0: Raw Flux (156003 flux in 799.55ms)
T4.0: Raw Flux (153678 flux in 789.40ms)
T5.0: Raw Flux (153486 flux in 793.71ms)
T6.0: Raw Flux (144218 flux in 800.02ms)
T7.0: Raw Flux (122168 flux in 616.19ms)
T8.0: Raw Flux (119472 flux in 606.46ms)
T9.0: Raw Flux (124823 flux in 617.86ms)
T10.0: Raw Flux (119014 flux in 606.46ms)
T11.0: Raw Flux (109334 flux in 606.15ms)
T12.0: Raw Flux (101826 flux in 628.97ms)
T13.0: Raw Flux (121886 flux in 636.28ms)
T14.0: Raw Flux (120349 flux in 617.00ms)
T15.0: Raw Flux (119984 flux in 618.61ms)
T16.0: Raw Flux (120670 flux in 614.96ms)
T17.0: Raw Flux (117031 flux in 606.28ms)
T18.0: Raw Flux (117611 flux in 603.43ms)
T19.0: Raw Flux (120469 flux in 612.04ms)
T20.0: Raw Flux (119003 flux in 605.59ms)
T21.0: Raw Flux (119297 flux in 603.19ms)
T22.0: Raw Flux (119338 flux in 609.24ms)
T23.0: Raw Flux (120125 flux in 606.33ms)
T24.0: Raw Flux (119347 flux in 605.73ms)
T25.0: Raw Flux (119401 flux in 605.73ms)
T26.0: Raw Flux (118844 flux in 603.31ms)
T27.0: Raw Flux (134321 flux in 615.27ms)
T28.0: Raw Flux (178668 flux in 792.26ms)
T29.0: Raw Flux (154578 flux in 778.40ms)
T30.0: Raw Flux (119105 flux in 607.68ms)
T31.0: Raw Flux (136288 flux in 614.60ms)
T32.0: Raw Flux (183680 flux in 789.22ms)
T33.0: Raw Flux (154475 flux in 776.97ms)
T34.0: Raw Flux (122766 flux in 606.05ms)
T35.0: Raw Flux (119059 flux in 608.99ms)
T36.0: Raw Flux (120011 flux in 608.37ms)
T37.0: Raw Flux (118919 flux in 613.99ms)
T38.0: Raw Flux (118849 flux in 614.14ms)
T39.0: Raw Flux (116996 flux in 615.70ms)

Lets see what we got!

Code: Select all

C:\greaseweazle\win>osihfe -d -i osi-c1p.scp

SCPFile: tracks 0 to 78, 1 sides, 3 revs, bitrate:253.16Kfps, 96TPI, 360RPM (header) 301RPM actual
File type OS65D5
OS65D File  Track range
-----------------------
 OS65D3      00 - 13
 BEXEC*      14 - 16
 COPIER      17 - 18
 CHANGE      19 - 20
 CREATE      21 - 22
 DELETE      23 - 23
 DIR         24 - 24
 RANLST      25 - 26
 RENAME      27 - 27
 SECDIR      28 - 28
 SEQLST      29 - 30
 TRACE       31 - 31
 ZERO        32 - 33
 ASAMPL      34 - 34
 ATNENB      35 - 35
 COLORS      36 - 36
 MODEM       37 - 38
 COMPAR      39 - 39

46 entries free out of 64

[Now test the disk data]

Code: Select all

C:\greaseweazle\win>osihfe -t  osi-c1p.scp
Test: disk type OS65D5
Trk 00 Boot @ $2200/8 pages
Trk 01 1/8
Trk 02 1/8
Trk 03 1/8
Trk 04 1/8
Trk 05 1/8
Trk 06 1/1 2/1 3/1 4/2 5/1
Trk 07 1/8
Trk 08 1/8
Trk 09 1/8
Trk 10 1/8
Trk 11 1/1 2/1 3/1 4/1 5/1 6/1
Trk 12 1/1 2/1 3/1 4/1
Trk 13 1/8
Trk 14 1/8
Trk 15 1/8
Trk 16 1/8
Trk 17 1/8
Trk 18 1/8
Trk 19 1/8
Trk 20 1/8
Trk 21 1/8
Trk 22 1/8
Trk 23 1/8
Trk 24 1/8
Trk 25 1/8
Trk 26 1/8
Trk 27 1/8
Trk 28 1/8
Trk 29 1/8
Trk 30 1/8
Trk 31 1/8
Trk 32 1/8
Trk 33 1/8
Trk 34 1/8
Trk 35 1/8
Trk 36 1/8
Trk 37 1/8
Trk 38 1/8
Trk 39 1/5 2/2

#2 Convert to HFE or OSIDump format with OSIHFE. ( I find this to work better than converting with GreaseWeazle or HxC Floppy Emulator due to the way flux to bit conversion happens.)
Note you can drop the SCP file on OSIHFE in Windows Explorer to have the conversion happen by default. SCP->HFE, HFE->65D
Using the command line, you can specify SCP to 65D conversion directly using target file extensions to specify file type.

Code: Select all

C:\greaseweazle\win>osihfe osi-c1p.scp osi-c1p.65d
osihfe: Wrote file 'osi-c1p.65d'

[And view resulting OSIDump disk format]

C:\greaseweazle\win>osihfe -d osi-c1p.65d
OS65D File  Track range
-----------------------
 OS65D3      00 - 13
 BEXEC*      14 - 16
 COPIER      17 - 18
 CHANGE      19 - 20
 CREATE      21 - 22
 DELETE      23 - 23
 DIR         24 - 24
 RANLST      25 - 26
 RENAME      27 - 27
 SECDIR      28 - 28
 SEQLST      29 - 30
 TRACE       31 - 31
 ZERO        32 - 33
 ASAMPL      34 - 34
 ATNENB      35 - 35
 COLORS      36 - 36
 MODEM       37 - 38
 COMPAR      39 - 39

46 entries free out of 64

As for file size, storing only the tracks that contain useful data yields a file ~1/4 the size of rabble7.

C:\greaseweazle\win>dir osi-c1p*

Directory of C:\greaseweazle\win

02/12/2022 12:57 AM 92,160 osi-c1p.65d
02/12/2022 12:55 AM 9,491,946 osi-c1p.scp

A 10199% size difference between flux & osidump files.

OSIHFE 2.2 is available on my tools web page. Its feature set has expanded since the early days, and now include the ability to test & clean disk images. I struggled to get this updated in a timely manner as it was long overdue, so hopefully there aren't any huge problems. It may be updated again soon if I uncover something. The source is there which compiles on Mac/Linux too.

Cheers,
-Mark

[dave]

A 360k drive IS a 40-track drive. The 360k format (used ever since MS-DOS 2.0) is double-sided, double density. Under MS-DOS 1.x, the same drives and diskettes were called 320k, or four times the 80k capacity of OSI's (non-standard) single-sided, single-density format.

3.5" drives and high-density (1.2 MB) 5.25" drives use 80 tracks.

@Danny: Yes, of course you are right as usual. Thanks for the correction!

@Mark: Thanks for the enlightening analysis. I knew you'd have the answer. You've done some amazing work here!

[exidyboy]

Using the data from Rabble7 after conversion to SCP with HxC Floppy Emulator, you can see the contents with the command
"osihfe -k4 -d -i rabble7.scp" (skip ahead 4 tracks at a time, show directory and file/disk information)

You should get the following:

Code: Select all

osihfe -k4 -d -i rabble7.scp

SCPFile: tracks 0 to 159, 1 sides, 3 revs, bitrate:246.91Kfps, 96TPI, 360RPM (header) 295RPM actual
File type OS65D5
OS65De File       Track range
-----------------------------
 OS65D V3.3          00 - 13
 COMPDOS 1.3         15 - 15
 BEXEC*              14 - 14
 Copier              16 - 17
 WORM                18 - 19
 INVADERS II         20 - 20
 INVADERS.CODE       22 - 24
 NEW 3D MAZE         25 - 27
 BASEBALL            28 - 30
 SAUCER              31 - 33
 LE PASSE            34 - 35
 BREAKTHRU           36 - 37

20 entries free out of 32

While you can indeed get a directory listing via OSIHFE I found I was unable to boot the .65d in WinOSI and the test flag in OSIHFE namely:

Code: Select all

C:\Users\x\Documents\OSIHFE\OSIHFE>osihfe -k4 -t "C:\Users\x\Documents\SCP_files\rabble7_minus_9.scp"

yields:

Code: Select all

C:\Users\x\Documents\OSIHFE\OSIHFE>osihfe -k4 -t "C:\Users\x\Documents\SCP_files\rabble7_minus_9.scp"
Test: disk type OS65D5
Trk 00 Boot @ $2200/8 pages
Trk 01 1/8
Trk 02 1/8
Trk 03 1/8
Trk 04 1/8
Trk 05 1/8
Trk 06 1/1 2/1 3/1 4/2 5/1 6/1
Trk 07 1/8
Trk 08 1/8
Trk 09 1/8
Trk 10 1/8
Trk 11 1/1 2/1 3/1 4/1 5/1 6/1
Trk 12 1/1 2/1 3/1 4/1 5/1
Trk 13 1/8
Trk 14 1/8
Trk 15 1/8
Trk 16 1/8
Trk 17 1/8
Trk 18 1/8
Trk 19 1/8
Trk 20 1/8
Trk 21 No Sector 1
Trk 22 1/8
      Sector 1 bit error offset:90 (1 more errors)
Trk 23 1/8
Trk 24 1/8
Trk 25 1/8
Trk 26 1/8
      Sector 1 bit error offset:90
Trk 27 1/8
      Sector 1 bit error offset:92
Trk 28 1/8
      Sector 1 bit error offset:89
Trk 29 1/8
      Sector 1 bit error offset:92
Trk 30 1/8
      Sector 1 bit error offset:85 (1 more errors)
Trk 31 1/8
Trk 32 1/8
Trk 33 1/8
Trk 34 1/8
Trk 35 1/8
Trk 36 1/8
Trk 37 1/8
Trk 38 No Sector 1
Trk 39 No Sector 1

Do you think these are genuine pathologies with the disk?

[Mark]

[Super short answer: OSIHFE updated. I think the disk heads need cleaning, the data changes between samples & I've found dirty heads cause this problem. Also, this disk image is a strange mixture of OS65D for C4P and C1P, Some ACIA code references FC00 other F000 as well as DC80? Is there an expected memory layout for this machine? ROM BASIC? CEGMON? UK101?]

[Long answer follows]
Well the first thing I noticed is that there was no list of possibly damaged files in the test output of OSIHFE. Turns out I didn't have the code in place for processing the extended directory format on this disk. I have only had one other disk which uses 14 character filenames, and there is no indication on the disk how the directory is stored (OSI standard or this 14 character mod), it has to be figured out from content.

So with that fixed, I now see this

Code: Select all

C:\sample\rabble7>osihfe -t -k4 rabble7.scp
Test: disk type OS65D5
Trk 00 Boot @ $2200/8 pages
Trk 01 1/8
Trk 02 1/8
Trk 03 1/8
Trk 04 1/8
Trk 05 1/8
Trk 06 1/1 2/1 3/1 4/2 5/1 6/1
Trk 07 1/8
Trk 08 1/8
Trk 09 1/8
Trk 10 1/8
Trk 11 1/1 2/1 3/1 4/1 5/1 6/1
Trk 12 1/1 2/1 3/1 4/1 5/1
Trk 13 1/8
Trk 14 1/8
Trk 15 1/8
Trk 16 1/8
Trk 17 1/8
      Sector 1 bit error offset:84
Trk 18 1/8
Trk 19 1/8
      Sector 1 bit error offset:90
Trk 20 1/8
Trk 21 No Sector 1
Trk 22 1/8
      Sector 1 bit error offset:90 (1 more errors)
Trk 23 1/8
Trk 24 1/8
Trk 25 1/8
      Sector 1 bit error offset:91 (1 more errors)
Trk 26 1/8
      Sector 1 bit error offset:85 (3 more errors)
Trk 27 1/8
      Sector 1 bit error offset:91
Trk 28 1/8
Trk 29 1/8
      Sector 1 bit error offset:92
Trk 30 1/8
Trk 31 1/8
Trk 32 1/8
Trk 33 1/8
Trk 34 1/8
Trk 35 1/8
Trk 36 1/8
Trk 37 1/8
Trk 38 No Sector 1
Trk 39 No Sector 1
Possibly damaged file Copier
Possibly damaged file WORM
Possibly damaged file INVADERS.CODE
Possibly damaged file NEW 3D MAZE
Possibly damaged file BASEBALL

Yes, lots of errors. However the SCP file stores more than 1 revolution of samples in the image. I modified OSIHFE to allow for extraction of other disk revolutions with the new "-r3" switch, to process revolution 3 instead of the default revolution 1. This gives a slightly different result

Code: Select all

C:\sample\rabble7>osihfe -t -r3 -k4 rabble7.scp
Test: disk type OS65D5
Trk 00 Boot @ $2200/8 pages
Trk 01 1/8
Trk 02 1/8
Trk 03 1/8
Trk 04 1/8
Trk 05 1/8
Trk 06 1/1 2/1 3/1 4/2 5/1 6/1
Trk 07 1/8
Trk 08 1/8
Trk 09 1/8
Trk 10 1/8
Trk 11 1/1 2/1 3/1 4/1 5/1 6/1
Trk 12 1/1 2/1 3/1 4/1 5/1
Trk 13 1/8
Trk 14 1/8
Trk 15 1/8
Trk 16 1/8
Trk 17 1/8
Trk 18 1/8
Trk 19 1/8
      Sector 1 bit error offset:90
Trk 20 1/8
Trk 21 No Sector 1
Trk 22 1/8
Trk 23 1/8
Trk 24 1/8
Trk 25 1/8
Trk 26 1/8
      Sector 1 bit error offset:90
Trk 27 1/8
      Sector 1 bit error offset:91
Trk 28 1/8
Trk 29 1/8
      Sector 1 bit error offset:92
Trk 30 1/8
      Sector 1 bit error offset:83 (1 more errors)
Trk 31 1/8
Trk 32 1/8
Trk 33 1/8
Trk 34 1/8
Trk 35 1/8
Trk 36 1/8
Trk 37 1/8
Trk 38 No Sector 1
Trk 39 No Sector 1
Possibly damaged file WORM
Possibly damaged file NEW 3D MAZE
Possibly damaged file BASEBALL

Less errors on this revolution!

You can get a detailed report of where the errors are, but unfortunately OSIHFE processes all tracks as HFE files, so the offset doesn't map back to SCP. Anyway to see all the details, output to a log file with "-v -lmylogfile.txt". It's too long to bother listing here, but we can look at a single track as an example.

Code: Select all

Track 12 @ $4E400-$54C00 ($6800 long)
--------
(36)(ED)PE @ 4E414
(20)(DC)PE @ 4E424
(10)(26)(81)PE @ 4E438
(3B)(08)PE @ 4E448
(82)(18)(27)(18)(63)PE @ 4E46A
(27)PE @ 4E476
(02)(00)(81)PE @ 4E48F
(01)(00)PE @ 4E49F
(F0)(00)PE @ 4E4B0
(1C)PE @ 4E4B6
(10)(F2) Zeros 116 
PE @ 4E4F8

FF  Zeros 627 

43 57 12 58  Zeros 137 

76 01 01 4F 53 36 35 44 20 56 33 2E 33 20 20 20 
20 00 13 43 4F 4D 50 44 4F 53 20 31 2E 33 20 20 
20 15 15 42 45 58 45 43 2A 20 20 20 20 20 20 20 
20 14 14 43 6F 70 69 65 72 20 20 20 20 20 20 20 
20 16 17 57 4F 52 4D 20 20 20 20 20 20 20 20 20 
20 18 19 49 4E 56 41 44 45 52 53 20 49 49 20 20 
20 20 20 49 4E 56 41 44 45 52 53 2E 43 4F 44 45 
20 22 24 4E 45 57 20 33 44 20 4D 41 5A 45 20 20 
20 25 27 42 41 53 45 42 41 4C 4C 20 20 20 20 20 
20 28 30 53 41 55 43 45 52 20 20 20 20 20 20 20 
20 31 33 4C 45 20 50 41 53 53 45 20 20 20 20 20 
20 34 35 42 52 45 41 4B 54 48 52 55 20 20 20 20 
20 36 37 23 23 23 23 23 23 23 23 23 23 23 23 23 
23 23 23 23 23 23 23 23 23 23 23 23 23 23 23 23 
23 23 23 23 23 23 23 23 23 23 23 23 23 23 23 23 
23 23 23 23 23 23 23 23 23 23 23 23 23 23 23 23 
23 23 23 47 53  Zeros 23 
PE @ 4F433

FF FE  Zeros 72 

76 02 01 23 23 23 23 23 23 23 23 23 23 23 23 23 
23 23 23 23 23 23 23 23 23 23 23 23 23 23 23 23 
23 23 23 23 23 23 23 23 23 23 23 23 23 23 23 23 
23 23 23 23 23 23 23 23 23 23 23 23 23 23 23 23 
23 23 23 23 23 23 23 23 23 23 23 23 23 23 23 23 
23 23 23 23 23 23 23 23 23 23 23 23 23 23 23 23 
23 23 23 23 23 23 23 23 23 23 23 23 23 23 23 23 
23 23 23 23 23 23 23 23 23 23 23 23 23 23 23 23 
23 23 23 23 23 23 23 23 23 23 23 23 23 23 23 23 
23 23 23 23 23 23 23 23 23 23 23 23 23 23 23 23 
23 23 23 23 23 23 23 23 23 23 23 23 23 23 23 23 
23 23 23 23 23 23 23 23 23 23 23 23 23 23 23 23 
23 23 23 23 23 23 23 23 23 23 23 23 23 23 23 23 
23 23 23 23 23 23 23 23 23 23 23 23 23 23 23 23 
23 23 23 23 23 23 23 23 23 23 23 23 23 23 23 23 
23 23 23 23 23 23 23 23 23 23 23 23 23 23 23 23 
23 23 23 47 53  Zeros 41 
PE @ 50010

FF  Zeros 73 

76 03 01 4C 6B 22 20 61 27 20 F7 2C A9 D7 A0 20 
20 7D 2A 4C 74 04 20 50 2D 4C 62 04 60 E1 20 3D 
26 50 05 4A 4A 4A 90 F6 60 85 BF A2 05 A5 92 60 
48 AD C6 2A 8D 21 23 8D 22 23 68 4C CC 0A 08 48 
AD 21 23 8D D5 21 AD 22 23 8D DA 21 68 28 60 20 
20 15 8D ED 2C 8E 5A 30 8C 5B 30 BA E8 E8 8E 6F 
22 A2 04 B5 77 9D 78 3A CA D0 F8 A5 7B 38 E9 3A 
E8 E9 08 B0 FB 8E 7D 3A 60 20 CD 0C 20 BE 0C A9 
00 8D E5 2C 20 10 21 4C F7 2C 20 15 16 CA 30 32 
E0 09 10 2E E8 A9 00 38 2A CA D0 FC 8D 22 23 4C 
C6 00 20 C0 00 F0 1B 90 19 C9 2C D0 F5 20 15 16 
E0 06 D0 04 A2 00 F0 06 E0 07 D0 06 A2 08 8E 8A 
22 60 4C 1E 0E 20 FF 20 F0 10 90 0E C9 23 D0 0D 
20 4B 21 F0 05 20 13 0E D0 EE 4C C1 06 4C BD 06 
20 73 0A 20 D4 21 60 74 04 20 FF 20 4C 32 0A 20 
C6 00 C9 23 D0 0B 20 4B 21 F0 15 20 13 0E 4C 35 
0A 20 B2 47 53  Zeros 23 

FE  Zeros 89 

76 04 01 4C A7 2E A9 2E 8D C4 22 A9 79 8D C3 22 
68 AE 8A 22 9D 2B 23 68 9D 2A 23 F8 38 E9 01 D8 
9D 2C 23 8A D0 05 20 CC 23 F0 03 20 20 24 4C 91 
22 C9 50 D0 0F 20 C0 00 90 17 D0 F9 20 F7 2C A2 
00 4C 8B 22 C9 47 D0 09 20 CA 2E 20 67 29 4C 8E 
22 4C 0C 37 20 C0 00 F0 F8 90 F6 C9 2C D0 F5 20 
C0 00 20 B9 0C 20 72 16 68 8D 6D 30 68 8D 6E 30 
20 F7 2C A5 F5 48 A5 F4 48 A2 10 A9 00 85 F4 85 
F5 F0 0D 2E 92 2F 2E 93 2F CA 30 65 26 F4 26 F5 
38 A5 F4 E9 10 A8 A5 F5 E9 00 90 E7 85 F5 84 F4 
B0 E1 EA EA EA F8 18 6D 2A 23 D8 CD 2B 23 F0 02 
10 39 8D 78 2F A2 07 18 26 F4 26 F5 CA D0 F8 18 
A2 00 B5 F4 7D 26 23 9D AC 23 9D C3 23 E8 8A 49 
02 D0 EF AD 78 2F 20 ED 36 AD 26 23 85 FE AD 27 
23 85 FF A9 01 8D 5E 26 4C 54 27 20 F7 2C 4C D0 
10 AD 92 2F F0 AF F8 18 AA A9 00 69 01 CA D0 FB 
F0 A4 00 47 53  Zeros 114 

76 05 01 00 8E C4 7F 8C C5 7F 48 C9 0D F0 34 C9 
0A F0 38 20 68 7F BD 68 7F 48 29 01 D0 0F CD C3 
7F F0 19 A9 00 8D C3 7F A9 7F 4C 36 7F CD C3 7F 
F0 0A A9 01 8D C3 7F A9 6F 20 50 7F 68 20 50 7F 
4C 60 7F A9 0B 20 50 7F 4C 60 7F A9 23 20 50 7F 
4C 60 7F 09 01 8D 0A C1 A2 80 A0 00 C8 D0 FD E8 
D0 F8 60 68 AC C5 7F AE C4 7F 60 29 7F C9 61 90 
07 C9 7B B0 03 38 E9 20 C9 1F B0 02 A9 FF AA 60 
FF FF FF FF FF FF FF FF FF FF FF 12 12 02 37 2F 
5B 12 53 7B 27 4B 47 1B 63 1F 5F 0E 77 67 43 2B 
07 57 73 33 0F 3B 03 17 3F 6B 4F 12 62 4E 3A 4A 
42 5A 2E 16 32 6A 7A 26 1E 1A 0E 36 76 2A 52 06 
72 3E 66 5E 56 46 00 16 10 48 A9 DC 8D 0B C1 A9 
FF 8D 0A C1 A9 24 8D 05 C1 A9 00 8D 17 23 A9 7F 
8D 18 23 A9 00 8D C3 7F A9 7F 20 50 7F 20 50 7F 
A9 C8 8D 32 25 A9 7E 8D 33 25 68 60 42 45 58 45 
43 2A EA 47 53  Zeros 23 
PE @ 52284

FF  Zeros 8771

This is track 12, the directory track, and it's actually fine. This track gets partially rewritten when the directory is updated. The R/W head gets switched on and off between sectors, so it generally has a bunch of noise in it as we see.
After the index which starts this track, there is a bunch of random data and errors until we get to the "Zeros 627" message. That means there have been 627 bits of just clock and no data that happens when the disk serial port is inactive, but the disk is writing. It allows the serial port to sync when the data starts. Next comes the track 12 header and a bunch more zeros as part of the gap before the first sector. 43 57 12 58 Zeros 137
Then the 1st sector data comes with the sector start flag 76, sector number 01 and sector length (in pages) 01. The sector ends with 47 53 a few more zeros and the head is switched off & the process begins again for sector 2. A Parity Error happens again when the heads switch on/off between sectors, but does not indicate a data error. (Not all errors are significant, which is why a file mapping needs to be made before reporting errors.)

So lets looks at another track with errors. When reading revolution #1 track 17 has errors.

Code: Select all

Track 17 @ $6EC00-$75400 ($6800 long)
--------
(00)(00) Zeros 746 

43 57 17 58  Zeros 62 
PE @ 6F08B

FF  Zeros 73 

76 01 08 F1 AD 00 C0 30 FB A9 83 20 63 27 60 20 
54 27 20 1D 27 20 2E 27 20 B9 42 90 F1 85 05 20 
B9 42 90 EA 85 06 20 B9 42 85 07 AA A0 00 A9 01 
2C 10 C0 F0 FB AD 11 C0 91 FE C8 D0 F1 E6 FF CA 
D0 EC 60 18 AD 00 C0 10 09 AD 10 C0 4A 90 F5 AD 
11 C0 60 F8 A5 02 18 PE @ 6F48F

91 18 15 03 60 20 BC 26 20 1D 27 20 2E 27 A9 00 
85 0A E6 0A 20 B9 42 90 5D C9 76 D0 F7 20 B9 42 
C5 0A D0 F5 20 B9 42 AA A4 09 C6 0A D0 06 A5 02 
99 79 2E C8 8A 99 79 2E C8 84 09 E6 0A A0 00 A9 
01 2C 10 C0 F0 FB AD 11 C0 70 14 D1 FE 91 FE F0 
04 A9 00 F0 1B C8 D0 E7 E6 FF CA D0 E2 F0 B3 20... 

But when processing revolution 3, there are no errors

Code: Select all

Track 17 @ $6EC00-$75400 ($6800 long)
--------
(00)(00) Zeros 745 

43 57 17 58  Zeros 62 
PE @ 6F08B

FF  Zeros 73 

76 01 08 F1 AD 00 C0 30 FB A9 83 20 63 27 60 20 
54 27 20 1D 27 20 2E 27 20 B9 42 90 F1 85 05 20 
B9 42 90 EA 85 06 20 B9 42 85 07 AA A0 00 A9 01 
2C 10 C0 F0 FB AD 11 C0 91 FE C8 D0 F1 E6 FF CA 
D0 EC 60 18 AD 00 C0 10 09 AD 10 C0 4A 90 F5 AD 
11 C0 60 F8 A5 02 18 69 01 D8 C5 03 60 20 BC 26 
20 1D 27 20 2E 27 A9 00 85 0A E6 0A 20 B9 42 90 
5D C9 76 D0 F7 20 B9 42 C5 0A D0 F5 20 B9 42 AA 
A4 09 C6 0A D0 06 A5 02 99 79 2E C8 8A 99 79 2E 
C8 84 09 E6 0A A0 00 A9 01 2C 10 C0 F0 FB AD 11 
C0 70 14 D1 FE 91 FE F0 04 A9 00 F0 1B C8 D0 E7 
E6 FF CA D0 E2 F0 B3 20 73 2D 2A 2A 20 50 61 72... 

So comparing the two dumps, rev1 has a parity error at the line 11 C0 60 F8 A5 02 18 , and the data doesn't match with rev3 again until 4 bytes later at 03 60 20 BC. It's not easy to reconstruct the bad data. It may be a glitch that wouldn't affect real disk hardware, but without locating it in the flux data I can't tell what exactly is wrong. OSIHFE doesn't have that capability currently.

When comparing disk dump images, it helps to run the disk through an OSIHFE clean operation. This processes known disk layouts to remove extra noise bytes from disk dump images, making binary comparisons easier.
Comparing the Rabble disk to OS65D for C1P and OS65D for C4P shows some ACIA locations have been patched for F000, others remain at FC00. It looks like a C4P OS65D was modified for C1P/UK101 except not all the memory locations were updated. There are a few bytes different where error messages were made lower case, and some patches for extended directory layout. Booting this disk ends up jumping into ROM monitor after loading tracks 0-8+. Not sure what ROM it is expecting.
With a better idea of the memory map I can make an emulation that matches. i.e. UK101 with serial keyboard perhaps?
Can you have another go at disk imaging after a head clean? (Just a cotton swab and some isopropyl alcohol should do it.) If not, it may be possible to overcome the glitches in this data with more inspection.

Cheers,
-Mark

[Mark]

Is there an expected memory layout for this machine? ROM BASIC? CEGMON? UK101?

I had a followup email that gave me a lot more information about the Australian OZI Computer's Rabble 65. The 12MB Rabble 65 technical manual has been posted here, and contains a wealth of information.

The Rabble 65 has the same basic memory layout and hardware as the OSI/UK101, but seemingly designed with knowledge of the limitations of earlier machines. It appears to be a single board computer with relocatable keyboard.
The disk hardware is the same at the same memory addresses as OSI. The keyboard layout has even more keys, controlled by a 6532 RIOT and leftover bits from a 6522VIA. It contains ACIA hardware at both F000 and FC00 with cassette or RS-232 I/O & software selectable baud rate. The addresses are decoded to a 4-byte range leaving the entire rest of F000+ area available for ROM. The system ROM is 8K, there can be four 8K bank switched ROMs which included ROM BASIC, ROM FORTH, ASSEMBLER, and user space/RAM. The head end card expansion I/O area is present (C700-C73F), along with 6821 PIA printer port (F400/F420), and a monochrome 6845 VDC based video display at D000-D7FF & C01C-C01F. The system supported 64x32 or 80x25 video (or anything you could get the 6845 to do) with a normal and alternate character sets.

Software-wise, most C4P OSI BASIC programs would work with modifications for any directly polled keyboard routines. The disk OS on Rabble7 seems to be a slightly modified OS65D with 14 character filename support. Because the Rabble65 ACIA works at both F000 and FC00 it explains why Rabble7 could use both addresses interchangeably. The programs I've looked at make use of the ROM routines present in the system ROM.

Hopefully the system ROMs can be located to make a complete virtual system someday. With a board scan maybe this computer could live again?
-Mark

[exidyboy]

Thanks Mark,

I am getting slightly different results to you when using the latest OSIHFE which you have kindly updated to assist in this digital preservation project.

What I am finding is less errors reported and I am not seeing differences between revolutions. Other than doing something wrong the only thing I can think of that I might be doing differently to you is that I am using the latest beta of HxC as Jeff suggested at the end of this thread:
https://torlus.com/floppy/forum/viewtop ... 417#p24417

I have shown my results below for revolutions 1, 2 and 3.

Code: Select all

osihfe -t -r1 -k4 rabble7_minus_7.scp	osihfe -t -r2 -k4 \rabble7_minus_7.scp	osihfe -t -r3 -k4 rabble7_minus_7.scp
Test: disk type OS65D8			Test: disk type OS65D8			Test: disk type OS65D8
Trk 00 Boot @ $2200/8 pages		Trk 00 Boot @ $2200/8 pages		Trk 00 Boot @ $2200/8 pages
Trk 01 1/8				Trk 01 1/8				Trk 01 1/8
Trk 02 1/8				Trk 02 1/8				Trk 02 1/8
Trk 03 1/8				Trk 03 1/8				Trk 03 1/8
Trk 04 1/8				Trk 04 1/8				Trk 04 1/8
Trk 05 1/8				Trk 05 1/8				Trk 05 1/8
Sector 1 bit error offset:01 (3 more errors)	 				[same for -r2 and -r3]
Trk 06 1/1 2/1 3/1 4/2 5/1 6/1		Trk 06 1/1 2/1 3/1 4/2 5/1 6/1		Trk 06 1/1 2/1 3/1 4/2 5/1 6/1
Trk 07 1/8				Trk 07 1/8				Trk 07 1/8
Trk 08 1/8				Trk 08 1/8				Trk 08 1/8
Trk 09 1/8				Trk 09 1/8				Trk 09 1/8
Trk 10 1/8				Trk 10 1/8				Trk 10 1/8
Trk 11 1/1 2/1 3/1 4/1 5/1 6/1		Trk 11 1/1 2/1 3/1 4/1 5/1 6/1		Trk 11 1/1 2/1 3/1 4/1 5/1 6/1
Trk 12 1/1 2/1 3/1 4/1 5/1		Trk 12 1/1 2/1 3/1 4/1 5/1		Trk 12 1/1 2/1 3/1 4/1 5/1
Trk 13 1/8				Trk 13 1/8				Trk 13 1/8
Trk 14 1/8				Trk 14 1/8				Trk 14 1/8
Trk 15 1/8				Trk 15 1/8				Trk 15 1/8
Trk 16 1/8				Trk 16 1/8				Trk 16 1/8
Trk 17 1/8				Trk 17 1/8				Trk 17 1/8
Trk 18 1/8				Trk 18 1/8				Trk 18 1/8
Trk 19 1/8				Trk 19 1/8				Trk 19 1/8
Trk 20 1/8				Trk 20 1/8				Trk 20 1/8
Trk 21 No Sector 1			Trk 21 No Sector 1			Trk 21 No Sector 1
Trk 22 1/8				Trk 22 1/8				Trk 22 1/8
Trk 23 1/8				Trk 23 1/8				Trk 23 1/8
Trk 24 1/8				Trk 24 1/8				Trk 24 1/8
Trk 25 1/8				Trk 25 1/8				Trk 25 1/8
Trk 26 1/8				Trk 26 1/8				Trk 26 1/8
Trk 27 1/8				Trk 27 1/8				Trk 27 1/8
Trk 28 1/8				Trk 28 1/8				Trk 28 1/8
Trk 29 1/8				Trk 29 1/8				Trk 29 1/8
Trk 30 1/8				Trk 30 1/8				Trk 30 1/8
Trk 31 1/8				Trk 31 1/8				Trk 31 1/8
Trk 32 1/8				Trk 32 1/8				Trk 32 1/8
Trk 33 1/8				Trk 33 1/8				Trk 33 1/8
Trk 34 1/8				Trk 34 1/8				Trk 34 1/8
Trk 35 1/8				Trk 35 1/8				Trk 35 1/8
Trk 36 1/8				Trk 36 1/8				Trk 36 1/8
Trk 37 1/8				Trk 37 1/8				Trk 37 1/8
Trk 38 No Sector 1			Trk 38 No Sector 1			Trk 38 No Sector 1
Trk 39 No Sector 1			Trk 39 No Sector 1			Trk 39 No Sector 1
Trk 40 : No Track Header		Trk 40 : No Track Header		Trk 40 : No Track Header
Trk 41 : No Track Header		Trk 41 : No Track Header		Trk 41 : No Track Header
Trk 42 : No Track Header		Trk 42 : No Track Header		Trk 42 : No Track Header
Trk 43 : No Track Header		Trk 43 : No Track Header		Trk 43 : No Track Header
Trk 44 : No Track Header		Trk 44 : No Track Header		Trk 44 : No Track Header

I wonder if you can duplicate these results?

If correct then only Tracks 5 and 21 have errors (assuming 38 and 39 were never written).
Could you also help me understand what "1/8" means?
In terms of interpreting the output does "Sector 1 bit error offset:01 (3 more errors)" mean Sector 1 has an error.
For Track 21 does "No Sector 1" mean an error with that sector but the other 7 are OK?

I have also observed that OSIFE says that there are only 3 revolutions in the .scp and gives an error if I try to access revolution 4:

Code: Select all

C:\Users\x\OSIHFE_221\OSIHFE>osihfe -t -r4 -k4 "C:\Users\x\SCP_files\rabble7_minus_7.scp"
Error specified SCP revolution 4 does not exist
Error while loading SCP track

But I imaged the Rabble65 disks with the default settings which is to capture 5 revolutions of flux transitions in the Kryoflux preservation stream. Visualisation the raw streams in the Kryoflux GUI suggests that 5 revolutions were captured.
I wonder if HxC is not exporting all give revolutions when it creates an .scp ?

[Mark]

If you use "OSIHFE -i file.scp" it should show you the information contained in the SCP header regarding number of rotations stored. It is stored as the 6th character (or position 5 starting at 0) in the SCP file if you load it into a hex editor. Yes it appears HxC only writes 3 revolutions to SCP files.

The disk information listed for each track is the sector number and the number of pages in the sector. 1/8 means sector 1, 8*256 bytes of data. Generally* track 0 on OSI disks is special. It contains no normal header, just a load address and the number of pages that follow. (* DOS/65 may use track 0 as a regular track for data disks.)
An OSI floppy may not have any sectors on a track if nothing has been written after formatting, thus the no sector 1 message. There must be a sector 1 to have a sector 2 (unless there has been corruption).
No track header means a track header could not be found (track is corrupted/unreadable).
Treat the bit errors as decoding errors, the offset isn't meaningful with scp files due to the internal conversion to hfe format. Under normal circumstances all revolutions of a disk should decode into the same data...

Under OS65D sectors can have varying lengths from 1 to 13 depending on disk (5.25" or 8") and number of previous sectors. You can store data as one large sector but not the same amount of data as many single sectors due to the intersector gaps & headers consuming space. So on 5.25" you can store one 8 page sector but only 6 or 7 single page sectors ( Maybe it's less, I forget the exact timing.) You can also have varying length sectors. Sector 1 can be one page, sector 2 three pages, sector 3 two pages. OS65D will only load files listed in the directory starting at sector 1 of the specified tracks. You can manually load data from any track & sector though, so some small programs can "hide" on sector 2+ of a track.

Please delete the extra kryoflux tracks before loading into HxC & converting to SCP. You should only go to 79.1. OSI 5.25" disks are single sided 40 track devices (0 to 39), 8" are single sided 77 track devices (0-76). Some accommodation has been made to support 80 track 3.5" OSI drives. But the extra kryoflux tracks are confusing OSIHFE into believing you have an 8" image which is why the directory is not listed. The directory lives on different tracks between 5.25 & 8" disks.

It would be best to sample these 5.25" disks on a 40 track 48TPI drive, single sided, without 1/2 steps or extra tracks.
Hope this helps!