• Please review our updated Terms and Rules here

68k-based homebrew?

OK, some updates on resurrecting the WS030 prototype. I have a 16bit Paradise, but it doesn't seem to recognize the card. I have a multi-io card; the prom software is supposed to look for a COM1 serial port if it can't find the VGA card, but so far no activity. I also have a 1Mx32 SIMM module for the memory. it might be time to pull out the logic analyzer and see what is happening at boot. I have LEDs that display the CPU status (super mode, and interrupt level) and it certainly does stuff when you hit the reset, and then stops, presumably because it got lost and got a double bus error or something. I'm going to validate the image in the prom I have (it's from 30+ years ago) to see if there is some bit-rot going on. I have an image and sources I can compile, so I can burn some new proms.

as a side note, I did find some of the sources to the modified Minix that ran on it, once the hardware is running, I'll see what needs to be done to build a bootable image.

also, recapturing the schematics and layout in Kicad.
 
Last edited:
OK, this is encouraging... but I only got it to do it once.

----------------------------------------------------
68030 Boot Prom Version 0.8mx
Console on COM1
Strike a Key to abort boot sequence
���"!! ��������O8�������������������������������������{��?gy�u��J����K�
Communications disconnect (Back at ingo-OptiPlex-980)
----------------------------------------------------
 
Perhaps your board expects to see old-fashioned RS-232 that uses +12V/-12V or maybe +6V/-6V rather than TTL serial which uses 0V and 5V?

Or maybe it's getting spurious data and thinks you've pressed a key?
 
Perhaps your board expects to see old-fashioned RS-232 that uses +12V/-12V or maybe +6V/-6V rather than TTL serial which uses 0V and 5V?

Or maybe it's getting spurious data and thinks you've pressed a key?
it uses an ISA multi-IO card with real RS-232 levels and the baud rate is 9600baud. the interface to my PC is a USB serial based on FTDI chipset and it will do +12/-12V as well. the terminal emulator is kermit running under Ubuntu Linux. this setup works for various other serial devices, like my ancient EPROM burner and other projects. the spurious data is stuff that comes out when I try to reset it or power cycle it various times. it's more likely, that the reset isn't very clean since it uses a electrolytic capacitor/resistor/diode to delay reset until VCC is stable, and has a switch that can manually cycle it. anyway, it's a 33 year old wire wrap board from project a long time ago, that I'm trying to revive it. having it print out the prompt in plain text is a giant step forward...
 
I have been transcribing the published schematics of the WS030 to Ki-cad and have found some errors in the published schematics. I will published what I found and the new Ki-cad schematics, once I'm done with capturing it.

