While working on the design for MAXI030 I completed another project: a new workbench microscope.

After watching various videos on the topic, I came to the conclusion that a setup with just a camera and large TFT screen would be best for me, ie. one without eye pieces. I have various things wrong with my eyes, including poor stereoscopic vision, and have never been able to use binoculars so a microscope with eye pieces would probably not work very well.

My new setup consists of the following parts, sourced from ebay and Amazon:

1. Amscope articulated arm with G clamp – ebay aprrox £210
2. Stereo microscope to 50mm adapter ring – ebay £23.99
3. Lens and camera – ebay £138.32
4. Adaptor ring to convert M42 to M48 – ebay £6.99
5. Barlow lense (X 0.5, M48) – ebay £17.48
6. Light ring – Amazon £21.61

So the total was about £417.

The arm was ordered from Amscope via ebay and took about a month to arrive, which was a little annoying. It’s a very substantial arm though which is clamped to the side of the desk. Ideally it would be clamped to the end of a desk, but since I sit in the middle of a long bench this isn’t possible. It works fine in any case.

I was amazed at the quality of the camera and its lens. For the money, it’s extraordinary value. The Barlow lens provides a 0.5 magnified view, ie a wider view. Crucially it also doubles the working distance, without which there isn’t a comfortable amount of room to work under the microscope. The M42 to M48 adapter was needed because finding a M42 Barlow lens, the size of the thread on the camera’s lens, seemed to be difficult. M48 is a much more common size.

Here’s a picture of the setup I’m now using:

In use it works very well. The arm has knobs for setting the tension on its various joints and can be moved out of the way when it’s not needed. The lighting could perhaps be better, but this is not surprising since I bought about the cheapest light ring available. The camera has a micro-SD card slot for storing images and video, though so far I’ve only used the HDMI and USB outputs.

Before ordering the MAXI030 boards a few refinements to the design were in order:

1. More decoupling capacitors around the 68030 since there was room. The capacitors were pinned following the manual guidelines which describes the power pin pairs used for the address bus buffers etc
2. The footprint for the clock oscillator was incorrect and needed to be 5 mm by 3 mm
3. Some test points for some key CPU signals seemed like they might be useful
4. There were missing pull-ups on some processor inputs; to make routing possible without ripping up the existing traces individual resistors were used

A big issue was also corrected: previously I used the best mapping for routing the PCB on the data bus connections between the buffers and the SIMM slots. But it turns out this ignores the fact the processor data bus bytes are individually selected via the /CAS signals for writing arbitrary whole bytes within the 32 bit wide SIMM data bus. So D0 to D7 on the processor must be connected into D0 to D7 on the SIMM, but within those bytes it doesn’t matter how they are mapped. The connections used are still a single PCB trace for half of the bits, but the other half use a trace on the reverse of the board to make the connections. It’s perhaps easier to explain this with a screenshot of this area of the PCB in KiCAD:

The fix involved adding the horizontal traces for the alternate bus pins. Without this change the SIMM would have worked, but only for whole 32 bit wide transfers.

Considering this problem was fixed at almost the last possible instant before ordering the board, I was pleased that the solution was relatively painless and didn’t involve moving the SIMM slots and making the board bigger.

One thing I experimented with only after essentially finishing the board design was using 8 mil wide traces instead of 6 mil, which my designs have generally used because it was believed to be the only way to get three traces between two 100 mil spaced through hole pads, which was necessary in some of the tighter places on the board.

In my collection of Amiga hardware I have a Blizzard 68030 Amiga 1200 expansion card. Looking at the back of this board reveals a very elegantly routed board, and there are multiple points where three traces pass between two 100 mil spaced though-hole pins. It’s also obvious these are not 6 mil traces:

The designers of this board achieved this by using smaller octagonal pads for the through-hole parts then KiCAD normally uses. Using the microscope I was able to determine that these 8 mil wide traces have a 7 mil gap between them, giving a “pitch” of 15 mils. This could be replicated with KiCAD but it would require custom footprints for all the through hole parts. I didn’t fancy redoing the MAXI030 board, but in the future I might consider using these sizes because it makes the boards potentially cheaper to manufacture and more rubust, though JLCPCB is certainly happy with the board as it is using their standard service.

Anyway, the boards were duly ordered from them and arrived just over a week later.

First the front:

The back, zoomed in on the buses:

The traces here are 6 mil (0.15 mm) wide with a 6.5 mil gap between them. I’m still in awe at what can be done for the relatively little cost!

