68010 custom computer build

[paulca]

So I think it's about time I got round to some hardware design again.  I've played around with this CPU in FPGA simulation for nearly a year now.

Part of the trouble is the first step seemed huge, probably because I was looking at a near complete design in Verilog/HDL.

So, last night I picked the simplest starting task and went with it.

I had a foam pad full of 8Mhz xtal cans from AliExpress.  Do they even work?  Not exactly a difficult task.  I did mess it up though.  Killed to xtals until I worked out I had them wired wrong.  The classic "bottom side view" visual pin mapping problem.  Once I had one wired up right I got the confirmation on the scope.  8.0002Mhz +/- "a bit" - nothing the 68k will care about.  Something like a 60Mhz inductive ring with overshoot, but that is to be expected  with a can on a breadboard.  Again 68k "probably" won't care about a 0.3V overshoot.

Task complete.  So while I had the desk powered up I added the 68010 (genuine 1990s IC reclaimed stock) to the breadboard.  Powered it, fed it clock and turned it on.  150mA spike down to 100mA.  "Normal".  I did add some LEDs to the databus and FC lines, but without the full databus pull down its going to read mosfet noise/random.  FC0/FC1 flickered breifly and stopped.  Also expected behaviour.

I pulled RESET/HALT low and powered up the CPU, then released them and it did respond.  Once it even put something on the databus at one point.  Then died again.

Next task is to 'free run it' just need to pull the databus low and DTACK low - and a basic pull up/down on most inputs.  The milestone I am aiming for is an Arduino MEGA (slow) puppet rig.  Just to go through the bus cycle with "DTACK stepping" and some "inline" static opcodes in puppet rig memory.

Puppet rigging:

Actually trying to think that part through in terms of memory.  The MCU has the ability to rewrite the address space, but it sadly has very little in terms of RAM.

"Code" can go into the flash, where I have 256K total to play with.  The 8K of RAM probably allows me to easily allocate maybe 4K of RAM.  I need minimal RAM to be a bus slave, but I do want a UART output and I need it to be async to the "address strobe" interrupts, so it needs buffers.

Still need to brush up on the Arduino interrupts again, but I am hoping I can have a "rising and falling" edge detection...  if I can't then I will just hot loop it myself.  On address strobe falling "Bus cycle start".  On address strobe rising (in response to DTACK) "Bus cycle end" - "Print bus to UART" - "Press a key to continue..." - release DTACK.

To be honest the "Hot loop" might just be fine.  I need to revisit the behaviour with the Adruino UART driven from interrupts but even if that doesn't work out, or the lack of DMA makes it pointless, I should still have budget for a multiplex loop of "Send UART char, check AS".  The tighter timing part is the release of DTACK.  The CPU will wait on DTACK forever, but once it releases AS the cycle is over and it will start another one very shortly.  Needs AC timing analysis to see what my budget is.  Again, a work around, if I can't respond fast enough to AS-rise I can "Yolo delay loop it".  Assert DTACK - count to N - Release DTAK - Hope.

The actual ASM code will just be a bootloader which loops through an array with ASCII "Hello World" in it.  I can read hello world in binary ...I think.

[paulca]

Still need to confirm the figures as they came from a bot, but... it would seem the worst case budget for DTACK release after AS goes high is 500ns.  However, the AVR asm to SBIS skip if bit set, and the tri-state two ports and lift DTACK all come to about 440-500ns.

Thats ASM instruction "golf".

Probably not wise.  Event a few ns of overlap on a bus write from the CPU will create current spikes on the pin mosfets and cross driving.  Even if the timing is close to perfect, capacitance will round edges and cause issues.

The bot is suggesting using a bus driver or 74HC245 with it's drive enable gated with AS so it always tri-states when AS goes high regardless of what the ATMega is doing.

The other option is to use a flip flop.  Arduino pin "clears" and AS "sets" DTACK.  So the "Assert" is in Arduino code and the release is in hardware.  "Clock ... could just be the 8Mhz clock?"  - not sure a 74HC flip flop will like that clock, but I can just fake the clock pulse.

[brucehoult]

So, last night I picked the simplest starting task and went with it.

