Creating an SDCC-based development environment to replace Dynamic C?

I’ve thought a bit about the possibility of creating an alternative development environment for the Rabbits, which steps would need to be taken to get there. These are my thoughts so far: http://www.colecovision.eu/stuff/Rabbitplan.pdf
Assuming You would want to keep devloping for Rabbits (e.g. to upgrade existing Rabbit products with new firmware, etc), do you think this plan makes sense? Are there any obvious (to you, for your use-case) gaps?

It’s an interesting project, but sounds like a lot of effort for limited gain.

You may not be aware that in late 2024 Digi International announced “end of life” (EOL) status for ALL Rabbit products. Customers had until the end of January 2025 to commit to a last-time buy (LTB) and shipping of products is scheduled to complete by the end of 2025. The LTB includes Rabbit 2000, 3000, 4000, and 6000 ICs, limiting the possibility of a third party developing new hardware based on those CPUs.

Having a modern toolchain is interesting, but I feel that most of the value from Dynamic C came from its Open Source libraries. Due to the many quirks (and limitations) of the Dynamic C compiler, I think it would be extremely difficult to create a version of SDCC that could leverage that existing codebase. Seeing a modern TCP/IP stack and mbedTLS running on a Rabbit 6000 using far pointers for everything is an exciting idea, but I think it would be an enormous undertaking for a what’s soon to be a “retro” platform.

I first started using Rabbit products around 2001/2002. I created and sold a product based on the RCM2200, wrote code for companies using Rabbit hardware in their designs, worked on Rabbit products while an employee of Digi International, and have been the sole engineer responsible for supporting the Rabbit products since 2015. It certainly feels like the end of an era.

1 Like

While the new toolchain is most likely too late to save the Rabbits in any way, the current situation also is a bit of a chicken.and.egg problem: as long as Dynamic C is the only viable option for rabbit development, and Digi keeping Dynamic C to themselves, no one else would want to make Rabbits. Maybe the situation would have been different, if there had been an alternative toolchain a few years ago.
Anyway, I think by now we are well-prepared enough for phase I that most of it will be done in less than a year. On the other hand, phase II and III might or might not happen.

Softools created an alternative toolchain over 20 years ago. I’m developing on it right now for a legacy product that needed some upgrades. It produces fantastic code, transparently handles the extended memory in the form of far pointers, and is very, very fast. Unfortunately, the Rabbit people could not see the value in it. It is still available, but with very, very limited support. However, it is so mature, that for most projects, no support is really needed.