Tuesday, 2 July 2019

Last day of current MEGA65 development sprint

Okay, so today is the last day of the current MEGA65 sprint.  I am currently trying to get the following things working:

1. UUID serial EEPROM for MAC address etc
2. Real-Time Clock + onboard SRAM
3. Ethernet
4. HyperRAM

And currently having only limited luck with most of them.

The UUID EEPROM has 256 bytes of memory, the first 128 are writable, and the last 8 provide a globally unique identifier that can be used for generating a MAC address for ethernet. This was the easy one: Adapt the I2C peripheral code I wrote for the MEGAphone, and change the I2C addresses, and voila*, I was able to read it.

* Where voila actually means synthesising probably 3 or 4 times to track down all the little errors.

Then it's currently all a bit down-hill.

The real-time clock and its SRAM I have also mapped, and I can read and write the SRAM, which is great, and I can read and write MOST of the RTC registers, which is not so great. Specifically, I can do anything I like, except for set the clock.  Now, there is a register that controls this, and a WRTC bit that must be 1, before the registers can be written to.  And I know I can write to this device, because I can set the register with that bit, and I can even set the RTC alarm, and all sorts of other things -- but what I cannot get it to do, is to set the actual time.  The only clue I have found so far is in an example driver, which sets all 6 bytes at the same time.  So I might have to modify my code so that it does the same, to see if it helps.


Then we have the ethernet adapter.  Ethernet really shouldn't be a problem, as we have had it working in the past.  What I can confirm so far, is that the reset line works, because I can stop and start the ethernet, in so far as I can make the link LED go away, and then when I start it again, it reappears after a couple of seconds.  However, there is no hint whatsoever that the ethernet is actually transmitting or receiving anything to/from the FPGA.  Again, there really aren't any good places to probe with the oscilloscope, to see what is going on.  I'll have to keep thinking about it.
 
Then finally we have the 8MB HyperRAM that will be the expansion RAM of the MEGA65. The HyperRAM is not responding to read requests, and I am not yet sure why. I have switched to using a known-working open-source HyperRAM driver, and have it synthesising (which was a bit of an adventure due to a silly mistake on my part).  It is just timing out when reading, which could mean one of many things.  The chip is a little BGA, so I can't easily probe its pins to see what is happening.  So that's currently stuck.


So the current situation is quite frustrating. I guess I will start with trying to get the RTC working, and think about the others at the same time.

But, the day has got away from us, so these will have to wait until I am home in Australia, and have time to attack them.  But even with these little frustrating bits at the end, it is really pleasing just how much we have managed to achieve: the MEGA65 now runs on real hardware, and is super fun and pleasing to use.  We are currently making a series of short show-and-tell videos showing off the system, which can be found at:

https://www.youtube.com/playlist?list=PLPehmjqZolWDKTSE_cc_ft9jgYQyKZP_f

They are well worth the look, so hop on over and have a look!

Monday, 1 July 2019

Internal floppy drive now working on the R2 PCB, and various other bits and pieces

Oh my, it is already 11pm! So this will just be a short summary of what we have achieved today.


Most of the progress was getting the internal floppy drive working.  We had some more forgotten pull-up resistors that had to be added to the boards, and then to the schematic for the future R3 PCB.  So now you can happily use the MEGA65 CONFIGURE program, which works a bit like an old PC BIOS, to select the real disk drive or disk image to be used on power-up ... and it works!



We wrote a 1581 disk using a PC transfer program, and we can read it happily.  One funny thing we found, was that the drive refuses to read 720K data from a 1.44MB disk, even if the disk has tape over the HD hole.  We have no idea why this is, but for now it just means using real 720KB media.



Anyway, with the disk image, we are able to get a directory and load programs from the drive quite happily.  It could be my imagination, but I think it loads faster than my original C65 did. If so, it is probably due to our floppy controller perhaps being a bit faster.  Not sure. Not that important.  I did time loading a 161 block file, and it took 19.5 seconds, so about 8 blocks / second = ~2KB / second.  That does sound faster to me than the original, which I recall in C64 mode (which is how I ran this test just now) loaded at ~1.3 - 1.5 KB / sec. It could also be luck of the sector order on the disk, too.



