Project number 2

The year was 2005 and I was a step away from becoming an electronics engineer. There was only one thing missing to finally end my student life: the final project. There were a lot of proposed projects to choose from, but none really caught my attention. Fortunately there was the option to propose your own project, so I came up with something that I thought it would be at the same time useful and really cool to develop: a vnc and rdesktop thin client. When finished it would be a small and simple board where you connect a display, keyboard, mouse and a network cable, then through vnc or remote desktop it would be a remote workstation.

Well, this was the original idea and the proposed project would divide in 3 major tasks:

1. Develop a FPGA based 2D GPU (with dedicated functions for networ display).
2. Build a prototype pcb for the main controller and GPU interface (it would be a mcf5407 with 32Mb SDRAM and 8Mb FLASH).
3. Develop the code for the microcontroller.

So, after brought back to earth by my project coordinator it ended up being just the first part (the 2D GPU). The issue here was time... It was a one man project and it needed to be ready in less than 3-4 months (and it was not a full time job).



One Xilinx Spartan3 (XC3S200) was used to develop the GPU. The spartan3 kit that was available had on board memory to go up to 800x600x16bit and enough I/O to pull out a dedicated parallel bus for the cpu interface.

The Diligent Spartan3 Starter Kit used for the GPU development

So the remaining question was: "What will control the GPU?" For demonstration purposes I could just interface the GPU with a serial port or some cheap 8-bit microcontroller using spi or i2c. But since the initial idea was to connect a coldfire to the gpu that question had a simple answer: "The dusty 68000!" And there I was again... cleaning up all the dust from those breadboards!

The spartan3 kit already had a VGA connector but it was a simple 3-bit 'resistor DAC'... Yuck! So one expansion connector was used to interface a 24-bit DAC and another one for the cpu interface (the pins were enough for a full 16-bit I/O port).

24-bit DAC board: top view.

24-bit DAC board: bottom view

The GPU ended up working pretty nice. It was modular so that the available functions could be included/removed from the top module, depending in purpose of the application was for. And these were the functions I have developed:

• putpixel, getpixel (the most basic functions for anything that display graphics). These functions have several working modes: A window could be defined and then post-increment or pre-decrement pixel manipulation methods could be used to fill the window (among other features).
• clrscr (clears screen, filling with a pre-selected color)
• poly (draws a polygon, points passed as arguments)
• circle (draws a circle, center and radius as parameters)
• text (places text in the display)
• copyrect (copies a rectangle from a place to another).
• save / load. (the remaining on board memory was used for a save and load function).

Alpha blending was also possible. Including all the functions, the synthesis wouldn't fit in the provided XC3S200. Using a 'bigger' FPGA this wouldn't be a problem.

Development (at my parents house during christmas season).

I remember that I had more fun than work during the whole project.
When I had the GPU almost finished I played a lot with the 68k and coded several small programs, things like a simple clock, image loading, mathematic function tracing, a simple 3d wiremaze game and 3D raytracing...

One of the the few pictures I've took during development showing a clock and some text in the upper left corner.

"Faculdade de Engenharia da Universidade do Porto" logo loaded from a .bmp file.

Too bad I didn't had enough time to play with it a bit more (and maybe finish the initial idea).

And this was the last project where my 68000 system was used...

A few months ago and after several years later I decided to play with it that 'spaghetti board' again!

And this is where uClinux comes in...

Project number 1

There I was in the year of 2002. The music was spreading all over the place in the form of digitally compressed bits and portable CD players were starting to be a thing from the past. Standalone MP3 players were already in the market, but the cost was very high and their capacity was very small. The very first mp3 player only had 32 Mb to store music. That's about the same an audio CD can handle...

Googling around I've stumbled in a forum where some people were posting about their mp3 player projects. Some guys were just stiffing a whole PC in some custom made enclosure to have in the living room, others would even attach an alphanumeric lcd to the printer port so they could have a sort of visual interface.
What caught my attention were the projects were you could use these hard-to-get-mp3-decoder-chips.

So that's when I decided: "I'll build a standalone MP3 player!"


At that time I remember only having two options as decoder chips: Micronas MAS3507D or VLSI Solution VS1001K and independently of which one I choose I wouldn't find one in a 2000 Km radius...

