AX MP3 player (pronounced as the 'Accumulator')
|
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)
|
|
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;
-
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.
-
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'.
Now we'd to implement this function in assembler so we decided to go for option 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
|