Some Ideas to discuss.

[f0m3]

Hey, thanks for your work (which i dont understand to the last detail since i am a noob).
I had an idea and would like to hear your thoughts about it.
Do you think, it would be possible to use the fcb1010 internal processor only as a kind of gateway that listens to commands from a serial bus and sends commands to it? Maybe one could use pins of the eeprom for that. Then it would be possible to attach an ESP or arduino and use the great webui of e.g. pedalinomini to configurate it in any way one needs without removing all the logicboard and replacing it with something else (like infinity FCB)
From that base it would be easy for a lot of people that dont know about programming embedded circuits because they could use arduino.
Maybe you can tell your thoughts about this...

[jspyve]

Hi,

Thanks for your comments. I'm not completely sure I understand what you want to do here, and I'm not familiar with PedalinoMini at all, although I did briefly look it up.

What actual function would the FCB1010 be taking on in this scenario? Just a dumb pedalboard with the switches and pedals being inputs to PedalinoMini, which is then doing it's usual control stuff?

Do you want to go further, and be able to arbitrarily turn FCB1010's LEDs on and off in response to commands, or display information on the 7-segment displays?

Or are you wanting to use a richer web UI of another product to effectively setup the FCB1010?

Or something else?

In terms of the FCB1010 hardware, really, unless you are going to start removing unnecessary items from the PCB, eg. as you suggest, the settings EEPROM, or maybe trying to solder wires onto the couple of pins spare on the CPU, you only really have the actual MIDI ports to transfer any information to eg. an Arduino.

Any hardware modifications you make to the FCB1010 are going to result in it needing custom embedded firmware. The library code I have published here, basically covers accessing all of the FCB1010 hardware, so could be used to develop an entirely new set of functionality, with eg. a command parser that allows turning LEDs on and off, writing to the 7 segment display, having events sent when pedals are pressed or moved. But someone would need to develop that code.

The FCB1010 was designed around an 8032 microcontroller, with program code on an external one-time-programmable EPROM. It's not an easy platform to develop for, compared with an Arduino or anything modern, with FLASH code storage. It's old-school, and as it stands, you either need, an EPROM emulator, an EPROM programmer, windowed EPROM, and EPROM eraser, or do what I did, and remove the existing CPU, replace it with a more modern 8032 variant with FLASH and a bootloader, and use that with a USB to serial cable.

You'll learn a lot about true embedded programming from working on this platform, but it's pretty raw and unforgiving. At least the software development tools are free, which is not something that was always true for the 8032/8051 platform.

Jon

[practicalusage]

Hi f0M3,
Hi Jon,

I have worked a lot with the FCB1010 in the past. Take a look at www.practicalusage.com. I still own many of them...

I agree with Jon that developing anything for the existing FCB1010 processor is complicated. I ended up replacing the electronics with Arduino microcontrollers (and the extended Arduino family). But in the end, I just restored my FCB1010 as a dumb midi pedalboard because it's solid and reliable. But I do connect the FCB to an arduino ESP32 now, similar to what PedaloniMini is using.

I have designed a simple (Web) interface on the ESP32 that uses input (Midi commands) from the FCB1010 to modify the parameters stored on the ESP32. Programming on the ESP32 is a joy, using the standard Arduino interface (or Platform IO like the PedaloniMini is doing). This way, I use an iPad of laptop to display all the parameters that I need.

Is that what you are trying to do?

[f0m3]

Thank you both for your work and your very long answers!
Yes, practicalusage and jon, you are right, i want an interface thats accessable with a browser via wifi to configure whati s sent from FCB1010 to any midi interface (or midi over wifi) and that makes it more comfortable to configure than an FCB UNO.
But i do understand, that it is not that easy because of the more historical aproach of behringers used processor/eprom combination :-)
@practicalusage can i see what you did with an ESP32?

[jspyve]

If programming a mostly stock FCB1010 via a more appropriate interface is what you really want to do, you could always consider just using the external UI to build up a sysex dump for the FCB and then have it download it to the FCB via the midi ports. I’m not sure how well documented this is in the FCB manual, as I’ve never really looked, but eg. information is available:

https://c3.zzounds.com/media/FCB1010_SysEx_Structure-2c6634e4d8b813c58d175d05a0def4d2.pdf

Jon

[dub1504]

Hi Jon,

I looked at your code and it all makes sense. I've already developed quite a few MIDI controllers based on STM32.
That would also bring USB and possibly BlueTooth functionality. Also we;ll have around 1MBytes of EEPROM to store config and Sysex commands, etc.. etc.
So the plan would be to hool STM32 to FCB1010 PCB instead of current MCU same as you did.

I can easily convert it to use FCB1010 Peripherals if I could find the spec or description of what PINS on current FCB1010 MCU are connected to what peripherals (E.g. P1.x to SW1, P2.x LED1 etc, etc).
I've tried to look into your code but only managed to decipher few.
Can you help with that. Once I hook it on and test it will share it with you.
Also if you have original schematic of FCB1010 that can help too.

Cheers

Dub Bartolec
Sydney, Australia

[jspyve]

Hi Dub,

Unfortunately, it isn't quite that straightforward. The FCB1010 is pretty representative of a typical 8051-type design which uses external EEPROM and RAM chips. Most of the actual pins are dedicated to a multiplexed address/data bus, leaving few I/O pins for actual peripheral use.

