I tried a PATA to SATA converter, with a SATA CF card reader, but did not work either, despite both devices supposedly supporting ATAPI.

Don’t know if any previous posters are still interested but thought I’d mention this, I bought a MPC2000xl with the MCD drive installed, I thought that I’d put the MCD drive in the SP-808 and use one of the generic ones that did not work in the SP-808 in the MPC, as I had a few around that did not work in the SP-808. Anyway I put a Startech CF-IDE in the MPC, but it wasn’t recognised, after a bit of research I discovered that the 1.14 firmware in the MPC was not compatible with the generic type IDE drives, but v1.20 was, so I installed that on the MPC and now the Startech works in the MPC. The MCD drive works well in the SP-808 as expected.

So it might be worth somebody with the appropriate skill comparing the MPC2000xl 1.14 firmware with the 1.20 firmware, to see what Akai changed.

Also if you are prepared to buy a MPC2000xl with the card reader and a Startech drive to replace it, you can probably resell the MPC for what you paid after changing the card reader, the Startech is about £25-£30 on Amazon, so essentially you end up with the MCD drive for a much lower cost if you don’t mind a little work and buying then selling the MPC. You can find the 2000xl for quite reasonable prices if you are patient.

maybe should have bought one back then... now $416 !

I missed the link to his hardware on the video in the description(out of stock!):
https://issues.tattiebogle.net/dokuwiki/doku.php?id=mantis:ide_simulator:start
and SP specific, with possibly some unkon info in this thread (it has been a while, I cant remember!)
https://issues.tattiebogle.net/dokuwiki/doku.php?id=mantis:ide_simulator:uhd

the proliferation of 0x00 is because many instructions are designed to have upper bits of addresses as 0x00


Initially promising, I found my disassembling lacking. The MAME emu has *some* support for H8's and there exists a disassembler in the tools. I couldn't get reasonable results.


I am looking at how likely it is I could write a processor module for Ghidra. The instruction set is only 69 odd instructions, but the variety of modes possible, and the many nuances look tricky. The H8 processor module doesn't look that scary, but you would need to get it pretty right, so you don't spit out garbage.

I see MAME has a few processors and looks like they build on previous versions. example H8S2600.h would have a H8S2000.h include which includes a H8300 include... and the last is simply a H8 include. but MAME processor definitions look HARD!

been looking around at some other stuff H8 hacking related to see if there are any that might help. more to come tomorrow

here is a lesson on hacking a MCU. fascinating. I don't think in my lifetime I will get to this level, sadly.
http://dmitry.gr/?r=05.Projects&proj=28.%20pokewalker

Seems the HD6432653 is one of those in-between models that the vendor will say.. what 2653? I dunno what you are talking about..shhh!!!

There are a few differences between closer models (would have been nice if it was one of those!) that is going to make it difficult to proceed.

adapter working? Translatable to English: https://www.phantom.sannata.org/viewtopic.php?t=40212&start=165

anyone have a dump of the Sharp Flash LH28F800SUT? Looks like it is where the .mid files write firmware to. maybe we are not supposed to cat them all together? possibly they need to align to specific memory map. Also, maybe this file is not a single program to execute, and therefore decomplie, but a collection of small programs/code to jump to and data.
this site appears to have worked out any sp808-ex will work fine with a HDD once updated with A^ .mid files, and so might not be too much in reversing the Hitachi 2653, but more effort on these .mid updates and the flash.
https://sp-forums.com/viewtopic.php?f=10&t=4353

I asked a chip revere engineer/decap company if they could get the mask and PROM from the hitachi, and they said they are working on it but not able to yet. GO HITACHI!!!

Anyone know anything about these expansion boards for the SP?

https://reverb.com/au/item/56525330-rare-roland-sp808-op2-scsi-digital-i-o-expansion-board-for-sp-808-sp-808ex-worldwide-shipping



I wonder if this port is useful in any way?

I have the OP1 board fitted in my SP808, sadly the SCSI also only works with Zip drives, I have a SCSI CF drive and tried it with various CF cards but no bueno.

Interesting to note about using the Akai MPC2000XL MCD drive in place of the Zip drive, you can still get disk busy messages if trying to cut and paste small sections of audio, albeit less so than with the Zip drive. AFAIK the Roland A6 which was fitted with a IDE HD did not suffer from disk busy errors, the A6 also has some other useful features like split phrase and adding fades which would be useful on the 808, but A6 lacks quite a lot of key features that the 808 has, if a hacked firmware could be possible someday, it would be great if some of the A6 features could be added to the 808 as well as of course the drive handling stuff.

Thanks for the info @Buzunki. Always good to hear about experiences with units from owners.

I've been looking at some EX's and will likely buy one next week to have on hand for testing and dumping the flash chip. I expect it to contain the firmware we already have, but I want to see the actual organisation of it on the chip.

The firmware is not decompilable in it's current form, or the tools don't exist to do it successfully.

Writing any code for it is currently off the table as well because we don't know what mode the H8S2653 uses, or what is in PROM/Mask ROM (if anything). I am thinking some form of bootloader / bare minimum OS.

