Maybe Dare was thinking about a Unix style "magic number" which can be used by the "file" command and other utilities to determine the file type.hmmm, interesting idea. You're thinking a value that would be unique to determine that a file is different from any other file that's not produced via a direct copy? Could be a hash of the current date, time, and user ID, something like that?
Exactly. Although I think a hash of the header data, including the magic number, could be good as well.Maybe Dare was thinking about a Unix style "magic number" which can be used by the "file" command and other utilities to determine the file type.
From previous postings the emulator doesn't directly work with SIMH images but has a program to convert so don't think this is an issue. Original SIMH format files won't be modified. I do something similar with my MFM disk emulator.Have you guys not followed the fiasco that happened with SIMH around adding/extending metadata within legacy disk images?
Rather than some kind of hash, why don't you use something like a CRC or an MD5. That way it can be used for both identification and validation.hmmm, interesting idea. You're thinking a value that would be unique to determine that a file is different from any other file that's not produced via a direct copy? Could be a hash of the current date, time, and user ID, something like that
Who assigns magic numbers and how big are they? Adding one would be trivial.Exactly. Although I think a hash of the header data, including the magic number, could be good as well.
I bring this up because at the moment I'm busy adding support for various virtual disk container formats to my retro-fuse project. This is happening as part of my effort to support mounting Xenix filesystems. But the work will make it easy to support different container types for any supported filesystem. With a magic number in the header, I should be able to autodetect one of these emulated RK05 files and automatically mount it (in the case where it contains a Unix filesystem).
I did follow the drama around SIMH adding meta-data to existing images. Here we talk about something different.Have you guys not followed the fiasco that happened with SIMH around adding/extending metadata within legacy disk images?
Upshot is fooling around with the disk data image, either prepending or appending arbitrary metadata within the file itself is highly frowned up.
Add a separate companion file that contains anything you want in whatever format you need (json, xml, raw bits) and maybe even the name of the companion data file.
But don't change the concept that the data file is just a pure data image of size N blocks from blocks 0 to N-1.
Just my 2c, but the arguments for/against this concept blew up the old SIMH project into the old and new forks.
And yes I realize also there were some personality issues involved.
Got it. You are making a tradeoff in the design of your controller to simplify it at the expense of preprocessing disk images for use with it.I did follow the drama around SIMH adding meta-data to existing images. Here we talk about something different.
There is no intention of touching the SIMH disk image format other than using SIMH image files as an input into a converter for the RK05 emulator's image container.
But you could compute the track/sector numbers from the position of the data block in the file, correct?The main reason for not using the SIMH disk format directly is that the RK05 emulator is storing the sector header, sector data and sector CRC in the image. This header and CRC are required by real disk controllers interfacing to the RK05 emulator.
LOL really? Then I hope you have at least parity or even better ECC and have used TMR techniques to protect all the internal memories and logic in your controller FPGA.Also the header and CRC provide a certain level of end-to-end data integrity assurance that is missing in the SIMH format. With modern SSD disk bit rot this is a good thing.
But if all the inputs are coming from SIMH disk images (most likely) there won't be any metadata except what gets created in your conversion operation.With the conversion utilities it is trivial to convert from one format to the other. Additionally the meta-data can nicely describe the RK05 emulator image.
Got it. You are making a tradeoff in the design of your controller to simplify it at the expense of preprocessing disk images for use with it.
But you could compute the track/sector numbers from the position of the data block in the file, correct?
And vice versa to go from a track/sector address to an offset into the data file?
And you must be able to generate a new sector CRC in your controller anyway if you are able to write new sectors.
LOL really? Then I hope you have at least parity or even better ECC and have used TMR techniques to protect all the internal memories and logic in your controller FPGA.
Those stray cosmic rays can be so problematic. SIMH seems to work just fine using the SIMH disk format. Don't know why your controller would be different.
But if all the inputs are coming from SIMH disk images (most likely) there won't be any metadata except what gets created in your conversion operation.
Unless you are proposing all the existing SIMH RK05 disk images switch to your container format? Color me skeptical.
You get to do that. All you need is a fixed, unique sequence of bytes, preferably placed at a known location in the file (right at the beginning is good). An 8 byte sequence is the minimum I would use in this case, since you're not really space constrained. But 4 would work.Who assigns magic numbers and how big are they? Adding one would be trivial.
$ dd bs=1 count=8 if=/dev/random 2>/dev/null | od -A none -t x1
5a 12 ce d1 d0 6c 86 56
0 string \x5a\x12\xce\xd1\xd0\x6c\x86\x56 Emulated RK05 disk data file
A magic number is rule #1 in creating a container format.I suggest including a magic number at the beginning of the file to make automatic identification easier.
Thanks for the link. There are a lot of good suggestions in the article.A magic number is rule #1 in creating a container format.
Too bad nothing in SIMH followed that rule.
Wow. I'd completely forgotten that Andy wrote that.A magic number is rule #1 in creating a container format.
Too bad nothing in SIMH followed that rule.
Rotational latency, yes. The interface signals pretty much require that. I suppose it might be possible to spin the virtual surface faster until the controller decides to read or write a particular sector, but I was too afraid to deviate from the normal operational characteristics. I wanted to emulate the real drive as much as possible. The emulator outputs index and sector pulses at the same rate and width as an RK05.Do any of these emulators emulate seek and rotational latency?
Maybe this project configured as a drive tester would be helpful to debug the drive. With different Pico software and FPGA code the device becomes a tester. I think the emulator by @PDP11GY can also become a tester.I have one RK05 drive and a controller set for my 8/e but I have not gotten around to working on that.