• Please review our updated Terms and Rules here

Victor 9000 HDD Images - direct manipulation

drdanj

drdanj

Experienced Member
Joined
Jan 5, 2013
Messages
118
Location
UK
Hello - it's been a while since I surfaced on here - I'm really pleased to see the amount of victor wrangling that's been going on, and was impressed to see the amount of disk images that are now on archive.org! Big thanks to @pdevine and @philpem for all the work on that, and others I've probably missed!

I was also really pleased to see that someone's finally dug out the schematics for the DMA board which I'd have attempted to start reverse engineering a few years back, then lost the will on. I'm gradually reconstructing that in kicad when I have moments here and there...

But the main point of my post. I've got mine running with rascsi at the mo - it's convenient, it works well if a little warm, and I can plonk images on and off it. I've been starting to muck about with trying to directly manipulate the partitions on a PC, which is going to be *much* easier for getting files on and off, but a couple of things get in the way -> the drive label is certainly not an MBR (not too much of a problem, we know what that looks like), but the boot sector on the HDD partitions is definitely not like a standard PC FAT12 boot sector... I've been gradually poking at it but I thought it wise to check - has anyone actually worked out the format of the boot sector properly? And managed to manipulate the images directly by sticking a PC boot sector on then fiddling in something like winimage? Edit: I've attached some of what I've worked out (disk label is documented in various places), alongside a big 120mb image that has a few different partitions on it.
 

Attachments

Last edited:
drdanj said:
But the main point of my post. I've got mine running with rascsi at the mo - it's convenient, it works well if a little warm, and I can plonk images on and off it. I've been starting to muck about with trying to directly manipulate the partitions on a PC, which is going to be *much* easier for getting files on and off, but a couple of things get in the way -> the drive label is certainly not an MBR (not too much of a problem, we know what that looks like), but the boot sector on the HDD partitions is definitely not like a standard PC FAT12 boot sector... I've been gradually poking at it but I thought it wise to check - has anyone actually worked out the format of the boot sector properly? And managed to manipulate the images directly by sticking a PC boot sector on then fiddling in something like winimage? Edit: I've attached some of what I've worked out (disk label is documented in various places), alongside a big 120mb image that has a few different partitions on it.
Click to expand...
Yes, I've done quite a bit of reverse engineering already. I have code here https://github.com/pauldevine/user_port_v9k/ that will parse a Victor formatted hard disk into the underlying virtual disk partition structure. I created a little raspberry pico-based sd card reader that connects to the user port on the V9K. I didn't punish it as I was viewing this as a prototype for another project I describe below. I do have a couple boards made if they're of any interest to anyone.

This code I've tested out with several images I created from the rascsi. I didn't get it to work with images from the MFM emulator, but I think that was me misunderstanding something about the MFM emulator preamble before the disk data. The code will open the rascsi disk image and read the contents of the drive and present it as a DOS disk through a custom dos driver for DOS 3.1. I didn't interpret the FAT tables as I was relying on DOS running on the Victor to do that portion.

I got the Victor disk structure information from appendix K in this version of the Hardware Reference http://www.bitsavers.org/pdf/victor/victor9000/Victor_9000_Hardware_Reference_Rev_0_19831005.pdf
Thanks to @westveld for that version.

The actual disk structures are defined in /common/dos_device_payloads.h and the code to interpret them is in /pico/lib/v9k_hard_drives.c. Sorry the organization of the files is a bit wonky. I was kind of learning as going and intended to go back and clean things up but just kept moving. The SD card to user port isn't particularly fast—think floppy speeds—but it does allow you to mount a disk image relatively easily. It can't boot the machine as it depends on loading a driver from config.sys

I'm currently working on an expansion port version that will be basically the same SD card -> Victor but I'm trying to emulate the xebec/DMA board using the Pico. I'm looking to create something that's bootable and much faster than the user port version. I have a prototype board setup at the hardware level. The timing is obviously much tighter on the expansion card than bit-banging the user port so I'm still doing a proof of concept of the whole situation in the pico software.
 
pdevine said:
I didn't get it to work with images from the MFM emulator, but I think that was me misunderstanding something about the MFM emulator preamble before the disk data.
Click to expand...
9000 sample I have here is format Xebec_104527_512B. I've found out more about how the silly Xebec cards work. For some there is a skew between the sector header and the sector data that I added command line flag to handle. Don't know how to detect when its needed so needs to be manually specified.

Try something like
mfm_util --emu victor-msdos3-clean-emulation --ext /tmp/ext --xebec_skew --ana
 
pdevine said:
The actual disk structures are defined in /common/dos_device_payloads.h and the code to interpret them is in /pico/lib/v9k_hard_drives.c. Sorry the organization of the files is a bit wonky. I was kind of learning as going and intended to go back and clean things up but just kept moving. The SD card to user port isn't particularly fast—think floppy speeds—but it does allow you to mount a disk image relatively easily. It can't boot the machine as it depends on loading a driver from config.sys
Click to expand...

This is excellent! Can you slap a license on it? GPL? BSD? I'll have a play with it a bit later.

pdevine said:
I'm currently working on an expansion port version that will be basically the same SD card -> Victor but I'm trying to emulate the xebec/DMA board using the Pico. I'm looking to create something that's bootable and much faster than the user port version. I have a prototype board setup at the hardware level. The timing is obviously much tighter on the expansion card than bit-banging the user port so I'm still doing a proof of concept of the whole situation in the pico software.
Click to expand...
This is the peak solution and something I was mulling. Can you use the PIOs to do some of the heavy lifting?
 
Thanks @djg I appreciate the tips. I had fixing this in my backlog. Just haven't had the time yet.

@drdanj I will slap a license on it. Hadn't really thought anyone would find this interesting. I am currently working out the PIO behavior. That's been the hard part with the whole situation. I can upload the kicad files too if you'd be interested.
 
So, that works in one direction! Just have to make it work in the other.

1742558781818.png

Interesting quirks in these early DOS formats - it seems the Victor will let you enter a number of root directory entries which it then "makes up" to the nearest sector size. If you just copy that directly across to a DOS boot sector you may well find that your data isn't aligning - you have to pad out the number of directory entries to fully align with a sector (which is in the specification).

I suppose I ought to actually implement this in a sane way rather than just bodging outputting a pc style image file at the end of the python script...
 
Last edited:
This is good enough to use in anger, so it gets a v1.0 - you can probably still break things, but it shouldn't break your original files and it does at least check that what you're trying to insert is the same size as the space you're trying to insert it into! 😄

github.com

Release Version 1 · drdpj/V9000HDTools

Enough error checking that people shouldn't be able to do anything too silly. It won't adjust your original files! All usage instructions in readme.
github.com github.com
 
You must log in or register to reply here.
Back
Top