As I mentioned a while back in my introduction, I recently embarked on my first electronic construction project in ages (must be over 10 years).
The aim was to build an extension board for my venerable old Acorn Electron, to replace the somewhat ramshackle one I built 30 years ago which stopped working.
The requirements were:

* Sideways RAM - at least two blocks of 32K

* Sideways ROM - at least two blocks of 32K

* 6821 PIA to interface to my 68000 2nd processor board

* Discrete glue logic chips replaced with a PLD

* A USB interface managed by an FT240XS interface chip, to give a fast way of getting data on and off the electron. This is an addition to the old board.

As well as the aim of replacing the old broken board, this project would give me experience of using PLDs and would also be my first project built with a proper professionally manufactured PCB. I'd done PCBs before, the old hobbyist way of using transfers for IC pads and drawing other tracks using a permanent marker pen. It worked, but it never looked particularly good.

Having thought a bit about what I wanted on the board, I installed KiCad and entered the schematic. I found it quite intuitive to use and became fairly fluent after a short while. Most of the components I needed were in the part libraries which come with the KiCad installation, with the exception of the ATF1508 CPLD, which needed a separate library which was easily found on the net.
Once I was satisfied with the schematic I set about laying out the board. I decided on a size of 100mm square, since the boards get more expensive above that size. That size of board meant that I couldn't fit in the 6522 VIA which I had on the old board. However that wasn't too much of a loss since I only ever used it to drive a home-brew EPROM programmer which I didn't need any more, having acquired a TL866II device.

It took around 2 days of work to lay out most of the board, and another few hours over the following week or so to finalize the layout and fix some issues. For example, one of the issues I needed to fix concerned the layout of the address lines. In general, when connecting a RAM device, you can arbitrarily permute both the address and data lines in order to simplify the PCB layout. You can do the same thing with a FLASH device provided that (a) you apply the same permutation to the required image if using an external programmer, (b) you apply the same permutation to the unlock codes and command codes required when programming the device in situ and (c) you preserve the erase and program blocks in contiguous addresses as seen by the processor. My original layout failed condition (c), so had to be modified.

So after much checking and rechecking, running DRC checks in KiCad, carefully generating the Gerber files and checking them on an independent viewer, I sent off the order to JLCPCB. A few days later my boards arrived. Fantastic! After admiring the craftsmanship for a bit, I took one of the boards and buzzed out most of the connections. Everything seemed to be in order, so time to start populating.

The first bit of fun and games was with the 50-way edge connector to plug the board into the Electron. The pins on the edge connector were only slightly smaller than the holes on the PCB and had been slightly bent in storage and/or in transit. So I spent a while bending pins back into alignment, then quite a while trying to wrestle the connector into position on the board without scraping and damaging anything. Eventually I got it into position and soldered it in. After that, component fitting went smoothly until I came to fit the FT240XS chip. This is in a SSOP package (0.025" pin spacing), which is quite small and I found it quite challenging. I was initially quite intimidated by it - I thought the pins would just turn into a huge solder bridge which would be impossible to correct. I watched one of the videos on here about soldering small components, and then decided to do a practice run on another board. The practice run went reasonably well. There were a few bridges, but the solder sucker removed them easily and eventually I got the chip soldered.

Then it was time to solder the chip onto the actual board. I followed the advice in the video to tin two opposite corners on the pcb first. After soldering the first corner pin, I somehow managed to bend the pin slightly. I soldered all the other pins, then checked everything carefully with a magnifier. There was a short between the bent pin and the adjacent one. A couple of applications of the solder sucker seemed to correct it, but a low-voltage continuity test still showed a short. The pin had been bent so it was pretty much touching the adjacent pin. Over what felt like ages, I managed to get a watchmaker's screwdriver in between the pins and bend the pin back to approximately the right position. Now the short was fixed. Just to be certain, I did a continuity test on all the pins to check they were actually connected. I discovered two pins weren't actually attached even though it looked like they were - this was because the chip was not quite centred on the pads. A couple of remade joints later, all was correct.

A few more components later and I had a fully populated board, with the exception that the CPLD, RAM and FLASH chips were not present in their sockets. After a bit more continuity checking I decided to power up the USB section on its own first, via the USB socket. I installed the FT240 driver on my laptop and plugged in the board. The USB and power LEDs illuminated and no smoke came out of anything - so far so good. However, the laptop didn't recognise the USB device. It produced an error message something like "The device has malfunctioned. Failed to read device ID."

This was a bit of a head scratcher. It should have just worked - all the usb functionality was contained on the FT240XS chip. Get the multimeter out and see what voltages are on all the pins. Vcc = Vcc_usb = 5.2V, ok. VccIO = 2.7V ? Curious - it should be 3.3V. After perusing the data sheet, I saw a signal mentioned which I didn't remember seeing on the schematic - VCORE. Apparently VCORE is the output pin of an on-chip 1.8V regulator, and it should be left unconnected. The KiCad component information for the FT240XS chip had that pin incorrectly labelled as VCCIO, along with the real VCCIO pin. Seeing two pins with the same name, I had connected them. So the output of a 1.8V regulator and a 3.3V regulator had been connected. That seemed like bad news - potentially very bad news. To fix it (assuming the chip hadn't been cooked) I thought I would have to lift the pin. That seemed a very daunting task indeed on such a small chip. Luckily, while sizing up the job I noticed an easier fix. A fairly narrow track connected the offending pin to the adjacent one, so using the corner of the watchmaker's screwdriver again, I carefully cut the track. Took a while, but eventually continuity test showed it was broken. Powered back up again and, amazingly enough, this time the laptop recognised the device.

