Sunday, August 20, 2017

Launching FDISK+FORMAT direct from boot sequence

Another little job done tonight: Fixing running the FDISK/FORMAT utility from the Hypervisor.  This has been almost working for quite some time, but not quite.

 The first step has been working for some time, which is to watch for the user pressing the SPACE bar repeatedly during boot.  This interrupts the normal boot sequence and displays the list of utilities compiled into the bitstream.  These utilities hide in the top 30KB of colour RAM, where no C64 or C65 program knows how to touch, and are pre-initialised in the FPGA bitstream, so that the RAM in this location "just happens" to have these programs there.


What was not working was actually running the FDISK program. This was because I had written it using CC65, which does a JSR $FFD2 to set lower-case character set in its entry routine. However, when running in the Hypervisor, there is no ROM present. To solve this, the boot ROM now writes an RTS instruction at $2FFD2, so that a JSR to $FFD2 will safely do nothing and return.

That got the FDISK utility running, and after a bit of mucking about with character sets (there is only the partial Hypervisor character set available), and various other little fixes, the FDISK utility now happily starts, and tries to probe your SD card:

 Note the friendly warning message: This is an improvement from before, when it would just go right ahead and repartition and reformat your SD card without asking, on the assumption that if you ran FDISK on the MEGA65, it was to get your SD card working, not for any other purpose. It now politely asks you to type the two words DELETE EVERYTHING in capitals before it will proceed.  If you get it wrong, for example, type it in lower case, then it tells you to try again:

 If you get it correct, then it does as promised, completely reformat and repartition your SD card:

This process is quite fast, taking only a few seconds to zero out the important parts of the disk and put the half-dozen or so correct sectors in.

What is not immediately obvious here, is that the keyboard input is using the new hardware-accelerated keyboard input: Reading ASCII decoded keys, including all modifier key effects, is as simple as reading $D610 to peek at the next character, and then writing anything back to $D610 to pop the key from the queue.

Hardware animating the on-screen keyboad

I have done a bit more work on the on-screen keyboard, adding hardware animation for it to appear from the bottom off the screen, and also to horizontally centre itself, and choose the correct width, based on the current video mode, so that it fills (or almost fills) the full width of the screen.  

Together, these features are important for adding touch-screen support, where touching the screen should cause the on-screen keyboard to automatically appear in a sensible place, and without the key boxes being too small to use, and all ideally without having to trap to the hypervisor (you might want to be typing something into the hypervisor).

I now have it running fairly well in simulation, and am currently building a bitstream with these changes incorporated.  But since I have the framework already for producing image files of the running simulation, I figured it would be fun to make an animated GIF of the keyboard appearing. 

Note that the speed it will appear on screen in reality will be faster than this, as animated GIFs only support a fairly low maximum animation speed.

Friday, August 18, 2017

Solid-state Joystick

This is not something that I was expecting to be doing this year, but sometimes opportunities just pop up.

Early in the year, one of my colleagues, Damian, showed me one of these strain-gauge solid-state joysticks that they were using as part of the undergraduate engineering curriculum:

Their goal was to teach the students how to read strain-gauges.  But I immediately saw the applicability for making a no-moving-parts super-robust joystick for the MEGA65 and all other retro computer users.

Strain-gauges measure the strain on an object, by effectively measuring the stretching or compression force on the sensor caused by deformation of the object under strain (apologies to any mechanical engineers who are probably cringing at my description here).  All you have to do is to try to move the joystick handle, and the gauges will pick up the minute deformation of the steel plate it is connected to.  This is how those touchpoint pointing devices that you find in the keyboards of some laptops work.

Seeings as we have only one sick TAC2 joystick in the lab, and haven't really seen anything worth replacing it with on the market, we decided to explore designing a MEGA65/C64/Amiga/Atari compatible joystick around this concept -- especially since we had working hardware on hand to work with.

The teaching unit was designed to work with an Arduino, so I went and bought one this morning, and between meetings today hacked up a tiny Arduino sketch to interface to it.  I figured we only needed 2 of the 4 sensors, since they are at 90 degrees to each other.  It turned out that all we needed to do was to tare two of the sensors, i.e., subtract their value when the stick is standing un-touched, and then monitor the sign and magnitude of deviation from zero for the two sensors, and we could quite easily detect all 8 directions with good reliability. The lack of travel makes this a potentially very fast joystick for those games where you have to toggle rapidly from side to side.

