O M T I - S O F T W A R E #=#=#=#=#=#=#=#=#=#=#=#=# 1.0. Hardware ------------- This archive contains the sources and executeables to a harddisk-device, and some support programs, who work together with the so called 'omti-harddisk' interface, which interfaces an PC Omti 5520 / 5527 controller to the Amiga. This hardware was published by the german computer magazine c't. I haven't designed a PCB by myself. The c't board must be modified with one more chip: Omti-Controller Amiga Bus DREQ ----|)*---+ INTREQ ----|)*---+----- INT2 2/6 74LS05 No, sorry, I don't know the exact pin numbers anymore. I made this modification to my computer about three years ago and haven't kept the documentation. Best thing is to solder the 74LS05 on the back of one of the other chips of the c't harddisk interface. The c't harddisk interface is *A HACK*! Its controller has no autoconfig capability and is fixed at 0xee0000. 1.1. The software This software was written with an Omti 5527 controller. It was never tested with an Omti 5520 and MFM drives. I'm in doubt, whether it will work without modifications. I'm using this software together with two Seagate Drives, a ST238R and a ST296R drive on an A500. The board of the A500 is built together with the two disks, a 2 Meg Memory expansion, a serial board and two 3"5 Drives in a big case. If you're on the UseNet, you may have heard of 'castle.franken.de' This is this machine... :) This archive contains sources and executeables to the following programs: - Boot-Startup-Code for AmigaOS 1.3 and 2.04 - Custom-Bootblocks for AmigaOS 1.3 and 2.04 - example Bootcode - A Drive-LED Simulator in two versions (only one working :) - A Low-Level Formatter - An information-program - An Disk-installer - A program to read and to write the boot tracks - sources for the device You'll need a directory 'DEVS:OMTI' where various files are stored. 2.0. Outline ------------ It always annoyed me, that, while using harddisks, I had to boot from floppy disk in order to get the omti.device etc. loaded into memory. I tried to build a piece of hardware, which contained EPROMs with the boot code, but this failed miserably. So I started moving another way: The AmigaOS *MUST* access the floppy drive in any case. It must check, whether there is a disk in the drive(s) and boot from them, if they're bootable. Why not write a custom bootblock and use a custom disk layout, which can boot from the harddisk with just reading the disk-bootblocks. So the following concept was created: - Loading the bootblock from floppy disk. It contains a bootstrap-loader, which is made resident under AmigaOS 1.3 (see below). This one loads the boot-tracks (normally tracks 1 - 3 on Cyl 0) from the harddisk). This code is checked for a 'BOOT' label, and if this exists, it is executed. - Under AmigaOS 1.3, this code mounts the following devices: - CON - RAW - NEWCON - PAR - PRT - RAM - DFx - one harddisk assigns the following Volumes: - SYS - LIBS - DEVS - FONTS - C - L - S loads the Devs:System-Configuration installs the FastFileSystem loads and installs the omti.device opens the first CLI Window with NEWCON: - Under AmigaOS 2.0, this code is more sparse (it needn't to do so much patches as under AmigaOS 1.3, because many of these things are already done by the OS. - it just loads and installs the omti.device - mounts up to four partitions on each of the two possible drives I also wanted to set up some kind of parameter block, who keeps all information about the drive. This became Block 0 on Track 0 on Cyl 0 of the harddisk. In general, you can say, that the Cyl 0 of a harddisk is reserved for system useage. 3.0 Bootblocks -------------- The code for the bootblocks is found in src/bootblock/1.3 and src/bootblock/2.0 3.1. Code for AmigaOS 1.3 ------------------------- This code makes itself resident and reset-able, if you use the 'setpatch R' option, which is also used for the RAD: ramdisk. It prevents itself from being overwritten by the flaky reset routine in AmigaOS 1.3 If you use this code, you'll need exactly *ONE* disk access *EVER*. All further attempts to boot from harddisk are made from this resident bootblock code. You can override this by either inserting a bootable disk in drive DF0 or pressing the left mousebutton while the reset sequence. 3.2 Code for AmigaOS 2.0 ------------------------ This code does *NOT* make itself resident. Reason for this was, that I wanted to insert the reboot code properly into the AmigaOS 2.0 reset sequence, i.a. after the initalisation but before the boot menu (the boot menu should show all drives already mounted) but I never managed to get it to work. Then again I lost interest in writing the resident routines and dropped them alltogether. So this bootblock must be read for every reset or you'll see the disk animation. Nevertheless, this bootblock sets the 'Silent Startup' Bit in expansion.library, so you'll boot without a window up to the first console write. 4.0. StartUp-Code ----------------- *WARNING* YOU MUST CUSTOMIZE THIS CODE FOR YOUR OWN GOOD & HARDDISK! 4.1. StartUp-Code for AmigaOS 1.3 --------------------------------- This code is rather crude and not documented. It relies heavily on the not documeted features of AmigaOS 1.3 and dos.library. However, it was not written by me and I'm not willing to support it. Use AmigaOS 2.0. If you really want to bother someone with this code, ask the author, Michael Schröder (mlschroe@immd4.informatik.uni-erlangen.de). If he's in good mood, he may help. 4.2. StartUp-Code for AmigaOS 2.0 --------------------------------- This code first sets up the device (it contains some kind of small relocator) and binds it into the device-list. Then it mounts all of your harddisk-partitions. So you don't need any mountlist. Every harddisk has an entry like this in the boot-code: part0 dc.b 'DH1',0,0,0,0,0 dc.l 20 ; Boot-Priority dc.l 0 ; Name of the Drive dc.l 0 ; Name of the Device dc.l 0 ; Unit for omti.device (Unit 0) dc.l 0 ; Flags für OpenDevice ;STRUCTURE DosEnvec dc.l 16 ; ULONG de_TableSize ; Size of Environment vector dc.l 128 ; ULONG de_SizeBlock ; in longwords: standard value is 128 dc.l 0 ; ULONG de_SecOrg ; not used; must be 0 dc.l 4 ; ULONG de_Surfaces ; # of heads (surfaces). drive specific dc.l 1 ; ULONG de_SectorPerBlock ; not used; must be 1 dc.l 26 ; ULONG de_BlocksPerTrack ; blocks per track. drive specific dc.l 2 ; ULONG de_Reserved ; DOS reserved blocks at start of partition. dc.l 0 ; ULONG de_PreAlloc ; DOS reserved blocks at end of partition dc.l 0 ; ULONG de_Interleave ; usually 0 dc.l 1 ; ULONG de_LowCyl ; starting cylinder. typically 0 dc.l 300 ; ULONG de_HighCyl ; max cylinder. drive specific dc.l 30 ; ULONG de_NumBuffers ; Initial # DOS of buffers. dc.l 1 ; ULONG de_BufMemType ; type of mem to allocate for buffers dc.l 256 ; ULONG de_MaxTransfer ; Max number of bytes to transfer at a time dc.l $fffffffe ; ULONG de_Mask ; Address Mask to block out certain memory dc.l 0 ; LONG de_BootPri ; Boot priority for autoboot dc.l $444f5301 ; ULONG de_DosType ; ASCII (HEX) string showing filesystem type; This is mainly the information, that you'll find in a mountlist entry. You'll find a little more information in the dos/ includes. Please don't forget, that Cyl 0 is reserved for the system! Bootpriority is not yet used. (I doubt if it ever will be) 4.3. How to put startup code on the disk? ----------------------------------------- This is the most interesting issue for you. You'll need a good monitor for this. I recommend FMon, written by Michael Schröder, which you can find in the UseNet Archives (comp.binaries.amiga). 4.3.1. For AmigaOS 1.3 ---------------------- Don't do it yourself. You'll need more help that I can give you. Ask Michael. Use the supplied boottracks for AmigaOS 1.3 as you starting point. These contain all four boottracks from 0 - 3. Track layout for AmigaOS 1.3: 0000 - 00FF Parameter-Block / Track 0 3400 - 34FF Basic boot code / Tracks 1 - 3 3500 - 3CFF omti.device 3D00 - 6CFF Fast File System 6D00 - 8AFF NewCon-Handler 8B00 - A6FF Shell-Seg A700 - AFFF StartUp-Code B000 - CFFF free FFS, NewCon and ShellSeg have been *HEAVILY* modified to work with this layout. Don't worry if you can't get your system alife with AmigaOS 1.3. Don't use it. Use AmigaOS 2.0. 4.3.2. For AmigaOS 2.0 ---------------------- At first, allocate a memory block of $6800 bytes. This will be your bootracks. Then, load the omti-device absolute to the offset $2004. *DO NOT RELOCATE!* The device must be for address $0. The bootcode will relocate it. The hexdump should look like this: [...] 1FF0: 00000000 00000000 00000000 00000000 ................ 2000: 00000000 70014E75 4AFC0000 00040000 ....p.NuJü...... 2010: 077A8004 03000000 006E0000 007A0000 .z.......n...z.. [...] Load the bootcode to offset 0. It may be relocated, because it contains no absolute addresses. The hexdump should look like this: 0000: 424F4F54 43E81FFC 22095881 D3FC0000 BOOTCč.ü".X.Óü.. 0010: 00082C79 00000004 20290002 D0812340 ..,y.... )..Š.#@ 0020: 00022029 0006D081 23400006 2029000E .. )..Š.#@.. ).. [...] Important is the 'BOOT' in the first four bytes. Then safe this memory block to a file. It must be exactly 26624 Bytes long. Then use the supplied 'OmtiWrite' to put the boottrack on the disk. Do this *AFTER* lowlevel format. Format will supply the Parameter block. If you set the disk mount entries (see above) correct, you should be able to boot from harddisk and get your partitions mounted correctly. 5.0. The device --------------- Look at the code. I can't say much more. It will not work with disks without PARA block. So format new disks immediately. The device supports two drives, in fact I'm using it with two drives for about three years under both, AmigaOS 1.3 and 2.0. 6.0. Support programs --------------------- 6.1. OmtiFormat --------------- This is the lowlevel formatter for the harddisks. It's quite self explanatory. You can read Err-Lists from DEVS:omti/ and store them there. So it's a good idea to have a disk handy, from which you boot before formatting. An Error-List looks like this: ERRLIST <- Yes, it's really an ERRLIST 37 <- Number of bad tracks 4,75 <- head, track 4,76 [..] 5,19 5,171 5,172 [..] 5,418 5,441 You can make this list with a text editor and store them into DEVS:omti/ as 'Errorlist.0' and 'Errorlist.1' for unit 0 and 1. You'll find the errorlist for your drive on a label glued to the drive. (At least with Seagate drives) You must click on the necessary gadgets to activate certain functions. E.g. at least unit and steprate must be clicked to be able to use 'Get Parameter from Harddisk' The user interface is crude and not written to the C= style guide. I apologize for it. But then again, it's about three and a half years old. You can't click Nof WrCyl. These are calculated by subtracting the tracks needed for error correction tracks. The formatter can also read and write the PARA blocks on the harddisk. So you needn't reformat to change e.g. the Autopark Flag. Parameter blocks are stored as 'ParaBlock.0' and 'ParaBlock.1' in DEVS:Omti/ *WARNING* If you low-level format your drive, you SHOULD DEFINITELY be aware what you're doing. Drives which you low-level formatted are *EMPTY* and no force in the world (except a backup) can give you your data back.* You've been warned! All other tools are less harmful to your data :) 6.2. OmtiInstall ---------------- This rather simple tool installs the custom bootblocks to boot from unit 0 or unit 1 on a floppy disk. It tries to read DEVS:Omti/OmtiBoot.0 or DEVS:Omti/OmtiBoot.1, which should contain the bootblocks together with checksum and all. You must create these bootblock files from the executeables with the help of a monitor, which can also correct the bootblock checksum. Did I mention FMon yet? Yes? ;) 6.3. OmtiInfo ------------- This tool reads the PARA block of a harddisk and displays some statistics. This is how my drives show up: Parameter fuer Drive 0: ---------------------- Device-Parameter: Hoechster Zylinder: 614 Hoechster schreib-/lesbarer Zylinder: 614 Write-Precompensation Zylinder: 256 Park-Zylinder: 670 Koepfe: 4 Steprate im uSec: 10 Init-Parameter: AutoPark aktiv: NEIN Write-Protect: NEIN Boot-Parameter: Boot-LUN: 0 Startkopf fuer Bootspur: 1 Startsektor fuer Bootspur: 0 Startspur fuer Bootspur: 0 Anzahl der geladenen Bloecke: 78 Format-Parameter: Verwendeter Interleave: 2 Sektoren pro Spur: 26 Sonstiges: Bruttokapazitaet des Drive: 31.23 MByte = 31980 KByte = 32747520 Byte Nettokapazitaet des Drive: 31.18 MByte = 31928 KByte = 32694272 Byte Parameter fuer Drive 1: ---------------------- Device-Parameter: Hoechster Zylinder: 819 Hoechster schreib-/lesbarer Zylinder: 812 Park-Zylinder: 0 Koepfe: 6 Steprate im uSec: 10 Init-Parameter: AutoPark aktiv: NEIN Write-Protect: NEIN Boot-Parameter: Boot-LUN: 1 Startkopf fuer Bootspur: 1 Startsektor fuer Bootspur: 0 Startspur fuer Bootspur: 0 Anzahl der geladenen Bloecke: 26 Format-Parameter: Verwendeter Interleave: 2 Sektoren pro Spur: 26 Sonstiges: Bruttokapazitaet des Drive: 62.46 MByte = 63960 KByte = 65495040 Byte Nettokapazitaet des Drive: 61.85 MByte = 63336 KByte = 64856064 Byte (Yeah, they're old, they're slow, they're hot and they were EXPENSIVE. But they're still running fine. Why should I change? ;) 6.4. OmtiRead and OmtiWrite --------------------------- These tools are used to read and write 2.04 compatible boot tracks from the harddisk and to the harddisk. They both work on track 1 and 2 of the harddisk (1.3 boottracks are on 1-3). OmtiWrite may damage your boottrack, but can do no harm to your data. 6.5. OmtiDisplay_Timer and OmtiDisplay_Vector --------------------------------------------- These tools have the same purpose. Their only difference: OmtiDisplay_Timer works and OmtiDisplay_Vector crashes. :) They both simulate the LEDs of the drives in a small window up in the right corner of the screen. This is useful if you don't have the drive led on your front panel of if your computer is faaaaar away from the monitor. If I think about it, there may be only a 'geta4()' missing in .._Vector', but I'm much too lazy to look at the code again. As I told you, this whole thing is a hack from the beginning and I do not really want to support it any longer. But you and you and you asked me about a release. So there. .._Timer uses the timer-device to poll all 1/10 of a sec. the state of the drive motors and draw the led symbol. .._Vector should use the callback hook in the device. If you get .._Vector to work, tell me. I'll be happy, too. 7.0. And that's a wrap! ----------------------- At least I think. If you still have followed me up to here (and understood everything :), I wish you good luck with installing this software. You'll be rewarded with blinding performance (This thingie is *MUCH* faster than the original c't device and about 10 % faster that the ALF device). If you got it to work on your system, tell me. I'll be happy to hear. You still have questions? Well, ask me. And may the source be with you (that's why I included it. :) Erlangen, in the Fall of 1992 Henning