Apart from that, we also updated the boot rom to set the audio mixer levels more sensibly, so now the SID audio that was super quiet is now quite loud.  We also fixed the audio channel control settings there, so that you can choose mono (both SIDs on both left and right channels), stereo, and stereo with swapped channels. At some point we will also add these (and the "use real floppy drive" to the freeze menu, so that you can easily change them at run-time.

Sunday, 30 June 2019

IEC port testing / GEOS for the MEGA65 R2 PCB

Just a quick note to say that we got the IEC (1541 drive / printer) port on the MEGA65 R2 PCB working today as well.  This works well enough that we can even boot GEOS from a 1541 drive.



Of course, the native port of GEOS for the MEGA65 is much nicer, with higher resolution and MUCH faster booting: The GEOS load process takes probably less than 1 second.



We have yet to get C128/C65 fast serial working, but all the hardware is there for it.  We will come back to this when we have time. The priority for the next two days remains to test the remaining functions on the R2 board, so that Antti and the crew have confidence of any potential changes required for what will hopefully be the production-ready revision of the board.

Getting the MEGA65 R2 Cartridge Port Working

Okay, so we have the keyboard and disk drive ports both working already, so the next stop is to get the cartridge port working.



On this front there is hopefully not a huge amount that needs to be done.  There have been a couple of pin re-assignments, as well as fixing a couple of issues that we knew about:

1. The FPGA pin for A15 has changed, which is easy to fix. In fact, for many purposes, it simply doesn't matter, because many cartridges only use the lower address bits. Anyway, it has been fixed now.

2. The /EXROM and /GAME lines that tell the MEGA65 to bank in ROMs from the cartridge are now proper input lines. On the first revision of the PCB these were connected to a two-way buffer that was really generally only used for output, so we had to periodically pause the bus and set the buffer to input, and read the lines. This can now be simplified, because the lines are pure input.

Fixing those problems didn't take particularly long. But cartridges were still not quite working.  After some investigation, I found that there occasional errors reading bytes from the cartridge.  Every now and then a byte gets read where some bits are changed from 0 to 1.  It doesn't seem that they switch from 1 to 0, however.  The R2 PCB has pull-ups on the address and data lines on the cartridge port, which the R1 did not have.  Thus it is possible that there may be too much pull-up power, so I have just gone through and disabled all of that work for the R2 PCB.

Of course, that will take a while to synthesise, so I'll try to think about what else could be wrong.  First I wanted to make sure that the cartridge port is not being run too fast: The dotclock is actually running at about 6.25MHz instead of 8MHz. The main clock is however running at 1.2MHz, which could conceivably cause problems.

The slow dotclock is because the pixelclock changed from 100MHz down to 80MHz, so I'll fix that while I am here as well.  What is a real mystery, however, is that the phi2 clock is only 1/5 of the dotclock instead of 1/8th.  I think I realise how this is happening now: The divider is /5 (0 to 4), instead of divide by 8, since the dotclock loop it sits in is counting dotclock phase changes, not clock cycles.

It turned out that the clock was not a problem, but the old logic for the R1 PCB to prime the data lines with charge (because of the lack of pull-ups), which meant that it would take longer for a line to get pulled low -- which is what we were seeing.

Then after this we found a problem where the cartridge_enable line in the CPU is not being enabled when requested, which meant we couldn't actually read the /EXROM and /GAME lines. So we have worked around this in the CPU initially, although the actual root cause is still not exactly clear, as the two locations that clear this flag should only be run under reset, and when the machine is in "secure mode" which is not the default.

After some hunting around this turned out to be caused by trying to keep compatiblity with the R1 PCB, which then confused the VHDL compiler with the way that I was using these signals as outputs as well as inputs.  It actually took quite a few hours to get to the bottom of this problem.



In the process, I also finally fixed the problem with some cartridges not working because they only pull /EXROM or /GAME low briefly on reset, typically with a capacitor.  The boot ROM now pulls the cartridge reset line low for a little while before exiting to boot, so that such cartridges present their ROMs.  This enabled such cartridges as the Epyx Fastload cartridge and Power Cartridge to begin to work. There may be features in them, and many other cartridges, that don't work, but we are getting to the point of having quite a number of cartridges working. Even the Ezyflash works now, although it is mostly rather useless to use a flash memory cartridge on a computer that already has an SD card for bulk storage.



Anyway, this has let us test the cartridge port enough to have confidence that it works physically, and the rest of the compatibility improvements in the future should need to be software/VHDL only.

The keyboard is now fully working!

So, in the last post we reported that we had the keyboard mostly working.  In the meantime, we managed to figure out the remaining problems with the communications protocol, and map the remaining keys.

As a result every key now works as it should, the clicky lock keys illuminate their LEDs, and behave as expected. All of the dedicated lines for special keys, like the left and up cursor keys that live outside of the keyboard matrix on the C65 are also correctly handled.

Suddenly it started feeling a lot more like a computer, now that we could type on it and interact with it.  We could do long-press on RESTORE to get to the freeze menu (reset is now only via the dedicated reset button the left side of the computer).



It really feels very nice.  The work we put into having sub-millisecond latency on the keyboard has really been worth it. There is absolutely no perceptable delay, and it just works as it should.  The indicator LEDs for the LOCK keys work perfectly, and with their clickiness and different tactile resistance, you know with certainty when you press one.  In short, we are really happy with the result, and hope that everyone who uses a MEGA65 will enjoy it as much as we do.


So, now onto getting the cartridge port working...

Friday, 28 June 2019

Getting the keyboard working with the MEGA65 R2 main board

Ok, so now that I can program the three FPGAs that are in the MEGA65 R2 board and keyboard, it is time to try to get the keyboard working.

The keyboard has an 8-pin interface, which we can define however we like.  The same pins are also used for the JTAG interface when programming the keyboard's FPGA.  So to simplify things, I'll use the same pin names as with JTAG.

The protocol will be a simple bit-shifter that shifts out the state of the 70 keys on the keyboard, and also allows shifting in of bits of data/control from the MEGA65 itself, e.g., to control the LEDs.  This can be done easily with four lines, just like JTAG: Clock, synchronisation signal, data in and data out. The MEGA65 will simply run the clock, and periodically assert the synchronisation signal, and then read in the bits of keyboard matrix, and at the same time on each clock tick send out the bits for the LED control.

The keyboard will provide the state of the 70 keys, complete with simulating the held status of the caps and shift-lock keys -- that is, the keyboard will internally keep track of the state of those two keys.

To plumb this through I am moving the layer that handles the widget board that we designed for the Nexys4 boards from deep down to the outermost layer of the VHDL, so that it can be replaced with alternatives.  The new keyboard will then be implemented by creating such an alternative.

This has now been done, but I now have to debug it all, because not surprisingly, it didn't work first time.  Main problem is we don't have an oscilloscope here in the cellar.   So a bit of frantic searching was required for one that was: (a) near by; and (b) not too expensive.  There were some nice ones for <100 Euro, but not near by, and since we don't have that long with me being here, we didn't really want to have to rely on multiple days of postal delivery. We did in the end find a nice 1987-vintage Tektronix 2430A from a University student here in Darmstadt, and with a new probe ("Tastkopf" is my new German word for the day) we now have a suitable setup for probing pins for 220 Euro:



So, the keyboard protocol should have a clock of ~2MHz and syncrhonisation pulses at ~10KHz or so on the keyboard connector, but neither are visible.  This makes me suspect that the plumbing through from the Xilinx FPGA through the MAX10 to the keyboard connector is not right.

To verify this, I have created a test bitstream for the MAX10 that routes the keyboard clock signal from the Xilinx to one of the two on-board LEDs, and then another for the Xilinx FPGA that puts at 40MHz clock on that line, without any conditional logic that could be messing things up.  Hopefully with that I should see the 40MHz signal on the LED pin.

After a bit of fiddling, I have come to the conclusion that going through 2 FPGAs and a cheap oscilloscope probe and into 1987-era oscilloscope is not that conducive to seeing a 40MHz clock. So I instead made the MAX10 wiggle the line at varying speeds, which confirmed up to about 10MHz is easy enough to see, and there is a weak signal at higher speeds. So then it was a case of adjusting the Xilinx test bitstream to produce a signal in the right frequency range, and tada! I had a nice signal.

So now the next step is to pull the new keyboard controller into the Xilinx test bitstream, so that I can see if I can see the signals being produced by that. Okay, so have that in, and pleasingly, I can see a signal.  However, it is only about 20Hz, instead of ~2MHz. Ah, no, actually it is in fact ~1MHz, which is fine:



To give an idea how tricky this scope is in the wrong time-base, here is exactly the same signal, but shown at the wrong time base.  The only real hint that something is wrong is the ripple in the signal.  Of course, someone who was actually educated in electronics rather than picked it up as they went along would probably have spotted that, but oh well. I just have to get used to this oscilloscope not giving a clear indication when it is showing low frequency harmonics if the time base is way out.

Ok. So that's one problem down. Now to see if that signal shows up on the relevant pin of the keyboard connector: Yes, nice clear 1MHz clock on pin 3.  Probing around the connector, I can also see a signal on pin 5, that looks to me like the LED control signal from the computer to the keyboard, which is also in the right place.  The synchronisation pulse is also visible on pin 4, and there are signals on pins 7 and 6, although I am not yet sure if they are correct. It is possible that they are wrong way around.

To check that pins 6 and 7 are correct, I have disconnected the keyboard.  That way only the signals from the FPGA should be visible.  Doing so leaves the signal on pin 6 visible, and the signal on pin 7 disappears: This is correct. So it looks like we now have communications with the keyboard possible, from a physical sense.  So now to debug the communications.

First step is to see if the synchronisation signal on pin 4 is being captured or not.  This signal has a pulse width of only ~1usec. This SHOULD be enough, because the keyboard FPGA runs its internal clock at about 12MHz, so it should see the signal for several clock-cycles.  To test that it is being captured, I have configured one of the LEDs to increase in brightness each time a TMS signal is seen.  It seems that it is not captured.

Since the signal should be wide enough to be captured, I am now wondering if the pin assignment is wrong, or some other similar problem.  To test this, I will have the keyboard FPGA route the TMS signal back out onto the TDO line, so that I can see what it thinks it is directly.  If it comes through fine, then I know that there is a problem with the VHDL logic, rather than the clock capturing per se.

Well, a lot of fiddling around has established that I don't seem to be able to read the JTAG pins as inputs from in the Lattice CPLD.  I have made sure JTAGEN is low, so that the JTAG interface is not being taken over by the JTAG system, but I still seem to only read fixed values from the JTAG input pins.  Apparently this is the default behaviour according to http://www.latticesemi.com/en/Support/AnswerDatabase/3/0/4/3043. So I can apparently set a flag to make them usable, but I need to make sure that doing so doesn't effectively permanently disable JTAG, thus preventing me from ever re-flashing the things.  That would be bad.   Anyway, it does at least explain the behaviour I am seeing.

There are a few potential solutions here:  First, I try to figure out how to switch the JTAG pins safely. Or alternatively, we do have 3 true GPIO lines on the connector, and so I could just write a protocol that uses only 3 pins instead of 4 to communicate with the keyboard.  Then it is a question of what protocol to use.

Probably the easiest is to switch to a 3 wire protocol, and use a stretched clock signal as the sync signal. That is, if the clock pulse is longer than, say, 2usec, then it is a sync signal.  That way the rest of the protocol can remain unchanged.
We can have the keyboard read and write bits on the rising edge of the clock, and the Xilinx FPGA can read and write on the falling edge, so that everything stays nice and simple. 

As with everything VHDL, this has taken a little longer than expected, and involved the usual cycle of me thinking I can get away without a test harness, and then eventually making one anyway, when I hit some inscrutible bug.  But I now have a 3-wire interface that uses a stretched clock pulse to mark the synchronisation.

One fun thing I found while doing this, is that having the keyboard protocol running on the keyboard cable while trying JTAG program the keyboard generates enough cross-talk to cause trouble with the JTAG verification process. So mental note to de-configure the Xilinx FPGA (or have it stop the keyboard protocol) before trying to flash the keyboard FPGA.

Better would be to make the dip switch that connects the keyboard to JTAG to also stop relaying the keyboard protocol pins through.  That means programming the MAX10 again, which is usually not much trouble now.  This time however, it tried to claim that the programming cable was not connected, when in fact it was. The problem turned out to be that jtagd got confused, which was fixed by killing jtagd, so that it would restart on the next programming attempt.

Excellent! I now have a blinking keyboard led (which is what the test Xilinx bitstream is supposed to do), and I can stop it blinking by enabling JTAG to the keyboard (which is what I just attacked), so I should now be able to easily flash the keyboard again.

Now, I said the LED is blinking, and it is blinking. However it should be the drive LED, not the power LED that is blinking (which is oddly the one nearest the drive).  Also, it should only be flashing RED, not with the occasional flash of blue.  And the other LED should be staying off.  However, such naughty things are happening.

Swapping which LED blinks should be nice and easy.  Working out the cause of the flashing is another thing altogether.  My best guess is that there is some clock glitching due to crossing clock domains etc.  This should be fixable by debouncing the clock.  Indeed, debouncing for a single cycle seems to be enough to fix it.

Now the colours are stable, but the LEDs are appearing green instead of the red that they are being instructed to be, so I'll need to look into that.  But first, I want to have a clear indication of when the computer is or isn't connected to the keyboard.  So I'll implement a bit of disco lights, maybe in police light style, that indicate when the computer isn't talking to the keyboard.  This should only ever happen in the first fraction of second at boot, which I will mask.  So basically if the police lights come on, you have a problem and need to pull over and sort it out.



Right, now back to the important business of getting the LEDs functioning properly for normal purposes, and working out if there is still any funny clock stuff going on. The reason I suspect clock funniness is because the wrong colour, which makes me worry that the clocks are being counted at half rate or so on the keyboard side, since red is in the first 8 bits, and green in the second. Or alternatively there are 8 bits being stuffed in at the beginning of each round of communications, which is causing the shift. I'll have tthink about it for a bit.


See: The LEDs can blink, just in the wrong colour.

But what is also nice now, is that the keyboard is responding with information about which keys are being pressed. This should be super responsive, because we get a complete update of the keyboard state every ~0.1 milliseconds, so the delay of the keyboard protocol should be really negligible.

So now to plumb it all in, so that the MEGA65 starts trying to use the keyboard. We know that the matrix will all be messed up initially, but that's okay.  First step is simply to get the key presses received and interpreted.

Okay, so, now I can detect when some keys are being pressed, but not all of them.  A bit of hunting found a stupid bug in the code that handles the key presses, which was causing all key presses to be interpreted as only one of the first 8 keys in the matrix.

Ok, fixed that, and now the keyboard decode accelerator at $D610 shows various ASCII codes of keys I am pressing (all messed up, because the matrix is not correct, yet), but our OpenROM BASIC is behaving as though there is no keyboard. A bit of poking around has found that this is because it thinks the joystick is active on all 5 inputs.  We had this problem with the R1 board due to lack of pull-up resistors, but that was supposed to be fixed.  What is weird, is that it is only one of the joystick ports doing this. I am now trying to work out which joystick port it is, and whether it is missing pull-ups or something else.

Hmm.. Oscilloscope is claiming that there is 0V on every pin of both ports. This new PCB does have a "5V enable" for the joysticks, which is controlled by the MAX10 FPGA, so I'll have to take a look at that. After some chasing around, I found and fixed a couple of stupid typos on my part, that mean that I was enabling on the wrong pin.  This was complicated slightly by the fact that the voltage control for the joystick port on the R2 boards already has a small patch on it.  Also we confirmed that the pull-up resistors were forgotten from the joystick lines, which is a bit annoying, but easy enough for us to fix. It's just a nuisance, because all 25 series boards will need to have ten surface-mount resistors fitted, and then tied to VCC.  That's quite a few hours work, in all likelihood.

Now, back to the keyboard, all that fuss about the joysticks was so that I could stop the joystick lines interfering with the keyboard scanning.  I'll have to implement a register that lets us connect and disconnect the joystick ports internally.  I had done this previously for the R1 PCBs, and it is just a case of resurrecting it.

Ok, so I have done that, can can see the joystick inputs disappear -- but there are still some funny things to solve: Pressing keys doesn't reliably set the bits in the bytes, and indeed the bits float around a bit.  This took quite a while for me to realise that I had de-glitched clock edges only partially. Once I realised that, I was able to sort that out.

Then the next funny problem is that some of the first few bits are still coming through as though keys are pressed -- even though I can see on the oscilloscope that the input line stays steadily high. Also, there seems to be a synchronisation problem with the LED colour receiving.  I think that it is probably reading one clock or one edge early or late.  The two problems may even be related directly, but that will require some investigation.


I am now invetigating the LED problems.  First, I have fixed a problem with the PWM brightness control.  Now I am trying to work out if there is a shift in the bits of data compared to where they should be.  The data consists of 4 x 24 bits for 8-bit RGB channels for each of the LEDs.  This is 96 bits in total.

The first 8 bits should be the red channel for the first LED, but seemingly do nothing.  So now I am working my way through systematically to figure out what is going on.  This requires about 3 - 4 minutes as I test each byte to see what it is being mapped to.  Ok, so the second 8 bits are also not seeming to do anything.  Ok, finally hitting where bits are doing something:

Bits 0 - 31 = nothing
Bits 32 - 39 = Blue channel for the second LED from the left.
Bits 40 - 47 = Green channel for the second LED from the left.
bits 48 - 55 = Red channel for the second LED from the left.

Hmmm,  it seems to be backwards.  Also note that 128 bits (total frame length) - 96 bits = 32 bits, which is suspiciously the size of the region which does nothing.  A closer look reveals that I am sending the bits indeed in reverse order.

Ok, time to reverse the bit order then, and see if that fixes it.
Hmm... Closer, but still something odd. I requested a red solid LED for power and blinking green drive led, and I have instead a blinking red LED and solid green one. They are also on the wrong LEDs, but that is really easy to fix.  I'm trying now to make the power led solid purple, and we will see what that does.  Most strange: I now have a blinking purple LED, even though the logic for the purple LED should have it solid on.  Found the cause of this: I had for some deranged reason in my test harness decided to make the power LED blink and the drive LED solid. Anyway, it's nice that that is now out the way.  The LED control is now all perfect, with C65-style green power and drive LEDs.

Now, back to the keyboard. Plenty of fun adventures to be had here, as I have chased down a variety of fun bugs. The bit order was being reversed here as well, but then the big problem was that initialising signal values doesn't seem to work on the Lattice CPLD we are using. It's probably a known situation, but it wasn't known to me until now.

So FINALLY I have the keyboard communications more or less working, and now just have to map the ~80 keys to the correct matrix order.  I have the schematic for the keyboard, as well as the C65 keyboard matrix from section 2.1.2 of the Commodore 65 Specifications, and I just have to match them all up.  Unfortunately the keyboard schematic for the MEGA65r2 doesnt show (or at least I couldn't find) the key number to keyboard position mappings, so I have to figure these out for myself.

I've started with SHIFT LOCK, because the lock keys are clearly marked on the schematic, and then with RUN/STOP and ESC because I can also deduce where they are.  If my hunches are confirmed, I will be able to fairly quickly match up more keys.  So, this worked in so far as I could indeed tell that I am pressing the correct keys.  However the matrix mappings seem to be wrong.

Fortunately I implemented the on-screen-keyboard for the MEGAphone, which lets me see in real-time exactly which keys are being pressed.  While this wasn't its original purpose, we can always pretend it was made for this purpose, for which it works fantastically, and looks pretty nice while doing it.



RUN/STOP should be key 63, but pressing it causes D to be pressed, as can be seen above, which is key 18 (column 2, row 2).
ESC should be key 71, but works as A, which is key 10.
SHIFT LOCK (key 15) works as key 66

Ah, in all cases they add up to 81! That means that the bit order is just reversed, which we can easily fix.  Oddly, trying to reverse the bit order didn't fix it, but making the key numbers be 81-(key number) has worked, so I am not going to worry too much for now.  So now to implement more of the keys.

Getting the vast majority of the keys correctly assigned took about 2 hours of iterating through, but in the end, we have most of the keys right. So we can finally type some things in, and even load programs again.  However there are a number of keys that are behaving oddly, which we will have to fix up.  But as this post is already half a mile long, I'll stop here for the moment.



Bringing up the SD card interface on the MEGA65 R2 PCB


Ok, the keyboard test bitstream is currently synthesising, so I though I would look at another important sub-system in the meantime: The SD card interface.

The R2 PCB has both an SD card and microSD card interface. As I have mentioned in a recent post, the microSD interface goes through the MAX10, which complicates things a bit. Also, the pre-series cases are quite tight around the microSD cards.  So, for both these reasons, we will concentrate on the full-size SD card slot.

So, to begin, I am using my FPGA pin identification framework to work out where everything goes. What I really need to know is the exact model of SD card connector we are using, so that I can verify that everything is correctly connected.

First up, check if we have VCC and GND

The signals we need are:

Data Out (DO)
Data In (DI)
Card Select (CS)
Clock (SCLK)Power (VDD)
Ground (VSS)

Now to see if they are on the correct lines in the current bitstream. I'll use my test bitstream that puts a unique bit sequence on each, so that I can see which is which. 

VDD - Correct at 3.3V
VSS - Correct at 0V
DO - FPGA pin #10
SCLK - FPGA pin #8
DI - FPGA pin #11
CS - Stuck at about 2V

The CS line looks to be the problem here.  Hunting through, I have found that I hadn't plumbed that line through properly.  So a bit of poke and fiddle, and it suddenly was working :)


Having the SD card working is super helpful, as it makes it MUCH easier to load things for testing.

Also, it is nice seeing other bits and pieces obfviously working, now that we can get as far as booting.  In particular, the internal floppy drive now does its spin and seek during the boot sequence. A happy piece of progress after a lot of preliminary work over the past few days.