archive.worldofdragon.org

Having just read a brief bit off the FUZIX post, gcc6809 was mentioned and having just built (I think!) a working copy of this I wanted to solict people's thought on the state of this project and if I'm going about things the right way or am missing something.

The "original" patch I downloaded & I think built back in 2010 from https://code.google.com/p/gcc6809/ but didn't really do anything much with. Since then I've upgraded to x64 Linux and it doesn't build. However I have tracked down this patch which uses lwtools as the backend assembler/linker and that seems to have worked out ok.

Now the murky bit, building a C-RTL. The original gcc6809 project mentions (but doesn't go into any real specifics) that a build of newlib 1.15 has been patched to work but it's not well tested. I've taken a bash at building this and have produced something - which to be fair I've not yet tried out. It throws up a few internal compiler errors when building some of the exotic floating point stuff but to be honest I doubt I'll be going anywhere near that so have just commented out the offending items. The original patch suggests it builds for either a 6809 simulator or the coco but given that there are no instructions on how to do this I suspect I've built the simulator version but shouldn't be too hard to either hack to work with a CoCo/Dragon given that it's only really providing console output.

So thus far I've built (but not tested) ye olde "hello world" program. I've compiled with gcc-6809 but done the linking with lwlink to give me a DEC binary which I plan to use DWLOAD to try out initially on Xroar.

I will be playing some more with this but just wondered if anyone else gone down this road at all?

It's possibly not going to be of much use to you, but I had a play with gcc6809 some years ago to experiment with a system that had no OS, just a monitor ROM. I ended up making my own crt0 and I think I scavenged functions like printf from Small C.

Using newlib would be a smarter way to go, but I've attached some files anyway as the functions that make ROM calls may be of interest.

Jon, note that the homepage for LWTOOLS and the gcc patch (which is the newest I have found) is at http://lwtools.projects.l-w.ca/ and forget about Gene's link. Also that the 64-bit build is known to be broken. I went 64-bit Linux myself last week for the first time, and installed the 32-bit gcc build and all the necessary :i386 library dependencies.

So you want to make a libc that hooks into the BASIC ROM? Otherwise I would encourage you to help out building the libraries for FUZIX

Another community having worked on gcc-6809 and C libraries is the enthusiasts around the French Thomson home computers:
http://forum.system-cfg.com/viewtopic.php?f=25&t=5641
http://nostalgies.thomsonistes.org/developpement.html

William (LWTOOLS) told me that he worked on the 6809 gcc patch explicitly to make it build on 64-bit, so that warning I gave seems obsolete. In fact I rebuilt it all last night on 64-bit and it builds FUZIX fine.

For anyone on Debian or Ubuntu, I made some .deb packages out of it (also the 32-bit version). They are not proper Debian packages, in particular they install to /usr/local but having it packaged make it much easier to install/remove/update. http://toolshed.sourceforge.net/gcc/ They run on Ubuntu 14.04 and newer and any recent Debian (these binaries need libmpc3 which is not in Ubuntu 12.04 or Debian squeeze).

UPDATE: Also added a 32-bit version for Ubuntu 12.04 or similar (using libmpc2).

Thanks for the info and pointers.

Jon, note that the homepage for LWTOOLS and the gcc patch (which is the newest I have found) is at http://lwtools.projects.l-w.ca/ and forget about Gene's link. Also that the 64-bit build is known to be broken. I went 64-bit Linux myself last week for the first time, and installed the 32-bit gcc build and all the necessary :i386 library dependencies.

Interestingly I'd not bumped into anything immediately obvious with the 64-bit build I put together using the patch from Gene's page either but then I've hardly used the thing in anger yet. I'll see how I get on and maybe switch to your builds if I run into problems (I remain on 12.04 so would have to build from scratch again anyway).

So you want to make a libc that hooks into the BASIC ROM? Otherwise I would encourage you to help out building the libraries for FUZIX

The former is my initial (such as it is plan) although I think I really need are the self contained bits of the library - the interaction with the BASIC ROM would be very minimal (stdin,stdout probably) such that I could readily switch into 64K map mode if needed. Some sort of heap would probably be useful as well although not essential. I managed to download and run my "hello world" successfully yesterday using DWLOAD/XRoar so that's a good start.

The FUZIX project does look interesting (I was reading the discussion about it on the CoCo list yesterday) but I probably don't have the time (or the low level innards of Linux experience) to be able to contribute. Given that the kernel is 40kbytes+ it would seem that realistically you would need a machine with >64K RAM fit to start making any real use of it once some userland apps start to appear. That means expanding the machine and having spent a good many years augmenting my original D64 with extra hardware/RAM disks etc. the appeal to do something similar again probably isn't there any more, I quite like the idea of going back to basics and see what can still be done with the just the original hardware. That said I noted on your screenshot of FUZIX booting you had 160K RAM being reported so would be interested to at least read about how the additional memory is being paged in. I have 3 banks of 128K SRAMS which I may yet be tempted to put back into service if it's not too much of an overly complicated project.

Rgs,

Jon.

Also make sure you use lwtools from hg or the upcoming 4.11. There is a index d,s bug that was fixed after the 4.10 release and which kicks in by the gcc generated code in some cases.

In my case, the original hardware is a Dragon 32, so I need to cheat by adding memory For the 160 KB, I have hacked together a 128 KB SRAM cartridge (based
on my 32KB one). It has 4 banks of 32KB that can be mapped in at 8000-FEFF. The CPLD used for address decoding and map type tracking also holds a little latch for bank selection.

Otherwise, the FUZIX kernel needs less than 32KB of RAM, so there is 32KB available for applications on a stock Dragon 64. But then some kernel code must sit in ROM (maybe a ROM cartridge will be enough). If you have a fast swapping device (maybe a Glenside IDE interface would work well), that's enough for some use, since usually only one task will be active and the others can be swapped out. Of course, swapping to DriveWire should work as well, although possibly painfully slow.

I used your PPA for my lwtools & I saw earlier on the CoCo list that they have just released 4.11 so I assume you'll be updating this in the near future?

Looks like I may have a use for my spare SRAMs then Will the design/code for paging in this additional memory be released & become part of the FUZIX kernel?

Yes, as you probably saw the PPA was updated the same day The description of the "nx32" memory cartridge is in the FUZIX repo, see the Kernel/platform-dragon-nx32/README file.

Yes, I picked the update soon after. I see you've been busy with FUZIX again, I do intend to build this at some point...

I'm guessing the gcc-6809 port is reasonable stable now then? I've been distracted with other things recently but the last time I played with the newlib C-RTL port, my heap was ending up in the middle of the screen memory The 6809 specific sbrk call looked ok and indeed PEEKing the relevant memory addresses afterwards seem to show that it was setting the heap up correctly iaw the settings in the linker. The underlying malloc code is a bit of a mare to read through but even those variables I could track down looked sensible. I was reluctantly concluding that something had been mis-compiled somewhere but your efforts on FUZIX seem to suggest the compiler is pretty good.

I also had a look at using Stewart's port of GDB with the codebase but am I correct in thinking this is limited to 6809 disassembly ie. I couldn't find an obvious way for it to load the symbols from my binary, it not being in ELF or another recognized format.