The Sinclair QL Forum

ppe wrote:

tofro wrote:The software part is more interesting. I don't know if any other device drivers have been written in C on the QL but it's been quite a ride.

I got one here and am doing the same thing (Writing a file system driver in C)

I think I can help if problems arise.

ppe wrote:I'm hoping to have the energy to also write some blog posts about some of the gotchas I ran into on the way. Perhaps documenting some of the (for me) trickier parts may be interesting to future code archaeologists.

You can never have too much good documentation. And anything that exposes "foibles" in a device, etc, can only be a good thing -- and will help anyone doing similar stuff.

Cheers,
Norm.

ppe wrote:Actually, in the case of W5300, one should talk about a "TCP/UDP controller" rather than an "ethernet controller".

That's to the point. And I think in terms of memory footprint and practicability, offloading TCP/UDP to a different CPU has the edge.
Using an ethernet controller directly was more or less a "philosophical" decision - my stubbornness wanting as much as possible on the 68K side.

ppe wrote:I don't know if any other device drivers have been written in C on the QL but it's been quite a ride.

I wrote the first working QL-SD driver (derived from QL-HD and never released) in C, but with an ancient K&R style compiler named PDQC.
Also recently my simple PS/2 mouse driver for Q68 Minerva, where I'm stuck with C68 bugs regarding TRAP #3. Since it is only needed for a safety check, I want to release the code without that check, if I fail to find the time to debug it.

Good luck and it's nice seeing your project! I think you're doing a fantastic job!

Peter wrote:I wrote the first working QL-SD driver (derived from QL-HD and never released) in C, but with an ancient K&R style compiler named PDQC.
Also recently my simple PS/2 mouse driver for Q68 Minerva, where I'm stuck with C68 bugs regarding TRAP #3.

Ah, group therapy feels so good! I was also struggling with some of the TRAP #3 stuff, plus memory allocation library calls being quite borked. The struggle is real... qdos-gcc to the rescue. Unfortunately, the libraries still seem to come from the C68 distribution but at least the optimiser works plus there's a functioning inline "asm" directive which makes it easier to work around some of the more ....ahem... "interesting" parts.

Peter wrote:Good luck and it's nice seeing your project! I think you're doing a fantastic job!

Thank you for your extremely kind words, Peter!

ppe wrote:The struggle is real... qdos-gcc to the rescue. Unfortunately, the libraries still seem to come from the C68 distribution but at least the optimiser works plus there's a functioning inline "asm" directive which makes it easier to work around some of the more ....ahem... "interesting" parts.

True, but as someone who worked a lot with qdos-gcc I found my share of pain there as well, e.g. macro related bugs. Overall, I find C68 slightly more reliable.