In the post which first discussed the MAXI000 board I plan to build, the idea of using a programmable oscillator to generate the pixel clock for video output was brought up.

A programmable pixel clock would have a big advantage: video modes would not be fixed by the choice of pixel clock oscillator. It would be possible to experiment with different resolutions and refresh rates without swapping the oscillator out for a different frequency.

The requirements for a programmable pixel clock generator for the MAXI000 are:

• 5V
• Supporting frequencies up to at least 40MHz
• Configurable via SPI
  • I2C would be considered, but only as a last resort

So far the best, and possibly only, candidate is the LTC6903 (PDF). I duly ordered a couple from mouser, and built a simple test rig:

As you can see, the IC is tiny and looks swamped attached to its adapter on the breadboard. It is in MSOP (Mini Small-Outline Package) and is 3mm long from end to end.

In any case, if I’d read the datasheet fully (and not just the features list) I would have appreciated that the part would not be suitable as a pixel clock generator.

At low frequencies, the square wave generated is nice and square, and most importantly of constant frequency. However, into the 10MHz range, the frequency generated wanders up and down. This is shown in the datasheet in the output spectrum graph:

If I’m interpreting this graph correctly, then at 20MHz the output will consist of around one in a thousand “pulses” being at plus or minus 1MHz. This might be suitable for some applications, but not a pixel clock. This was born out in the test performed where the output of the programmable oscillator was attached to the VGA FPGA, after removing the 25.175 MHz oscillator can. Sure enough the picture looked pretty terrible, and not all the problems can be put down to the use of breadboards.

There may well be other, more suitable, programmable clock generators to choose from. But the conclusion is it is best to stick with a fixed clock.

This leads to the interesting problem of actually obtaining a 25.175MHz oscillator can that is both 5V and available in an SMT package. Whilst using a through-hole oscillator can would be perfectly acceptable, using as many SMT parts as possible is preferred.

Unfortunately actually finding a suitable part seems to be impossible, on eBay and on electronics component suppliers websites.

So the solution I’ve come up with is to cheat a little and use a 25MHz oscillator instead. I’ve read that most LCD and indeed old CRT monitors are fine with a 25MHz pixel clock.  After all, it is only a 0.7% variance. However, to be sure I sourced a through-hole 25MHz can and tried it out in the IO Board. Sure enough, a good picture resulted.

It is worth pointing out that the Flex 10K FPGAs (PDF) are really not fast enough to cope with faster pixel clocks; the timing analysis on my current VGA VHDL implementation gives a current maximum pixel clock of 42MHz. Unfortunately the EPF10K20s I’ll likely have to use on the MAXI000 board are the -4 speed version, instead of the -3 version currently used. As a quick test, an EPF10K10 -4 would have a maximum pixel clock rate of only 32MHz so it looks like 640×480@60Hz will be the only resolution available. Not a big problem, but it is slightly annoying.

Now onto the main purpose of this post; a description of the MAXI000 schematic since it is now, pending any last minute changes, at a point where PCB layout can begin.

Before looking at the schematic, here is a summary of the main features of the board, and the parts used:

• 68HC000 (PDF) @20MHz:
  • 68010 (PDF) will be optional, though this PLCC part will be soldered and not socketted to save board space so swapping MPUs will be a little involved
• 1MB of SRAM using 2 x IS61C5128AL (PDF) in SOJ36
• 1MB of Flash using 2 x SST39SF040 (PDF) in PLCC32
• A single 72 pin SIMM slot providing support for at least 8MB SIMMs
• 4 UART ports provided by a  SC16C654 (PDF) in PLCC64:
  • 2 x EIA-232 on RJ45s
  • 1 x TTL header
  • 1 x External keyboard connection on RJ10
• 1 Atari Joystick port presented on a 74HC574 (PDF) addressable latch
• 1 PC-Game port joystick port:
  • Four analogue axis readable via SPI and provided by 2 x MCP3002 (PDF)
  • Four fire buttons presented on a 74HC574 addressable latch
• Stereo 8 bit PCM sound output provided by 2 x MCP4902
  • Each channel has a 8 bit volume level
