The Sinclair QL Forum

A big thumbs up...that drove me a bit batty trying to see what was going on

For a second there, I thought Jon Eproms was s great name for a hardware guy.

Cheers,
Norm.

Btw, getting back to the original post on this, here is the YouTube video on how I created the image and also some other drawing programs I tried.

https://youtu.be/IHV8kIKO_5Y

ARTice worked pretty well. Is Damon Chaplin still around? He wrote some really nifty programs for the QL (a couple of cool games I recall).

Next project: now that you've listed the QLTIFF_bas on screen, I can type it in manually and then see if GIMP can produce a TIFF file that it can read. I would assume this is the case, but you never know...

Report (and evidence) to follow!

Erm...

This went in - or, at least, an equivalent TIFF file (2 colours, black and white only, uncompressed) went in:



This came out:



As Sir Jeremy of Chipping Norton would say: "That's not gone well!" I've provided the .tif file and its _scr output below, so if anyone knows what's gone wrong, do tell me. The TIFF file output doesn't look to be long enough - it should be 128 KB for 512x256 pixels with one byte each, but is only 113 KB. I've tried deselecting everything I could (EXIF data, comments, and anything else in any "advanced") menu... and that cut it down to 16 KB, which makes about as much sense as a badly-translated manual for a piece of cheap Chinese junk that Big Clive regularly dismantles.

I've checked through the qltiff_bas code that I've taken off the screen and it's exactly as it needs to be - I figured that if I'd made a mistake, then it would just not run at all because reading files and manipulating them the way this program does is far beyond my understanding at this stage.

Or... perish the thought, but is GIMP 2.10 not going to do the job after all?

TMD2003 wrote:Erm...

This went in - or, at least, an equivalent TIFF file (2 colours, black and white only, uncompressed) went in...

You didn't have to type the code in as it's on Dilwyn's website under Graphics. Not sure why the picture is inverted (though ARTice can easily recolor that). Did you run QLTIFF_bas in mode 4? (The source image itself is the right size at 512 x 256.)

Edit: btw, on mine it sometimes was off because when using vDrive on my BBQL, a delay in reading the first sector of the TIFF file caused the program to lose its way. If you are running it off MDV (even on emulator) one way to fix it is to run it off RAM disk -- with vDrive I just needed to re-run it and the second time it was fine...in fact I did a video edit to splice the two parts together to get rid of that hiccup

Just checked ungif working on q-emu, my settings are 640k ram, js rom and tk2. This is my boot

100 TK2_EXT
110 LRESPR flp1_ptr_gen
120 LRESPR flp1_wman
130 LRESPR flp1_hot_rext
140 LRESPR flp1_macmouse11

TMD2003 wrote: This went in - or, at least, an equivalent TIFF file (2 colours, black and white only, uncompressed) went in:
...
This came out:
...

As it is a _bas program it should be possible to fix it for this example.
Comparing the two images there appear five lines of rubbish at the start minus an offset of 32 pixels.
I guess some header info got translated as well, so conversion should start at +5x256 -32 pixels, in bytes for the Tiff.

Anything white must set the green as well as the red bit on the QL side.
A mode 4 word contains 8 green bits and 8 red bits so 8 pixels are done together (gggggggg.rrrrrrrr).

BSJR

bwinkel67 wrote:You didn't have to type the code in as it's on Dilwyn's website under Graphics.

I thought it would be, but I didn't see it on a first look (was it renamed?) and the listing was so short I thought... why not type it in? It only took about five minutes.

Did you run QLTIFF_bas in mode 4?

Certainly did - it was a fresh boot in monitor mode, which is what I'd always default to using.

If you are running it off MDV (even on emulator) one way to fix it is to run it off RAM disk -- with vDrive I just needed to re-run it and the second time it was fine...in fact I did a video edit to splice the two parts together to get rid of that hiccup

Sounds like that involves QPC2 (in that I've seen RAM1 at the top of the screen next to WIN1 and DOS1). At least that'll be fast.

BSJR wrote:Comparing the two images there appear five lines of rubbish at the start minus an offset of 32 pixels.
I guess some header info got translated as well, so conversion should start at +5x256 -32 pixels, in bytes for the Tiff.

That's what I'd assumed - but then I'd also assumed that the four values in the SELECT loop towards the end of the main procedure had been chosen to account for that.

TMD2003 wrote:

bwinkel67 wrote:If you are running it off MDV (even on emulator) one way to fix it is to run it off RAM disk -- with vDrive I just needed to re-run it and the second time it was fine...in fact I did a video edit to splice the two parts together to get rid of that hiccup

Sounds like that involves QPC2 (in that I've seen RAM1 at the top of the screen next to WIN1 and DOS1). At least that'll be fast.

I ran this on a 128K BBQL, and when using microdrives it sometimes adds a delay. If you run this on a BBQL with a floppy it should work fine, or with an emulator just use a RAM disk since emulated microdrives may also have timing issues (I know QLAY has this issue for me).

But the more I look at your picture, the more likely that's what happened during the conversion so I bet if you stopped the BASIC program and re-ran it, the second time you would have been fine (no need to make any code changes).