Before you can do anything useful with a Prisma workstation, you have to get over the hurdle of the network boot loader. In its original configuration, the Prisma loaded its runtime system from a Un*x server, an elderly Masscomp 5450 in my case, using a proprietary boot protocol running over an OSI CLNS transport service. There is no support for BOOTP or TFTP in the Prisma's monitor ROM. I couldn't add the Masscomp to my home network, it was still in occasional use, so I needed something else that supported OSI CLNS and which had tools that would allow me to write a boot server. The only freely available systems that had direct support for OSI networking were the BSD derivatives, and I was already running NetBSD on my Amiga, so the choice very quickly settled down to NetBSD-Amiga.
For the toolkit, the only practical choice was ISODE. I had some exposure to ISODE many years ago and although it had since gone commercial, the final free release (8.0) was still available and, as it turned out, quite sufficient. As a relic of that previous encounter, I also had the book The Open Book, A Practical Perspective on OSI by Marshall T. Rose which proved to be very useful.
The final piece that made the boot server possible was a packet trace of a Prisma booting from its original server. This allowed me to see the header that the server sent which described the code image that followed. The header contained information such as the code and data sizes, the load address and the entry point.
From the packet trace, I could see that the boot protocol was very simple, it ran over the OSI transport layer, which offers reliable transport, so no additional checksums or acknowledgements were used. However, writing the server took longer than it should have because I had to spend some time debugging the CLNS network code within the NetBSD kernel itself. It turned out that there was a subtle structure alignment problem on m68k systems which broke the CLNS code in NetBSD 1.2. This has been fixed in later releases (I currently run 1.3 and 1.4 is not far away). There was also a problem with ES-IS routing which I have not been able to fix as yet and for which the only work-around is to disable recognition of ES packets in the NetBSD kernel (a one line patch).
Having debugged the OSI network layer, the boot server was created by modifying one of the example TSAP servers, 'support/isod.c', included in the ISODE distribution. The diffs are available in the downloads section. The server is not specific to Minix, it also recognises NetBSD a.out files. I use this facility to transfer stand-alone test programs when experimenting with low-level code to talk to the hardware.
In its original environment, the boot parameters are stored
in NVRAM and the Prisma boots automatically when it is switched on.
You can also give the command 'netboot' at the monitor
prompt. I understand that the parameters were originally entered using
a configuration option
within the CAD application since there does not appear to be any
simple way to save them using the monitor ROM commands. To boot
a Prisma from a new server you can specify all the parameters
using the interactive option 'netboot -i' but these are
not saved in NVRAM and have to be repeated every time you boot.
This gets to be a real pain after a while so I searched out where
the parameters were held in NVRAM and found that you could edit
them using the monitor's memory examine and change commands.
To give an example:
My Prisma's MAC address is: 0000E900013C
and the NetBSD server's MAC address is: AE5553001247
The full netboot command then looks like this, keyboard input is in
bold:
>>>netboot -i
OSI Version 4 bootstrap
Valid Network Address: 0000E900013C
Enter the name of the file to load: /tmp/minix
Enter the boot host NSAP address: 490001ae555300124700
Enter the boot host 12-digit MAC address
if ES-IS protocol is not supported: ae5553001247
Enter this Prisma's NSAP address: 4900010000e900013c00
Auto-execute? (y/n): n
OSI device at 120000, device <ethlan0>, MAC <0000e900013c>
Booting from 490001ae555300124700
lsdlt: cco (4ab0) ccb->dest_ccb = NULL, ppi = (nm), port = (down)
boot failed
>>>
What doesn't show in the example above is that you get a spinning line on the screen while the data transfer is in progress. The 'boot failed' message is the result of me not getting the boot server quite right. I guess that it should be sending some sort of marker or checksum at the end of the transfer but I do not know what the marker is. Since it doesn't stop the image being used, I am ignoring it for now.
The boot parameters are stored at the start of the 2nd 1K block of NVRAM. It looks like this:
>>>db 1c03f0 1c04ff 001C03F0: 00 00 00 00 00 00 33 CC 00 00 E9 00 01 3C 15 C3 *......3L..i..<.C* 001C0400: AE 55 53 00 12 47 00 0A 00 00 00 00 00 00 00 00 *.US..G..........* 001C0410: 00 00 00 00 00 00 2F 74 6D 70 2F 6D 69 6E 69 78 *....../tmp/minix* 001C0420: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 *................* 001C0430: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 *................* 001C0440: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 *................* 001C0450: 00 00 00 00 00 00 77 79 35 30 2E 69 67 73 00 00 *......wy50.igs..* 001C0460: 00 00 00 00 00 00 00 35 30 30 00 00 00 00 00 00 *.......500......* 001C0470: 00 00 00 00 00 00 00 00 49 00 01 AE 55 53 00 12 *........I...US..* 001C0480: 47 00 00 00 00 00 00 00 00 00 00 04 00 0A 49 00 *G.............I.* 001C0490: 01 00 00 E9 00 01 3C 00 00 00 00 00 00 00 00 00 *...i..<.........* 001C04A0: 00 00 00 0A 00 01 00 00 00 00 00 00 00 00 00 00 *................* 001C04B0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 *................* 001C04C0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 *................* 001C04D0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 *................* 001C04E0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 *................* 001C04F0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 *................* >>>
The addresses I have been able to identify are:
1C03F6 1 byte CPU clock speed with 1 byte checksum
1C03F8 6 byte MAC address of this Prisma with a 2 byte checksum
Note: this is the end of the 1st 1K block and is write protected.
1C0400 MAC address of the boot server
1C0416 Name of the boot file
1C0478 NSAP of the boot server
1C048E NSAP of this Prisma
The command to modify memory is 'mb' followed by the hex address. This can be used to change the boot server MAC and NSAP addresses in NVRAM to avoid having to type them in every time you boot.