How about use mild pull-ups and pull-downs to make the data bus always read 4E71 and then just watch the address bus count?

I've used a Mega2560 to puppet 6502 and 6809. Pretty easy. 68k has more pins of course.

You know you can bump the Mega2560 RAM to 64k total using an external RAM (and a 74HC373)? That does tie up the whole of Port A and Port C plus pins 39,40,41 on Port G. Still leaves you with 6 full 8 pin ports though.

[paulca]

So, last night I picked the simplest starting task and went with it.

How about use mild pull-ups and pull-downs to make the data bus always read 4E71 and then just watch the address bus count?

I've used a Mega2560 to puppet 6502 and 6809. Pretty easy. 68k has more pins of course.

You know you can bump the Mega2560 RAM to 64k total using an external RAM (and a 74HC373)? That does tie up the whole of Port A and Port C plus pins 39,40,41 on Port G. Still leaves you with 6 full 8 pin ports though.

Instruction $0000,0000 - ORI.B D0,$00 - OR immediate with (D0, $00 operands).

So it basically just cycles anyway.

If address $000000 contains $00000000 (4 words) and address $000004 also contains "0".  Then the stack pointer is set to 0, the bootstrap entry point is set to address 0.  As long as nobody touches the stack everything will be fine.  The 23rd bit should have a period of about 2 seconds.  I have a strip of 8 LEDs to get a light show.

On the puppet rig.  Expanding the memory sounds painful.  Especially considering how cheaply I could "filter" some address bits to map that to a real memory IC on a breadboard.  It's the same number of wires to pin out.  I have got compatible nor flash and SRAM ICs in a box.  Just not very much.  2x32k SRAM chips is 64K of RAM and 2x1Mbit NOR Flash 8 bit chips = 256Kb of ROM.

By that point though the arduino starts to look like a rather excessively rubbish MMU.... although it could easily migrate to being a UART controller.

[brucehoult]

Sure in this application you can almost as easily completely manually drive the external RAM.

The advantage of the built in facility is that it's completely transparent and just 2 clock cycles (1 extra) to read or write the external RAM [1] vs I guess 5-10 to manually read/write all the ports.

although it could easily migrate to being a UART controller.

Yes, I reserve a location in the MCU address space for stdin/stdout.

[1] or you can add 1 or 2 wait states if your RAM or the 74HC573 needs it

[paulca]

Beyond mickey-mousing the CPU on a breadboard I still have a bit of a "field of options" and still haven't picked were to go yet.

Physical 68010 is 5V.  I can get 5V 74HC gates and 5V SRAM and Flash ROM.  Thats not a problem... much.  It starts to hurt a little though when you introduce "boot loaded memory map gymnastics" required to make the "0 page" writable or if you want a "Unified RAM" model where ROM is copied to RAM on boot.  That requires latched address rewrites to map ROM somewhere else or out entirely.

Its not hard to design, I had it working in a few days of FPGA fiddling.  Its when you transcribe it all back out, along with the "*DS" data strobes et. al and are looking at placing and routing 12-14 logic ICs it starts to hurt.  Its not the effort creating it that worries me.  It's that number of ICs and a rough "estimated" error rate on my part is far too many to expect anything but failed PCBs and long debug sessions.

So the obvious solution is to just slap an FPGA onto the board instead of the sprawl of logic gates.  Then the age old 5V/3.3V issue demands an array of level converter bus-trans and open-drain shifters.

I'm still "picking my poison" lets say.

Two FPGAs.  One running a softcore, one running the "FSB" IOMMU fronting ROM/RAM/IO sounds great... but that has the draw back of finding or adapting a 68k soft-core to support the 68010 instruction restartability.

EDIT:  That later feature - restart instruction on bus fault is not going to be a problem for me for a LONG time into the OS design.  I can just implement a bus errror as a "KILL" and terminate the process.  The only real feature that prevents is dynamic paging, disk paging and auto allocation (for stack say).  I think I might just go with the dual FPGA and the fx86k soft core.  That gives me a LOT of flexibility.

[brucehoult]

What is the actual long term goal here?

[paulca]

What is the actual long term goal here?

