[sebhc] H17 ROM and disk info

Dave Dunfield dave04a at dunfield.com
Sun May 23 04:51:12 CDT 2004

Hi Walt,

>What is the goal of having "H-17" emulation in the emulator?  Is it to allow
>any application which may have been written to run under the emulator, even
>if it does some really weird stuff with the disk controller, or is it to be
>able to read disk images and have some form of disk I/O under the emulator?

I think the main goal is to provide a virtual environment as close to a real
H8 as possible, but not necessarily accomodating software that does "weird
stuff" - in other words, to be able to boot and use unmodified HDOS images.

>Heck, throw out the ROM image!  You don't need it!

Um - you need something to boot!

>What you do need is enough of a driver to read bytes and write bytes.

>Anyway, from my perspective I want to run HDOS 2.0 and have disk I/O
>available.  I don't want to do fancy tricks with the disk controller.
>I also don't currently care about HDOS 1.5 and 1.6.  I just want to
>read and write disk images.  This can be done the quickest with a small
>system device driver were the emulator can recognize a couple of addresses
>to trap on and perform a sector read/write, or even through a couple of
>unused I/O port address which are emulated.  Very simple.
>Remember, HDOS proper only cares about reading/writing disks sectors.  It
>doesn't care where they come from.  They can even come from the ether!

I have considered this - I've done both approaches in the past.

For my Altair emulator, I implemented the NorthStar single-density disk
controller right down to the register level - the system boots using the
original unmodified ROM from the NorthStar controller and runs using the
original unmodified disk drivers for both the NorthStar DOS and my own

I was able to do this for three reasons:
  1) The register interface is very well documented.
  2) I had already had a lot of experience with the interface (wrote my
     own OS for the machine.
  3) The interface is simpler than the H17 - it consists of a single 256
     byte data sector per hole - no header etc. In other words, all you
     need to understand to implement it is the hardware - there is no
     software component to the disk format that has to be emulated.

For the D6809 emulator, I decided that the 765 disk contrller was going to be
too much work to implement. In this case, all disk I/O was done in the ROM, so
updating the ROM with new drivers allowed me to transparently add a very simple
virtual disk controller. This device has 8 registers:

      0 = Command/Status
      1 = Data
      2 = Drive select
      3 = Current Cylinder
      4 = Current Head
      5 = Current Sector
      6 = # Heads    \_ For geometry -> file index calculations
      7 = # Sectors  /

If you don't need to support multiple disk geometries, then the last two are
not required. To read/write a sector, all you do is set the Sector/Head/Cylinder
values, then issue a READ or WRITE command - then do 512 reads or writes to the
data port (this was a DD system with 512 bytes/sector).


This interface also allows you to support up to 256*256*256 sectors, which makes
for a fairly large disk (8G for 512 byte sectors).

I could implement such a disk controller in the emulator in less than an hour -
and I could easily provide a boot ROM, however I would need someone with HDOS
experience (and probably a working HDOS system) to configure the system disk
to work with it.

I am also a bit concerned that the H17 ROM provides quite a few vectors which
are entry points for very low level/H17 specific functions (Move ARM in/out, wait
for Hole, wait for Sync etc.) - These function would make no sense on the virtual
disk contrller described above - Does HDOS use any of these functions?

dave04a (at)    Dave Dunfield
dunfield (dot)  Firmware development services & tools: www.dunfield.com
com             Vintage computing equipment collector.

Delivered by the SEBHC Mailing List

More information about the Sebhc mailing list