RAM Upgrade

Someone has just pointed out to me that he Nexys4 board that the C65GS project is based on is about to receive a modest upgrade in the form of switching from the 16MB cellular RAM to a 128MB DDR2 RAM module:

http://www.digilentinc.com/Products/Detail.cfm?NavPath=2,1301,1319&Prod=NEXYS4DDR

Reading through the new reference manual for the Nexys4 DDR, I discover the following:

The Nexys4 DDR is an incremental update to the Nexys4 board. The major improvement is the replacement of the 16 MiB CellularRAM with a 128 MiB DDR2 SDRAM memory. Digilent will provide a VHDL reference module that wraps the complexity of a DDR2 controller and is backwards compatible with the asynchronous SRAM interface of the CellularRAM, with certain limitations. See the Nexys4 DDR page at www.digilentinc.com for updates.
Furthermore, to accommodate the new memory, the pin-out of the FPGA banks has changed as well. The constraints file of existing projects will need to be updated. 

The audio output (AUD_PWM) needs to be driven open-drain as opposed to push-pull on the Nexys4.

So overall the changes look relatively small, and it shouldn't be hard to port the design to the new board.

The actual DDR2 memory part is a MT47H64M16HR-25:H, which is capable of 667MB/sec, but according to the reference manual the practical limit will be 650MHz.  Xilinx have a memory interface generator which should make it fairly easy to interface to this RAM, although DDR memory is inherently more complex.

I will likely implement a very small cache, perhaps 8 or 16 bytes, because although the DDR2 RAM has a bandwidth of 650MB/sec, the random-access latency of DDR memory is typically fairly high, and it will be important to avoid incurring this latency on every slowram memory access.

Taking a quick look at the data sheet for the DDR RAM, it looks like the actual speed is 650MT/sec, i.e., 650 mega-transactions per second. I have done some reading on DDR and DDR2 RAM lately, but will need to sit down with the actual memory specifications to work out what this all means in practice.

What is almost certain is that the DDR2 RAM could drive a linear frame buffer if I wanted to, but as I have discussed on the mailing list, a linear frame buffer doesn't fit my definition of an 8-bit style computer.  However, there is already 128MB of address space already reserved for slowram expansion, so it will be quite straight-forward to incorporate it.

LCD Screen Test

I had a little time this evening so I unpacked the LCD panel and driver and hooked it all up to see if it works.  The beginning looked something like:

 The VGA lead is connected to the C65GS FPGA board. And again from above:

So then I tried to turn it on, which, pleasingly resulted in the back-light illuminating, but sadly not in any picture.

So flip the panel over and check that everything is properly connected with the data cable:

The panel end of the cable wasn't quite in properly, but once it was then things were happy:

The next steps for laptopification are now likely to be in the direction of designing a 3D CNC millable case, that can hold the screen, FPGA board, keyboard and other components.  This is where I step outside my current expertise.  If anyone is interested in helping to design the case, I would welcome their assistance.

Some parts for laptop prototyping have arrived

I have been away on holidays with the family for a couple of weeks, so haven't really touched the C65GS during that time.  

However, just before we flew out I ordered a 15.4" 1920x1200 LCD panel and driver circuit from China to use for laptop prototyping. China air-mail is outrageously cheap to Australia if you don't mind waiting 2 - 6 weeks for delivery.  Since I was going to be away, I figured I could wait.  

So after letting our local post office know that they might need to hold the parcels a bit longer than usual in the unlikely chance that they would turn up early.  

And turn up early they did -- at around 2 weeks including the dispatch time from the suppliers.  Of course, in theory air mail (and sea mail for that matter) from China to Australia should be fast, since we are in the same general part of the world, and their are multiple direct China-Australia flights and sea freight routes.

Here are the two boxes before un-packing:

First, I opened the little one which contains the panel driver:

Then the big one with the 15.4" panel:

The panel is a bit smaller than I expected, being only just larger than the dimensions of my 13" MacBook Pro.  The difference is mostly due to the really fat bezel on the MacBook Pro.

This all makes me happy, because I really want the C65GS laptop to be as compact as possible, especially since I know that it will have to be about 4cm - 5cm thick to fit the full-travel keys, FPGA board and other components in.

I got my genuine C65 keyboard out to see how it compares in width: The screen is only a couple of centimetres wider than the keyboard, so just about perfect.

The next step is to get a 12v UBEC or other power supply so that I can hook the panel and driver up and test that they work.

Working on the anti-aliaser

I finally got around to plumbing the alpha-blender together to begin testing it for use with anti-aliasing text.

Not surprisingly, there are some things that aren't quite right. Primarily, Xilinx's reference implementation of an alpha blender doesn't quite seem up to the 192MHz pixel clock.  In particular, the blue channel is failing to meet timing closure, and seems to be delayed by a few pixels, as can be seen in the screen shots here:  

The displacement is a fixed number of physical pixels, as can be seen if I change the horizontal scaling of the text generator:

The timing failure isn't too surprising, given that the alpha blender uses a double-clock rate to multiplex the DSP operations to save a bit of silicon.  However, it means that the blender is effectively running at 192MHz x 2 = 384MHz. 

