Sound and video; more MAXI000 bring-up

      No Comments on Sound and video; more MAXI000 bring-up

The build of the MAXI000 board continues.

The first job was to finish the quad UART construction. The RJ45 and RJ10 sockets and the MAX238 (PDF) with its associated tantalum capacitors were all attached without any difficulty.

After fixing a dodgy joint, caused by there being not enough paste on a corner pin on the MAX238: success. The bootloader was modified to use port B for flashing, with the monitor on port A. The baud rate remains 9600, at least for now.

The keyboard connection, on port D, was also tested, but at this point it was not used to control the monitor.

The original plan was to start on the video portion next, attaching the video SRAM (IS61C5128AL (PDF)) and resistor ladder DAC. But because this was a fairly daunting task, I tackled the relatively simple DS3234 (PDF) Real Time Clock first.

This is only two parts, ignoring a decoupling capacitor: the IC and a CR1225 battery holder. After soldering the parts it was a fairly trivial job to cut and paste the SPI controller, originally written for DISCo in the MAXI09 board, into the Beta VHDL project for this board. To keep things tidy the SPI controller, including the decoder to select the needed peripheral IC, is in a separate source file. Simulations have not yet been written.

Here is a capture from the logic analyzer showing a read of 3 bytes, which are the seconds, minutes and hours from the clock:

No proper software has been written at this point. All that exists is a monitor command for exercising the SPI controller which dumps read back data into memory.

And here’s a picture of the board as it was after the RTC had been attached:

The RTC and battery holder are at the bottom right of the board. The breadboard was used for prototyping the video resistor ladder DAC, though I ended up not using the results obtained.

The point of the prototype was to improve on the performance of the DAC on the MINI000 IO board, which produced somewhat muted colours on both the cheap LCD TV, which happens to have an SVGA input, and a Dell monitor.

I hadn’t properly realised three things when picking 1K resistors for each and every resistor in the DAC:

  1. The circuit is properly called a R2R ladder DAC because the resistors which are on the input side have a value of twice the bridging resistors. Ignoring this results in a non linear relationship between input value and output voltage.
  2. The values chosen should factor in the 75 Ohm input impedance within the monitor.
  3. The maximum intensity is meant to be at 0.7V on the red, green and blue pins.

Here’s the output as captured from the ‘scope with the first point addressed. The resistor values are 1K and 2.2K:

This uses the 3 pins on Alpha which are routed to the expansion header, which is exactly the number needed for a single DAC channel. A simple counter is employed. As you can see its nice step up, but the problem is the maximum voltage: over 3V and no where near the 0.7V needed. However the main contributor to this is the fact that no load was attached to ground.

In the end I bypassed a physical simulation and used an online tool at circuitlab.com. This tool can be used to input a schematic inside a browser which can then be analysed, trivial as it is in this case, to calculate the voltage and current at particular points in the circuit:

The point being inspected is the far end of R7, relative to ground. This shows a calculated voltage of 0.77V, about perfect.

In fairness I think I could have have done the needed maths, but I was feeling lazy.

The 3.6V value on the inputs is a logic 1, which the EPF10K20 will generate on the red, green and blue pins, and was determined experimentally with the multimeter. The values chosen were the best ones available in my set of 1206 resistors.

In any case before getting to the DAC and SVGA connector I had to first solder up the PCM DACs, a pair of MCP4902 (PDF), and associated parts. These were “in the way” and if the SVGA connector was soldered first it risked getting damaged when nearby parts were reflowed. Initially I got no joy at all from the DACs but after tweaking the SPI controller in Beta it came to life. Unfortunately the DS3234 RTC then stopped working. It seems further tweaking is necessary if the SPI controller is to be able to control both peripheral ICs. In conclusion this controller is crying out for a decent test bench.

In any case I’m pretty pleased that both left and right sound channels work. As per my previous prototyping only the MPU writing PCM data directly has been tested, but in principle driving the DAC with data held in the locally attached SRAM via a local DMA channel should be possible, which will be an interesting exercise for a future day.

Finally then, attaching the video SRAM, building the video DAC and attaching the DB15 connector.

Attaching the video SRAM, with its SOJ pins, went well. Once again I used the reflowed solder paste method. There was one problem with an open circuit on a pin, but I fixed it by inserting a blob of paste under the pin and reflowing it. This was only after I failed to fix the problem with the iron, and it turns out reflowing a dot of paste is a better method for fixing that type of problem which I wish I’d found out about earlier.

The resistor DAC was fiddly work as it uses 18 resistors. It was going well with reflowed solder until the last few resistors when a couple flew off the board. They were reattached with the iron:

R20 and R25 look to be a bit out of alignment. If I get the inclination I will realign them. The board also needs a good clean with some IPA or similar.

In any case I was amazed that getting the console working on MAXI000 took very little time, and the picture looks quite a bit better then on the MINI000 plus IO board combination:

The VHDL (and 68000 code) is certainly a bit hacky, but it works!

In comparison to the previous board, access to the video memory is now 16 bits wide. This is also the width of the databus attaching Beta to the MPU.

To keep the VHDL design simple, at least initially, reads and writes to the video memory through Beta are mandated to be 16 bits wide. This means extra logic using /UDS and /LDS is not needed. Also only 16 bits of video addressing is used currently, again to simplify the logic and 68000 code. This means out of the 1MB of memory wired, only 64KB is usable. As only text mode has so far been implemented this is not a big problem.

The use of 16 bit wide access to the video memory simplifies the 68000 code as well, since the character in a character square and its attribute can be set with a single word-wide write.

One little optimisation to the VHDL remains possible: reading the video memory as part of the display process is currently done a byte at a time, ie. the character index and attribute are read alternately from each SRAM IC instead of being read at the same time.  Correcting this will simplify the state machine which controls the memory reading, and reduce contention between the MPU wanting to read and write to the memory and the display generator wanting to read it.

All in all I’m pleased with the state of the MAXI000 board, and I’ve not even finished the physical construction:

The next big test will be the 72 pin SIMM slot which I will probably attach next. But even if I can’t get that to operate properly I can still consider the board to be a success.

There are many, many, possibilities for projects with this board. I have not yet even given a thought to writing a DMA controller or MMU in Alpha. And of course there is scope for more interesting video modes to be implemented in Beta, and of course there are the PS/2 ports. Then there are less exciting things, like interrupts.

One thing I’m mindful of is resource usage. The EPF10K20 (PDF) are not a huge FPGAs by modern standards. I will have to be particularly adroit to make everything fit. As a data-point Beta, with its text video display controller, single PS/2 port and SPI, controller is currently at around 60% logic resource usage (and 50% SRAM bit usage, for the font data). However I have made no attempt to minimise resource usage and, reading about it, there are plenty of techniques available.

And of course there is software. Porting MAXI09OS to the 68K is an obvious choice, though this time I plan to write as much as possible of it in C. But before getting to that I thought it would be satisfying to look at porting an existing, mature, OS.

A good candidate is EmuTOS. It’s a reimplementation of TOS, the Atari ST operating system. It’s pretty crude compared to AmigaOS but has been ported to the 68008 based Kiwi board. The Kiwi uses a V9990 video controller, which is the last in the series which started at the TMS9918 and includes the V9958 used by MAXI09. This video controller operates in a similar way to Beta with video memory directly attached to the controller instead of having video memory combined with system memory. The only thing missing, which I think will be needed, is a four colour bitmap mode.

This is jumping ahead somewhat. I should probably complete the hardware build before seriously thinking about software…

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.