Tinker.  Learn.  Discover.  Build a computer from first principles, following loosely the historical pain points.

Writing an OS having designed the hardware to support it.

The Z80 build got completed prior.  It got 'ended' by "Multi-tasking" being the next historical milestone and for that I choose to skip ahead to where the CPUs actually support virtual memory addressing properly.

[pqass]

The other option is to use a flip flop.  Arduino pin "clears" and AS "sets" DTACK. 

I made a ROM emulator (see attached) that uses a D-FF to introduce wait states until an Arduino feeds the next byte then releases the D-FF.   I initially made it for a breadboard 8085 but also works for a 68008 or any board with /WAIT (or /DTACK w/ N-FET gate on D-FF pin 6), /RESET, and /MEMRD.  Wait can be asserted indefinitely until released. 

It works by gating the /MEMRD line (via OR gate) so the emulator takes over all RAM reads (disables existing RAM for reads but NOT writes).  This allows the emulator to send any opcodes like the following to write into RAM, then resets the CPU but with /MEMRD working normally.

Set the start address:     movea.l #0xXXXXYYYY, %A0
Then for each byte to write into RAM send:    move.b #0xXX,(%A0)+

The BOOT PROCESSOR in the attached is an Arduino UNO that has a command processor that accepts an Intel hex line that will execute the above opcodes to write the line into RAM.  I used this setup to get acquainted with 68K assembly (was new to it) and before I knew how to write to flash ROMs.  It allowed me to develop a monitor program that I now have on flash ROM.

Using a D-FF and /DTACK, you can interrupt an Arduino (or other MCU) to respond to I/O requests mapped to its own memory space (rather than disabling RAM).  If I recall it takes a couple of microseconds for an ATmega328 @16MHz to respond to an IRQ.  That would represent 4 machine cycles (or 16 clocks) delay for a 68K @8MHz.

[Benta]

Beyond mickey-mousing the CPU on a breadboard I still have a bit of a "field of options" and still haven't picked were to go yet.

Physical 68010 is 5V.  I can get 5V 74HC gates and 5V SRAM and Flash ROM.  Thats not a problem... much.  It starts to hurt a little though when you introduce "boot loaded memory map gymnastics" required to make the "0 page" writable or if you want a "Unified RAM" model where ROM is copied to RAM on boot.  That requires latched address rewrites to map ROM somewhere else or out entirely.

-------------

EDIT:  That later feature - restart instruction on bus fault is not going to be a problem for me for a LONG time into the OS design.  I can just implement a bus errror as a "KILL" and terminate the process.  The only real feature that prevents is dynamic paging, disk paging and auto allocation (for stack say).  I think I might just go with the dual FPGA and the fx86k soft core.  That gives me a LOT of flexibility.

1: Please explain "mickey-mousing".

2: don't even think of using 74HC in a 68010 system. 74HCT is mandatory. Ask me how I know...

3: A bus fault is no problem in a 68K system. In fact, it's a regular occurrence. But you need to write an exception handler to deal with it (swapping in a new page etc.). A double bus fault is catastrophic, because it means your stack doesn't work.

[paulca]

Thank you for the heads up on HC/HCT and the TTL/CMOS incompat.

Thankfully I did check before proceeding and indeed my chips are NMOS and so... TTL and weak as piss with no snot at all to compensate.

VOH is only "2.4V" and VOI only 400uA  for "most lines".  Ouch. 

Not least does this cause TTL-CMOS issues for interfacing, but you can forget putting LEDs on the bus as with much short of a 10K series resistor it will pull the depletion gate below 2.0 and crash the bus entirely.

However.  I need to explore level shifting things anyway and "Bus transcievers" I have a strip of.  Dual voltage ones.  However, the LS74LVC16T245V and variants have compatible VOL/VOH levels IF it's run at 3.3Vcc.  So the 68k is 5V and it's bus is "barely 5V reliably 2.4V", but the LVC VOH at 3.3V is 2.0V  so a match.  More importantly it's inputs are tolerant all the way up to 5.5V.

This solves many a problem out of need of the first.  Forcing me to "buffer" the bus to not load the NMOS chip puts me into a "3.3V master voltage" scenario anyway.

