TODO list cleaning continues today…
- Figured out what was broken with Neko the Replicat on my machine. In the end no code changes were needed. Made a Git repository with the sources for all 4 unown versions, and my cleanup changes added
- Sent my patches to the vbcc compiler adding an u'nSP CPU backend (for the VTech VSmile to the main developer
- Updated Haiku package of SDCC to the latest version and now recompiling fatfs with it for the UNIDOS FAT driver
SDCC introduced a new calling convention (back in 2022, this is an old TODO list item…) which finally allows passing parameters in registers instead of the stack. I expect this will help a lot with the code size and maybe speed of the FAT filesystem. However I have no compatible hardware to test with, so I'll have to first finish debugging the X-Mass plugin for ACE…
I have built the new SDCC and it seems to be working fine. Then I decided to have a look at updating Contiki for CPC to use it. Contiki is a small operating system that needs relocatable executables. These are done with a patch to SDCC and the patch isn't quite working anymore. Trying to find my way around in sdcc linker and it's "intel hex" writing code now…
I did not manage to convince sdcc buildsystem to compile the linker in debug mode so I can trace through it.
Ok, after sleeping over it, it's a bit clearer…
- Located and removed a "strip" in the install process (but I will put the debuginfo in a separate package, so the main package is still small)
- Replaced -ggdb with -gdwarf-3 which plays nicer with Haiku debugger
Rebuilding it all again…
Debugging was useful! It seems SDCC switched to 24-bit addresses internally for the z80 port, this needed a small fix in the relocation patch.
And now it's crashing somewhere else in the Contiki build. Hopefully I can cherry-pick some patches from the SVN? Or should I just wait for SDCC 4.3 to be released? I saw it will use undocumented opcodes (optionally) to generate better code, that may be useful
Patch is cherry picked and Contiki is compiled. Now I have to uhdate all the assembler code to use the new calling convention. But first, it's weekly bike ride time!
#TodaysBikeRide
Nice weather, sunny but not too hot, blooming flowers. Much more enjoyable than riding in the winter!
The unremarkable office building in one of the pictures is where I used to work for 5 years. We moved down the street ~a year ago and it's being demolished now to make space for an above-ground subway extension. So here's a picture of it before it's gone.I won't really miss it, it had awful thermal isolation (walls built of metal sheets and single pane glass).
Ok, so I fixed the disk io functions and the Desktop is loaded. Now trying to get "conio" working to display something. So far I have broken icons and lines of the wrong lnegth (which is not a bad start, the initial "clear screen" is setting the correct colors already)
I'm adding some "preserves_regs" declarations to asm functions and that helps removing some push/pops to save registers, code is almost readable but still not great… need more max_alloc_per_node but then it's slow to build :(
It would be ok with a normal program (rebuilding just one file) but the way apps call into Contiki kernel means all apps must be rebuilt for pretty much every change. Maybe I should look closer at implementing the interface between apps and kernel with an RST and/or a jumptable? But I don't want to get into that while I don't have the system running
Got it almost working, some hroblems remain with the "clear rect" function and the keyboard input. But it's time to sleep now, so I'll lookeinto it tomorrow.
As an effort to better keep track of things I do, this oebug session is now also available as a blogpost: https://pulkomandy.tk/_/_Hacks%20and%20stuff/_Keeping%20Contiki%201.x%20alive
Ok, the "clear rect" thing was a stupid mistake from me, and the keyboard was due to trying to use sdcc provided isprint function. Now it's mostly working and I have pretty much exactly 1K more free RAM than with the previous versions, not bad!
However, the "directory" app is not showing the disc directory, so still one thing to fix…
I'm annoyed. The compiler is now generating undocumented opcodes (the z80 has a few of these which do reasonable things and end up being quite helpful). But the assembler says "no, you didn't allow me to assemble these". There's supposed to be a command line switch and assembler directive to allow these instructions, but it doesn't exist in the latest released version. Do the assembler and compiler really disagree on the default? Why did no one else notice?
Here is a screenshot for people who have no idea what I'm talking about in this thread
It's all running fine now. I still have to move the code out of Githib and push the new version and upload a new DSK file for everyone to enjoy. And then, I guess, move on to the next project and visit this again in 10 years?
Let's see if I can get this running from ROM… the modifications to the linker script are simple enough and if it works, that's 16K more free RAM for apps. But I guess it will just crash at boot!
Well… managed to move some, but not all of the code to C000. If I understand the manual correctly, sections should be put after the previous one, but that doesn't seem to be the case, instead only the code section is moved when I set an address for it.
Also, I have to figure out how to not generate 48K of empty space before the start of the ROM in the output file…
Ok, it's running from ROM now. There are some gliches (writes in the C000 area where there should be only read-only data) during startup, then it seems to work OK except the desktop icons are missing? But the apps are added in the menu, and other icons elsewhere work just fine :/ so I don't know why this would happen