Unlike the MIDI020 board, I didn’t use a SMT stencil. The reason for this is mostly because placing and reflowing all the SMT parts in one sitting makes it harder to diagnose issues.

Almost immediately I found a hiccup. In a serious case of history repeating itself the 5V potted switching regulator, a P7805-2000-S (PDF), had its footprint reversed. I had foolishly assumed that this 2A part had the same pin-out as the SR05S05 (PDF) I’ve previously used on many boards in the past. Instead it is reversed.

There are two solutions to this problem:

1. Use a 1A SR10S05, which has the same pin-out as the SR05S05 and would give some current rating boost over the 500mA of the previous part
2. Use the 2A part but fit it backwards with regards to the footprint, hanging it off the board

For now I’m hanging the part off the side of the board. It looks ugly but it works; I get a good 5V rail:

The next step was to solder up the 2.5V and 3.3V regulators. Everything proceeded as expected.

Next, soldering the passives  (resistors and capacitors) for the FPGA, config flashes, and JTAG header. I opted to solder the decoupling caps for the FPGA first because I wanted to avoid heat, even from the back of the board, getting to the FPGA after the problems with popcorning I’ve previously experienced with these older parts. In addition, I used a mixture of caps, not just the 0.1uF described by the schematic. The idea was to further reduce noise on the FPGAs power pins.

At the same time I soldered the LED, buzzer and 20MHz oscillator can attached to the FPGA.

The next challenge was something I wasn’t looking forward to: soldering the 240 pin QFP EPF10K130EQC240-1 (PDF) FPGA. I seem to be getting the hang of soldering these large QFP parts as I didn’t encounter any difficulties. The process followed was:

1. Align the part using the microscope, zoomed out as much as possible
2. Tack one corner with a dry iron, using the solder tinning of the pads and leads for adhesion
3. The opposite corner was then not quite true and needed a small nudge before it too was tacked
4. A generous amount of my usual flux was applied to the lead and pad area all around the part
5. Then the pins are all methodically soldered, a width of the iron tip at a time, by dragging down from the “heel” of the lead to the toe
6. The iron tip was “refilled” with a small amount of solder every 30 pins or so
7. Bridges were few are far between but were cleared easily using flux
8. Cleanup was with IPA and a tooth brush

I was very pleased with the result:

The last step of the core FPGA section was to solder the two EPC2 (PDF) config flashes and the JTAG header. Soldering the EPC2s was accomplished with reflowed solder paste.

After modifying the MAXI030 VHDL to include a simple LED flasher, it was time for an initial test.

The result, which surprised me, was an intact JTAG chain and a flashing LED!

After trying to program the EPC2s I encountered a problem: one of the devices refused to go through the erase process, aborting the programming step. The fix was simple but laborious: a part swap of the faulty device for one I first tested in my old MAXI09 board. With this, I had a board which flashed the LED a moment after applying power.

Next up then, the parts for a board capable of running code on a 68030 processor. The tedious bit was the 68030 PGA socket itself; 128 pins. This also required all the passives. The 68882 PLCC socket, socket for the flashes, and reset logic gates were also soldered. I was amazed, again, that this worked first time; I had an LED flashing under processor control, albeit one without any RAM.

The next job was to solder the expansion port buffers and the DIN 41612 female connector for the first socket. I could then attach the test SRAM card originally built for MIDI020.

But before trying a basic test of the SRAM I decided, rather foolishly, to jump ahead and attach the SC26C94 (PDF) QUART. I then ended up down a blind ally exploring non existent problems with the processor’s data bus which ended up being a simple case of a faulty MAX238 (PDF) line driver. I’m not sure why I didn’t simply revert to trying the TTL serial header, but perhaps I’ve had a lot on my mind lately.

In any case, I replaced the MAX238 and then had my boitloader and monitor program up and running, which was a fantastic milestone for this board.

The last three areas I’ve worked on were the 68882, the SIMM slot and the IDE header.

In short I’ve had some trouble from the FPU. An F-line exception is sometimes being generated when running maths instructions. The VHDL for the selecting of the FPU is as follows:

if (as = '1') then
    if (vector_fetched = '0') then
        selects (DEV_MAJ_ROM) <= '1'; addr_width <= WIDTH_WORD;
    else
        if (fc = "111" and addr_mid = x"2" and addr_low (15 downto 12) = x"2") then
            addr_width <= WIDTH_NULL;
            if (fpu_sense = '1') then
                selects (DEV_FPU) <= '1';
            else
                berr <= '1'; 
            end if;
        else
            if (addr_high (31) = '0') then selects (DEV_MAJ_SIMM) <= '1'; addr_width <= WIDTH_LONG;
            .....

