[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
DMF OS.
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).
The commands are: INITIALIZE, RESET, READ, WRITE and FORMAT
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?
Regards,
Dave
--
dave04a (at) Dave Dunfield
dunfield (dot) Firmware development services & tools: www.dunfield.com
com Vintage computing equipment collector.
http://www.parse.com/~ddunfield/museum/index.html
--
Delivered by the SEBHC Mailing List
More information about the Sebhc
mailing list