The Sinclair QL Forum

Regarding flash programming:
Most (not all, there are read while program chips, but prices are high and there are other limitations) flash chips cannot be read while in program mode. Hence, your approach depends on the need to execute code from the same flash chip. If not, then you have to be sure you can get to the data to program the flash with (pre-load in RAM?) and the flash programming code must be completely independent of anything in that flash chip, and then there is the concern if you have anything to return to after programming, or the system should be re-booted.
If code needs to be executed from the flash, re-programming is a 'blind alley', i.e. after the flash is programmed, there MUST be a re-boot.
Here is an example: if you are using the flash to store code which is later going to be loaded into RAM and executed from there, but the flash is still accessible at some address, then programming with the OS is possible, it can even be a basic program. Of course, you have to take precautions that you do not brick the machine on re-boot, perhaps by retaining a default OS for recovery and offering a jumper (or similar) that maps this to the appropriate address at power-up, so the machine can be un-bricked. Having a basic command to do the programming is certainly possible under these conditions. Timing is no problem as the chip offers a busy signal which can be timed in a loop for the required 'overprogram', even if the timing ends up longer, at worst the programming will not be optimally fast, which I would not consider a problem. Additionally, the simplest programming method is usually supported by all manner of flash chips, it is not the fastest possible but it will always work.
The remaining problem is the initial programming. So, either the chip needs to be programmed with he default OS (which may include the programming command) off board, or, which I would consider a better option, how about making an adapter which disables the on-board CPU and then the board is connected to another machine. Since flash unlock and program is a series of normal reads and writes to the flash location, this should not be too difficult.

Relevant aside: the SGC copies the QL ROM and parts of it's own ROM into shadow RAM at the same addresses, and then runs everything from the copy. The QL ROM and ROM slot are still accessible at $400000 (not sure about the SGC ROM though...) BUT it is read only, SGC does not generate write cycles to the QL bus for those addresses. Why of why??? Enabling write would do no harm as the motherboard select logic simply ignores writes, but something like Aurora could have used it for flash writing (not to mention a writable ROM port...)

@Dave, since you are using a FSM for writes to the QL bus, why not use it for reads too, and then just run the QL side at 7-5MHz, while the CPU side can always work at 30MHz?

I would suggest forcing a system restart after programming the flash.

If you've changed base OS code - you want to ensure you re read it again.

As others have pointed out - even if your flashing routine was in RAM memory, and you made the whole process atomic with no interruptions or other programs able to access the machine or interrupt your flash process - it would be interdeterminate if resumed.

Perhaps a better solution would be to boot into a special piece of code - specifically for flashing - the down side - you potentially lose access to drivers and other code that can provide you with access to your new code that you want to flash, but it would not be too dificult to boot into a small monitor program that can read/write S Records from a serial port.

If you wanted to read / write from a QL file system, then you'd need to use an approach similar to QEP III - reserve some RAM to store your ROM image into, then go into a quiesced state (no interrupts, no jobs running, etc) then flash your code

Finish up with a verification of the code and a reboot.

Pr0f wrote: Mon Sep 15, 2025 5:10 pmIf you wanted to read / write from a QL file system, then you'd need to use an approach similar to QEP III - reserve some RAM to store your ROM image into, then go into a quiesced state (no interrupts, no jobs running, etc) then flash your code

QEP III is able to multitask via "EPROM_M".

RalfR wrote: Mon Sep 15, 2025 5:18 pm

Pr0f wrote: Mon Sep 15, 2025 5:10 pmIf you wanted to read / write from a QL file system, then you'd need to use an approach similar to QEP III - reserve some RAM to store your ROM image into, then go into a quiesced state (no interrupts, no jobs running, etc) then flash your code

QEP III is able to multitask via "EPROM_M".

Perhaps I wasn't clear in my post - it was the concept of reserving some workspace in which you can store / maybe even edit your code that you intend to flash - before turning off access to the rest of the machine.

The combination of responses here leads me to keep it simple and have the code erase, write and verify, then trigger a reboot or reset.

I have group emailed the maintainers of Minerva and SMSQ/E in the hope of a final go-ahead with my scheme here. The hardware is settled, with room for one more proto order before the dev boards are made in about six weeks. The programmable logic has a JTAG port and is updatable. A bit above most people's pay grade though. I would like to grasp the mechanism used to shadow one or two screen areas, room for optimisation.

The current memory map is:
Q68 compatible ports may move to the IO area.
128K to 192K writes passed thru to QL and shadow RAM. Reads from shadow RAM only.

May contain errors. If you see one, please let me know. Banana for scale.