The only caveat with using only two sensors instead of four is that we can't then interpret a tap on the top of the joystick. While such tap detection is a fun idea, for a retro gaming joystick, it isn't really required, as you can't tap a stick while yanking it around at high speed.  Thus we will still need to have a real fire button, but it does mean we can save on sensors and the associated amplification circuitry for reading them.

Current idea for the fire button(s) is to have a fire button which interrupts an infra-red sensor, like a shop door sensor.  That way, there will be the absolute minimum of moving parts, short of making the fire button touch-sensitive -- but that doesn't feel right.

Otherwise, the biggest challenge we saw was the drift in readings, which means that there is a need for recalibration.  This is a well known problem with the Touchpoint devices, as they have to fairly frequently recalibrate. This occurs automatically, and shouldn't be a big problem, but we will have to implement the algorithm for this. 

Apparently a common approach is to look for a steady reading with very little variation as an indication of it being stationary, and recalibrate to that point. This would be quite easy to implement.

Otherwise from an electronic perspective, we just need to add the joystick port signalling, which is fairly easy to do.

Simultaneously, we can also start looking at laying out the important parts of the Arduino and the strain gauge shield onto a single PCB that can fit over the metal base plate.  We have a student who will hopefully look at this as part of their project, but I might also talk to Damian about this.  

I would also like to add PWM output onto the pot lines, so that we can have it support 1351 mouse mode, using the proportional/analog nature of the strain gauges to allow the joystick to work as a pointing device for GEOS, so that you don't need to swap joystick and mouse all the time.

Then the plan is to design the plastic case and knob for it, and make necessary adjustments to the metal base plate, so that we can assemble these into complete working joysticks, and indeed have a design that is feasible to produce in modest quantities. Maybe we will design it for a clear case, so that the no-moving-parts insides are visible. Either that or traditional Joystick Black.

Either way, if we like the result, and they are robust enough in practice, we might look at making them available to folks if there is sufficient interest.

Tuesday, August 15, 2017

On-screen keyboard display

Today I more or less got the on-screen keyboard working for the MEGA65:

Not only does it appear as a nice alpha-blended composited display, it also shows which keys are being pressed, even if not being pressed on the on-screen keyboard (more on input modes in a moment):

Some might be asking why a computer with a keyboard needs to have an on-screen display in the first place.  This is indeed a very good question, with several possible (if not plausible) answers:

1. If you were using a C64 keyboard instead of a C65 keyboard, you might like to press one of the additional keys.

2. If you are using a Nexys4 board, and can't remember the key mapping, you can now mash keys until you see the one you want toggle.

3. You might have a broken key, and need an emergency rescue.

4. You might be playing a game, and find it is just too inconvenient to lean forward to press a key on the keyboard, when you could instead do it from your joystick.

5. You might be using a model of the MEGA65 that completely lacks a keyboard by default, such as a tablet or phone form factor.

6. You might want to just show off when people complain that 8 bit computers can't do advanced things like composited video.

As I say, while some of those might be possible, they might not be plausible.

Now, for how this works behind the scenes.

First, this is the fourth layer of compositing that the MEGA65 supports. The other layers are:

1. Bitplaned sprite mode, which allows modifying colours of underlying objects.

2. Alpha-blended text mode, that allows pixels to shade between the foreground and background colours.

3. Matrix Mode, that displays the serial console as a composited overlay, not dissimilar to what the on-screen keyboard does.

Like Matrix Mode, the On Screen Keyboard (OSK for short) is a post-process composited display.  It takes the output of the VIC-IV and Matrix Mode, and overlays the keyboard display on top.  It goes on top of Matrix Mode, because you might need to drive Matrix Mode via the OSK if you don't have a real keyboard available for some reason.

Also like Matrix Mode it has its own character set ROM (currently the ASCII 8x8 font I created for the MEGA65 text editor).  It also has to draw the complete keyboard layout, which is procedurally generated.

