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.
So, after many attempts and experiments I was able to boot my M6000 and bring it back to life!
Soluce:
Use this procedure if your unit crashes during boot (front panel never turns green + floppy disk drive is never accessed).
For the impatients, here is the soluce (see below for the how and why):
Write the M6bv20.ins on a DOS Formatted (FAT32) floppy disk and rename the file to « dumpfile.bin »
Find a 1MB or 2MB SRAM Flash PCMCIA Type 1 (the SRAM characteristic is essential, a simple PCMCIA flash adapter won’t do the trick)
Find a working M6000 unit (ask a nearby studio, this is litellary a 20 seconds manipulation)
Insert the floppy disk and the PCMCIA card on the working unit (unit is ON)
Go into « Frame > System > Main > Card » and press « Dump binary file to card ». The floppy disk is read and dumpfile.bin is written on the pcmcia flash card.
Now eject the floppy disk and extract the PCMCIA card.
Turn your faulty M6000 off
Set the internal DIP switches to OFF OFF ON ON ON ON ON ON
Insert the PCMCIA card and turn the unit ON
The Front panel led will turn orange then green after a few seconds (around 10s)
Turn the unit off and extract the PCMCIA card
Set the internal DIP switches to their default values: ON ON OFF OFF OFF OFF ON ON
Turn the unit ON
That’s it!
After this procedure, your unit should properly boot (front panel led is green) and access the floppy disk drive during boot. If you still have issues, think about reflashing the main software (write S6KAppl.M6K and m6kboot.ctl on a floppy and boot on it).
I recently purchased a « non working » TC Electronic System 6000, here’s a few notes of what I found while trying to fix it.
The TC Electronic System 6000 is based on two units:
The Mainframe with a floppy disk drive and a PCMCIA slot
The Remote + Icon
In my case, the remote unit works fine: the system boots properly, shows the Windows NT4 splashscreen and then the M6000 GUI.
The Mainframe unit is another story: the front panel is fixed red and.. stays red.
During a normal boot process, it’s supposed to access the floppy disk drive and the LED turns green once the boot is complete.
The Mainframe parts
The mainframe unit contains the following parts:
A power supply
A floppy disk drive
The AES/DSP cartridge
The AD/DA cartridge(s)
A network card
The mainboard
Power supply
The power supply unit delivers +/-5V and +/-20V:
Black / Red 5V
Black / Gray -5,2V
Black / Brown 20,5V
Black / Blue -21V
There’s also two wires connected to the fan (and a temperature probe): red/blue 5V. The potentiometer is probably used to adjust the temperature level triggering the fan.
Motherboard
Taking a look inside the unit shows the following:
the internal DIP switches are in default position: ON ON OFF OFF OFF OFF ON ON
the LEDs are in the following state: ON OFF OFF BLINK
I tried booting without additional units (AD/DA, DSP, floppy disk drive, ethernet card) without success.
I also tried replacing the floppy disk drive with a Gotek floppy to USB emulator. This actually didn’t worked, the floppy drive is still not accessed. Since the Gotek drive has many configuration options it’s hard to tell if it’s normal.
The motherboard hosts:/
H8/3003, 16bits microcontroller
A QuickLogic FPGA
A floppy disk drive controller
Two RAM chips
A Flash chip
As far as I understand the system, the H8 is in charge of the boot process: read from the floppy disk drive (through the floppy disk drive controller) firmware updates. If found, flash the H8 bootloader itself (on the Flash chip) or the FPGA.
The bootloader firmware « M6bv20.ins » seems to contain debug strings, so there’s may be some serial output for debugging purpose.
The schematics shows that the H8 has two serial ports, and following these brings us to the DIN 7 « Remote port » at the back of the unit. The Serial port 1 (Tx0/Tx0) is connected as follow:
pin 2 : GND
pin 3: Tx
pin 4: Rx+
pin 5: Rx-
Moreover, the unused JP3 connector also exhibits the same serial port and really looks like a debug interface:
pin 1 (closest to the board corner): GND
pin 2 : Rx
pin 3: Tx
I used an USB to serial adapter to connect to this port, hoping for a terminal connection (or at least debug strings). Sadly, the port seems to be inactive, at least at this part of the boot process.
Reverse & DIP switches
The motherboard schematics provides interesting information on the DIP switches usage:
DIP #
ON
OFF
1 (sw1A)
Send boot_cs to inernal flash cs (Chip Select)
2 (sw1B)
Send pcmcia_mem_cs to fpga pcm_bus_cs
3 (sw1C)
Send boot_cs to fpga pcm_bus_cs
4 (sw1D)
Send pcmcia_mem_cs to flash cs
5 (sw1E)
Connect H8 MD2 to GND
Put 5V on the H8 MD2
6 (sw1F)
Put 5V on the H8 MD0/MD1
Connect H8 MD0/MD1 to GND
7 (sw1G)
Connect sram_cs to RAM chips CS
Disable external RAM
8 (sw1H)
Connect flash_cs to FLASH
Disable Flash
According the the schematic labels we also learn:
Set switches 1 and 2 to ON for ROM boot
Set switches 3 and 4 to ON for « CARD » boot (pcmcia sram)
Set switches 5 and 6 to ON for 8bits operation (16 bits otherwise)
ROM boot: (1&2)
The switches 1 and 2 are ON by default, which makes sense: the unit is supposed to boot on the ROM. When switch 1 is set to ON, the boot_cs (a signal used to enable/disable a chip, thus select who’s going to read data sent on a bus) is connected to the flash memory cs. The switch 2 connects the pcmcia_mem_cs (again, a signal used to enable access to the PCMCIA) to the FPGA. I guess the FPGA is in charge of driving the PCMCIA.
During boot: read flash memory
After boot, when using PCMCIA: use pcmcia
CARD boot: (3&4)
When set to ON, the 3 and 4 switches enable the CARD boot. Thanks to the 3rd switch, boot_cs signal is sent to the FPGA pcm_bus_cs, which probably propagates this to the PCMCIA slot. During boot, the PCMCIA card is then enabled. The switch 4, connects the pcmcia_mem_cs to the external flash cs, thus when accessing the PCMCIA slot after the boot process, the unit will actually read the external flash.
During boot: read pcmcia
After boot, when using PCMCIA: use external flash
Here I learned something protentially fixing my issue: I suspect the bootloader to be corrupted and thus not accessing the floppy disk drive. If if use CARD boot mode, with a pcmcia sram memory card contaning the boot image (« M6bv20.ins ») raw written on it, I may actually bypass the flash memory issue. I found some technical documentation explaining that the M6bv20.ins should be copied to a floppy disk, then flashed on the SRAM pcmcia using a M5000 unit (« Wizard to disk » tool).
8/16 bits (5&6):
Switches 5 and 6 interacts with the H8/3003 MD0, MD1 and MD3 pins.
Mode 3: Address pins A23 to A0 are enabled, permitting access to a maximum 16-Mbyte address space. The initial bus mode after a reset is 8 bits, with 8-bit access to all areas. If at least one area is designated for 16-bit access in ABWCR, the bus mode switches to 16 bits.
Mode 4: Address pins A23 to A0 are enabled, permitting access to a maximum 16-Mbyte address space. The initial bus mode after a reset is 16 bits, with 16-bit access to all areas. If all areas are designated for 8-bit access in ABWCR, the bus mode switches to 8 bits.
So clearly, these two switches are used to select 8 or 16bits memory addressing, keeping the default position to 16bits (off/off) is a good option since I do not plan to rewrite the whole firmware 🙂
External RAM (7)
When OFF, switch 7 disables the two external RAM chips, thus the H8 CPU can only use its internal memory. Clearly we don’t want this and we’ll let this switch to ON.
External Flash (8)
When OFF, switch OFF disables the Flash chip during flash operations. Again, we don’t want this and we’ll let this switch to ON.
Reverse & JTAG
The J6 connector is a JTAG debug interface, connected to the FPGA. It’s probably used to load the fpga firmware in the factory. Since I don’t have a JTAG probe (and passing sniffing is pointless), it’s currently useless.
Factory setup
As far as I currently understand the motherboard, I suppose that:
the H8 firmware is loaded using the DIP Switch 3&4 and a PCMCIA card with the bootloader firmware written. Thus, the H8 boots properly and is then able to « update » the bootloader using the floppy disk, writing the program on the flash.
the FPGA firmware is loaded using the JTAG interface, probably prior to the H8, since the FPGA seems to be in charge of controlling the floppy disk driver.
Host Bus interface
I used my Salaea probe to watch traffic from the motherboard to the Host Bus Interface card. I didn’t tried to decode the whole traffic, but clearly there’s some.
Flash memory bus
I’m currently trying to scan the accesses to the flash memory bus, hoping it may help me to find what’s going on. The best place to sniff the bus seems to be the Ethernet card: the card shares the BUS with the flash chip, and the connector can easily be used to connect my probes. I’ll have to collect 3 bits lanes for each run and then reassemble, my Salaea is the 4 channel version. 1 channel will be used for the Clock (pin 43) and the 3 others for data.
