• Please review our updated Terms and Rules here

M24-IDE: a 16-bit IDE adapter for the Olivetti M24 / AT&T 6300

Valerio

Experienced Member
Joined
Aug 20, 2017
Messages
131
Location
New York, Rome, London
Hello again -

As I mentioned my newly-acquired AT&T 6300 is missing a hard drive. I have glitchworks's XT-IDE in my Italian Olivetti M24 and it works flawlessly, so I could just get another one. But I've always wondered if it would be possible to remove the latches and have the IDE device communicate with the M24 through a full 16bit-wide data path? After all that's what an 8086 distinguishes itself for!

So I have spent a bit of time looking at the bus converter schematics (*) and the sequence of signals on the proprietary Olivetti 16-bit bus connector, and I can see no obvious reason why it should not work.

Olivetti 16-bit data transfers seem to work very similarly to their ISA counterparts, ie an address is presented on the bus, and if the card asserts a specific line (/IOCS16 in ISA, /16BCH in Olivetti) then a 16-bit transfer takes place. There are differences - in the Olivetti case, during a 16-bit transfer cycle the ISA-compatible command lines (/IOR, /IOW, /MEMR, /MEMW) are disabled and alternative Olivetti lines on the 16-bit connector are used (/XIOR, /XIOW, etc).

With this knowledge, I sketched a possible, simple interface, essentially a simplification of glitch's design split into two boards: a main one that plugs into the ISA-compatible 8-bit slot, and a smaller one that plugs into the Olivetti 16-bit slot. The two would be connected via a short 12-pin ribbon cable.

I have not breadborded or tested this at all - my ISA breadboard card is old and cranky, and with this many connections user error or breadboard malfunction would be virtually guaranteed. Also, at $5 a pop for professionally-fabricated prototype PCBs I'm willing to just have a board made with a reasonable starting design and then just debug that. (**)

So my question is... does anyone see any glaring flaws with my schematic, or any obvious reason why the whole thing would not work?


(*) The bus converter schematics in the Theory of Operation manual does not exactly match mine - probably a different revision. I have a hand-corrected version if anyone is interested.

(**) I have also not finished routing it yet. It's a lot more complicated than I thought or, most likely, I'm not very good at it.

(***) Sorry for the zipped version - I know it's not smaller than the .pdf, but the forum won't allow me to upload .pdf's larger than 48kb...
 

Attachments

  • m24_ide.zip
    89.8 KB · Views: 4
  • olivetti_16bus.pdf
    24.5 KB · Views: 6
Interesting! What kind of performance could we expect on something like this?

I don't know for sure as I have not timed the 16-bit I/O cycle, but it should be faster than only currently available solution for these PCs (XT-IDE in Compatibility Mode), which uses two separate 8-bit cycles for each IDE 16-bit data access. It should also be faster than an XT-IDE in "Chuck Mod" version if that could be made to work on the M24, since a 16-bit cycle split into two fake 8-bit cycles by the bus converter is slower than a true single 16-bit cycle (I did check this).
 
Was there a 286(ed) version of these? I know they did a 386, or at least am reasonably sure.

This is along the lines of a project I had in mind for the Tandy 2000 a long time ago, that is amending and ide card to work with the 80186 based expansion bus. It uses a 96 pin eurocard connector. It's possible much of that which is needed is already there. The NEC APC III (or PC-9801) has C-Bus, and likewise you could at least expect 16 data lines to be present.
 
This is along the lines of a project I had in mind for the Tandy 2000 a long time ago, that is amending and ide card to work with the 80186 based expansion bus.

Not to hi-jack the thread, but I've looked at doing it for the T2K - and still plan to for Tandy Assembly'19. The T2K - and maybe other work-a-likes - do not have a standard PC BIOS. There is no support for a BIOS option ROM for XT-IDE BIOS. And even if there were, the system ROM in the T2K only has enough of Int 13A to boot-strap DOS from floppy or hard disk and then most of BIOS is replaced from code in IO.SYS - including Int 13A.

The T2K does use a WD1010/1100 combo on it's hard drive controller - which IDE was based on. And it appears that even though hardware designers added support for DMA and IRQ on sector transfer, the code still only uses PIO and busy-waits. So it may be possible to map an IDE drive's register set in the same spot and things 'just work' - in 8 bit mode. The T2K does use a 80186 - unlike the PC6300's 8086. So the designers heavily leveraged the built-in programmable chip-select lines to make peripheral card decoding easier.

I'm afraid in order to do a lot more with the T2K, most of the BIOS code needs to be ripped from IO.SYS, combined with the ROM, and updated to a proper PC clone compatible code-base - and placed back in ROM. There is only 16KB of ROM window, but it should be doable - skipping pedantic things like placing handlers at the same segment address as IBM! That's why I disassembled and annotated the T2K ROM and was about half way done with IO.SYS when a squirrel ran by. It would break loading the T2K specific DOS flavors but would allow running of more modern stock DOS versions. I plan on finishing and getting MS-DOS 6.22 booting on it as step 1 toward hard drive emulation.

-Alan
 
Was there a 286(ed) version of these? I know they did a 386, or at least am reasonably sure.

So I read, but I have not had one personally.

This is along the lines of a project I had in mind for the Tandy 2000 a long time ago, that is amending and ide card to work with the 80186 based expansion bus. It uses a 96 pin eurocard connector. It's possible much of that which is needed is already there. The NEC APC III (or PC-9801) has C-Bus, and likewise you could at least expect 16 data lines to be present.

Yes I have often wondered whether and to what extent these pre-IBM-AT 8086-based PCs had 16-bit expansion cards available for them back in the day. The only such 16-bit cards seen with any regularity on eBay are memory expansion boards for the M24... but maybe I missed others the existence of which I am not aware of.

