Archiving OSI Disks with a Kryoflux

exidyboy
Posts: 9
Joined: Tue Feb 08, 2022 10:34 am

Re: Archiving OSI Disks with a Kryoflux

Post by exidyboy »

Mark wrote: Sun Mar 20, 2022 2:16 am 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 developer pointed out to me that there is an Internal Parameter you can set called "SCPEXPORT_NUMBER_OF_REVOLUTIONS" that changes the number of revolutions written in any .scp file. Changing this to 5 allows OSIHFE to pick up one more revolution but it cannot find -r5. I could not get the SuperCard Pro utility to run on my computer to independently verify how many revolutions are present but the header suggests there are 5.

OSIHFE with the -i flag confirms there are 5 but gives me an error "Error while loading SCP track" if I try and do a -t on revolution 5 with -r5
Mark wrote: Sun Mar 20, 2022 2:16 am 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).
OK so those tracks are probably just unwritten.
Mark wrote: Sun Mar 20, 2022 2:16 am 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...
OK
Mark wrote: Sun Mar 20, 2022 2:16 am 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).
Yes I made an error and did remove enough tracks from the preservation stream folder before dropping those on the HxC tool and exporting the .scp.
Mark wrote: Sun Mar 20, 2022 2:16 am 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.
Thanks for the additional info regarding the disk layout.
Mark
Posts: 297
Joined: Tue Sep 16, 2008 6:04 am
Location: Madison, WI
Contact:

Re: Archiving OSI Disks with a Kryoflux

Post by Mark »

Hi,
Using the current beta HxC floppy emulator software V2.5.10.1, I loaded the rabble7 kryoflux tracks you provided earlier.
I set "SCPEXPORT_NUMBER_OF_REVOLUTIONS" to 5 and saved the data to an SCP file.
The resulting SCP file did have 5 revolutions specified in the file header, however the Track Header Data table in the SCP file only has 4 pointers to flux data, the fifth one is zero indicating the track does not exist.

[The header in the SCP file should have the same offsets across all files for files with the same number of tracks until the track data table, so the following offsets should be valid in any file you create.]
The track header starts with "TRK" at offset $2A8 in the SCP file. Starting at $2AC, each track entry consists of three values 4 bytes long; the track indextime, length, and the offset to track flux data. When you get to the fifth entry at $02DC all values are 0 (no data present). Directly after that, the flux data for the first revolution starts.
Hex View
Hex View
scp-no-rev5.gif (5.79 KiB) Viewed 2396 times
(Green indicates start of each track header).

I'm not sure why the scp file is missing revolution 5, but it explains why OSIHFE failed to extract it. How many revs are in the kyroflux data?

Maybe report it as a bug to the developer?
exidyboy
Posts: 9
Joined: Tue Feb 08, 2022 10:34 am

Re: Archiving OSI Disks with a Kryoflux

Post by exidyboy »

The tracks contain 6 index timing records so there are 5 full revolutions recorded.
exidyboy
Posts: 9
Joined: Tue Feb 08, 2022 10:34 am

Re: Archiving OSI Disks with a Kryoflux

Post by exidyboy »

Mark wrote: Sat Mar 05, 2022 2:05 am 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.
So as the HxC tool can also output .hfe would it make sense to export in that format rather than .scp to make it easier to map back?
Mark wrote: Sat Mar 05, 2022 2:05 am 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.
Are you saying you applied the OSIHFE clean operation to the files in your example, or that I should do that in future or that you can't because the Rabble65 disk layout is too different and not (yet at least) a "known disk layout".
exidyboy
Posts: 9
Joined: Tue Feb 08, 2022 10:34 am

Re: Archiving OSI Disks with a Kryoflux

Post by exidyboy »

Mark wrote: Thu Apr 07, 2022 7:26 am Maybe report it as a bug to the developer?
Jeff has issued a new HxC tools beta that addresses this issue. The fifth revolution is now exported in the .scp and it offers clean reads of tracks
22, 28 and 29 which were not available from any other revolution :o

What this gives "for free" is INVADERS.CODE and should allow the recovery of BASEBALL if there is a way to combine good tracks from different revolutions. For example take the good read of track 30 from r3 and paste it into r5.

It looks like NEW 3D MAZE is unrecoverable because it requires Track 27 which was not captured without error in any revolution. This would be the track to hone in on when the opportunity arises to access this floppy again.

