@metadata, looks great, can't wait to have one. Will you be doing a protective case/cover for the CumulusBus? It's no big deal but would add a little polish to it and may help in insertion/removal. There are more important things to be done...

metadata wrote:Here is a little "how-to" connect the Cumulus to the Oric.
The blue side of the IDE-Cable goes to the Cumulus and the black one to the CumulusBus-Controller. The cable will only fit in one direction because of a missing pin in the IDE-Cable. Also the 4-Pin Power/Resetcable fits only in one direction.

The CumulusBus goes in the Expansion-Port of the Oric with the 3 Chips at the top!!!

The Cumulus is powered direkt from the Oric. So you need a powersupply with a little bit more power than the original one. I use a cheap one with 1000mA.

Looks good

I have a question though: The Oric expansion bus has 34 pins, and you use a standard IDE flat cable that 40 pins: Would have it not been possible to pass the power through the unused lines of the IDE cable instead of the separate 4 pin power cable?

The Oric expansion bus has 34 pins, and you use a standard IDE flat cable that 40 pins: Would have it not been possible to pass the power through the unused lines of the IDE cable instead of the separate 4 pin power cable?

as jorodr already said. I don't think there are enought pins free on the IDE-Cable.

Will you be doing a protective case/cover for the CumulusBus? It's no big deal but would add a little polish to it and may help in insertion/removal

Maybe. One problem is the time and another is that there is not really much space free around the board an the Oric. So it is not so easy to design that case.

Hi!
Just a quick update. I'm working on the bootloader at the moment. Trying to find out what's wrong with it. On the picture you can see the updateprocess when it is freezing.
I now have soldered 10 complete cumulusboards ready and a lot of 3d-printed cases.
...here is my code from the bootloader

I'm not familiar with the programming of these things, but some questions:
Are we sure that the size of the files are multiple of 64 bytes?

If I understand correctly, erase_program_verify_page, is the routine that writes data from a 64 bytes buffer to some particular address in 'rom' and then return 0 on error or 1 on success.
What are these 'far rom uint8_t* rom_ptr;' a far pointer to a rom?
Why does this 'i = *rom_ptr;' does?
Is there some delays to respect between the operations?

After quick walk trough code I found obvious case which can lead to program freeze exactly as in attached picture.
Probably the reason is SD-Card read error:
In function 'update_firmware', if 'card_read(sector, sector_buffer)' fails, then execution returns silently to 'main' and sleeps forever without any error message.
So, I suggest to replace: