This is the “How and Why” article on my experiments on the M6000.
I was finally able to bring my M6000 back to life using this procedure: https://radix-studio.fr/blog/2022/05/16/m6000-soluce/
This article details my hypothesis on why this actually made the trick.
Tuning the DIP switches
The H8 CPU boots with CS0 enabled by default, thus the program is accessed on whatever memory is connected to the main bus and enabled by CS0. According to the schematics, we can see that the switches A and C should be used to boot on the Flash memory (A) or the PCMCIA BUS (C). Default switch position is A, in order to boot on the Flash memory. In our case, we suspect the flash to be corrupted and we want to boot on the PCMCIA card instead. Thus we set A to OFF and C to ON.
When the H8 program needs to access the PCMCIA card it uses the PCMCIA_MEM_CS which can be routed to PCMCIA BUS (by setting switch B) or FLASH CS (by setting switch D). Clearly, the default position is switch B: we want to route PCMCIA accesses to the PCMCIA BUS. When flashing the main Flash, we’re in a different setup: the roles of the PCMCIA card and the internal flash memory are inverted (we boot on pcmcia and we want to write the flash). Thus, we set it to B disabled and D enabled.
The switches E and F are funny. By default we set them to OFF, which sets the H8 memory access to 16bits (MD0, MD1 are set to gnd and MD2 is set to 5V. This sets the H8 CPU to “Mode 4”). Now we want to boot on the PCMCIA which is an 8 bits memory so we set these switches to ON ON (MD0, MD1 are set to 5V and MD2 is set to GND. This sets the H8 CPU to “Mode 3”).
Switch G is used to enable the external RAM memory. This is the default setting and we still want external RAM.
Switch H is used to enable the flash chip. Since we plan to write on the flash memory, we will need it.
| Switch | Position | Why? |
| A | OFF | We don’t want to boot on the flash |
| B | OFF | Roles of PCMCIA and Flash are inverted so don’t root pcmcia accesss to pcmcia |
| C | ON | We want to boot on the PCMCIA, so boot_cs goes to pcmcia |
| D | ON | Roles of PCMCIA and Flash are inverted so pcmcia accesses go to flash |
| E | ON | Set MD0 and MD1 to 5V for Mode 3 (8 bits). |
| F | ON | Set MD2 to GND for Mode 3 (8 bits). |
| G | ON | Keep the external RAM in use. |
| H | ON | Keep the flash memory in use. |
Mv6b20.ins
Initially the Mv6bv20.ins was sent to me by the TC support (Musictribe). They told be to put it on a floppy disk and boot on it. Since my M6000 was crashed it never tried to read on the floppy.
I tried to reverse the Mv6bv20.ins but a few things were strange to me:
- This firmware was labelled “boot”, but if it’s a bootloader what mecanism is supposed to “read on the floppy and write on the flash?”
- Musictribe told me to write it on floppy and “boot” on it, so there’s must be a bootloader somewhere
- The assembly code of this firmware, shows that a large portion of the code seems to be duplicated at address 0x1001C. Why?
- It’s pretty hard to understand if the memory adressing is 8Bits or 16bits, depending on where you look. Are we in Mode 3 or Mode 4?
I was wondering if the first main program at addres 0x000000 could not be the bootloader and the second one at address 0x1001C the actual main program. But thus, why is not the adress 0x1001C not fitting into a specific block of the 28F800 flash chip?
The answer it that the Mv6bv20.ins binary is not a firmware, it’s a flash tool. When run, this program will write the data at 0x1001C address to the flash chip.
When reading from the PCMCIA SRAM, we’re in 8bits mode adressing, that why our first “main” program (the flash tool) uses 8bits address and the second one (the actual firmware) uses 16bits mode adressing.
Clearly, writing the file (M6bv20.ins) on a floppy disk and inserting it on a faulty M6000 was pointless.