Friday 29 March 2024

Expansion Board revE Bring-Up and Shake-Down - Part 1

The revE expansion board and bridge board (that connects it to the MEGA65 main board) have arrived, as have the remaining components that I needed.  The PCBs arrived within 72 hours of shipping from China which is a new record for me -- they were even delivered on a Sunday!

I've already spotted the first stupid error I made: J6 on the bridge board has been placed next to J13, when it should have been about 15mm to the right, to line up with the other power connector on the expansion board. Oh well.

I'll start by putting the connectors onto the bridge board, and confirm that it has comfortable fit to the MEGA65's main board on all the connectors.  It connects the JTAG, floppy 34 pin and floppy power, and also J19 on the MEGA65 R4+ boards (including of course the R6 boards that are shipping around the middle of this year). J19 is a break-out of the 3.5mm audio plug on the MEGA65 main board and allows us to also deliver the audio to the C64-compatible analog A/V plug on the expansion board, without requiring extra FPGA pins and another DAC on the expansion board.

If that fits, I'll then put the connectors except for J15 on the expansion board (which is the one that is supposed to connect to that J6 that I put in the wrong place), and make sure that that all fits, and that the spacing of the PMODs is correct in that configuration for the existing PMOD connector boards to also comfortably fit.  If that all works, I'll be pretty happy for a starting point.

And it does by and large fit:


It's still a bit tight to fit it all together, but I think this is mostly down to the tolerance of the connector placement.  This really isn't surprising for something hand-assembled, and that is effectively pinned in multiple directions at the same time.  There is probably some further refinement of the relative connector positions, but I don't know that it is worth pursuing, as the errors in connector direction and position that result from hand-soldering are already the most significant factor.  You do have to take care when soldering the connector to make sure that they are sitting flat against the PCB! 

Fitting the boards together is best done by connecting the bridge board to the expansion board, and then connecting that pair to the main board. Only after that should the PMOD connector board be fitted, and as absolute final step, screwing the expansion board into place. I'll probably make a video showing the process once I have finished assembling the boards.

So I think I can now safely add the missing components on to the expansion board and start testing that. I'll test the ESP32 on the bridge board after I am happy that the latest expansion board revision is good.  

Actually, I already have enough components on there that I can test the TE0790 JTAG relay... If I can find where on earth the TE0790 has gotten to, after I've been plugging and unplugging it from boards over the past few weeks. And it works fine for both JTAG and serial communications :) I'm really happy, as this was the biggest risk.  First, because on the previous revision it didn't work, and second, because it would have been easy for me to get the pinout reversals not cancelling each other out that I put on the bridge board to further simplify the wiring.  I'll test it again once we have the ESP32 fitted, but for now, it's working just fine, and has me a lot happier.

Meanwhile, it's out to the shed to solder on the remaining components, and pull the chips out of the previous prototypes and re-use them on this one.  That's all done, and I now have the complete assembled board in my MEGA65 R5 test machine.  I can power it on without any smoke coming out, so that's a good start :)

So now to test the various ports to make sure that they all still work.

First, we have the A/V port. I have colour PAL signal coming out, which is good. I added jumpers to allow me to enable/disable and completely disconnect the low-pass filter circuit that I added on the revE in case it didn't work, but also so that I can compare the picture quality with and without it. And the result is that there is no perceivable difference.  This is likely the case because the monitor is already internally doing a similar low-pass filter.  Anyway, it's still safer to have the filter in there for older monitors.

But the fact that the A/V output still works says that I got all the other changes right that I made for this: The resistor ladder is now only plumbed with 2 bits per channel instead of 4, and uses 2x 1K Ohm in serial to get 2K Ohm and 4x 1K Ohm in parallel to get 250 Ohms. So there are quite a few changes from the revD, and the output looks at least as good as it did on the revD. 

Now, it has to be said that this economical approach of using any resistor ladder and the approximate signal processing that I am layering on top of that still isn't perfect, and I don't know where the limit of the hardware design I have made is versus how much further improvement is possible in the VHDL by producing a better composite video signal, nor how much of a difference the monitor is making in all of this. The gradient of blue values actually looks to be really quite good, while red and green have some weirdnesses in them, and the colour is generally a bit under-saturated which make me think that the problem is really in my composite generation VHDL, rather than a limitation of the hardware circuit. In theory changing some coefficients in the calculations for that should improve that quite a bit.

So anyway, the video output is more or less as before, and thus confirmed working.  I would like to test the audio relaying via the bridge board, but I'll need a separate monitor or TV with an audio input to really test that. 

Meanwhile I've also confirmed that the tape port still works, with Tunnel Vision successfully loading on first attempt from the old tape and datasette I have here, and thus the ring buffers must still be working. A more thorough testing of the user-port again would still be a good idea here, but that can happen later.

Maybe I'll next test that the internal floppy drive still works with the relay via the bridge board, and that the floppy cable origami is all laid out appropriately in terms of where I moved the floppy connector to on the expansion board to facilitate this. The cable routing is now much easier... The only problem is that the floppy drive doesn't seem to be working.  I'm guessing that I have something in the relay board routing of floppy signals wrong -- like tying all the signals together as GND and vice-versa from having the signals and GND sides of the connectors flipped.  I'll have to investigate that. Time to investigate this. 

Step 1: Does the floppy drive still work fine when connected directly to the MEGA65 mainboard - yes.

Step 2: Test it again with expansion board to make sure I'm not imagining the problem.

Actually, Step 1.5: Look carefully at all the boards to make sure I had the signal pins on the correct sides of the connectors and notice that I hadn't soldered half the pins on one of the connectors!  That seems highly probable as the root cause :)

Let's give that a go after I give it a quick talking to with the soldering iron... and that indeed seems to have fixed the problem.  The disk I have in the drive has a read error, but that is behaving the same both with and without the expansion board connected, so it's probably fine. But just to be sure I'm going to try reformatting the disk. Hmm... BASIC65 refuses to format the disk -- even without the expansion board connected, i.e., just the way it used to be.  So I've tried formatting it using my test utility, and it looks like one side is totally fine, but the reverse side is refusing to read.  Is it that my drive has dropped a head or something else? 

Yup -- looks like my internal drive has dropped a head! Using a different drive  Well, I have flogged it pretty hard. It might be possible to clean the head or something.  The main nuisance is that the eject button for the MEGA65 assumes an ALPS drive, as they eject mechanism are in slightly different positions on all models of drive.  I might have another ALPS drive lurking around, which would be the convenient solution to that. Otherwise I'll have to stick with a half-working drive in my MEGA65 until I make the working M1565 controller board, and can then use an externally connected drive in place, or alternatively pickup another ALPS drive when I next visit the folks in Germany.  Anyway, let's call this mystery solved.

