Before getting to the MAXI000, a brief discussion on some unrelated things.

First up, I’ve finally bought an oscilloscope, specifically a Rigol  DS1054Z. This is a fairly low end 50Mhz DSO (Digital Storage Oscilloscope), which should nonetheless be perfectly adequate for my needs for the foreseeable future. One nice feature: it has four inputs. I must admit that a lot of its functionality is over my head. Interestingly it attaches to a network, though I have yet to play with this.

It’s eyeopening looking at digital signals with a scope! As an illustration to the use of such a tool in building digital systems such as computers, here is a look at the MINI000’s 16 MHz clock signal:

It’s quite far from looking like a perfect square wave! I expected this to be much more defined. The generator of this signal is the QX8 Series (PDF) 16 MHz can oscillator, which is in HCMOS.

Here is the /READ signal:

This signal is generated by the EPM7128S (PDF) CPLD. It’s far more square, though you can clearly see the swing, especially on the 0V side. Interestingly this part cannot generate the full range of 0V to 5V and is about 2V short of this range. This is within the spec as listed in the datasheet however.

Finally a signal generated by the 68HC000 (PDF) itself, specifically /AS:

Probably the cleanest signal of the three, this one swings across the whole power supply range.

Next up, another tale of probable fake ICs.

I recently purchased two 68010s from good ol’ eBay. The purpose for doing so was to try them out in the MINI000 board. Not that the 68010 is much of an advance on the 68000, but it would be nice to have a play with some of its small improvements over the original 68000.

Here is a photo of the top of both of the ICs:

You can see that the laser engraved markings are exactly the same, but the pin 1 dot is in a different place on each IC. This would never have happened if the parts were made at the same time, as indicate by the part numbers and the date code (1901). Here’s a shot of the bottom of both parts:

You can see more evidence that the plastic bodies were not formed from the same mould, so they were not made from the same batch; they are almost certainly not what they say they are.

Needless to say neither part works in the MINI000 board, when it was fitted with a 8 MHz oscillator. Luckily I didn’t waste too much money on them.

I do still want to get a 68010 for the MINI000. For completeness I’ll source some original 68000s in PLCC as well; it’s about the only variant I don’t yet have. For that and the parts for the MAXI000, I’ll use UTSource.net. I’ve yet to receive with any fake parts there.

I’ve also finally retired my home made EEPROM programmer. It was with some sadness that I’ve bought a “proper” programmer, a XGecu TL866II Plus. I bought mine from eBay for the very reasonable price of £49.99. This programmer supports 15,000 ICs, which is pretty incredible, and comes with adapters for PLCC and SMT parts.

What has previously put me off buying an off-the-shelf programmer is the software. The T86II Plus is no exception: the Windows software is pretty bad, but functional. But what made me want this particular programmer is it has a pretty decent, and maintained, Linux command-line tool called minipro. This means I can integrate flashing the EEPROMs and Flashes with my normal Makefile-based build system.

So, this leads to the MAXI000.

My current ideas are no where near fully thought out, but a rough idea of the specification is as follows:

• Pizza-box style form factor with a separate keyboard
• 68HC000 clocked at 20MHz
  • Optional: 68010 for experimenting with disk based virtual memory
• 1MB SRAM
• 512KB or 1MB Flash memory
• DIMM or SIMM slot for DRAMs
• Core logic provided by an EPF10K (PDF) FPGA:
  • A true MMU:
    • 4KByte pages
    • Page table held in system memory
    • Cache in FPGA RAM
    • Permissioning system supporting at least 256 tasks
  • DMA controller:
    • Bus mastering via 68000 bus arbitration signals
    • Low priority transfers in MPU dead cycles
  • SPI master
• Graphics provided by a second EPF10K:
  • 512KB fast SRAM (16 bit data path):
    • 640×480 in 256 colours
  • 16 bit data path to MPU
  • Can be a target of DMA controller for 40MB/s transfers
  • Hardware accelerated block transfers and memory fills
  • Hardware sprites
• SC16C654 (PDF) Quad UART:
  • 2 channels on RJ45
  • 1 channel on TTL header
  • 1 channel attached to RJ10 keyboard connector

Once again, this is ambitious. I believe it is about the same distance outside of my comfort zone as MAXI09 was when I drew up its feature set though.

I intend to use Surface Mount parts wherever possible. Indeed, this is required by the bigger EFP10K FPGAs which I’ll have to use due to the number of IO pins on the PLCC84 EPF10K10, which is not enough to support an MMU and DMAC. ICs which are not Surface Mount will be in PLCC (but socketted) to save board space. DIPs will be avoided, hopefully entirely, to further reduce the size of the board. This applies especially to the Flash memory. And I’ll be using Flash memory instead of EEPROMs because they are available in bigger sizes – which is necessary if I want to try porting large OSes to the board – and because I now have an off-the-shelf programmer available so I can choose any ROM-style memory without worrying about building my own programmer for it.

