Source for coldload.bin, pilot.bin?

[digidotcom]

Source for coldload.bin, pilot.bin?

[spth]

On second look, the source for pilot.bin cannot be the one from Dynamic C 10, as the latter uses the jk register pair, which is only available on Rabbit 4000 and above.

[tomlogic]

I'm working on getting the source to these files added to the repository. I've made progress, but want to make sure I can build the exact .bin files with the given source, and that isn't the case at the moment. I believe I have an unreleased version of the Pilot BIOS source code and need to dig through an old code repository to check the history of that file. And I need to update a .cpp program used to create a "triplet" version of the cold loader to take a command-line parameter for the MB0CR/MB1CR value that's currently hard-coded (and that prevents me from getting a correct RAMonlyColdload.bin).

Once I have that working, I will release the source code and build files for the released .bin files, and then release the updated pilot source (assuming the compiled .bin still works).

[tomlogic]

Should be resolved by d939c14. Please take a look and re-open if anything is missing or you can't get the builds to work.

I decided not to bother with the RAMonly files since only someone with custom hardware using RAM on /CS0 instead of a flash chip would need them.

[spth]

Thanks.
I was able to translate COLDLOAD.C to assembler source suitable for the sdasrab assembler (whch comes with SDCC). Though I had to add some instructions manually:

• nop after each call.
• ld a, xpc; push af; pop af; ld xpc, a; ret at the very end

I do not know where those come from in the original COLDLOAD.BIN.

Also, the makecold.cpp file is missing license information. Could you please add that?

P.S.: My short-term goal is to have a minimal free toolchain by making OpenRabbit (https://github.com/spth/OpenRabbit) independent of DynamicC, so it can be used as RFU for programs written using SDCC (http://sdcc.sourceforge.net/). OpenRabbit needs coldboot.bin and pilot.bin, so by including those 2 files in OpenRabbit that goal is achieved.
In the long term it would be good if there was a better alternative toolchain to Dynamic C 9. SDCC has far better standard support and optimizations than Dynamic C 9. But to allow easy porgramming, one would want good on-target debugging (easy to integrate with IDEs such as Code::Blocks). This could be achieved by having OpenOCD and gdb support the Rabbit 2000 / 3000 and ELF/DWARF support in the SDCC Rabbit backend (a similar SDCC/OpenOCD/gdb(Code::Blocks setup works reasonably well for STM8).

coldload.s.gz

[tomlogic]

Hmm. The nop after each call is probably unnecessary, and the result of building COLDLOAD.BIN in a debug mode, where it leaves a nop after each instruction that the debugger can replace with an RST 28 to allow for single stepping code.

And that sequence of bytes at the end isn't necessary. The cold loader for Dynamic C 10 uses a separate "triplets" program that looks for the byte sequence 0x76 0x76 0x76 0x76 and discards everything beyond that. When working to get this source released, I wanted to make sure that the tools would create identical .BIN files to what shipped with the compiler. At one point, I had updated the cold loader source to use the triplets program instead, and it was generating an identical .BIN file except for dropping the unnecessary opcodes at the very end.

I have updated the copyright on makecold.cpp. triplets.cpp from DC 10 is also under MPL, and it isn't difficult to add the appropriate //@ markup to the DC 9 COLDLOAD.C so you can convert the binary with DC 10's "triplets" program instead. I wanted to keep things simpler, so I didn't go down that path.

[tomlogic]

Please open a new issue if having the command-line RFU source would be helpful, and I can advocate for Digi releasing it as Open Source. I personally would like to see a cross-platform version out in the world, possibly rewritten into Python or another tool that has more traction/interest.

[spth]

We already have a cross-platform replacement for the RFU written in C (OpenRabbit provides that functionality since the original 0.0.1 release in June 2004 by Lourens Rozema).

I'm currently working on making OpenRabbit useable 1) on modern systems 2) without Dynamic C:
https://github.com/spth/OpenRabbit

Work is progressing well so far; however, I want to do some testing on hardware before making a release. It would alos be good to get some third-party testing.

[tomlogic]

Please reach out to me if there are ways I can help. You should be able to make use of the libraries and samples provided with Dynamic C now that Digi has released them as Open Source. I would be hard pressed to get them to Open Source the full compiler, but I could probably get some data regarding the assembly opcodes out into the world for people to use in writing a disassembler or in implementing a compiler for the Rabbit 4000 and 6000 opcodes.

My email address is on every commit to the Dynamic C projects. Feel free to email me at any time.

[spth]

Thanks for your offer.

I think a good end goal would be to have a free toolchain replacement for Dynamic C 9 that is equivalent or better in functionality.

The Small Device C Compiler would be the centerpice: It already has a Rabbit backend, that generates faster and smaller code than Dynamic C (I did some microbenchmarks back in 2016 - https://github.com/roybaer/sdcc-wiki/wiki/Z80-code-size - and SDCC has improved further since), and it has good standard compliance.
The Rabbit backend in SDCC will still need some small improvements (such as a larger memory mode to handle an address space > 64 K), but those seem minor.
For an IDE, one could use Code::Blocks, since it already has some SDCC integration.
The Dynamic C libraries could be ported to SDCC.
In the long term, one would want on-target debugging (probably via Rabbit support in OpenOCD - https://sourceforge.net/p/openocd/tickets/278/).

In the short term, we'll just want a useable free toolchain. The first step would be to have a free replacement for the RFU. OpenRabbit is meant to be that, but I'm having a bit of trouble still: spth/OpenRabbit#4; maybe having the source of Digi's RFU could be helpful for reference.
Once OpenRabbit works, it could be polished a little bit further. Then the Rabbit backend in SDCC would be improved: The current model could become a small memory model, with a new medium memory model that has 24-bit functions pointers, using lcall instead of call, etc.

Once all this is in place, there would be a fully free toolchain to replace Dynamic C 9. Rabbit 4000/5000/6000 support to also replace Dynamic C 10 could be looke dinto next.

Aren't all the assembly opcodes already in public documentation anyway? Though there are some corner cases not clear from documentation: https://www.digi.com/support/forum/75782/rabbit-4000-instructions-in-rabbit-3000-mode

I am an SDCC developer and can work on that. But the porting of Dynamic C libraries and OpenOCD support would have to be done by others.