The Sinclair QL Forum

...

"Pure" programs are programs that can be started through the Hotkey System multiple times and can share the same instance of code, but have a private data space - They have basically the same restrictions as ROMable code.

...

"Impure" programs are in no way any "worse" than "Pure" ones ...

The question is: Has these (available) options from C68 been tested in the QDOS version of C68. They are not used in the libraries delivered with C68 (and so the code is not tested). Lattice was the most famous compiler at tits time, (Atari, Amiga, DOS, embedded, ...) and so it's reentrant ...

I'm actually not getting why you haven't replaced IC21 that you have (IMHO) identified as faulty in post 67. It is possible, but very unlikely, that the B side is completely grounded by defective RAM chips.

Well that hasn't had the effect I was hoping for, it hasn't sorted it but at least I know I am turning the interrupts off
correctly now and I can rule that out.

Strangely, when I read and print the contents of the interrupt register directly after setting it to 0x1F
and before the emulator ...

like this...

ps_write_8(0x18021, 0xFF); // Mask off all interrupt sources
ps_read_8(0x18021); // clear any pending interrupts by reading interrupt register?

I'm pretty sure it isn't right. :D


To clear all interrupts, you need to write the lower 4 bits with 1 (for gap=0, interface=1, transmit ...

The first 2 yellow blips are me trying to mask all interrupts and clear any pending interrupts before the main
execution loop of the emulator. The solid yellow is JS booting up. For a single moment IPL1 goes High ie. no interrupts
and IPL_ZERO also follows but IPL1 immediately goes low again ...

Even if the C68 options to produce reentrant code are working, you can write functions, which you can call from assembler. But you cannot even write the "hello world" program from Kernighan & Ritchie, cause this uses printf(), which is in the standard library which is not reentrant.


Well, the ...

My Reflection toolkit does not currently load any system extensions, just S(uper)BASIC FuNctions and PROCedures. It's practical to LRESPR them in a MultiBASIC job when developping. If you change something you can kill the MultiBASIC job, start another MultiBASIC, LRESPR the new version and test it ...

You would not normally use libc in romable programs anyway. Libc is not re-entrant and also relies on global state. This is true no matter the compiler.


Well sort of. I have no problems whatsoever to use memcpy() or most string functions in code intended for a ROM - Most of them are fully re ...

Replacing the front plate with a black PCB might be another approach.

Once you have the design, you could also have a PCB (no copper traces at all) manufactured by one of them Chinese factories for little money, they make them in black with white print. Should make a perfect replacement.