Close
0%
0%

rhombus

An open-source minimalist 68020 based single board computer

Similar projects worth following
rhombus is a minimalist Motorola 68020 single board computer based upon Motorola's Application Note 1015. A CPLD is used for all glue logic. Typos and omissions in the original Motorola schematic and code have been addressed.

The goal is to code a functional and user-friendly ROM monitor and allow the board to become a useful development tool. I searched long and hard for open-sourced projects based upon this processor and found very little information. While I am building this to become familiar with low-level system operation and assembly programming, I am hopeful that this project will serve as a starting point for other hobbyists who are just getting started in the home-brew computer world as well.
  • 1 × MC68020RC16E Microprocessors, Microcontrollers, DSPs / Microprocessors (MPUs)
  • 1 × XC95108 Logic ICs / Programmable Logic: PLDs
  • 1 × MC68901P Microprocessors, Microcontrollers, DSPs / Multifunction Peripherals
  • 1 × 27c256 Memory ICs / PROMs, OTP PROMs
  • 1 × UM61256K-15 Memory ICs / Static RAM (SRAM)
  • 1 × 50MHz Oscillator
  • 1 × 2.4576MHz Crystal
  • 1 × 48-pin wire-wrap socket (wide) for MC68901
  • 1 × 13x13 pin-array wire-wrap socket for MC68020 Custom ordered from samtec.com
  • 1 × PLCC84 wire-wrap socket for XC95108 CPLD

  • New board designs underway

    Jason Westervelt01/22/2016 at 21:35 12 comments

    I've finished the schematic for the two boards and once the parts that I have on order arrive, I will begin making wire-wrapped prototypes prior to sending the boards off to be fabricated. Overall, the design is a lot more flexible and a lot less complicated that I thought it would be.

    The VME board itself will be somewhat expensive due to the physical size of the board. For this reason, I want to make the board as flexible as possible to allow for future changes without having to spin off a new board. While rhombus is a 68020 board, I do plan on moving up to a 68040 for my next project, and I'd prefer having a VME interface that will accept the new CPU board with no physical changes. The board itself is rather simple... a CPLD, an EPROM for doing the address modifier lookups, and the bus buffer/transceivers.

    With regard to rhombus, the board is actually going to end up being smaller than my current wire-wrapped prototype, mainly due to switching to the PLCC-packaged MC68901 and ROM. RAM is going to be tested with DIP parts, however it will be replaced with 4x 44-TSOP packaged ICs once I run off copies of the board. There will be a need for pull-up resistors as some of the CPLD outputs are needing to be changed to open collector as they will also be potentially driven from the VME bus header.

    I also plan on adding a flash configuration rom and creating a basic configuration utility, but i'm currently debating a few design choices. Primarily the flash rom will be useful for storing information about add-in cards on the VME bus, and thus generating the necessary address modifier codes. Additionally, it will store things found in traditional PC BIOS, such as date/time, serial port configuration, etc. As such, there is potential need for the ROM to exist on the stand-alone CPU board as well as on the VME adapter board. I'm thinking of going with the latter, and allowing the CPU board to read data from the flash ROM if it is present and reverting to either jumpered values or values programmed into the CPU-board's EPROM if the flash device is not present.



  • VME Documentation Voodoo Deciphered

    Jason Westervelt01/19/2016 at 22:28 7 comments

    So, after going through a ridiculous amount of documentation, I had to resort to a handful of schematics for 8-bit port cards which show that D0-D7 on the interface, whether UART or SCSI or network, are connected to D8-D15 on the VME bus. The schematics that I have seen would indeed work with the diagram provided on my prior log entry. At least I have a path forward now.

    The next design phase is relatively straight forward. I have two 6U prototyping boards which will be used for wirewrapped versions of my main CPU board as well as a simple FT245 UART interface card. The UART is just to verify that I can get the VME signals all working as expected. Once the UART is verified to work, it will be moved to the main CPU board and the prototyping board will be cleared up for development of newer interface cards.

    The CPU board is receiving an overhaul. I am moving to a 16bit data bus for the EPROM, and 32bit data bus for the RAM. In addition to this, the 68901 is being changed to the PLCC part since the DIP package is considerably larger. I am also adding my keyboard interface to the CPU board.

    The board will remain minimalist in nature to allow a solid starting point for other tinkerers, but the expansion header on the board will mate with my VME interface board which will contain the bus transceivers as well as the necessary glue logic within another CPLD. The VME interface board will contain much blinkenlights, with the intent of providing visual feedback as to the status of each VME signal.

    That said, here are a few shots of the 10-slot VME backplane that I am using. This backplane is passively terminated with 330/470 ohm resistor pairs on each end of each non-daisy-chained line. Between both connectors, there are a total of 96 lines which are terminated. The serial resistance between 5V and GND at each end of each line is 330+470 = 800 ohms. 96 lines * 2 terminations (one at each end) yields 192 parallel resistances of 800 ohms each. Doing that math, that's an effective resistance of 4.167 ohms between +5V and GND. Gonna need over 1 AMP just to drive the backplane. :)

    When I first obtained the backplane, I was shocked by just how heavy the thing was. As I looked it over, I started to notice even more interesting traits. The resistor packs are all socketed. I guess this is to be expected as I would have done the same. Aside from the resistor pack sockets and the 2 dozen capacitors, nothing else is soldered. The screw terminals, the jumper headers, the giant 96pin VME bus connects... each are press-fit into through-plated holes. The first photo shows this upon examination. I guess the parts can be pulled and replaced should the need arise. I'm quite happy with this board, especially seeing as I obtained it for $10.

  • Time to bust out the books...

    Jason Westervelt01/12/2016 at 03:30 29 comments

    In preparation for the next revision of my hardware, I'm looking at making use of a standardized bus. I have a VME chassis and backplane, so I might as well make use of it. There are a few issues that I am running into, but I am certain that I'll get them figured out with a little reading.

    Basically what it boils down to is that A0 (address 0 line) is not presented on the VME bus. This leads one to believe that everything is 16bit data width or higher on the bus. There is an issue with that thought, specifically that 8bit cards and peripherals DO exist for VME systems.

    The documentation that I have from Motorola shows that, because the 68020 and higher are capable of 32bit data operations, that a few things have to be addressed when interfacing these CPUs to a VME system. One such difference is that the 8-bit data bus is present on D24-D31... 16-bit on D16-D31. That's fine, a few transceivers and supporting logic should fix the byte presentation to the CPU... and in fact the documentation that I have proposes just that...


    The problem is that the documentation shows D0-D7 on the VME bus going to D16-D23 on the CPU and VME D8-D15 going to CPU D24-D31 for a 16 bit operation, but for an 8-bit transfer, VME D0-D7 still end up going to D16-D23... not D24-D31 as I'd expect.

    I find it hard to believe that the documentation would be so horribly flawed, but it wouldn't be the first time that I've run across a spectacular booboo in documentation. Perhaps it is possible that 8-bit devices on the VME bus are actually attached to the upper byte, and thus D8-D15 on the bus ends up getting placed on D24-D31 on the CPU.




  • keyboard controller almost functional

    Jason Westervelt12/29/2015 at 02:55 0 comments

    I've got a couple of quirks to iron out with my keyboard controller, but it is almost working. I should have it completely operational sometime tonight or tomorrow. I elected to go with that old intel N8042 that I found, and it looks like it is going to be a very useful part for this project.

    The rev1 board is being designed at the moment. I elected to go with 3 parts which are in a PLCC44 or PLCC52 package:
    • The first is the intel N8042 keyboard controller. This has linux support. The good part is that I will work to emulate this part with one of my 5V tolerant PLCC44 Xilinx CPLDs. This will give folks the option of using either part should they elect to build one of these systems once I get the board files online.
    • The second is a Hitachi HN27C4096CC-12 UV EPROM which is a 2MBit (256Kx16) PLCC44 part. Obviously this means that I'm extending my ROM data bus to 16 bit. :)
    • The third is the PLCC52 packaged version of the MC68901. I really like this part, and since I haven't really found a linux driver for it, I certainly plan on using this board as an excuse to write one.

    In addition to these 3 PLCC parts, I'm also throwing in 4x K6X8008C2B-UF55 These are 1Mx8 55nS SRAM, so I will end up with 4MB of SRAM, likely 0 wait-state via a 32bit data bus. Also being thrown into the mix is an FT245 USB FIFO. This definitely has linux support and will be my initial console once I get uClinux up and running.

  • System clock requirement

    Jason Westervelt12/27/2015 at 02:00 2 comments

    In preparation for eventually booting uClinux (and full linux once I get my MMU and dynamic ram controller built), I'll need a system clock of sorts. I'm not too terribly familiar with how linux deals with the system clock/timer, but I am guessing that an interrupt would need to be triggered every so often... 1khz? 100hz? Anyone know the juicy details on what is needed from both a hardware and a configuration aspect?

  • It's always the little things...

    Jason Westervelt12/26/2015 at 05:04 0 comments

    I managed to fix the input issue...

    The device table includes the device name, such as "CON_IN" and "CON_OUT" for console input/output. When matching was being performed, I foolishly was matching on 8 characters and padding shorter names with spaces. I inadvertently placed a single space after each name, giving "CON_IN " a length of 7 which was causing it to fail during the device lookup. Ooops. I'll be moving these to null-terminated strings in the future.

    Things will pick up in pace a bit once I get the functionality from the old monitor into the rewrite. I'll keep the old monitor around since it is pretty simple and easy for a "novice" to understand. The whole purpose of this project is to trailblaze so newcomers can have a shot at doing something which may seem quite intimidating at first.

  • Alternate monitor in the works...

    Jason Westervelt12/25/2015 at 11:52 0 comments

    I have been working on a rewrite of the monitor. There were a couple of deficiencies which would have impeded development later on.

    The new monitor uses generic I/O functions for devices, and builds a device definition table in RAM which contains the device's address as well as pointers to the I/O handling routines for each device. The system input and output devices can thus be changed easily while the system is up and running... useful if the user wishes to load s-record data over a separate device for instance.

    To my amazement, the output function worked just fine after this massive rewrite. Something is wrong in the input, however, as the 'getline' function is ending prior to receiving any input from the serial port, throwing the thing into a massive loop as it sends a prompt over and over again. Too exhausted to continue debugging it tonight. It's probably some stupid little oversight...



  • Nothing says energy inefficiently quite like...

    Jason Westervelt12/25/2015 at 05:06 4 comments

    ...a big beefy vacuum fluorescent display!

    While this is going to be attached to my board, it really isn't part of the core project. I'm re-writing my monitor to allow for a generic I/O method which will allow the user to toggle between input and output devices. The user can use a serial port for input and output, or switch to LCD output with PS/2 keyboard input to remove the need for a second computer.

    The display shown here is a Noritake GU256X128D-3900. It's big, heavy, and guzzles electrons like there is no tomorrow... but the display screams retro and has a very beautiful quality to its color and contrast.

    I do have a video from another project, from which I am borrowing this display. That video is down below. Once I document that project and get the code up on github, I'll be posting it to hackaday.io

  • Inner Conflicts, v1.0

    Jason Westervelt12/21/2015 at 10:16 6 comments

    Soon I will be adding keyboard and an LCD to make this a self contained unit. There are quite a few older style LCDs, mostly monochrome, but I will likely opt for something newer which has color. 8-bit parallel LCD interfaces tend to be very similar, physically at least, so I don't feel too bad about using a modern panel because I can always switch it out to something ancient whenever I like with minimal code changes.

    The issue of the keyboard is a different story. I looked around to see how other 68k family boards work with keyboards, but I really couldn't find much. Most newer 68k designs end up using a microcontroller such as an Arduino to feed the keyboard data into a UART. Besides not being retro, such a solution is also not very elegant in my opinion. It is an easy solution, however, but I'm not too keen on easy. What to do?

    As luck would have it, I stumbled across an old Intel N8042 in my vast collection of deadtech. Intel and Motorola on the same board? Yeah, this is pushing all of my buttons... it needs to happen.

  • Timer interrupt working!

    Jason Westervelt12/20/2015 at 13:23 0 comments

    After discovering another mistake in the original application note, I resolved the issue with _IACK generation and the MC68901 came to life on the timer side. Unfortunately with an 8-bit timer, it is really unlikely that I'll get the accuracy needed for timekeeping, but I can do some basic multitasking now.