I think I will have to modify the blender so that it doesn't need to multiplex DSP blocks, and can hopefully then meet timing, and avoid the colour planes separating like this.

Proportional font glitches fixed

It is almost a week since I fixed some underlying faults in the hardware support for drawing proportional fonts, together with some bugs in my font file generator that was trimming the right-most pixels from some glyphs.

However, it is only tonight that I have managed to get the display working, because the character generator logic in the VIC-IV would seize up when trying to display variable-width full-colour characters. I eventually tracked the bug down to the paint_ready flag never being cleared if the VIC-IV was asked to draw a one-pixel wide 256-colour character.

This came about because the logic previously assumed that there would always be a 2nd-to-last pixel in a character, which is clearly not true when a character is trimmed to be just a single pixel wide.

Now that I have that fixed, I can finally draw variable-width anti-aliased* fonts.  The following two screen shots are of the same Unicode string being rendered using 10 point and 20 point versions of the same font. You can get an idea of the size of characters from the grid of junk at the bottom of each.

Again, the matrix-like tint is due to the colour-cube approximation of the VNC viewer I used to capture the image.  The characters look pure white on the VGA display.

Obviously the 20 point version (top) looks nicer than the 10 point version.  That said, to my wooden eye, they both look pretty decent.  The kerning looks acceptable, and both ascenders and descenders on characters are drawing fine.

I haven't optimised the unicode printing routine code at all yet, so it is still fairly slow to draw. Nonetheless, I can draw those several words in well under a frame, as can be seen in the following screenshot where I set the border to white while the drawing happens:

Earlier I said that I can now draw anti-aliased characters.  This is currently true only if I want to consume the entire 256-colour palette on fake alpha-values.  As discussed in earlier posts, I am part-way through implementing a real alpha-blender that will allow each character to be a different colour, and appear on a different background.

I also need to get around to implementing variable height characters, so that there are no large blank regions between lines when the upper rows of pixels in the top-most row of characters of a font are unused.

The other thing I hope to work on soon is to update the little programme I wrote to display the unicode text so that it can access fonts located outside of the first 64KB of RAM.  This will use the new 32-bit indirect zero-page addressing modes.  Then I will be able to display text from different fonts on the same display.

First steps towards a C65GS laptop

From the outset I had thought about what form-factor the C65GS would have as a computer.

Basically it was a question of whether to make it something that looks and feels like the original C65, or whether to make it into a laptop.

Nostalgia said that something that looked like the original would be nice.  However, the realisation that being able to create 3D-printed or injection moulded replicas of the C65 case would be extremely expensive put a dampner on that idea.

Also, as I got working on the C65GS I found myself increasingly desiring a portable computer - both for taking places to show and so that it could be used for some light general productivity.

So I have been thinking about how to do this, and taking a look at what some other very clever people have done in the past.  The most interesting one is this laptop commodore 64, made using original parts.  This is interesting to me, because it was created using a real C64 keyboard, and he fabricated the case parts himself.  While I don't plan to use a real C64 keyboard for mine, I do intend to use the real C65 keyboard I bought on ebay recently.  Fortunately, the C65 keyboard already has the function keys moved to the top, and so is narrow enough to be used unmodified in a 15" laptop.

More of how Ben fabricates custom cases like this is covered in another post of his.

However, before I get to that point, I need to work out exactly what I intend to cram into the thing.

Obviously the Nexys4 FPGA board needs to go in.

I have already sourced 4 x 30Wh LiFePO4 rechargeable batteries, sufficient to skirt the air-line limits in several countries, but also enough to run a bright screen for a few hours at least.  I'll need to find a charger circuit for them, perhaps something like this that should allow me to put 15.6V in and charge the batteries.  The output from the batteries then can be fed into one of these to provide enough 12V for a 15" LCD panel, and a very similar one of these to provide ample 5V for the FPGA board and related circuitry.

I had originally looked for a 13" 1920x1200 panel, but those are rare as hens teeth, so have settled for a 15.4" one.  After a bit of hunting it looks like this panel and this LCD driver kit should work together, and will accept the 1920x1200 60Hz VGA signal from the FPGA board.

This leaves the joystick/keyboard/IEC serial and other ports, plus speaker driver PCB as the great unknown in terms of internal components. However, even without that PCB, I am starting to have a think about how things would be arranged in the eventual case.

I will probably use a similar approach to Ben's portable C64, and have an external lead that connects the panel in the top half of the case to the lower half.  Because I am using VGA connections, I am contemplating making the cable easily removable, at least from one end, so that it is easy to connect to an external monitor, or indeed use the 15" panel as a VGA display for something else when required.

I might buy a panel and LCD driver kit just to get my head around getting those working together and with the FPGA board, and then incrementally work on everything else as I get the opportunity.

Migrating to Vivado (Part 3)

Vivado is still refusing to synthesise the various BRAM blocks correctly.

I have, however, had a response to my post on the Xilinx Community Forums asking for more information about the problem, which I have provided.

Let's hope that they can suggest a solution.