OSI related questions

[EtchedPixels]

During some discussions on what the oldest micro computer platforms that could run Fuzix someone brought up the OSI machines as having banked memory, hard disk options and the like. I've been on a fascinating spelunk through the archive and I understand how most of it works now but I am stumped on a couple of things related to OS porting

- The bigger hard disk interfaces don't seem to be well described or have any useful disassembly. I can kind of guess most of it but not all. So looking for more info
- For all the hard disks I've not seen anything documenting what goes in the areas around the data for writes. I know contemporary controllers in the S100 space your transfers tended to include a bunch of header bytes and sometimes a checksum that was your problem, but also they expected you to put the right bytes (or often only some of the right bytes or at different offsets) in a write. Does anyone know what has to go in E000 before the data for writes on these machines ?

Also some emulator questions
- The emulated disk format doesn't appear to keep the parity. Is there any way to fix that as I was going to try and implement "proper" soft sectoring by using odd and even parity to separate data from headers so I don't have to wait for the index hole (akin to the way standard controllers using non standard FM encodings for those bytes)
- Is there any emulator source available as the other thing Fuzix supports already is attaching compact flash to just about anything with a pair of 8bit I/O ports one reversible - 82C55, PIO, 6522's etc. And for that matter does anyone run anything like that with a real machine ?

I'm very sure I can get it running on the C3 Z80. The 6502 mode is going to be very tight on memory though as the 6502 isn't quite so C compiler friendly and the fact banking appears to switch 0000-01FF is sure going to make it interesting in a few spots.

Alan

[Mark]

Basically all the HD information I have was gleaned from schematics, the operating system, and the support programs found on old media.

So as far as I know OSI supported 5 different hard drive types, but only with OS65U, the business operating system. OS65U was not popular for home machines due to it's memory and hardware needs as it only ran on 8" drives. HD support required a considerable hardware investment!

Multiuser OS65U support required OSI510 CPU board, but only the 6502. Z80 was needed for CPM of course.
OS65U RAM banks seem to have used 24K(?) to 48K and are controlled by a PIA on the OSI510 CPU which generated the extra address lines. Only the lower 48K was switched, the upper hardware from C000+ was constant. Each user got their own RAM bank & BASIC copy to use. 4K $D000 RAM was required for multiuser (& CPM) along with IRQ support on serial I/O. The OSI 510 also contained $80 bytes of RAM (6810) which could be mapped in to replace the $FF00/$FF80 ROM to redirect interrupt vectors.
OS65U also supported machine networking!! but I have never seen any of the networking support floppies that contain the missing code to enable this feature

I know OSI used at least two different hard drive interface ROMS which are 256 bytes long at $FD00. 65U uses a 3584 byte long sector with 2 additional checksum bytes and sometimes a header byte. Hard disk used additional headers (below).

OSI disk sizes (minus boot trk)
CD-74:Hard drive Size = 72,898,560 (339 cyln ) CylnSize = 215,040 (12 heads):TrkSize = 17920 (5 OSI sectors) (OSI 592)
CD-36:Hard drive Size = 36,449,280 (339 cyln ) CylnSize = 107,520 (6 heads):TrkSize = 17920 (5 OSI sectors) (OSI 592)
CD-28:Hard drive size = 29,360,128 (512 cyln ) CylnSize = 57,344 (8 heads):TrkSize = 7168 (2 OSI sectors) (OSI 594?)
CD-23:Hard drive Size = 23,166,976 (202 cyln ) CylnSize = 114,688 (8 heads):TrkSize = 14336 (4 OSI sectors) (OSI 594)
CD-7: Hard drive Size = 7,311,360 (255 cyln ) CylnSize = 28,672 (4 heads):TrkSize = 7168 (2 OSI sectors) (OSI 596 / 598)

They all seem to use an OSI590* interface with a specific hard drive interface board (592/594/596) and 4K dual-ported RAM (525).
*The OSI598 interfaces to SA1004 type hard drive (CD7 and possibly CD23) and replaces the 3 board configuration 590/525/596 (&SA1000).
(I am not sure of the specifics of CD-28, but if it really does use 594, then it probably works like CD-23/CD-7)

The two different ROM/controller sets CD-74/CD-36 and CD-7/CD-23 use slightly different headers on the hard drive and differing checksum routines on the hard disk cylinders. The CD-74 interface uses a more intelligent controller - set cylinder to seek & send go, the CD-7 interface is more floppy-like where the controller steps up or down to the desired cylinder. Once seek is done, a 16bit starting and ending address is sent to the controller and the data is transferred to or from the hard disk in a DMA like way.

