Emulating bus contention and improving the cycle accuracy of the T80 core is definitely on the cards, but for now the ability to finally load emulator images from SD makes the machine extremely usable.  An explanation of how to get this up and running is a job for another post (hint: format the card as IDEDOS and bootstrap ResiDOS into the extra RAM), but for the time being here is a detailed write-up and the full VHDL source.

And let’s not forgot the obligatory eye candy…

Planning to revisit the Spectrum design next for some bug fixes, as it is clear there is still quite a bit of interest in that.

You can see the MMBEEB ROM extensions providing access to multiple disk images on the SD card, then some messing about on Chuckie Egg and Boffin.

BBC Micro boot screen running on FPGA

It’s been a while since the Spectrum project and, although there is still work left to do on that, I eventually gave in and did another great British computer from my childhood – the BBC B.  Getting this machine up and running has been an interesting job given its complexity.  For something that first came out in 1981 it really is a sophisticated computer, and one that I’m sure anyone who grew up in the UK in the 80′s and early 90′s will remember.

I’ve written this one up on its own page so that it doesn’t disappear, and the Speccy will get the same treatment in the next few weeks.  A bitstream image is provided for you to run on your own DE1 board, if you have one, and the full VHDL source code is available too.

A detailed description of the design is also in the works, and should be ready in a day or two.

Enjoy!

A full write-up will follow, but here is a quick summary:

The implementation is of a standard PAL 48K Spectrum.  IO is via the DE1′s existing interfaces, with the video hardware able to drive either a normal TV (via RGB SCART) or a PC monitor.  In the latter case the picture is double-scanned to obtain the required line scan rate.  A PS/2 keyboard can be connected although you will probably need a picture of a real Speccy to work out what all the keys do!  Some key combos like caps-lock and escape (BREAK) do actually work, though. Audio input and output are both available through the normal jacks, and programs can be loaded from tape or by using something like playtzx on a PC.  Loading images from SD card is planned but not yet implemented.

The design runs from a PLL-derived 28 MHz clock with clock-enables used to time-slice RAM access between the CPU and video hardware.  The CPU runs for one cycle in eight, resulting in the required 3.5 MHz cycle time.  Note that because of this time-slicing there is no RAM or IO contention, so this is slightly faster than a real Spectrum meaning that some games and turbo-loaders don’t yet work properly.  The CPU is a synchronous T80 core connected to the rest of the hardware through some address decoding and multiplexing logic.  The ROM image is contained on the FPGA, but the external SRAM is used for the Spectrum’s RAM, and the entire 48K is accessed over one time-sliced bus.  The address applied to the SRAM comes from either the CPU address bus or the video logic depending on whose turn it is.

On the IO side the ULA’s single IO port is implemented.  The PS/2 keyboard interface applies key up/down events to an 8×5 matrix representing a real Spectrum’s keyboard.  This matrix is addressed by the CPU and routed to the ULA IO port as in the real thing, so no changes to the ROM are needed.  Audio is fed both ways through the Wolfson codec which has its settings loaded on reset by a simple I2C loader block.  The register settings are hard-coded into this logic.  A bidirectional I2S<>parallel interface is used to interface the audio bus with the ULA register.  For recording (EAR in) the sign-bit from the capture side is used – some hysteresis would probably be beneficial here.  Note that the audio codec has its own 24 MHz clock and operates asynchronously with the rest of the design.

Four of the slide switches are used:

• SW9 – /RESET – Down to reset, up to run
• SW8 – PLL reset – Leave this down
• SW7 – Slow mode – Allows CPU operation to be traced on the LEDs – Normally leave down
• SW6 – PAL/VGA – Down for PAL (SCART) or up for VGA (PC monitor)

Several years ago I implemented most of the ULA in VHDL on a MAX7000 CPLD, mainly as an exercise to brush up on my HDL.  I didn’t have enough space to fit the keyboard interface so it was pretty useless, but it did boot!  The complete system used a pair of SRAMs, real Z80 and the Sinclair ROM in flash.

