• Please review our updated Terms and Rules here

What is the CP/M soft sector skew on the Victor 9000?

H

hjalfi

Experienced Member
Joined
Feb 11, 2017
Messages
265
Location
Zürich, Switzerland
Context: I'm adding filesystem support to FluxEngine (<plug> https://cowlark.com/fluxengine/ </plug>) and have some CP/M images for the Victor 9000. I have a CP/M filesystem plugin, but of course any soft sector skew on the filesystem isn't stored anywhere actually in the filesystem, and everything is complicated because the Victor 9000 uses different numbers of sectors per track...

I've figured out that most of the disk uses a constant skew factor of 4, but some files still look garbled, so clearly other disk zones use a different skew. Or something. Anyone know what it is? I can't find much in the way of CP/M documentation for this machine.
 
Super excited to hear you're working on filesystem support for FluxEngine. I've uploaded a bunch of Victor floppies to archive.org.

To get to your question, according to the mame implementation, the interleave factor is the first nibble of the 33rd byte of the Disc label, which indeed is 4 for several CP/M disks I just checked. I did find one disk that has that nibble as 0.

Mame:
//Sector Interleave
osd_printf_verbose("Sector Interleave: %02x\n", data[33]);
Click to expand...

This is also mentioned in the ROM bios floppy code, although the note indicates it's unused. I couldn't find any reference to the int_fact in the rest of the assembly.
;
; FLOPPY DISK LABEL FORMAT
;

fd_lbl struc;

valid dw ?; must be ff00 to be a loadable O/S
load dw ?; system load address
paras dw ?; size of system
entry_offset dw ?; program's start offset from segment
entry_segment dw ?; program's start segment
disk_id db 8 dup (?); disk identification (unused)
system_id db 8 dup (?); system identification (unused)
sector_size dw ?; floppy's sector size
data_start dw ?; offset to unreserved region
boot_start dw ?; boot sector origin
flags db ?; (unused)
int_fact db ?; sector interleave (unused)
disk_type db ?; disk version
reserved db 3 dup (?); (unused)
speed_control db 18 dup (?); speed control table
zone_table db 15 dup (?); locations of speed change
sectors_track db 15 dup (?); sectors per track

fd_lbl ends;
Click to expand...
 
One last thought, I did find at the end of the Hardware Reference manual, in Appendix F

Floppy access times:
2 micro-second per bit data transfer rate, with an interleave factor of 3. Average seek time is approximately
90 milli-seconds.
Click to expand...
 
I did find that last, but I believe that's talking about the hard sector interleave, not the soft sector interleave... yes, there's both.

So if the soft sector interleave is 4, why am I getting bad files? I wonder if the zone table is bad, again. If one of the tracks is read with the wrong number of sectors, that would cause very bad things to happen. (Apparently the documentation is wrong and doesn't match what the machines are actually doing!) The definition file is here:

github.com

fluxengine/victor9k_ss.textpb at master · davidgiven/fluxengine

PSOC5 floppy disk imaging interface. Contribute to davidgiven/fluxengine development by creating an account on GitHub.
github.com github.com
 
get on the applesauce discord and look in the victor topic
a lot of work has been done there, and there are known problems with the documentation

it is incredibly annoying that this work is getting siloed and there are two groups that
apparently are unaware of the others existence
 
hjalfi said:
I did find that last, but I believe that's talking about the hard sector interleave, not the soft sector interleave... yes, there's both.

So if the soft sector interleave is 4, why am I getting bad files? I wonder if the zone table is bad, again. If one of the tracks is read with the wrong number of sectors, that would cause very bad things to happen. (Apparently the documentation is wrong and doesn't match what the machines are actually doing!) The definition file is here:

github.com

fluxengine/victor9k_ss.textpb at master · davidgiven/fluxengine

PSOC5 floppy disk imaging interface. Contribute to davidgiven/fluxengine development by creating an account on GitHub.
github.com github.com
Click to expand...
Hi Hjalfi,
Code: 
 cpmfs {
        filesystem_start {
            track: 5
        }
I'm confused about why you're starting the filesystem on track 5? When I look at the raw .img file in a hex editor it looks like the directory listing starts at byte 2048 decimal or 0x800h. By my reconning that would be the 4th logical sector of track 1. Am I misunderstanding the organization? It looks to me like you're throwing away some valid tracks at the start of the disk.

Something strange is happening--perhaps user error on my part--as I built your latest version and was able to load a few disks and see their directory structures in the GUI, but other disks were pulling in garbage. I realized that only the SS disks has support for the filesystem configuration so I created an updated victor9k_ds.textpb that added the additional filesystem config. After doing so the DS disks directories were loading correctly, but when I went back to look at the SS disks those no longer pulled up the correct directory structure, which was weird as I hadn't changed the SS configuration.

Now when the directory structures seemed to show the correct data, I viewed the contents of the files, they seemed to be pointing to the wrong physical layers. I believe that's what you're trying to fix here.

I just realized I think I can view these disks in a hex editor on the actual vintage hardware. I can take a run at that tomorrow.
 
Uh-oh. I have the horrible feeling that the number of reserved tracks can  vary depending on which disk --- I've been testing with the WordStar disk you sent me; what disk are you looking at? This will require special logic to pull the right number out of the boot sector in the CP/M filesystem code, which I've been very much trying to avoid.
 
I was looking back through the mame code again, and found this comment in victor9k_dsk.cpp. I wonder if it's that byte 28 is variable? And then the byte 32 is the interleave? Actually, forget the addresses in these comments. I pushed a PR last week that fixed some errors in the offsets and I'm realizing I neglected to update the comment.

26 Sector size byte count for sectors.

28 Data start first data sector on disc
(absolute sectors).

30 Boot start first absolute sector of
program for boot to load at
'load address' for 'length'
paragraphs.

32 Flags indicators:
bit meaning
15-12 interleave factor
(0-15)
0 0=single sided
1=double sided

34 Disc type 00 = CP/M
01 = MS-DOS
Click to expand...

In terms of what disks I'm looking at, I don't have that many examples of CP/M. The disks I have are here: https://archive.org/details/@pauldevine?&and[]=subject:"CP/M-86". The older CP/M disks are all single sided and use an earlier version of CP/M. The later disks are all double sided and use a later version of CP/M. I wonder if there's a difference in how the versions layout the physical sectors?

I hadn't looked at that wordstar disk in a while. I see what you're looking at now. I found another disk, the CP/M-86 Kopie 1 17.3.83 Version 1.0 where it seems to start at 1024. These look like they're all over the place.
 
I tried opening the CP/M disks inside the hex viewer I have on the Victor. I was thinking that could help us understand something about the layout. Unfortunately I only have the hex viewer for DOS, and it uses the DOS APIs to access the file system. So I got a bunch of non-DOS disk errors instead of any actual values. I also just acquired some new Victor programming manuals I've never seen before. I'll scan them and upload them. I'm hoping there's some info in there about the file formats.
 
You must log in or register to reply here.
Back
Top