QSound and QPrint Interface

[mk79]

Hm, the device should never hang, so this is at least strange or a bug in the device.

v1.93 rom hangs QL on both these Basic commands:

OPEN#3;QSOUND
BGET#3,a

OPEN#3;QSOUND
BPUT#3;1,2,3,4,5,6,7,8,9,10,11,12,13,14

On QPC2 you get err_bp for BGET, with expected noisy output on BPUT.

Unfortunately I don't get any crash in QemuLator at all, so it's difficult to pin down for me. What OS do you use?

(BTW your device code will be running in the very slow E bus access to EPROM so I don't know whether it may affect it.)

Well, what happens if you load the ROM file into RAM and execute it using "call x+46"? It should then shadow the device in ROM so it's not used anymore.

Yes I forgot I left that in there . As I mentioned I got bad playback running QPC2 with Wine on Linux I thought it might have been the device overhead/bug. I forgot to revert back to API call.

Ah ok, I see There is some overhead (e.g. I cache the written registers) but at 50Hz or so call rate it shouldn't matter in the grand scheme of things.

[mk79]

Have you problem with play command? any "out of range error"?

Yes, I almost always get that error.

PLAY 'CDEFGAH' is always accepted (but of course no sound).
PLAY 'v8CDEFGAH' sometimes just plays scale (but not always)
PLAY 'v10CDEFGAH' always complains 'out of range' (as do all other commands with arguments in PLAY string)

That is so weird. The code isn't that complex, I went over it in my head halve a dozen times but I cannot explain it. Neither does it trigger in QPC or QemuLator, which it should as the AY hardware is not involved at this stage at all I'm really looking forward to the eventual solution of this puzzle, but maybe I have to boot up a real QL eventually as well.

[aalea]

Have you problem with play command? any "out of range error"?

Yes, I almost always get that error.

PLAY 'CDEFGAH' is always accepted (but of course no sound).
PLAY 'v8CDEFGAH' sometimes just plays scale (but not always)
PLAY 'v10CDEFGAH' always complains 'out of range' (as do all other commands with arguments in PLAY string)

That is so weird. The code isn't that complex, I went over it in my head halve a dozen times but I cannot explain it. Neither does it trigger in QPC or QemuLator, which it should as the AY hardware is not involved at this stage at all I'm really looking forward to the eventual solution of this puzzle, but maybe I have to boot up a real QL eventually as well.

I'm not finish yet, because I have not time, and I need to read more documentation, because I'm not very familiar with the M68K architecture, but in any case, I do some experiment:

If disconect the VPA line, and conect it to DTACKL, (directly, or by a 1N4148 diode to the CE pin 20 of the eprom) and in both cases, the interface do not cause errors and PLAY work well, BUT I dont get any sound at all. (with 1.10 and 1.93)
If I connect both (VPA to pin 6 of 74LS03, and DTACKL throught a diode to inverse signal of VPA) there are errors and the QL hang.

So I suspect to a fault in the schematic, and we need aditional circuit to carry VPA only when access 6821 and DTACKL only when read de rom.

[Silvester]

Well, what happens if you load the ROM file into RAM and execute it using "call x+46"? It should then shadow the device in ROM so it's not used anymore.

Well, it all works PLAY and QSOUND device perform as expected. (I removed EPROM and loaded image into RESPR)

I was using JS rom on 128K QL (slow memory) and got many errors, aalea is using 640K so in faster memory and got fewer errors. I previously copied EPROM several times (SBYTES) to see if any drop out occurred but nothing failed.

So I suspect to a fault in the schematic, and we need aditional circuit to carry VPA only when access 6821 and DTACKL only when read de rom.

I suspect hardware timing problem. Be interesting to hear if Derek gets his original QSound board working and the results he gets. I can't think of anything missing from schematic.

(Ideally 6821 access should use 7473 (as suggested in Motorola 68K manual) and DTACKL for EPROM.)

[Derek_Stewart]

Be interesting to hear if Derek gets his original QSound board working and the results he gets. I can't think of anything missing from schematic.

(Ideally 6821 access should use 7473 (as suggested in Motorola 68K manual) and DTACKL for EPROM.)

The damage to my Qsound PCB, is the voltage regulator through hole plating is missing and some tracks to the regulator legs missing.

I intended to replace the missing Through Plating with new eyelets, I am waiting for the correct sized eyelet being delivered.

However I will wire up a voltage regulator to get the interface powered up.

I guess there maybe other faults...

I will try my best.

[Silvester]

Got it working from EPROM by making a couple of changes to hardware. DSL to pin 1 & 2 of 74LS03 (address decode). E to pin 12 & 13 of 74LS03, output pin 11 to pin 4 of 74LS03 (gate VPAL). I can only guess this is what tracks might do under 74LS03, puzzling thing is there would be no pull up resistor for pin 11 of 74LS03, which works without one (I haven't put one on mine yet).

[aalea]

Got it working from EPROM by making a couple of changes to hardware. DSL to pin 1 & 2 of 74LS03 (address decode). E to pin 12 & 13 of 74LS03, output pin 11 to pin 4 of 74LS03 (gate VPAL). I can only guess this is what tracks might do under 74LS03, puzzling thing is there would be no pull up resistor for pin 11 of 74LS03, which works without one (I haven't put one on mine yet).

Yes!, I confirm that it work correctly, I will update my project to reflect it, now we need one more version, with automatic address instead of fix to 0xC0000

[Pr0f]

That's what the SPn lines are for - on a multi slot bus - these would increment from one slot to the next as a 4 bit number - when the address lines A17, A16, A15 and A14 match the SPn lines for logic state - the card is selected at that address represented - starting at 0x0C0000

[Silvester]

I didn't wire to expansion SP0-SP3 but to DIP switches so I could force slot location and test direct access. But if the QSOUND device does not add too much overhead on slow 68008 QL then it could be argued we never need to know where it is in address map.

OTOH...
Before Super Gold card arrived with its printer port I has used a 8255 PIO chip in the QL I/O area ($18000-$1BFFF) as PAR port for plain Gold Card QL. The AY chip access could be done similarly, which would also work with SGC/GC systems (which don't offer E signal).

[aalea]

That's what the SPn lines are for - on a multi slot bus - these would increment from one slot to the next as a 4 bit number - when the address lines A17, A16, A15 and A14 match the SPn lines for logic state - the card is selected at that address represented - starting at 0x0C0000

Yes, but to clarify:
This is the standar way, and the original ROM check the real position of the ROM, store the address in a system variable, and expect the PSG to be there.

MK79 made a custom ROM where the PGS is fixed in 0xC0000, So I was able to put the ROM in a cartridge, that is mapped in a diferent address of the PSG and do some test until silvester found the problem with the schematic.

Thats mean that If silvester move the ROM to another position with the dip switches, the orignal ROMS (1.10, 1.30...) wil work properly, but with the version 1.93 of MK79, don't get sound, only if mapped in 0x0C0000.