[David Hess]

Thank you for the heads up on HC/HCT and the TTL/CMOS incompat.

That leaves logic families with TTL compatible inputs, including HCT, AHCT and ACT for extra speed, and of course the various bipolar TTL families.  CMOS logic families with a supply voltage of 3 or 3.3 volts should work, but I seldom see this recommended.

The 68010 datasheet says 1.1 kilohm pull-ups are supported allowing outputs to achieve at least Vcc-0.75 volts with a reasonable load, so it is not out of the question to drive a 5 volt CMOS input.

Not least does this cause TTL-CMOS issues for interfacing, but you can forget putting LEDs on the bus as with much short of a 10K series resistor it will pull the depletion gate below 2.0 and crash the bus entirely.

LEDs should be active low, meaning connected to the positive supply with a series resistor and then the logic output pulls the cathode low.

[paulca]

The 68010 datasheet says 1.1 kilohm pull-ups are supported allowing outputs to achieve at least Vcc-0.75 volts with a reasonable load, so it is not out of the question to drive a 5 volt CMOS input.

LEDs should be active low, meaning connected to the positive supply with a series resistor and then the logic output pulls the cathode low.

Interesting.  If I understand the pullup use here, a cpu output typically has very little drive current, but can sink a lot more 1-3mA or so depending on which line/pin.  A small pull up can easily be pulled low by the CPU but when it drives "high" and hits 2.4V the pull up will pull it far closer to Vcc.... and just waste power/heat.

Im a bit ham fisted at this.  So I still want to "isolate" the fragility of the NMOS with buffers/transievers so beyond that the interface has snot and cares less if I just plug an 24 led array into a bus.

As I said, I feel crossing the 5V-3v3 boundary is inevitable going forward, so I might as well embrace it from the get go.

Which brings me to a nice bit of "project alignment".  It's been wandering around with no clear "MVP" or beyond.  So many hardware paths I could take, but all had gotcha's or costs in complexity or other. 

I think... stands to testing.. I have found my solution.  An FPGA devboard with most of it's IO banks exposed directly.... and in a form factor I can "drop" into a project, literally.  It's mounted on a laptop sized SODIMM socket.  Something like 104 IO exposed.  More than enough to make it an MMU/chipset and probably enough, at a push, for a full "dual bus" "Front side bus controller".

The MVP surfaced when I made a deciions to... for now...  limit myself to an 8 bit IO bus.  It's nice in DIY that you get to choose.... and live with it later.  4 region selects.  8 address, 8 data.  Some CTRL.  This can follow my prior ribbon cable -> breadboard breakout and allow me to continue to develop out the basic IO.  Commiting me to less complex "first PCB".

I fear if the first PCB is complex and has multiple compounding errors it could kill the motivation.  So I'm aiming to just "reuse" parts and build a "Minimal 68010 build".   more or less a clone of the Z80 arch, just expanded to more bits. Just the real 5V CPU.  Minimal glue gates.  Bus transcievers (the main test) and existing 8 bit ROM/RAM paired into High/Low.  Giving 256kb ROM and 64k RAM.   ROM exception vector table, but as it's a first memory map, that's fine, it's just a contract.

[fchk]

My recommendation: skip the 68010 and use this: 68EN360
https://www.ebay.com/itm/127264240106
Reasons: it's easier.

• You have got 4 programmable chip select outputs. After reset CS0 is always active - that is where your ROM/Flash goes. No external address decoder, no external DTACK generation. As easy as it gets. CS1 is for your external RAM. C2 and C3 are for other things.
• Built-in DRAM support
• Timers, UARTs, even Ethernet is built-in.
• You have a BDM debug port for singestepping.
• You have most of the 020 opcodes (only bitfields are missing)
• 33MHz instead of 8MHz.
• And you still have  complete 68k 32 bit address/32 bit data bus

[Benta]

68EN360 is obsolete (so is the 68010, but the OP already has them).
It doesn't support the fun paulca is looking for.

[SiliconWizard]

Yes apparently the OP wants to design around the 68010, so anything more recent is probably off the table.