The OSI disk controller is only visible in memory for a few ms after accessing address $c280, after which hdisk registers at C200-C207 are active.
Generally the registers are:
C200 = cylinder hi (bit 7) & head (bit0-6)
C201 = cylinder lo
C202 = controller status read / disk control step ; drive sel write (READ available w/o C280 access)
C203 = start addr lo
C204 = start addr hi
C205 = end addr lo
C206 = end addr hi
C207 = write to start disk ops & DMA, read for controller specific status
C280 - access to enable disk controller for a while (10ms?)

As far as I know the sector layout is this:
E010 = $A1 (flag?)
E011 = ($0)
E012 = ($0) expected Cylinder hi
E013 = expected Cylinder lo
E014 = expected Head#
E015 = expected Sector#
E016 = ?? flag ? $00 or $0F
E017 = checksum of track header (E010-E016)
E018 - EE17 = sector data
EE18, EE19 = checksum of sector data

Boot track is loaded from cylinder 0 head 0 sector 0 and executed at $E018. This loads additional data as needed to start the OS & drive specific code.
The disk sector transfer starting & ending address differs for each HD.
The CD7 boot ROM uses $0010, $0725 CD-74 uses $0072/$0862 for sector 0 read;

For CD-7
When reading data, sector data goes from E018-EE17 (EE18, EE19) are chksum E010-E017 trk hdr
When writing data, sector data goes from E1C2-EFE0 (EFE1, EFE2) are chksum E1B7-E1C1 trk hdr

For CD-74
When reading data Sector data goes from E018-EE17 (EE18, EE19) are chksum E010-E017 trk hdr
Write data uses the same offsets as read.

The checksum of CD-7 does not clear the carry when overflowing 8bits, so the checksum is increased by one on every overflow, such as this:

Code: Select all

	; ORIGINAL OSI HEADER CHECKSUM CODE CD-7 1.42  & CD-23
        ;Carry is only forwarded for bytes 1-5 in reverse order
	*=$36C3
		LDX #$06
		LDA #$00
		CLC 
	LOOP 
		ADC $E010,X
		DEX 
		BPL LOOP
		RTS 

The CD-74 does clear the carry after each overflow -- the "LOOP" comes before CLC
But this is an OS consideration - you don't care from a HD point of view.

I have working CD-7s but have not found anyone with CD-74/36 to at least verify disk reads work as expected, & the information I have isn't bogus.

My WinOSI emu diskette support was started with RAW ASCII dumps from OSI controller, before it was possible to read flux bits, and just never got updated. OSI used only 2 different disk formats (OS65D 8E1 & OS65U 8E1/8N1) so parity support wasn't critical for emu. If I was to do it, it'd probably be stored as an HFE file. Since the OSI uses 6850 for reading disk flux, switching in the middle of a disk without 11+ bits of gap may lead to loss of synchronization, although the data separator should sort out clock vs data bits OK. OS65U switches from 8E1 to 8N1 after disk track header & then checksums the sector. There is usually 1 byte of garbage between the two, and it only starts reading after the index hole.

Hard disk support was made possible once working HD support floppies were found & the code was run to determine what it wanted. The HD disk emu image format is just the storage of each sector as a 4K block of data, once again as full bytes as there was no way to read raw hard disk formatting. (WinOSI includes a working multi-user C3 HD configuration )

Memory swap for zero & stack page happens on OSI CPM for Z80 support as it originally swapped back to 6502 to do native disk/diskette I/O.
OS65D (home OS) does some swap for BASIC and 65D routines, not sure about OS65U & that BASIC version though. Certainly page swapping is not required if you run your own OS or software. The OSI hardware does not require low mem swapping...
Cheers!

-Mark

[EtchedPixels]

Thanks that helped a lot.

I have most stuff working with the later drives. The earlier stuff needs some more digging as there seems to be other stuff going on along with the seeks, precomp perhaps ?

Anyway I can boot the system, run multi-user and play adventure happily enough. Disk is a bit slow but some of that is because it's totally unoptimized at this point and some because the shared memory buffer means extra copies. It also needs a lot of banks as I've not yet implemented swapping to disk.

One thing I've not been able to figure out is interrupts in Z80 mode. The 510 schematic has them connected to the same wire as the 6502 but I don't seem to be getting ACIA or floppy disk timer ints at this point.

[Mark]

Amazing! What are you running it on?

