If you're not familiar with MP3's, here's a good
place to start.
The release of the MAS3507D chip, from Micronas
Intermetall, has caused something of a stir in the MP3 world. This
chip handles pretty much all the nasty side of decoding MP3 audio. You simply
clock a serial MP3 bitstream in one side, and digital audio gets clocked out
of the other side. I'm currently trying to interface this chip to an IDE drive, to create a car-based
MP3 player capable of storing hundreds of CD's, and delivering high
quality 16-bit audio at the touch of a button. I've started making a log
of my efforts, in the hope that they'll be of interest and/or use to anyone
attempting a similar experiment.
19th July 2001
First off - a big apology to those of you who have been having difficulty
getting the infra-red remotes to work. It turns out that there is in fact
a flaw in the RevB firmware that prevents the PIC from detecting infra-red
signals when it's talking to the PC. Unfortunately this means that the PC
training programs can't initialise the HD IR translation table, and so,
when the player is running in normal mode, although it's decoding the IR
correctly, it doesn't understand the commands.
The reason I didn't find this sooner is that although I have a RevB box
running the latest firmware, I don't use the IR with that particular box.
I have another box with older hardware that runs my original firmware,
which works perfectly with the IR. Somewhere in the merging of my code,
Mike's code, and Leandro's code, the timer-interrupt (which is where all
the IR decoding takes place) got broken.
Anyway, the good news - it's a simple fix. Download and burn the new
If you've been using boot.exe to flash your firmware, you can go ahead
and use the same program to perform this update.
Hopefully, you should now be able to train your players using Winskel
or (shudder) mp3down.
14th July 2001
I just got an email from a company selling MAS3507D and DAC3550A's in small
quantities for less than $30. Since I get so many emails asking about where
to purchase MAS/DAC chips, I figured this would be of interest!
5th July 2001
Just a quick firmware update from Mike Weston: v1.2.2 provides
an easier EQU directive for selecting between 15-bit and 12-bit SIRCS
remotes. The code now does a software reset of all IDE devices, not
13th June 2001
From Greg Wood:
Here is a thru-hole hole PCB designed by
for MP3public rev. B. It uses a slightly different schematic than
MP3public. Anyone with enough electronics experience to build and
UNDERSTAND the MP3public rev B schematic should have no trouble
understanding this one. There is a readme file included for further
3rd May 2001
New firmware - now there's a #define option in the code to allow
continuous play. In the past, the default behaviour when reaching
the end of the last song on a CD was to jump back to the first track on
the same CD. Now, the CONTINUOUS_PLAY (see boot.asm) option will
cause the player to move on to the next CD. Thus, the player will cycle
through all the music on the drive. Version 1.2.1!
29th April 2001
Another firmware update from Mike Weston. Get it here!
27th March 2001
17th March 2001
Another util - mp3chk.exe is a standalone integrity
checker for the mp3 player. You can use this to initialise the player before
use for the first time. Make sure the win95.dll file is in the same
14th March 2001
Fixed a bug in the downloader (MP3DOWN.EXE), that would cause a
hang on certain corrupt mp3 files. New version is here.
Note that you still need WIN95.DLD in the correct directory. Also,
if it fails to connect to the player the first time you run it, you may
need to select the driver again. By the way, something I forgot to mention:
This will NOT run under NT. I haven't tested it under ME or 2000 - but it
should definately be OK under Win98 or Win95.
7th March 2001
Michael Weston has been busy! He's taken the PIC code and schematics for
my player, and merged them with Leandro Gentili's CD code, to produce
a player that supports both hard drives and CD-ROM drives. As if this weren't
enough, he's produced schematics and a board layout for the new player.
(If you're planning on building your own player, and have looked at Leandro's
schematics, or my code, it's important to note that the IDE_WR and IDE_RD
outputs from the 74138 may have changed position. Remember to double-check
The hardware information is here, and the first
version of the firmware (1.1.0) is here. Mike is
also working on some additions to the firmware (eg. random shuffle), so
expect updates to occur!
3rd February 2001
The first release of information regarding the player is
There are several pieces that are missing, but in theory, everything
you really need is there. I hope to add more information to this at
some point, but you'll have to be patient! Make sure to read the README.TXT.
30th January 2001
Good news - I just received permission from John to release the schematics
and source code. It's going to take me a little while to get everything
in a suitable format for publication - but hopefully it shouldn't be
too long now. Bear in mind, though, this is a fairly complex project, and
I don't have time to assist with construction problems, so you
should have a fair degree of electronics experience in order to
undertake this project!
31st October 2000 - ooh spooky
It seems that everyone is looking for information on interfacing
microcontrollers to hard drives. This finally prompted me to get off my
ass and relocate a copy of this, which is
the ATA/IDE interface spec that I used when building the MP3 player.
This document assumes a degree of knowledge about busses, and the like, so
unless you have a fair understanding of this kind of stuff, it's probably
not going to help too much. On the other hand, if you have experience
with this sort of thing, it's indispensable.
A request... PLEASE don't email me with questions about the contents
of this document. Much as I'd like to help, I just don't have the
23rd August 2000
Well, to be honest, I'm not sure what the future of the player is. John,
the guy who has been building the units has moved onto other things, and
it looks unlikely that we'll be making more units. Although it's a shame,
realistically, it's difficult for a small company to sell a product like
this at a decent margin. Thanks for all the interest and enquiries though.
I'm currently talking to John about open-sourcing the schematics/code
for the player... we shall see what happens.
7th June 2000
For those of you who are looking for IMBDEV.COM, with a view to purchasing
MAS/DAC components, you can email John
Levstek, who, despite having changed jobs and moved several thousand
miles, is still selling chips. At present, he can only supply MAS-D8/F10's,
DACs and crystals.
4th December 1999
Not much new to report - work on the newer, groovier Windows software
continues. There's some info about the player at:
13th November 1999
One of the new units just arrived in the post, so I've taken a few more
pictures, this time with the top off to hopefully satisfy all you tech
junkies. The MAS and DAC are the SMT chips on the right hand side of the
middle picture... all the PIC circuitry is under the hard drive. I haven't
ventured under there yet, since I don't have the right screwdriver, and
I don't want to risk breaking anything.
I didn't have anything to do with the actual board layout, so this is
a really pleasant surprise... other than a few phone conversations describing
the size of the box, I didn't really know what to expect. I'm really pleased
with the end result though - the folks at imbdev.com
have done a fabulous job.
Here's another quick snapshot with a CD for size comparison.
30th October 1999
Apologies for the scarcity of updates recently! The next version of the player
is being built at the moment - this is pretty much what will be on sale in
the near future. I'll post some more details relating to price/ordering
sometime soon, but in the meantime, here are some snapshots of the new unit.
As you can see, it compares favourably in size to both pencils AND
coins. Whoo hoo!
It will be a short while before these units are available - we're still
waiting on the final boards, so current units are being assembled by hand.
The PC software is still under development too, but hopefully all these
things should come together in one glorious union before too long!
In the meantime, please don't send me emails requesting price/ordering
information - rest assured I will post the information here as soon
as it becomes available.
6th August 1999
Only had time to take one picture before the batteries in my digital
camera gave up...
As you can see, the box is fairly sizeable. There's a load of empty
space though, and subsequent revisions will be much smaller. There's
a headphone socket on the side, and some line outs at the back, as well as
the 25-pin standard parallel port connector. On the front panel (ultimately
removeable, we hope) live the LCD display, buttons, infra-red receiver, and
some kind of hole, the purpose of which I'm not sure - the hardware guys
haven't told me.
5th August 1999
Just got back from a couple of weeks vacation back home in the UK. While
I was away, the hardware chaps managed to get the first prototype version
working, and shipped it to me. I'll be taking pictures and posting them
really soon, but right now I have some heavy jet lag to deal with. I just
wanted to post this in order to let people know that the project is still
going - I've received a lot of emails enquiring about the state of the
player... Well, watch this space...
24th June 1999
Things have been a bit quiet here of late, for which I apologise... however,
there's a good reason for this - I'm currently collaborating with a company to
produce a consumer version of the player. Although there are still details
to work out, testing to be done, etc... etc... progress has been good, and
hopefully something should be available in the very near future. More details
as they arrive.
On the technical side, just did another stress test - playing back a high
quality variable bitrate encoded MP3, with clusters alternating between the start
and end of the drive. This means that every cluster fetch also entails a FAT
sector fetch, and (probably) the maximum possible seek distance between
clusters. As I type this, I'm listening to smooth, glitch-free audio, so it's
clearly coping ok. I'm thinking of repeating the test, but with me striking
the hard drive with a hammer, just to see how well it does :) Also fixed a minor bug
which sometimes caused rewinding to jump straight to the start of the track.
Nothing fatal, but a bit annoying - still, it's working fine now.
10th June 1999
Yay! The I2C treble/bass controls are up and running. Seems that the MAS
likes to extend the I2C cycle by holding the clock low at various points
during the transfer. In rather paranoid fashion, I've put clock checking
code at every point in the code where I lower the clock. Seems to
have fixed the problems I was experiencing. I put some error checking code
in too, which can't hurt.
6th June 1999
Been away for a short while, but came back today and realised the EPP mode
wasn't working. Fixed it. Something odd is going on with the treble and
bass controls, but hopefully I'll crack it before too long. Did a quick
"stress test", where I wrote a track onto the hard drive using completely
random sector allocation. This means that the drive has to seek all over
the place during playback, not to mention fetching FAT sectors a lot more
often. Fortunately, the drive didn't miss a beat. No skipping or anything.
2nd June 1999 - later...
I2C is working. At least, I have the I2C write function implemented, and a
crude test to set the DAC volume is working just fine. The volume/treble/bass
aren't hooked up to the user-interface yet, but that shouldn't take up too
much time. The I2C runs as part of the idle loop, and processes a byte at a
time, just to make sure that the MAS doesn't get ignored for too long.
At present, the only thing in this whole project that uses interrupts is the infra-red, which runs
off a 1024-cycle timer interrupt. The reason for this is that it has to be
polled at a fixed frequency, in order to measure pulse widths. Hopefully the
lack of dependancy on chip-specific features will make it nice and portable.
2nd June 1999
Yikes... where did all my free program memory go?! User-interface, that's
where. Writing a user-interface (no matter how simple) in 16C64 assembly is
about as much fun as digging one's own grave with a spoon. I'm down to
just under 400 words, and still need to put the I2C code in. Pretty sure it'll
fit without having to make any major changes, but it's going to be tighter
than I expected. (Let's not forget that the poor PIC is doing all the IDE
transfers, streaming data to the MAS, decoding Infra-Red, and updating the LCD
all at the same time, all in 2K!).
28th May 1999
The MAS eval board from IMBDEV arrived
today... I rushed home to hook everything up, and after a few false starts
(couple of stupid mistakes on my part), I was greeted by the sound of Alanis
Morissette whining (as she usually does) about former boyfriends. Never before
has it sounded so good!
Yes, it works.
After a couple of months of writing PIC code based purely on datasheet
specs, it's enormously satisfying to finally hear the auditory products of
one's labours. I still have a bunch of things to fix, and need to finish off
the user-interface code, but I now know that the core code works, (and has
a lot of CPU time to spare by the looks of things!).
It's not often that you'll hear an Englishman whoop, but I'm very
happy :) So happy, in fact, that I took a photo. You'll notice that the
parallel port is hooked up to the PC, because I was testing the IMBDEV
board, but if you look closely, you'll see the actual jumpers connecting
the MAS header pins to the tangle of wires that comprise the player.
25th May 1999
Just been messing with EPP stuff. Some subtle rearranging of the code means
that I can now use either SPP or EPP mode with the same cable. The PIC code
needs to be much more optimised, but EPP mode gives download rates of about
230KB/sec. With some further optimisation, I estimate that at least 300KB/sec
is attainable. Yes, I know EPP can go much faster than this, but don't
forget that the PIC handshaking is all in software. As things stand,
Supposed Former Infatuation Junkie, a veritable behemoth of
a CD at 69MB, transfers in its entirety, in about 5 minutes. (Bear in mind that
this is nearly twice as long as some other CDs).
If only Scenix had their new chips out, things would be so much cooler...
22nd May 1999
Saw Star Wars at Mann's Chinese Theatre in Hollywood last night... Better
than I was expecting it to be, I have to admit!
The PIC is now talking to the LCD. Still no user-interface per se, but I
have an area of the SRAM set aside as a kind of "display buffer", which the
PIC continually sends to the LCD when idle. I'm using a 16x2 LCD display,
because it's nice and small, and I want the whole contraption to fit into
a fairly small space, but I hope to support a few different LCD sizes.
So, all that remains is to ensure the MAS serial interface works (which it
should do!), write the I2C code, and the user-interface (which I'm dreading).
21st May 1999
Did some testing of the Win95 front-end, fixed some bugs. Downloads work
just fine, with a 4MB song taking around 30 seconds. Also started playing
around with the LCD modules - hooked one up to the PC parallel port and got
it to display stuff, so I can now start writing PIC code. Whoo hoo! Fixed
a nasty, unpredictable PIC stack-overflow bug. Of course, it's much easier
to find these bugs when you have an emulator!
As far as the user-interface goes, as previously mentioned, I'm going for
a cheap/functional approach. It'll probably be along the lines of a standard
CD multichanger for now - standard Disc+, Disc-, Track+, Track-, as well
as FFWD/RWND, Volume and Tone controls.
20th May 1999
Started hacking together a Win95 front-end for managing the MP3 filesystem.
It's not the most robust piece of software (pretty much no error
checking at the moment), but it seems to be vaguely working, as the screenshot
I am, sadly, (on the few occasions when I'm forced to write Windows code),
a "Classic" Windows programmer - ie. of the Petzold school. None of this MFC
nonsense for me, thankyou very much. Perhaps this explains why it takes me
hours to accomplish even the most basic functionality, whilst my MFC-addicted
colleagues simply point, click, and hey-presto - instant software. Grrr.
One day I'll learn MFC (but not today).
It's just dawned on me that I haven't come up with a stupid name for this
project yet (as the rather bland "Status" on the title bar suggests). Hmmm.
The LCD modules arrived yesterday, along with some Mystery Science Theatre
3000 tapes I ordered. MST3K has thus far taken priority, although I envisage
some serious LCD hardware/software development some time this weekend.
17th May 1999
Yow... I must confess that I haven't done a great deal since my last posting.
E3 was fun, but tiring. At last, our game is announced! ExciteBike64! Whoo!
A 64-bit revamp of the old 8-bit NES classic. Anyway, enough shop-talk. Flew
to Seattle today (6.00am start - ouch!) on work-related matters, but I did manage to hack out a little
more PC code on the plane, so some progress was made, however small. My main
reason for posting this, however, is that since I've been away I've received
a deluge of mail messages regarding MP3 players. Much as I'd like to respond
to each one individually, I'm probably not going to have the time, so I'll
Thanks to everyone who sent messages of encouragement - your support is greatly
If you're looking for information on MP3's, in particular, building MP3 hardware
solutions, then spectsoft.com
is a very good place to start. Lots of handy links. IDE info, links to similar
projects - what more could one ask for?
To everyone who offered to help on the project - thanks! I'm doing ok at the
moment, and hopefully won't need any assistance, but should I get stuck, no
doubt I'll be posting lots of questions to the Spectsoft mailing list (see
above link!), and any assistance will, of course, be acknowledged.
Anyway, thanks for the interest. I hope to get back into the coding side of
things very soon. Right now, however, I'm going to sleep.
11th May 1999
Finally got around to ordering a couple of Optrex LCD modules from DigiKey.
Hopefully they should be here in a short while. I'm going to be at E3 (big
videogame convention) for the next few days (by day I'm a games programmer),
so I won't have much of a chance to work on the player, but hopefully my
return should coincide neatly with the arrival of some hardware!
I was surfing around the other day, and came across quite a few other people's
MP3 player sites, all of which look quite interesting! I notice that the direction
a number of people have taken is to build their players around a PC, generally
running Windows or Linux. This is a great approach, and in fact, I have a
similar system at home hooked up to the stereo. It's a P166, running DOS,
and using some MP3 decoding software (that I hacked together from the
Fraunhofer demo code) to talk to an AWE32. It uses a Scenix SX18/AC to decode
the IR signals, which are then dumped to the PC's serial input. The display
is a nice, backlit 20x4 serial LCD. Works great. Sounds terrific.
However, this time round, I'm building a unit for the car, and taking a very
different approach. I own a Miata, and fitting an entire PC-based assembly in
the trunk just isn't feasible. (Well, it is, but it wouldn't leave any space
for anything else). The PSU issues are also a great deal more complex in a car,
and I also didn't want to have to worry about proper shutdowns, etc... So,
rather than use an existing motherboard, I'm building the hardware from
scratch. This should result in a much cheaper unit too. There are a
couple of drawbacks to my approach, however, which one has to be aware of.
The main one is the fact that the microcontroller I'm using (PIC16C64) isn't
really that powerful. Since all the decoding is done by the MAS3507D, it
doesn't need to be. However, I'm cramming all the interface code into 2K of
ROM, so there really aren't going to be that many bells and whistles. I'm
probably not going to bother with playlists, or anything like that. Also,
I'm initially going to support only IDE hard drives. No CD-ROMS. Perhaps
I'll put some ATAPI/ISO9660 code in there later, but that's not too high
on the list of priorities. (The main point of doing this is to get away
from carrying a stack of CD's around with me everywhere!) Also, I've thus
far resisted the temptation to buy a CD-R unit. So, in summary, "Cheap and
Functional" is pretty much the order of the day.
8th May 1999
Infra-red is working. I'm decoding 15-bit SIRCS at present, 'cos that's what
kind of remote I've got handy. I have yet to design the whole menu/navigation
system, but now that the IR's in place, it should be nice and easy. One thing
I was thinking of, which would be neat, is to allow the system to be trained
to respond to any standard IR remote. We'll have to see... Code size is up to
768 words, (but that includes a load of debugging stuff). I'd forgotten the
misery of using interrupts on a 16C64 - context saves have to be done by
hand... at least on the Scenix chips, you get W and STATUS backed up
automatically! In fact, if Scenix's upcoming 48-pin chips were generally
available, there's little doubt I'd be using them instead! Actually, the
code doesn't make use of *any* chip-specific features except a timer
interrupt every 1024 ticks, so in theory porting it to another uC should be
a breeze. Even the I2C will be bit-banged.
Embarrassingly, I discovered another major opcode emulation bug...
addlw was actually resetting W to 0 every time! Upon discovering this,
I blinked in amazement, and asked myself how the hell the thing could have
worked at all! A quick scan through the code reveals that this was the first
time I'd actually used addlw. Amazing, eh?
7th May 1999
Right... I've calmed down a bit now after the Windows fiasco.
Tidied a few things up a bit, added a slightly more generic TrackStart
routine which actually fills the buffer up before spooling any data to
the MAS. End of track detection is handled a little more neatly now too.
I'm pretty much twiddling my thumbs until the MAS boards arrive, although
I have been considering how best to implement the user interface, etc... Code
size is hovering around 600/2048 words. Plenty of room to put PONG in there
too :) The next step (assuming the boards don't arrive today or tomorrow)
will probably be to add some kind of infra-red support. I may start off by
supporting just SIRCS, 'cos it's nice and slow!
5th May 1999
Grrrrr.... lost a whole f*cking day to Windoze. I was up until
2.30am reinstalling, and fighting with Microsoft's crappy
software. Is there anything more depressing than a shagged-up registry? If
there is I don't want to know. Of course, re-installing only makes things
worse... despite the fact that I don't really have any freaky hardware
Windoze continues to fail miserably with all manner of device conflicts
and dodgy driver complaints. Thing is, I know about computers,
and I pity the hell out of any poor newbie who has to deal with this.
4th May 1999
I think the filesystem specification is now more or less firm enough to
describe. Of course, it's all subject to change, but what I have seems to
work reasonably well. As mentioned before, I'm using a proprietary FAT-like
system. My main reason for not wanting to go with FAT16 is the inability to
have partitions bigger than 2GB. FAT32 I don't know enough about, and I don't
want to have to deal with any complexity on the PIC side of things. The
filesystem is designed to take most of the work off the PIC. The PIC won't
ever be writing to the filesystem (except under direct control of the PC),
which makes life a lot easier.
All addressing is done in LBA mode... quite why anyone would still want to
stick to CHS in this day and age is beyond me. The first sector on the drive
contains the following information:
unsigned long signature;
unsigned char copyright;
unsigned long fatStart;
unsigned long fatCount;
unsigned long dataStart;
unsigned long dataCount;
unsigned long cdStart;
unsigned long cdCount;
Note that an IDE sector is always 512 bytes.
Ignoring signature and copyright for now, we come to fatStart.
fatStart contains the LBA address of the first FAT sector. fatCount contains
the number of sectors of FAT data present. Since I use 32-bit FAT entries,
there are 128 entries per sector. Each entry corresponds to an 8KB
cluster, and contains 00000000h if the cluster is free,
FFFFFF00h if this cluster is the last in the chain, or XXYYZZ00h
where XXYYZZ is the number of the next cluster in the chain. Note that all
values here are little-endian, and the last byte is 00h (this is reserved for
dataStart contains the cluster number of the first data cluster.
The data clusters follow the FAT table, and start on a 16-sector (8KB) aligned
boundary. Thus, the physical LBA sector address of a cluster can be
sector_address = (cluster_number + dataStart) * 16
Predictably, dataCount contains the number of data clusters present
on the drive.
The CD sectors are stored contiguously, at the end of the drive.
The CD database grows backward from the end as new CDs are added. If the user
wants to add a new CD, and a data cluster is in the way, the data cluster must
be relocated to a free cluster elsewhere on the drive (and the FAT table
updated correspondingly). Once this is done, the dataCount member of the
header is decremented.
A CD is stored in a single sector. The format is:
unsigned char trackCount;
unsigned char reserved;
unsigned long trackClusters[MAX_TRACKS_PER_CD];
MAX_TRACKS_PER_CD is 100. This makes the CD sector exactly 512 bytes
long. The trackClusters array contains the starting cluster for each of the
tracks. So, where are the track titles stored? Why, at the start of each
track cluster chain, of course! Each track chain starts off with the following
unsigned long signature;
unsigned long length;
unsigned char reserved;
unsigned char trackTitle;
unsigned char artist; // for compilation CDs!
unsigned long indexMarks;
This structure takes up exactly 2 sectors, and is followed immediately by
the MP3 bitstream. The indexMarks array is something I added after wondering
how to deal with fast-forward, and more specifically, rewind. While the FAT
table is great for purely sequential file access, it doesn't help much in finding
the preceeding clusters. I considered a number of options, but decided that the
easiest way (and therefore the best for the PIC!) was to store an array of
equally spaced index points in the tune. The array contains the cluster
numbers of these points. For a, say, 5 minute track, this corresponds to
a spacing of 1.34 seconds. If we have a ridiculously long 1 hour track, this
corresponds to a spacing of 16 seconds. What I might do later (haven't decided
yet) is clamp the minimum spacing at, say, 4 seconds, and have a correspondingly
fewer number of index marks for songs less than 15 minutes long (ie. nearly
all of them). I think 4 seconds is plenty of accuracy for FFWD/REWIND, and
this solution makes the PIC's life (not to mention mine) much much easier.
2nd May 1999
Slow weekend... went to see Underworld playing in Santa Monica last night,
so consequently this morning was spent nursing a hangover and not coding.
However, the last couple of hours have been a veritable code-fest. The
streaming is working, in hardware, and not just under emulation. Not too
much had to be changed... turns out I had a bug in the RLF opcode emulation,
which meant that things worked slightly different in hardware, and I had a
couple of minor bugs in the PIC code, but nothing too severe. I'm very glad
I decided to go with the emulation approach, because tracking down subtle
PIC asm bugs without a debugger can be a nightmare! So, once I verify that
this works with the MAS board, all I need to do is handle the I2C, LCD,
IR, buttons, and general user-interface. Whoo hoo!
29th April 1999
Don't you just love debugging your code at the nano/microsecond level?
Well, I'm using a 20MHz crystal, and now my PC to IDE transfer rate is
up to 150KB/sec, and the IDE to PC rate is 90KB/sec. A bit slower than
anticipated, but it'll do - at least for now. The difference in speed to
the maximum theoretical throughput is probably due to the delays inherent in
a synchronous protocol with polling loops. A 4MB MP3 file now takes around 25
seconds to download. I *was* getting a whole load of errors, until I
realised that two pins that really shouldn't change at the same time, were.
Doh. Still, it's all working fine now.
As an added treat, here's a picture of the circuit as it stands...
As you can no doubt tell, the 16C64 is at the heart of the circuit (it's
mostly obscured by wires). The octal latch and transceiver comprise the PC
parallel port interface, and share a "bus" with the SRAM and the IDE
28th April 1999
Managed to get quite a bit done today - the PC parallel port interface and
PIC server code are working, so I can finally read and write sectors from the
PC at a half decent speed. I say "half decent", because the throughput is a
little slower than I would have liked. I'm getting around 100KB/sec. This
is mostly due to the fact that I'm still using a 10MHz crystal, and also
partly due to the fact that all the polling loops on the PC side are
written using pretty inefficient C code. Maybe I'll try assemblifying these
tomorrow. I expect to get a lot nearer to 300KB/sec by the time it's finished.
I'm waiting on a MAS evaluation board to arrive, and until it does,
the next goals are to write some nicer filesystem-manager/file-transfer
software for the PC, and to see if the streaming code works in real life as
well as the simulation!
The code size is up to 537 bytes so far, which includes all the streaming
code, generic IDE to RAM transfers, as well as the PC comms. I think 2K
should be plenty!
27th April 1999
Wrote the code for transferring IDE buffer data to the PC parallel port.
The maximum possible throughput at present (assuming I run the 16C64 at
20MHz) is around 300KB/sec from PC to PIC, and 150KB/sec from PIC to PC.
This is a little on the slow side, but it's a pretty bulletproof protocol,
and it should work on any PC parallel port.
The components at present consist of: PIC16C64, 74138 (octal inverting
demultiplexer), 55256 (32K SRAM), 74245 (bus transceiver), 74574 (octal
D-type flip-flop). This is enough to control the IDE interface, SRAM buffer,
and PC parallel port interface. I'm pretty sure I can add a Hitachi 44780
type LCD display with no additional components. An additional transceiver may
wind up being required for interfacing with the MAS chip (depends on whether
or not I run out of IO pins). Haven't come to a decision yet as to the
user input method (buttons, or maybe just infra-red). Infra-red is obviously
a little more effort to decode, but has the advantage of requiring only one
IO line. I've also done a whole load of IR stuff in the past, and happen to
have a spare "credit-card" sized IR remote that could work quite nicely.
25th April 1999
I've been working on this for a few weeks now, but haven't had as much time
as I'd like, since "real work" keeps getting in the way. However, I've
made a number of fundamental decisions about how the thing is going to work,
and started hacking stuff together on a protoboard.
I'm using a PIC16C64 as the main controller, since it has a nice large number
of I/O pins, it's reasonably affordable, it's reprogrammable in circuit,
it's easy to emulate, and I'm pretty familiar with how PICs work.
Since the 16C64 only has 128 bytes of RAM, I'm using a 32K SRAM chip as a
buffer for the IDE sectors. The player will be based around a filesystem
of my own design, and will connect to a PC via a standard parallel port
in order to transfer tunes and modify the CD database. The player itself
doesn't have to worry about updating the filesystem - when connected to the
PC it will operated in a "slave" mode, simply reading and writing sectors
as the PC requests. Thus, all the filesystem management issues can be handled
by the PC (integrity checking, etc...). At present, I'm using a FAT-like
filesystem, with 8K clusters, and 32-bit FAT entries. On a 4GB drive, this
results in about 2MB of FAT (yoinks!!), but hey, you can afford it, right? :)
I don't have an in-circuit emulator for the 16C64, so rather than proceed
by trial and error, I've written a software emulator for the whole system.
This program simulates the 16C64, the IDE drive, the SRAM, and I've just added
support for the PC parallel port interface, via TCP/IP. This means, I can
run the "virtual player" in one window, and run a modified version of the
PC comms software in another window (or indeed, on another computer), and
thus debug the parallel port interface.
Thus far, I've been attacking the problem from two angles. In order to debug
the PIC code, I've been using my software emulator. In order to ensure the
hardware works, I've also got some "slave" PIC code that talks to a PC over a 5 wire
synchronous serial interface, and allows the PC to control the PIC's 28
remaining IO lines. This enables me to verify that the hardware functions as
it should. Fortunately, it seems to. At least, I can read and write IDE
sectors just fine.
Over the next day or two, I hope to get the PC comms to a level where I can
manipulate the player's filesystem at a decent speed. I also want to merge the
"slave" PIC code with my emulator, so that I can single-step through the
IDE streaming code, using the actual hardware (albeit indirectly).
I'm acutely aware that there are some issues I haven't yet resolved. These
include getting a clean power supply from the car battery, what kind of
user interface to present, interfacing the (lower voltage) MAS chip, and
most importantly, what colour it should be.
Get Back, Jack.