MP3 Player

MP3 Player

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 firmware at:

http://www.codepuppies.com/~ben/sens/pic/mp3/v1.2.3.zip

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!

http://www.vitrum.cz/snail/eng/mp3sale.htm

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 just hard-drives.

13th June 2001

From Greg Wood:

Here is a thru-hole hole PCB designed by Greg Wood, 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 explanation.

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 directory.

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 this!)

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 here.
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 time. Sorry!

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: http://www.imbdev.com/mp3r1.html.

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. Phew.

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
IT LIVES!!!!

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 below illustrates:

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 summarize...

Thanks to everyone who sent messages of encouragement - your support is greatly appreciated!

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[28];

	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 future use).

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 got from:

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[15];

	char		title[48];

	char		artist[48];

	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 structure.


	unsigned long	signature;

	unsigned long	length;

	unsigned char	reserved[24];

	unsigned char	trackTitle[48];

	unsigned char	artist[48];		// for compilation CDs!

	unsigned long	indexMarks[224];

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 interface.

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.