• IDE interface
• Real Time Clock (and board temperature reading) provided by a DS3234 (PDF)
• “Alpha” FPGA:
  • Implemented with a EPF10K20 (PDF) in QFP144
  • Attached to all MPU pins
  • MMU:
    • 4KB pages
    • Page tables held in main RAM, with MPU suspended during lookups
    • Page cache held in FPGA RAM bits
  • DMA controller
  • SIMM controller
• “Beta” FPGA:
  • Local 1MB (512K x 16) SRAM implemented with 2 x IS61C5128AL
  • VGA interface:
    • 640×480@60Hz
    • 4 bit RGB DAC
    • Text and graphics modes
  • Sound interface:
    • DMA from local RAM to PCM output
  • SPI master
  • Interrupt routing
  • Miscellaneous IO: LED and buzzer
• Expansion connector

There are  two types of system RAM: static and dynamic, as provided by a 72 pin SIMM. The main reason for this is to have a computer that’s useable without a working SIMM slot, which will ease the bring-up. It also means the board will not be a total write off in the, hopefully unlikely, event that I cant get the SIMM socket to work reliably.

The IS61C5128AL SRAMs used are 12nS parts. To keep things simple 12nS memories are used for both system and video memory, even though system memory does not need to be the fast type.

Now onto the schematic.

There is very little interesting here. This is the same Quad UART as used on the MAXI09 board to good effect. The port arrangement is the same as well, with ports A and B being used for the RJ45-presented EIA-232 interfaces, port C being used for the TTL-level header (used for bring-up only, most likely) and port D being used for the connection to the keyboard.

Unlike with the IO board, the UART IC is attached to the high half of the 16 bit data bus. This will present the IC on even addresses, which is the usual arrangement for 68000 computers with 8 bit peripheral ICs.

Like the 68000 itself, SC16C654 in PLCC will be soldered directly to the board instead of being socketted.

Next, the joystick section. The addressable latch arrangement is identical to the MAXI09 board except, again, the 8 bit part is attached to the high half of the 16 bit data bus.

Unlike with DISCo’s SPI controller, the MISO (Master-in, Slave-out) SPI pins are all connected together. After studying various SPI peripheral IC datasheets, it appears that most if not all SPI peripherals will tristate their MISO pin when the IC is not selected, allowing the pins to be joined together at each IC.

Once again, the MCP3002 is an IC that was used on the MAXI09 board, albeit the SMT version will be used here.

Next up, sound and “other” SPI peripheral ICs. The sound section is identical to what was previously prototyped, except there are now two channels instead of one.

The Real Time Clock IC, a DS3234, was used long ago in an IO board for an a pre-MAXI09 computer. This part is pretty interesting because in addition to presenting an RTC it also has a temperature sensor. The crystal is also a built in component of the IC. I have gone for a smaller CR1225 3V cell to hold the time when the board is powered off, as well.

Next, IDE. This is a bit more complex then the IDE interface on the MINI000 IO Board. Bi-directional buffers, in the form of 74HC245 (PDF) have been added. This will prevent the MPU data bus being directly attached to the IDE device, which might at the far end of a long cable. Low value resistors have been added to terminate the bus in another attempt to improve signal quality.

Next up, the 68000 itself. Very little to say about this one. Pull-up resistors have been included to allow inputs (eg. /DTACK) to be driven by off-board sources (ie. expansion board) as well as being driven by Alpha, which will tristate the pin when it is not asserted, instead of pulling it high. Outputs from the 68000 are also pulled up, to cater for the times when the buses are being mastered off the board and not by Alpha. It’s unlikely I will ever have a bus  master which isn’t the 68000 or Alpha, but it never hurts to cater for all possibilities.

The MPU’s memory arrangement is identical to the MINI000 board’s, except that the “ROM” is now provided by two SST39SF040 in PLCC32. These parts are flash memory and not EEPROMs that I have used in my projects for this purpose up until this point.

The principle advantage flash has over EEPROM is storage size; flashes are available in monstrous sizes. In this case, the parts are more modest: each IC is 512k x 8.

One disadvantage (or perhaps it is an advantage, it depends how one looks at it) is the programming process is more complex then with EEPROMs. Instead of simple SRAM-style memory writes – perhaps with suitable timing constraints observed – a command sequence has to be followed. This makes programming more complex, but the advantage is inadvertent writes are essentially impossible. None the less the board includes a write protect jumper.

