HxC for Ohio Scientific disk interface

HxC Floppy emulator support for all others computers...
Post Reply
dfnr2
Posts: 6
Joined: Wed May 29, 2013 7:22 am

HxC for Ohio Scientific disk interface

Post by dfnr2 »

Hello,

I'm interested in getting an HxC2001 working with the Ohio Scientific disk controller, as the old disk drives for these machines (from the 70's and early 80's) are hard to find in working condition.

The interface is different from most of the era, using a parallel port to control track stepping and direction, track zero detection, etc., and a serial port to generate the single density data stream of 1 start bit bit, 8 bits data, even parity, one stop bit, at a 125 kHz data rate. two pulses for a 1 and 1 pulse (clock only) for a zero. Some external circuitry turns the raw data stream into an FM data stream: (two pulses--clock and data--for a 1, and a single pulse-clock only--for a 0.


Each track has a track header, which is written and read approximately 1 ms after the index pulse, consisting of a 2-byte track start code, followed by the track number in BCD, followed by a stop byte code. The track header is followed by a software-defined gap.

Each sector is indicated by a sector start code, followed by a sector number byte, followed by the sector length, followed by the sector data (the length in pages multiplied by 256 bytes), followed by a sector end sequence. There is a software-defined gap between each sector.

As you can imagine, this scheme does not lend itself to reading or writing using a standard interface chip.

I haven't been able to find the source code for the firmware, and so I'm not sure how much the HxC2001 relies on special formatting, versus simply decoding the FM or MFM transition stream and storing the result on simulated tracks.

My question is, how much does the HxC2001 depend on the data format? Would it be possible to use the HxC2001 with this interface?

Thanks!

Dave

Jeff
Site Admin
Posts: 8092
Joined: Fri Oct 20, 2006 12:12 am
Location: Paris
Contact:

Re: HxC for Ohio Scientific disk interface

Post by Jeff »

dfnr2 wrote: My question is, how much does the HxC2001 depend on the data format? Would it be possible to use the HxC2001 with this interface?
Read : No problem at all because all tracks are preencoded into the HFE file at the pulses level. So you just need to generate the HFE with the right format.

https://hxc2001.com/download/floppy_driv ... format.pdf

Format : Should work too : the incoming bits stream is directly copied to the tracks

Write sector : Here is maybe the problem : The HxC is looking for some sync words in order to put the sector datas exactly where it must be. i need to know the sync values.
Do you know the exact track format ? is there a documentation ?

dfnr2
Posts: 6
Joined: Wed May 29, 2013 7:22 am

Re: HxC for Ohio Scientific disk interface

Post by dfnr2 »

Hi Jeff,

That's great news about the bitstream read and write. The format is very simple, and is documented in a pair of articles here:

OS65D Disk Routines Part 1
OS65D Disk Routines Part 2

Also, here is the relevant source code for reading and writing to floppy, extracted from the OS:

Disk Driver Routines Source

I don't know if it will be an issue, but the HxC2001 code that looks for the sector headers would have to take into account the asynchronous data format of 1 start bit, 8 data bits, even parity, and one stop bit.

So, from what you are saying, I understand that the firmware records raw data streams for each sector, but builds up a data structure storing the track header and each sector as a separate blocks? If so, does the structure also include the timing information to reproduce the time gaps between the track header, sectors, etc?

If it is possible for the HxC2001 to support this format, I will be happy to do anything I can to facilitate it. OSI users everywhere would be very grateful!

Best regards,

Dave

Jeff
Site Admin
Posts: 8092
Joined: Fri Oct 20, 2006 12:12 am
Location: Paris
Contact:

Re: HxC for Ohio Scientific disk interface

Post by Jeff »

I think that the best think to do is to send me a disk: i have the hardware to read it here.
dfnr2 wrote: So, from what you are saying, I understand that the firmware records raw data streams for each sector, but builds up a data structure storing the track header and each sector as a separate blocks? If so, does the structure also include the timing information to reproduce the time gaps between the track header, sectors, etc?
No No ! the entire track is on the sdcard. No particular structure used... :wink:

dfnr2
Posts: 6
Joined: Wed May 29, 2013 7:22 am

Re: HxC for Ohio Scientific disk interface

Post by dfnr2 »

Jeff wrote:I think that the best think to do is to send me a disk: i have the hardware to read it here.
No No ! the entire track is on the sdcard. No particular structure used... :wink:
Excellent--that sounds very promising then. I tried emailing the contact address on the site, but I'm not certain if that goes to you, or elsewhere. If you can email me through this site, I will be happy to send you some sample disks, although I'm not able to test them at the moment due to no working drives :-( Also, I have raw-data dumps of some disks I can post here, or email you, if that would be helpful. They are essentially raw bytes from the disk (after data separation and decoding by the serial chip, stripping off the start, stop, and parity bits), starting at track 0, and continuing through track 39.

Just for my own education, would you mind explaining how the sector write works in the firmware? Does it use the actual timing of the bitstream to determine track position? What is the role of the sector information? Does the firmware use any other special information? I'm also interested in what is generally required to support different formats, or how the firmware sees one format vs another. If possible, I'd also love to have a look at the firmware source. Is that available?

At least for the most popular operating system, I believe that tracks were buffered, and written out one entire track at a time. However, I don't believe that to be necessarily the case for every disk-related software written for these machines.

Many thanks,

Dave

dfnr2
Posts: 6
Joined: Wed May 29, 2013 7:22 am

Re: HxC for Ohio Scientific disk interface

Post by dfnr2 »

I am looking for a disk solution for Ohio Scientific systems, which used 5.25" and 8" floppy disks. The interface used a UART to write the data to disk, with an extra FM encoding/decoding to handle clock and data pulses. I do have some raw disk dumps available, as well as some working computers. What is the recommended method of bootstrapping the HxC emulator support for a new machine? I would be grateful for any pointers on exactly what to do next.

Thanks in advance,

Dave

Jeff
Site Admin
Posts: 8092
Joined: Fri Oct 20, 2006 12:12 am
Location: Paris
Contact:

Re: HxC for Ohio Scientific disk interface

Post by Jeff »

dfnr2 wrote:I am looking for a disk solution for Ohio Scientific systems, which used 5.25" and 8" floppy disks. The interface used a UART to write the data to disk, with an extra FM encoding/decoding to handle clock and data pulses. I do have some raw disk dumps available, as well as some working computers. What is the recommended method of bootstrapping the HxC emulator support for a new machine? I would be grateful for any pointers on exactly what to do next.

Thanks in advance,

Dave
Do you know the bitrate used (Clock + Data ) ?

dfnr2
Posts: 6
Joined: Wed May 29, 2013 7:22 am

Re: HxC for Ohio Scientific disk interface

Post by dfnr2 »

I apologize for the delay in answering.

There are two different bit rates. For 5.25" disks, the data rate is 125 kHz. An FM circuit produces a clock pulse, and a data pulse (if 1) for every bit. The data is written with a UART (start bit, 8 data bits, even parity, 1 stop bit). For 8" disks, it's 250 kHz.

Track format (except track 0, see below) is:
- (INDEX DETECTED)
- 1ms delay after index
- 0x43, 0x57 /* track header start */
- Track number /* one byte */
- 0x58 /* track header stop */
- nominal 6.6 us delay after header / * may vary with system speed */
Sector format:
- 0x76 /* sector header start */
- sector number /* one byte */
- pages in sector */ one byte */
- sector data /* #pages x 256 bytes */
- 0x47,0x53 /* sector end */

Delay between sectors, nominally 800 us for each page in previous sector. In practice, this varies.

Track 0 is usually reserved for boot code, and has a different format, due to the simplicity of the bootloader in ROM. There is no sector. The header is just the load address and number of pages to load, followed by the data:

- INDEX PULSE
- 1 ms delay
- high byte of load address
- low byte of load address
- # pages /* one byte */
- data

dfnr2
Posts: 6
Joined: Wed May 29, 2013 7:22 am

Re: HxC for Ohio Scientific disk interface

Post by dfnr2 »

So, to clarify, this is a simple FM format.

The bitrate is 125 kbps for 5.25" drives (pulse rate up to 250 kHz including clock and data pulses)

The bitrate is 250 kbps for 8" drives (pulse rate upt to 500 kHz including clock and data pulses.)


I do have a couple more questions:

- If the HxC is looking for sector id codes (see above), how can I tell it about the format (standard UART protocol, 8E1), as it's different from the standard controller chips. Aside from that, I imagine that raw bit sampling should not care about the dat format.

- The OSI DOS counts on certain delays between sectors. How does the HxC deal with these? If the whole track is encoded as raw flux transitions, then I imagine there is no problem. If sectors are identified and stored as sectors, and the tracks are reconstructed, then I imagine there may be a need to specify timing to the controller.

I apologize if those are obvious questions; I'm not familiar with the low-level details of HxC, and I can imagine there are many ways to approach disk emulation.

Thanks,

Dave

namachari
Posts: 59
Joined: Tue Aug 23, 2016 11:33 am

Re: HxC for Ohio Scientific disk interface

Post by namachari »

Hello,
I was just wondering if any progress has been made on the OSI disk format for the HxC?

Thanks

exidyboy
Posts: 22
Joined: Thu Aug 01, 2019 4:55 pm

Re: HxC for Ohio Scientific disk interface

Post by exidyboy »

I have started thread on the OSI forum to discuss archiving OSI disks with a Kryoflux, it includes a link to preservation streams from an OSI disk and a screen grab from the disk visualiser in HxC.

Hoping to get some momentum going and any insights on whether the streams contain valid SSSD FM data.

https://osiweb.org/osiforum/viewtopic.php?f=3&t=717

Jeff
Site Admin
Posts: 8092
Joined: Fri Oct 20, 2006 12:12 am
Location: Paris
Contact:

Re: HxC for Ohio Scientific disk interface

Post by Jeff »

Have a look into the "new" stream view in the latest beta version. (with the KF stream files)

exidyboy
Posts: 22
Joined: Thu Aug 01, 2019 4:55 pm

Re: HxC for Ohio Scientific disk interface

Post by exidyboy »

The OSI community have some custom tools to work with the OSI format and they are showing data on at least one of the disks I imagined with the Kryoflux. Track 21 of the disk rabble7 is being flagged though. Here are grabs from the new visualiser of track 21 and the adjacent tracks 20 and 22.
It looks to me like 21 just has not been written?

Image

P.S. How are you representing the 5 revolutions in the preservation stream?

geowar
Posts: 1
Joined: Mon Nov 13, 2023 5:11 pm

Re: HxC for Ohio Scientific disk interface

Post by geowar »

What’s the status of this? I’d love to use HxC on my OSI C4PMF system. ;-)

Post Reply