So now I think it's probably safe to solder on the ESP32 now, which needs to happen before I can really screw everything into place permanently, as to remove the bridge board you really need to first remove it and the expansion board from the case, as its quite difficult to separate from both the mainboard and the expansion board simultaneously. 

I've soldered the ESP32 on. This is a bit fiddly, as it is a surface-mount module. But fortunately it has big enough pads that are crenelated rather than a nasty ball-grid array that would require a reflow oven. The only pad on the underside is the thermal transfer pad.   The holes for that are a bit small on this revision to easily wick solder through by applying solder to the reverse side. So I've logged an issue to enlarge the holes on the next revision.

Now, for testing the ESP32, I was quite conservative and added in a bunch of ways that I can try to talk to it. This includes a TE0790 compatible header that can be directly connected to the ESP32 UART pins:

Basically we can connect via the J6 connector that goes to the MEGA65's PMODs, or we can communicate via the TE0790 header if we put the right jumpers on J3, which is there to allow for if I got the TX and RX around the wrong way, which Sod's Law says would be the case if I hadn't added in the ability to switch it around. 

This TE0790 option is there so that I don't have to get a bitstream working first -- I can confirm that the ESP32 is talking over the UART without having to do anything else. Well, apart from ensure that the WIFI_EN line is set correctly to turn the unit on. According to the datasheet, this pin is active high. 

Now, by default that line is low from the ring buffers, which by Sod's Law is the case, since I failed to add a way to reconfigure that line with jumpers. This means I will need to connect the PMOD board after all, and make sure that the bitstream I use doesn't drive the ESP32 RX and TX lines. Ah, except that because of what a good friend of mine would call a Self-Correcting Stuff Up, the WIFI_EN line connects to the expansion board via that header I put in the wrong place, so it's currently not being driven, and I can just jumper it to 3.3V if I can find a convenient source somewhere. The only possible source is the TE0790 right now, because the 3.3V supply would normally come from that same header that's in the wrong place and thus not connected.  Well, I could connect just the 3.3V and GND pins of that connector. That's probably a better and easier solution.

... except that it isn't running. Poking around, it looks like my hand-soldering of the pads hasn't been an unmitigated success. The WIFI_EN line at least seems to not be connected.  The 3.3V power pin seems to be fine, though.  I guess I'll pull the board back out, and probe all the solder joints to find the ones that need reflowing, and see if I can't fix those without bridging others. This would be a great time to use the HDMI microscope, but we have currently lent it out to our kid's school. Oh well.  Maybe I should use the hot air gun to reflow it...

In the end I used the "lots of flux on everything and wipe the soldering iron sideways along the row of pins" trick, which works pretty well. I will make the pads for the ESP32 bigger though, on the next revision. That will make it much easier to get decent soldering iron contact onto the pads, which are otherwise mostly covered by the ESP pins.  The RF shield on the ESP32 is also connected to a few of the pads which makes them really hard to reflow, but such is life.

Okay, that has it booting, because I can see action on one of the UART pins. Now let's see if I got them around the right way :) And I did! 

I can now see the ESP32 stuck in a boot loop via TE0790 serial connection. This will let me debug that quickly, directly from my Linux machine.  My best guess is that one of the bootstrap pins is not set correctly, and it's trying to boot from some odd method, or that it needs initial flashing, in which case, again, the TE0790 will make that much much easier.

This is the message the ESP32 keeps spewing out when I have WIFI_EN set high:

rst:0x10 (RTCWDT_RTC_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)
configsip: 0, SPIWP:0xee
clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00
mode:DIO, clock div:2
load:0x3fffeba4,len:4
load:0x4009f000,len:3248
entry 0x4009f574
�OHAI�ets Jul 29 2019 12:21:46

I am now working to plumb this all through so that the ESP32 UART can be accessed from the MEGA65 core via the buffered UART interface at $D0Ex. That interface has 8 buffered UARTs, designed for exactly this kind of thing, especially for the future hand-held that will have a bunch of UART peripherals, e.g., for the cellular modems).  I've also added $D0E7 to allow the control of the ESP32/accessory enable in bit 0. 

This is already quite a long post, so I'm going to wrap it up here, and leave the following for the next post:

1. Test ESP32-enabled bitstream built ok

2. Test ESP32 "Accessory enable signal" on $D0E7 bit 0

3. Test ESP32 UART on buffered uart #0 (TX/RX swap?)

4. Load AT firmware on ESP32

5. Test simple operation of ESP32

6. Plumb FPGA PMOD lines for UART to buffered serial port and test from BASIC65?

7. Test C1565 port direct lines can be controlled

8. Test C1565 port direct lines can be read

9. Test C1565 port ring-buffered lines can be controlled

10. Test audio relay via bridge board 

That list is as much for me to not forget what needs doing as much as anything else -- but if anyone wants to tackle any of those steps before I have the chance to attack them, drop me a line. This is a community project after all :)

M1565 External Drive Controller Board Design

As part of the work on the MEGA65 expansion board we are going to have a working 1565 external drive port -- well almost. I have made the 1565 port on the revF board use a 9-pin instead of an 8-pin mini-DIN, so that it can also power the drive. 

We'll call the enhanced port and external drive specification the "M1565".  The M1565 port is designed to talk to an original 1565 using a special adapter cable -- much like we changed the MEGA65 cartridge port from the C65's funny one (which is quite similar to the Plus/4 cartridge port) to a C64-compatible one to make life on the MEGA65 nicer.

But to test the M1565 port we need an M1565 drive! So I have designed up a little board that can connect to a conventional 3.5" floppy drive (or for that matter, a 5.25" one) and talk an enhanced version of the 1565 serial protocol.

The original 1565 protocol doesn't allow you to detect if there is actually a unit connected, nor to identify if its a 3.5" or 5.25" drive (the 1565 was designed only to ever be a 3.5" drive).  This would let us have a 1541-format compatible external drive that was as fast as the internal drive. It would also let me experiment with seeing how much data I can fit on a 5.25" disk some time, too :)