Now the “heart” of the board: the two FPGAs.

This section also includes the two oscillators:

• 32M – This is the 32 MHz system clock which Alpha will divide down to obtain the 16 MHz MPU clock. The 32 Mhz clock will drive the DRAM state machine, and driving it twice as fast as the MPU should hopefully eliminate wait-states.
• PIXELCLOCK – The pixel clock for video generation.

The naming of 32M (and 16M) is poor and will be changed.

Alpha is attached to the full 24 bits of address bus:

• The low 12 bits (within a page) is labeled simply A1 to A11
• The high 12 bits on the MPU side is labeled LA12 to LA23, and forms the logical number of the page to be accessed
• The high 12 bits on the memory (and other devices) side is labeled PA12 to PA23 and forms the physical (hence P) page number

Both Alpha and Beta are attached to the full 16 bit data bus.

Alpha is also responsible for generating the system /RESET and /HALT signals. System reset generation will operate the same as with MAXI09, whereby the /RESET (and /HALT) are held low when the FPGA tristates it’s output pins during the configuration. After configuration the pin will be pulled high by the FPGA. There may actually be a problem with this: the 68000 can also drive /RESET low when it runs the RESET instruction. Without circuit changes this will cause contention; something to address before moving on to drawing up the PCB.

Note that Beta is attached to all 16 bits of the MPU’s data bus. To perform 8 bit accesses from (or to) the MPU it has access to the /UDS and /LDS signals. It remains possible, at least initially, that only 16 bit access will be supported to simplify the logic. Access to the local memory (for video and sound data) is also 8 or 16 bits wide. 5 bits of MPU address space is available for Beta; ie. 64 bytes of registers. Hopefully this is sufficient to implement all needed functionality

The section specifically related to video is pretty trivial and includes the two IS61C5128AL 512K x 8 12nS SRAMs, the 4 bit wide RGB DACs, and the SVGA D-Sub connector itself.

The DAC’s resistor values remain up in the air. Looking at the IO Board VGA output, it seems evident that a white image is not as white as it probably should be, even with the screen’s controls turned all the way up. This will no doubt be down to the complete lack of tuning I did when picking the resistor values.

Next, the SIMM slot. This has been discussed previously, and very few changes have been made since the initial schematic was drawn up. The only change is the multiplexer address inputs are now spread, in sequence, across all 22 bits of address. In other words the row and column DRAM address is interleaved from the input address, instead of splitting it at half the expected DRAM address width. This is possible, and makes things simpler when supporting larger SIMMs, because the address mapping (MPU address to DRAM address) used is immaterial.

The expansion connector is straightforward. Once again simple PCB headers will be used. I did think about using something more robust, like an edge connector, but PCB headers are cheap and well suited to board stacking.

I also considered using bus drivers to isolate expansion boards from the MPU’s buses, but looking at schematics for Amiga computers did not seem to indicate it as being necessary. Plus I expect the expansion connector will only be used for occasional breadboard experimentation, or perhaps it wont be used at all, which was the case for the MAXI09’s expansion connector.

For completeness, the power supply and decoupling section. Once again an SR05S05 (PDF) potted switching regulator will be used to provide 5V to the system. Unlike the MAXI09 board, there is not a reasonable quantity of analogue ICs or transistor amplifiers on the board, but the reference voltage for the audio DACs are isolated behind a ferrite bead and separately decoupled, which should hopefully improve the audio signal quality.

Though I have not yet finalised the schematic, I have begun looking at just how difficult laying out the PCB is going to be. I immediately found one problem: I initially ordered the IS61C5128AL 512KB SRAMs in TSOP-II packaging. This packaging uses 0.8mm spaced leads, and leaves no room to run 6mil wide traces between the leads. This presents a massive headache when the ICs need to be “tiled” with two of the same part having almost the same connections, which is often the case with memory ICs. The solution to this problem is to use the slightly larger SOJ packaged version of this part, which does have room for running traces between the leads, SOJ being a kind of hybrid between PLCC and DIP.

The other thing to do is gather up the needed parts. To do this I will first use KiCAD to generate a Bill of Materials. I can then collect up all the needed components, and figure out which ones I need to order, and from where…