The Sinclair QL Forum

Great result!

Thanks, and 1024x768 4 colors

Amazing that's only 4 colours!

lliont wrote: Mon Feb 03, 2025 1:46 am Thanks, and 1024x768 4 colors

It looks to me more like 8 colors. at least

Gimp did the dithering, I was impressed too

lliont wrote: Sat Feb 01, 2025 10:26 am I added 2 new screen resolutions
-512x384 256 colours
-1024x384 16 colours
I tried aurora emulation for smsq/e, it works but doesn't support the higher than 512x256 resolutions, no good so I quit trying.
It currently works with a pretty standard version of gold card smsq/e with the standard resolutions.
it also worked with super gold card smsq/e but had to enable 68020 mode in the core which takes a lot of fpga resources and doesn't gain anything significant.
I just wish I was able to run smsq/e in these two new higher resolutions and maybe a 1024x768 and I would call it finished.

As far as Aurora is concerned, the SGC only offers the extra IO address area which Aurora uses for screen RAM.
If I remember correctly, SMSQ/E for GC/SGC is the same binary so at some point if a GC is detected it skips testing for Aurora extra screen RAM, this could possibly be patched so the test is not skipped and other Aurora resolutions are enabled.
It should be noted that Aurora uses 3 basic bitmap sizes for all resolutions:
1024x1024 4 colors (256 bytes per line)
1024x512 16 colors (512 bytes per line)
512x512 256 colors (512 bytes per line)
This remains constant and only dependant on the color mode used and NOT the screen resolution, basically if the resolution is less than the bitmap size, the screen resolution is mapped into the top lefthand part of the bitmap.
This was done because the hardware needed to be simplified. Also, pixel and line doubling could be used (but not trippled lines).
Now, 16 colors was never a QL thing - until you redefined the flash bit - so no 16 color driver exists. Also, Aurora 16 color uses packed pixels, 2 pixels per byte, left one in the upper 4 and right one in the lower 4 bits of a byte so not compatible with mode 8. That being said, it does support mode 8 (without flash) but as usual it is based on the mode 4 bitmap so the maximum resolution would be a strange 512x1024.
Also, the top 16k of the 256k of video RAM on the Aurora is accessible by the hardware as long as there is no peripheral mapped into that area - in other words, Aurora uses the usual QL peripheral decoding using the DSMCL line on the bus. In principle, most resolutions that were actually used only needed the first 192k out of the available 256k so up to 4 peripherals could be used in the top 64k of the extended Io area - this was all down to how the software was written. If a peripheral was mapped in an address area used by the screen driver, the initial screen RAM test would fail and Aurora would remain running in compatibility mode, same as with GC.

All that being said, since these days, due to available monitors the usable resolutions have to based on the VESA 1024x768, pixel doubled and line doubled or trippled, there are only a few sensible resolutions that can be used with the above setup today:
Old mode 4 512x256 or 256x256 mode 8
Extended mode 4 512x384 (could be used as 256x384 mode 8 too)
High res mode 4 1024x768
256 color 512x256 or 512x384 (both of these modes as well as 512x480 were supported by Aurora in 256 colors).
In principle the driver could be extended to 512x256 or 512x384 mode 8 (based on the high res mode 4 bitmap) or, since you are doing your own thing, you could redefine the bitmaps as you like.

As far as I know, the mister version of smsq/e does not support 512x384 in 256 colors, even though the SMSQ/E Aurora drivers did.
When Aurora was first developed, there were no high res drivers let alone 16 or 256 color ones, but in order to demonstrate it, the demo machine ran Minerva and found the screen definition block in RAM (unlike JM and JS it was not hard coded!), poked it from superbasic with the proper start address, screen size and bytes/line values and it worked just fine, including pointer environment etc so this might also be possible with the mister driver...

When Aurora was first developed, there were no high res drivers let alone 16 or 256 color ones, but in order to demonstrate it, the demo machine ran Minerva and found the screen definition block in RAM (unlike JM and JS it was not hard coded!), poked it from superbasic with the proper start address, screen size and bytes/line values and it worked just fine, including pointer environment etc so this might also be possible with the mister driver...

Thats how uqlx does its Minerva hires mode!

I don't use the compiled smsq/e version from mister anymore, I only tried it to test that I could run smsq/e. I think the mister version as Marcel mentions is the same as the public one.
I used the public source smsq/e version and emulated the aurora registers and set the same vram addresses, I managed to make the smsq/e recognize my card as a gold card with aurora, machine=11. The standard modes worked using the aurora vram space. The higher resolution 512x384 didn't seem to work. Then I tried with a 68020 mode and was recognized as super gold card but again it didn't work. It didn't switch to another resolution. Maybe I missed something and I'll try again to find a solution when I find some time. That Minerva trick is promising.
Thanks for the info.

Was there a special smsq/e version for aurora that was different from the one I try with that supported the high resolutions ?

lliont wrote: Mon Feb 03, 2025 1:46 am Thanks, and 1024x768 4 colors

The palette seems the default one (red-green-black-white). I suppose it can't be changed, am I right?

yes, I haven't done this for the 1024x768 mode but it's easy to add palette choice.