Roland S10 OS Modification

Only half a display

Introduction I fitted a new OLED display to my Roland S-10 sampler in February 2019, but the new display only shows the first 8 characters, as the original display is configured as 2×8 lines when it actually shows 1×16 lines. The new display is not a drop in replacement. This problem also affects the Roland Alpha Juno 1 and 2 which uses the same display. The solution is to modify the operating system to change the assembler code that writes the characters onto the LCD.

Processor History Roland started off in the late 1970’s using the Intel 8048 processor with inbuilt mask ROM in the Jupiter 4, Pro-Mars, CSQ sequencers and the 184 keyboard. This had a tiny 1k byte of ROM space, so the programs had to be very small and tight! The Juno 6/60 used the 8049 which has double the ROM size, whilst the Jupiter 8 and MSQ700 use the Z80 and external ROM chips. By the mid 80s’ Roland were using the Hitachi 630X processor family alongside the Intel 8051 family. The S-10/MKS100/S220 samplers all use the same Intel 8032 processor with 64k bytes of external ROM to hold the operating system. The UV EPROM chip used was the MBM27C512.

OS Change Process To correct the display readout I need to modify the code in the Roland S-10 Operating System which is written in 8051 assembler. Fortunately this has been done before to alter the MIDI notes off (in both the S-10 and Alpha Juno), so I am treading a proven path. The OS is extracted from the ROM into a binary file, then disassembled. I can then alter the display code to provide the corrected offset on the LCD, and assemble the code back into a binary. This can then be burnt into a new EPROM and put into the S-10 replacing the old OS chip. I am using a modern Micro Chip 27C512 chip with 70 ns read speed, and they cost £1.50 each.

Roland S10 OS Binary The latest OS version from Roland is 2.07 file, and this ROM has already been extracted and is available here. I used this version as it saved a step in the process and meant I could look at the disassembled code quicker, and see whether the project was possible.

OS 2.07 Features I suspect most S-10’s have the latest OS, but if you have an earlier version this is what you are missing:

• MIDI system exclusive capability.
• Fix to fast appregiations dropping notes.
• Fix for the GATE input silencing voices.

Disassembly I tried using a free Windows program from Spice Logic to disassemble the code, but this did not read the hex file successfully. I then used a Windows 10 cloud based disassembler and this gave me both a reference and disassembled file. Looking through the code I could see what looks like an LCD write subroutine at address 73C3 with two sets of mov instructions spaced 40h apart, which matches the spacing of the original LCD data structure. Here is the code:

Address_73C3:
mov a,#0x80
mov Register_68,a
mov P2,a
mov r0,#0x00
movx @r0,a
inc r0
clr c
lcall Address_3AE0
lcall Address_78ED
mov r0,#0x00
mov a,#0xC0
movx @r0,a
inc r0
lcall Address_3AE0
lcall Address_78ED

In theory all that needs to change is the second mov command to use an address of 0x88, so that all the 2nd line display commends have an offset of 8h in addressing rather than 40h. The code would be well written if all the LCD calls use this sub routine. Register 68 looks like the LCD display register. There are around 200  text messages in the S-10 operating system, including messages for the test routine, and an Easter Egg at address DB7E (SUZUKI GSX-R 400, HONDA INTEGRA GSI). This text is longer than 16 characters and was never displayed!

I have mapped the text messages in the code to the address lines, and then back to the LCD write sub routine at 73C3. I have not mapped them all back but I am sufficiently confident to change the code and burn a new EPROM along with a change in OS version to 2.09, as 2.08 is the unofficial modified version for correcting the all MIDI Notes Off.

Assemble and Burn The change is only two bytes in the whole code, so my initial approach is going to be to alter the binary code at the appropriate addresses rather than re-assembling the disassembled code, as this is more straight forward and the as51 assembler may not read the disassembled code correctly. The first stage is to buy some EPROM chips (Micro Chip 27C512) and burn the 2.08 code into one and check the S-10 works with no modifications by me.  I am using my trusty TOPS 2009 ROM burner, but there are more recent versions that do the same job.

The second stage is to modify the binary code in two places (OS version and LCD offset), then burn a new EPROM and see if it corrects the display writing on ALL 200 messages. If there are any exceptions I will go back to my message address map and see how the display is being called for that message that fails. I will post the results soon!