Suddenly I had 4 quests in my life:

1. Get my hands on one of these mp3 decoder chips.
2. Build a board with the mp3 chip + audio DAC.
3. Feed the mp3 decoder board with some music (and enjoy the beautiful sound).
4. Build some controller board with some heavy mass storage (I really mean heavy when I say it! the main goal was to use a laptop IDE hard disk but all I had back then was a heavy 3.5'' hard disk).

Quest number one turned out to be easy. I was living with a cousin at that time (we both were studying electronics engineering out of hometown) and he was dating a girl that had her father in Germany near a local shop where they actually had the mas3507d. Great! Her dad bought us 2 Micronas chips and sent by mail (and also 2 Micronas audio DACs). (My cousin also ended up joining the mp3 player adventure, which without him I would stuck in the first quest for some time!).


While waiting for the package to arrive, I started quest number two.
The MAS3507D datasheet had this reference design, so I took it, ripped of some unneeded stuff (like auxiliary audio inputs) and used it in my board. The scary thing was that the chips were SMD. Developing a home-made pcb for smd was something I had never done, but after about 3 or 4 tries I was able to etch an almost perfect double sided PCB using UV sensitive boards.

Soldered all the components and the there I was, with a perfect mp3 decoder board that was just missing the... mp3 decoder! The chips arrived some days after, soldered them and I was ready to provide my ears with some music.

The finished mp3decoder board! Left is MAS3507D, right is DAC3550; Top connectors: I2C, SPI, Power supply; Right connectors: Lineout and Speaker out.

Quest number three was about to start: feed the beast!
The beautiful thing of this decoder board was the simplicity to make it work.
The board is fed with the mp3 bitstream in a 'crippled' 2 wire SPI interface (mosi, clk) and a "i'm busy" signal telling that the chip buffer is full. The output are two stereo connectors: line out and speaker out.

To test the board all I has to do was connect the 3 wires to a computer parallel port and code a simple program that grabbed an mp3 and bit-streamed it in the parallel port.
And... well, I can say that it did work! A sort of something that I can call half-second music, half-second silence was flowing in the air.
What was happening was the mp3 that I selected to be the One, had a high bitrate encoding and the computer plus the parallel port couldn't handle the job. Maybe if I did some assembly coding it would play higher bitrate mp3s but that was not the point. I just simply searched eMule for a small and low bitrate mp3 and tested it. Funny that the first hit was the theme song from a Portuguese TV show named "Batatoon". And there it was, playing perfectly in the mp3 decoder board (as perfect as it could get with only 96kbps bitrate)!

