Tuesday, June 6, 2017

Building lab-prototype MEGA65, and remembering the thrill of my first C65

After getting the MEGA65 prototype PCB up and running last night, today was time to build up the prototype in the lab.

First, with Ben's help, get the SD card adapter working correctly, and give it a bit more physical support to stop it getting broken again. We still need a bit taller legs:

Second, make sure that it boots fine:

 Third, get my Commodore 65 keyboard that I bought ages back on ebay, and one of the plastic laser-cut outlines I made when I was starting to work on the laptop concept for the MEGA65:

Work out how I was going to hold it in place. There are three hole-throughs on the keyboard:
 Looking closer at one of them:

Unfortunately, one of them is behind the space bar (which is possibly the widest space bar I have ever seen on a keyboard -- a point which is causing us some fun in getting our own production in order for our own MEGA65 keyboards.)  So I resorted to drilling some holes in my acrylic outside, and screwing a retainer strip on the back. It isn't perfect, but it works enough for now:

You can also see that I have screwed the C65 prototype motherboard down to another panel, and then added a home-made friction hinge (although it isn't strong enough to hold the keyboard open in position), so that I can open it up to get to the SD card.  We might yet extend the SD card to a better location, so that we don't need to open the "lid" all the time.

Putting it altogether and powering it up, it still looks very, very rough -- but the point is we now have a working and usable bench-top prototype, from which to progress.

Here is it is from a couple of other angles, so you can see the power connector, joystick ports and reset button:

And looking in the side, where you can really see that the temporary physical construction is indeed a gross hack.

So, now I have it working.  One of the really unexpected things was a wave of emotion and nostalgia as I started interacting with a C65 via a real feeling keyboard for the first time in close to ten years.  I didn't get this when using a keyrah and Commodore 64 keyboard on it, and certainly not using a USB PC keyboard.

But suddenly with a real C65 keyboard, it felt like I was 19 again, and using the prototype C65 again.  It's hard to explain. It might be the tactile feel of the keyboard, or even the subtle timing of where in the key press the computer registers the input, or some combination of the two. But whatever the trigger, it was like smelling a familiar smell for the first time in years, and having that rush of memory and recollection, including evoking the emotion of the moment, not just the cerebral memory of it.

It is this thrill and experience that I hope we can share as we continue with making new C65s through the MEGA65 project.  That wonder of discovering a new heir in a noble lineage of computers.  We might not be Commodore, but I am convinced that we will be able to bring the C65 to completion, and finally bring the last chapter of the 8-bit dynasty to life.

Monday, June 5, 2017

Powering up the MEGA65 prototype PCB at home

Just another quick post to say that I have the prototype PCB at home now, and with the help of a student got a power supply for it, and now I have it powering up at home:

As you can see, I have my genuine C65 keyboard (complete with missing top-printing of the keys) connected.

The C65 keyboard connector is a bit tight to move on the power-supply switch side, which we will re-work on the rev2 PCB:

Unfortunately the SD card adapter has developed a couple of dry-joints in transit from Germany, so I will need to take it back into work tomorrow and re-touch those.  Hopefully it will then work fine.

After I have that all working, I'll start looking at the cartridge port and floppy connectors to verify that they function fine.  Apart from a known signal direction wrinkle on the cartridge port, I am not expecting any particular problems there.

Then I will try to debug the problems with the keyboard interface that Falk discovered. I think it is ghosting due to the relatively weak pull-ups in the FPGA causing ghosted rows or columns on the keyboard interface. The solution there will probably be to have the real keyboard scanner in VHDL, populating an internal matrix representation that is actually scanned by the C64/C65 ROM.  The internal matrix representation is already there, because it was required for the PS/2 keyboard interface.

Sunday, June 4, 2017

My MEGA65 Prototype PCB has emerged from the postal system

After a tense month of waiting, one of the only three MEGA65 prototype PCBs finally arrived here today.  This is both a great relief, and also very exciting.  Unpacking photos follow:

Now my main challenge is to find enough time to test the various ports that we still need to confirm the function of.  Lesser challenge is wiring up a 12V power supply for it, but that is really not a problem.

Friday, May 12, 2017

FDISK and FORMAT utility for the MEGA65

Preparing SD cards for the MEGA65 can be a bit tricky, as the FAT file system implementation in our Kickstart is rather restrictive.

To make life easier, we are creating an FDISK+FORMAT utility that will be in memory on each first power-on (this is one of the nice things about FPGAs -- RAM contents are not random on power on, but we can put what we like in there).  The idea is that if Kickstart fails to find a valid partition and file system, it will launch this utility to give the option to investigate the problem, and to quickly and easily (re-)partition and format their SD card in a manner that is compatible with the MEGA65.

At the moment the utility is functional, but a bit raw. In particular, if you run it, it WILL completely erase and repartition and reformat your SD card WITHOUT EVEN ASKING.  Consider it a proof-of-concept, rather than a finished product.

Nonetheless, it is nice that we have a simplified combined FDISK+FORMAT utility in less than 9KB.

Screenshot of it running in the MEGA65 emulator where I have been developing it:

Real testing on a MEGA65 will have to wait until I get back from my travels or another of the team has the chance to try it out.  I am not sure if the SD card size detection will work on real hardware or not.

Sunday, May 7, 2017

Pulling pieces together for the new PCB: Matrix mode, preliminary cartridge support and updated video mode

Progress is continuing towards the new MEGA65 PCBs, and full support for the various connectors and ports.

First, a general improvement thanks to Tim's hard work: The "Matrix Mode" composited overlay of the serial monitor interface is now very nice to use directly from a USB/PS/2 keyboard.  You can now change turn "Matrix Mode" on and off with ALT-TAB, and select the size and position of the overlay with ALT-1,2 or 3 and the cursor keys.  This makes for a much more convenient debug interface, as you don't need to have a separate computer hon hand.  ALT-TAB actually triggers a hypervisor trap, and there is a little snippet of code there that simply toggles the flag for Matrix Mode in the protected hardware configuration register (only accessible from the Hypervisor).

Some photos to show how this looks in reality. Sorry that they are a bit fuzzy, but it is all I had time to grab before flying out this afternoon.

First, full-screen.  Note that the serial monitor is overlaid with transparency, so you can still more or less see what is happening behind.

Pressing ALT-2 makes it middle size, and you can then move it around.  The smaller image dims the background more strongly, to keep the text clear and readable.

Finally, smallest size:

Then separately, I have been working on cartridge support for the new MEGA65 main boards.  However, I don't yet have one here, so I decided to make a fake cartridge as a means of testing that I had the interface correct, while using only the Nexys4 boards I have here.

To do this, I made a cartridge that has pretend IO at $DExx and $DFxx, and maps an 8KB ROM at $8000-$9FFF.  I then used that as the handle for implementing expansion port memory accesses to that, first simulating with GHDL, and then synthesising with Xilinx ISE.

Once I had it generally working, I then updated the memory mapping on the MEGA65 CPU to actually map the expansion IO at $DE00-$DFFF to the expansion port (except when the SD card sector buffer is mapped there -- I forgot it initially, and then wondered why it couldn't mount the SD card any more ...).  I also updated all the memory mapping for the expansion port ROMs.  Most bank-switching cartridges should work okay.  Ultimax mode is also supported, so even some crazier cartridges might work, but there are limitations to the degree of compatibility we are offering. Nothing that does DMA will work, so REUs are a no go, and I'd be really surprised if any freeze cartridges worked.  We might add support for more devices in the future, but for now, most software and game cartridges and some fast-loaders should work without too much trouble.

In the process of implementing this, I also rationalised all of the expansion memory interfaces, so that it is easier to pick which one is active, as the original Nexys4 board, the Nexys4DDR and MEGA65 main boards all have different types.  This means that we should be able to add back support for the PSRAM on the original Nexys4 boards fairly soon.

For testing on the Nexys4DDR board, I plumbed switch 8 (which is also CAPS LOCK for C65 mode) to the /EXROM line on the fake expansion port.  That is, if CAPS LOCK is on, then the cartridge is present, and if CAPS LOCK is off, then the cartridge is "removed", and doesn't map.

This all works quite nicely, and so after a bit of fiddling, I was able to get this display on boot:

The @'s and MEGA65 boot message are there because as soon as Kickstart hands over to the C65 ROM, the cartridge is started.  The missing bottom border is because I was still fixing problems with the video mode at the time, so can be ignored.

For those not familiar with the workings of boot process of the C65, it first starts up running the C64-mode KERNAL.  As on a normal C64, one of the first thing the KERNAL does is look for a cartridge.  This happens on a C65, as well.  As a result, if the cartridge is enabled, we just get the rainbow border that is the tiny program on the fake cartridge I made.

Finally, for the new main boards, we are switching to 1080p and a 150MHz dotclock (down from 192MHz).  A side effect is that the CPU speeds up slightly to 50MHz, which is not a bad thing.  This means that I have had to refactor the video mode framing in the VIC-IV.  This has been more painful than I would have liked, and it still isn't finished. It is temporarily driving 1280x1024 @ 57Hz, which I didn't think was a real mode, but my monitor displays it okay.  When I get a chance, I will figure out the right mode timing, and deal with any remaining VSYNC/HSYNC generation bugs, and move it across to 1080p, which will be a very significant moment, after which the video mode of the M65 should remain fixed, with only the PAL/NTSC 50/60Hz timing difference remaining, which will be run-time selectable, as on the Amiga.  From there on raster timing should be reasonably fixed.  

I also need to merge in Falk's work on fixing bitplanes, and get it synthesising for the MEGA65 main boards, with the real cartridge port plumbed and test that. 

In short, there is a real feeling of progress at the moment, and already some nice outcomes from that.

Sunday, April 16, 2017

Prototype MEGA65 PCBs at Revision 2017

This weekend many of the MEGA65 team are at the Revision 2017 demo party.

Excitingly, they have with them the first prototype PCBs for the MEGA65 mainboard, thanks to Antti's amazing work.

So, before we get any further, it is time for some pictures.

First, here is the bare PCB before being populated:

Then with just the bare minimum components for initial testing by Antti:

Having real hardware, even if it is 18,000km away from me was a very exciting moment!

However, excitement had to give way to hard work, if we wanted the MEGA65 to actually run on the new PCB during the party.

First step, update the mega65-core repository to add a branch (m65pcb) with a target for the new board, and work out all the pin assignments.  That process took longer than I would have liked, but after a day or so, we had kickstart running, and the new 24-bit VGA output working.

The Nexys4 boards have only 12-bit VGA output, so I decided to make a quick routine to draw a vertical colour gradient by writing the contents of $D012 (current VIC-II raster line) into $D100 (red channel of palette entry 0).  It was pleasing (via skype video call) to see this all working.

Then the next step was to solder on a microSD slot to a set of test pads.  The final PCBs will of course have a microSD slot on them, but the time crunch for revision meant that these first prototypes didn't.  Fortunately, the PMOD connectors also aren't wired up, so it was possible for the guys to use a PMOD microSD adapter, and link the test pads to the appropriate pins.

Note that in the above image an incompatible SDHC card is visible. We're still working on adding SDHC support.  After switching it for a 2GB SD card, and putting the appropriate files on there, the familiar C65 boot screen appeared.  No photo of that, because if you are reading this, you probably already know what it looks like.

What I didn't mention above, was that after some initial problems with the VGA output, we realised the VDAC chip on these prototypes is only rated to a 170MHz dotclock.  The MEGA65 currently is still using a 1200p 60Hz video mode, with a dotclock of 193MHz.  As a result, the VDAC was not happy, and there was no image.  Solution: lie to the VDAC and claim our dotclock is only half what it really is. Result: it samples only every other pixel, which makes the horizontal non-integer scaling in 80 column mode look uglier than normal.  This will of course be fixed for future PCBs.

Then we found some problems with the keyboard interface. Basically there is cross-talk of some sort, or possibly weak pull-ups in the FPGA not allowing lines to float back high quickly enough.  This causes some strange problems with phantom keys being pressed:

However, these problems are when we are using real C65 keyboards with the PCB.  Needless to say, this is a very nice step forward in usability and authentic feel.

Time constraints also meant that the joystick ports lacked pull-ups (they are on separate lines from the keyboard, so that we can make MEGA65 software work more happily with keyboard + joysticks simultaneously).  Antti confirmed that with pull-ups, we can read those lines just fine.  Hopefully we will be able to update the bitstream soon to enable them before the end of the party.

 Speaking of bitstreams, we are loading the bitstreams onto a 32MB SPI flash on the PCB.  We can set this to configure the FPGA on power-on at 66MHz and 4-bit parallel, for a total 33MB/sec. As the bitstream is ~9MB, this gives a power-on time of 0.25 - 0.3 seconds -- very nice.

Finally, we have some of the folks celebrating and presenting the PCBs at the party:

Saturday, April 1, 2017

Emulating an 8080 on the MEGA65

I must say I was very impressed to discover what LGB has been up to lately:

As the URL suggests, he has been working towards CP/M emulation on the MEGA65.

What is remarkable is that he is currently obtaining the performance of an approximately 12MHz 8080 CPU on the MEGA65, i.e., about 3x faster than many of the real CP/M computers -- but this is emulation using the 45GS10 CPU of the MEGA65 to achieve this.  Put another way: The 45GS10 can emulate an 8080 at fully 1/3 of the clock speed of the 45GS10.  

Both he and I were at first rather surprised that it could emulate at such speed.  However, on inspection, it turns out that the 45GS10 is quite friendly for emulating foreign hardware.  Specifically, the combination of a large address space, together with the ZP-indirect 32-bit addressing mode and the JMP ($nnnn,X) jump-table instruction means that an emulator can operate in its own address space, separate from the emulated system, and use ZP registers as emulated registers, with the ZP-indirect 32-bit mode allowing dereferencing of those emulated registers.