Alman
Newbie level 4
Hi there, new here, looks like the right forum to maybe provide a little help with my situation.
So here's what I'm up against.
I have been the proud owner of a Neo35 car jukebox since they were first introduced around 2001-02. This is a hard drive based mp3 player that can be removed from a vehicle (sleeve mounted) and used in other locations etc.
The main unit contains the IDE drive (I know, old right) and the mainboard, lcd display, and a few buttons. There is also a remote head unit for the car sleeve, which I have mounted in the dashboard of the truck, and it duplicates the display and controls on the main unit.
The CPU is a Hitachi SuperH SH-1 configured in PROM mode, and in addition to the DSP and other components on the main board, it is hooked up to a 29F040 flash eeprom that is in a 32 pin PLCC socket.
It was manufactured in the states by a company called ssiamerica, but apparently it is the same as another unit called the mstation by I think a company called traxdata.
The original OS as shipped was kind of buggy, didn't work all that well, so after a couple of years, the user community developed open source software for it called OpenNeo, which originally was a port from RockBox.
I have been running the open source software since it was released, waaay better than the stock OS. It went through several revisions, ending at ver 2.1 beta 14. Up until recently I was running beta 11.
I have been saving IDE drives for years now, as I need to replace them every once in awhile due to failures from bumpy roads.
The ssiamerica web site still exists, but they dropped the neo a long time ago. Similarily, around the time that Steve Jobs changed our world with idevices, the open source community also disappeared.
A couple months back, my drive died (expected) so I pulled it apart to install a replacement. It was at that time that I noticed that there was the beta 14 firmware on sourceforge, so I downloaded it, and went to flash it onto the neo. Thats when my troubles began, I should have left well enough alone. Oh well.
The method to update the neo was as follows. All you had to do was copy the new bin (renamed to either openuu.bin or neo35.bin) to the root of the drive. Then you would hold down the P (program) key when powering up, which would invoke the loader program. You would then select a menu item to program from the hard drive, and it would search the root directory for the file. If it found the file, it would tell you, then offer the option to proceed with a button push. Once done, it would write the new file to the eeprom, then say programming finished, reboot and away you go! Not this time unfortunately.
All I got was a blank screen. OK, I thought, I'll try it again. No go. same result. I could invoke the loader, but it was not able to write the flash successfully. I tried loading older versions, no go etc.
Not to be outdone, I thought well I'll just use my Willem programmer. Of course, this meant I had to get it working first, so after installing a LPT port on my win10 machine, and jury rigging the dll so it would actually work (it does) I tried my hand at it. I only know enough to be dangerous, and I managed to corrupt the eeprom on the first go.
I used the wayback machine and downloaded absolutely every page and file I could find, managed to get all the source code etc, even found some more bin files for both the loader and the main os, and found out a whole lot more, but there is still one part missing which is why I am here now. I am not a coder, and although I have gained a fundamental understanding of it all, the one thing I can't figure out is what bytes need to be at memory location 0000h on the eeprom although I know what they are supposed to do.
Normally, the loader boots first on power up and checks for the P button being pressed, if detected, the loader runs. If not it calls the main program which resides at a different location on the eeprom.
The loader is written starting at memory location 10000h and the main program is at 20000h. According to an obscure reference I found in an old forum post, there are some bytes at 0000h which "set up the CPU, then call the loader program". I cannot find anywhere what these bytes should be. I have seen references to vector tables, and in the source it talks about file alignment when writing to the eeprom, but I can't figure out the math to establish what it should be. It also makes mention of calling the routines at 10200h for the loader, and 20200h for the main program. I tried byte patching a jmp to those various addresses but nothing happens on power up. Now I am just pulling out my hair trying to figure this out. I am about to go on some very long drives, and need this thing to work again for my sanity.
Is there anyone here that might be able to provide some guidance? I can post or send all the info I have got. I would be very grateful, and so would my wife, who thinks I am avoiding her lately due to all this......
So here's what I'm up against.
I have been the proud owner of a Neo35 car jukebox since they were first introduced around 2001-02. This is a hard drive based mp3 player that can be removed from a vehicle (sleeve mounted) and used in other locations etc.
The main unit contains the IDE drive (I know, old right) and the mainboard, lcd display, and a few buttons. There is also a remote head unit for the car sleeve, which I have mounted in the dashboard of the truck, and it duplicates the display and controls on the main unit.
The CPU is a Hitachi SuperH SH-1 configured in PROM mode, and in addition to the DSP and other components on the main board, it is hooked up to a 29F040 flash eeprom that is in a 32 pin PLCC socket.
It was manufactured in the states by a company called ssiamerica, but apparently it is the same as another unit called the mstation by I think a company called traxdata.
The original OS as shipped was kind of buggy, didn't work all that well, so after a couple of years, the user community developed open source software for it called OpenNeo, which originally was a port from RockBox.
I have been running the open source software since it was released, waaay better than the stock OS. It went through several revisions, ending at ver 2.1 beta 14. Up until recently I was running beta 11.
I have been saving IDE drives for years now, as I need to replace them every once in awhile due to failures from bumpy roads.
The ssiamerica web site still exists, but they dropped the neo a long time ago. Similarily, around the time that Steve Jobs changed our world with idevices, the open source community also disappeared.
A couple months back, my drive died (expected) so I pulled it apart to install a replacement. It was at that time that I noticed that there was the beta 14 firmware on sourceforge, so I downloaded it, and went to flash it onto the neo. Thats when my troubles began, I should have left well enough alone. Oh well.
The method to update the neo was as follows. All you had to do was copy the new bin (renamed to either openuu.bin or neo35.bin) to the root of the drive. Then you would hold down the P (program) key when powering up, which would invoke the loader program. You would then select a menu item to program from the hard drive, and it would search the root directory for the file. If it found the file, it would tell you, then offer the option to proceed with a button push. Once done, it would write the new file to the eeprom, then say programming finished, reboot and away you go! Not this time unfortunately.
All I got was a blank screen. OK, I thought, I'll try it again. No go. same result. I could invoke the loader, but it was not able to write the flash successfully. I tried loading older versions, no go etc.
Not to be outdone, I thought well I'll just use my Willem programmer. Of course, this meant I had to get it working first, so after installing a LPT port on my win10 machine, and jury rigging the dll so it would actually work (it does) I tried my hand at it. I only know enough to be dangerous, and I managed to corrupt the eeprom on the first go.
I used the wayback machine and downloaded absolutely every page and file I could find, managed to get all the source code etc, even found some more bin files for both the loader and the main os, and found out a whole lot more, but there is still one part missing which is why I am here now. I am not a coder, and although I have gained a fundamental understanding of it all, the one thing I can't figure out is what bytes need to be at memory location 0000h on the eeprom although I know what they are supposed to do.
Normally, the loader boots first on power up and checks for the P button being pressed, if detected, the loader runs. If not it calls the main program which resides at a different location on the eeprom.
The loader is written starting at memory location 10000h and the main program is at 20000h. According to an obscure reference I found in an old forum post, there are some bytes at 0000h which "set up the CPU, then call the loader program". I cannot find anywhere what these bytes should be. I have seen references to vector tables, and in the source it talks about file alignment when writing to the eeprom, but I can't figure out the math to establish what it should be. It also makes mention of calling the routines at 10200h for the loader, and 20200h for the main program. I tried byte patching a jmp to those various addresses but nothing happens on power up. Now I am just pulling out my hair trying to figure this out. I am about to go on some very long drives, and need this thing to work again for my sanity.
Is there anyone here that might be able to provide some guidance? I can post or send all the info I have got. I would be very grateful, and so would my wife, who thinks I am avoiding her lately due to all this......