Page 7 of 11
Re: 68K/OS "ROM" based disk attempt
Posted: Mon Jun 03, 2024 9:46 pm
by Pr0f
The original ROM's used by Sinclair are a pair - the "enable" line is active High on the 'top' 16K ROM and active Low on the 'bottom' 32K ROM, regardless of which socket you put them in - they will always work together - this is also why you can piggy back solder them and fit them in only one ROM socket, if you look at the PCB wiring - A15 goes to the chip enable input - hence it selects which ROM - upper or lower is selected - as one is only active when this signal is low, and the other active when it's high. This wiring also means a standard 64K EPROM cannot just be placed in the internal ROM socket - as it expects A15 on pin1, which on the QL is just 5v, hence a carrier board is required.
Re: 68K/OS "ROM" based disk attempt
Posted: Tue Jun 04, 2024 6:33 am
by t0nyt
That helps a lot many thanks Pr0f
It does somewhat limit my options though
It rules out a single 64K EPROM as I don't have a daughterboard and I assume, without some extra logic onboard, it wouldn't give me the 2nd 32K at $C000 (it would be at $8000?). Although 16KB at $C000 would be enough.
It rules out simply fitting 2 separate 32K internally without daughterboards
I can live without the "utility" 32K eprom, but can I just fit a single 32K EPROM internally without any re-wiring/daughterboard for the OS please?
Many thanks
Re: 68K/OS "ROM" based disk attempt
Posted: Tue Jun 04, 2024 8:00 am
by Pr0f
The main issue from memory is that an Eprom has two pins OE and CE - these are both active low (when 0v, they are activated). On the 28 pin socket - the A15 address line is where you would normally find CE - so that will address the Eprom from 00000h to 07FFFh - which is the bottom 32K - no problem there.
The gotcha - the OE pin on the 28 pin socket is active high - that is to say the ROM would be active when this pin is high - this is the exact opposite of what an Eprom chip would expect. There is a relatively cheap solution - using a resistor and mosfet (such as BS170) to invert the logic - but you'd have to work that into either the QL PCB or use a carrier, and if you use a carrier - then why not get one of the breakout boards - leaving your QL PCB intact and giving you 64K of ROM space?
Chr$ sells them I think -
viewtopic.php?t=4437, and may be able to burn you a combined 64K image
Re: 68K/OS "ROM" based disk attempt
Posted: Tue Jun 04, 2024 7:11 pm
by t0nyt
Pr0f wrote: Tue Jun 04, 2024 8:00 am
Chr$ sells them I think and may be able to burn you a combined 64K image
Thanks Pr0f, spoke to Chr$ and he is going to try and make me a board with the OS and 16K utility ROM
If that works ok I'll be able to try and get the floppy driver to work with one of my FDC's
But in the meantime I have an ICE ROM cartridge with a socketed EPROM and I'm wondering if I can make use of this board (not the eprom) for various experiments as I learn more about the QL hardware?
It's a 16K EPROM so am I correct in thinking I can just replace the EPROM with one of my own 16K eproms please?
Many thanks
Re: 68K/OS "ROM" based disk attempt
Posted: Tue Jun 04, 2024 7:28 pm
by Chr$
t0nyt wrote: Tue Jun 04, 2024 7:11 pm
Pr0f wrote: Tue Jun 04, 2024 8:00 am
Chr$ sells them I think and may be able to burn you a combined 64K image
Thanks Pr0f, spoke to Chr$ and he is going to try and make me a board with the OS and 16K utility ROM
If that works ok I'll be able to try and get the floppy driver to work with one of my FDC's
But in the meantime I have an ICE ROM cartridge with a socketed EPROM and I'm wondering if I can make use of this board (not the eprom) for various experiments as I learn more about the QL hardware?
It's a 16K EPROM so am I correct in thinking I can just replace the EPROM with one of my own 16K eproms please?
IMG_3889.jpeg
Many thanks
Yes, you can and whatever is put on that 16k EPROM will appear at C000h, but there will be no way to disable it in case anything else also tries to utilise that area of ROM. You can also modify those boards to take a 64k 27C512 chip and replace the entire internal ROM(s) and have the C000h area for whatever you want.
It looks like this:
Hopefully you can see the cut traces etc.
Re: 68K/OS "ROM" based disk attempt
Posted: Tue Jun 04, 2024 7:36 pm
by t0nyt
Many thanks Chr$
For the time being I’ll just experiment with 16k ROMs, given my soldering history!
As I have the ICE complete in box with MDV and manual it would be a shame to modify and lose it I think
But will keep an eye out for another board to try the mods on
Many thanks
Re: 68K/OS "ROM" based disk attempt
Posted: Tue Jun 04, 2024 10:35 pm
by Pr0f
would be handy to design a ROM port plugin cartidge with a switch or jumpers and a ZIF socket - for just such experiments

Re: 68K/OS "ROM" based disk attempt
Posted: Tue Jun 04, 2024 10:38 pm
by Pr0f
It also makes me wonder if the 68K/OS can potentially access ROM disks at other possible ROM locations - such as at 10000 or 14000, or in the top 256K of space - from 0C0000h onwards.
Obviously dependant on any expansion cards or GC or SGC being present.
Re: 68K/OS "ROM" based disk attempt
Posted: Tue Jun 04, 2024 11:02 pm
by Chr$
Pr0f wrote: Tue Jun 04, 2024 10:35 pm
would be handy to design a ROM port plugin cartidge with a switch or jumpers and a ZIF socket - for just such experiments
I did, but when I ordered a few slot connectors of the right size (as a passthrough for QIMSI) they never came! They don't seem to be available in the right size and I haven't yet looked into buying longer ones to cut up.... was going to modify a PC ISA slot connector to experiment with.
Re: 68K/OS "ROM" based disk attempt
Posted: Wed Jun 05, 2024 5:14 am
by M68008
t0nyt wrote: Sun Jun 02, 2024 6:02 pm
You can't do anything that needs the Microdrives as Q-emuLator doesn't support the 68K/OS MD format yet (but I believe Daniele is working on that from a logic capture of my drive)
Yes, I have a prototype that allows 68K/OS to access the microdrive:
Still thinking about the mdv image format, it's ... complicated.
I've also noticed that the ICL OPD microdrive cartridges have a sub-byte space between block header and sector data, so I wonder whether a byte-based representation would work well for them.