• Please review our updated Terms and Rules here

68k-based homebrew?

I’m very interested in your 68030 restoration. Looking at your prototype, I think my own 68030 efforts in 2017 was very similar; I started with 8-bit RAM, ROM and added 72-pin SIMM memory later. I used a CPLD to reduce IC count to fit the design in 100mmX100mm pc board. The board was mostly pc board, but the DRAM portion was hand wired because I’m not sure about that part of design. I think my memory map can be changed to like yours so hopefully I can port your Minix software to my prototype.
Bill
 

Attachments

  • Tiny030-comp.jpeg
    Tiny030-comp.jpeg
    367.8 KB · Views: 13
  • Tiny030-solder.jpeg
    Tiny030-solder.jpeg
    454.1 KB · Views: 12
Plasmo said:
I’m very interested in your 68030 restoration. Looking at your prototype, I think my own 68030 efforts in 2017 was very similar; I started with 8-bit RAM, ROM and added 72-pin SIMM memory later. I used a CPLD to reduce IC count to fit the design in 100mmX100mm pc board. The board was mostly pc board, but the DRAM portion was hand wired because I’m not sure about that part of design. I think my memory map can be changed to like yours so hopefully I can port your Minix software to my prototype.
Bill
Click to expand...
very cool. I really like the compact design. Hopefully, I can find all the Minix sources I modified for the MMU. I was able to power it up last night, working on figuring out the serial comms... I tossed all my terminals a long time ago and working with kermit on Linux and USB-serial adapters to talk to it, but so far silence.
 
Plasmo said:
I’m very interested in your 68030 restoration. Looking at your prototype, I think my own 68030 efforts in 2017 was very similar; I started with 8-bit RAM, ROM and added 72-pin SIMM memory later. I used a CPLD to reduce IC count to fit the design in 100mmX100mm pc board. The board was mostly pc board, but the DRAM portion was hand wired because I’m not sure about that part of design. I think my memory map can be changed to like yours so hopefully I can port your Minix software to my prototype.
Bill
Click to expand...

While CPLDs do reduce IC count they also often end up obscuring/obfuscating the actual logic from the perspective of someone coming along later who doesn't have a working chip or any way to read one.

Nevermind that HDL documentation + hardware/software tools tend to become obsolete with time and become unobtainium.
 
Istarian said:
While CPLDs do reduce IC count they also often end up obscuring/obfuscating the actual logic from the perspective of someone coming along later who doesn't have a working chip or any way to read one.

Nevermind that HDL documentation + hardware/software tools tend to become obsolete with time and become unobtainium.
Click to expand...
one of the reasons that 74LSxxx logic was used on the WS030 project, is to keep the design open enough for students to figure out what is going on while they are learning assembly language and basic computer architecture. we had an advanced computer architecture class where they had to program some basic PLDs for their projects. we had enough information about the PLDs used that they students could use an fusemap editor to understand how to program them. we also had a homegrown PLD assembler. the PLD used on the WS030 for memory map, would have been within the capabilities for a student to understand and modify for the "advanced students" seeking to work on research projects or extra credit. the lab version of the WS030 had a DIN connector with all of the CPU signals, so custom designs could be implemented. I.e. need a DMA framebuffer ? no problem. it was before things like open FPGA/CPLDs projects existed to design/program Lattice 10k CPLDs. we were using Xilinx, Actel FPGAs and VLSI with eCAD proprietary software for some of our research projects at the time. in the end (30+ years later), I have enough software to replicate the PLDs on the WS030, but would be hard pressed to recreate the workstation, licenses to replicate some of our FPGA design of that era. so your observation of the HDL documention and tools availabity, is right on.
 
Last edited:
I agree CPLD is fairly difficult to understand, however it can be modified easily and additional logic added. So it is relatively easy to change its memory map and add diagnostic and observation points. I’ve designed most CPLD in schematics which are easier for me to understand and more efficient usage of resources. The CPLD are Altera EPM7128S (128 macrocells) which are still available for $3-$4 each, the design tool is Quartus which is free download with free permanent license. So other than steep learning curve of CPLD, it is a low cost, flexible glue logic solution.
Bill
 
Plasmo said:
The CPLD are Altera EPM7128S (128 macrocells) which are still available for $3-$4 each, the design tool is Quartus which is free download with free permanent license. So other than steep learning curve of CPLD, it is a low cost, flexible glue logic solution.
Click to expand...

Is Quartus any better than WinCUPL? I've been thinking of trying to adopt the ATF1508 for some projects that would be a bit much to do with GALs (or, at least, would require quite a few GALs to pull off), but WinCUPL is the absolute worst. It looks like it's possible to use Quartus and a tool to convert the output? There are forum posts and docs that describe the conversion and say the ATF1508 is equivalent with the EMP7128S
 