I could have done it using a bitmap instead, which would have been more flexible for the base layer, but would have also required 640x145 = ~11.3kB, unless I compressed it. More the point, it would not be possible to decide to show individual keys highlighted to show when they are being pressed.

I started out by thinking about how I could generate it procedurally.  I began with the ASCII-art keyboard layout from the C65 specifications guide, and
modified it slightly to better suite my tastes:

----+    +----+----+----+----+    +----+----+----+----+    +----+----+----+----
RUN |    |ESC |ALT |ASC | NO |    | F1 | F3 | F5 | F7 |    | F9 | F11| F13|HELP
STOP|    |    |    |DIN |SCRL|    | F2 | F4 | F6 | F8 |    | F10| F12| F14|   
 ~  | !  | "  | #  | $  | %  | &  | '  | (  | )  | {  |    |    |    |CLR |INST
 _  | 1  | 2  | 3  | 4  | 5  | 6  | 7  | 8  | 9  | 0  | +  | -  |GBP |HOME|DEL
TAB    |    |    |    |    |    |    |    |    |    |    |    |    | PI |
       | Q  | W  | E  | R  | T  | Y  | U  | I  | O  | P  | @  | *  | ^  |RESTOR
CTRL|SHFT|    |    |    |    |    |    |    |    |    | [  | ]  | }  |
    |LOCK| A  | S  | D  | F  | G  | H  | J  | K  | L  | :  | ;  | =  |  RETURN
    |       |    |    |    |    |    |    |    | <  | >  | ?  |      |    |
 M= | SHIFT | Z  | X  | C  | V  | B  | N  | M  | ,  | .  | /  | SHIFT|  UP|
              |                   SPACE                    |    |    |    |
              |                                            |    |LEFT|DOWN|RGHT
              +--------------------------------------------+    +----+----+----

Note that I have also trimmed the left edge and right edge from the key art, and replaced some of the more exotic characters to descriptions of them.  This is to keep the result to 80 columns wide (as the compositor expects 80 columns), and to fit the character set I already had (since we are still not totally sure that it is safe to use the C64 character set without a license.)

I then wrote a C programme that directly reads this ASCII form of the keyboard and creates a packed version of the key labels, ignoring all the +, - and | characters that draw the outlines of the keys, and produces a simple packed format, where multiple spaces are run-length encoded.  The whole thing packs to about 400 bytes.

Then I hand-wrote the key mapping for each discrete key on each row using the keyboard matrix position numbers that the MEGA65 internally uses, numbered from $00 - $47.  If a key was wide, it had $80 added to it.  I probably could have figured out a way to automate the table generation, but for the small size, I figured it wasn't worth it.  Also, even though I made a few mistakes initially, they were easy to find and fix by pressing keys and seeing if the correct one lit up on the screen.

This gave the following table of 7 x 16 entries:


The astute will note that there are only 6 rows of keys, and that the bottom row looks rather repetitive.  This is because $7E is a special value that means "a non-existent key, but with a horizontal line drawn on the top edge" and $7F means "a non-existent key, with no horizontal line drawn on the top edge".  This sequence draws the bottom edge on the space bar and the cursor keys in the last real row.  This is also the reason for the $7F's on the first row, to leave the tops uncapped on the non-keys between the groups of keys there. If we used $7E, they would have been closed at the top.

The $C1 at the start off the third row is the TAB key, which is wide, so is really key $41 + $80 = $C1.  The wide flag causes the key to be drawn 150% wide, and for the text labels to be offset by half a character, so that they don't get drawn over the vertical lines between keys.

For wider keys, like RETURN or SPACE, the same key value is simply repeated enough times to get the required width, and the logic that draws the boxes around the keys knows that this means a single longer key.

It was then a bit of fiddling to get the VHDL code working correctly to draw all this, although the end result ended up being only 400 lines.  To speed up development, I wrote another little program that could be fed the output of the GHDL simulation of the OSK, and produce a PNG image of the OSK.  This allowed me to find and fix bugs in a seconds instead of the almost hour it takes to synthesise the design to FPGA. Here is an example of the output of the simulation:

Here you can also see several keys being held down with the respective keys being shown in reverse video with a thin border.  This was one off my goals to provide nice visual feedback of keyboard activity, and that the procedural rendering allowed without great trouble.