For the record, the first of the series that was on a CMOS process was the 68020. That would draw less power and allow being compatible with CMOS levels, but it was still a 5V device only. Same for the later ones AFAIK (and anyway, designing a board around the 68030 or later becomes significantly more complex).

The only one of the series that I know of that supported 3.3V operation was the MC68SEC000.

Otherwise, yes, there are more recent designs with a similar ISA but those are different beasts that the OP is probably not interested in.

[Benta]

I find it totally cool that paulca is pursuing this. The 68010 is the "real" 68k that fixes the few flaws in the 68000.

[paulca]

Yes apparently the OP wants to design around the 68010, so anything more recent is probably off the table.

For the record, the first of the series that was on a CMOS process was the 68020. That would draw less power and allow being compatible with CMOS levels, but it was still a 5V device only. Same for the later ones AFAIK (and anyway, designing a board around the 68030 or later becomes significantly more complex).

The only one of the series that I know of that supported 3.3V operation was the MC68SEC000.

Otherwise, yes, there are more recent designs with a similar ISA but those are different beasts that the OP is probably not interested in.

Pretty much.  I have went looking up and around the series several time already and the higher end chips get rarer, less documented, less 'retro-community familiar and  increasing amounts and higher grades of support circuitry - less forgivng.

The 68010 has what I need over the 68k, so I pick it.  I also have 2 working copies.

Yesterday I finished the design and lyaout of first board of the project... a ROM progrmmer, even though they exist on AliExpress to buy.

It lasted 3 minutes in review and was scrapped.  This is how it goes.  I assumed my "Package of choice" for the Flash ROMS was TSSOP and so I was "assuming" making them swappable meant placing them on DIP adapater boards.  So I layed out the board using ZIF32 sockets for the ROMs.

Then I find the only people selling them want £5 each adapater!  I was so scandalised I made my own.  Then I checked PCBWay and ticked the "Customer panelled, 2 designs" and the price when from $5 to $45.

Then the "Dumb" penny dropped.  PLCC32 sockets... "yes, sockets!"  DUH!

By the way.  I own the folks here a "Thanks".  The last programmer I did I struggled with the MCU routing.  Someone pointed out, you hiave got the ability to remap the pins on the MCU side to "work with the  layout".

I had preveiously ignored this and attempted to make the config and code access easy with lovely "congruent port blocks" for buses etc.  Asides the fact these never really work as you expect.

Last night after the first "rats nest" conversion into a "birds nest" I decided to give it ago.  All my port requirements are just bog standard GPIO so I literally just maps the pins "physically" convenient. 

The result was the Kicad autorouter "F key" was able to do most of the MCU routing.

That "birds nest" PCB is not completely wasted though.  I'm just out of practice at seeing what I need to see in the "Rats nest" version.  When I had the first draft .... staring at it a while you start to see things.  "Wait... most of the lines going to that lower shifter are coming from the TOP of the board area.... and the middle one is crossing 75% of the upper ones traces.  It would get 50% as complex if you just swapped those around.  etc.

[brucehoult]

I find it totally cool that paulca is pursuing this. The 68010 is the "real" 68k that fixes the few flaws in the 68000.

Plus "loop mode" that made for quite a performance boost on 2-instruction loops e.g. memcpy().

[paulca]

There just isn't going to be a neat way is there.  The two 32pin ICs are on a shared bus.  90% of those pins interconnect between them 1 to 1.  That much is fine and "possibly" easier in the current "inverted" stance.  It only leaves the two facing rows as messy.

However.  I still need to wire that bus to the trainscievers on the right.

Side by side, the transcievers only see one to connect to, but vertically stacked the transcievers can pick and choose for routing.  Vertically stacked with one inverted also means the present different sides to the transcivers requiring less routing to the back sides.

[paulca]

More happy.  Not sure yet.  I stopped stitching as I already notice I don't like the fill island settings.

But over all very little ground plane was harmed and except in a few places easy to stitch in help.

Board got smaller which is a plus.

Also, I note... as I moved the PLCC socket decup caps to the darkside.  I might as well move the rest darkside.  Penalty.  They need hand soldering.

