Close
0%
0%

hexahedron

An open-source minimalist 68030 based VMEbus computer

Public Chat
Similar projects worth following
hexahedron is a minimalist Motorola 68030 computer based in part upon Motorola's Application Note ANE426. a set of CPLDs will be used for all glue logic. it is a successor to the rhombus project that i previously worked on.

the goal is to reuse my existing ROM monitor from rhombus and allow the board to become a useful development tool; serving as a platform for learning m68k assembly, VME bus operation, as well as peripheral card development. as this CPU has an MMU, i am expecting to eventually boot linux on it.

as with rhombus, i looked for open-source projects based upon this processor and found limited information, especially when leveraging the full 32bit data bus to interface with ROM, RAM, as well as the VME bus. 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.

high level overview:

  • main system board will be developed in a modular fashion
  • modules will be developed in stages
    • first stage will be a wirewrapped prototype
    • second stage will be a PCB with debugging headers for wirewrapping
    • third stage will be implementation into an all-inclusive mainboard
  • each module will serve a function (such as CPU initialization, bus arbitration, etc)
  • each module will be documented so other hobbyists can replicate the effort

design decisions:

  • controller board specs:
    • VME bus card, 32bit
    • MC68030 33MHz CPU
    • MC68881 or MC68882 FPU (MC68881 currently on hand)
    • MC68901 multifunction peripheral
    • 32MB zero-wait state SRAM
    • 4MB ROM
    • Both ROM and SRAM to utilize full 32bit data bus
    • CPLDs for glue logic
    • Utilize user-defined pins on the VME P2 connector for extra functionality
      • ICSP
      • CAN
      • SPI / I2C
  • PS/2 keyboard interface (probably using the N8042AH i have laying around)

    in addition to the main controller board, i plan on building several peripheral boards:

    • DRAM
    • SCSI
    • Sound (I have 4 MOS 6581 "Sid" chips laying around, could build a stereo synth card)
    • Video (likely with an FPGA)
    • Floppy disk controller

    • build log 7 - SRAM / ROM / serial

      Jason Westervelt01/08/2022 at 14:34 0 comments

      512KB 55ns SRAM added

      512KB ROM added

      MC68901 Multifunction Peripheral added

      The CPLD at the top is a 7ns part and is tasked with address decoding and chip select generation.  The CPLD on the lower right is handling the VMEbus signal synthesis and is additionally dealing with the interrupt signals.

      Initially I had concern that the CPLD would not be fast enough for address decoding, but it seems to be doing the job.  My logic analyzer only runs up to 500MHz, so 2ns is my resolution, but the CPLD is driving the chip select low within 2ns of the address strobe being asserted.

      In this capture, ADDR3 through ADDR 15 is attached to A19 through A31 on the CPU.  CSEL 0 is ROM and CSEL 1 is the MFP chip select.  As expected, the CPU transitioned from asserting ROMCS to asserting MFPCS when A19 went high.  The time between /AS being asserted and MFPCS being asserted was within 2ns.  The only think keeping me from running this thing at 0-waitstate is the fact that my pokey SRAM is only 55ns.  I have faster parts on hand, but i will need to make a PCB for those as they are surfacemount components.

    • build log 6 - ROM, basically

      Jason Westervelt12/24/2021 at 07:50 0 comments

      my apology for lack of updates... got a million things in flight IRL at the moment and very little cache to deal with them all...

      i needed to get ROM and SRAM attached to hexahedron, so i built a wirewrap adapter for the PLCC44 ROM that I have.  around that point, i realized that my ROM programmer is only good for 8-bit ROMs.  No problem, I can build an adapter...

      T W O   H O U R S   L A T E R


      I threw a test pattern at it... 0xAA55... and it worked... GREAT!

      ...or not.  When I decided to fill the thing with `0x00000000`, you know, for that sweet `ORI.B #0, D0` free-running code, i realized that it was returning 0x80408040.  obviously two of my data lines were not properly connected.  after throwing another half pound of solder on the back of the adapter, all was well...


      unfortunately, now i have to handle a few non-maskable interrupts in real life, so i won't be able to test the free-running from the ROM until tomorrow.  i will, however, share the schematic in a few minutes showing my idea for jumperless IO base address configuration.

    • build log 5 - unorthodoxy exemplified

      Jason Westervelt12/14/2021 at 05:58 1 comment

      currently programming the PLDs for the system. while doing so, i started thinking about how i wanted to handle the memory-mapped IO, and how to remap peripherals.  sure, i COULD do it old style and use jumpers to set a comparison address on a 74F521, but that seems entirely too pedestrian for this project.  i like the idea of setting things in BIOS, interactively...

      ...the problem is, HOW?

      seems like there are plenty of motherboards that I have owned, even back in the 80386 era, that were jumperless and permitted changing the base IO address of serial and parallel ports.  i never really looked into how this was accomplished.  this isn't really something that is easily searched for either, and no magic combination of search terms led me down a path to illumination.

      so, i decided to get creative...

      hexahedron will boot up with ROM at 0x00000000, but this can cause issues with linux, issues which have workarounds, but issues where remapping the base IO of ROM will be useful.  the ROM that i have on hand is a 4megabit (512KB) HN27C4096CC-12, an aesthetically pleasing piece of silicon for sure.  the idea is to have a 74F521 attached to 8 lines of the address bus for each peripheral (RAM, ROM, serial0, serial1, parallel, etc).  instead of front loading these with jumpers to set the identity address, i will be using 74LS164 shift registers... shift registers and a microcontroller.

      the microcontroller i have on hand is an ATMEGA328P.  it will have it's own 74F521 and 74LS164 as well.  it will have one line running out to gate each of the 74F521 outputs, except for ROM, which will be on its own dedicated pin which will be asserted (LOW) at power-on.  at power-on, each of the 74LS164s should have their outputs = 0x0000,  but only ROM will be enabled so the CPU will start reading from ROM as it loads BIOS.  meanwhile, the microcontroller will run through its own internal program, reading the base IO address stored in EEPROM for itself and each peripheral.  by default, the MCU will have 0x80000 as its base address, residing just above the ROM. it will then serially clock in data to its own shift register so it will match on 0x80000, and then it will proceed to do the same for the other peripherals.  once they are all set, the MCU enables output on the non-ROM ID comparators.

      the CPU will then contact the MCU at 0x80000 and request the peripheral base IO addresses stored in its EEPROM to  update its own state.  at this point, the user is free to remap the base IO address for anything by sending commands to the MCU, eventually disabling the ROM and remapping RAM to 0x00000000 should the need arise.

      at this point, some people are either facepalming over my overcomplication of matters, or amazed by this implementation.  maybe i'm doing something that is actually sane.  i don't know, but i have to try it at this point.   feel free to chime in if you have insight as to how jumperless motherboards actually work on commercial gear.   

    • build log 4 - VME basic connectivity

      Jason Westervelt12/12/2021 at 13:33 0 comments

      in this build session, i rewired the entirety of the computer, primarily to relocate the CPU module and make room for the bus transceivers.  most of the other systems that i have seen are using 74LS645s for the bus transceivers, perhaps because they can sink more current.  from a previous conversation on my rhombus project, it was mentioned that up to 64mA would be needed.  i do not have 74LS645s on hand, however the 74F245s that I have will sink that much, with the caveat that it is the B port, not the A port.  as a consequence, i have the CPU attached to the A side and the bus attached to the B side.  this will require inverting the chip enable logic, but seeing as this will be handled within my CPLD, i suspect that it will not be an issue.

      speaking of the CPLD, after obtaining an XC9536XL, my programmer worked just fine.  the only issue here is that i'll need a 3.3V supply for the CPLD's main source, but the I/O is rated to handle 5V.  

      video 1: overview of current state

      video 2: added the address lines A24-A31 to the bus and added LEDs to visualize the activity

    • build log 3 - revenge of the part obsolescence

      Jason Westervelt12/08/2021 at 17:09 1 comment

      i am rethinking a few things regarding this project.  i would prefer to use programmable logic, but i would also prefer to avoid using level shifters to deal with the 5V logic on the CPU and other peripherals.  the xilinx situation has been a bit of a fiasco, and i will elaborate here.

      to program the CPLDs that i have, i had to build a programmer since the one that i used with rhombus would not work.  i built 3 programmers, one of which was a parallel port design published by xilinx.  none of them worked reliably.  long story short, the newer versions of the xilinx software do not support the revision 0 silicon that i have.  i suspect that the commands are similar, if not identical, however i cannot program the CPLDs.  the CPLD has a different device id and the first 4 bits indicate the revision and are '0' instead of '2', thus the resulting .svf and .xsvf files will not work.  i attempted to modify the .svf, which is human readable, to updated the device id, and this permits the programming to proceed a bit further, but it still fails due to intermittent mismatches coming from the chip.  i triple/quadruple checked my wiring and signaling... it isn't a fault on my end.

      turns out, xilinx knows that the xc9500 series has issues in this regard, and they do not recommend using .svf format since it lacks the automatic retry capabilities of the .xsvf format.  the problem is, i cannot modify the .xsvf file to adjust the device id to match.  i COULD put some of my own logic in between the CPLD and the programmer to "inject" the "correct" device identifier in response to the initial query, but i want this project to at least be repeatable by others...

      i have an order in for some xilinx CPLDs which have a datecode from 2003 and later.  the CPLD used in rhombus was revision 2 silicon and it was made in 2002.  the CPLDs are rather cheap on ebay with a little searching, but there is no way to know what the date code is, let alone the revision, unless you contact the seller...  if these prove to be viable, i will continue with the HUGE caveat that others wishing to follow along will find that programming these chips to be a daunting task.

      an alternative would be to use a lattice part, specifically from the ispMACH 4000ZE or similar.  these have 5V tolerant I/O from what i can see, and the parts are not under obsolescence from what i can see.  i will need to grab a few and try these out as well.

    • build log 2 - CPLD woes

      Jason Westervelt12/06/2021 at 13:20 0 comments

      i have not had much time to post an update since i have been fighting a losing battle trying to program my CPLDs.  i have a half dozen Xilinx XC9536 units, and i cannot find a reliable DIY programmer/software solution.  i have a parallel port adapter wired up, but i will need to cannibalize a DB25 cable tomorrow to finish it up.  hopefully this will resolve my issue without requiring a considerable investment and a 3 month lead time on one of the officially supported programmers. 

    • build log 1 - bus interface ongoing

      Jason Westervelt12/04/2021 at 00:56 0 comments

      Currently putting the bus arbitration and data buffer/transciever boards together.  I might have another video online this evening.


    • build log 0 - free running

      Jason Westervelt12/03/2021 at 01:37 0 comments

      Free running was accomplished today and the CPU verified as functional on a 25MHz crystal.

      Photo in gallery with my oscilloscope shows the waveform on A21, whereas the LED in the video is attached to A23.  A21 (bit 22) is cycling at 5.95Hz according to the oscilloscope.  5.95 * 2^22 = 24.956MHz.

      Schematic below:

    View all 8 project logs

    • 1
      DIY wirewrap sockets

      I was unable to locate a source for the 68030 socket with wirewrap termination.  There were some sources which asked for $30/unit with a minimum of 50 units.  Needless to say, this option was out.

      As a consequence, I decided to DIY my socket.  I planned to start with single-row wirewrap machine pin sockets and cut them to length to match the footprint of the 68030.  Unfortunately, I did not have any, however I had a ton of wirewrap DIP sockets that I decided to cannibalize.  I separated the rows, cut these resulting rows to length as needed. I then pushed the pin strips onto the CPU, and then once every CPU pin had a corresponding wirewrap pin, i fed the wirewrap pins through a small prototyping board to provide structural support and to hold the headers in the proper location.  Once this was done, I carefully removed the CPU from the socket and applied some cyanoacrylate glue to the strips to cement them into place, which was probably not a required step.

      This socket is then in turn inserted into my VME wirewrap prototyping board, and the wrapped wire locks the socket into place.

    View all instructions

    Enjoy this project?

    Share

    Discussions

    Avi Cohen Stuart wrote 12/09/2021 at 10:12 point

    Very nice! I've started a 68030 project as well. The first step is indeed to have the D31-D0 at GND and see if the processor works.

    I've been using MAX II chips for my FPGA as they also run on 5V.

    The current board has EEPROM, 4MB of SRAM and the 68901. And of course a 68882.

    I've been using a TLA715 Logic Analyzer with a own made TMS203 processor probe to do all the hardware debugging. The TLA allows me with the TMS203 to see all the bus cycles including the instructions.

      Are you sure? yes | no

    Jason Westervelt wrote 12/09/2021 at 16:13 point

    I have an HP 1660A for doing debugging, and it has treated me well.

    As for the programmable logic, I also have a MAX II laying around, but I am pretty certain I looked over the datasheet and they were 3.3V devices.  Maybe they had multiple MAX II families.  :(

      Are you sure? yes | no

    Avi Cohen Stuart wrote 12/09/2021 at 16:21 point

    You're correct. It is MAX without the II...

    I'm using an EPM71640STC100-10 for the experimental board and planning to use a EPM7192SQC160-7N for a final design which will be on a 4 layer PCB.

    I bought a couple of these beauties on aliexpress before the Covid

      Are you sure? yes | no

    Jason Westervelt wrote 12/09/2021 at 18:07 point

    @Avi Cohen Stuart for some reason i couldn't reply directly to your prior comment... might be because you put the naughty "Coovid" word in there...

    *apparently you can only go two-indents deep on conversations... today i learned  :D

    I think i might try some of the XC95**XL parts... they have a 3.3V core, but apparently one can run the I/O at 5V.  If that fails, I will take a stab at grabbing some MAX components.

    The final revision will have a proper PCB, but the first revision will use socketed components that are built onto separate module boards... so the IRQ handler, for instance, will be a plug-in module.  I'll be building the modules with discrete logic as well as incorporating them into programmable logic.  While it will be a prototyping step, it also marks the end-step for those who lack PCB fabrication capabilities, so it would be nice to have such modules designed and documented for anyone wishing to follow along.

      Are you sure? yes | no

    Tobias Rathje wrote 12/09/2021 at 19:32 point

    Another vote for the older MAX7000 series. They have 5V IO and are available as PLCC. Also I have found the Quartus II software to be surprisingly pleasant to work with from a beginner point of view. The last version that supports MAX7000 devices is 13.0p1, I hope it is still available for download. 

      Are you sure? yes | no

    Jason Westervelt wrote 12/09/2021 at 19:39 point

    Thanks Tobias.  I will keep that in mind and attempt to find the 13.0p1 release.

    As an interesting note, I still have an old copy of the Lattice LeverISE and my email with the free license i had way back in the day.  Lattice apparently only has a subscription model now, but old copies of the ISE, run in a virtual machine with the system clock back-dated will work just fine. While I could go this route, I would much rather avoid supporting a company that has turned its back to the hobbyist community.  Hopefully Altera won't follow suit.  I get it that these are ancient products in many ways, but we don't exactly have modern replacement parts that are suitable in many cases.  All part of the hobby, I guess.

      Are you sure? yes | no

    J. Ian Lindsay wrote 12/09/2021 at 03:54 point

    I played Oregon Trail on that sliver of sand. :-)

      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