View all 16 project logs

  • 1

    Constructing the system by following Motorola's Application Note 1015 will be sufficient, with the exception that the schematic is missing 2 external connections on the MC68901. One of the timer outputs TCO or TDO needs to be tied to TC (transmit clock), and the remaining timer output needs to be tied to RC... otherwise the data sent to the USART data register will never be shifted out to the transmit buffer... ooops!

    Also, with regard to the GAL implementation (done in CPLD in my case), the Motorola application note refers to A00, A01, and A02 with regard to _IACK generation. This is not correct, as the CPU will set the IPL to be serviced across A01, A02, and A03 with A03 being MSB. This delayed me by about 1 hour and 24oz of Red Bull.


    Once I consolidate my CPLD constraints file, I'll post that on github as well. This will allow others to load my .xsvf into a comparable CPLD and wire it correctly to the CPU and peripherals. **constraints file uploaded

    For software, the BIOS .x86 file is in the Motorola format and can be assembled with vasm. I use the following command: vasmm68k_mot -m68020 -Fbin bios.x68 -o bios.bin

    S-Record output is also possible with vasm. The code should work on any 680x0, as long as the processor has a vector base register... otherwise you'll have to shuffle things around. The simple way is to make the ROM respond to read requests at 0x00000000 and 0x00000004, but then remap the RAM to start at 0x00000000 after the first two reads. This is a pretty basic trick, and plenty of examples exist online.