Back at the beginning of this year I decided to brush up on my HDL again and I bought myself an Altera DE1 development kit.  The heart of this board is a Cyclone II FPGA with a range of support hardware including 512KB SRAM, 8MB SDRAM, 4MB flash, an I2S audio codec, VGA port and the usual switches, LEDs and buttons.  I would highly recommend it for anyone looking for a relatively cheap way to play with FPGAs.

This time I decided to put as much as possible into the FPGA.  All the core ULA logic is in there along with a Z80 soft-core (T80 from opencores), the ROM, proper bus routing (the real Spectrum used a lot of tricks that simply aren’t an option in an FPGA), VGA scan-doubling for the video output, logic to drive the I2S audio codec, plus a PS/2 keyboard interface.  Apart from the audio codec, which is absolute overkill and only used because it is already on the board, the only other key part external to the FPGA is the SRAM.  This is used for both contended and non-contended memory regions by a method which I will cover in a later installment.

A full write-up will follow, along with better pictures, video and full VHDL for the project once it has been cleaned up a bit.  In the meantime here are a couple of photos of the thing in action (click for bigger, and yes I did load that from a real tape!)

Searching through the junk box I managed to find a dual-mode LPC/FWH device of the same size (PMC Pm49FL004).  This one was responding properly to write commands, but I needed a way of reliably transferring the new BIOS image down to the AVR.  The flashrom project already has support for an external AVR-based programmer (called serprog) but this is for devices using a parallel interface only.  However, it was a fairly simple task to take the serprog protocol support from the existing flashrom programmer and graft it onto the LPC interface code I had already written.  The resulting AVR code can be downloaded here and was tested with both the Ubuntu 10.04 version of flashrom, and with the latest development build from SVN.  A Makefile is included for building the project on Linux using the GNU AVR tools.

The hardware side was based around an ATMEGA88, although it could be ported to pretty much any ATMEGA device with minimal effort.  Connections to the LPC bus are defined in board.h, and these can be connected directly to the flash chip, although care should be taken to ensure that the supply voltage is restricted to 3.3V.  If using the STK500 then this has a programmable target supply which can be changed using AVR Studio, or with avrdude in terminal mode.  As well as the various power connections that the flash device will require (refer to its datasheet) it was also necessary to tie /WP,/TBL and /INIT high for correct operation.  Other pins can be left unconnected.  For best results the AVR clock needs to be faster than the 3.6864 MHz that the STK500 can provide by itself, but it does need to be of a suitable frequency for baud-rate generation; I used a 7.3728 MHz crystal.  The actual frequency used needs to be specified in the Makefile.

Many thanks to carldani and others on #flashrom for their help in putting this hack together!

Updated: The source code archive was missing a couple of files, which are now included.

AVR32 NGW100 Driving an STN LCD Module

I’ve had a few controllerless QVGA (320×240) mono LCD modules lying around for a while looking for some use.  These are fairly easy to get going with a low-end microcontroller using an external controller IC like the SED1335, but that’s another story.  I’d been thinking about doing some sort of integrated home automation project, and since this would need a user interface and I happened to have an NGW100 going spare, getting one of these displays to run on the AP7000′s integrated LCD controller seemed like a nice idea.

The NGW100 only has a 16-bit interface to its already relatively slow DRAM, so driving a high-res colour LCD from it leads to a fairly obvious slowdown.  For this application a mono display would be adequate, and easier to drive, requiring only a 4-bit data bus, the 3 clocks and a GPIO to power up the drivers.  The LCDC has no problem driving an STN panel, although I had to deviate from the datasheet in one area to get it to work – more on that later.

