The Sinclair QL Forum

Not expecting to find a solution to this, would just like to understand, as much as possible, if this is purely down to an address clash please?

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?

Many thanks
Tony

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.

Many thanks for the comprehensive reply Popopo

I don't really want to "patch" anything, was just trying to confirm it must be a clash

Which you have confirmed for me thank you!

I don't really need to be running 896KB, except for the problem where lowering the memory in the Trump card (to 128/256/384) via software reset, as per other thread, is knocking the Trump Mini 3 "offline" for want of a better term

I'll have to settle for swapping the 256kb board and Qsound board as needed

Many thanks
Tony

You are welcome

Please to keep in mind that my explanation is an exposition of what may be happening (I bet for it), since you wanted to understand what is happening.
the confirmation should come from people who has studied this specific hardware and knows the ADDRs they set for its use. Since I have not the map ADDR they have internally blocked/reserved.

I would not want to make you think that I know so deep that specific hardware. I know how some works, but I have not those specific one.

Popopo wrote: Sun Aug 03, 2025 2:55 pm You are welcome

Please to keep in mind that my explanation is an exposition of what may be happening (I bet for it), since you wanted to understand what is happening.
the confirmation should come from people who has studied this specific hardware and knows the ADDRs they set for its use. Since I have not the map ADDR they have internally blocked/reserved.

I would not want to make you think that I know so deep that specific hardware. I know how some works, but I have not those specific one.

Understood, thanks

Could it be as simple as the fact the Trump card seems to use the 256kb of expansion addresses at top of the memory map as RAM to get the 896kb, so leaving no room for an expansion card, please?

Yes the extra RAM is conflicting with the ROM driver of the other card for the allocated space in the CPU mapping. All Trumpcards were restricted to no other expansion options because of this.


And you lot thought I was just thick.. :D

Wicksy wrote: Sun Aug 03, 2025 3:42 pm Yes the extra RAM is conflicting with the ROM driver of the other card for the allocated space in the CPU mapping. All Trumpcards were restricted to no other expansion options because of this.


And you lot thought I was just thick..

Many thanks Wicksy!

Not to say that is the cause in this case, just it could be.


I have to admit that when you go from using a dedicated backplane to multiple thru connected cards am a little less certain of the consequences.

The combination of minitrump3 (with the GAL for only minerva) + minerva + 512Kb RAM + Qsound, work without problems because everything go to the correct place.

The conbination of minitrumpcard3 + 512Kb + 256Kb only leave free the ROM Cartridge space, so shall only be used in combination with QbIde, QIMSI, ICE, or other interfaces that do no use the top memory area.

Using the extra 256Kb + Qsound shall be avoid, cause errors in minerva and even hardware damage in long term,

This also apply to use minitrump3 with JS GAL + Qsound, even without extra RAM, shall also be avoid, because for a small period of time minitrump3 and Qsound conflict in the memory space.

IN THEORY, The Qsound Card follow the "QL Standar plug'n'play system" so when using a adecuate backplane (one that allow you to configure the DSn lines of the slot) can be moved to other memory allocation without conflict, but AFAIK this only work with minerva because bugs in JS do not allow to inicializate on other places of memory. I say IN THEORY because in my test, do not work, but only do fast-test.

The extra 256Kb memory has a dip-switch configuration to allow to configure for use only 192Kb of memory (I only test it with minerva gal of trump) this allow space for up to 4 extra cards and 832Kb of RAM.

So In Theory you can have:
QL with Minerva + 512Kb RAM + Minitrump3 (minerva's gal) + 192Kb + Qbide (bonus!) + Qsound (modified or using a backplane) + 2-3 more interfaces
And shall work, but I do not managed to made it work.