View all instructions

Enjoy this project?

Share      

Discussions

ceneblock wrote 01/10/2017 at 18:11 point

What are you using to program the XC95108? It'd be nice to grab one, may my own programmer, and include it that way.

  Are you sure? yes | no

Tobias Rathje wrote 02/04/2016 at 20:03 point

Found your project when I was searching for information about the free running mode of 680x0. This is really great! 

I am trying to build more or less the same thing as you, just with a 68030, and I can see that I am basically following your footsteps. I would really like to try your ROM monitor whenever I get that far. 

Right now I am just trying to collect the various bits and pieces, and one of the next steps would be to try the same free running setup to see if I have a functional CPU.

I am looking forward to see how you progress.

  Are you sure? yes | no

Jason Westervelt wrote 02/04/2016 at 20:58 point

I have been hella busy the past 3 weeks... sadly I haven't been able to work much on this project since moving into a new home and doing some repair work on my Jeep are taking precedence.  

The ROM monitor should work on any 680x0 as long as it supports the vector base register, so it should work on the entire family except for the 68000, 68008, and 68010 I believe.  A minor re-write would be needed to eliminate the need for the vector base reassignment.  I simply chose to have my ROM start at 0x00000000 for simplicity purposes.

The 68030 needs a few changes to the overall system design, such as generating the STERM* signal.  Implementing the necessary changes is quite trivial, however.  