The PLCC socket itself I am aware of the issues and the pins being within the plastic wall/base footprint.  But I'm hoping the hot plate will help if these are fitted with the passives for the first pass.

Also it still needs "Foot print verification" from an actually purchased and delivery DOM list from Digikey.

[ale500]

I recently did an all  through-hole 68008 board with a ZIF socket for the EEPROM. The good thing about the 68 K is that you can program it in C or in a very nice assembly, but be prepared to burn some EPROMs/EEPROMs. Some test code, burn it,, add more test code, burn more EEPROMs. At some point an UART and a monitor are a good thing. I ended up using a 6850 and a monitor I wrote, there are plenty already written. The E input of the 6850 I used it as chip select, I saw it somewhere. A 68901 would do too but you have to mess with DTACK, not a big concern. I just grounded it, and the processor runs at 10 MHz. A 68B50 is what I have.
For DTACK generation you can use a shift register, input AS_n and clock it down, clear it on not AS_n.
For RESET generation, there are supervisory circuits. I used a 555 like in the VIC-20, it works a treat, and a MOSFET to invert it and make it open drain, RESET_n is bidirectional.
Don't forget FC0/1 you need them for memory access, and FC0,1,2 to acknowledge interrupts.
A timer is also very useful. I did mine with a 4060, a couple FFs and some gates.
Decoding was done witha couple of GALs. An all TTL version is also possible.
A newer version that uses a 68EC020 and is all SMD sits on the desk sparsely populated, it depresses me: THT is easier.
Don't forget test points, lots of them, they help , that means a connector with Address, Data and important signals.
Sorry if you knew all this.
Have fun!

[paulca]

https://www.eevblog.com/forum/programming/virtual-blinky-68000-assembler-learning-lab/
https://www.eevblog.com/forum/beginners/designing-a-uart-register-file/
https://www.eevblog.com/forum/eda/bus-and-higher-density-ic-routing/
Just some cross links, apologies for the clutter.

I especially like these projects when they start to "fork" into more and more sub-projects and branches with their own only elastically coupled timelines.

In no particular order:

DTACK master flip-flop working on the breadboard, at least at 140kHz with an arduinno driving.
Shared DTACK trigger (protocol)- in progress - probably making it an open drain with an inverter to get CLK edge.

That unblocks the Arduino CPU puppet breadboard test.  Over-thinking says it will run into many problems asides DTACK and the slow arduino will force me into hardware-izing the data bus drive too.

If the CPU fetches a "write to RAM" instruction from the puppet...  The DTACK flip flop will 100% clear DTACK before the next bus trans starts.  However, that bus trans will not wait and it will drive the databus for that write in about 450ns, (needed reverified on the AC graphs).  The ATMega2560 is probably not completely capable of tri-stating two 8  bit ports that quickly.  It might be.  I'll find out.

If a databus transceiver is required, then the choice is .. a basic 245 or a 'latching one' like the 573?  That would allow the Arduino to be effectively async, not tied to address strobe 'transactionally'.  It write the port data, pulses the latch and immediately tristates the data and moves back to being ready in it's hot loop on address strobe.  UDS+LDS determine the latch OE drive effectively "close" the transaction in hardware for it.

It depends on how "fun" that is.  The 'real' CPU board will have SRAM and NorFlash which will spend most of it's time waiting on the CPU.  They will (still in design review), "ROM EN | RAM EN->Set DTACK trigger" async, combinational.  The memory ICs have < 100ns read times.

The bit that needs design review is the possibility of having a "supervisor" on board.  Not a FSB or MMU, nothing that heavy, yet, but just a "Bus spy with authority".  A potential use case is, as a bus spy.  If it is enabled to "log the bus for N insructions and halt" it needs to "over-rule" the DTACK trigger.... while assuming responsibility to issue DTACK when it as captured the bus.  "DTACK interception bus stepping" basically.  Classic breadboard style.

The "supervisor" MCU idea.  It has gravity.  While not "in step" upto speed with the CPU, like an FPGA would be, it can still take a LOT of the less time critical functions internally ... its what MCUs where made for literally.  The "control unit" used to be a cabinet and it controlled the other cabinets around it, including, memory, printers, disks, punch tap reader machines.  Handling basic IO/serial/interconnects/back plane coms etc.