Instead, the designs end up memory-mapping external latches, via additional address decoding logic, to provide the peripheral functions they need. This is all completely design-specific, and the only way to describe it fully, is via an actual schematic, or, as an alternative, some source code that exercises it all. For me to try and describe it all just isn't going to cut it, not to mention, will be a monumental effort to put together.

With a modern STM32 design, you generally have the benefit of a lot of I/O pins, and internal memory, so you simply don't have to deal with the same constraints the designers of the FCB1010 had when they put this thing together. You would naturally just connect everything up directly.

The stuff I can easily describe:

T0 (pin 16) Serial CLK for IC12A (pedals ADC), IC6 (EEPROM)
T1 (pin 17) Serial Data SDA, for IC6
P1.0 (pin 2) /CS for IC12A
P1.1 (pin 3) DO for IC12A
P1.2 (pin 4) DI for IC12A
P1.5 (pin 7) Row 1 multiplex for switches
P1.6 (pin 8) Row 2 multiplex for switches
TXD (Pin 13) Midi port TX data
RXD (Pin 11) Midi port RX data

P0 and P2 are used in standard form for the multiplexed data/address bus, to the external memory and memory-mapped peripheral logic, along with /EA, /PSEN, ALE, /RD, /WR

If you look at hardware.h, you will see that the memory mapped peripherals are decoded in a group of 8 at hardware address 0x1ff8 onwards, with only some of the addresses having an actual function. Hence, the extern volatile XDATA __at (HW_BASE) uint8_t PERIPHERALS[]; array, is actually a memory mapped array onto the significant hardware addresses involved.

The WRITE_PERIPHERAL(p, v) macro is used to correctly manipulate the address decoder output, to provide a brief latching clock pulse to the latches involved. The PERIPHERAL_DUMMY_MUX address is used as a "park" position on the external address decoder, when nothing is being accessed, and to prevent spurious clock pulses being generated as different peripherals are selected.

I would accept that what you really need, is a schematic, which would be quicker to understand than the code.

All the best,

Jon

[dub1504]

Hi Jon,

Thanks for very technical and to a point explanation. Yes I can see now where the complexity is.
I might be able to read

ADC (READ)
MIDI (READ/WRITE)
Decode switches.
I need to find out if I can do something with leds.
In fact more I think about it it is easier to remove entire MCU board and wire in STM32 that talks to Pedals, switches, LEDs and perhaps get rid of segment display and replace it with small 20x4 LCD. Once I do all this I might as well move pedals to different enclosure and use smaller pedal switches and have smaller pedal overall.

I've done similar based on Rocktron All Access device. Basically remove all internals and only used switches and LEDs.

Pitty as I actually like FCB1010. I could get it to do everything I ever needed by using stock EPROM.
Only thing I don't like about it as there is no way to set its LEDs via CC or Sysex to actually reflect the status of device it controls.

Thanks again for your help.

[jspyve]

Hi Dub,

If you don't want to have to rip everything out, you can still interface with what's there, you would need to use STM32 I/O pins to emulate the 8051 bus cycle of accessing external memory, using /EA, ALE, /PSEN, /WR, /RD and P0.0 - P0.7 to simulate the 8051 multiplexed address/data bus (D0-D7 are multiplexed with A0-A7) as well as the upper address lines A8-A15.

It would work something like this:

Tie /EA, /RD, /PSEN to +5v (ie. logic 1)
Tie P2.0 - P2.7 to 0v (ie. logic 0) These are the A8-A15 address lines

Use STM32 I/O pins for ALE, /WR and P0.0-P0.7

Initial condition:

ALE = 0
/WR = 1
P0.0 - P0.7 = 0

Then, to write data to the external latches that control the LEDs, switch matrix decoding, relays (per my hardware.h addresses mentioned earlier)

Address phase:

ALE = 0
[Put binary representation of external address decoder index on P0.0 - P0.7. Only P0.0-P0.2 are actually significant here, indexes are those as used in hardware.h]
ALE = 1 (latches address bits)
ALE = 0

Data phase:

[Put binary representation of data to write on P0.0-P0.7]
/WR = 0 (address decoder outputs become valid, selected output will become active low)
/WR = 1 (address decoder outputs become invalid, all outputs will become active high)

You might want to verify the general behaviour of the 8051 ports when being used for external RAM access, which is effectively what accessing this external address decoder actually behaves like.

address decoder indexes 0 (LED common anodes), 1 (LED common cathodes), and 5 (relays, switch columns) are used to latch the data bus into 74HC273 latches, via a low-high transition

address decoder indexes 6 (LED common anodes / & common cathodes) and 7 (relays & switch columns), are used as resets for the respective latches, to ensure a known output. These are active low, so the latches get reset when the respective address decoder output is activated, ie. /WR = 0 with the appropriate address decoder index.

I think I've captured all the various transitions. You therefore control the LED segments and individual LEDs, via X/Y matrixing via index 0 and index 1 of the address decoder. And you check the switches, by setting one of the bits in index 5, and reading P1.5 and P1.6 to see which of the 2 rows are set. Bits 0 & 1 actually control the relays, the higher 5 bits are the switch matrix.

You can't read back any of this state from the latches, they are write only.

This might all seem like a load of extra work, vs. just ripping the guts out. Or it might seem like an interesting approach!

The code might start to make a bit more sense in places now. In my code, the switches are read and debounced in the timer ISR, and "scan codes" are posted into a buffer for reading by the main loop. The LED data is also written from the timer ISR, derived from an in-memory "display buffer".

Hope this helps.

Jon