This project is documented well enough that I could consider it complete.  I do need to change my CPLD code so it is all defined as FSMs within Verilog... the current implementation is using schematic input which doesn't lend itself to documentation as easily.  The VME bus board is being split into a separate project, and this project will undergo one more design change to convert it into a standalone board which can also plug into the VME board.  Once that is done, I'll run off a PCB and, provided there are no issues, I'll post the board files online.

Following that, I plan on reusing my VME board while designing new daughterboards based upon the 68040 and possibly the 68060.  I will likely just jump into the 68060 first.  There is practically zero information on minimal systems involving this processor, so a lot of it will be trial and error.  I'm challenge-driven, so getting started on that project is very high on my priority list.





  Are you sure? yes | no

jaromir.sukuba wrote 12/16/2015 at 12:40 point

There is not much working projects with 68k CPUs around, this one is IMHO really nicely executed. 

What are your plans regarding the software? Do you have some favorite piece of software you'd like to see running on it?

  Are you sure? yes | no

Jason Westervelt wrote 12/16/2015 at 21:20 point

Favorite piece of software?  Well, eventually I will get linux booting, one way or another.

I want to take a stab at hooking up one or two of my old C64 SID chips and see if I can write a simple music player.  

  Are you sure? yes | no

Matt Bettcher wrote 12/14/2015 at 01:45 point

