close-circle
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)

View all 10 components

  • What a homebrew computer can do... Fractal Art!

    Jason Westervelt07/14/2017 at 05:53 0 comments

    I was talking with my friends in Slack about writing some interesting code for rhombus since I've been away from the project for so long. This is what came out of 3 hours of coding and a couple cans of Red Bull.

    Enjoy!


  • Much needed updates...

    Jason Westervelt07/11/2017 at 20:52 0 comments

    My sincere apology for the extended delay. Job and life kinda smacked me upside the head at the same time. :/

    I decided that the original intent of this project was to make something minimalist, open-source and easily replicated by the masses. To that extent, the current state of rhombus meets those goals, however I need to do some polish on the code as well as the hardware, and do a good deal of documentation explaining how to get ROMs flashed, how to program the CPLD, etc. Ideally I'd love it if someone with minimal experience could stumble across this project when searching for something to do with an old 68020 that they found inside a laser printer or other salvage... and make something that actually works and can serve as a learning aid.

    But whilst working on this project, which has been a learning experience for me, I've thought about many things that I'd love to do with the system that I have built. Things like booting linux, which require an MMU, as well as interfacing with a bus such as VME, will take this project out of the realm of minimalism.

    The two systems will remain closely related, enough so that starting a new hackaday project would seem unwarranted. One thing that hackaday.io seems to lack is a way of versioning a project. This kinda drives my inner OCD demons nuts. What I plan on doing is splitting the project into rhombus v1 and rhombus v2, with v2 being focused on modularization and adaptation to the VME bus, as well as development of peripherals (SID based stereo sound, SCSI adapter, network adapter, etc). This should let my audience have the best of both worlds... a simple system one can build to experiment with homebrew computing, and a more complex system which can be put to use doing real-world tasks.

    All that being said, I have a board which I need to send to Oshpark. It's a full size VME board and has dimensions of about 13.5x9.5 inches. That is a $600 investment to run off a board of this size, even though I get 3 boards in return. This is another reason for the delay in my update. I've been going over this board design multiple times to make certain that it is a perfect as I can get it before sinking the money into a first prototype run. Once the board is received, populated, and tested, I'll post pics as well as documentation. I have built this board to be a generic VME interface with surface mount LEDs on every single VME line, mainly for the geek factor but also because I figure why not... I'm already blowing half a kilodollar on the board. The board will allow me to use different CPU modules, perhaps an x86 or some other architecture, and just reuse my existing VME chassis, backplane, and peripherals. Or, if somebody else wants to take a stab at a homebrew VME board for a particular CPU, they will have a nice looking mainboard to start from.

    The goals are thus pretty straight forward. For v1, I need to do code cleanup, documentation, and make the hardware a bit more tidy. For v2, I need to get this board sent off, then get it into my VME chassis and tested. Once that is done, I will start focusing on v2 and take suggestions from the community as to what peripheral to build next. I have great interest in building just about anything related to computers, and I am certain that whatever is suggested will serve as a learning opportunity for myself and others.

    Additionally, I have noticed that hackaday.io has added a file attachment space for each project, so I will work on adding resources from my github.com account here locally.












  • 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

View all 18 project logs

  • 1
    Step 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

legacy wrote 07/21/2017 at 17:44 point

hi

can i see your schematic and CPLD files ?

  Are you sure? yes | no

Jason Westervelt wrote 07/21/2017 at 21:32 point

I could certainly put together a schematic, although as stated in the project description, it is built according to Motorola AN1015.  You can use discrete logic for this, or use a CPLD, provided it is 5V tolerant.  I have provided the cpld flash binary on my GitHub as well as the .ucf file which gives the pin designations that I have made.

Truth be told, I am redoing all of the CPLD project files so as to remove schematic programming. 

  Are you sure? yes | no

legacy wrote 07/21/2017 at 23:01 point

I'd like to see vhdl or verilog as well a schematic where (and details about) the CPLD is connected to the CPU. I have a different project in mind, so I am not interested in replicating yours.

  Are you sure? yes | no

