Home   Geek   Fotos   Hardware   Download   Order   Mail us 
I love Vim! 
AX MP3 player (pronounced as the 'Accumulator')

Smallest prototype What is the Accumulator? Well... the accumulator is the one register on an Intel 80x86 based platform used for multiplication, division and much more arithmetic, logic and data transfer operations.

But what has it to do with playing MP3? Haha... since we've lost our minds somehow somewhere, we've build an MP3 player using 100% intel 80186 assembler. With a few changes it even runs on the old XT (808[68]). We've succeeded in developing our own MFS (media file system) which is able to map up to 160 Gb, which makes it possible to store LOOOTTSS of MP3 files. It's somehow a gatherer of information, a gatherer of music... an Accumulator!

All software is written using A86 and debugged using D86 and TRACE. It has been build and tested on standard Intel Pentium platforms (which are mostly 80x86 backwards compatible). Afterwards it has been ported to the Beck SC12 processor* (i.e. extended with multi-tasking calls).

Click here to see the Accumulator boot into our test GUI.

* The Beck SC12 is an AMD 80186 processor running at 20 Mhz.

The SC12 is delivered with the following build-in software:
  • Ethernet driver
  • TCP/IP stack
  • Multi-tasking layer
  • DOS extension
  • BIOS

The software we wrote consists of the following low-level drivers:
  • IDE driver (harddisk)
  • LCD driver (display)
  • IR driver (infrared)
  • PM driver (power management)
  • MP3 driver

On top of the low-level drivers we wrote these drivers and libraries:
  • MFS driver (media file system)
    • PSS (playlist sub system)
  • GUI library (graphic user interface; yes we're wasting our time)

And then the above is bound together by:
  • FTPD (file transfer protocol daemon)
  • SPCD (shoutcast pre-capture daemon)
  • MP3 player (the main program)

All prototypes

2.5\ Somehow it feels like wasting my time... We developed MFS. MFS is able of mapping up to 160 Gb, is fully crash proof using a journalling and locking implementation. It uses a block size of 16K, 32K or 64K which is specially usefull with (big) media files. It's specialy optimized for use on 8-bit (slow) platforms.

Move one step closer to insanity and you start building an object orientated GUI class using assembler. You mean like you can build your program using panels, buttons, slider and listviews like in Windows? Yes just like in C++, just register all your objects, position them (if you don't want to auto-position) and then redraw the top.

But calculating and drawing all these objects takes lots and lots of time right? Well, it sure will take more time than just poking a few lines and texts to the LCD. But using this GUI system makes building and changing programs way more fun and prevents from creating bugs.

Since we've created everything in assembler we've the ability to make functions change their own code. For instance; we'd have to implement a 'draw horizontal line' function in C. The function takes 4 parameters; x, y, length, mode. The mode argument can be SET, NOT and CLEAR. Logic function are resp. OR, XOR and AND. Two ways to solve this problem; Lines and Circles
  1. calculate start address, make a loop, then a big if/then/elseif/else/endif, the 'if' will then be executed length time. Waste of your valueable processor power.

  2. calculate start address, make an if/then/elseif/else/endif, make 3 loops in every part of the 'if'. Your code gets less bug-proof, since you might solve a bug in one of the 'if' parts and leave it (by mistake) in an other part of the 'if'.

    3. Now we'd to implement this function in assembler so we decided to go for option 3.
  3. Make one function with one loop and no 'if' inside the loop, then change the instruction inside the loop to whatever was selected by mode. The code gets real efficient. Then moving a little closer to sick assembler coding, why not removing the 'if' part, which translated the 'mode' into the corresponding instruction, then just poke the 'mode' variable right in place of the instruction to be changed. Then change the mode definitions into the correpsonding instruction numbers. WOW it's efficient! Once the code workes, it's put away in an include and no one will ever know the truth.
BTW. It's very funny to see someone debugging your code not knowing it's not a bug the code changing while running :-)

; play mp3 data
mov ah,04
mov cx,MP3_BUFFER_SIZE
mov si,offset mp3_buffer
int 0D3
Q: Why use the Beck SC12 and not a faster and better ethernet enabled micro processor?
A: I always loved to code Intel 8086 assembler. ;-)



Development Environment
Development Environment


© 2003 by Lourens Rozema