WinCUPL is the worst tool! Quartus is far better. Atmel 150x have few enhancements than EPM7xxxS, but they are basically the same. I’d design in Quartus then translate the resulting programming file to Atmel format using POF2JED converter. That method seems to work well for most designs.
 
Hmm, some setbacks with the wire wrap proto of WS030. turns out the rom images I have will only allow a Paradise PVGA1A 8bit card as console and won't auto detect the serial port on the Multi-IO card I have. it has the code, but apparently once I had the VGA driver working, I never bothered to check if the autodetect still worked, if there was no VGA card.

Right now the only 8bit Paradise cards I can find, are like $200 from Poland. I last compiled the proms with the Sun3 compiler under SunOS or one of the earlier gcc-m68k cross compiler or maybe the Stanford m68k compiler. I'm going to try it with the current version of gcc-m68k and fix what is needed to build a ROM image that can handle the serial port.

WRT to Minix for it. I don't have the sources or the distribution I used for it. I have a boot image with the kernel, but it will need the Minix-ST /root and /usr floppies. I think the best route would be to try to get the Minix-Amiga 2.0.4 build running on it. it's not copyrighted by Prentice Hall and the sources are available online. the original reason for not releasing the modified Minix-ST was because of copyright issues with PH.

Overall, this is a fun exercise and not unlike the projects I sometimes do for work (although different architecture and no open source).
 
@cylIax
Searching 'paradise vga' on eBay returns 90 results in the US. Is there any reason you couldn't just pick up a nominally "16-bit" card that's using a PVGA1A chip? -- If you are not located in the US, I understand that might not be an option.
 
Istarian said:
@cylIax
Searching 'paradise vga' on eBay returns 90 results in the US. Is there any reason you couldn't just pick up a nominally "16-bit" card that's using a PVGA1A chip? -- If you are not located in the US, I understand that might not be an option.
Click to expand...
yes, because my recollection is that the 16bit version didn't work because the 16-bit memory space is different from the 8-bit memory space in the design and the software needs to know. I may order one and try anyway, because I'm at the point of having to recompile/configure the boot proms anyway.
 
cylIax said:
yes, because my recollection is that the 16bit version didn't work because the 16-bit memory space is different from the 8-bit memory space in the design and the software needs to know. I may order one and try anyway, because I'm at the point of having to recompile/configure the boot proms anyway.
Click to expand...

Do you suppose your driver could be fudged somehow to get something onto the screen? Presumably the registers and other details must be similar in order for it to be VGA compatible...

Perhaps some additional hardware could be used to rearrange the data bits in between the bus and the video card?
 
Istarian said:
Do you suppose your driver could be fudged somehow to get something onto the screen? Presumably the registers and other details must be similar in order for it to be VGA compatible...

Perhaps some additional hardware could be used to rearrange the data bits in between the bus and the video card?
Click to expand...
yes, the proms can be compiled to work with some 16bit cards, it wasn't very reliable. I'm resurrecting a 33 year project and I have boot proms that were compiled back in the day that do not auto detect the COM port properly when it doesn't find the VGA card and has been configured to deal with the Paradise 8bit card, if it can find it.

I'm going to try a 16bit Paradise card just to see if it works, but most of the effort at this point is to re-create a cross compilation environment using gcc-13 so I can build the prom, and then I can fix some of these issues in the software. the original proms where compiled with gcc-2 for Sun3 target.

I do have a programmer, and in theory can burn eeprom or flash boot proms.
 
I am in the early stages of a 68000 homebrew build. I want to learn OS development in a sort of white room setting. ie. I want to learn by figuring stuff out and doing. As I tend to work upside down a lot, I decided it was a good idea to build the hardware to understand why you need an OS in the first place.

I am no married to any prior example and have no ultimate design or purpose. Just for fun.

Starting simple with a bare bones CPU+ROM+RAM+DUART and basic static 74HC logic address decode. I completed the "test harness" in verilog simulation and Im working on the first schematics.

The age old pain of the 68k et. al. era is the 5V rail. Beyond the above 5V "POC / MVP", things starts to get a bit difficult. So many avenues are blocked with the "3.3V" sign. It brings the options to:

* Level shifting the bus
* Using period 5V hardware throughout
* Use an FPGA 68k softcore
* Find and use a 3.3V SEC variant.

My first board is going with Option 2 for now, but option 3 is tempting.

My second board will hopefully include an FPGA for basic MMU/IOMMU functionality, as I don't think I have the stomach for legacy CPLD eco-systems. tool chains and programmers. I spent too many evenings trying to find a 5V CPLD that was easily available and had a tool change which working on anything more modern than Windows95.

So if I either level shift or softcore and start 3.3v.

Decisions, decisions.
 
paulcam said:
I am in the early stages of a 68000 homebrew build. I want to learn OS development in a sort of white room setting. ie. I want to learn by figuring stuff out and doing. As I tend to work upside down a lot, I decided it was a good idea to build the hardware to understand why you need an OS in the first place.