Next step was to install the CPLD and the RAM chip, and program the CPLD. JTAG connection worked with no problem. Attach board to back of Electron and power up. Electron doesn't boot. Remove RAM chip - still doesn't boot. Remove CPLD - boots. So the CPLD programming is probably at fault. After poring over the output of WinCUPL I discovered that the IRQ line was being asserted all the time. I couldn't see anything wrong with my source, so I rewrote the code to remove the negative logic markings on the pin declarations and put them in the logic equations instead. Now the output seemed to be correct. Reprogram CPLD - Electron now boots.

Spent a few days (in spare time) testing the functionality. USB transfers worked. Sideways RAM worked. Program test pattern onto FLASH using XGecu programmer, check I can read it correctly on the Electron - all fine. Erase/program FLASH on electron - all fine, although time consuming to test since I had to correct for the address and data line permutations mentioned earlier.
PIA functionality was an interesting one. I didn't have room on the board for a real PIA, so I had implemented the required functionality in the CPLD. Port A was permanently set to input and Port B to output since that was how I used it, and the DDRs were permanently set to 00 and FF respectively, with writes ignored. All other functionality was present. Tested it bit by bit with LEDs and flywires just to test basic input and output behaviour and a logic analyser to test the strobe functionality on CA2 and CB2.

So, everything appeared to be working at this point. The final test was could I use it to communicate with the 68000 board? So I first had to detach that from the old interface board and fit some proper pin headers so I could attach it to the new board. Eventually got it connected up and powered on. The 68000 initial boot code seemed to be running, and a short snippet of code could be downloaded and run. So, finally I loaded the proper software into the sideways RAM and reset the system. "MC68000 256K RAM" came up - all good. Start BASIC on the 68000 - seemed OK for a few seconds, then everything freezes. Reset, try again. Every time, after a period ranging from a few seconds to a few minutes, the system freezes.

I tried setting up a small basic command line in *KEY10 to toggle an output pin on the 68000 board at approximately 1Hz, attached to an LED. That carried on running for 2 hours with no problem. As soon as I stopped it, the system froze up again. So it seemed the problem was not with the 68000 board, but with the interface between that and the Electron. The obvious suspect was the strobe behaviour of the CPLD. The strobe lines were used in each direction to tell the other side that data is available, or that data previously sent has been read. CB2 on one side connects to CA1 on the other, CB1 on on side to CA2 on the other. Port B on one side connects to Port A on the other. Writing to port B generates a short (1 clock cycle) pulse on CB2 which triggers the CA1 flag on the other side. When the other side reads the data from Port A, that generates a 1 clock cycle strobe on CA2, which triggers the CB1 flag on the originating side.