All in all, I am pretty happy with the result.  The keyboard is clear and accurately laid out, nicely composited over the display, and yet still has a distinctively 8-bit feel to it -- and if we want to change the layout a bit, it is as easy as changing the text file that is pre-processed to produce the packed representation.

Next step will probably be to add a mechanism to have a "cursor" in the form of a highlight key that is used to navigate around the OSK, so that keys can be pressed using a joystick or other input device.  This will be in addition to touch-screen support, that I hope to add in due course.

Sunday, August 6, 2017

Fast booting the MEGA65 with custom bitstream, kickstart and ROMs

The last couple of days I have put some more work into makingg a stream-lined software development process for the MEGA65.  The goal is to make it possible to test changes to software in a few seconds, and without hassle, instead of mucking about with pulling SD cards out, flashing the SQI flash on the FPGA boards and generally forgetting what it was you were trying by the time you got your modified software loaded.

An additional motivation for this is that the SD card interface on one of our hand-modified prototypes is not working at the moment, and Falk needed another way to get bitstreams, Kickstart firmware, C65 ROMs and software he is writing onto the machine easily.

This was a new requirement, that required something more advanced than the monitor_load utility that I wrote last week to solve some of these problems. 

Specifically, it needed to be posssible to load a C65 ROM and character ROM image, without ever even initialising the SD card.

So I set about modifying monitor_load to load the ROMs into the correct memory location.  That was fairly easy, apart from a little speed bump caused by the limitation of the bulk memory upload command in the serial monitor.  That problem is that the address counter when loading only increments the bottom 16 bits of the address, combined with the start address needing to be one less than the first address.  

For example, to load memory to pre-load $20000-$2FFFF, i.e., the first 64KB of a C65 ROM, we couldn't just subtract one from the address, and say l1ffff 2ffff, because it would only increment the bottom 16 bits, and leave the "1" at the front of the address the same.  (The "l" in front of the address is the command code to tell the serial monitor to bulk load memory.)

Instead, we have to say l2ffff 2ffff: 1 is added automatically, but only to the bottom 16 bits which rotate over from $FFFF to $0000, leaving the leading "2" unchanged, for a complete address of $20000 -- exactly what we want.

The next challenge was how to tell Kickstart not to initialise the SD card, but instead to just launch the loaded ROM.  My simple solution to this problem was to add two consecutive instructions just before SD card initialisation would occur:

  BIT go64
  BIT $1234

where go64 is the label in the assembly language of the routine to launch the loaded ROM.  The monitor_load program searches for this signature, and changes the first BIT instruction into a JMP, so that it becomes JMP go64, thus exiting to the loaded ROM, without worrying about the SD card.

With this change in place, there is really very little for Kickstart to do, and it does it so quickly at 50MHz, that you don't even see the MEGA65 kickstart screen, before it drops to C65 mode, as can be seen in the following video:


What is also really nice is that the whole process takes only a few seconds.  You can see that the FPGA fires up in a couple of seconds. Much of the rest of the time is waiting for the monitor to wake up from sleep.

Combining this with the existing ability of monitor_load to load and automatically run a program in C64 mode (and C65 mode would not be hard to add), it is possible to execute a single command that loads the bitstream, kickstart, C65 ROM and program of choice, and sets it running -- all in less than 10 seconds, as can be seen in this video:


As usual, the curious can checkout the source code on github.

(Also, for the curious, the strange program that runs in this video is an old test of the hardware-accelerated proportional text mode that the MEGA65 has.  This little program takes a UTF-8 text file, and renders the variable width glyphs in text mode, which makes it both fast, and very memory efficient, as repeating the same character re-uses the glyph memory.) 

For Falk and the machine without a working SD card, the next challenge is to provide remote control of the floppy controller, so that D81 disk images can be used, without having to load them on the (in his case, not working) SD card.

The ability to automatically trap to the hypervisor already exists, and it is now a case of writing the trap code in Kickstart, and modifying monitor_load to interface to it, so that a disk image can also be specified when starting the machine, and knowning that all disk access will be redirected to it.

With that in place, the ongoing development of the MEGA65 version of GEOS will hopefully be able to proceed very quickly, with no inserting of SD cards required.

