eesrajm@cc.brunel.ac.uk (Andrew J Michael) (03/01/90)
My comments on my 68020 MINIX system raised quite a lot of email requesting more details, so here goes. You might also want to treat this as a small compendium of ideas on porting MINIX to non-Atari 680X0 systems. It's pretty long, so hit the 'n' key if you are not interested ..... 1. HARDWARE Firstly, some more details on my 68020 box. It's a home brew wire-wrap on an extended double eurocard. The processor is a 12.5MHz 68020 with a 12MHz crystal (the 12.5MHz ones cost more and weren't ex-stock !). There is no provision for a 68881, but these days I would include one, because gcc supports it if one is present. The memory is 768k of static ram, 62256-120 in fact. With hindsight I should have allowed for more, but the board was not originally designed to run MINIX, and 768k seemed adequate for SK*DOS or OS9/68k. The ram is configured for 32-bit wide operation, and runs without wait states at 12MHz. There is a single eprom with DSACKX configured for 8-bit accesses. A simple counter arrangement maps out the ram on reset and maps in the eprom instead. The board has two serial ports (a 68681) and uses one of them as the console with a VT100 emulating terminal attached at 9600 baud. The floppy disk controller is a 1772, with the extra control lines (drive select, etc) driven from the I/O pins on the 68681. Note that although the MINIX-ST sources say that the ST 1772 is modified for step rates, it isn't. Unfortunately Western Digital's chips got out of sync with their data sheets for quite a while and confused people ... The hard disk interface is SCSI, driven by a pair of parallel ports on a 68230 PI/T. People seem to think that SCSI is difficult, but it is really quite simple. You just use one 8-bit port for data and one for the control signals. Remember to use a decent driver chip like an LS642-1 and the correct terminating resistors. You don't need any form of DMA device - see later for details .... 2. SOFTWARE I started with a copy of MINIX-ST running on a Mega-2. With the advent of gcc for MINIX-ST, you could probably do the port with a Sun or similar as the host; I just didn't happen to have a Sun at home .... Apart from obvious things like writing device drivers for your chosen peripheral chips, other files like stmpx.s need some attention. For a start, you should note that MINIX-ST encodes the vector number in the upper byte of the vector handler address in order to establish which vector the handler was called from. Look at the line which says something like "get number from saved PC". What may not be entirely obvious is that this scheme is hardware dependant. On a 68000, the upper 8 bits of the 32-bit address bus don't go anywhere, so you can put anything you like on them without affecting the address which the processor will jump to. On a 68020, all 32 bits are presented to the outside world, and your hardware may or may not decode them. If you are building your own, ignore the upper 8 bits of the address bus and you can use the ST scheme as is. If you have 68020 hardware which uses the upper 8 bits, just remember that you CANNOT place the vector number in the upper 8 bits, or the machine will jump to the wrong address ! You will also need to look at the stack frames in stmpx.s and adjust them for a 68020. Remember that the 68020 pushes a format word onto the stack, and two lines of code in stmpx.s need to be adjusted for this. In particular, failure to clear the format word while setting up the dummy stack frame will result in very unpredictable behaviour. I didn't alter the kernel code defining the stack frame, because it doesn't really need to know about the format word and I saw no point in making it different to the ST. In my port, stmpx.s also contains two extra assembler routines for dummy DMA. The ST sources assume the existance of a DMA device, and I didn't want to alter the code any more than necessary. The floppy and wini drivers talk to what they think is a DMA controller but is actually some spare ram locations in low memory. For example, the 1772 floppy controller has its IRQ line connected to level 1 interrupts and its DRQ line connected to level 7. In stmpx.s, the level 7 interrupt handler does not pass the interrupt to MINIX, but to the assembler routine which just transfers the data byte to or from the floppy controller and does an RTI. It knows whether to read or write and the memory address for transfer by looking at the ram locations set up by the code in stfloppy.c (the DMA controller registers). Very simple, and requires only a small amount of alteration to stfloppy.c; about six lines, I think. The SCSI transfers are also done by assembler routines in stmpx.s, but they are not interrupt driven. With a fast SCSI disk there is very little point in doing them any other way because data is coming off the disk at a pretty fast rate ! I won't go into details of the serial or parallel port drivers because it is pretty simple once you have got a data sheet on the device and figured out how to talk to it. Anyone who has written drivers for OS9 or anything similar should have no trouble at all; writing them in C is a nice experience after years of drivers written in assembler ! You will need to write a boot routine to load the MINIX image. This isn't too difficult; build tells you how many sectors to load by placing the number in the first sector of the disk. I wrote a little routine in assembler to read the first sector from floppy and determine from it the number of sectors to load. The boot program then loads that number of sectors into high memory out of the way. When it is finished, the image is copied to location 0000 upwards, remembering the 0x200 skip in the middle (look at stmpx.s). The program then just jumps to the reset vector (usually 0x600) and off you go, hopefully. The important thing to remember is to change as little as possible of the original code. Apart from limiting the number of mistakes you can make, this will help greatly when you want to update to 1.5.X or whatever. Oh, and don't try putting debugging statements in until the tty driver has been initialised, because the machine will hang otherwise. Best of luck !!!! Andy Michael -- Andy Michael (eesrajm@cc.brunel.ac.uk) " Software cannot be written to 85 Hawthorne Crescent be completely free of errors." West Drayton Middlesex - Acorn Computers Ltd. UB7 9PA