There were two possibilities I could think of. Either the CPLD was outputting pulses which were too short for the 6821 on the 68000 board to detect, or the CPLD was missing pulses sent by the 6821. To determine which (if either) was happening I wrote some test code which sent data across the interface in both directions. 64K was sent one way, followed by 64K the other way. The opposite direction port was used to give an unambiguous indication that the write strobe had been seen by toggling bit 7. Running the test program revealed that all the strobes output by the CPLD were seen by the 6821, but approximately 1 in 130,000 strobes from the 6821 were missed by the CPLD.

The input strobe edge detection in the CPLD had been implemented as follows:

/* CA1 input edge capture */
PIACA1CAPTURE.d = 'b'1;
PIACA1CAPTURE.ck = IFC_CA1 $ !CA1PosEdge;
PIACA1CAPTURE.ar = !nRST # PIACA1S;

PIACA1S.ar = !nRST;
PIACA1S.ck = PHI;
PIACA1S.t = (!PIACA1S & PIACA1CAPTURE) # (PIACA1S & isPIAPRA_Read);

The CAPTURE flipflop was clocked by the CA1 input, clocking in a 1 when an active edge occurred. No obvious problems there. However, the output of the CAPTURE stage drives the status flag flip flop. At the next rising edge of PHI (the processor input clock), if the CAPTURE is set and the flag is clear, the flag becomes set. The CAPTURE stage is then asynchronously reset. Two problems here - the output of the capture stage is not synchronized with PHI, giving rise to potential metastability issues. If such an issue does occur, it could give rise to a very short pulse on the capture stage output. My guess as to what was happening was that if the CA1 active clock edge occurred very close to the rising edge of PHI, the CAPTURE stage would output 1, the PIACA1S stage would go metastable, its output would briefly go high, resetting the CAPTURE stage. PIACA1S would then change its mind and end up with its output low, and an edge would have been lost.

To fix this issue would require synchronizing the strobe inputs with the PHI clock. However, on the Electron that clock can be stretched to as long as 40us when in the higher video modes due to the video display eating all the RAM bandwidth. This is far too long to detect a 1us pulse emanating from the 6821. Luckily I had routed the 16MHz clock on the Electron edge connector (from which the CPU clock is derived) to the GCLK2 pin on the CPLD. So I could change the edge detection system as follows:

/* CA1 input edge capture */
pinnode = [CA1Sync2..0];
[CA1Sync2..0].ckmux = FCLK;
[CA1Sync2..0].ar = !nRST;
CA1Sync0.d = IFC_CA1;
CA1Sync1.d = CA1Sync0;
CA1Sync2.d = CA1Sync1;
PIACA1CAPTURE.t = (!PIACA1CAPTURE & CA1PosEdge & !CA1Sync2 & CA1Sync1)
# (!PIACA1CAPTURE & !CA1PosEdge & CA1Sync2 & !CA1Sync1)
# (PIACA1CAPTURE & PIACA1S);
PIACA1CAPTURE.ck = FCLK;
PIACA1CAPTURE.ar = !nRST;

Here FCLK is the 16MHz clock. There is a 3 stage delay line, with the first two stages used purely for synchronization and the last stage used to detect edges.
Rebuild JEDEC file for PLD with these changes. "Design does not fit"!!!!!
To cut a long story short, I discovered that I could only get it to fit by switching some pin assignments on the CPLD. After some experimentation I found that it would fit if I switched CA2 and CB1. I just had to swap two wires on the 68000 board to correspond.
Powered it up again and ran my test code. 48 hours later, 1.3GB total data transfers, no errors. So I guess the problem is fixed.
Finally, run basic on 68000. Everything works. No more freezes.
Whew!

Congrats on your success, kernelthread ! Quite a lot of debugging, and you've given us a rather detailed explanation... to the point where I'm almost as tired as if I'd done the work myself! But that's alright. The photos look great, and I would only suggest that the description of the project be presented separately from the description of the debugging process.

I'd be curious to see some pics of the 68000 board, and also the original "ramshackle" expansion which has now presumably been retired.

Further to the point about a description of the project, an overall Block Diagram would be helpful, showing the Electron, of course, and particularly the Expansion and its data and handshake arrangements with the 68K. (Also, the "schematic" you posted is little more than a netlist. That may be adequate for your own purposes, but folks unfamiliar with the design will probably prefer to see more of the detail actually drawn in -- notably including the buses, for example. Just a suggestion!) Cheers,

Jeff