WinOSI doesn't have emulated Z80 interrupts, but it wouldn't be hard to enable them. The code is there, it's just missing the virtual wire that connects Z80 to the interrupt source.

[EtchedPixels]

Just the emulator at the moment, which means there may be more to the hard disk to work on real hardware and all the usual caveats

Apart from floppy drivers (not tackled) and interrupt it seems to test out ok so far. I've put the disk swapping in and some optimizations so its a bit better. For the older disk controller I need to go read more monitor code and see if I can make more sense of driving it and what all the bits do.

I did try a 6502 build but the C compiler output is somewhat less dense so it won't actually fit without RAM at D000-EFFF and that means no disk controller so not a lot of point. Z80 fits nicely though.

I can put a 34Mb disk image and boot floppy up (not done HD boot yet) if you are curious.

[bxdanny]

EtchedPixels,

That sounds like quite an impressive project you're working on, and I'd love to see a copy when you think it's ready. But I think I should point out that the CD-23 option in WinOSI doesn't actually work, as far as I can tell, so please don't waste time trying to get your OS working with it. The CD-7 option does work nicely, as do the the CD-74 and -36.

Mark,

I am basing what I said above on trying to use the OS65U_V1.2 disk image on your site with an empty CD-23 disk image created by WinOSI. That diskette image does contain a CD-23 operating system, or at least it appears to [PEEK(13316)=1]. But trying to Initialize the HD with the version of COPIER on that disk produces only disk errors. I wonder how glitch and his friends are doing trying to read that real CD-23 they have.

[EtchedPixels]

Not had a chance to sort out the CH7 yet but I did stick bootable floppy/hd image on

www.fuzix.org:/tmp/ch3fuzix.zip

Matching sources are in the Fuzix github.

It's a bit chuggy at 1MHz but does seem to work. Time is not working as the emulation wasn't providing Z80 interrupts. That also means the serial is only responding when the machine is idle. Because of that anything timed will hang and there is a small chance stuff will hang anyway.

At the boot prompt hit 1 for the first hard disk partition, at the login prompt "root" no password (if you get it wrong it'll say so and then get stuck because of the lack of timers). The shell is the classic Unix Bourne shell. To shut down cleanly "shutdown"

There may be a few other glitches. The Hazeltine terminal doesn't like the tab char and whilst there should not have been there were a few embedded tabs in some of the tools I found as a result of the port and there maybe more.

Most stuff should work though. The mini vi editor is known broken at the moment on all targets. That needs some unrelated reworking and debug

[Mark]

Yes, CD-23 interface isn't working yet. It has different signaling conditions than the CD-7. I've run the "newly" discovered CD-23 specific software on the 6502 emulation side, but I haven't figured out what exactly it is expecting in a response from the disk controller. The CD-23 that Glitch has seems to respond correctly to the commands sent from an OSI dump utility made for the CD-23, but until recently it didn't have the correct addresses for the sector offsets (which are contained in the CD-23 software) , so the sector data transferred was incomplete. That disk came from someone who only had a CD-7 system, so not sure how they got CD-23 code. I was wondering if OSI had CD-23 specific boot ROM code. So far it looks like one for CD-7/CD-23 & maybe CD-28 and one for CD-36/CD-74...

Regarding WinOSI and the Z80, I have added the IRQ handling to Z80 emulation after learning a bit more about Z80 interrupts. So as far as I can tell, the OSI just used Interrupt Mode 1 with Z80? Nothing placed on the bus to set a vector, so it defaults to the code at 38h. I'm a total newbie with Z80 though, so please correct me if I am wrong.

I also realized that the WinOSI disk PIA always has IRQ connected even though that is optional on the OSI, so some additional U/I was added to support disconnection. I hope to get an update ready soon!

[EtchedPixels]

I did look at some of the circuit diagrams but I am not sure what the bus reads when inactive

If you shove a Z80 onto a bus with no specific support glue the usual results depend upon the bus state. So if it has pullups you get

IM0: executes instruction FF (RST 38). In all sampling the bus and executing RST38 takes 13 T states
IM1: executes RST38 always. The timing is the same the CPU just assumes 0xFF rather than sampling the bus
IM2: fetches the address at I * 256 + 255 and I * 256 + 256 and jumps to the 16bit little endian address given at those locations.

Timing for IM2 is 19 T states before executing the next new instruction. The CPU manual states that the least significant bit of the vector read must be 0. This is wrong. Various zilog devices always set it to 0 but the CPU will fetch as described above when it gets FF

I will have a play once you have a release and fill in and sort the timer related stuff. Thanks for working on it