The particular panel (a Samsung UG32F05) requires a 5 V logic supply, but also calls for around -20 V for the LCD drive.  In the prototype this was generated using a nasty buck-boost converter thrown together from a 555 timer and a MOSFET, but this is not recommended (use a real switch-mode controller)!  The 5 V was derived with a linear regulator connected to the NGW100′s 2-pin power header, and the signal lines from the LCDC were connected up directly (D0-D3 straight through, PCLK to XSCL/CL2, HSYNC to LP/CL1 and VSYNC to DIN/FLM).  Because powering an STN display without the proper clocks applied can cause damage the module provides a /DISPOFF connection, which was driven from a spare GPIO on the NGW100.  Normally this would be connected to the LCDC’s PWR output, but this is shared with the SD card detect input on the NGW, and the application would be using this.  The pinout of the module goes like this:

To get the display working from Linux (I started from a vanilla 2.6.28.1 kernel) I created a copy of the evklcd10x.c board support module, added it to Kconfig and modified it to suit the parameters of the new LCD.  The fb_videomode structure was set up as follows:

• refresh = 75
• xres = 320, yres = 240
• pixclock = KHZ2PICOS(1500)
• left_margin = 1, right_margin = 1
• upper_margin = 0, lower_margin = 0
• hsync_len = 2, vsync_len = 1
• sync = FB_SYNC_HOR_HIGH_ACT | FB_SYNC_VERT_HIGH_ACT
• vmode = FB_VMODE_NONINTERLACED

This gives a refresh rate of around 75 Hz, although this is mis-reported by fbset.  The settings in the fb_monspecs structure are not that critical (it seems).  I set the frequency ranges based on the quoted timing data for the display.  More important is the atmel_lcdfb_info data, which was set up like this:

• default_bpp =1
• default_dmacon = ATMEL_LCDC_DMAEN | ATMEL_LCDC_DMA2DEN
• default_lcdcon2 = ATMEL_LCDC_DISTYPE_STNMONO | ATMEL_LCDC_SCANMOD_SINGLE | ATMEL_LCDC_IFWIDTH_4 | ATMEL_LCDC_INVVD_INVERTED
• guard_time = 2
• default_monspecs = fb_monspecs_structure
• atmel_lcdfb_power_control = lcd_power_control_function

The power control callback function is called by the driver after the controller has been set up and the timing signals are valid.  This is used to control the GPIO pin connected to the /DISPOFF input of the panel.  It is trivial, and along with an updated initialisation function it looks like this:

#define LCD_nDISPOFF    GPIO_PIN_PE(7)

static void lcd_power_control_function(int on)
{
printk(KERN_INFO “Turning LCD power %s\n”,on ? “on”:”off”);
gpio_set_value(LCD_nDISPOFF,on);
}

static int __init lcd_board_init(void)
{
at32_add_device_lcdc(0, &lcd_board_lcdc_data,
fbmem_start, fbmem_size,
/* IO port mask */
ATMEL_LCDC(PE, DATA0)  | ATMEL_LCDC(PE, DATA1)  |
ATMEL_LCDC(PE, DATA2)  | ATMEL_LCDC(PE, DATA3)    |
ATMEL_LCDC(PE, MODE) |
ATMEL_LCDC_CONTROL);
at32_select_gpio(LCD_nDISPOFF,AT32_GPIOF_OUTPUT); /* LCD /DISPOFF */
return 0;
}

That should be it.  However, it turned out that the AP7000 was generating 1/4 the number of clocks per line that it should have been even considering the 4-bit interface (20 clocks instead of 80).  Although I established this fact prior to connecting the module, visually this results in a display of vertical stripes.  In the datasheet it states that for STN mono mode, HOZVAL (found in the LCDFRMCFG register) is equal to (number of horizontal pixels / interface width) – 1.  The Linux driver calculates HOZVAL based on the display type, but does it by the book and chooses a value of 79 (320/4-1).  It was found that going against the datasheet and setting HOZVAL=319 solved the problem.  This was implemented by patching atmel_lcdfb.c so that hozval_linesz = info->var.xres (around line 577).  Please feel free to point out where I have screwed up here, or if this is indeed a mistake in the databook!

Once the board boots you can use fbset -depth 4 to switch to 16 shade greyscale mode.  The photo above shows the Qt text editor demo running in this mode.  Certain shades of grey exhibit a slight flicker, but for an STN display the image is pretty reasonable.