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:

double_restore_trap:
; 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
inc
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:

10PRINT"I RULE!!! ";:GOTO10
RUN

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.

Sunday, August 14, 2016

Tutorial Video for m65dbg

Gürçe who has been working on the very nice m65dbg symbolic debugger for the MEGA65 has released a nice video providing an introduction to the current feature-set of m65dbg:


Saturday, August 13, 2016

We can include GEOS with the MEGA65

Just a very quick but super exciting note to say that we have received permission to include GEOS with the MEGA65, provided that we do not charge any extra for doing so.  Since we are creating our software suite as open-source, this is no problem at all for us, and means that we can potentially use GEOS to make the MEGA65 configuration menus etc using GEOS, which would make them look nice, and probably be much quicker to write as well.