And it shouldn't take too much effort to make the disk virtualisation code, because we already have the tools to iterate on the Kickstart firmware very quickly, through monitor_load itself.

Tuesday, August 1, 2017

Getting 1080p 50Hz working ... using a video mode editor written in BASIC v2

One of the joys of the MEGA65 project is that it is all about doing something that is not grounded in conventional measures of wisdom or practice -- at least none invented since the 1980s.

One of the TODO items for a while now has been to get 1080p at 50Hz (for PAL) and 60Hz (for NTSC) video modes working, ready for the move to HDMI on the new MEGA65 mother board.

This has been a bit of a drawn out process, partly because of everything else I have going on, and partly because I didn't have the tools to quickly and easily test and move forward.  That latter problem has now been substantially improved on several fronts:

1. The monitor_load program makes it easy to try a new bitstream and/or Hypervisor ROM on the MEGA65, without having to fiddle about with SD cards.

2. I now have a native Linux machine, so that I don't have to muck about with transferring bitstreams and source back and forth in and out of a virtual machine on my mac.  It also means that synthesis is a bit faster, without the overhead of the virtual machine.

Together, those two things, while not particularly ground shaking, have made a huge difference to what I can achieve in the little puddles of time I have.

The next step today was to implement a monitor_save program, that lets me save whatever is loaded in C64 mode, even if the program is running. This isn't a freeze function, but rather just saving BASIC program memory.  This makes it easy to work on a BASIC program on the MEGA65, saving it as I go along.

So now I had the means to save and load a program from my Linux box from and onto the MEGA65 in a second or two, as well as build and try out new bitstreams quickly, thus allowing me to do even more in the limited time available to me.

Back to 1080p video modes, I have worked over the past week to make VIC-IV registers at $D072-$D07C that allow complete control over the VGA video signal generation, so that I could try out various mode lines, with a view to generating the 1080p modes.

I also found out by accident that one of the VGA monitors at work is totally happy to do very low frame rates, down to and below 50Hz.

Now I was set, I had the tools to allow me to write a simple program to try out and modify video parameters on the MEGA65, to tweak them for proper video image placement and timing.

One of the joys of the C64, is that it contains a powerful and simple programming language out of the box, i.e., BASIC. While BASIC v2 is a bit minimal, it is totally functional, so I started hacking away on an interactive video mode line explorer.

Within an hour or so, I had not only a functional video mode editor, but had also worked out the correct parameters for 1080p 50Hz,  1080p 60Hz, and 1200p 60Hz, all using a fixed 150MHz pixel clock.  Here are some screen shots of my program in the various modes, and as I was testing them on the monitor:

First we have 1080p @ 60Hz. The BASIC program calculates a rough estimate of the horizontal and vertical frequencies of the mode. The letters and numbers in  brackets let you adjust the value to the left by -10, -1, +1 and +10 respectively.  If you look carefully you can see the bit of letter-boxing, because this monitor is actually nativelly 1200p.

Then a ~50Hz mode as I was trying to figure out a good 50Hz mode, and checking what the monitor thought of the mode.  This monitor, while nice for such funny modes, is a pain to get it to show the current mode. You have to navigate through quite a few menus to see the current mode info.

 And 1920x1200 @ 60-ish Hz.

In that mode in particular we can see that the scaling of the video imag is not correct within the borders. This is one of the next things on the list to fix.  It isn't hard, as the VIC-IV already has the necessary scaling registers.