This is almost identical to what was used in MIDI020.

vector_fetched deals with the start-up case, where the ROM must be selected from the low addresses, which would otherwise be used for RAM, until the stack pointer and reset vectors have been read in. addr_mid is address bits 19 down to 16, and addr_low is bits 15 down to 0. The first is required to select co-processors, and the second (new for MAXI030) is required to disambiguate MMU and FPU instructions. This shouldn’t be needed on the 68030 as it has a built in MMU, but somehow after making this change the FPU started behaving itself, for a time at least.

I’ve only ran my simple “square root of 2” routine, previously used on MIDI020, on this board. More testing is warranted to debug the occasional issue I’m seeing. Hopefully it is is just a bad joint on one of the FPU socket pins, or an FPGA pin.  It’s also possible the VHDL needs tweaking. In any case, I decided I’d come back to this problem later.

In terms of the SIMM slot, initially I had no luck at all. After pouring over the VHDL, slightly modified from the code used by MIDI020, and trying to decipher the data read back after storing test data, I decided to try reflowing all of the through-hole pins on the connector. The result was positive: a basic checksum test passed, so I quickly switched the address decoder to use the SIMM for RAM at address 0, instead of using the first expansion slot, which had the SRAM card attached. The result was I was able to run the monitor environment with only the 8MB SIMM installed for memory.

Of course this implementation is not even slightly tuned. Even the CBR interval counter value was guessed at. It also makes no use of the 68030 burst mode to fill the processor’s cache quickly. Using the logic analyser I was able to time the wait states at around 100nS per access, not terrible but also not at the edge of the SIMMs maximum performance either. Further tuning is certainly possible.

The most interesting aspect of the SIMM controller, relative to the implementation used by MIDI020, is the address multiplexor. It is now implemented inside the programmable logic, whereas before it was implemented with three 74HC257 (PDF) mux ICs.

The processor address bits, for the 8MB module used at least, are arranged as follows:

1-0 : byte and word selectors
2 : bank selector (generates the /RAS lines)
3-12 : 10 bit column address
13-22 : 10 bit row addres

The VHDL for the address mux, which drives the 12 address inputs on the SIMM, is as follows:

entity simm_mux is
    port ( mux_select : in STD_LOGIC;
           addr_in : in STD_LOGIC_VECTOR (31 downto 0);
           addr_out : out STD_LOGIC_VECTOR (11 downto 0)
    );
end entity; 

architecture behavioral of simm_mux is
begin
    addr_out (9 downto 0) <= addr_in (9 + 3 downto 3) when mux_select = '0' else
                             addr_in (9 + 10 + 3 downto 10 + 3);
    addr_out (11 downto 10) <= (others => '0');
end architecture;

The upper 2 bits are used on higher capacity parts.

This raises an interesting question about how larger SIMMs can be supported. Currently supporting different size modules would involve hacking at the VHDL. It would be nice if this could instead be automatically configured, either by the processor manipulating registers to configure the mux (and possibly other logic) or by the FPGA itself somehow determining what part is installed.

After the success with the SIMM I was feeling chuffed, and a little brazen. I decided to try running the board using a 40MHz oscillator. Amazingly everything worked without any further tweaking.

The last thing I’ve very briefly tested, after attaching the parts, is the IDE port. The disk identify command and block level read and writes succeeded in polled mode. I have yet to look using interrupts, yet alone the DMA signals this board has.

The main piece of construction work remaining is the ethernet controller, a RTL8019AS (PDF). The other parts to be attached include the I2C peripheral ICs, and the remaining expansion connectors. Also the PS/2 and my custom serial keyboard connectors need to be soldered on. And I should solder on the second SIMM connector.

Talking of SIMMs I need to scour ebay for some bigger parts. It would be very nice to see two 64MB sticks working.

I’ve found a number of very minor problems while building the board:

1. The cache and MMU jumper silk screen labels are backwards; disable and enable should be swapped over
2. The /DACK pin on the SC26C94 QUART is missing a pull-up; I neglected to read the datasheet fully, but luckily this is not essential as hard coding a single wait state seems to result in reliable operation at 40MHz
3. And of course the aforementioned problem with the switching regulator

All in all I’m over the moon at how well MAXI030 is shaping up. I’m anxious about the ethernet port, but even if I can’t get it working I’d still consider this project a major success.

Here’s a shot of the board as it currently stands:

One thing I want to do before continuing the build is to try out my video card. It would be very pleasing to see that working with this computer…