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.