In your design, did you make use of the IDE (or ISA) /IOCS16 signal? In my design I critically rely on it working as I expect to select between 8-bit and 16-bit IDE register accesses...
 
Just a quick update... I finally finished routing it (yep, a year later!). Here is a render of the main board:

m24ide.jpg

and one of the little board that goes into the 16bit slot:

16bus.jpg

I did not put any mounting holes to attach a bracket... mostly because I could not figure out where to place them (suggestions welcome).
 
Update

Update

A quick update - the PCBs have arrived and I have built a prototype, with XTIDE Universal Bios 2.0.0.beta3.

Here is a photo of the setup inside my Xerox 6060:

5D0A79F2-40D8-4554-94F6-279575C2E685.jpeg

Unfortunately it doesn’t quite work “out of the box” and now I am slowly driving myself insane while attempting to debug it.

To this end - can you suggest a small IDE diagnostic utility? Something that scans for connected drives and performs basic connectivity checks? It would need to:
- not rely on a BIOS but access the I/O ports directly
- run in DOS on a 8086
- ideally fit into a single 360k disk

Thanks!
 
Update

Update

Some progress, but no happy ending yet.

After several tests, I concluded I had to make some hardware modifications. One was minor - a 100pF capacitor to ground at the end of a particularly long TTL line. The second one was rather major, as it addressed a design flaw.

This host adaptor is really rather simple - just like its ISA AT siblings, it aims to mate the IDE interface to the host bus by providing little more than address decoding, exposing the IDE registers to the host.

Crucially, all the IDE registers are 8-bit wide except for the data register, which is 16-bit wide. The IDE specs state that if the 16-bit register address is presented to the device, the device will respond by asserting /IOCS16 to let the host know it’s willing and able to perform a 16-bit transfer. So far so good.

My mistake was to use this signal directly to drive the /16BCH line on the M24 host bus. This line is functionally equivalent to the /IOCS16 line on the ISA AT bus. If the host samples this line asserted early into a word I/O cycle, it will read or write all 16 bits at once; if not, it will split the word cycle into two 8-bit cycles.

The mistake was that I did not realise that the IDE device will assert this line whenever the data register address is presented to it, regardless of whether an I/O cycle is taking place or not. This could happen during a memory cycle or even I guess as a result of noise while the ISA address bus is not being driven. Anyway, I think it makes more sense to gate the IDE device /IOCS16 line and only use it to drive the host bus /16BCH if an I/O read or write is taking place. Luckily I did have enough spare logic gates on my prototype board to do just that so I hacked this with some flying wire connections.

In order to test all this I wrote some simple code that reads some data off the IDE device, and it works!!

92466EA4-93BF-464F-AA12-423B46883A0A.jpeg

Note that it reads both 8-bit registers (for Status etc) as well as the 16-bit data register (for model name, serial number, etc). This means the /IOCS16 decoding is working when I do IN AX, DX (ie word input).

Sadly, I cannot get it to work with the XT-IDE bios. I configured it as a plain 16-bit ISA card as I thought it would be functionally equivalent to one of those. Unfortunately, it crashes at startup as soon as it tries to access the IDE device. I am using the xt-only ROM image specifically to avoid using any 186+ instructions, but now I am wondering whether by selecting “16-bit ISA” it somehow branches to code that uses 286+ instructions... (where else would you find a 16-bit ISA card anyway?).

Any suggestions?
 
This is huge!

Thank you! Indeed to my knowledge there aren’t any expansion boards that do native 16-bit I/O transfers with the M24/6300 - this may well be the first one :D (I know there were memory expansion boards that presumably did native 16-bit memory transfers).


Thank you for bringing this thread to my attention - I didn’t know about it! I’ll read through it (maybe not all 57 pages).

Anyway I have some further updates...
 
More Updates

More Updates

Reading some recent posts I realised I wasn’t using the latest XTIDE BIOS - so I went here and I downloaded the r602 version for plain xt. With the enclosed utility I configured it for plain 16-bit ISA IDE adapters.

And now it does not crash anymore!!! At boot it recognises the IDE device:

8703468C-9A35-43CC-9DFC-6A0B43324227.jpeg

I did FDISK /MBR and then used FDISK to create a single DOS partition - which worked (after a couple of tries...). However formatting the drive fails after a few percent:

1508FF7B-19A7-4F4A-8496-099D94BB9C00.jpeg

So some progress - but still not quite there yet. At this point I suspect the XUB config is probably fine (I doubt I would have gotten this far if 186+ instructions were being used). What still is unclear is if 16-bit I/O writes work properly (that’s the only instruction my simple IDE info program does not test) and whether the whole board is stable (ie glitches, etc) and whether the timings work (my hack uses an awful lot of logic gates in series - maybe it works for reads but not for writes...).

Anyway, more testing needed. Some pictures of the current state of the board (the back is even worse):

D8F455A0-BC7B-4F86-BD96-D57267E54310.jpeg

51669B24-5A38-462A-A3A1-6169D12E97DF.jpeg
 
Thank you! Indeed to my knowledge there aren’t any expansion boards that do native 16-bit I/O transfers with the M24/6300 - this may well be the first one :D (I know there were memory expansion boards that presumably did native 16-bit memory transfers).

The EEMS board is a 16-bit board (which I'll be installing next week when I get the 41256 chips to populate it :)
 
Thank you! Indeed to my knowledge there aren’t any expansion boards that do native 16-bit I/O transfers with the M24/6300 - this may well be the first one :D (I know there were memory expansion boards that presumably did native 16-bit memory transfers).

Yes, there are memory boards for such M24 which do not have 640kB onboard. And there is the M24 grpahics card itself, and the optional DEP board.
 
Back
Top