Some background on this. the original designs was done in a schematic capture (don't recall the name) that ran on SunOS. it didn't have a layout editor, but our department had a License for PADS 2000, which was sort of the standard at our University at the time. I was able to extract a Netlist and BOM for the project, which we fed into the PADS PCB editor directly and designed the boards. The schematic was later re-captured in PADS, but I don't think we ever validated the re-captured schematic with the PCB. there were also two version of the PCB with minor changes. There is a lot of vintage stuff I like; however one of the few modern things I like, is the free eCAD scene. Ki-Cad has come a long way, from the days of gschem, gEDA, etc... At work, I use Altium (like everyone else it seems), but for protyping and personal projects, Ki-Cad is my "goto" tool.
 
I should take my blank board into work and scan it on our high resolution 11x17 scanner.

Do you not have a PCB of the finished board any more?

Could a Gerber be synthesized from PADS output that you have?
 
I should take my blank board into work and scan it on our high resolution 11x17 scanner.

Do you not have a PCB of the finished board any more?

Could a Gerber be synthesized from PADS output that you have?
If it's not too much trouble to do that, it would help. especially in identifying which version you have. I do not have any PCBs, just the wire wrap protoype, which has some known hardware difference, but is software compatible.

I do have the Gerber files from PADS and I was able to add the aperture definition to the Gerber files so that the KiCad Gerber viewer can image them. there is supposed to be a way to import the Gerber data into the KiCad PCB editor.

However, the bottom Gerber is mirrored and the KiCad Gerber viewer can't un-mirror them to match the component side view. I have tried gerbv, which can mirror them, but won't output/save the mirrored file. I'm not sure if I have access to a CAM tool to do the mirror and save it, so I might just save them as a tiff image, which I can mirror and import into the KiCad PCB editor as a seperate graphics layer.

[EDIT: I can import the Gerber layers into the KiCad PCB editor as real layers, the only remaining issue is the mirrored bottom layer]

1769716159280.png

I think the serial port driver on the Multi-IO card I got from Ebay isn't working. Last night, I was able to get the 16bit VGA card I have to boot up in 8bit mode. I'll see if I can scrounge a AT keyboard and see if I can talk to it and maybe try to the Minix floppy image.
 
Last edited:
Perhaps there is something physically wrong with the Multi-IO card?
could very well be. it doesn't have the standard 1488/1489 driver/receiver, it's an ASIC, so not really something to diagnose or fix easily. the VGA card works and I have a AT keyboard, just need to fix the DIN connector that got lost over the years...
 
it doesn't have the standard 1488/1489 driver/receiver, it's an ASIC, so not really something to diagnose or fix easily.

A lot of PC serial ports have a single SN75185 (or equivalent) instead of the 1488/89 pair, it doesn't have that either? Even the SuperIO chips on 2000-s era motherboards still typically use external driver chips.
 
A lot of PC serial ports have a single SN75185 (or equivalent) instead of the 1488/89 pair, it doesn't have that either? Even the SuperIO chips on 2000-s era motherboards still typically use external driver chips.
the one I have doesn't external driver/receiver. they are part of a single chip that has the USARTs and the drivers/receivers and is connected to the +/-12V and +5 ISAbus supply. it's 90s era unbranded stuff. I'll re-visit it later.
 
IMG20260201074718.jpgIMG20260201074747.jpgIMG20260201074807.jpg

Success !!! I was able to boot it from a 30+ year old prom. this weekend. next, we'll see if we can boot from a floppy. Even works with a PS/2 KBD (with adapter).
 
You can do it the Apple Lisa way, which takes advantage of the fact that you can restart some instructions. The Lisa developer's documentation warns you to TST.W <address> if you are reaching far enough away in the address space that you might cause a page fault. Evidently TST.W is restartable enough. The documentation offers no insight into whether other instructions are suitable.

When you say virtual memory people, arguably correctly, lump all possible modern virtual memory functionality into the concept.

Paging to disk or other storage is the only part that needs restartable instructions.

So without restartable instructions the process is quite simple. Access an unmapped address and get you get "Page Fault" and your application is terminated.

Paging to disk is SO far away on my plans that it would be rather stupid to include it as a dependency at this stage. I don't even have the concept of a disk "planned". I'm starting with "tape". Why? I want to learn what went before disks to understand what people knew when they came to do disks.

Tape is a lot more simple. However a lot of the simple things there just get a little more complex and moved around for disk.
 
So without restartable instructions the process is quite simple. Access an unmapped address and get you get "Page Fault" and your application is terminated.

The way the tst instruction for segment sniffing works is the same way Unisoft Unix dealt with stack expansion.
It special cases the instruction used for stack sniffing and cleans up after itself after the faulted instruction.
It then just proceeds or faults if it can't expand the segment.

In the case of Unix, they modified the C compiler to stack sniff on procedure allocations to make sure there is space
in the stack segment for automatics.
 
Last edited:
When you say virtual memory people, arguably correctly, lump all possible modern virtual memory functionality into the concept.

Paging to disk or other storage is the only part that needs restartable instructions.

So without restartable instructions the process is quite simple. Access an unmapped address and get you get "Page Fault" and your application is terminated.

Paging to disk is SO far away on my plans that it would be rather stupid to include it as a dependency at this stage. I don't even have the concept of a disk "planned". I'm starting with "tape". Why? I want to learn what went before disks to understand what people knew when they came to do disks.

Tape is a lot more simple. However a lot of the simple things there just get a little more complex and moved around for disk.
excellent point you make about pageing in virtual memory.

there are also other interesting application where pageing can come into play. E.g. in traditional programs, there is a heap, which grows when you allocate memory and a stack that has to allocate memory as it grows. some operating systems use page faults to signal the OS to allocate physical memory when the application wants to grow the stack and heap.

interestingly, during my life as a research engineer, we had a project where we implemented various ways of reference counting memory, I.e. associate some meta-data that indicate what memory is still being used by the application, so that when the references to that memory become zero, it can be free'ed up. one implementation, which ended up being fairly efficient is using page faults to keep track whether memory is still being used. i.e. when a page fault occurs you know the application is still referencing the memory. for example, many languages like Scheme and even Java don't explicitly free memory, I.e. they just forget the pointer to the memory, when they are done with it, and you have to implement some sort of garbage collection, otherwise you have a memory leak.

in learning about computer science, it's really fun and useful to build custom hardware like you are doing. I miss that phase of my life.
 
@paulcam Are you talking about magnetic tape? How is it any simpler in your mind?
a lot of what we do with disk storage mimics what we used to do with tape. I.e. open, seek, read/write sequential, close, etc... many tape devices allowed random access to blocks on the tape and it was possible to use them as block devices and mount filesystems on them, albeit slow. if you think about it, magnetic storage disks, are conceptually flat tapes in a loop with multiple tracks on it. flash drives and SSDs only emulate disk drives on true random access devices, to make it easy to interface.
 
Hi!
I still have the two pcbs (still unassembled) that you sent
It would be fun to add the Minix files to what I've archived on bitsavers
Hi Al,

so, I have done some searching. turns out I have the sources to the Minix I ported to it. I believe it was based on Minix 1.3. for Atari-ST. I modified the kernel/mm/fs to implement a memory mapping system that mapped the Heap/Stack to it's own physical memory, so it didn't have to do a memory copy at context switch to a forked process. also, of course, drivers for the devices use on the ws030.

I have a boot image of the modified OS, which I will try this weekend, but it will require a /root and /usr floppy with the system binaries, to built the initial system on a harddisk. once there, it can then compile itself and generate new boot, root and /usr floppies, i.e. basically clone itself. it will also need the C compiler (ack) for it, which only came as a binary on one of the filesystem floppies. after scouring some of the archives, but haven't found any images of the original Minix-ST floppy distribution.

I think at this point, I'm going to figure out how to get the essential system commands cross-compiled under Linux and generate new floppy image for the installation process and maybe a complete hard disk image once it's running again.

The plan is still to resurrect the original version as best as possible, before making any mods to it and freeze it. I'd be more than happy to have everything archived on bitsavers once it's all restored and running again. is it possible to archive the disk images there as well ? also, I have some PDFs of the 3 part article series I did for Circuit Cellar INK, would you be interested in that as well ?

I don't know what I want to do after that, but it will feel like an accomplishment to put a final chapter on one of my creations, even several decades later... always open to suggestions.

Oh, so the actual gerbers I have are for version 0.1 of the PCB, and it looks like you have the full-on version 0.2 of the PCB. it would be useful to get a good quality scan of the unpopulated 0.2 board to reverse engineer the (hopefully minor) changes that were made.

-ingo
 
Last edited:
Hi Al,

so, I have done some searching. turns out I have the sources to the Minix I ported to it. I believe it was based on Minix 1.3. for Atari-ST. I modified the kernel/mm/fs to implement a memory mapping system that mapped the Heap/Stack to it's own physical memory, so it didn't have to do a memory copy at context switch to a forked process. also, of course, drivers for the devices use on the ws030.

I have a boot image of the modified OS, which I will try this weekend, but it will require a /root and /usr floppy with the system binaries, to built the initial system on a harddisk. once there, it can then compile itself and generate new boot, root and /usr floppies, i.e. basically clone itself. it will also need the C compiler (ack) for it, which only came as a binary on one of the filesystem floppies. after scouring some of the archives, but haven't found any images of the original Minix-ST floppy distribution.

I think at this point, I'm going to figure out how to get the essential system commands cross-compiled under Linux and generate new floppy image for the installation process and maybe a complete hard disk image once it's running again.

The plan is still to resurrect the original version as best as possible, before making any mods to it and freeze it. I'd be more than happy to have everything archived on bitsavers once it's all restored and running again. is it possible to archive the disk images there as well ? also, I have some PDFs of the 3 part article series I did for Circuit Cellar INK, would you be interested in that as well ?

I don't know what I want to do after that, but it will feel like an accomplishment to put a final chapter on one of my creations, even several decades later... always open to suggestions.

Oh, so the actual gerbers I have are for version 0.1 of the PCB, and it looks like you have the full-on version 0.2 of the PCB. it would be useful to get a good quality scan of the unpopulated 0.2 board to reverse engineer the (hopefully minor) changes that were made.

-ingo
Have you looked at https://github.com/mevenson/minix-for-the-PT68K-2-4
 
Back
Top