_________________
In 1988 my 65C02 got six new registers and 44 new full-speed instructions!
https://laughtonelectronics.com/Arcana/ ... mmary.html

A great result - and having a 68000 board hanging off a 6502-based Acorn Electron is interesting in itself.

That was part of the intention - to illustrate how careful you have to be to get something to work. I thought I'd been very careful, checking and rechecking at every stage, but still ended up with quite a few issues. As the saying goes, "measure twice, cut once." Maybe it should be, "Measure three or four times with at least two different tape measures, just in case one is stretched." I guess the CPLD issue could probably have been avoided - in retrospect my original design was quite unlikely to work.



I'll try to knock something up when I've got a bit more spare time.



That I can do...

This shows the 68000 board at the bottom, with the interface board at the top and the sideways memory board in the middle. The latter two are replaced by the new PCB. This was taken when I was probing around for the problem. In actual use the two boards were mounted horizontally on the aluminium baseplate. At the top left you can see the end of the long 50 way ribbon cable which connected the interface board to the Electron. The quartz crystal at the top in the middle, on the interface board, is actually the clock crystal for the 68000. You'll see that again later...

This shows the 68000 board attached to the new interface board with nice ribbon cables instead of a mess of wires.

This shows the bottom of the 68000 board after it had been detached from the other two boards, with a small bit of extra Veroboard attached to the end to hold the new pin headers. The red wires in the left of the photo are about to be soldered to the pin headers.

This is the old sideways memory board. Two 6264 8kx8 SRAMs to give 16K of sideways RAM. The empty socket usually contained a 27256 32Kx8 EPROM to give two banks of sideways ROM, which held the software to drive the 68000 interface. The 74LS174 was used to latch the selected sideways memory page whenever the 6502 wrote to address $FE05, and the LS154 decoded that.

Same board viewed from bottom, showing PCB tracks resulting from the "transfers + permanent marker pen" method.

The old interface board has most definitely been retired - this is all that's left of it:


The two sockets used to contain a 68B21 PIA and a 6522A VIA. The bottom picture shows a makeshift pin header made with discrete bits of stiff wire soldered into the holes on the board. The connector at the end of the ribbon cable plugged onto the board there. The cut out part of the board contains the clock oscillator for the 68000 - I dremelled that off and attached it to the 68000 board.

This shows the 8MHz 68000 chip, along with clock oscillator butchered off the old board. The 8MHz chip has been overclocked to 10MHz. I tried 12MHz, but that didn't work. 10MHz is 100% reliable.

This shows the 256K of RAM (4 pairs of 62256) plus 64K of EPROM (2 x 27256) which contains OS, BASIC interpreter, assembler and a basic word processor, total code size 34K. Originally there was only a very small boot EPROM plus the RAM, with each of the 8 RAM chips in separate sockets. After a while I got fed up having to load the 68000 OS + BASIC from cassette at 1200 bits/sec so added the EPROMs. The EPROMs went in two of the RAM sockets and the displaced RAM chips were stacked on top of the ones in the adjacent socket.

This shows the Boot EPROM (2 x 2716) of which only 256 bytes is used. This runs at reset - if a program is already resident in RAM, it just jumps there. Otherwise it does a memory test to work out the RAM size, then downloads code from the Electron and runs that.

Glue logic. A pair of good old LS138 decoders for the RAM, plus some other stuff for ROM and I/O decoding. One of the 74LS74 flipflops is used to effectively move the reset vector to $800000. After reset, the boot rom is temporarily mapped to $000000 instead of RAM. As soon as the first access is made with A23=1, the map reverts to normal, with the boot ROM as $800000 and RAM at 0.

I/O devices. The chip at the bottom, partially obscured by the veroboard, is the 68B21 PIA which connects the board to the Electron. The Veroboard module contains a 6522 and 6850 UART. The 6522 originally plugged directly into the main board, but in order to fit in a UART I added this extension board, which plugs into the VIA socket on the main board.

This is the 1 metre long 50-way ribbon cable which used to connect the Electron edge connector to the interface board. You can get away with murder when running at relatively low speeds...

This is the entire setup as it currently exists, with the Electron + new interface and memory board + 68000 board.

Version of schematic with buses attached. It's a lot harder to draw than the one without and I'm not convinced it's any clearer. But anyway here it is.