tcat wrote:Hi,
<snip>
Provided QPAC is or can be made romable easily. This may fit $E0000-$FFFFF which is 128K.
I was hoping to use either eeprom AM29F010 (128K, 8x16K sectors) or AM29F040(512K, 8x64K sectors). The latter seems still available. Cannot tell how fast these chips are compared to QL ROM.
I believe that the code can be executed from EEPROM, rather than copied to RAM, after it is linked into the system during boot.
Tomas
Ou of interest, there's a few QL programs which help with creating and manipulating EPROM images, such as Jochen Merz's Thing & EPROM Manager and Liberation Software's RPM (Resident Program Manager). The RPM is on the QLiberator page on my website.
AN interesting device a few years ago was the MCS Multirom, which plugged into the EPROM slot at the back of the QL and allowed "soft" EPROM images to be loaded into its memory, so that you could use images of different ROMs. SO that you didn't have to keep physically unplugging ROM cards. See QL Wiki entry https://qlwiki.qlforum.co.uk/doku.php?i ... om&s[]=mcs
Dilwyn - do you know where you can pick up thing and eprom manager - apparently it is in some toolkit, but my previous search for it ended in a dead end.
I did think about seeing if a RAM disk driver could be rewritten as a 'ROM disk' - but then decided that a tool to assemble the ROM disk full of files would also need to be written, and given most of the storage solutions for the QL are solid state now, it seemed a bit futile.
Pr0f wrote:Dilwyn - do you know where you can pick up thing and eprom manager - apparently it is in some toolkit, but my previous search for it ended in a dead end.
As far as I know: this was a toolkit on its own. I have a disk with such a label. We have to ask MK about the status. Perhaps we can make it freeware. But Liberation's RPM works (for EPROM/RAM) in the same way.
T&EM has additional keywords: EPROM_LOAD as far as I remember and an EPROM_TEST to verify, if there is any self modifying code in the Eprom file. That is missing from RPM and would have been important.
I've seen utilities to load eprom file images into RAM and load them as if they were ROM's - but I thought the eprom manager actually allowed you to build and test eprom images, or have I got that wrong?
Pr0f wrote:I've seen utilities to load eprom file images into RAM and load them as if they were ROM's - but I thought the eprom manager actually allowed you to build and test eprom images, or have I got that wrong?
No, that is exactly, what the T&EM from JMS does. You make a command file (like with RPM) and the program genarates a RAM or ROM file. Additionally you can load a ROM file (EPROM_LOAD is just in SMSQ/E not in standard QDOS) and test if there is self modifying code in it.
For RAM files, you can also use the classical "BOOT_MAKE" program from the QRam suite
Pr0f wrote:I've seen utilities to load eprom file images into RAM and load them as if they were ROM's - but I thought the eprom manager actually allowed you to build and test eprom images, or have I got that wrong?
No, that is exactly, what the T&EM from JMS does. You make a command file (like with RPM) and the program genarates a RAM or ROM file. Additionally you can load a ROM file (EPROM_LOAD is just in SMSQ/E not in standard QDOS) and test if there is self modifying code in it.
For RAM files, you can also use the classical "BOOT_MAKE" program from the QRam suite
Excellent - that sounds like exactly what's required.
Some time ago I designed a number of methods to add EPROM (NVRAM, actually) in to the upper 128KB area, allowing for up to 640KB (additional = 768KB total) RAM.
I have placed most of those utilities in that space, including many other DIY TK routines as well - all merged with T & EM (though the DIY TK equivalent utility would have worked as well.)
If you really have to avoid using the expansion port, as I did in one of my designs, you have to resort to some hackery. Doable, but a little bit involved - I'll describe below in case its of interest.
Ultimately, it's FAR easier to go the expansion connector approach, as long as you have one of the various bus-expanders (Dave sold a simple adapter that may meet your needs - not sure if he still has any in stock...)
In my case, I actually use a 512KB SRAM backed-up with a Varta 3.6V cell-pack and a small battery-backup monitoring/Chip Select gating IC, with the top 128KB re-mapped to the right slot in the QL memory map (at 896KB upwards.) The lower 128KB of SRAM is configured to shadow the base 128KB for Reads (Writes pass-through to the DRAM), giving a slight but significant speed increase to the lower 128K of RAM... The remaining (middle) 256KB of the SRAM IC are mapped as RAM, giving 384KB RAM altogether + 128KB for the NV portion. Sounds complicated, but works really nicely and allows for in-band/in-socket re-writing to the NV portion of the SRAM as I was continuously updating the contents! I use one of the spare IO ports of the Hermes (normal or super) to dynamically enable Write access to the upper 128KB of the SRAM (defaults at power-on to Write-protected.)
To keep my expansion port clear, I designed a daughter board that fitted in one of the ROM sockets - capturing the majority of the Address and Data signals needed.
The additional signal lines (RWL, DSMCL, DSL, DTACKL, A16..19) I grabbed from the mainboard via a 10-way (8 needed) IDC cable, soldered to the respective pins of the CPU and ZX8301 on the underside of the mainboard, routing the flat IDC cable up and over via the cut-out by the ROM port, then terminated in a 2x5way IDC plug/connector to the daughter board. Quite tidy, but physically blocks use of the ROM port, which I was not using - you could route the flat cable elsewhere to keep the ROM port clear.
A simple 16v8 GAL does the address/control decoding and generation of (tri-stated) DSCML and DTACKL when addressing the SRAM, making provision for the dynamic write-protection of the upper 128K, using the Hermes IO output to gate the WR line to the SRAM.
If of any interest, I could provide more details via PM. Its not for everyone, so wouldn't want to occupy this thread...
Last edited by martyn_hill on Wed Mar 25, 2020 9:25 pm, edited 1 time in total.
I did a 128K battery backed SRAM with write protection a few years ago, for my own personal use. I'll dig it out. It sounds exactly what you need. If I can find the PCB files, I'll publish them. It used two 628512 to implement 896K, with the top 128K write protectable with a switch. It would stay backed up for about 12-15 years with a CR2032.
I was hoping to use it to map SRAM into $0 to make basic QLs SMSQ/E compatible. Never got there, though.
Thanks for all the input, digesting (1 of 100% complete).
I am also thinking of `venturing' something simple of my own, me capable of.
Looking back at `Simple RAM' these are GAL equations, I pulled together with the help in the forum here.
GAL16V8
Glue logic for 512x8 SRAM
Sinclair QL RAM Expansion
(c)2014 Sinclair QL forum
# control bits set by assembler
# SYN = 1
# AC0 = 1
# AC1(n) = 1,1,1,1,1,1,1,1
#1 2 3 4 5 6 7 8 9 10
1 NC A19 A18 NC /DS NC NC NC GND
0 NC /RAMCE VALID NC /DTACK DSMCL NC NC VCC
#11 12 13 14 15 16 17 18 19 20
# input 1 is wired to VCC
# input 0 is wired to GND
# NC - signal not connected
# / - signal active on low level
# / NOT, + OR, * AND operators
# enables SRAM on VALID memory range and data strobe DS
VALID = A19 * /A18 + /A19 * A18
RAMCE = VALID * DS
# start of our cycle DSMCL goes high, else tristate high impedance
IF( VALID )
DSMCL = 1
# end of our cycle DTACK goes high, else tristate high impedance
IF( VALID * DS )
DTACK = 1
# END
Now this decoding is for expansion RAM, and I wish to add some logic for expansion ROM, so the same GAL controls both RAM and EEPROM. The address could be either $E0000 or $C0000.
EEPROM 29F040 8x64K
am29f040.png (22.34 KiB) Viewed 2239 times
I need help around these lines above.
Many thanks
Tomas
to decode for C0000 address - this is A19 High and A18 High
if you want to get E0000, then you also need to include A17 (high will select E0000 if A19 and A18 are also high)
e.g. VALID_ROM = A19 * A18
or
VALID_ROM = A19 * A18 * A17
then have a CS signal
ROM_CE = VALID_ROM * DS
That's for eprom or flash - if you wanted to use RAM and make it look like a ROM - you would need battery backup and some method of conrtolling Write access to the chip - you would also probably want to include R/W signal for selecting the chip.