P.I.Cole 2 – The Invisible Case

Screen Dump from P.I.Cole 2

P.I.Cole2-The Invisible Case – The second in Andrei Tenu’s P. I. Cole series of adventures for Sinclair QL and compatibles.

You are the detective Cole and you have to find and retrieve a stolen item, in order to receive the reward paid by the insurance. The story then gets more complex, and much darker, as you play.

It’s an illustrated adventure game, with commands chosen from a menu using cursor arrow keys. The author describes the game as “much more complex than the first game” (the first game was P.I.Cole, The Case Of The Missing Doxie). You need to solve a lot of puzzles, not necessarily in linear order, although your previous actions (or lack of actions!) may have an impact on the developments in the game, possibly even affecting the ending. There are 3 possible endings – a happy ending and 2, let’s say, not so happy. So save often! You might need it! In addition, try not to end up in hospital!

Toolkit 2 is needed to run the game.There are three versions of the game for different systems – a generic zip file, qxl.win-style image and a floppy disc image, follow the instructions in the manual to install your chosen version. Unlike the first P.I.Cole game, there is no MDV image for this one as the game is just too large.

In addition to a PDF file manual, there is an eight page “walkthrough” document to help you when you get stuck.

Download the game from the Sinclair QL Software-Games Page on my website. QL Forum members can also download it from the P.I.Cole Sequel thread on the Forum.

A screen from P.I.Cole 2 – The Invisible Case

AMOS Basic on Amiga


In early 1990s, I used STOS Basic on Atari ST for a while, then went over to AMOS on Amiga.

STOS still had line numbers(!) and as far as I remember it did not have procedures. AMOS crammed together a lot of features and resembles Sinclair QL SuperBASIC in some respects.

I was spoiled with AMOS and Basic generally in that just with hitting F1/RUN my program would run in a second. So I've never been especially tolerant towards slow build times.

Blitz Basic helped make more system-friendly code but it was also somewhat trickier to get into.

Installing AMOS Pro with the compiler takes some effort but without the compiler and a hard disk I wouldn't really bother with it. 

Acceleration is very useful too, especially in a setup where a modern PC is used for writing the source and compiling it on a super-fast Amiga emulator. I'll discuss this further below.

