On 09/04/02 at 12:23 Phoebus Dokos wrote: >Hi all, >I am turning to the list for any ideas... >As you might have guessed at last I have a working (well sort of) Aurora >setup... However I experience a couple of problems, mainly with resolutions. >... >Specifically, I give DISP_SIZE 640, 480 but nothing happens (still 512x256).
OK, this has been solved. The soulution has two parts: the usual one, and the 'read the manual' (oops, sorry, don't think it's in there!) part. The usual part is taking out the 8302 ULA and cleaning it's pins, which for some reason have a tendency to oxidise. They do this even when left alone in a drawer - I have three spares and they all had their pins turn black while sitting peacefully in my QL spares box, in their antistatic rail. The ...other part is quite simple in retrospect: SMSQ/E was not detecting the Aurora, hence always thought it was working with regular QL compatible hardware. How? Simple: the problem has nothing to do with Aurora or SMSQ/E - rather with the address setting of the Qubide, also present in the system. IMPORTANT!!! When an Aurora is used, only the following two base address settings are legal: 0C000 (i.e. ROM slot) FC000 (top of IO area) Obviously, if you are using the Aurora with a GC for any reason, there is no IO area so you only have the 0C000 address to use. If this is set, in either case the ROM slot will be disabled, and anything plugged into the slot will be 'invisible'. At present, there is no way around this problemm save for using a SGC so the address can be set to FC000. So, why did SMSQ/E fail in changing resolutions? Simple: C0000 to FBFFF (this appears as 4C0000 to 4FBFFF on SGC) are used for the Aurora screen RAM. Anything else set to any part within the same address range (like a Qubide, for instance) will result in Aurora screen RAM test fail during initialization of the Aurora screen driver, and the system will revert to emulation mode. ALL Aurora extended graphics support, including DISP_SIZE will be switched off. There may be other consequences, such as superHermes not being initialized correctly. USers that start the system with a JM ROM have a unique problem here because this ROM will not initialize any IO peripherals unless they are at 0C000 or C0000. AFAIK, the GC/SGC software corrects this, so there should be no problem. SMSQ/E also corrects it. Minerva also looks for ROMs in two alternative addresses, 10000 and 14000. If you are using GC/SGC and Qubide, DO NOT attempt to use these addresses because GC/SGC do not support them and Minerva will not find a Qubide at these addresses even if everything 'should' be just fine. If you have a ROMdisq, and use SMSQ/E, you can set the Qubide to FC000, load SMSQ/E from ROMdisq, at which point SMSQ/E will correctly initialize Qubide. Alternatively, you can use the LRESPR-able version of Qubide or figure out the Qubide init routine address from it's ROM header and just CALL it 'by hand'. Nasta PS can't believe I'm doing Qubide support after all these years!