In terms of which EPF10K I’ll need, looking at the parts available, the EPF10K20 is probably the one to go for. It’s exactly twice the size of the EPF10K10 in terms of logic elements and memory bits, and has 102 IOs in its smallest package.  The problem is this package it is a 144 pin PQFP – a Quad Flat Pack with a pin pitch of 0.5mm. It is only 20mm along each side. Soldering it will require new skills, and some new tools. But it looks doable, and I have to crack building SMT boards at some time.  Luckily these parts are not yet that expensive – $5.28 vs $11.74 for the EPF10K10 in PLCC84. The configuration flash they require is the same, the EPC2 (PDF) in PLCC20, and fortunately one EPC2 can hold the complete configuration of two EPF10K20s. The configuration of the FPGAs should be identical to the one used on the MAXI09 board.

A rough pin count estimation for the core logic FPGA:

• 1: MPU clock
• 16: Data bus
• 12: Low half of the address bus
• 12: High half of the logical side of the data bus
• 12: High half of the physical side of the data bus
• 5: Asynchronous bus control (Including /DTACK)
• 3: Bus arbitration control
• 3: Interrupt control (IPL0, 1 and 2)
• 3: 6800-style bus control
• 3: System control (FC0, 1 and 2)
• 2: Read and Write
• 5: SIMM DRAM control
• 11: SIMM DRAM address bus latch
• 3: SPI bus
• 2: SPI selects

This totals 93 pins, and does not include any chip selects or peripheral interrupts. Including the SIMM address latch in the FPGA may be a luxury I can’t afford, and I will have to use external latches. The choice of using SIMMs is up in the air at the moment as well. It is possible to use 32bit DIMMs in 16 bit systems without wasting address space, but the logic is more complex. In any case this will need to be prototyped using the MINI000, probably with the 41464 (PDF) DRAMs I’ve previously used with the V9958. Alternatively I do have some SIMM sockets that I could breadboard mount, since the SIMM pins are on 100mil spacing.

And the updated video controller:

• 1: MPU clock
• 1: VGA pixel clock
• 16: MPU Data bus
• 2: MPU Upper and Lower data strobes
• 4: MPU Address bus
• 1: MPU Chip Select
• 2: MPU Read and Write
• 1: MPU Interrupt
• 16: VRAM Data bus
• 2: VRAM Upper and Lower data strobes
• 18: VRAM Address bus (512KB total video memory)
• 2: VRAM Output Enable and Write
• 12: 4 bits of red, green and blue (for 4096 colours)
• 2: Horizontal and vertical sync

This makes 80 pins. It should be possible to move some functionality from the main FPGA to the video FPGA, just to balance the pin requirements. An obvious candidate is the SPI functionality, but moving the SIMM logic and address latch to the VGA FPGA should also be possible, if that will balance the pin requirements better.

Another possibility is to attach the video FPGA to 19 bits of MPU address bus. It would then be possible to access the video memory without going through an address pointer register maintained by the FPGA; random access to the memory would be possible without any overheard of writing to the address pointer register every time a non incremental address needs to be accessed.

It might also be worth looking at programmable oscillators for the VGA controller, as this would let me experiment with, for example, 800×600 resolutions which require a 40MHz pixel clock. These parts are typically programmed via SPI and a suitable example  (in 5V) for the MAXI000 is the DS1077 (PDF).

Outside of the core computer, there are a bunch of other decisions to be made:

• One concern I have, which I’ve never really given much thought to in the past, is weather some of my choices will dissuade other people from building their own MAXI000. Probably the biggest issue is my choice of keyboard, which is unusual for a retro microcomputer, where PS/2 is a far more common choice.
• The computer will need at least one joystick port. It maybe interesting to look at using a PC-style analogue joystick instead of the 9 pin Atari-compatible joysticks I’ve used in the past.
• It might be worth giving some thought to including a mouse port, though I don’t know what the best interface to use is.
• Ethernet would be very nice to have, as while not having it does not prevent me looking at implementing my own TCP/IP stack (via SLIP or perhaps even PPP), having an Ethernet port would be preferred.
• A big question mark hangs over what kind of sound to employ. A must is some kind of digital (sampled) audio, as I’ve not looked at this before. But I’ll probably include some kind of FM synth as well.
• Mass storage is a must. IDE is easy, but it might be worth looking at alternatives.
• I need to give some consideration to power usage.
• Some kind of expansion connector should be included. It’s possible that some of the above peripherals, and possibly the video solution, could be moved to an expansion card.

There are many things to do before starting work on seriously planning the MAXI000. The most important one is to gain experience, and confidence, in soldering up large SMT parts. This will require watching many YouTube videos, buying tools and supplies and, critically, lots and lots of practice.

In parallel to that, the other thing I plan to do over the next few weeks is to improve the VGA implementation in MINI000’s IO board, starting with implementing a 640×480 2 colour bitmap mode…