The Sinclair QL Forum

Hi Per,

Excellent programme, the manual is well written.

I altered my Fileinfo2 config, to add QV.

I usually use the Fileinfo2 PIC Viewer to display PIC files. But it only knows about the specific graphics format of thd machine/emulator it is being usrd on. But QV can handle Mode 32 and Mode 33.

I read in the manual, that you indicate that there is no way to determine the graphics format.

From the SMSQ/E Reference manual:

The 16 bit QPC/QXL/SMSQmulator format is as follows:
G2 G1 G0 B4 B3 B2 B1 B0 R4 R5 R2 R1 R0 G5 G4 G3

The 16 bit Q40/Q60 format is as follows:
G4 G3 G2 G1 G0 R4 R3 R2 R1 R0 B4 B3 B2 B1 B0 W

Could future versions of QV determine the bit format on loading the graphics file and then select the correct code to display the PIC file.

Not sure how to do this, just thinking aloud.

Hi Dilwyn,

Thanks a lot for your valuable feedback!
It always amazes me how very different my homely programs work in other people's
environment, despite my best efforts:

dilwyn wrote: <>I take it the fact that both versions complain about the lack of Wolfgang's
BMP extensions is that as hinted in the manual, it's a temporary measure until
the final BMP routines are ready.

Nope. In both cases WL's BMP toolkit is linked in, and when I test the compiled
code in a pristine QLE environment it works fine. I dont know what could be
wrong..

Will take me some time to get used to the 'alternative' (bottom right)
resize. Although the crosshairs appear, resizing only seems to take place in the
vertical plane? (Maybe I'm misunderstanding something here)

Admittedly it takes some getting used to.. I may change it somewhat. But it
should work in all directions - provided theres room! Are you using a mouse?
Meanwhile, the standard resize button works more or less as usual (with HIT).

Would it be possible for the command line parser to assume "/F" if no
command line switch is given? I have some programs which allow a viewer to be
specified, but not a command line other than a simple filename.

I usually do, but forgot to implement that here. Will do!

Sizes of headerless screen files: the approach I took in some of my
graphics offerings was to calculate the size for given 'standard' resolutions
such as 512x256, 640x480, 800x600, 1024x768 etc in the various modes and form a
list of the resolutions corresponding to given file sizes in a lookup table. Far
from infallible of course, and you can't tell the difference between a 512x256
16-bit colour and a 1024x256 8-bit colour, but works for most standard screen
sizes used. Where GV can't deduce the screen sizes, a small popup could ask the
user to enter width, height, mode, or goes to the current "can't work it out"
popup and bows out gracefully.

I already do that with modes 0-8, but perhaps its not working for some reason?
I'll check. Perhaps I dont have such an extensive list as youve provided. I
based mine on typical values I found on my system. Thanks for your list! I'll
see if I can merge it with mine.

I thought about an input dialogue to add missing information, but I wanted to
keep QV as "light" as possible. QV started off as a sub-program of another
utility (QL PreView, or QPV). That utility already has its own sub-utility to
gather extraneous information about screen dumps when required and allows the
user to test various settings quickly and visually. It stores that information
in the thumbnail representation of the screendump so it need never ask again. I
might re-use that utility in the stand-alone version of QV..

I have also taken the liberty of defining some extensions which are supposed to
convey the correct information to QV. They could be changed (in the program
code) if you dont approve, but I was sort of hoping for a sneaky
"standardisation effect", so I didnt make it easy..

(Dilwyn goes and hides before Per sends a Norwegian whaling fleet hunting
for him for causing unnecessary work... )

Yeah folks, Im very sorry and ashamed about Norway's whaling stance. So you can
rest assured, Dilwyn: My harpoon is laid up for good.

Table of file lengths for the most common resolutions in the various
modes, also gives an idea of just how large mode 32 and 33 uncompressed graphics
can be!

Thanks for the list. I'll pick out any Im missing (if thats ok).
<>

Finally, for those who haven't tried GV, here's what it looks like. I
suggest XorA should not look at the picture - it's the train which broke down
during his trip up mount Snowdon a couple of years ago...
qv1.jpg

Ive taken that train twice now. But only down

Derek_Stewart wrote:Hi Per,

Excellent programme, the manual is well written.

Thanks! You actually read the manual?! Gosh, what a bunch of nerds we are..

I altered my Fileinfo2 config, to add QV.

I usually use the Fileinfo2 PIC Viewer to display PIC files. But it only knows
about the specific graphics format of thd machine/emulator it is being usrd on.
But QV can handle Mode 32 and Mode 33.

I read in the manual, that you indicate that there is no way to determine the
graphics format.

From the SMSQ/E Reference manual:

The 16 bit QPC/QXL/SMSQmulator format is as follows:
G2 G1 G0 B4 B3 B2 B1 B0 R4 R5 R2 R1 R0 G5 G4 G3

The 16 bit Q40/Q60 format is as follows:
G4 G3 G2 G1 G0 R4 R3 R2 R1 R0 B4 B3 B2 B1 B0 W

Could future versions of QV determine the bit format on loading the graphics
file and then select the correct code to display the PIC file.

Not sure how to do this, just thinking aloud.

Sadly, a bit is a bit. They arent neatly labled inside memory. Unless there is
some unique tell-tale value (like the flash bit in mode 8) I dont think it is
possible.

Hi Per,

I always read the manual, if someone takes the time to write the manual, I think I should take the time to read it.

Mind you, I have all day to read manuals, with no daytime employment now...

Pity about detection of Mode 32 and Mode 33 bit patterns.

pjw wrote:But thats sort of my point: Why go backwards after 20 years? Dont get me wrong. I think the Q68 is great! Its compact, well- designed and built, and interfaces with modern components, which means it can actually be used occasionally. But there is so much talk of re-creating various forms of the old QL when to my mind, if effort is to be expended on a new device, why not try to make it significantly better?

As "significantly better" seems to mean "much faster" for you, the answer is the same as 20 years ago: Because there is no much faster 68K CPU. Technically, there are two ways to design a top speed QL mainboard:

1. Go back to the 68060 CPU. A little more than Q60 speed could be squeezed out by faster SDRAM bursts and overclocking. Removable storage could be modernized from floppy/CDROM to SD card. Video and a few peripherals could be modernized. The overall system could be more compact. But that's it.

2. Use the closed source + commercial Apollo core for FPGA. The effort involved would be massive. Development costing much more money and time than the 68060. Risks lots of debugging, like previous FPGA cores that included bugs affecting QL code, but not Amiga code. If an expensive FPGA is used, roughly twice as fast as an overclocked 68060.

Both options are frustrating, inasmuch they cost insane work, while not delivering a speed breakthrough compared to the 20 years old Q60. They will never reach even a fraction of emulation speed.

Peter wrote:

pjw wrote:But thats sort of my point: Why go backwards after 20 years? Dont get me wrong. I think the Q68 is great! Its compact, well- designed and built, and interfaces with modern components, which means it can actually be used occasionally. But there is so much talk of re-creating various forms of the old QL when to my mind, if effort is to be expended on a new device, why not try to make it significantly better?

As "significantly better" seems to mean "much faster" for you, the answer is the same as 20 years ago: Because there is no much faster 68K CPU. Technically, there are two ways to design a top speed QL mainboard:<>

Im aware of those issues. But there has been talk here of "developments" that distinctly point in a retrograde direction. This may be exactly what some people want, but my argument is that its easier to slow down fast hardware than to speed up slow hardware. So faster hardware covers more bases - with the same effort.
Video seems (to me) to be the main bottleneck. This is especially the case with high colour. If there were a way of isolating the video hardware from the CPU, much could be gained without having to break the currently insurmountable CPU speed barrier. I dont know if there are off-the-shelf solutions that could be used, or whether other hobbyist groups have solutions one might adopt, but I know Id sleep better at night if I knew people were thinking along those lines rather than trying to re-create a "better" 1980's QL ;o) Well, thats my penny's worth anyway..

In the article series from TT (QLtoday page 16/53 of "TTos.pdf")) TT has written, that someone designed a kind of "Windowing hardware" which unfortunately has not reached the market. Would be interesting to konw, what this was or is.