Jason Westervelt wrote 07/24/2017 at 05:51 point

I've added the Xilinx project files to my github, as promised.  I still need to clean up the files and convert the schematic bits to VHDL.  I'm also going to update the interrupt bits since currently IPL0 and IPL1 are tied to Vcc via the CPLD, making it unable to detect anything other than devices operating as INT4 (currently the UART).  I want to add a debounced push- button NMI so I'll need to get IPL0 and IPL1 properly implemented.

I'll also post a complete schematic once I get a couple of hours to work on it in KICAD.

  Are you sure? yes | no

Greg Kennedy wrote 07/07/2017 at 22:03 point

I've been searching for a few days for a good 68000 disassembler that runs on a Windows machine.  Do you have any suggestions?

  Are you sure? yes | no

Jason Westervelt wrote 07/07/2017 at 22:06 point

DISassembler?  No, I don't go that direction... :)

There is an online one here : https://www.onlinedisassembler.com/odaweb/

There was a link to a program on easy68k, but seeing as how I am not a windows guy, I cannot recommend running any binaries on that platform.

  Are you sure? yes | no

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

Jason Westervelt wrote 07/07/2017 at 22:10 point

I'm programming it using Xilinx's tools... as rough as they are.  I just built a programmer out of an Arduino to interface it to my PC.

  Are you sure? yes | no

Matt Lacey wrote 07/11/2017 at 05:42 point

I need to double check what I purchased (think I got the same CPLD so that it's 5V tolerant) for my 68k project, but don't you need a licence for those tools? Seemed a bit too much like bother, but would be useful to not have to worry about logic level translation. 

  Are you sure? yes | no

Jason Westervelt wrote 07/11/2017 at 19:58 point

I believe that the older versions of their ISE are free to use for non-commercial purposes.

I am starting up development on this project again so I can report which version of the ISE I have once I get my build environment back online.

  Are you sure? yes | no

Jason Westervelt wrote 07/24/2017 at 05:56 point

I had to reinstall Xilinx's tools on my new laptop, and have some additional details.

If you download the Xilinx ISE 14.7, when you install it will give you the option to select the WebPack installation.  It will ask to generate a perpetual license, but there is no cost to do so.  So while their ISE is free from monetary standpoint, it isn't free of IP burdens.

I've added my project files to my github, but honestly they are more of an example of what NOT to do... I did that work 18 months ago and I knew almost nothing of VHDL at the time.  :D  Still learning, to be honest.

  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

Jason Westervelt wrote 07/24/2017 at 21:56 point

Will do.

I'm already starting on my 68030 board, and like this project, I am using wirewrap for prototyping.  I didn't feel like dropping $35 on a 68030 wirewrap socket and waiting 2 weeks for one to show up, so I just made one myself.  :)



I will probably have some questions for you when it comes time to try throwing linux at the 68020 or the 68030.  I need to wire in the MMU for the 68020, and I figure I will probably just start with the 68030 since the MMU is internal.  Once I am done, I'll have CPU/RAM/ROM/UART SBCs with a common header that will connect to a VME interface board.  As long as the binaries are compatible, which would be the case with the entire 68K lineup, I can just swap the SBC module and keep my other peripherals such as SCSI disk, parallel port, sound card, video card, etc. in place.  When I get around to building an X86 system, I'll just need to swap out the operating system storage (or have an X86 install on a separate partition)

  Are you sure? yes | no

Jason Westervelt wrote 07/14/2017 at 17:49 point

I saw your project, seems pretty amazing.  I will eventually do an 030 project, but I want to try getting the mmu interfaced and boot Linux on this thing first.  Looks like you managed to get Linux loaded up, so I'll probably look to see how you did the loader.

  Are you sure? yes | no

Tobias Rathje wrote 07/24/2017 at 19:43 point

Thanks. Happy to see you're working on Rhombus again. I hope you can use some of the stuff I have published. If you have any questions, just let me know.

  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