I am no married to any prior example and have no ultimate design or purpose. Just for fun.

Starting simple with a bare bones CPU+ROM+RAM+DUART and basic static 74HC logic address decode. I completed the "test harness" in verilog simulation and Im working on the first schematics.

The age old pain of the 68k et. al. era is the 5V rail. Beyond the above 5V "POC / MVP", things starts to get a bit difficult. So many avenues are blocked with the "3.3V" sign. It brings the options to:

* Level shifting the bus
* Using period 5V hardware throughout
* Use an FPGA 68k softcore
* Find and use a 3.3V SEC variant.

My first board is going with Option 2 for now, but option 3 is tempting.

My second board will hopefully include an FPGA for basic MMU/IOMMU functionality, as I don't think I have the stomach for legacy CPLD eco-systems. tool chains and programmers. I spent too many evenings trying to find a 5V CPLD that was easily available and had a tool change which working on anything more modern than Windows95.

So if I either level shift or softcore and start 3.3v.

Decisions, decisions.
Click to expand...
I like mc68030 over 68000 because of the dynamic bus sizing, which makes it easier to mix and match 8bit rom/IO/ram with 16 and 32 bit devices (also builtin MMU). legacy 5V vs. 3.3V is a pain, especially if you want to use modern FPGAs. I would probably just go with level shift. there are versions of 74 logic which are 5 volt tolerant and can provide 3.3v output, like 74LVCxxx. your typical TTL inputs can typically do 3.3V CMOS logic, since it's 1/2 3.3V for logic high. sounds like a fun project.
 
I want to stick with the 68000 or 68010 so I have to do the MMU self in FPGA for virtual memory addressing/multi-tasking.

On that, it will make a nice FPGA project for a "not quiet brand new" beginner. The actual address mapping is easy, providing an IO interface to supervisor mode to flush/append/rebuild the lookup buffers might be a bit more challenging, but as the "scale" is hobby I could get away with a fixed size lookup table with direct memory mapped IO for each entry.

That's only just setting up for the real fun in the OS of "How do we manage different address spaces and signals?". Again, baby steps of discoveries. I am wearing Unix tinted specs though. I can't unlearn things.

As to what I know about OS design? I read most of Jean Bacon's book on concurrency in OS and DB design. It was the chapter in her book on "TLBs" and virtual address isolation and shared memory that still intrigues me enough to try it in a 68000 and FPGA homebrew.
 
paulcam said:
I want to stick with the 68000 or 68010 so I have to do the MMU self in FPGA for virtual memory addressing/multi-tasking.

On that, it will make a nice FPGA project for a "not quiet brand new" beginner. The actual address mapping is easy, providing an IO interface to supervisor mode to flush/append/rebuild the lookup buffers might be a bit more challenging, but as the "scale" is hobby I could get away with a fixed size lookup table with direct memory mapped IO for each entry.

That's only just setting up for the real fun in the OS of "How do we manage different address spaces and signals?". Again, baby steps of discoveries. I am wearing Unix tinted specs though. I can't unlearn things.

As to what I know about OS design? I read most of Jean Bacon's book on concurrency in OS and DB design. It was the chapter in her book on "TLBs" and virtual address isolation and shared memory that still intrigues me enough to try it in a 68000 and FPGA homebrew.
Click to expand...
well, it would be a good learning experience. implementing virtual memory in a 68000 is difficult, because it can't restart instructions when they encounter a page fault. early on there have been some implementations, using two 68000's slightly out of step, so the second CPU can re-run the instruction that caused the page fault, but it's messy. implementing straight segmented and remapped address spaces is certainly doable in 68000. 68010 does add restartable instructions and special move instructions to different address spaces, so it would be possible to implement virtual memory. early Sun Microsystem used mc68010 and then mc68020 CPU boards with external MMU designed with discrete logic and memory for lookup tables, so they could support virtual memory and port Bsd Unix and build early SunOS around it. you might be able to find early versions of NetBSD which may have had support for Sun1/2 hardware as a reference, since it has source code. putting all the MMU logic in a FPGA would be a fun project and allow you to play around with implementations. a big FPGA might have enough fast RAM to implement the translation/page tables. anyway, great project.
 
As long as you know what instruction was just executed then you can probably just manually revert the changes in many cases, albeit you'd have to write some code to manage that.

Presumably you could also do something a bit more cumbersome like a context switch before executing any code that might hit a page fault so that it's easy to restore the previous state. Although it might just be easier to abort the execution of the offending code.
 
cylIax said:
well, it would be a good learning experience. implementing virtual memory in a 68000 is difficult, because it can't restart instructions when they encounter a page fault.
Click to expand...
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.
 
You must log in or register to reply here.
Back
Top