@Jason Westervelt I want to end up with a quality pcb based design at the end of my build. I hadn't thought to much about 5V tolerant FPGA being difficult to find. I may end up with going with a CPLD just because of that fact. I don't plan on using an MMU, but I do plan on including an 882 fpu and trying to interface a 72 pin SIMM so I can have lots of ram. I plan on implementing the DRAM controller in my glue chip if possible. I'm not going to support FPM or EDO so it should be fairly cut and dry. My plan is to use SRAM for however I design my video card. My goal is to have 640x480x8 VGA output and have the frame buffer located somewhere in the memory map and easily accessible. I may try for something more complicated once I get a basic frame buffer working. And I need to make sure the video part of my computer is separate. I may end up with just the main computer and a good sized connector on one side for when I design the video card. Overall I want mine to have the same outside style as the Kiwi 68k, the computer under/behind the keyboard with most ports on the back. So I will try to design my computers pcb around this end goal.

  Are you sure? yes | no

Jason Westervelt wrote 12/14/2015 at 03:23 point

Then it sounds like we have very similar end goals.  I'm planning on making a 68020 version of the Kiwi 68k, but this project is just to make sure I understand the basics so I can quickly identify what needs to be altered from a hardware and software perspective.

  Are you sure? yes | no

Matt Bettcher wrote 12/13/2015 at 01:06 point

This project is awesome! I am working on a 020 with an 882 fpu. Please let me know any tips or tricks you used or found to get your system running.

  Are you sure? yes | no

Jason Westervelt wrote 12/13/2015 at 04:49 point

Well... I guess it is better to ask where you are getting stuck.  I have an FPU and an MMU, and I plan on hooking them up as well...  I'm doing this project to learn, but I also want to help people get started.  Once I get the board to an improved state on an actual circuit board, I'm thinking about running a bi-weekly or monthly series on youtube where I ask people what they want to see interfaced with the 680x0 architecture, and then implement it to the best of my abilities.  

  Are you sure? yes | no

Matt Bettcher wrote 12/13/2015 at 15:41 point

Well I'm still in the early design stages. I kind of want to go with a back plane design, but after seeing your wire wrap prototype running I feel like I should start there. I really want a decent FPGA as my glu so I can rapidly change fix things without having to reprogram a CPLD every time. I figure I can achieve this by running the system clock out of the FPGA, basically it will control all timing. I'm also looking at 72 pin simms as my ram. So my FPGA will need to handle all the ram signals. I was looking into an MMU, but I think I should stick with a flat memory model. I have no intention of being able to run linux on my computer. Only custom software.

  Are you sure? yes | no

Jason Westervelt wrote 12/13/2015 at 19:43 point

@Matt Bettcher Couldn't reply to your comment directly for some reason...

Every prototyping method has its pros and cons.  With soldering and wire-wrap, and even bread-boarding, you have to measure/cut each wire and strip insulation for each connection.  It is this measuring/cutting/stripping aspect that takes the most time with respect to wire wrap.  

The nice thing about wire wrap is that when you have a bunch of ICs tightly packed, you can make connections easily without neighboring connections getting in your way as would happen while soldering.  

The not-so-nice things about wire wrap is that you'll need wire wrap sockets and you cannot simply re-use a wire once you've un-wound it and released it from a prior connection, you have to undo both ends and replace that wire completely.  Sockets for standard IC footprints are cheap and easily found.  Wire wrap sockets for PLCC/QFN packages, not so much.