Meanwhile, for the curious, here is the BASIC listing of the program I wrote to let me tweak and fiddle with the video modes, as output using petcat -2

   10 k=53295
   20 pokek,asc("g")
   30 pokek,asc("s")
   40 poke0,65
   50 r0=53248+7*16+2
   60 poke650,128
   70 poke53280,6:poke53281,11
  100 rem default mode values
  110 ss=2290:se=100
  120 fh=1072:dh=1056
  130 fw=2432:dw=1920
  140 fp=128
 1000 printchr$(147);"{wht}mega65 video mode editor"
 1010 print
 1020 print"hsync start=";ss;"  (a,s,d,f)"
 1030 print"hsync end=";se;"  (q,w,e,r)"
 1040 print"front porch=";fp;"  (z,x,c,v)"
 1050 print"frame width=";fw;"  (t,y,u,i)"
 1060 print"display width=";dw;"  (g,h,j,k)"
 1070 print"frame height=";fh;"  (1,2,3,4)"
 1080 print"display height=";dh;"  (5,6,7,8)"
 1900 print"hfreq = ";150000/fw;"khz"
 1910 print"vfreq = ";150000000/fw/fh;"hz"
 2000 poker0+1,se/256
 2010 poker0+2,seand255
 2020 poker0+10,ss/256
 2030 poker0+9,ssand255
 2040 poker0+0,fp
 2050 poker0+3,dwand255
 2060 poker0+4,fwand255
 2070 poker0+5,int(dw/256)+16*int(fw/256)
 2080 poker0+6,dhand255
 2090 poker0+7,fhand255
 2100 poker0+8,int(dh/256)+16*int(fh/256)
 3000 geta$:ifa$=""goto3000
 3005 printa$
 3010 ifa$="q"thense=se-10
 3020 ifa$="w"thense=se-1
 3030 ifa$="e"thense=se+1
 3040 ifa$="r"thense=se+10
 3050 ifa$="a"thenss=ss-10
 3060 ifa$="s"thenss=ss-1
 3070 ifa$="d"thenss=ss+1
 3080 ifa$="f"thenss=ss+10
 3090 ifa$="z"thenfp=fp-10
 3100 ifa$="x"thenfp=fp-1
 3110 ifa$="c"thenfp=fp+1
 3120 ifa$="v"thenfp=fp+10
 3130 ifa$="t"thenfw=fw-10
 3140 ifa$="y"thenfw=fw-1
 3150 ifa$="u"thenfw=fw+1
 3160 ifa$="i"thenfw=fw+10
 3170 ifa$="1"thenfh=fh-10
 3180 ifa$="2"thenfh=fh-1
 3190 ifa$="3"thenfh=fh+1
 3200 ifa$="4"thenfh=fh+10
 3210 ifa$="5"thendh=dh-10
 3220 ifa$="6"thendh=dh-1
 3230 ifa$="7"thendh=dh+1
 3240 ifa$="8"thendh=dh+10
 3500 ifss<0thenss=2999
 3510 ifse<0thense=2999
 3520 iffp<0thenfp=255
 3530 iffw<dwthenfp=dw+1000
 3540 ifdw<640thendw=1920
 3800 ifss>2999thenss=0
 3810 ifse>2999thense=0
 3820 iffp>255 thenfp=0
 3830 iffw>3000thenfw=dw+50
 3840 ifdw>1920thendw=640
 3850 iffw<ssthenss=fw-10
 3860 iffh<480thenfh=1500
 3870 ifdh<480thendh=fh-10
 3880 iffh<dhthenfh=dh+2
 3890 ifdh>1300thendh=480
 3900 iffh>1300thenfh=480
 4000 goto1000

Sunday, July 30, 2017

Revamping Hypervisor boot display, and SPACE to enter utility menu

Now that I have a much easier way to develop the boot ROM for the MEGA65 via the monitor_load command (which I have now pushed up from 230,400bps to 2,000,000bps as I previously discussed), I got inspired to fix the boot display of the MEGA65.

Basically in the past we had a 64x64 area for a 256-colour logo.  This predated the renaming to the MEGA65, and the creation of the wide MEGA65 banner.  As a result the banner was all squished into a tiny space and was almost unreadable and quite ugly.

I'd been meaning for a while to rework the boot ROM  to support a 320 pixel wide banner instead, so that the MEGA65 logo could be properly displayed.   So this is what I have done. I have also gone a step further, and included the MEGA65 logo as preinitialised data in RAM, so that it still shows up, even if you don't have an SD card inserted. 

In the process, because it is now so quick and easy to test new versions of the boot ROM, I also added the option to hold SPACE to enter the utility menu, which serves a similar role to the BIOS menu on old PCs, but will have different utilities.  The main utility planned for now is a combined FDISK+FORMAT utility, to make it easier to setup a new SD card for use in the MEGA65.  The utilities are also stored in pre-initialised memory (in this case the upper 30KB of the 32KB colour RAM), so that you don't need an SD card or anything else for them to be there. 

