So here is my situation;
I am the owner of a Neo35 car jukebox, which I bought new almost 20 years back, and have used it practically daily since then up until recently. Unfortunately, I managed to kill it, now I am trying to revive it, and this is one of the few places left anymore that may be able to help me, from what I can gather at least. Here are some facts about this unit that may help you understand why I feel this is the case.
- The Neo35 is a hard drive based MP3 player that uses the Hitachi SH1 processer, like the original Archos Recorder.
- The original firmware released with this unit was horrible, and that quickly inspired an open source community to be established to fix this.
- The first iteration of the open source platform was originally ported from here (Rockbox) although I think some bad blood may have been created over this back then.
- The Hitachi SH1 was a popular MCU back then, but has fallen into obscurity since then, at least for this type of application.
- From what I can determine, that original Archos functioned very similar to the Neo in the way that the OS was loaded into memory on startup etc.
- The old forum that used to exist for the Neo has disappeared long ago, only fragments are left in the Internet Archive (Wayback Machine).
- The particular issue I am having was never covered in that forum (I was a member back then).
- Although the Archos has also faded into relative obscurity, there are still some files for it here,
and more importantly, there might be some people here who understand it all at the level I need right now.
This is the issue that I am having, how I got here, what I understand about it, and what I (think) I need.
As stated before, I used this player a lot over the years, in my various vehicles throughout that time. The hard drives would eventually fail due to bumpy roads, and I have been saving old IDE drives for a long time now to swap them out when I do. Around Christmas time, the last drive I was using crashed, so I took the unit apart and changed it out, no problem. At the same time, I was browsing online, and discovered much to my surprise, that a newer version of the firmware was on sourceforge, and had been for sometime. It was version 2.0 beta 14, I was running beta 11, the readme detailed some improvements, so I downloaded it, and attempted to install it. This is where things started to go wrong for me.
When these players were sold, they came (obviously) in working condition, preloaded with the factory original OS. There were some updates to that, but the open source versions really were better, so nobody ran the factory OS long, if at all. To update, one would copy a correctly named bin file to the root of the drive (via the built in USB interface) and then power cycle it while holding the (P)rogram button down. This would invoke the bootloader/updater utility, which allowed one to flash the new bin to the socketed EEPROM (29f040) on the main board. A power cycle once complete would boot it up with the new flash. Simple.
In my case, recently, the flash process stated it was complete, but it would not boot into the main OS, I could only get the loader to work. I tried everything I could to get a working version of the OS to flash with no success. Drat.
I am a marine engineer by trade, I work with all kinds of PLC's and computers among many other things, I am good at what I do, and am not afraid to venture outside the box.
I have a Willem flash programmer which was lying around for a long time, I had hardly ever used it. Reading up on its capabilities, I determined that I could flash the EEPROM directly. I got it going, and started playing with it. It took me some time to discover that the way you physically socketed the chip made the difference as to whether you could accurately read/write to the EEPROM. Unfortunately, I had corrupted it beyond all recognition by the time I figured that out, and never did get a good read of the original formatting on it. Now the bootloader won't even run as I wiped the formatting from the EEPROM too.
I am not a coder, but I understand it at a fundamental level. I have been studying the source code for the OS, which I managed to get from that repo on sourceforge. I posted here a month or 2 back about the SH1 compiler environment, and did download the rockbox image here, and got the compiler properly set up and working in a VM. So far it hasn't helped me much other than to clarify a few things about how it all works.
As stated above, the normal process for flashing is done by the bootloader, which exists on the EEPROM, at address 10000h. Also, when run normally, that same bootloader calls the main OS code, which is also stored on the same EEPROM at address 20000h. The SH1 MCU is hardwired into "Mode 7" operation, which means that it only uses the external EEPROM and some external RAM for its functionality.
Here is the crux of my issue. When the unit is first powered up, it polls the EEPROM at address 0000h for some initialization routines, then it copies the bootloader to RAM, then executes it from there, I believe that the main OS is loaded in a similar fashion by the bootloader code, again I am not a coder, so I am struggling to understand exactly everything that is happening.
When I managed to bork my EEPROM with my trial and error, I also wiped out that code at 0000h. That is what I need to do, is figure out that code, and write it to that position on the EEPROM.
I have found a couple posts here that talk about restoring the original OS on a SH1 equipped Archos. It talks about backing up your original firmware. See the quoted post for details;
http://forums.rockbox.org/index.php/topic,30.0.html
What I think I need is a copy of the file that is generated for 0000-FFFFh (internal_rom_0000-FFFF.bin) as stated here. Although it might not work for me "out of the box", it may be enough to get me pointed in the right direction. Has anyone got it archived? I can't seem to find it anywhere so far.
I also have all the open neo source code, it is possible that a version of this routine exists in there too, but I cannot determine that for sure with my limited understanding of it, and would need help to "carve it out" then format it properly to compile it in the VM environment. If the Archos file doesn't pan out, maybe there is someone here that could help me figure that out?
Thats about it, feel free to ask away if I can clarify things any further, and thanks in advance for anyone who responds...