My current board is a compromise because I didn't have the wire wrap socket for the CPLD.  I instead stripped a very small amount of insulation from one end of my wire and pushed it into the same hole as the lead from the CPLD's socket, then soldered both in one go.  The result is a wire which is wrapped on one end and soldered on the other.

Breadboarding on the whole is the fastest and easiest method, I feel.  The issue, however, is that the layout of the breadboard requires significant spacing of your ICs, and you'll have to build adapters for anything not in a SIP/DIP package.  

FPGA may be the way to go.  I avoided FPGA because I couldn't find any that were 5V tolerant, and I didn't want to resort to using buffers to deal with the issue.  I chose this part because in addition to being 5V tolerant I/O, the core takes a 5V supply and thus I have no need for a separate power supply.  My board has an ICSP header for the CPLD, and in all honesty, it only takes about 60 seconds to reprogram the thing.  I have an Arduino Mega as my programmer, so it is a lot slower than it could be with a proper programmer.

For reference, I'm using the JTAG arduino libraries found here: http://eeandcs.blogspot.com.br/2015/08/jtagxsvf-library-for-arduino.html 

  Are you sure? yes | no

J. Ian Lindsay wrote 12/11/2015 at 18:46 point

In case of apocalypse, you will be the last man alive with a working computer. :-)
Seriously: cool build, man.

  Are you sure? yes | no

Jason Westervelt wrote 12/11/2015 at 20:33 point

Nah, lots of people here have homebrew computers... I'm just coming to this party about 30 years too late.

  Are you sure? yes | no

K.C. Lee wrote 12/10/2015 at 11:33 point

I usually have the bare minimum code to download S record/Intel hex to ram, "go" command in a ROM monitor.  Every thing else in the monitor can wait as I want to get pass those EPROM erase/program (aka burn and crash) cycles ASAP.

  Are you sure? yes | no

Jason Westervelt wrote 12/10/2015 at 12:06 point

I must have phenomenal luck... I haven't crashed yet, just got garbled data due to errors in my RAM dump branching and hex->ascii conversion, but the thing has never gone unresponsive on me.  :)  Helps that I have 4 ROM chips though, I don't have to wait for the UV erase (yeah, I need flash ROMs...)

I have the ability to dump memory now.  Tomorrow I will work on code to "run" or "go" as well as code to enter data into memory.  Not sure how best to implement a load function over serial... guess I'll start looking around online for examples.

  Are you sure? yes | no

Yann Guidon / YGDES wrote 12/10/2015 at 23:27 point

Awesome :-)

  Are you sure? yes | no

K.C. Lee wrote 12/11/2015 at 13:03 point

I wrote some ugly C code that read Intel hex on the fly using polling serial for Z8, Z80 and 8051.  These microcontroller managed to keep up with the ASCII upload on the terminal program without hardware/xon-off handshakes.  I don't use that terminal program nor remember what it was called as it was a long time ago before my PC upgrade.

My C code for Z80 here:

https://hackaday.io/project/7700-collection-of-misc-small-project/log/28951-old-intel-hex-loader

I used an assembly stub to jump to memory location as C only do calls to function pointers.  (A decent compiler would have translated a tail end call to jump.)

I have Motorola S record parser for my EPROM programmer, but it was untested.  These file formats are pretty easy and would only require minor code change.

  Are you sure? yes | no

Jason Westervelt wrote 12/09/2015 at 23:57 point

I had this old 020 laying around collecting dust and decided to finally do something with it.  I previously built a free-running board with the processor and just turned it into an LED blinker.  

I gave thought to building my first computer with an 8-bit CPU like a Z80, but I opted for something more challenging.  

Ultimately, I'm going to be building a Kiwi clone with an 040, but I plan on using this system, likely on the next board revision, for testing code.



  Are you sure? yes | no

Matt Stock wrote 12/09/2015 at 23:46 point

This is neat.  Prior to deciding to do something completely custom, I had thought about a design centered around the 020 or 040.  I look forward to seeing how this develops.

  Are you sure? yes | no

Similar Projects

Does this project spark your interest?

Become a member to follow this project and never miss any updates