Fellow DECstation hackers
Michael Engel wrote:
> due to the overwhelming amount of requests regardings the DECstation port
> during the last few weeks ;-), we should do something to get the port further
Glad to see that there are other people working on the DECstation port.
I began to feel lonely ;-).
> I will set up a mirror site of Paul's DECstation information pages on Monday
> and would like to ask all people who have DECstation patches to upload the
> patches to ftp://ftp.math.uni-siegen.de in /incoming.
I have done some work on the port lately. You can download a snapshot of
my work from
This is a diff against the linux-220.127.116.11.dec source tree from Paul.
> We should try to find out what the biggest problems in the current
> state of the port are. Areas that IMHO need work are:
> - Interrupt handling
I have completely rewritten the interrupt handler itself. The code for
initializing the tables in there definitely needs some more work. Have a
look at decstation.c to get the idea.
> - MMU setup and handling
Rudimentary MMU support is also there, very rudimentary. This is just
enough to get through buffer_init(). The kernel is now dying in the
attempt to return from the first syscall in kernel_thread(...) at the
end of main(...) in init/main.c. I am getting a kuseg miss with a
BAD_VADDR of 0x00000000, which looks like a NULL pointer dereference. I
haven't yet been able to find the reason cause using the prom_printf
routine in exception handling code seems to be a bad idea :-(. Actually
I am working on a primitive debugging console via serial port.
> - of course, device drivers:
> o Ethernet (Lance 7990) - should be able to derived from the Sparc port,
> major difference is that the Lance has a separate memory area in at
> least the DS100 and 5000/200 and isn't able to do DMA.
This is true for the DS100 and the 5000/200. The 5000/25, 5000/1xx
and 5000/2x0 DECstations have DMA support for the Lance, the NCR53C94
and even the Z8530 chips.
> o SCSI in DS100 - the DEC SII chipset. Documented in the DS3100
> functional specs
> o SCSI in almost (?) all other DECstations - NCR53C94. Is this chip
> documented ?
See other replies.
> o Console drivers (I got some of these working with the DZ11) - a DZ11
> compatible UART in DS100 and 5000/200, a Zilog 8530 in at least the
> Personal DECstations and the DS5000/1xx.
And the 5000/2x0.
> Support for the DS100 frame buffer also exists.
> We should also examine the differences between the various REX- and
> non-REX firmware versions in the various DECstations.
> o TurboChannel support - probing for cards etc. and support for the most
> important TC options - PMAG-[AB]* graphics adapters, ethernet and SCSI
> controllers (which are simply TC versions of the Lance and NCR53C94).
> Well, we also have a nice 24-bit i860-accelerated graphics board here ;-)
Mee too ;-).
> [So you say that's almost everything - hmmm, maybe you're right ;-)]
> Probably it is also a good idea to make a list of the hardware that is
> available for testing kernels.
> I have a DS2100, a 5000/25, a 5000/120 and a 5000/200 and can get
> access to 5000/33's, 3100's and 5000/240's at University.
I have a 5000/133 and a 5000/240.
> I would personally also like to support the first-generation TurboChannel
> AXP machines (3000/00) as the Alpha developers don't seem to be
> interested in these ... but I still don't have such a machine :-(.
>From what I have been able to find out, these are very similar to the
DECstation 5000/240 and are quite well documented.
> Michael Engel (email@example.com)