pjw wrote:This may be exactly what some people want, but my argument is that its easier to slow down fast hardware than to speed up slow hardware. So faster hardware covers more bases - with the same effort.

Not sure what you mean here. Slower hardware, like just using a medium speed CPU inside FPGA as the Q68 does, is much less effort.
Also much cheaper, and doesn't require obsolote sockets and obsolete chips.

pjw wrote:Video seems (to me) to be the main bottleneck. This is especially the case with high colour. If there were a way of isolating the video hardware from the CPU, much could be gained without having to break the currently insurmountable CPU speed barrier.

The Qzero does just that. It isolates the video hardware from the CPU. The gain is usually overestimated. Separate video does not at all change the fact that highcolor with highres is a lot of data. And at some point a CPU has to generate that data. Many people are so used to emulators they have lost sense of realism for the 68K era. 1024x768 @ highcolor is so much that only a CPU in the range of a fast 68040/060 can decently use it.

pjw wrote:I dont know if there are off-the-shelf solutions that could be used, or whether other hobbyist groups have solutions one might adopt, but I know Id sleep better at night if I knew people were thinking along those lines rather than trying to re-create a "better" 1980's QL ;o)

As I wrote, I've been more than just thinking. But separate video won't turn a medium range 68K system into someting that's fun for highcolor with highres.

The "Windowing Hardware" the TT article probably refers to, is the "SLICK Windowing Display Controller" designed by QJUMP Limited.

TT's last comment on the controller was as follows:-
"The only thing that is remarkable about the design is that seven years after it was originally conceived, the circumstances which gave rise to the original design have not changed at all"

The circuitry could be implemented in FPGA, possibly in a Qzero.

I use my Q68 in black and white mode which I think looks very good.
It is quite possible, as Peter suggests in this forum, that a Qzero would be perfect for developing hobby control systems and for such uses, colour might not be considered paritcularly important.

In my opinion colour is nothing like as important as high resolution for multi-tasking/windowing control system displays (think multiple applications showing what ever it is you are trying to monitor and /or control).

A B&W mode might reduce the amount of display data that needs to be manipulated by 68000 systems in FPGA