In my last post I outlined the planned hardware for our CPC dongle.  Now let’s look at how that hardware might fit together.   I’m focussing on the modules internal to the FPGA, as this is where all of the complexity lies.

Behold, the grand design:

This probably needs some explaining!Part 1 described the function of each of the physical components, so let’s look at the internal functional blocks.

Starting with the right hand side of the diagram, most of this functionality are the CPC modules themselves.  Top-to-bottom, left-to-right order, the modules are sound, CPU, Disc interface, keyboard, RAM/ROM controller, CRTC, SDRAM controller (not strictly a CPC module, but still a key function), Gate Array.  The PPI is not shown due to lack of space, but will sit between the sound and the CPU.  Some of the CPC bus connections are also not shown.

The PAL graphics render is a special “virtual” display or VDU.  This is one of the key modules to modernizing the CPU hardware.  Many of the legacy hard emulators or older FPGA implementations interface to VGA or analogue video electronics to maintain special video modes.  This project will interface to modern hardware such as your home LCD panel, up to 1920 x 1080 at 60Hz by converting the PAL signal to an upscaled HDMI signal.

As the CRTC and Gate Array ‘draw’ the CPC output image, it will be captured by the render unit and stored as a “picture” in main memory.  The CPC framerate is a non-interlaced image at 50Hz to match the UK mains frequency, so 50 times per second the memory holding the active frame is switched.  We then have a full frame available 50 times per second for upscaling to HDMI, at 60 frames per second.  We will use a framerate of 60Hz for the HDMI image, so we’re displaying at least every frame created by the CRTC/GA, some will be duplicated to avoid video tearing.  This should ensure that at least some of the special display modes are catered for.

Here’s a simplified diagram of the display handler:

The image capture will handle the full-frame PAL capture, and convert to green (or any other arbitrary colour) for storing in the memory ready for the HDMI upscale to pass the data to the HDMI encoder.  I’m considering whether we can make better use of the buffer memory as only 27 colours are output from the CPC, but each byte has 256 possible states, giving rise to the option of a high colour mode available to the supervisor CPU.  I’ll look into this later.

Onto the other modules.  The CPC sound module will output three square waveforms plus a white noise channel. This waveform will be either mixed or sent to separate channels for output through the HDMI connection. This will provide the sound through your TV, just like the 80s! The module that converts this waveform to the I2S required by the HDMI encoder, is the Wave-I2S module.

Before we leave the CPC components, it’s worth mentioning the CPC Disc Emulation module. This will appear to the CPC to be the original Hitachi 765FDC chip.  In reality it will make requests of the supervisor CPU (labelled support CPU in the diagram) to get data from the flash memory. The command set will be exactly the same allowing drop-in compatibility with the existing AMSDOS or after market ROM.

The inter-CPU controller will be a coordination module.  This will handle the hard reset of the CPC CPU and the suspension of the input clocks allowing the supervisor CPU to pause the CPC and present a user interface controlling various aspects of the CPC emulation.  Examples would be swapping disks, tapes, ROM  configuration, display mode (green/colour), HDMI resolution and so on.

It will also be able to handle inter-CPU communication, and with suitable software on the CPC side we can provide access to some of the modules connected only to the supervisor CPU, such as the M-RAM and FT2232 interface.

A special note on the keyboard module, as this does not have an external interface and requires the supervisor CPU to identify which keys are pressed and when. On the supervisor side, the USB host will allow the connection of a USB keyboard, that will provide the input to both the supervisor program and the CPC itself through the keyboard emulation unit. This allows us to dynamically map keys and use modern keyboard layouts.

We already mentioned that the Flash memory will provide the disk images through the 765FDC emulation.  It will also provide the tape images and ROM images for the CPC.  These will get pushed into the main SDRAM at boot time, based on the required configuration.

Configuration of the system will be stored in the M-RAM.  We could use the Flash memory, but as this has a finite lifetime of writes, the unlimited M-RAM would be more robust and allow frequent changes of settings such as the ROM config.

The FPGA config device will be oversized for the FPGA configuration data, so I’m planning to store some immutable images in here, such as the CPC ROMs, AMSDOS and application ROMS, like the Arnor Maxam Assembler. The supervisor chip will insulate the request from the source.

The FT2232 device will be used for communication as well as configuration and debugging of the FPGA with Quartus.

Finally, the Bluetooth module may be used as a wireless keyboard, wireless gamepad/joystick, and possibly wireless communication say with a smartphone.  This lends itself to a smartphone app to manage the configuration. A nice touch, but not essential.

There is a huge amount of work to do, but as they say, sometimes it’s about the journey.

Don’t miss part 3 where I explore the capacity and timing constraints of the SDRAM.