t0nyt wrote: Sun Aug 03, 2025 10:47 am
If I configure QL(JS)->512KB->Trump3->QSound/Qprint the Qsound is detected and commands like explode/bell/shoot work fine from QDOS along with Floppies. Haven't tested functionality any deeper than this
If I configure QL(JS)->512KB->Trump3->256KB->QSound/Qprint then the QL halts at a white screen
If I swap the QL ROM to Minerva for this same configuration it halts with a RAM fault
Normally I've used QSound with QIMSI/Microdrive (as I don't have any other non-memory expansion cards with pass-thru) but would just like to understand what's going on please?
Hi.
REASON 1
From what I see... each OS may manage the memory and some IOs ports as it pleases.
The most part of them have common address for some IO devices. Farther than this each OS may have different.
If you get the maps of each ROM (OS) where they expect to manage IO devices or special registers for its own working functions, you would see easily what is happening.
Each device could use some address to do not clash with others in some areas. Those areas may have expected to be "plain" ram for OS or user use, or devices.
When one OS expect to use an specific ADDR to manage a register that it needs, but is occupied for a device that capture any call to that ADDR, then my OS will clash and get in troubles.
You know already that. The only thing you need is the ROM maps with the ADDRs that this ROM (OS) uses for managing devices or its own purpose.
REASON 2
Something like old Sounds cards with PC where we had to configure jumpers and IRQs...
In this point the chain order matters, since the RAM expansion of 256KB may be blocking the access to the next device that try to access to the same ADDR it wants to use or have reserved.
All those devices use to read and/or write in some ADDRs, those are "reserved" or expected to be free by them using jumpers or inner configuration (eg. a GAL structure, mix of OR & AND gates... )
Consequences
Could you "patch" it? probably Yes. you could place the 256KB in a ADDR zone that doesn't clash with the previous device.
Need to avoid overlap address.
Based on what you have exposed:
Case A:
WORKING CASE
QL(JS)->RAMEXPANSION->Trump3->QSound/Qprint
0-128K
______128K-640K
_______________Upper zone with some areas for IO reserved where Trump3 and QSound doesn't clash (wherever they are. they are not the same)
Case B:
FAULTY CASE
QL(JS)->RAMEXPANSION1->Trump3->RAMEXPANSION2>QSound/Qprint
0-128K
______128K-640K
_______________Trumpzonessomwhereinupperzone
_______________#640__________896K
__________________ #QSoundIO
As you can see in this awful diagram (I have not better tool now) the options to clash are too high with that order. Since the second RAM Expansion may hide devices ADDR after it in the chain or even clash with them.
Please to check your ROM MAP and then share it
that way we could study it together and maybe get a solution.