Just that origin in in "Mainframe" and "Mini-computer" architecture, not typically in "Home micro-processor systems of the 80s".

For one example.  Power on.  An STM32 already inherently follows a supervised boot process internally.  So it with barely any extra circuitry take "precise" control over the RESET and HALT lines.  Immediately freeing me from fiddling around with OR gating the open drains.  Why use a RC latching RESET/HALT with OR/NOR mechanics and sprawl 2 or 3 74 series chips on the board, when i tiny little MCU can do that, or just two pins on a larger central MCU.

The CPU is effectively a "client" not the master.  That provide some immediately advantages.  In circuit rom Flash, with the classic styles supported.  "Flash on reset" or "Flash under HALT" or even "Flash over DMA in-flight".

The programmer board is also in PCB routing stage.  The BOM arrived in the mail.  All accounted for, foot prints locked in.  Just effort and my own acceptance gates remain for that to go to fab.

In the mean time I threw together a breadboard break out board for the LVC16T245 IC just to get my feet back into the water.  And end to end project which should total about 3 hours.  Shit... I should NOT have said that!

[paulca]

"Software side"

I have so far for a rom.bin which:

Defines a full 68010 vector table.
BIT tests the CPU and it's memory access.
Probes RAM boundaries and writes "total RAM chunks" to the first byte of RAM.
Performs a CPU fault (bad address) fault.  Catches it.  Verifies the full 68010 type 0 frame.... noted the Mushashi variance with the real CPU here.
Performs a TRAP and return.
Switches to user mode.

UART driver is in progress in user mode.  When it looks like emulator is functional, a BIT/POST test of it will follow.

Then I will mark that IO address space supervisor only.  Handle the bus fault.  Then move the register file access behind a "TRAP".  A large part of that is in Unix C inside Musashi's bus accessors and whatever I build behind them.  Im honestly not sure I want the "Minimal" first boot rom to even attempt masked IO space.  Without an MMU all I can do is gate the "Supervisor" bit to the IO space.  All that will do is cause a "hang", not a fault.  To get a fault I need a "bus timeout" circuit.... of that MCU again.

In other off shoots I have been breadboardign small subcircuits and using an arduino to puppet test them.  Such easy, pleasant and highly inefficient code the arduinno framework.  "Don't care, just want it and fast." its perfect for.  Like python.  Blisteringly fast to write.  Runs like a snail.  Even just an "AS transition" bus cycle test... 140kHz is it's opening offer.  I figure if I cared I could double or tripple that, but not right now.

[paulca]

Progress is deliberately slow.  Especially hardware wise as there are a LOT of "new" things and any "working computer" board is going to bring all the tricks to the party.  I just don't fancy debugging that board to be honest.  So I have a different strategy.

So far I have created, built and tested:

A LVC16T245 dual voltage transciever "Breadboard utility" PCB. 
An Ice5LP4k FPGA breakout/dev board PCB.
A dual parallel ROM programmer board ... with a full bus level shift it doesn't need at all, but... tests the transcievers work as I expect/intend them to.

The FPGA board was then flashed with the intended address glue, dtack duties and a test fixture built to test it with an STM32.

The ROM programmer so far has worked, I can write, read and verify all addresses, although I did see few verify errors on a longer stress test rewriting the ROM in a loop.  That kind of error rate, like 1 write in a million, and verify catches it, is fine AFAIC.  The "Command line" and complimentary programmer.py are the current work in progress.

The next probably PCB will be a CPU test harness.  Not that I want to test the CPU works, but because I can't be bothered breadboarding a  puppet rig.  I don't need a puppet rig either, but I feel like I need to prototype that general area of the board.  Besides if that board does provide a "free run of ORI d0" (instruction 0x0) it at least will tell if a CPU off ebay is even worth playing with.  Outside of that the MCU can feed it real instructions, provide a hardware debug style CPU status dump, stepping, memory peek/poke etc.

Not that I intend to sell any of this, but I do note that Z80 "Nop" boards are apparently still popular.  Its a bit of a scam because NOP on Z80 is just 0x00.  Its literally just pull downs.