Sunday 7 May 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.

4 comments:

  1. Nice post, thanks :) I've already seen this matrix-mode stuff, but only in the form of VHDL not so much as a screenshot :) As far as I can judge, it's almost the same as Xemu uses On-Screen-Display for some information (not so much yet, but the framework is there), it's exactly like this, with alpha channel for adjustable transparency. That means, that in theory it wouldn't be extra hard to implement something like this in Xemu too, though I always thought an external debugger/monitor is better for an emulator (for a real hardware, it can be a bit different issue). But anyway, it just sounds so nice, it's hard to resist ;-D

    ReplyDelete
  2. Does the 1080p mean that a 16:9 monitor is required?

    ReplyDelete
    Replies
    1. A good question. It should work on any shape monitor, it will just be a question of how it looks. We might be able to offer a video mode optimised for 4:3 monitors for those who still have them, but possibly only via the VGA output, not HDMI. Let me get the 1080p video mode working properly first, and then we can figure out the best way to do that.

      Paul.

      Delete
  3. For default can the debugging be like this? https://2.bp.blogspot.com/-lp-S7I6EWxI/WQ8WKAa-FKI/AAAAAAAAGLo/GRv4wSU_rcEsuEm9quBGuzg-qDkxV-TxwCLcB/s640/IMG_20170507_150918.jpg

    It reminds me so badly of Apple II/c (monochrome monitor) and Commodore 64 poke 53280,0:poke 53281,0 with green cursor...

    look what just happened...my head is swimming and I just shivered!

    PLEASE KEEP IT LIKE THAT AS DEFAULT! I will buy your mega65 regardless of price if you do it.

    ReplyDelete