Question:
does anyone know of any other Roland equipment from around the same time that also uses a H8 or H8S MCU? Might be able to research those and see if any commonalities exist.

The A6 and possibly some VS models from that era use the same MCU.

@HaQue so editing/spicing the A6 and SP-808 firmware midi files isn’t a viable option? That is a shame if not, is it because the code is not readable into meaningful human readable form to determine the sections of interest?

The fact is, we don't know enough about the firmware to splice it. And we are using the word 'splice' very liberally here. I/O to disk is not so simple that you can replace 'write_to_Zip()' with 'write_to_disk()'
- We don't know what mode the CPU is in yet. This would be a critical factor in reversing the firmware.
- We don't know the memory map.
- We know there is a 64 mask rom, but don't know if it is actually used. If it is, 2 chip decapping companies so far has said they cant hack it.
- We know there is flash, but don't know the mapping.
- We assume the firmware we have is written to the flash, but we don't know for sure, or know what is at what addresses.
- There are maybe a 4 to 6 other H8 or H8S hacks with very little info. there is not a lot to go on, unlike many other hacks of products.
- There isn't much expertise in this area looking at this project. This is going to be slow going.


I have bought an A-6 (SP's are a bit pricier and if it looks promising enough I will get one.) I want to read the Sharp flash chip for a start to document that part of it. I also want to poke at the MCU with my Saleae and see if there is any way to get some info from it.
I have a few ideas brewing but need to get a phy unit first to play with

So this part of the manual appears to confirm there are 2 'firmwares'



It is kinda obvious, but still good to confirm things

Received my A-6 today. labels all in Japanese!



Luckily this was an overlay easily removed.



It already had SP-808EX on it.



Nothing lasts long without me getting a screwdriver to it! Here is the MB:



I thought the pads at CN7 looked like they had been probed, but no this was just some flux. but the 2x25 row of pads when looking under microscope definitely show there has been probes pushed into the pads, each pad had about 3 probe marks. the circled ones I only had time to check, but they go straight the the H8S processor.



The processor and flash chip are my targets. I am going to hit the SCI Serial Communication Interface on CPU, test pads and other Ports of chip with the Saleae logic analyser, read the flash chip once my new T56 Programmer arrives and see if any signals are evident. Also looking at the test programs mentioned in the manual and finding some way to run code from ram to try and read out the mask rom on CPU. if there is a vulnerability in the system somewhere, it may be possible.

There is Beam board and MIDI peripherals that communicate with the processor, so maybe there is a way to use these I/O ports to gain more access.

Wondering if it is possible to use the technique in this post to somehow access other parts of the system. Namely put CPU in a different mode that ignores onboard OTPROM and boot from flash with some code.

https://hackaday.io/project/188508-repu ... 039-h8300h

Also wondering about how the buttons tell the OS what to do. Looking to see if a button press is sent via an ascii code or some protocol, what happens if we send something unexpected?

I edited together some images of the test mode. The RAM looks interesting. Not sure what PRAM0, PRAM1, IRAM0, IRAM1, GRAM and ERAM are. I have seen reference to IRAM being CPU Instruction RAM, but not so sure that is what it is here.

Appears the update file previously put together decompiles. Have got a nice disassembly of over 1200 subroutines. Subroutines appear to mostly look well disassembled. The pic shows the start of a function with parameters passed at the start.



Some disk routines found:






This looks to be a menu or at least a case statement, if or similar. likely responding to a user input:



Test Mode looks to be part of Flash:



Getting some nice idea of program flow:



TODO:
-continue to map strings properly to help identify subroutines.
- find out what maps to 0x400000 of the address space to eliminate the dreaded red references
- learn more H8S 2600 ASM !
- go through and find anywhere there is a part of a routine that waits for user input, and see what it is using to compare to. eg a button press of "OK" to what hex code... where does it get the code? can we inject codes ourselves...
-understand the disk routines.
-compare to A-6 System code
-sleep

I received the programmer to read the LH28F800SUT flash chip.

Interesting. The start of the flash dump is essentially the same The SP808.bin that we have from previous work extracted from the .MID updates.



The dump is bigger, and continues with assumed empty space until 0x000F000



Then there is some more data:



if you make the view 256 bytes, there is a visible pattern.



I think I have all functions defined in the code now.



the flow looks to be easy enough to follow, so starting to drill down into the disk ones and analyse them.
Luckily we can isolate functions so as to not need to follow this

@HaQue you're back!

I too bought the flash reader, and found what you found.

but i can not decompile the firmware cleanly. Which address did you use as entry point? Did you remove the Roland header and footer first?

I have the reader from our Russian friend, i worked with him to make it compatible with the SP808

HSIBOY

Yes this works very well, i worked with user Sintechi to get the emulator working perfectly with the SP808. Due to the sanctions placed on Russia and because of the political unease, he is taking a break from the project, but he has re-spun a new version of the board.

The emulator has a bus sniff function, which allows all data on the IDE bus to be captured. This allowed us to see the interaction between the SP808 and the ZIP drive. I have put logs here: https://github.com/hsiboy/Roland_SP-808_Reverse_Engineering/blob/default/Roland_SP-808_to_ZIP_Drive_sniff.md