The Sinclair QL Forum

Tinyfpga wrote:The design exists in a reasonably detailed format but not as a functional circuit diagram. I cannot program FPGA's

That is unexpected considering your user handle

To test the difference of display performance between QPC and a Q68, I decided to recreate the Amiga bouncing ball demo runing in a moveable SMSQE window. I Installed QPC on a Lenovo Thinkpad X220 containing an i5-2520m (running at 2.5Ghz).
A large ball bounces smoothly on QPC. For a smooth bounce on a Q68 the ball has to have a diameter that is a 1/4 of the large ball. I think that is a pretty impressive performance for a system that is 100 (maybe more?) times less powerful than the PC.

It's not only the raw CPU power, QPC also employs PC-based accelerator techniques similar to a blitter chip (if you use the OS calls).

Mk79 reasonably states that my user handle implies that I might be able to program FPGAs.
The user name I chose was meant to indicate an interest in tiny FPGA development boards because I had a fanciful notion that it might be possible, one day, to resurrect Tony Tebby's computing project in FPGA.

I have bought a number of tiny (and not so tiny) FPGA boards and helped (financially) in the development of one of them. I started by installing SMS2 in a MIST but that project was overtaken by the much more useful SMSQE-in-Q68.

I have found QPC to be a very useful for transfering the large body of work that lay dormant in a couple of hundred floppy discs left over from my SMS2-in-Atari days. It would not have been easy to save this work in a contemporary format without it.

Although I mostly use QPC2 I actually prefer QPC1 because I like to put a USB stick into any old bare PC and watch it boot up into a windowing and useable system in a few seconds. Doing the same thing in FPGA is, in my opinion, also a significant achievement.

My user name was chosen before the anouncement of the Qzero but the board is a perfect example of a tinyfpga board which might lead to a kind of future for QL enthusiasts and many others in the maker world.
I would love to be able to program FPGA's. I have imagined an "SMS/Stella" system in FPGA that might provide an easier route to the delights of this technology, a kind of FPGA programming environment for dummies.

I don't know how these forum threads drift off in all sorts of directions but I realise that my recent posts have nothing to do with Knowware. (great name by the way)

Your plaintive cry:- "I realised (yet again) that people here, despite what they say, aren't really interested in software, particularly nothing produced this millennium!" deserves a reply.
The Q68 has reignited my interest in writing software. I have just scanned your hard work and found , as usual, that I know very little about programming but I am going to make an effort to grasp the essence of your efforts.
I, for one, am really interested in programming in SMS and I say, keep up the good work.

mk79 wrote:It's not only the raw CPU power, QPC also employs PC-based accelerator techniques similar to a blitter chip (if you use the OS calls).

Another example why accelerator techniques are no shortcut to make the speed gap between QL hardware and emulation smaller.

Afforementioned Atari no longer included a blitter chip for the TT. Why? Because the original blitter design would only have been a bottleneck instead of an improvement. And the amount of work for a new design, providing a performance benefit for the latest CPU and memory technology of the time, was not economical. Now designing a blitter for modern SDRAM technology and a 68060 is even more complex than for classic DRAMs and a 68030! And to make sense, it must massively outperform what the 68060 with it's caches, optimizations and burst capabilities could do directly. A lot of work, even for me who has some degree of expertise. And (in contrast to a faster CPU) only a small portion of the user experience would be improved.

In the end, a hobbyist working for free would have to invest more work for such a DMA hardware than a multi-million $ corporation - while emulation gets at least the same improvement simply by software.
Unfortunately, speed is not a rewarding design goal for QL hardware anymore.

By the way, I was hopeing for significant "automatic" speed increase by newer FPGA chips, but my recent experiences were disillusioning. ECP5 versus LFXP2 is only marginally faster for the same 68K core. (Has to do with the CPU structure, which does not map ideally to the lastest lowcost FPGAs.)

Tinyfpga wrote:I don't know how these forum threads drift off in all sorts of directions but I realise that my recent posts have nothing to do with Knowware. (great name by the way)

Your plaintive cry:- "I realised (yet again) that people here, despite what they say, aren't really interested in software, particularly nothing produced this millennium!" deserves a reply.
The Q68 has reignited my interest in writing software. I have just scanned your hard work and found , as usual, that I know very little about programming but I am going to make an effort to grasp the essence of your efforts.
I, for one, am really interested in programming in SMS and I say, keep up the good work.

Thank you for your feedback and encouragement!

The "QL" is a great system to program for fun and to learn about general, fundamental, programming techniques. And who knows: You may end up making the next "killer app"!

So good luck with that! and enjoy!

So heres the latest from Knoware.no:

2020/12/14 Additions and Updates
Added Snip - a screen snipper.
Added Pic2Pac, to compress PICs to the new PAC format.
Added Pac2Pic, to decompress the new format PACs to standard PICs.
Added Pic2Spr, to convert PICs to compressed or uncomressed solid sprites.
Added RLE, a toolkit to compress and decompress a block of graphics memory.
Added some information on graphics file name extensions and formats.
Added MBLK, a command to move a block of graphics memory. (pv_mblk wrapper)
Updated enrle_bas: Bug fix. Update if you used this!
Updated QV: All you asked for, and then some..
Updated MenView. Minor changes, eg to list menu elements.

If you want to know about headless data, graphic file extensions, PAC
files, and other weighty matters, head to
Knoware.no/Articles/Extensions.

As Ive said before: I find it too much trouble to bring my stuff up to
"production quality" - they usually work well enough for me! You, however, may
sometimes find things a bit rough round the edges. I make this stuff for my own
enjoyment, but Id like for you to be happy too! (believe it or not). So if you
report any bugs you find, or have suggestions for improvements, or let me know
about things you like or dislike, I do take note, and may, eventually, get round
to doing something about them!

Hi Per,

I think you are doing yourself an injustice. Your software is excellent and your web site is has a wezlth of information that I always refer to.

I read on your web site about the PAC format, can expand a little more on this.

What viewers will bd able to PAC files?

Hi Derek, Thank you!

The PAC file format is very similar to the standard QL PIC file format. The only
differences are the "RLEx" long word tag prepended to the header and the fact
that the graphics data following the header is RLE compressed, using the
identical method as used for Wman2 sprites:
The RLE format (lifted from the SMSQ/E source files, originally by Marcel
Kilgus) goes like this: At present only my QV (QuickView) can display these files, but at least one
other graphics viewer author has expressed an intention to update his viewer to
support PAC files. (I wont mention any names so as not to put undue pressure on
the persons involved ;o) I hope the format will be taken up by others as the
advantages become apparent..

In the mean time one can use the SBASIC tool, Pac2Pic_bas, found in the GO SUB
section of Knoware.no, to unpack PACs. (There are also an SBASIC version of the
RLE-compressor, enrle_bas, and a PIC packer, Pic2Pac_bas.)

In the Knoware.no toolkit section, you can find a suit of commands, complete
with assembler source code, that does the actual compression/decompression

I should have mentioned in the associated literature (and will in future
updates) that Bob Spelten Jr's ideas were adopted in defining the format and
extension name.

Thanks for publishing this information Per.

dilwyn wrote:Thanks for publishing this information Per.

I just updated the "article"! However, no need to trouble you with it again: I just cut some of the waffle and added the most informative bits from my clarification to Derek. So anyone whod like to support PACs (and/or any of the rest) can find the info in one place.