It would also be nice to know if the drive is a DD, HD (eg 1.44MB 3.5" or 1.2MB 5.25"), QD (eg SFD1001 style mechanism, if I remember correctly), or ED (eg 2.88MB 3.5").

We'd also like to support having more than one drive daisy-chained on the port, since the controller supports up to 7 external drives, and also to be able to write-protect the drive competely, e.g., if you are using it to archive disks.

This means we need some dip switches on the drive, as well some way to read those bits of information.

Fortunately the 1565 serial protocol has an unused status bit. I'm hijacking that to allow reading a serial bit stream, one bit per frame of data. This will also let us tell a 1565 from a M1565, as the 1565 will return all 1s, while this can only happen if the M1565 claims to be device 7 with a write-protected 2.88MB ED 5.25" floppy drive -- a drive that doesn't exist.

The logic for this is fairly simple, and I use the RESET pin on the 1565 port to synchronise this bit stream.  I'll go into more detail when I implement the communications protocol. For now, I'm just trying to get the PCB ready to send of for fabrication with a couple of other ones I am ordering, so the description here will be uncharacteristically short.

The other nice thing I have implemented is to make it work with either a twisted or straight-through floppy cable, since each board can connect to only a single drive.

This is what the prototype board looks like right now. Once again its designed to be all hand-solderable with no surface-mount components. 


Note that it is too long to fit in a real 1565 case, because that's not my objective right now.  The form-factor doesn't matter so much for testing. So I've just made the board the same width as a 3.5" floppy drive, and with those two bottom holes in theory lining up with the screw holes in the bottom of a 3.5" drive and placed appropriately that it should be possible to easily connect a short 34 pin data cable with the drive sitting there. We'll see how it goes when the boards arrive.

So that's really about it for now.  Hopefully I'll get the blog post out for the recent work on the expansion board and friends shortly as well.  There is still more testing required for that, but it's all looking quite promising, and some folks in the USA and Germany will be building their own prototypes of that soon to test, and will probably also want to build up one of these boards, too at some point :)

Oh, I should say that the KiCad design for this board can be found at  https://github.com/MEGA65/mega65-r3-expansion-board/tree/master/external_drive_board for the curious.

Sunday 25 February 2024

Expansion board revD and new connector PCBs

Spoiler: This is the new revE expansion board, and matching bridge board to connect it to the MEGA65 motherboard.  Read below for the full story and adventure as usual, including to find out what that big hole in the bridging board is all about...

The new revD MEGA65 expansion board PCBs arrived today, as well as the prototype connector PCBs to replace the need for cables to bridge between the expansion board and the MEGA65 motherboard. Yay! So now it's time to see how well I did with the various things I was trying to fix / implement.

First, the hole positions on the revD expansion board are essentially in the right places, although I realised that I still missed one whole hole in the motherboard. Fortunately it's not in a position that will cause physical interference, so I'm going to ignore it for now. We'll call that a victory. 

Second, the thin connector PCB that joins the PMODs of the MEGA65 to those of the expansion board is indeed thin enough that it doesn't cause physical interference with the MEGA65 keyboard, which was a bit of a worry.  So that's another good victory. You can see from the shadow in this photo that there is clearance between the two, and that's without the connector PCB being fully inserted, which will increase the free space. This was a pain to photograph, because the inside of the case is in the dark, of course. So I had to use the flash, which resulted in annoying external shadows. But as said, the connector PCB, the thing with the two sets of 12 pins poking through, is well and truly clear of the keyboard PCB, i.e., the big green PCB covering most of the trapdoor.

We can also get a general idea of how the various boards will fit together in the picture below:

The expansion board sits in the bottom of the case, as you'd expect, and then the thin connector board joins the PMODs on the front edge of the two boards, and then the other bridge board connects the JTAG, floppy connectors and power connectors between the MEGA65 main board and the expansion board.  As you can probably already see with that PMOD connector board, the relative positions of the connectors is not quite right...

In fact, almost all the connectors on both boards are not correctly located. I did try during the initial design of these boards to get all the measurements right, but I failed fairly dismally in the end.  I'm a bit annoyed with the result, partly because I can see several of the problems that I really should have been able to pick up during the design phase, as well as others that were always likely to be a bit tricky, but I had tried to get right by printing pieces of paper with the PCB outlines and connector positions so that I could validate them before manufacture.  It's probably not surprising that errors of upto about 1mm remain after the paper method, as it was quite hard to line things up when the MEGA65 main board is fully populated, and I didn't have a printable version of the bare board to do the paper trick for that.

All in all it's ok, because much of the point of making these prototypes was to identify exactly this kind of issue, and the chances were slim that I'd get them _all_ right first time. However, getting at least some of them right first time would have been nice... What I am going to do, though, is make the changes to the bridge and connector PCBs, rather than the expansion board PCB, in the hope that I don't have to change the expansion board PCB, partly because it's more work to do so, and it would be nice to not waste those boards that I have had made.

So I soldered some connectors on to some of the boards so that I could work out the errors in the positions, especially between the MEGA65 motherboard and the expansion board.  I'm noting the required changes down as I go:

P2 - move right approximately 0.5 mm

J9 - move left approximately 0.75 mm

J10 - move left approximately 3.0 mm

JB1 - move up approximately 0.5 mm

JB1 - move right approximately 0.5 mm

J1 - move up approximately 0.25 mm

J1 - move right approximately 0.5 mm

J4 - move left approximately 1.0 mm

J4 - move down approximately 2.0 mm

J2 - move to have the correct relative position to J4.

JTAG RELAY - move to have the correct relative position to J4

All of those "approximately" measures are those that relate to the relative position of the MEGA65 PCB and the expansion board PCB, and/or the unknown exact relative positions of the connectors on the MEGA65 motherboard.  Some I can deduce from the drawings that I have managed to find (and I retrospect should have found and done before sending the PCBs off to manufacture...) such as:

J1 should have the holes centred horizontally compared to J3, based on drawings of the MEGA65 main board.   But vertical distance relative to J3 cannot be determined.

Well, that's actually the only one I can be certain of. 

P1 and P2 should almost certainly be 0.9 inches apart, as they are based on 2.54mm = 0.1" spacing.

J9 and J10 should also be similarly aligned to 0.1" of an inch, although they seem to be 0.8" apart, rather than 0.9" apart, which I can at least verify from the expansion board PCB. But I'm still relying on hand measurements to work out their horizontal displacement relative to P1.

I just don't have the drawings to improve the rest. So I'm just going to have to trust my measurements of the errors, and try to get those accurate enough, that the connector placements all fall within acceptable tolerance.

I've now gone through all the changes, and I think I have everything correctly placed. But then, I did last time, too.  I'm going to sleep on it, and check it all again in the morning.  I might also see if I can't relate the positions between the MEGA65 main board drawing and the expansion board PCB using the mounting holes in the case, as they do provide an absolute reference.  I just need to make sure I measure relative to one of the holes that is well centred, rather than H3 and H9 that are a little offset to one side.

Well, it's another day, and I've converted the PMOD connector board to 2-layer instead of 4-layer, which reduces the build time to ~24 hours instead of 4 - 5 days and ordered the two boards as is, as I needed to put in an order to PCBway, anyway, for some C64 cartridge break-out boards to debug an unrelated problem.  So I should have the new boards within a week, probably on the 29th or 30th Jan.

The conversion to 2-layer for the PMOD board required the board to be a little wider, but it should still comfortably fit in the case with a couple of millimetres of clearance between the edge of the board and the bottom case.

Anyway, they are ordered, and should be en-route to me here in Australia within 24 hours, and at my door early next week.  I'll continue this post when they arrive.

The boards have arrived and they very nearly fit nicely. I can force it all together, but then the screw holes don't line up exactly.  But it gives a nice idea of the final appearance. But I am going to have to re-spin at least the bridge board, and probably the PMOD connector board, too.


I do still like how nice and neat it is when it is all hooked up.  The spacing between each PMOD in a pair of PMODs on the PMOD connector board is fine.  But the spacing between the pairs of the PMODs is about 0.5mm too narrow. It can be forced, but it really is a force.

For the bridge board, it looks like the JTAG connector on the MEGA65 main board side need to be shifted up about 1mm, and the other connectors on the MEGA65 side up by about 0.5mm. I would like to double check that with a bare board MEGA65 board, but I don't have one.  So I've emailed Trenz Electronic to see if I can get exact measurements from their design files.  But the bridge board does fit easily onto the expansion board:

The third and final issue I have seen so far is that I wasn't able to get JTAG working via the bridge board -- the serial interface works on the TE0790, and while the JTAG interface gets detected, every time I have tried to send a bitstream via JTAG it has failed.  So I'll need to investigate that further.

The first thing to try is to use a cable to do the JTAG connection instead of the bridge board. That way we will know if the revD expansion board can do JTAG at all. If that works, then I'll suspect the bridge board. If it doesn't work, then the expansion board will need another re-spin.

Interestingly, with a cable instead of the board, I can't even get the JTAG adapter to be recognised on the revD expansion board. I'm suspecting that the more circuitous routing on the revD expansion board for this connector is causing problems.  But that shouldn't stop the JTAG adapter being detected, only prevent it from succeeding with JTAG operations. Squeezing the cables around I can get the JTAG device appearing, but the JTAG communications are still thoroughly messed up.

I think the solution here will be to put the relay connector much closer to the TE0790 connector. I might also try putting the header for the TEI0004 on the revD board I have assembled, and test that, as it is at the end of the traces, so should not have any reflection problems.  It might in fact be the presence of that connector that is pushing things over the edge.

Hmm, I found one problem with the cable: One of the pins has broken the little housing it is in, so it was only making intermittent connection. That's probably why the JTAG interface was only being intermittently detected. 

So, back to the JTAG not working to load a bitstream, if I have a TEI0004 fitted and connect the cable to where I would have the TE0790 normally, then I can push a bitstream over JTAG without problem. The serial monitor interface also works. This results in a short and direct path between the TEI0004 and the off-load from the expansion board, as they are basically next to each other:

 


So now let's try moving the cable to the header where it is supposed to go. In this configuration that path will still not have reflection problems, because it will still be linking end-to-end over the circuit path, but it will have the more convoluted routing in the path:

And that works fine, too, being able to push a bitstream to it.  So that's a convenient enough work around for my test board.  But I would still like to get to the bottom of this problem, as the reflections weren't a problem with the previous revision. My gut feeling is that the combined impact of the reflections from the traces to the TEI0004 socket and those from the vias and other routing changes that I made are enough to tip it over the edge.

Now I should solder up another bridge board with JTAG relay headers and confirm that it works with the bridge PCB, rather than the cable.  I'm not expecting any problems, as the bridge PCB should result in better not worse signal integrity. But for completeness I should check this. And it works!


Now I want to confirm that the reflections are the problem here, by soldering the TE0790 and relay connectors onto an unpopulated revD expansion board, but only after cutting the traces to the TEI0004 header.  If that makes it work, then we know at least one of the factors involved -- although the worsened routing must be having an impact as well, since the TEI0004 header was fine to be connected on the revC board. The challenge is going to be accurately cutting those traces. We'll see how I go, but maybe after lunch.

I had a quick go, but I don't really have the tools on hand to do it confidently.

Anyway, as much as I might be trying to avoid it, I think the solution is that I need to do another revision of both the bridge board, but also the expansion board itself.  The PMOD connector board will be okay as it is, because I can move the PMOD connectors on the expansion board to correct for the placement offset.

What I think I need to do is to move U6 and U7 towards where the TE0790 relay header is currently located, and then move the TE0790 relay header to be as close as possible to the TE0790 connector itself.  It's also an open question as to whether I leave the TEI0004 connector on the expansion board, as I think most people have a TE0790, anyway.

Reworking the expansion board will let me do a couple of other helpful things: First, if I test the A/V output lines with just 2 resistors, and doing the 8x over-drive trick that I do on the least significant bit, and confirm that this works, then that will let me free up 6 IO pins.  I can then use some of those to directly connect the C1565 serial link without going through the ring buffers.  And the left over ones I can route to another header to the bridge board, and perhaps stick a WiFi enabled ESP32 on the bridge board, for the folks who would really like to have a built-in WiFi interface for the MEGA65.

The first step is to make a bitstream that just drives the 500 Ohm and 8x 500 Ohm = 4K Ohm resistors in the A/V outputs to see if we still get decent video quality.  I'll just ignore the other 2 resistors for now. Let's start with our test-pattern on digital video output as reference:

So we have a set of nice colour gradients and colour bars. Now with our existing 4-pin DAC implementation:

The camera doesn't really capture it particularly accurately. But it's pretty clear (and totally expected) that the colour reproduction for composite video is much worse than a puree digital video output. For real-life use, it actually looks not too bad, at least as good as a C64 on a real TV did back in the day, and probably on a par with component video output to a proper CRT monitor -- and this is with the MEGA65 just producing a single composite output. With separation into chroma and luma channels, it should be better again. I just haven't implemented it yet.

But dropping to 2 pins only results in a much worse outcome, with colours distorted and quite washed out:

Either we need to increase the frequency of the over-sampling, or we need more pins, or both.

Thanks to some help from the CVBS community, I looked at this nice calculator to design a low-pass filter for the A/V output: https://markimicrowave.com/technical-resources/tools/lc-filter-design-tool/, but I'm not totally confident working with filters. For example, if we are using a ~500 Ohm based resistor ladder, does that mean that our input impedance is ~500 Ohm? I think so, but I'm not totally sure.

So I think the step before that is to see how 3 bits of output performs, without filter or over-sampling the bottom bit.  If it turns out to be enough for good colour PAL reproduction, then that's a convenient solution to freeing up a few pins.

Ah, except in the investigation I found that I am probably not looking at the composite channel at all, but rather at the luma channel, and it's just leakage between traces causing a very low-saturation colour effect on the signal.  That is, I'm probably connected to the wrong pin on my video output cable. Also, the cable is connected to the revC expansion board, which I recall now has an issue with one of the channels.  

To work around this, I'm going to do something that I had intended to do anyway, which is to make each output channel configurable. This will also allow the board to output composite, S-Video, component video and other formats in future.  That's now synthesising, and will allow selection of each output on the A/V connector independently, initially just from chroma, luma, composite and left and right audio. This will be via $FFD8000-2, with the lower 4 bits of each register selecting the source.  I'll document it further in future.

In the process I also noticed some bugs with NTSC colour generation, and that I was not actually producing a pure luma signal, except when the MONO bit of the VIC-III was enabled.  I also messed up the source select logic, so that any IO write would update the source, rather than just one targetted at the correct address.  So reconfiguring with all those fixes. Will be nice to see if it fixes the weird NTSC colour problem issue (beyond NTSC's normal colour weirdness ;)...

Well, it didn't fix the NTSC problem, but it does look like I can select the various outputs on the various channels of the A/V plug now, which is good. So now to try again to reduce to 2 pins with 3-bits per pin.  And the result is much better. The colour is still a bit washed out compared to using 4 bits directly, at least I think so. But it is way better than before when I had stuff things up in various ways. To get an idea of the difference:

The images in the left-column use only 2 pins each, with the 8x over-sampling used to get 3 bits from each pin, for a total of 6 bits of resolution. The right-column uses 4 pins, with three pins directly connected to resistors, and the 4th pin using 8x over-sampling to get 3 bits instead of 1. The result is 1+1+1+3 = 6 bits of resolution. In other words, the two should be effectively equivalent in terms of output.  

Now, my camera doesn't really do a perfect job of capturing the colour, or all of the video artefacts for that matter.  In particular, the colour gradients are much better in real-life, and the colour intensity is also a bit better. At least with the DELL monitor I am testing with. With real CRT monitors, the results could be totally different.

Anyway, the overall difference is a bit reduced colour saturation and brightness when using only 2 pins.  I have every reason to believe that those can be corrected in VHDL, at least partially.  Thus I feel safe in moving to only 2 pins per colour channel, and thus recovering 3 channels x 2 pins = 6 pins total.

I had a problem where the monitor was not getting VSYNC or correct HSYNC, and I wasted quite a few hours chasing my tail on this. In the end turning the monitor off and on again fixed it. Of course, this means that something must still be a bit marginal.  To help debug that, I have added sawtooth and sine wave test signal sources to the A/V output, so that I can verify that the resulting waveforms looks fine.  

The complication for me to evaluate this, is that my oscilloscope has a bandwidth of 100MHz, which means that it is not integrating the over-sampled signal as much as I would like, and as much as I expect typical CRT monitors will do.  That said, the sawtooth waveform already looks pretty good. The sine curve had some stupid errors in the generation, so I'm resynthesising that right now.  As mentioned, the higher bandwidth of the oscilloscope means that we will see oscillation around the mean point of the signal.  

That said, as the images below show, it's still really not that bad:

First up, we have the saw-tooth waveform:

There is more noise at low values, which is not so great, presumably at the level where only 1 pin is really being active.  Also, it's not totally linear, but it's still not that bad.

Then for the sine-curve we get a really nice clear sine waveform visible, again with noise, especially at lower absolute values:

If we zoom in on the time domain, we can see that the noise is substantially caused by rapid oscillations, i.e., the over-sampling method we use to generate the signal:
The oscilloscope is showing an approximate frequency of this oscillation of ~65MHz, which is a bit of a mystery, as our pixel clock rate is 27MHz, so I'd expect it to be an integer multiple of that, but things are never that simple. Anyway, what it clearly shows is that if we do add a filter, we would like at least 10dB of attenuation by 2x27MHz = 54MHz to really smooth this out. Anyway, it's enough for our purposes right now.

Otherwise, the main issue with the video is we have a bit of a red tint on the composite video, so we will need to adjust the coefficients that control that at some point. That doesn't require changing the hardware, so that's good enough for now.

A more annoying issue is that the expansion board is causing spurious resets, presumably because it thinks the user port /RESET line is being pulled low.  This is despite the /RESET pin on the user port seeming to be sitting comfortably at +5V the whole time. This makes me think that maybe the ring buffer for reading the pins is a bit wonky.

My best guess here is that the latching of the read ring is a not rock-solid. What I should be doing is reading the previous bit on the instant just before I clock the next bit. To debug this I have added a few things: 1) I have made the controller check that the ID lines are indeed one high and the other low, which should prevent framing errors from sneaking through; (2) In the process, I have made it easier for future revisions of the expansion board to offer different ports; (3) Added the option to mask the user port reset line, in case it is still causing problems; (4) Count the number of reset events on the user port, in case that is the problem; (5) Allow direct reading of the input ring from the expansion board; (6) Generally document the registers that control all this stuff.

With (1) in place, the spurious resetting has totally stopped, so I'm guessing that was the problem.  I'll leave it at that for now.

Meanwhile I now have the dimensions sheet for the MEGA65 main board, so I should be able to refine the positions of the connectors to the MEGA65 main board. That also reminds me, that on the R4/R5/R6 boards, we now have an analog audio output header that is conveniently located enough that I should be able to make it an option to pipe to the audio pin of the analog video port, which is an other advantage.

So all in all, I think we can add the WiFi adaptor, as well as improve the plumbing to the C1565 port. This will be in addition to the correction of the connector locations, and re-routing the TE0790 relay connector so that JTAG can work reliably.  That sounds to me like more than enough changes for one revision of the board.

So let's look at those connector positions, and work out what needs adjusting, and by how much, now that I have the ground-truth relative positions of the MEGA65 main board. But before that, I really should double-check that everything that did work on the revC still works on the revD, and that the positional corrections I made for that are correct.

One thing I noticed is that the floppy connector on the expansion board lines up with one of the screw points for the floppy drive:

This isn't a show-stopper, but it does require more cable origami to get the cable to be able to get into the connector:

I can move the header on the expansion board towards the front of the MEGA65 by 18mm to clear it. This will slightly increase the cost of the PCB, but it shouldn't be too tragic. The main question really, is whether moving the cable that far forward will collide with the back of the keyboard.

I can test this by purposely mis-seating the floppy cable, and seeing if I can still close the case. Each position is a movement of 0.1" = 2.54mm. So 18mm = 7.1 positions, so I'll try 7 positions.

It's close, but doesn't quite fit. Now, part of the reason for that is that the edge of the keyboard PCB is still just over the connector. If I move the floppy connector to the right 7mm, it should clear it comfortably. This will require extending the right edge of that part of the PCB, but there is comfortably room to do this, so that's fine.

I also double-checked that there is still space for the TE0790 behind the floppy cable, as I did move that down on the last revision. It does still fit, but with not too much space to spare!

The tape port still works, and I'll assume that the user port still works, too, since they are both on the same ring buffer loop. I do get errors loading from the test tape sometimes, but at least 1 out of 3 times I am able to correctly load a game from tape that uses a tape fast loader. So I'm going to assume for now that it is likely the age of the tape and datasette, rather than the expansion board that is to blame here.  I might later experiment with adjusting the ring buffer clock speed to see if it makes it better or worse.

I'm now going through the process of updating the schematic and PCB for the various changes. 

I'll start with simplifying the resistor ladders for the video output channels: Instead of using 4 pins for each, I'll use only 2, with 500 Ohm and 4K Ohm, constructed using only 1K resistors in series and parallel, which will simplify the bill of materials. This means each channel now looks like this:


That's a net increase of 2 resistors per channel, which I'll need to fit on the PCB, but that should be ok.  

I'd also like to add provision for optional low-pass filters on the three channels.  Based on the oscilloscope probing, we need to have at least 10dB roll-off by ~54MHz.  I'm using the great filter design tool at https://markimicrowave.com/technical-resources/tools/lc-filter-design-tool/.  The output impedance of analog video is normally 75 Ohms, and the input impedance is approximately the resistance of the lowest resistance rung of our resistor ladder, so 500 Ohm in this case.  Out cut-off frequency can be set to 13.5MHz, the maximum channel bandwidth for a PAL or NTSC signal -- in reality it probably only needs to be half that, but it's certainly enough.  So let's put the appropriate parameters into the model:

and see what the response of the filter looks like:

Well, that looks pretty okay to me. The insertion loss below 13.5MHz is about 2dB, which means that about 2/3 of the input voltage will be able to pass through. Then we have about 3dB filter loss below 13.5MHz, so our total loss for the frequency range we want is maybe 5dB. That's a bit more than I'd like, as it means that our output voltage will be divided by about 3.1. Given our output impedance of 500 Ohm and the input impedance of a monitor at 75 Ohms, this means that before the filter, our output voltage should be something like 3.3V x 75 / (500 + 75) = 3.3V x 0.13 = 0.43V, which is already at the lower end of things, since the target peak voltage is around 0.7V.  The filter will divide this by a further factor of 3.1, to give a peak voltage of only ~0.14V, which is really quite low.

We can improve this by reducing the output impedance from 500 Ohms to 250 Ohms, which will bring the peak output voltage up to 0.76V, which is safe without further reduction by the filter, and still allow the voltage after filtering to nearly double to ~0.25V ... except that filters are never that simple. We need to update the filter model to reflect the 250 Ohm input impedance, which gives this response curve:

In other words, even though we have nearly doubled the input impedance (for a gain of ~3dB), the input loss of the filter has increased by almost exactly the same amount! That is, our filtered signal will not have any greater voltage range than with an output impedance of 500 Ohms. Grr! Well, in any case, 500 Ohms over 3.3V = 6.6mA, and 250 Ohms would mean 13.2mA, which is still within the max current limits of the FPGA, so let's halve the output impedance, but add a bypass-able resistor that increases the impedance back to 500 Ohms by adding a 250 Ohm resistance in the path, as well as making the output filter selectable.  

The main trade-off here will be adding yet more components on the board, as it would require either one 250 Ohm resistor (which I don't have in stock), or more conveniently, four 1K Ohm resistors in parallel, but that would take the most space.  The filter also requires 3 components, and then we would have two jumpers to allow the bypassing of the extra output impedance and the filter. So in the worse-case scenario, this would mean we would have the existing 6 resistors for the resistor ladder, plus 3 filter components, 2 jumpers to select function, and between 1 and 4 resistors for the output impedance trim resistors. Multiplied by 3 channels. That's probably more than I can realistically cram in, even given the extra space available from increasing the board size to accommodate relocated connectors.

I thought I would just check the voltage I get on the video channels with a 75 Ohm load, just to be sure. I didn't have a 75 Ohm resistor handy, but I did have a 68 Ohm resistor, which should be fine, just resulting in slightly higher voltages than with a real monitor. I was expecting to see ~ 3.3V x 75 / (500 + 75) = 0.43V. But instead I am seeing a peak voltage of more like 4V instead of 0.4V... which is also the voltage I see when it's open circuit. Ah, I was measuring it incorrectly. It is indeed somewhere around 0.4V, so halving the output impedance to 250 Ohms makes sense, and I won't need the impedance selection jumper and resistor -- just the filter and filter bypass jumper.

So let's start moving things around and see how much space I can free up for the filters etc.  I've also flipped the connector over that carries the JTAG signals to the bridge board, to avoid the need for vias, that would degrade the signal integrity.  The difference in routing is now quite profound with those changes, with the JTAG lines now running simple straight paths, without any vias at all, and no non-JTAG signals crossing the path of the JTAG signals.  I really think that they should have much better signal integrity now. You can see the improved routing between the two 12-pin TE0790 connectors here:

As a reminder of what it looked like before:

There were those two ICs in the way, and crazy circuitous routing to get around them and the existing circuitry. I also moved J8 further up the board, to minimise the path lengths, so I'll have to update the bridge board position of J8, as well as horizontally flipping it (which should also remove some vias on that board, too).

I've also moved the PMOD connectors on the expansion board left by 0.5 mm, so that the existing revD PMOD connector PCB spacing will be exactly correct. Well, I hope exactly correct.  I also adjusted the position of the other MEGA65-board side connectors to try to get it all right.  This was a bit fiddly to work from the various precise and non-precise sources of information I had, and to then put the positional markings on the bridge board PCB layout as measurements, to make sure that I have everything as correct as possible:

You can also see that I have added place for the ESP32 WiFi module to the middle of the PCB:

I have included a complete cut-out zone for the external antennae, located below the straight and direct traces for the TE0790 relay to the expansion board. Note that I have also added an extra TE0790-compatible connector to this bridge board, to allow easy connection and debug of the ESP32 module. That is, the header labelled "ESP32 JTAG+UART (TE0790)" is for that purpose alone.  I've also added a header for the ESP32 sensor pins, in case that turns out handy for something.

I still need to add a few more break-out pins for the ESP32, so that all the bootstrap pins are exposed conveniently, in case I need to adjust them. I've done that now, as well as adding a dedicated ESP32 UART break-out connector for convenience.

I'm thinking that that is probably about it for the bridge board.  Now I need to add the plumbing to connect this to the expansion board beneath it. That's done as well now, using 3 of the 6 lines to connect UART RX & TX, as well as the WIFI_EN line, which needs to be 3.3V.  That leaves only 3 pins for the C1565 interface improvements, which hopefully will be enough.

So let's look at the C1565 interface improvements.  Ideally we want the ring clock and latch as well as the SERIO data pin to be fast by being directly connected to the FPGA pins.  Three signals, three pins, sounds easy. The trouble is that those are all 5V on the C1565 plug, but 3.3V on the FPGA pins, and the SERIO pin is bi-directional.  But let's start with the easy ones: We can just connect the C1565 clock to the expansion board's existing ring clock.  So that just leaves the latch and data pins. 

The latch is fairly straight forward: It's an output only from the FPGA to the C1565 port, so we just need a 3.3V to 5V level converter. If we were lucky, we'd have a spare buffer on one of the 74LS125's, but of course they are totally fully. So we will need at least one more IC.  But before we just go an add another 74LS125, let's see what we need to make the SERIO line bidirectional. We can do the output direction using part of a 74LS125. But for the input direction we need to level convert from 5V to 3.3V. SERIO is output when the latch line is high, and input when low, like this:

2.5.5. F011 Disk Expansion Port Serial Protocol

     +-+ +-+ +-+ +-+ +-+ +-+ +-+ +-+ +-+ +-+ +-+ +-+ +-+ +-+ +--
     | | | | | | | | | | | | | | | | | | | | | | | | | | | | | CLK
   --+ +-+ +-+ +-+ +-+ +-+ +-+ +-+ +-+ +-+ +-+ +-+ +-+ +-+ +-+

    +---------------------------------+                     +--
    |                                 |                     |  LD
   -+                                 +---------------------+

   --+---+---+---+---+---+---+---+---+---+---+---+---+---+---+-
     |LED|MOT|STP|DIR|SID|DS2|DS1|DS0|SPR|DKI|DKC|IND|PRT|TK0| SERIO
   --+---+---+---+---+---+---+---+---+---+---+---+---+---+---+-

So we can in fact control the output control of SERIO using LD: When LD is high, then we want the output enable on the 74LS125 buffer for SERIO.  I'll connect that now, and then think about what to use for the input side.  So the outputs are connected, and that uses 2 of the 3 pins, and I still have one pin free for the input.  So I don't even need to do anything fancy to switch the direction if I don't want to. I can just use a simple "always on" input buffer.

Meanwhile, I am hitting a problem with KiCad 7 complaining about the user port and tape port edge connectors.  Older versions of KiCad didn't have this problem, and it is apparently a known false alarm, but still quite annoying. It seems the two options are to ignore the errors in the design rule checker (which I never like doing), or adding a bit of solder mask back between the each pin on these edge connectors, which is also not that great. I guess I'll have to add exceptions to the design rule checker...

Okay, so now that I have the design rules passing again, I can go back to planning how I am going to read the SERIO line. I think I'm just going to add yet another 74LS125 powered on 3.3V rail and with a 1K Ohm resistor on the input from SERIO, to limit the maximum current to 5V / 1K Ohm = 5mA, which should be fine.

Okay, so I think I have SERIO input now correctly plumbed in. The schematic page is getting a bit crowded, though, so it's not as immediately obvious if I have it right or wrong, which I don't like.  So I'll just have to go over it carefully for now.

I'm going to pull out the 1565 port stuff onto a separate sheet in the schematics so that I can reason about it much more easily. This is the result:

You can also see that the WIFI_EN signal for the ESP32 wifi adapter is also generated by this block. This is because it needs to be 3.3V, and I didn't want to waste a whole FPGA pin on a line that might toggle once every time you start a wifi-enabled program.  

I have used the FPGA pin that freed up to separate the C1565 port clock from the ring buffer clock, so that they can be clocked at different rates. This is to allow the C1565 bus to be slower, which will likely be required if we want to allow reasonably long cables to external drives.

The only problem I hit in the above is that I had a +5V symbol lurking spare after I rearranged everything. I can't see where it is missing from, if I did accidentally drag it when copying something to the new sheet. I did check PCB to schematic parity, and nothing showed up. So I still have zero idea where it came from. Maybe I had +5V attached to a single net twice.  Anyway, if there is going to be a problem with the next revision of the board, this is what I am going to guess will be a likely cause. Fortunately if that happens, it will be easy to bodge a blue wire to whatever pin and a pin with +5V.

So, I'm getting towards the end of the list of things I want to address. The very last thing I am thinking of doing for the C1565 port is to address what I see as a missed opportunity by Commodore at the time: The C1565 port has no +5V or +12V, which means that the external drive needs a separate power pack, unlike on the Amiga.  Modern 3.5" drives don't even need 12V, so we only need to include +5V.  But there are no spare pins in the mini-DIN8 connector. 

Fortunately there are 9-pin mini-DIN connectors, so I can just use one of those. This will even still allow use of a genuine C1565 drive if someone has one. All that they would need would be an adaptor cable. But as there are about 2 such drives in existence, I'm not really worried about even that inconvenience.  Switching the connector over wasn't particularly hard -- the biggest effort was finding a variant of the connector for which I could easily find a Kicad footprint.  This probably means I'm not using the cheapest version of this connector, but I can live with that. I might buy a couple of the cheapest ones, and confirm that they still fit in this footprint, as they should be identical. The datasheets look like this is the case.

What would be great for finally testing the C1565 is for me to design up my own C1565 compatible PCB to go with a standard PC 3.5" floppy drive. I might do that soon, but first I want to finish off this expansion board.

This means we are now up to adding that low-pass filter to the A/V output lines.  As discussed above, a 3rd order low-pass filter should be adequate, like this one:

The 500 Ohms represents our source, and the 75 Ohms the monitor it is connected to, so we don't need either of those. Just the two capacitors and the inductor between them. As a safety catch, I'm going to make the filter able to be bypassed, in case I stuff it up somehow. This will also let me real-time see how the filter performs, if I can easily switch it in and out by moving a jumper. This is how I am planning to hook each one up:

I say planning, because the board is getting a bit busy, and I want the filter switch jumpers to be accessible when the bridge board is fitted, and I don't want any signals crossing those JTAG lines that caused me trouble before. And, I'd ideally like all the filter switches in the same place. Oh, and I want to route lines for the audio pin on the A/V jack, too, so that the audio header on the MEGA65 R4+ boards can be fed directly to the A/V jack if desired.

Well, I succeeded in the end, but it wasn't easy, and I'm not totally comfortable that there won't be a lot of cross-talk on the A/V output lines that might compromise signal quality. But we will have to see.  But if the result is not too bad, then I'll be happy enough, as the idea of this board is that you can build it yourself, not get the most perfect picture and sound possible -- the digital video output and 3.5mm audio jacks are there for that.

Anyway, this is how the board looks now, with, I think, everything it needs:

In the end I couldn't get all the filter jumpers in the one place, so one of them is up to the left of the tape port, where it should be exposed even with the bridge board over the top.  The other two are to the left of the two mounting holes that are below the right-hand side of the user-port. Those are together, but are likely to be covered by the bridge board when fitted.  That doesn't greatly worry me, as after testing is done, those jumpers will either be permanently fitted (or not), and quite likely replaced with simple tracks instead.

Other things to observe on this revision of the board compared to the last one, include the movement of the floppy cable header down a bit as I discussed some time back to make the cable origami routing easier.  Also, just above the MEGA65 logo is the new 8-pin header to connect to the peripherals on the bridge board, primarily the ESP32 wifi adapter and to route the audio signals to the A/V jack.

Speaking of which, I have routed both left and right audio to the A/V jack, even though the C64 only supported mono on it. This is done by using the almost never used "audio in" pin on the C64 audio jack as a second audio output pin.

So the bridge board now looks like this:

I have contemplated making this board 4 layer instead of 2 layer, but I'm not sure that it is worth the extra cost for whatever benefit it might give for signal integrity, given that most of the signals are quite slow, or are simply being routed between pairs of connectors (like the TE0790 JTAG relay).  Si I'll leave it 2 layer for now.

So that just leaves the C1565 drive board before I can place my order for the revised PCBs, assuming I want to do that.  It should be a simple board to design, and with no tricky routing, so I'll give it a quick go, and if it takes too long, I'll just stop and place the order for the other boards.

Someone has already made a replica C1565 PCB that works with real C65s (except for formatting, because I believe the index hole sensor is required to know when to enable the write gate). However, they haven't released the schematic.  Also, Bo Zimmerman has the schematic for the original 1565 PCB. The main tid-bid from that is to know that it uses a 74LS125 to tri-state the F_READ line from the floppy drive when the drive is not selected.

I'll start by adding the 34-pin floppy data connector and 4-pin floppy power connector, and then the 9-pin mini-DIN. Actually, we can have 2 of the mini-DINs and allow daisy-chaining, like with the Commodore serial drives. The C65 ROMs don't support more than 2, but it doesn't mean that we can't. The main limitation will be the current draw from the cumulative circuits on the relatively small pins of the mini DIN connector.  But we may as well see what we can achieve.

Next we need to put a tri-state gate on the RDATA line via a 74LS125.  I'll use a 74HC85 4-bit comparator to check whether the C1565 unit is the currently selected one.  Those are active high, while the 74LS125 is active low, so I'll use a buffer from the 74LS125 to make an inverted driver for that. Or I could switch to an active high buffer like the 74LS126 -- but let's see what the other bits of logic we need require, before making decisions like that.

Next up we will need an 8-bit latch. Going back to our 1565 protocol diagram:

2.5.5. F011 Disk Expansion Port Serial Protocol

     +-+ +-+ +-+ +-+ +-+ +-+ +-+ +-+ +-+ +-+ +-+ +-+ +-+ +-+ +--
     | | | | | | | | | | | | | | | | | | | | | | | | | | | | | CLK
   --+ +-+ +-+ +-+ +-+ +-+ +-+ +-+ +-+ +-+ +-+ +-+ +-+ +-+ +-+

    +---------------------------------+                     +--
    |                                 |                     |  LD
   -+                                 +---------------------+

   --+---+---+---+---+---+---+---+---+---+---+---+---+---+---+-
     |LED|MOT|STP|DIR|SID|DS2|DS1|DS0|SPR|DKI|DKC|IND|PRT|TK0| SERIO
   --+---+---+---+---+---+---+---+---+---+---+---+---+---+---+-

We can see that we need to latch the data word on the falling edge of LD. But the 74LS595 latches on the rising edge. So we need to either invert LD, or find a latch chip that has a negative edge latch. We can probably invert LD using one of the spare buffers in the 74LS125, if we need to.  We also need to gate the SERIO line to only be driven by the drive when LD is low.  The 74LS165 to serialise the drive status bits also needs the opposite sense to work. It really is a pain, in fact, that LD is not the opposite to what they chose, as it would have been quite a bit simpler for the logic decoding. 

The existing replica only needs 4 chips, but that's because they are only doing a single bit of drive ID decoding. I'd still like to keep the option for more than 1 external drive.I could solve this by adding a 5th chip, e.g., a hex inverter, to allow me to invert this signal, but a whole chip to do that is a bit of a pain, when I am only exactly one gate short of what I need.

One option might be to use a 74LS139 2-to-4 decoder, as those have two such decoders, so I could still allow 4 drive IDs (probably the odd ones, 1, 3, 5 and 7), and then use the second one as a make-shift inverter. But maybe I'm just trying to be too darn clever, and should just get over myself and use the inverter.

I think I have a sensible schematic now, and the beginnings of a PCB layout. But then I realised that the reason I was looking at doing this now is because I wanted to be able to make sure the 1565 port would work.  That was an issue when I had some of the control lines on the ring buffers, which would have caused them to be much slower. But now I have it nicely directly connected to the FPGA, so that isn't an issue. 

In short, I can leave that for another time. Which is good, because I've just about run out of weekend. So I'm just going to give the expansion and bridge boards a last going over, and then generate the gerbers to send off for fabrication.

The PCBs have been ordered, so all that's left now is for me to order the last few parts that I don't have laying around, so that they can ship while the PCBs are being manufactured. Normally a 4-layer board takes about 5 days for PCBway to fabricate, and another 4 days or so to ship. So probably I'll have the boards in a couple of weekends time -- which is also about how long it takes for an order to ship from digikey in the USA, because they use FedEx who are a bit slower to get to Australia than DHL from China.

Well, that order is in now, too. So now it's hurry up an wait for a couple of weeks for everything to arrive, and see what silly mistakes I have made on these boards ;) But seriously, I'm hopeful that we are now on the home-run with this, and will have a nice functional and fun expansion board solution for the MEGA65 in the not too distant future... maybe even around the same time that the back-log of MEGA65s ships around the middle of the year...