Code: Select all

osihfe -t -r1 -k4 					osihfe -t -r2 -k4 					osihfe -t -r3 -k4					osihfe -t -r4 -k4 					osihfe -t -r5 -k4
Test: disk type OS65D5					Test: disk type OS65D5					Test: disk type OS65D5					Test: disk type OS65D5					Test: disk type OS65D5
Trk 00 Boot @ $2200/8 pages				Trk 00 Boot @ $2200/8 pages				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 01 1/8						Trk 01 1/8
Trk 02 1/8						Trk 02 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 03 1/8						Trk 03 1/8
Trk 04 1/8						Trk 04 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						Trk 05 1/8						Trk 05 1/8
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 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 07 1/8						Trk 07 1/8
Trk 08 1/8						Trk 08 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 09 1/8						Trk 09 1/8
Trk 10 1/8						Trk 10 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 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 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 13 1/8						Trk 13 1/8
Trk 14 1/8						Trk 14 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 15 1/8						Trk 15 1/8
Trk 16 1/8						Trk 16 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 17 1/8						Trk 17 1/8
Trk 18 1/8						Trk 18 1/8 Sector 1 bit error offset:91 (1 more errors)	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 19 1/8						Trk 19 1/8
Trk 20 1/8						Trk 20 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 21     No Sector 1					Trk 21     No Sector 1
Trk 22 1/8 Sector 1 bit error offset:90 (1 more errors)	Trk 22 1/8 Sector 1 bit error offset:90 (1 more errors)	Trk 22 1/8 Sector 1 bit error offset:90 (1 more errors)	Trk 22 1/8 Sector 1 bit error offset:90 (1 more errors)	Trk 22 1/8
Trk 23 1/8						Trk 23 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 24 1/8						Trk 24 1/8
Trk 25 1/8						Trk 25 1/8						Trk 25 1/8						Trk 25 1/8						Trk 25 1/8
Trk 26 1/8 Sector 1 bit error offset:90			Trk 26 1/8 Sector 1 bit error offset:90			Trk 26 1/8						Trk 26 1/8						Trk 26 1/8 Sector 1 bit error offset:90
Trk 27 1/8 Sector 1 bit error offset:92			Trk 27 1/8 Sector 1 bit error offset:92			Trk 27 1/8 Sector 1 bit error offset:92			Trk 27 1/8 Sector 1 bit error offset:92			Trk 27 1/8 Sector 1 bit error offset:92
Trk 28 1/8 Sector 1 bit error offset:89			Trk 28 1/8 Sector 1 bit error offset:89			Trk 28 1/8 Sector 1 bit error offset:89			Trk 28 1/8 Sector 1 bit error offset:89			Trk 28 1/8
Trk 29 1/8 Sector 1 bit error offset:92			Trk 29 1/8 Sector 1 bit error offset:92			Trk 29 1/8 Sector 1 bit error offset:92			Trk 29 1/8 Sector 1 bit error offset:92			Trk 29 1/8
Trk 30 1/8 Sector 1 bit error offset:85 (1 more errors)	Trk 30 1/8 Sector 1 bit error offset:85			Trk 30 1/8						Trk 30 1/8 Sector 1 bit error offset:91			Trk 30 1/8 Sector 1 bit error offset:91
Trk 31 1/8						Trk 31 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 32 1/8						Trk 32 1/8
Trk 33 1/8						Trk 33 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 34 1/8						Trk 34 1/8
Trk 35 1/8						Trk 35 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 36 1/8						Trk 36 1/8
Trk 37 1/8						Trk 37 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 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 39     No  Sector 1					Trk 39     No Sector 1
Possibly damaged file INVADERS.CODE			Possibly damaged file WORM				Possibly damaged file INVADERS.CODE			Possibly damaged file INVADERS.CODE			Possibly damaged file NEW 3D MAZE
Possibly damaged file NEW 3D MAZE			Possibly damaged file INVADERS.CODE			Possibly damaged file NEW 3D MAZE			Possibly damaged file NEW 3D MAZE			Possibly damaged file BASEBALL
Possibly damaged file BASEBALL				Possibly damaged file NEW 3D MAZE			Possibly damaged file BASEBALL				Possibly damaged file BASEBALL	
							Possibly damaged file BASEBALL
Post Reply