We have the bulk of the FDISK+FORMAT  utility already written, but need to work out how to get CC65 compiled programs to run on the MEGA65 when there is no C64 ROM yet loaded.

But for now, here is a screen shot of the revamped boot display, looking, I think, much nicer:

Hope you enjoy it.

Wednesday, July 26, 2017

Fast-loading via serial monitor for development (part 2)

I woke up in the middle of the night, so decided to finish the serial monitor fast loader for supporting development.

After a bit of fiddling, it is now possible to compile and use the monitor_load program to:

1. Load a fresh bitstream and completely reset the MEGA65, thus allowing reloading a program regardless of the state of the machine.

2. Wait until the M65 boots to C65 mode.

3. Switch to C64 mode via GO64

4. As soon as it is in C64 mode, load the program you provide on the command line.

Example command line:

tools/monitor_load /dev/ttyUSB1 something.prg nexys4ddr.bit

As the serial monitor interface runs at 230Kbps, this gives a maximum load speed of around 20KB/sec.  At the moment it is probably around 15KB/sec, so quite acceptable.

From typing the command to having the program completely loaded takes about 10.5 seconds, for a 16KB program. That is, about 9.5 seconds is spent loading the bitstream, and waiting for Kickstart to prepare the SD card, load the C65 ROM etc, and get to the C65 prompt.

Monday, July 24, 2017

Fast-loading via serial monitor for development (part 1)

Ages back I started working on a mechanism to allow fast loading of programs via the serial monitor interface, but never finished it.

The idea was to add a command to the serial monitor interface that allowed bulk up-loading of data into memory, and trapping the LOAD vector so that it triggered this mechanism. Funnily enough, trapping LOAD from the serial monitor, working out which program to load, and loading it was the easy part.  This has been in monitor_load.c for some time now.

The hard part was working out why what should have been a very simple memory upload command wasn't working.

Well, I finally figured out the problem with this command last night, and fixed it. The problem, as is so often the case, turned out to be quite simple: There was a safety catch that reset the UART monitor to CPU request strobe whenever a character was received via the UART interface.  This is normally fine, but in bulk upload, this was cancelling the request to write the byte to memory each and every time it was made, resulting in timeout errors in the UART monitor, and a complete lack of loading of the data.

So I fixed this problem, and now I can easily write ranges of memory with arbitrary via the UART interface, at approximately 20KB/sec, since I am running the serial interface at 230,400bps.

The nice thing is that I also worked out how to jtag program the FPGA via the USB lead which also carries the serial monitor interface.  This means that I can write a small shell script that pushes a bitstream into the FPGA and resets the machine, and then waits for someone to try to LOAD something, and then loads what you want at 20KB/sec.  This is a really nice advance for writing software for the MEGA65, as from a cross-compiler you will be able to start the program automatically on a clean machine in just a few seconds. If nothing else, it means that you won't have to fiddle about pulling microSD cards out any more.

You might have noticed I used the future-tense there.  This is because while I now have all the pieces mostly ready, I haven't finished pulling them together.  I hope to do this over the next few evenings, time and energy permitting.

What I have managed to do, however, is to make the serial interface speed run-time selectable from the serial monitor itself.  This means that we don't have to be limited to 20KB/sec, which while nice, would still take a few seconds to load 64KB, and a rather annoying dozen seconds to load 256KB (128KB normal RAM, plus 128KB of "ROM" RAM), when testing larger programs.

There isn't too much to see at the moment, except if you were to try my new bitstream and issue the command:


from the UART monitor interface.  At that point you would see rubbish, until you set your terminal program to 1,000,000bps, i.e., a little better than four times the current speed, and thus allowing something like 80KB - 100KB/sec, which should allow for nice fast loading of all of memory.

So then I tried:


to set it to 2,000,000bps. That seems to work, too, and should allow ~160KB - 200KB/seconds. Even nicer. Sadly +10 didn't work for trying to set it to 3,000,000bps.

Oh well.

Anyway, hopefully I will have an update in a few days showing the ability to fast-load close to 200KB/sec in a development environment, to make writing MEGA65 software more pleasant to do.

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.