The board also has a second connector for an I2C interface. It allows to control internal registers of the mas3507 like volume, treble, bass, balance, ... (and really needed in a latter chip revision to start the decoder! I know this because after some days a badly connected power supply destroyed the first mas3507 and when using the second one (and I'm glad I had a second one!), the music was gone! so after reading through the datasheet and setting a specific bit in some register, the board was back to life).

Having a working mp3 decoder board, all that was left was the last quest: Have a full working system with space to store a bunch of music.

This is where the 68000 comes in. I grabbed my 68000 system, cleaned all the dustin it and attached an IDE harddisk.
I think I've aged about 2 years just for cutting the 40 pin IDE cable and connecting each signal to the 68000 bus (in breadboards). One word: tedious!


 "Let the coding start"!

For who never programmed 68k assembly this can sound weird, but the truth is that it is pleasure to code those lines! The instruction set is so vast and there are a lot of addressing modes!
And so I've codded the IDE driver, partition and FAT32 reader. I could soon play some tunes!

When it came to the part of connecting the mp3 decoder board, problems appeared! How the hell am I going to send the bitstream?


Ideia number 1: Serialize the bitstream in software and send it bit by bit through some sort of parallel port (and I've wired a simple 8-bit latch). 
Result: The 68k running at 8MHz didn't have horsepower to do the IDE access and send bit by bit clock by clock the bitstream. And to make things worst I wasn't using any kind of interrupts, so the bigger the buffer was, the longer the pauses were.
This is understandable because the cpu is not intended to do SPI with its 16-bit wide databus! 
> FAIL <


Ideia number 2: Use the same setup but using the 'busy' pin from the mas3507d to interrupt the CPU for data.
Result: It worked... better, but not good! The main loop would just fill in the buffer while the interrupt routine dumped it to the mp3 board. It was almost smooth playing, but time to time I could hear the music stop. High bitrate mp3 (320kbps) still didn't play...
> FAIL <

Idea number 3: Send 1 or more bytes of data to 'something' that could serialize it and then send to the mp3 decoder.
Result: The 'something' was the big question mark. It could be a 8-bit shift register, clocked at some frequency, being fed by the 68k with some glue logic. But I wanted something that I had at that time in my junkyard, so I picked this little PIC16F84A and thought "this thing has enough pins for a 68k 8-bit data transfer plus 2 for spi and its fast enough to serialize the data!".
The connection was pretty simple: one pic interrupt pin for a write signal from the 68k, the 'busy' signal was directly connected to the 68k to request data and pic port B was used to receive the data from the 68k.
At that time I thought in wire up two 8-bit shift registers and have a 16-bit serial shifter (or use a PIC with more pins). Sending 16-bit at time would reduce in half the effort needed by the cpu to feed the data, but...
> SUCCESS <

But the full working system was already a monster (in size)... It was working good but it was way far from a portable mp3 player.

After some time playing around with this thing I had shifted away from my main goal so I decided to go back on track.
The main goal was to have a portable mp3 player and from what I had at that moment was failing in some important aspects: It was huge it was heavy and it was consuming lots of amp's!
Trying to figure a way to solve all of these issues I came up with some ideas:

1. Get rid of the 68000 - Ended up using a 40pin PIC18F452. It had lots of IOs and I2C and SPI port.
2. Get rid of the 3.5'' IDE harddisk - These disks need two power supplies: +12V and +5V. Final goal was to use a laptop harddisk that only require +5V. The interface is the same so when the time comes I could simple switch disks.
3. Make everything smaller - The prototype mp3decoder board ended up being bigger than expected (well, its a prototype!).
4. Add a display and some buttons!

So the ultimate goal was making a small board with the max size of a laptop harddisk.

And then I stated to develop the prototype board for the PIC18F455. The final board had the following specifications:

• PIC18F452 as main controller.
• 32Kb SRAM as buffer.
• 64Kb serial eeprom for settings and other stuff.
• RS232 port for firmware upgrade/development.
• LCD port (ended up using a 4x20 alphanumeric LCD)
• Infrared port (used an universal IR remote as controller, so there were only two push-buttons: reset and bootloader entry).
• 40 Pin Parallel ATA (IDE port)
• 8 bit expansion port.
• SPI and I2C connectors (to mp3decoder board) 
• IR led, harddisk led

Controller board prototype. Top connectors are: Power supply, power supply to mp3decoder board, SPI, I2C, RS232. Bottom left connectors are: expansion port, lcd connector and the IDE connector. (MAX232 is M.I.A.!)

I coded everything up in C (IDE driver, FAT32 access functions, LCD driver and IR driver).
When I had the code practically finished, I placed everything in 'small' acrylic box.



That box was part of my car about 2 years in a row! At that time the first car mp3 CD players were becoming cheap, but why would one carry a bunch of CD's when all would fit in a single harddisk? It was something that caught attention and the remote control was something I really loved in it.

The good points were: huge capacity, fast and easy user interface (custom made!) and a sweet universal remote control.

There were also disadvantages, starting by the fact that when I needed to add music I had to connect the harddisk to the computer. The initial idea was to use that expansion port to to the transfer interface (possibly using the parallel port), but that never got completed.

In summary, the final board never got made... And I gave up also because flash memory prices were dropping fast, while available memory capacities were rising faster.
A few years later the mp3 players industry exploded! I ended up buying a car radio with a USB connector where I could just plug anything with mass storage...

The full system connected. Almost 10 years later I've connected the player.

The systen boots, initializes the hard disk, LCD and MAS3507D but then it gets stuck in the "Loading settings"... I guess the serial eeprom is no more! What is also no more is the source code... where the hell did I store it?

In the next post I'll talk about the other real big project where the 68000 was the king!