Find all the AMOS Pro disks, then the Compiler disk images which has the necessary update/patch. Perform the update on the disk images (couldn't get it to work on an already existing HD install) and then install them to HD.


AMOS basics

The following program opens a 16-colour low resolution screen, removes the cursor and flashing. Then it sets up a few colours and clears the screen.

   Screen Open 0,320,240,16,Lowres
   Curs Off 
   Flash Off 
   Paper 0
   Ink 1
   Pen 1
   Cls 
   Palette 0,$FFF,$F00,$F
   Hide 
   Sprite Update Off 
   Sprite Off
   Print "Hello World!"
   Amos To Front
   Do
      I$=Inkey$
      If i$="q" Then End
   Loop

Using Hide, Sprite Update Off and Sprite Off together is redundant, but goes to show all this variety exists. (Hide simply hides mouse cursor)

Amos to Front brings everything on top. The Compiler can be set to have Amos in the back by default. This way I can be absolutely sure the first thing the executable displays is something I choose, and not the orange AMOS screen with flashing cursor.


Editor and procedures

Compared to modern coding environments, the editor shows relatively few lines. Another problem is that you cannot really split the source into multiple files, so it will easily grow in size. This is something I didn't care about back in the day but I finally have come to see this as valuable.

But at least it's possible to close and open procedures. This means that for a longer program, having most of the code as closed procedures helps keep the source length manageable.

_CIRCLE here is poor use of Procedure

There is some overhead for calling procedures and the compiler can't see a difference between a simple call and a structurally complex one. So, I'd avoid intensively calling procedures. A long FOR loop that calls a procedure to do a minor task can be 2-3 times as slow than one that doesn't.

For example there could be a procedure that draws a screen using 200 tiles, but these individual tiles should not be drawn using procedure calls.

Another editor quirk is the procedure and variable names are always automatically upper-cased. So it's less easy to make any useful distinction between procedures, variables, global variables and "constants" (not that AMOS really has constants).

I've done this: All procedures are preceded with _ and all global variables are indicated with G_ so that for example G_MAXITEMS is a global variable and _CLEARITEMS is a procedure.

Parameters can be passed to procedures between brackets:

    Procedure _ADDITEM[TYPE,X,Y]
        print "I'm adding type ";TYPE
        print "at coordinates ";X;" ";Y
    End Proc

These parameter names are local to the procedure, so I could call another procedure from within this procedure that also uses TYPE, X and Y (integer) variables as parameters. So far so good.

Although there's a neat way to return values from procedures, these parameters are clumsily referred by using PARAM after the procedure call. 

    _ADDITION[2+2]
    print PARAM

    Procedure _ADDITION[X1,Y1]
        RESULT=X1+Y1
    End Proc [RESULT]

So, X=_ADDITION[2+2] is not possible.

POP PROC exits the procedure. POP PROC [RESULT] puts the value in PARAM/PARAM$, otherwise the procedure returns nothing.

In 1990s I mostly used a single global variable like RES to store procedure outputs, and simply avoided using procedure results.

So, although the AMOS procedures elevate the language far above BASICs that don't have them, they are not exactly as powerful as c or Java functions.


Causes and effects

AMOS has quite rigorous syntax for if-endif structures.

I can have the normal BASIC style...

    if FLAG=0 then print "You're Dead!": print "More"

...and...

    if FLAG=0
        print "You're Dead!"
        print "More"
    end if

...is fine too, but...

    if FLAG=0
        if 
FLAG2=0 then print "You're Dead!": print "More"
        if 
FLAG2=1 then print "You're Alive!"
    end if

is illegal, as it combines if-endif and then.

So I have to do:

    if FLAG=0
        if 
FLAG2=0
            print "You're Dead!"
            print "More"
        end if
        if FLAG2=1
            print "You're Alive!"
        end if
    end if

...which is kind of clean but it can be annoying. AND, OR, ELSE and ELSE IF are helpful here, though.


"Cross-developing" AMOS

Above, I complained about the AMOS editor. But there's another way. 

After the AMOS Compiler has been properly installed, it also works from the Amiga CLI. APCmp is the command:

    APCmp source.AMOS INCLIB

INCLIB ensures the outcome is really stand alone and doesn't need an additional library file with the distribution.

Interestingly enough, APCmp can also compile ASCII formatted files, which means I'm not limited to using the AMOS editor. (Sources in AMOS editor are always tokenized).

I'll skip over the idea of using some other Amiga editor for typing the source, and instead use a modern code editor in Linux.

The downside is that the APCmp first tokenizes the ASCII source and then "compiles" the file, and the tokenization phase is what takes a lot of time.

But this is not the end. Although my Raspberry Amibian setup can be too slow for this, it doesn't mean everything is. So, using UAE in my main Linux box, setting the processor/accelerator to Blizzard 1230 IV, the resulting "Amiga" is considerably faster than the Amibian. Then the AMOS tokenization/compilation time will be shrunk to almost nothing for any reasonably sized source.


This means I can edit my AMOS source in sublime-text in Linux and compile with CTRL+B build command. This needs a Makefile/script that combines different separate files in the project folder and dumps the thing over to the UAE Amiga disk image folder. 

Something like this:

    cat *.txt > source.asc
    cp source.asc /path/to/amiga/harddisk/folder/amosstuff/source.asc

So I can have any txt file as part of my source without explicitly defining them in the Makefile or the script. 

Yes, CAT combines the original sources in alphabetic order, so if this approach is taken some care should be taken when naming files. As all the source snippets are filled with procedures, the order doesn't matter that much. 

I can still name a file aaa_main.txt if I want a particular block to come up first. One thing to remember is that global variables need to be declared before they are used.

On Amiga side I still need to run the compiler from CLI, perhaps using a short script that both compiles and runs the program:

    APCmp source.asc INCLIB WB NODEF
    source

I saved this as "build" on the Amiga project folder and then used "execute build" to run it from the CLI.

(INCLIB means the library is integrated with the outcome file. WB puts workbench back on start and NODEF means no default screen will be opened.)

Of course, it is only at this stage it will be revealed if there are errors in the source, and not inside the Linux editor. Also, the line numbers in the errors refer to the source.asc file, but it's not too hard to check that in the Linux side.

AMOS editor is still friendlier about errors and easier for debugging. But the fast speed of the UAE environment means that if the code crashes totally, it doesn't take too long to get back to the command line.

By the way, writing Processing/Java and AMOS in same session can be confusing! AMOS procedure inputs are marked with [ and ], dimensioned arrays with ( ), with Processing it's the exact opposite. With AMOS, you can't have ; at the end of the line, equality checks are = and not == and so on and on.

The subtly dangerous thing with AMOS is that as variables don't have to be declared, I can mistype a variable name and it does not register as an error.

A syntax pre-checker at the Linux end might be helpful. Also, while at it, allow more modern syntax and have procedures converted to GOSUBs or even unrolled, when possible.

So, perhaps goodbye to fiddling with Amiga keymaps and AMOS editor idiosyncrasies? Of course I'll lose that AMOS feeling. Snif.


Hiding AMOS

I already talked some about Amos to Front and hiding the "orange screen" effect that plagued many AMOS programs.

I used to be careful with hiding if a program was written with AMOS. This made sense as often the first impressions are important. If anyone saw it was a BASIC program to begin with, it might get a negative response. Although some might go "wow, was this really made in AMOS?!"


Apart from the orange screen, AMOS programs can be revealed by using Amiga-A to flip back and forth between the program and workbench, or using Control-C to break out. These might not be uncommon key combinations, but together they can be revealing. 

BREAK OFF instruction can remove the latter, and AMOS LOCK disables the Front/Back switching. The counterpart is AMOS UNLOCK. Locking might unfriendly though, considering the programs seem to multitask nicely enough. Yet if I intend to spread the software on a floppy disk image, it might not matter.

Function AMOS HERE results in true or false. With this it's possible to see if AMOS is currently in the back or not. This way the program might be stopped from using CPU too much, but I've not really tried it.

What remains is that if there is file access, and the device is not present, AMOS compiled programs will open an ugly AMOS-like dialogue box.


System friendly?

Although AMOS programs are self-contained, it's still possible to write shell-runnable programs that don't open a screen at all. The string variable COMMAND LINE$ holds the arguments. AMOS executables tend to be huge, so it's not an ideal way to write tiny commands.

Graphics is a thornier issue. In later days, more modern graphics modes came available and software that didn't play nice with these new modes were frowned on.

But Amiga 500 itself is now increasingly recognized as a retro platform on its own right, despite any newer developments. So it is possible to target the Amiga 500 and care less if the program works on some new-fangled Amiga or not.

Looking at the AMOSPro manual, there are ways to access the Amiga libraries so who knows, it might be able to set a system screen/window.

Some speed considerations

To get some more speed out of AMOS, there are some simple guidelines that can be followed.

I already mentioned the dangers of using procedures in a wrong way. I also noticed GOSUB/RETURN is faster than calling a procedure without parameters. This puts to question whether PROCEDURE should be used so much after all.

Integer variables (1,2,3,4...) should be favored. Floating/real number variables (1.0, 2.0, 3.0, 4.0 ...) are indicated with # so that variables like X# and Y# are floats and X and Y are integers.

If no complex evaluation is needed then Add X,1 should be faster than X=X+1 and Inc X should be faster still.

Adding a variable to another such as Add X,Y does not seem to slow down the computation much.

However, after compilation the difference of these tends to shrink to almost nothing. AmosPro allows compilation+running within the editor environment so comparing non-compiled with compiled sources is quite easy. Set TIMER=0 before your test loop and then print TIMER afterwards.

It can be useful to reduce multiplications and complex equations in a loop.

For example:

    For I=0 to 99
        LOC=BASE+I*32
        if peek(LOC)=1 then Inc A
    Next I

Consider this instead:

    LOC=BASE
    For I=0 to 99
        if peek(LOC)=1 then Inc A
        Add LOC,32
    Next I

Again:

    For Y=0 to 10
        For X=0 to 10
            LOC=BASE+X+Y*40
        Next X
    Next Y

This is faster:

    LOC=BASE
    For Y=0 to 10

        For X=0 to 10
            Inc LOC
        Next X
        Add LOC,29
    Next Y

Also, if a calculation like AD=AD+Y*WID needs to be done a lot, first Z=Y*WID and use Add AD,Z instead. (If Z doesn't need to change)

Unrolling is helpful in BASIC too, and the compiled code also benefits from it. So, instead of the first example:

    LOC=BASE
    For I=0 to 49
        if peek(LOC)=1 then Inc A
        Add LOC,32
        if peek(LOC)=1 then Inc A
        Add LOC,32
    Next I


AMOS and machine code

Writing 68000 machine code is not super-hard in itself, but on a complex 16-bit computer and OS like the Amiga it's a chore to get something visibly up and running.

I've used AMOS as a frame to which I can add some machine code at speed-critical points.

Just to prove it works:

   Reserve As Data 10,65536
   Doke start(10),$4E75
   Call start(10)

The machine code routine is called from the start of the bank 10, where I have reserved 64K of memory.

Then I have used doke (16-bit length POKE) to write the value that corresponds with RTS so the only thing the routine does is come back to AMOS.

This is a very silly way to insert 16-bit code. It is better to load in an output binary from an assembler:

   Reserve As Data 10,65536
   Bload "output.bin",start(10)
   Call start(10)

Assuming the binary is less than 64K long.

As the start address can be where ever AMOS has reserved the memory area, the code has to be relocatable. This isn't a huge deal, for example vasmm68k knows to produce relocatable and optimized code just as long the ORG/* statement is left out. 

Vasmm does a lot to ensure the code is relocatable, but the programmer still has to know some things. For example, it's not possible to move a label address directly to a d-register. It's possible to do move.l #label,a0 because the compiler changes it to lea, but this has no counterpart for d-registers. (Edit: This explanation is not correct, the move instructions have (pc) relative addressing modes just as lea does, it's just that in practice the compiler allowed the use of LEA without explicitly stating a relative addressing mode.)

Register values can be set from AMOS using areg(n) and dreg(n), corresponding with the a and d registers of the 68000. The dreg 0-7 can be freely used whereas a-register 0-3 are available. 

This isn't a limitation, for example areg(0) could point to a start address of a memory area that contains a large table of values you want to use from machine code. Or, the table is inside the assembly binary in a reliable location you can access from AMOS.

To give some clarity the start addresses can be variables. E.g. G_REFRESH=Start(10): Call G_REFRESH

I stored a calculation result in a variable that was apparently in 0-255 byte boundary but became something else in the assembler. I learned AMOS had signed the variable during the process. This helped get rid of the sign:

    If A<128 then A=A AND $7F: Areg(0)=A

This means that even if AMOS prints the variable content as 84, it might be internally something else. It's possible the transition using areg(0) is buggy, or I have not understood something. If the variable is directly set as A=84: Areg(0)=A there's no trouble.

Phybase(bitmap#) and Logbase(bitmap#) are AMOS variables that have the addresses of the current screen bitmaps. If double buffer is on, then Phybase will point to the start of the visible screen and logbase to the "logical", the hidden screen. Screen Swap will change these addresses.

So if you use areg(0)=phybase(0) you can transmit the start of the screen bitmap 0 over to the machine code, for custom graphics routines.

There are a few ways an Amiga can set up a bitmap screen. AMOS reserves screens bitmaps with one bitmap after another and apparently you can't tell AMOS to do otherwise. (The other way would be to store bitmaps so that all bitmap lines follow each other.)

In my experience, drawing grids of 16x16 (or 8x8) tiles with 68K is considerably faster than AMOS at the same job with a PASTE BLOCK loop. This helps a lot in purely tile-based screens.

Something I've been working on...

Other than that I don't know if it's wise to try write faster graphics routines than AMOS already does.

As an aside, I found out the hard way there is a difference between how 68000 and 68020 can handle some operations. It's better to have any word-size (move.w) operations on word-aligned addresses, (e.g 0xdf000 is okay, but not 0xdf001). 

Even if 68020 doesn't crash on these, the plain 68000 does. I spent some time wondering why particular code did work on the WB3.1 68020 emulator environment but not on the real A500, thinking I'd run out of memory or did some other cock-up.

Obviously byte-size operations (move.b) are fine on any kind of addresses. It's just that when possible, moving words and long words is much more effective.

Amibian Amiga system

After installing Amibian on the Raspberry Pi, I wanted to go forward and try a hard disk install.

I'm using the folders on the memory stick as hard drives. This has the downside that certain characters in filenames are not accepted. ("español")

But I can throw in files directly and even through ethernet, so I can ditch the idea of translating files from/to adf images. And although the memory stick isn't especially fast, it is still fairly rapid as an Amiga hard disk. 


Some Workbench re-learning was in order. Firstly I remove the visually throttling main window, by checking "Backdrop" from the Workbench menu.

Instead of dragging an icon to the desk (which looks ok but is non-permanent) the icons have to be treated with "Leave Out" from the Icons menu, which doesn't sound that intuitive.

For the cheap TV, I adjusted Workbench to fit a 640x240 resolution instead of 640x256. Strangely, although the panel should be 768-high, implying a 256-high Amiga screen with no interference pattern, I can only have 240 with no interference. Well, enough of that TV. Many programs play nice with this Workbench setting.

Directory Opus is a great help in arranging folders, moving files and creating icons for software.

I've probably looked at this and CLI more than the actual Workbench

Yes, every file needs that .info file in order to be visible in the WB environment. Folders (drawers, directories) can also display the "real" files as a list.

I was pleased to see that media files can launch apps, for example IFF images saved in Dpaint will again open in DPaint by clicking their icons. 

But it's not possible to globally link file extensions to particular applications. Also, Dpaint doesn't seem to remember the folder from which the file was loaded from.

We reached peak Deluxe Paint in 1988

File transfers

The un-wisdom of constantly rewriting on an USB stick is not lost on me, and I intend to make enough backups in case it eventually breaks. It also helps to have multiple images if the Workbench setup becomes broken. Fortunately, by today's standards an entire Amiga hard drive install with software is not very huge.

As the ethernet is connected and running, I can use the scp command to transfer files over to the Raspberry filesystem, to /media/usb0/System/ or how ever it might be represented there. It's useful to share the ssh keys between the computers before this, so the transfers don't get bogged down by permission requirements.

Default login and password for Amibian is root/1234. Scp is also a good way to make the drive backups.

Copying over ssh can be done even when the emulation is on, but I have tried to avoid doing this, especially on the System drive. The Workbench/AmigaDOS probably doesn't do a lot actively but it's better to be safe than sorry. Maybe a completely separate "hard disk" should be set up for the file transfers.

Troubleshooting

At one point I started to get this alert during boot:

"Intuition is attempting to reset the Workbench screen. Please close all windows, except drawers."

This was annoying and slowed the boot just a tiny amount.

After some Googling I found out the error message emerges from a step in startup-sequence that launches iPrefs. The thing is, if there is text output before the iPrefs it will produce this alert. This may be one reason why all the startup-sequence commands have their output to >NIL:


Looking at the boot more closely it was easy to see the error messages in the vein of "Monitors/PAL.info.uaem: file is not executable" 

The .uaem files are not part of the Amiga system, but are generated by the UAE (The U#? Amiga Emulator) These files begin to crowd the file system and this experience shows they can actually cause some harm! 

The Amibian likely doesn't produce them, but as I built the install using UAE on Linux they probably came out from that.

So in UAE a file might not only have an .info, but both the file and the .info will have an .uaem too. To represent one item there might be four files which is ridiculous.

Removing the .uaem files from devs:Monitors/ removed the error message.


Modern or not

Time has passed and a lot of desktop conventions have become widely accepted. I was seeking a balance between the "original Amiga experience" and looking for some modest ways to update it.

Back in the day only few of the most used apps were placed as icons on the desktop. I now felt compelled to put as many apps as desktop icons as possible. Furthermore, I put them in a neat line at the bottom of the screen, like the icon strip in Mac OS and others. 

...which is strange as I don't use an app launcher in Linux either, but it does have that handy menu.

While I wouldn't want any additional launcher to clutter the WB experience (a few must exist), at least this could be done.

Workbench Storage disk should have storage/keymaps with different country keymap files. These are then copied to devs:keymaps. After this the desired keymap can be selected in prefs/input.


The Swedish keymap was only a partial solution and I especially kept missing the [ ] characters which are in a silly place to begin with in that keymap. So I have persisted with the "wrong" US keymap.

Although the Blackstorm keyboard I've used is a nice counterpart to the black box and TV, it doesn't have function keys or a numeric keypad.

Even if I had all the keys in correct places, it's not all going to be like 2021.

One widespread agreement is now that Control-C is Copy, Control-X is Cut, Control-V is Paste and Control-Z is undo. Old Amiga software is inconsistent about what keyboard shortcuts to use. And whether to use Control-key or the Amiga-key as the base? How universal is the clipboard?

The shortcuts are likely partly inspired by Unix and partly an own convention. There are mixtures, like the menu item saying "Save" but the shortcut is Amiga+W(for Write).


Even if some programs allow adjusting shortcut keys, it might not work 100%. In AMOSPro editor I could change them but Control-C was out of bounds as it is the "break" key.

While I feel for "u key as undo" (as in Deluxe Paint) I have to agree having undo together with C/X/V cluster makes sense.

A minor grievance is that text generally cannot be marked with a single drag, but has to be double-clicked at first. The Amiga Shell (CLI) actually has a more modern single drag "paint selection" but the other programs haven't all caught on. 

You use Right Amiga+C and V to copy/paste in Workbench. It does work across software, but apparently not in smaller text entry boxes.

Mouse wheels were not really a thing in Amiga's heyday, but now I feel it is indispensable. There's a software called FreeWheel that enables the wheel in Workbench applications, but sadly I only got it working in UAE on Linux, not on Amibian. Possibly the Amibian mouse routines are very minimal.


I actually now like the ubiquitous Amiga top-down, pull-down menus. Nowadays operating systems try to abolish menus, or offer different ways to present the same idea. The rigid pull-down menus don't work that well on touch screens.

The idea of moving the entire screen from the menubar now feels quirky and idiosyncratic, but there are situations where it feels right. It is a suitably disciplined and fast way to have a peek at another program. on a system where many programs wouldn't fit on the same screen anyway. Whether it is better than simply switching between screens or workspaces, I am not so sure.

"Open recent file" function is not a given even now, but appears to be non-existent on Amiga.

Some thoughts

In my memory a real Amiga Workbench on hard disk was a shaky proposition at best, but now it felt surprisingly robust. I can use and multitask nostalgic favorites like Deluxe Paint, Directory Opus, Protracker, AMOS, Asmone and it doesn't come crashing down every 30 minutes.

I know I could have explored different display mode emulations and perhaps get more colours and resolution out of Workbench, but at least for now I'm satisfied with the 4-colours 640x240 mode.

I actually enjoyed, at least up to a point, the need of manual tweaking here and there, having to move and confirm window and icon positions by hand. 



Sometimes I half forget it's not a real Amiga. Even if I accept it's not very genuine it can work as a dry run in the case I eventually have an SD-card equipped, turbo-charged Amiga. I think I could use the hard drive images in a real Amiga too, at least if it has the correct Kickstart. Not that I'm very eager to have such a huge lump of old electronics any more.

I was surprised how smooth Amibian has been with games. But already using Hippoplayer caused some hippo-hiccups. So, although the Amibian setup is well geared for playing floppy games, trying to keep exact time while in Workbench and other environments might be less successful.

Now that I mentioned it, AMOS used to be a huge part of my Amiga experience and I'll likely come back to that on another blog post. I went through the process of installing AMOSpro and the compiler.

QReview Magazine

QReview magazine

Bruce Nicholls has kindly given permission for all seven issues of QReview magazine to be made available via my website.

The magazine ran from July 1993 to March 1995 as a quarterly paper magazine, which focused mainly on reviews, as its title implies.

Richard Alexander kindly scanned the seven paper issues and they are available to download as PDF files from the magazines page on my website.

Please note the fairly large file sizes of the PDF files before downloading.

Download from:

http://www.dilwyn.me.uk/mags/index.html#QREVIEW

A sign of the apocalypse? QPC2 v5 is here

As a developer I wouldn’t exactly say that I thrive on pressure but it certainly is an important element in getting stuff done. QPC2 v5 has been in the works for over three years and I wanted to release it for almost as long, but there has always been this one more bug to fix or this one more feature to add to constantly push it back. Besides, writing software is kind of fun, releasing is not. To release software means updating manuals, creating installers, changing web-pages, and after the release hearing all the things that are wrong with it. In the past this would have been a payed for upgrade, giving at least one more incentive, but now that QPC2 is free this went out of the window, too.

On the other hand it’s sad to spend all those many hours, literally hundreds of them, and not make it available for other to enjoy. So I set myself a release date for today, January 24th 2021, which is not coincidentally exactly four years after the last release. I released QPC2 v4.05 on the 3rd birthday of my daughter and today is her 7th, how time flies!

Never thought we’d celebrate during a pandemic, but nonetheless, happy birthday Marla!

By the way, QPC1 went on sale in 1996, so this is QPC’s 25th year!

So, what’s new? Well, the question is more, what stayed the same?

hg churn -s -f "%Y"
2013  58272
2014     73
2015    355
2016   1946
2017  21275
2018   5031
2019   8603
2020     57
2021    116

These are the number of lines changed, by year. 2013 was the initial transfer into the Mercurial versioning system and in 2017, the start of v5 development, we see quite a lot of activity with over 21000 lines changed. This was the time when I rewrote almost all of QPC’s remaining Assembler parts in C. Of course rewrite means that although it’s a lot of work, for the user everything pretty much stays the same. But having the code in an easier to handle language allows to make more complex changes later on.

Direct3D screen driver

The previous screen driver was based on DirectX 3, the one that was current when Windows 95 was still a thing. And, Microsoft not being Apple, it actually still sort of work 25 years later. But support for it became worse and worse over the years, mainly because graphic drivers have to do their part, too, and no manufacturer still cares for these old APIs. What sealed the deal was that my new laptop didn’t do pixel interpolation anymore for DirectDraw surfaces, making the result look really ugly and me very annoyed.

So after dragging my feet for a few years I finally made the plunge and rewrote the whole driver for Direct3D 11. Direct3D is an awfully complex and daunting beast and not really meant for the kind of usage I need for QPC, but it eventually worked fabulously and I couldn’t be happier with it.

DOS device (Windows file access)

Having the DOS device written in C opened up many venues for improvements without going insane by having to write it in x86 assembler. One of the most noticeable changes is that it now supports QemuLator style EXE headers, a choice that also took me many years to decide on. But with this feature the DOS device is now a first class SMSQ/E device that can actually be used in place of a WIN container.

Another feature is that file extensions by default are now translated to PC format, meaning the last “_” in a filename becomes a “.”. This way files can be used equally well from both within Windows and SMSQ/E. Not everybody might like this, so it can be disabled.

QSOUND

When I bought myself a ZX Spectrum 128 I was intrigued with the sound quality of the old AY-3-8912 chip and wanted to support this in QPC, too. The question was how to best provide an API that can abstract the hardware away enough that QPC’s virtual chip can equally well be accessed as one attached to a PAR port or a native solution.

For the QL there was the QSOUND board with the same chip, which wasn’t a huge commercial success and only experienced little circulation. But at least it was a native solution, so I took the existing API and tried to stay as compatible as possible. Not 100% compatible because QPC implements two AY chips for a total of 6 sound channels and two machine code functions needed an additional parameter to support this, but the rest is exactly the same. I also wrote a player application called AYPlay for some common sound formats. It’s included in the QPCDemo.win file.

Unfortunately documentation is a bit lacking at this point. The original QSOUND Basic commands as documented in the QSOUND manual should work though (try typing “explode” into SBASIC…). There is also a new and original QSOUND device that can be used to stream data to the chips. AYPlay uses this device for example. And AYPlay can also be used to create the data stream necessary from all supported formats, with that music can also be played using a simple COPY or SPL command.

Digitally signed

This is the first QPC executable that is actually digitally signed. This might help some people with corporate PCs because due to security concerns it becomes more and more difficult to install unsigned binaries in some environments. Problem is that this costs actual money and must be renewed every year. We’ll see if further version will still have this.

Misc

The floppy driver has been rewritten and got a write cache to drastically improve write performance.

QPC_QLSCREMU now works both ways. Previously it could only transfer writes to the old 512×256 QL screen to the high resolution/colour screen. This was a problem for applications that mixed direct screen writes and OS writes. Now writes to the big screen are reflected back to the old QL screen, too, making the emulation perfect.

There are slight improvements to the BEEP implementation. This was triggered by fellow QL user Lee Privett, who unfortunately didn’t live to see this very delayed release. Still, this one is for you, Lee, rest in peace.

QPC2 now is not compatible to Windows 95 anymore! Say it ain’t so! XP is needed at least, but even that is so old that you shouldn’t really use it anymore, at least not on anything that is connected to the internet.

SMSQ/E v3.37

QPC comes with the new SMSQ/E 3.37, which was also released today. It’s important to know that the two need each other, SMSQ/E 3.37 is not compatible to earlier QPC versions anymore and vice versa.

Get it

If you made it this far you can finally download the new version here. If you enjoy it, consider making a donation or at least tell the world how great it is 😉

Raspberry Pi Case for Amibian

This looks like a year for the Raspberry. Or the Amiga. Or both.

I already told of my experiences in using Pi/Amibian with a new-found cheap TV (see last post). Although the picture is not the most satisfying, I'm going forward with it. 

First, a look at the Raspberry Pi case. Another time I will make a few notes about the Amiga Workbench/Amibian install itself, which is already up and running.

Obviously I can use the case as a Raspbian computer too by just switching the SD card, but the Amiga emulation was strongly behind this idea.

The Case

Already a couple of years ago I salvaged a very cheap digi-TV tuner, because the case looked like it could be used in a project. I now thought it would pair nicely with the TV, so I finally drilled and cut holes to make the Raspberry Pi fit.


The Raspberry is annoying in how the connectors all point to different directions. This was slightly improved with Pi 2 but there are still three important directions: Power/Display, SD card and the USB/Ethernet.

With an ancient Targus USB-hub, which I also used with this old wooden casing project, at least the USB ports can be redirected elsewhere.

So I only need address two sides and the Raspberry can be placed in the corner.


I had considered putting the memory stick inside the case as an "internal hard drive". However I use the same stick in the real Amiga 500 Gotek drive, so I need to be able to move it quickly. 

Although the USB hub has four outputs, one of them points in the opposite direction. After a mouse, keyboard and a memory stick, there's no room for a joystick. I found a very short extension cable which helped me get the fourth port out. It's perhaps good one of the ports is not part of the hub.

The single USB cable was more difficult to attach than the hub. The USB connector has those flaps which means it can't be simply pushed through the hole it is meant to occupy. The flaps also help keep it in place so they should not be removed either.

I made a rough test with two chipboard pieces in a wide "U" shape. The "U" shapes interlock and keep the connector from being pushed in.  I was afterwards happy enough with the solution so I didn't try to improve it for now.


Three layers would be better as two can't keep the connector from wobbling. 

The small existing rounded opening marked "12V" could be a better place for this connector, but I wanted to try this in the most spacious location. 

Looking from the outside, it also gives an idea how the other ports might be cleaned up.

The material of the backside was pleasant and clean to drill and cut, which shouldn't be a surprise as it is clearly meant to be cut into different configurations. It looks as if the "decoder" hole wasn't very accurately cut to begin with.

A nice change after all those wood and chipboard projects.


One more woe is the minimal micro-SD card, and even now it's not protruding more than 1mm. I don't have a clear picture to show here, but the Raspberry is positioned so that the card comes out just below the metal cover edge.

I don't really need to remove the card that often as the emulator files are on the removable USB stick. I can use tweezers to pull the card out if I want to.


To have a better access to the network connector I used a short extension. Again something I did with that old wooden case.

The RJ45 "gender changer" is plastic so I made a groove around it and inserted it without any additional fasteners or screws.


I recently learned the Raspberry Pi 3 does have an internal wireless network adapter, but this felt more secure than trying to build an antenna.

Time to put it all together. What's nice about this box is the metal cover can be fit into place without screws really, but I can also use two hand-rotatable computer case screws.


So, that's it. The front side of the case is not very impressive, as it is a TV tuner box after all, but at least this time I didn't start the project with designing a front panel. Perhaps badges and stickers here...

The buttons at the front do nothing and could be hidden.

As I said, different types of Raspberry installs could be used here, and not just the Amibian, so I may need to consider this angle too.

Q-Connect Manual

Picture of Tandata Q-Connect modem modules stack
Tandata Q-Connect modem modules stack

Thanks to a user on QL Forum, I’ve been able to add a Replacement Manual for the old Tandata Q-Connect modules for the QL to my website.

Download the manual as a PDF file – it’s about 5MB in size – from the Replacement Manuals page on my website:

http://www.dilwyn.me.uk/docs/manuals/index.html#Tandata

Cover of Q-Connect manual.

Finlux TV

Again, supporting the local fleamarket, a television for the glorious price of 8,50€

The model is a Finlux 24" 24FLK274SVDN, it doesn't appear to have any simpler marketing name. 

It's possible the same tech appears under various different brand names. ("Finlux" has little to do with Finland nowadays.)

The feel is plasticky and it doesn't weigh much. I could easily carry it in a bag.

Last time, I whined about the lack of 50hz displays for my Raspberry Pi Amibian Amiga setup, so I figured this would do at least something to amend it, and if it didn't then the price wouldn't be high.

As a bonus it might even do composite for a real C64 and work as a computer display too?

It has two HDMI connectors, a SCART, a tiny AV and a VGA. Two USBs and an internal DVD player. The internal info-sheet shows a plethora of different modes, video file formats and inputs the TV can supposedly handle.

And that's not nearly all

I punched it in to the Amibian Raspberry using HDMI->VGA adapter, and got some kind of ugly picture to begin with.

Then I took a step back and started experimenting with the options.

Bad news

The TV fares rather poorly as a computer display. I'm not sure if I expected it to do 1080p, the specs (provided in the internal documentation) says it can but in reality the native vertical resolution is 768 pixels. (Or 720, actually)

So the TV can camouflage itself into a 1080p and 1920x1200 resolution, but the scaled picture quality is not impressive on a HDMI. I'm not fully convinced with the framerate either.

Using a Displayport->HDMI adapter a laptop refused to recognize it as a second display, which wasn't nice either.

The VGA produced quite a bad image but this is something I'm now forced to use if want it as a display for the 2nd computer, as they don't have HDMI. (It might not be too horrible as I have only very specific purposes for the 2nd comp).

Removing all kinds of automation (not that there's much) and sharpening, the image can be improved a little.

Good news

After teaching the Raspberry Pi Amibian to do 50hz, scrolling was smooth. For this, I uncommented the 50hz HDMI portion of the Amibian boot/config.txt

This wasn't initially very satisfying as the display scaling would produce artefacts for scrolling games. For this purpose I adjusted the hdmi_cvt line (for custom HDMI resolution).

hdmi_cvt=768 768 50 1

The 1 gives aspect of 4:3, 4 would give 5:4 (Amibian recommended) but does it matter as the TV sets does what it wants anyway?

In the Amibian GUI config display panel, I selected 768 x 256, unticked "correct aspect ratio" and also gave -16 v.offset (maximum), but this depends a bit on the Amiga software. Sadly there's not more offset as some modes won't fit the screen even though the height is unlikely to be more than 256.

Of course, it's worth checking if the TV is in the 4:3 state, and not for example zoom 14:9!

This way, there's at least 1:1 correspondence between display pixels and scrolling doesn't "scale" and games like Battle Squadron, scrolling in multiple directions, now scroll smoothly with no jittering and "living" lines.

Edit: I think the vertical height of the display is 720, which gives a 240*3 as a 256-height screen will be cropped a bit. I don't get how the Raspberry setting of 768 works, maybe it reverts to 720.


Ugly news

Checking the composite and RGB options, I noticed the TV can't handle these signals really, but sort of combines two frames instead of having a proper progressive display. For example if the computer flashes a black and a white frame repeatedly, the result will be a solid gray. Apparently anything that is a non-HDMI mode behaves this way.

With a "life gives you lemons" attitude I could start seeing this as some sort of extra colour mode for ZX Spectrum, but to be honest the idea of building something on a poor display doesn't appeal to me.

Edit: I tried a real Amiga RGB output too, just in case it would produce something different. The picture was actually surprisingly bearable and the frame conflation is not immediately apparent when watching games and demos. Sadly, there was a tiny hiccup all the time in the frame rate. Also, flashing black/white screens finally reveals the same result as with all the RGB and composite modes.


BMC64 and THEC64

It gets a bit weird, trying to get a "fake" C64 to work with a "fake" display. But why would it be more fake than the Amibian+HDMI? Perhaps I find the idea of connecting an Amiga to a modern display more acceptable as it has a history of pretending to be a serious computer.

Also, the THEC64 is by definition mean to interact with a HDMI so it makes sense to see if the BMC64 really functions as a complete alternative to that product.

For the BMC64 c64 emulator I had to at first activate hdmi_safe=1 to verify a HDMI image at all. This produced a 640x480 image.

I then removed the safe mode and advanced towards a custom resolution. I found it's easy to come up with a mode that looks ok at first but again "blurs" two frames together as in the aforementioned RGB and composite modes.

So I copied the parameters from the Amibian config.txt and found the BMC can live with the same 768 x 768 setup. (The config.txt scheme is common to all Raspberry installs) 

With this the 50hz flickering test is passed. Then the display border sizes and stretch factors are adjusted from within BMC. There's still something a bit un-perfect about the horizontal size but at least it matches the pixel resolution somehow.

So I ripped these lines from the Amibian config.txt:

hdmi_cvt=768 768 50 1
hdmi_group=2
hdmi_mode=87
hdmi_drive=2
scaling_kernel=8

I have this Commodore 64 videotest software exactly for this kind of purposes. (1=horizontal scroll, 2=flickering screen (the 50hz test), 3=horizontal alternating lines, 4=vertical alternating lines, 5=checkerboard)

The text is part of the BMC overlay, C64 produces the test image.

I don't see how I'm no longer allowed to "Apply scaling parameters at boot", though. 

Admittedly the "screen ratio" test would be nice to have.

With THEC64, the TV is obviously recognized by the computer and the picture is nice and clean. The 50hz test is passed, horizontal lines are ok but vertical lines have some scaling trouble. This is probably because the device insists on a correct aspect ratio. 

It is more revealing in horizontal scrolling, such as the Giana Sisters intro scroll. Playing Giana Sisters, it doesn't really bother that much.

It's pointless to try to photograph how good the display is

A more thorough head-to-head between BMC64 and THEC64 will have to wait, but I'm now thinking both have benefits. But at least with this particular TV, the BMC64 again comes up with the goods.


The verdict

Had the TV been even slightly more costly, it might have been a disappointment.

But it suits well for the originally intended purpose, connecting the Raspberry/Amibian to a 50hz TV. It even exceeds my initial expectations in that area. For these lower resolutions, HDMI mode colors are good, crisp enough and the black is extremely, deeply, black.

There's soul-searching to do, as it is now the TV would cater both as a semi-retro display and a poor man's computer display, winning more space on the desk. But it's a clear step down for some uses, as it is not CRT and not a real computer display either.

Amibian

Let's have a look at the Amibian Amiga emulator on Raspberry Pi 3.

First I used Etcher to write the .img to the Micro SD card.

First time boot, exit the emulator config screen ("Quit"), use raspiconfig and find the option for extending the SD card filesystem. (It might not be on the first page of menu items). Then Finish and prepare to reboot.


It takes a few seconds to get to the config screen. F12 switches between the config and the emulation.

It's also possible to again Quit to the linux command line and examine the folders and change the various settings. There you can update the system, too. The command line parts have simple assistive menus so I'd think less advanced users might find what they want.

In the graphical config menu again, if the Amiga files are on a separate USB stick, navigate to /media/usb0 to get there.

You can select ROMs (e.g. kick13.rom) from anywhere, but at amibian/amiga_files/kickstarts they will be convenient. 

To get your system to boot as directly as possible to the Amiga Kickstart, quit the config, use "Emulators setup", "emulator config" and "uaeconf1" to select for example config 1 as the one that starts automatically. You can also use the uaeconf1 directly without resorting to the menus. From the graphic config untick "show GUI on startup" at Miscellaneous tab. 

To change or creatively remove the Amibian logo from boot, change the contents at amibian/boot_pictures/

As the linux shell background has been set as blue, it will flash in sight during the boot sequence. This was mildly annoying.

This can be changed by editing the file called .profile (e.g. nano .profile) at the home directory (the one you land at after Quitting the config). Change the "background blue" into "background black", so the boot process looks less aggressive. In theory you could set the font to black too but this isn't very practical as the shell is needed!


Composite video

I was curious about how well the Amibian would show composite video.

This is not an entirely minor point as many modern computer monitors won't do 50hz, but the 1084S does and it's also a period-authentic display.


Using the Raspberry Pi video splitter cable, the tiny audio/video connector can be divided into RCA Composite video and stereo audio.

Changing the config.txt on the Raspberry partition enables composite video output. 

sdtv=2 gives interlace and sdtv=18 enables progressive scan. 

There's an option that enforces HDMI even if no HDMI cable is connected, so this has to be commented out too.

I have to say Amibian appears not to be as sophisticated with video options as the recent BMC64. I will easily get pattern artefacts at least with 1084S. Adjusting the overscan settings in config.txt did not help. 

This may not be a big deal in many games, but it is obvious when making horizontal lines in Deluxe Paint.


How about screen refresh? Trying some games (Battle Squadron, Rodland, Giana Sisters) the screen sync was fine, but the demo Enigma by Phenomena started revealing hiccups in the screen update and there were some graphics glitches too.

This has nothing to do with the composite, as HDMI showed the same effects. But the glitches might also result from incorrect Amiga settings rather than the Amibian as such. 

It's also possible the Raspberry just can't emulate it all fast enough when it comes to more Amiga-specific bitmap and screen handling.


But, arguably the refresh rate was generally more stable than the 50 adapted to 60 on UAE on my Linux+computer monitor. The demo didn't have the glitches on Linux emulation so the adf is unlikely to be corrupt.


HDMI

Less of a purist can go with HDMI and it might be easier on the eyes.

You can't get audio from the composite/audio connector while the HDMI is connected, so you need to depend on your HDMI to deliver that, too. I had a HDMI->VGA/Audio splitter which separated the audio output to a mixer as my display doesn't have speakers (or HDMI for that matter).


A television does better than a computer display, as it is more likely to do 50hz and playback the audio through the HDMI.

My poor ears could not notice any particular audio problems. Of course with headphones the Amiga stereo separation can be unbearable, but as I had the sound go through a mixer anyway I could adjust the situation.


Other considerations

Trying Frontier: Elite II with an anomalous setting of an A500 with "Fastest" speed (I guess the maximum) the game plays quite smoothly. It can still choke on very high detail. The speed can be changed on the fly, and making an eyeball judgment here the "fastest" speed looks like at least twice as fast as the 25mhz setting and the launch from Ross 154 with high detail is quite smooth.

So from this I'd judge there is enough raw power in the Raspberry 3 to run an Amiga, it's just that there are some features it can't pull off that easily, and these can be more apparent in scenedemos. I didn't test a lot of software though.

I experienced keyboard problems when typing, but this meant I had to remove the keyboard from the joystick emulation. After that the keyboard worked ok for AMOS Professional :)


The Logitech Gamepad F310 was recognized easily and worked fine. The config menus can be operated with the gamepad. Putting "Enter GUI" to the start button enabled me to reach the config from the joypad, however the function actually went to the left shoulder button. So a lot can be done without a keyboard if you have set things up cleverly enough.

I would have liked to connect a real Amiga keyboard to the GPIO or at least a joystick. The keyboard would probably require far more work than the Commodore 64 solution.

Edit: I could use the USB wanna-be Competition Pro joystick that came with THE C64 to give some more "authenticity". With Stunt Car Racer it felt better than a modern gamepad.

When connected to HDMI, it's hard to see an advantage or difference compared to having UAE on your main computer, for example running on a second screen. It's of course nice to see the Raspberry is so capable.

With composite video, the nostalgia factor is higher but the video options couldn't get rid of the horizontal line artefacts and it's possible a proper Amiga screen just can't be achieved in all situations.

The best use situation is with a HDMI 50hz television.

Amibian from here:

https://gunkrist79.wixsite.com/amibian

2020

The customary look-back into the year.

Retro stuff = C64 stuff

Apparently I'm concentrating on fewer and fewer platforms. The year was quite Commodore 64-centric, such as toying around with THE 64, 1541 Ultimate II and casemods. More recently, I've worked with the BMC64 Raspberry Pi C64 emulator again.

I did a bunch of 6502 code but only a little of it has seen the light of day. I did release a small videotester for C64, though. PETSCII graphics is small enough to do occasionally. Also I made a couple of tiny demos based on PETSCII, such as the Petmanbatman and Advanced Pet Dragons.


I also got a PETSCII piece out in a paper publication, Kuti #57.

I've done less pixel graphics. I prefer to draw fast and that's hard to reconcile with the pixel aesthetic. Compared to PETSCII it feels time consuming and the results are not that different.

Multipaint got the inevitable 2020 update with transition to Processing 3 and resizable windows. Possibly it finally works reliably on a Macintosh. I'm perhaps hoping to put less time into this project and the 2020 version could be one of the last big overhauls. Many tiny improvements are on the to-do list, though.

On less retro front, I've been playing with a server, more and different Linux installations, a "new" mac and with some help I'm getting to know my way around these systems. Even Raspberry Pi looks more attractive now that I understand more about Linux than 5 years ago, and maybe it's a platform to look at more closely in the future.


Games

Mostly thanks to Proton, I could enjoy new games in 2020. The biggest game I completed was Just Cause 3 which worked nicely on Linux. A very enjoyable and not too long open world destruction romp.

I couldn't finish Nier:Automata, but maybe will return to it eventually as it had some quite impressive parts. It also glitched more on Proton than Just Cause, but was playable. 


Some of the smaller games were Lonely Mountain Downhill and Saboteur Sio

Lonely Mountain was incredibly addictive at first, but when I got bored I got totally bored with it. Perhaps less routes and bikes might have been better so I would have had more genuine motivation to optimize the courses, like with Stunt Car Racer.

It amuses me now how I initially dismissed Surviv.io, a game I first tried at the end of 2019. Then I played it for most part of the year and still play it. The overhauls to the login system and various outages almost put me off it, though. I'm now better at it but even now the results seem more to do with whether the really good players happen to be on-line or not, rather than my inherent skill. Outright cheating/hacking may have diminished somewhat at least.

Chess is still on the playlist but I've been concentrating on it a bit less. I make this complaint every year, and I'll make it again: I feel I could improve if I put even 30 minutes into it every day, but that measly amount would feel too much to dedicate. I did manage to play about 1000 games this year, although mostly blitz on Lichess. Slower chess would be nice but the time use is even harder to justify.


TV, Films, Books, Scifi

For films, the year 2020 was more about re-watching rather than covering much new terrain. Tenet was a memorable film but perhaps not the bullseye everyone was hoping. Well, amidst the worst Covid-19 stupor, this film had begun to gain a messianic promise which it really could not fully deliver.

Doctor Who continued, the episode ideas were good but the writing overall had some problems. No reason to stop watching, though, it's still solid TV sci-fi. In some ways I'd compare it to the first season of the new Who, an attempt to keep the episodes self-contained and finding ways to renew the mystery of the character.

Westworld season 3 started with a bang, what the season 2 ought to have been. But it begun to veer away from the Westworld concept and overall was a puzzling addition to the series. I guess it was meant to deliver the idea that we all live, or are about to live very soon, in a sort of "westworld". As a detail, a lot of people got shot from a close distance in a random and nonchalant way, something that got boring very quickly. 

The 100 came finally to an end, a not so high-profile series that over the years has had its ups and downs. I often felt it built upon watered-down themes from bigger series (Game of Thrones, Hunger Games) but it had its own voice too. The confused last season perhaps took some story-telling elements from Westworld.

The Mandalorian was probably the best Star Wars related thing in ages, but it also reminded me of how bloated the whole SW phenomenon has become. There's a lot of verbal/visual in-jokes and meta-gags, which the series can now afford as there are so many layers to the SW verse. 

The Queen's Gambit mini-series was a fascinating story about chess and a nostalgic look at 1960s US. As a TV series it was able to give more detail to the games and the chess player's practice than films usually do. Given how popular it has been perhaps there will be more chess-themed shows.

As for books, I also kept revisiting the old rather than reading much new things. Well, when I was somewhat ill I did go through Suzanne Collins' Hunger Games trilogy and Stig Larson's Millennium trilogy, pieces of past zeitgeist I had previously ignored. I made a point of reading the Asimov Foundation/Empire/Robot novels in a chronological order and a blog post about it is still in the works.


Onwards to 2021

I'm hoping to continue with business as usual. This blog will have its tenth anniversary in June!