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.

Sunday, November 27, 2016

Working on the MEGA65 IDE

It's been a bit of a while since the last post, and there are some good reasons for that.  Chief among those is that I have been busy temporarily moving to Germany with my family for work.  We are staying just long enough that we have to go through all the formalities as though we were staying forever, but not long enough to be able to settle properly.  The net result is even less time available than normal.  However, on the upside, I am located nearby to most of the other MEGA folks for a few months, which is very nice.

What I have been working on in the meantime in what spare moments I can find, is the beginning of the MEGA65 IDE.  This IDE will integrate with the m65dbg debugger, and will run mostly from within LGB's MEGA65 emulator.  That is, the user interface will in fact be a C65 program.  While this might sound strange, it has the added benefit that we will end up with a (hopefully rather nice) native text editor/viewer for the MEGA65.

I have a large part of the editor working now, including the ability to load multiple files (even if they don't all fit in RAM at the same time), switch between them, and even display multiple files on screen at the same time, as the following screen-shot shows, showing some of the C source code of the editor itself loaded (it is being written using the cc65 6502 C compiler):

The idea of the split-screen mode is to make it easier for debugging: The current stack-trace could be displayed visually showing the recent call graph.  Also it is handy to be able to look at two files at once when programming.

The editor also natively uses ASCII instead of PETSCII, so that it is easier to work on source files intended for cross-compilers and cross-assemblers (or in the future at some point, cc65 or ca65 running natively on the MEGA65)

Here is a more ordinary looking screen-shot with a single file in view:

You can see here that we have curly-braces as part of our ASCII-goodness.

The next step is to finish cursor movement functions, and then work on editing functions.  The editor controls are based rather loosely on Emacs and the UNIX shell conventions, e.g., control-A and control-E to jump to start and end of line, respectively.

Thursday, September 1, 2016

MEGA65 Emulator can run kickstart and disk menu

Just a quick post while I am on the road to share Gábor's latest progress on the MEGA65 emulator: It can now run kickstart and supports hypervisor traps and SD card access, sufficient to boot, and run the disk menu program (which makes heavy use of hypervisor DOS calls):

Monday, August 22, 2016

Double-tap RESTORE to enter Hypervisor "freezer"

After a lot of little bug fixing, I finally got the keyboard based trap-to-Hypervisor function working.  While this might sound dull at first, it is actually super important, and enables a bunch of really interesting and fun features.

The best way to think of this, is as an integrated "freeze" button, that is triggered by tapping the RESTORE key twice in quick succession (between 50ms and 800ms apart).  When this occurs, it triggers a transparent trap to the Hypervisor. That is, the running program doesn't have the slightest idea that it has happened.  This allows the Hypervisor to run some arbitrary routine, before exiting back to the running program.  In other words, it really is just an integrated freeze function. Right now, that routine just toggles between slow and fast CPU speed, which is kind of fun, but not really that exciting.  Here is the current Hypervisor RESTORE trap routine:

; For now we just want to toggle the CPU speed between 48MHz and
; 1MHz

; enable 48MHz for fast mode instead of 3.5MHz
lda $D054
eor #$40
sta $D054

; enable FAST mode,
lda $D031
ora #$40
sta $D031

; bump border colour so that we know something has happened
lda $D020
and #$0f
sta $D020

; return from hypervisor
sta hypervisor_enterexit_trigger

There isn't anything really to exciting to see there: It just fiddles a couple of registers to toggle the CPU speed between normal and 48MHz, increments the border colour as a bit of a debug aid, and then exits from the hypervisor.

For the technically inclined, what you might be noticing what isn't there.  As I have talked about previously, the Hypervisor trap process is super efficient: The entire CPU state is saved to shadow registers, resulting in a 1 cycle entry and exit time from the Hypervisor, because you don't need to save or restore any CPU or memory mapping registers.  The CPU is automatically set to a known configuration on entry to the Hypervisor, and restores the running program's configuration on exit.  Thus, this entire Hypervisor trap takes only about 40 cycles, or about 850 nanoseconds.  Most modern desktop processors probably would have trouble beating that.  Indeed, as previously mentioned, a minimalistic Hypervisor trap can complete in under 200 nanoseconds.

Anyway, back to the story at hand...

Like on a freeze cartridge, we will implement a freeze menu, that will allow a number of useful operations.  The usual staples will be there, including memory monitor, the option to reset the machine, probably some poke finder type functions, the option to freeze the currently running program to disk, and so on.

However, the MEGA65 has been designed from the outset to do much more in the freeze menu.

First up, you will be able to switch tasks, by browsing through the list of tasks, complete with 80x50 pixel thumbnails that are drawn using the previously described hardware thumbnail generator, that continuously generates little screen captures of the running program.

Similarly, you will be able to delete tasks and start new ones.

So, for example, if you have a sudden need to show off your BASIC programming prowess half-way through a game of Ghosts and Goblins, you can just double-tap RESTORE, choose the menu option to create a new C64-mode task, demonstrate your elite status by typing something like:


and then when you have demonstrated your mastery over coding to whoever was doubting it, you can double-tap RESTORE again, and switch back to Ghosts and Goblins, which you can easily find from the thumbnails.

Similarly, when approaching a hard part of a game, you could freeze it, make a back up of the game where you are up to, and then go on to play that hard level, and reload the saved state until you can conquer it.  In this way, mere mortals should be able to get a score of at least 7 in Flappy Birds without too much trouble.

While these use-cases might be a bit simplistic and contrived, it is hopefully not too hard to see how the Hypervisor freeze menu will likely play a central role in the use and experience of the MEGA65 for many.  Thus it is really nice to have the hardware side of it implemented.  The next step is to start working on the menu program itself, the freeze/unfreeze routines, and getting saving to the SD card actually working, so that things can get saved.