Thursday, 13 June 2019

ZX Evolution joystick port




A tiny upgrade for my ZX Evolution computer, housed inside an Antec mini-ITX case.

As an aside, when I opened the case from the wrong side I noticed there's room for a drive below the motherboard. This has nothing to do with the joystick but I thought I'd add this memo to self here too.




Anyway, the joystick

Sinclair ZX Spectrum had no definite joystick standard, even though Sinclair had provided their own with the Interface I/II. Many games offered the selection between Keyboard, Cursor(joystick), Interface II/AGF/Protek, Fuller, Kempston/12L...

I suppose most if not all, accepted an Atari 9-pin standard one-button joystick. How the inputs were read by Spectrum differed. The interfaces were produced by third parties, and some did not interfere with the keyboard input unlike the Sinclair solution.

Not an unlikely choice
Kempston was the most popular and became a de facto standard. As a child I didn't have a clue what the word meant, but now it's easy to check that Kempston is a town in the UK, and Kempston Micro Electronics is the company that produced these interfaces. They also made some joysticks of their own.

Even after other companies produced compatible interfaces the name somehow stuck. I guess British video game companies and Sinclair also preferred not to have the name 'Atari' shown around so it made common sense to call it something else.

The publisher Ultimate could have helped cement the name and the standard, as they supported Kempston in their games and their games were hugely popular of the early lot.


Making the port

ZX Evolution supports the Kempston IN 31 standard with on-board pins, so there's no need to solder anything. I could also connect to the suitable keyboard rows to make a cursor joystick, but I went for Kempston/Atari.

I had a COM-port extension back panel for PC lying around, and after salvaging the actual connector it could be used as the joystick port.

I had previously connected a transparent acrylic panel to the backside of my ZX Evolution case, which houses the likewise DIY connector for RGB.

This kind of plastic is a bit too hard and tends to break when mistreated. At least the two holes on both sides of the connector are smooth.


I then continued to drill holes to cut out the shape for the interface.

I turned the drill along the direction of the cut to get it behave bit like a saw. This is something I should not have done, but I had no other solution at hand and the whole piece of acrylic might have fractured had I used a larger drill.



I finalized the cuts with a small saw and the center piece fell out. The result was smoothed a bit with a file.

It's a bit crude as the connector is attached from behind and doesn't have the covering piece of metal the RGB connector (that DIN a bit further off) has. However it stays in place firmly and that's enough.


At the top, the new 9-pin Joystick port and the RGB connector. Below: SD, RS-232, micro-USB, VGA and audio/tape plugs.

I had a go at Atic Atac using a TAC-2 joystick. This is the first Spectrum game I recall playing with a joystick, and to my surprise I could now complete it easily. Just remember not to eat every 2nd food so you'll have more spares later :)




Friday, 31 May 2019

Sinclair QL SMSQ/E experience on Super Gold Card

What makes QL literature near unreadable is that there is a long tradition of naming everything in an obfuscated manner :) So, we have QL, SMSQ/E, MDV0_, TK2, QL-SD, WMAN, PENV blah blah blah.

For text-based environment it's handy to have somewhat shorter names for things but damned if it ain't difficult sometimes to remember the keywords.

So welcome again to the Sinclair QL world both wonderful and strange (to borrow a phrase).

What I am mostly looking at is the SBASIC with the Sinclair QL SMSQ/E operating system.

I realised SMSQ/E can nowadays be downloaded freely as a binary and made to work on a Goldcard or Super Goldcard-equipped computer. It's not possible to have a replacement ROM, but the loading time is bearable with Super Gold card and QL-SD card reader.

To distinquish from SuperBASIC, the BASIC in SMSQ/E is called SBASIC. I think in the past I may have used "SBASIC" or "Sbasic" as a shorthand for SuperBASIC but it really is a bit different thing.

I usually feel it's more interesting if the BASIC is contained in ROM, because that is what makes it the standard for that machine, part of the experience of that machine. However, SBASIC doesn't differ that much from SuperBASIC, it's more of an extension than an alternative. So I feel like I'm not violating a huge principle here.

The SMSQ/E integrates the Pointer Environment, Window Manager and the Hotkeys System 2, so I'll touch on these topics too.


Getting SMSQ/E to run and boot

Download the goldcard.bin and rename it for example as SMSQGC_BIN

It's one kind of ordeal to transfer files over to the QL. I used my own solution for transferring files using the HxC Floppy Emulator hfe disk format.

When the file is on your QL disk, it can then be LRESPR'd. (Here we go again with the handy keywords)

I needed the Toolkit 2 to get the LRESPR command. It's a pity that although TK2 is also integrated in the SMSQ/E, it has to be invoked before it can be loaded? Handily the extension is part of the Super Gold Card, although it's curiously slow to activate. But anyway, TK2_EXT is the command.

Then, use LRESPR FLP1_SMSQGC_BIN (or SDC1 if the file is on QL-SD) and the file will be loaded and run like a resident extension.

Well, I can use

a=RESPR(240*1024)
LBYTES sdc1_smsqe_bin,a
call a

...to run the SMSQ/E file without resorting to TK2. I'm not sure if there are any downsides, seeing as the new system discards everything that happened at that point. At least this way I save a few seconds of boot time.

Using JOBS and HOT_LIST after booting through various files
Now we have the familiar divided red-white-black screen. The WTV command might be the first remedy if the image does not fit the screen.

I found I can't use the SDC1_ to reboot to a boot file on that drive after the SMSQ/E has started. The BOOT file has to be on FLP1_ so for the purposes of writing boot files I have my HxC connected to the disk interface of the Super Gold Card.

For example, as suggested above, the boot has to first activate TK2_EXT, then LRESPR the SMSQE_BIN. But after this has been done, the boot will not continue executing the lines, but SMSQ/E will boot again the BOOT file from FLP1_ drive.

So, in the worst case it will simply start reloading the SMSQ/E binary file again! This can be avoided by using

IF VER$<>"HBA" THEN TK2_EXT : LRESPR SDC1_SMSQE_BIN

...which means the file will not load if we are running the boot from inside that version of the system. Obviously the correct version string has to be checked from within the SMSQ/E by PRINT VER$.

After this my system will turn over to the SDC1_ as it is faster than the floppy emulator.

I've understood SMSQ/E uses many of the screen and graphics speed-up routines similar to what used to be in separate extensions over the years. This is not especially noticeable when drawing lines, but the BLOCK command is indeed lightning fast compared to normal SuperBASIC. It might be the Minerva ROM already speeded the lines up, if anything.


Multiple SBASIC interpreters

The Pointer Environment does not mean that on running SMSQ/E you'll automatically see a mouse pointer and menus, it is up to the programs to do all that. But what the PE does do is that the multitasking SBASICs will handle the screen area in a more ordered manner when switching between jobs. Let's look at multitasking SBASIC.

Ineffective, but there it is: Two SBASICs drawing on their windows, on the same screen.
A new multitasking interpreter can be invoked by simply typing SBASIC. You might make a couple of interpreters, and put a program looping in each one of them. It's possible to switch between these jobs with CTRL-C.

QUIT exits the current job. RJOB removes a job with name. JOB_NAME "kekkonen" gives that name to the current job. JOBS lists to jobs as with Toolkit 2, with the job names given.

Sometimes I've experienced that a stopped program may be 'unfinished' so that it can't be removed with QUIT or RJOB. Could it be that files have been left open, I don't know.

On a whim I created a program I called 'jobkeeper', that simply clears the screen, prints the DATE$, lists the existing jobs using the JOBS. It also shows the remaining memory. The contents are refreshed every 5 seconds or so. PAUSE is used for timekeeping.

This way very little resources are taken from the other jobs. It was educational in looking how multiple SBASICS could be set up and viewed from this little 'jobkeeper'.

I notice there are not many ways the jobs can interact with each other via BASIC, I suppose switching to another job screen through a command is a no-no, and can only be achieved with the CTRL-C key or a Hotkey.

I've not looked too much into how jobs might communicate with each other. I've understood they can share channels. In recent versions SEND_EVENT and WAIT_EVENT can be used to send bits between SBASIC jobs. The program that is on x=WAIT_EVENT will be on hold, and after receiving an event the x will contain the information.

Screens grabbed on a real physical QL. I'm so proud! The date is printed by a different job.
As I said the integrated Pointer Environment helps keep the screens clean when switching between jobs. If the different BASIC jobs don't have overlapping windows, you can see the jobs using the screen at the same time. In the above example another SBASIC job prints the clock on top of the screen, above the default window area supplied by WTV. The clock stays visible and be updated while I work on the BASIC program that displays a chessboard.

Messing with multiple windows at the same time can get quite slow quite quickly even on 68020, but by managing time and pauses a couple of SBASICs can happily coexist on the same screen. Jobs that work completely on the background don't slow the computer that much.

One nag I have is the screen MODE is forgotten when switching between the jobs, which results in messy screens when changing to a job that was originally on a different MODE. However this may be intentional and there are situations where it might be impossible to resolve the correct MODE in a satisfactory way. So better try to stick to one mode.


Hotkeys


This is one of the neat extensions integrated to SMSQ/E. You have to HOT_GO to activate it. A new job will remain resident and keyboard can be aliased into commands that should work throughout your system. The normal ALTKEY would just push the commands into current keyboard buffer, which is not that useful. The hot keys can activate other programs and BASIC commands even if you are not on the BASIC console.

This does not mean you can simply activate a compiler via a BASIC command, though.

Normally in basic, supposing I have copied both my compiler, linker and sources to RAM1_ I can do this:

EXEC_W ram1_qmac;ram1_source: EXEC_W ram1_qlink;ram1_source

and make it into an altkey, which again will not work from inside the QED editor as it would simply paste the command there.

QED job window on top of BASIC windows
And, although the above can be run as a BASIC command with the hotkeys HOT_CMD, as far as I see it won't really fly.

Instead you could associate the compiler and the linker to two hot keys, r and t respectively:

PRINT HOT_LOAD ("r","ram1_qmac";"ram1_source")
PRINT HOT_LOAD ("t","ram1_qlink";"ram1_source")

...passing the source file name trunk as a parameter.

Now I can work on a source inside QED editor, and use the hotkeys to compile to check it for errors, without exiting the editor. The fact that I've removed the wait time from my compiler end results becomes harmful; it goes back to QED so quickly I can't really see what the result is!

The HOT_LOAD won't simply accept a raw output binary, and it might be wiser to call the binary outside the QED editor anyways.

Although I can't run the compiler by a BASIC command through the HOT_CMD call, I can get around this by setting a separate, parallel SBASIC program that can be invoked using HOT_PICK. This program could then call the assembler, linker and even execute the result.

I used a bit similar technique for getting the above screengrab from QED. A separate basic job waits for keypress, then waits 5 seconds (for me to switch to the QED job) and stores the screenbuffer using SBYTES ram1_screen,131072,32768. Because this happens no matter what is on the screen at that point, the QED job screen can be grabbed.


Afterword

Years ago, when the standard QL was the only thing I had tried, I asked what would have happened if the Sinclair QL approach got to mature over the years? Well, SMSQ/E and SBASIC is one step in that process.

SMSQ/E and SBASIC powered with the Pointer Extension and Hotkeys shows how cool the original Sinclair QL environment can be when some more thought and development has been put into it.

I like that with Sinclair QL, there is less distinction between using the machine and programming it than in computers like Apple Macintosh (and pretty much everything that came after). This makes it it interesting to tinker with.

I have not really compared the role and functionalities between the Minerva ROM and SMSQ/E.  Minerva functions would deserve a blog post in itself, perhaps some other day. The one thing I notice the dual-screen boot option of Minerva does not seem to mean anything after the SMSQ/E has been launched. This means the code I wrote utilizing page flipping on the assumption of Minerva being present, won't work. The lesson is perhaps: don't assume the presence of Minerva.


After-afterword:

This was the first time I started experiencing hiccups with the QL-SD card reader. At one point the card simply refused to write or delete anything, instead locking up the entire machine at that point, jobs and all.

I tried to re-format the card and copy the BDI disk image there, and this worked for a bit but alas the problem reappeared. I've been told QL-SD is not very compatible with Gold Cards, but as I had so far had no problems I felt I might be lucky. Alas, apparently no. Some more investigation is in order.

Wednesday, 15 May 2019

Linux games test

I noticed there's quite a lot of "big" games available for Linux on Steam. Partly inspired by this, I switched my computer setup to a slightly more able 1050 GPU-based system.

Now I don't have to resort to playing Half-Life 2, Portal or 2D indie games.

Here's a few more 3D-intensive games I've tried, with some completely unscientific notes on how they performed on my 64-bit Linux Mint 19, i5 3.00GHz × 4, 16 GB, 1050 GPU computer.

The native resolution of my display is 1920 x 1200 which is bit too optimistic for recent games.


Tomb Raider (2013)

Already somewhat old game, I could bear to play this through last year on my old setup. This was possible because the play doesn't need to be that smooth.

I recall that I lowered the resolution quite a lot, and turned off the more involved hair simulation(!) that brought the speed down.

At native 1920 x 1200
What was left for me to try how Tomb Raider benefits from the 1050 GPU.

At first I experienced surprising slowdown and tried to remedy the situation by lowering the resolution to 1024 x 768. This resolution can even look a bit crude without the anti-aliasing as the environments are quite detailed at times.

But then I found out that "somehow" it does work quite nicely with 1920 x 1200 by changing various settings, especially when using the FXAA anti-aliasing, which is what you might expect from a 5-year old game. It didn't seem to need the triple-buffering either for syncing.

at 1024 x 768, no AA, scaled to 1920 x 1200
2013's Tomb Raider is a well balanced combination of exploration, climbing and action shooting with some roller coaster type run/jump sequences thrown in.

The puzzle elements are now in optional sub-quest tombs which I felt was a good idea.

Besides the main quest there's bunch of things to do and collect, different weapons and equipment to wield and stats and items to upgrade. Instead of toting the dual-pistols, Lara's main weapon of choice now seems to be the fashionable bow.

1920 x 1200


Everspace (2017)

If there's one game that inspired me to upgrade my computer a bit, it's Everspace, because without 1050-level GPU it just quite didn't work.

Even now I went for 1440 x 900 to make it faster. Strangely I could not get the in-game resolution switcher to work so I pre-set the resolution through desktop.

Gorgeus locations at 1440 x 900
The play requires quite fast frame rate, otherwise maneuvering in the battles becomes too confusing. However, a better resolution would be helpful as you want to sort out details from far off so a balance needs to be struck.

A long time ago, I wanted to play Elite: Dangerous, but as that game is not available for Linux I turned to this as a consolation. In some ways Everspace is really closer to the original Elite, although in many ways it's not. It's been described as a rogue-like in space, which is quite nice description.

The Gunship
The universe is structured as a sequence of bounded small locations, accessed through jump points and jump gates. If you think about it this is not unlike the original Elite, except here the galaxy is not open for free exploration.

The locations are most often filled with detail, multitudes of asteroids and derelict spaceships and other wrecks. Realism and space simulation has been thrown away in favor of condensed situations, again, much like Elite.

Combat can get intensive with drones and auto-turrets blazing.
You'll often encounter hostile ships, either outlaws or the dreaded Okkars, but sometimes you can manipulate different factions to fight each other and only enter the fray at a more opportune moment.

Again, as in most modern games, it's possible to customize and upgrade your ship endlessly, switch weapon systems and acquire special one-off items.


The Long Dark (2014)

Another "oldie", and not too big either, this game would have worked rather nicely on the old setting, as the 3D is not very complex. Now I can play it on 1920 x 1200 resolution with all detail on.

I've not looked at the story mode, as the plain survival mode felt more interesting to me. The game places you somewhere in the wintry northern Canada, and a geomagnetic (read "magical") storm has broken all electrical equipment. You'll simply have to find a ways to stay alive in the harsh environment.

That fog isn't there to clip the view distance... it's there to kill you.
Some of the first moments with the game were quite intense. A lot of effort has been put into producing dynamic weather effects, literally the most atmospheric part of the game.

There's something satisfying in wandering desperately in a snowstorm and then finding refuge in an old cottage in the middle of nowhere. Then you try to get a fire up and running and arrange food and drink before opening the bedroll.

The Maintenance Yard. Those planks will be transformed into firewood.
The illusion begins to break for me as I realized the areas are meticulously designed to have certain amount of exits and inroads to other areas. (Possibly to facilitate the story mode) You really can't get that lost, and the cliffs are really un-climbable, ultimate constraints of the maze.

It turns out that as an abandoned national park, the neighborhood is filled to the brim with equipment, buildings and pathways to follow. A somewhat more generative universe would have been welcome for the survival mode.

Yet again, stuff to be crafted, broken apart to component pieces, repaired and so on and on, but in this game concept this seems more justified.

Saturday, 27 April 2019

Larn Volcano Lottery and Becoming Creator


Spoiler alert! For a 30 year old obscure game!

What's the Larn Volcano Lottery?

Well, it's already described more than a decade ago here. My take is more about winning the easy level fast, whereas the advice on that blog post might be more generally useful for different difficulty levels.

The usefulness of this strategy and the values/costs of items may vary depending on the version of Larn. I tend to play only the online version at larn.org, which has been tweaked a bit, there the LVL works really well only on the easy level.

In short, the aim is to get to the Volcano and grab books and chests, as these sell for amazing prizes. After getting near to 100000, the money can be put into bank. Go through all the classes in the College of Larn and behold, you have enough money for the Lance of Death without having to go deeper than L1 in the dungeon.

It's not really about cheating or circumventing the game, the fun thing about the "lottery" is it is almost like another game inside the game of Larn.

Normally, you would get killed almost instantly in the Volcano, but the Scroll of Stealth prevents that from happening, as the monsters simply won't notice you. However, that scroll alone isn't so useful, as you probably can't find the exit before the scroll effect wears out. So, instead of crawling the dungeons, it becomes a more intense game of route-finding, invention, cleverness, business sense and luck.

The approach also gives a good shot at becoming a Creator, which I'll discuss further below.


Getting the initial funds

So you need to buy these three objects:

  • Scroll of Stealth, because handily the monsters won't move or attack you at all.
  • Scroll of Magic Mapping, because this gives the level map and you can plan your way in and out.
  • Scroll of Pulverization, because a wall or a monster may block your way.

You need roughly 13000 gold to get this holy trinity. Clear the first dungeon level and bring back any scrolls and potions you might come across, never reading or drinking them. Chests and books are always sold, never opened or read, because they can be sold for money.

Don't do anything that might Aggravate Monsters or risk teleportation etc. Trying to get effects from random potions and scrolls is not a good idea with this strategy.

There's nearly always a book and a chest on the first dungeon level, or something that is equally valuable. After selling them you can buy the book from the DND store. This can be sold for good money. After that, buy the chest from the DND store and sell it. You should have above 13000.

If you find a really rare artefact, such as a Device of Theft Prevention, you are in luck as these often sell for more than 10000 and you can stop scavenging instantly. These are rarely very useful in itself.

The scrolls and potions are not brought home for money, as unidentified objects can't be sold. But there is a very rare chance that one of the scrolls turn out to be duplicates of the Three, which increases your chances in the Volcano. You'll identify the scroll types after buying them. Gems are also sold and this is necessary if you don't find anything else of value.

If you have enough surplus money for the Scroll of Identity, you can make sense of your scrolls and potions and perhaps sell them for more than the scroll was worth (fat chance). Not many of them are that useful in the Volcano Lottery anyway.

The Scroll of Hold Monsters is one that can be useful. Expanded Awareness, Enlightement, Object Detection and Treasure Finding might work as poor substitutes for the mapping spell should you need to explore further volcano levels.

Should you try to clear more than the first dungeon level? It takes a bit more time, there's a bigger chance of getting teleport-trapped further down, you might drop into a room full of monsters, and you may encounter monsters that sap your strength, and so on and on. So if you have enough gold, why risk it?


Inside the Volcano

The Scroll of Stealth should be read just before you enter the Volcano, otherwise it won't have any effect there. Immediately after entering, you should read the Scroll of Magic Mapping. Now, take a deep breath and look around for the V sign, which is the exit, and take note of any books (B) and chests (C) you might spot on the way.

My Volcano level V1
In this case, I've been fairly lucky: The volcano exit is near, the staircase to second level is near, and there's a statue (&) at the bottom. (These can be pulverized for the book inside)

I pulverized the Dragon guarding the book at the top, got the book from bottom, and returned, all well within the lifespan of the stealth scroll. I also came up with 10 levels of experience and 50000 gold, not too bad. The books on V1 are not especially valuable, though.

When moving you should take care, as monsters still appear from nowhere on your way and might block a passageway you thought was empty. This is one reason not to linger too long inside the volcano.

With the 50000 I could easily again buy stealth and magic mapping, and a Scroll of Hold Monsters. Greedy, I went to volcano level 2, and was rewarded. I saw a chest and a book for taking, and I didn't need to resort to teleporting at all.

My Volcano level V2
I accidentally hit a gnome king the way back, but luckily this turned out to be not fatal (My character was at level 11 after all) and I could flee. With the chest and book from V2 I became truly rich.

If there's no exit route at all, and the scroll of Pulverization is not enough to clear the way, you can kill a monster with the Pulverization just as in the example above. Make sure it's something that takes you immediately past level 10, as then you can use teleportation with shift+Z. After this it really becomes down to luck, as the teleport can easily take you to any of the three volcano levels, but hopefully it will take you near the exit.

Teleporting, you may find yourself stuck inside a rock and that's it, game over. Additional scrolls of stealth and magic mapping become more valuable here, as you can scan the levels below too.

You can also tickle the monsters with the magic missile spell you already have from the start. This will take the one monster out of the stealth status, and it will start chasing you. If you are clever and the floorplan permits it, you can get around a monster this way.

If the exit (V) can't be seen at all, it could be hidden under an array of monsters. This is nearly always a fatal outcome, but not all is totally lost. Pulverize a monster to get the character past level 10 for the teleport skill. Wait for the stealth effect to dissipate, the monsters begin to move and you might spot the exit and have a snowball's chance in hell of finding your way there. A scroll of Hold Monsters can be a lifesaver. Reading the Books might give you an useful spell, too.


Shopping

Even after getting a couple of books or chests out of the Volcano, you are rarely filthy rich. The money has to be invested.

The College of Larn does absolutely nothing to your stats, it is only for spending time so your money grows in the bank. I only recently understood that this is a satirical joke, probably tied to a very specific time, social class and locality in the history of US. Well, anyway, take all courses, and keep all the other money in the bank.

If even after the courses have run out you still don't have quite enough funds for the Lance of Death, you can walk around the surface to spend some more time. Walking 100 squares takes one mobul, the time unit in Larn. Each mobul spent increases your funds 1/250th. 125000 in the bank, and your funds increase by 500 each mobul. Note that running around with shift-key, won't spend mobuls faster, but will wear out your spells faster. (Larn's time is weird like that)

After you get the Lance of Death, if you can still buy another Scroll of Stealth you can return to the Volcano with a vengeance and simply kill everyone you meet without them knowing you hit them. If you didn't have money for the Stainless Steel Armor the first time, this stealthy rampage will ensure you'll get the funds.


How to become level 100, The Creator

This is something I bothered to do only very recently.

A combination of Stealth and Lance of Death is helpful to up your levels in the volcano. With the Lance, go through the dungeon levels. The only intent is to get your spellbook filled (shoot those statues) and any rings of protection & scrolls of Enchant Armor and Weapon.

If you wield your shield as a weapon, it can be improved with Enchant Weapon. When your AC is 40-50, the volcano monsters cease to pose a threat.

Ramp up your armor and keep any rings of protection and regeneration for the cumulative effect, eventually throwing away other types of rings if necessary. After a certain point energy rings will no longer be useful as your spell count never diminishes.

If you encounter the genocide (gen) spell early enough, it might be handy to wipe out all Spirit nagas (n) as they can still be missed and may produce some nasty random effect.

The end game: You can use Vaporize (vpr) to tease out a Demon Prince out of the altars, each time, preparing each kill with a Hold Monster (hld) or Stealth. But this route is stressful and slow as you have to take care not to step on the altar square.

There's so much junk and trinkets the larn.org reality begins to crack.
When you find a Permanence (per) spell, you can make your stealth and other effects permanent. Combined with Create Monster (cre) spell, you can generate masses of non-moving Demon Lords and Demon Princes at the bottom of the volcano, and then kill them for xp.

After creating 9 monsters around you, you can move down and across to destroy the whole bunch. With Wall-Walk (wtw) you can move inside a solid wall and create the demons alongside the wall as you move slowly within it. Then you come out of the wall, hold the move key to kill a whole row of demons, which I believe is the most time-effective way of gaining xp at this point.

After a mind-numbing repetition and time (watch those mobuls), you'll eventually climb up to level 100. The experience limits do not raise exponentially after a certain level which makes this more bearable.

To me there was no apparent advantage of being The Creator, it seems to be just a title. After all you need to "create" a bunch of stuff to achieve this level, so it's apt. Ha, ha. I did not check if there are any special commands for that status, though.

The character is quite un-killable around level 25 anyway, and especially after the permanence spell almost nothing can threaten you anymore. Funnily enough you as The Creator can still get hit by traps, you can slip when exiting the volcano, fall into the infinite pit, your spells can still fail etc.

Sunday, 14 April 2019

ZX Spectrum ULAplus mode, Multipaint etc.

I was asked to do ULAplus extended ZX Spectrum graphics mode support for the Multipaint painting software.

I was initially reluctant. Multipaint supports only the most established and "culturally recognized" modes, and I've not bothered to make C64 FLI/AFLI modes either, and they don't even require new hardware.

But I then saw that some images might actually come out of it, and seeing as I already own hardware that can display the mode (ZX Evolution) my curiosity grew. It's a challenging mode to work with, and Multipaint might help here.

I suppose a fairly huge proportion of currently active ZX Spectrum enthusiasts would be at least aware of the ULAplus mode. Although there are many modded and patched games and converted images that use the palette, the lack of editors and paint programs means Multipaint could even fill a niche here.

I'd usually prefer to release things before discussing them, but here I'll make an exception as there's a bit more to digest than usual.


ULAplus hardware?

In addition to the already mentioned ZX Evolution, I know about a ZX-UNO computer that has it. Then there is the SLAM drop-in ULA replacement which works on 128k or a +2.

A HDMI video board called the TK-Pie appears to promise these modes too.


Emulators also support the mode. I couldn't get my Linux Fuse patched to support it, but I have the mode working on ZX-UNO emulation within the ZEsarUX emulator. There I have to switch the mode on in the Display segment of the settings menu.



ULAplus and ZX Evolution

I had to update the firmware of my ZX Evolution to make this mode work. The firmware you get from one of the nedopc pages is not recent enough, so I went to GitHub and downloaded the latest zxevo_fw.bin and zxevo.rom. (Go look for the ROM at pentevo/rom/bin/)

I cannot guarantee this is the best option for your ZX Evolution, but at least I have my ULAplus mode working on a hardware speccy.

Upgrading the firmware was easy as I have my Evo inside a mini-ITX case. Wired correctly, I can then copy the zxevo_fw.bin to the SD card, and simply hold down the "soft" power button while plugging the cable in. The power LED flashes a bit and the firmware has been upgraded. These days the ZXevo ROM can be updated from within the baseconf service and it is a good practice to have both the ROM and the firmware updated at the same time.

ZX Evolution does not have a full ULAplus mode, it omits the difference between 6th and 7th level of the Red and Green components. So it might be something to consider when making graphics on the ULAplus.




ULAplus mode in Multipaint

Here I focus on how ULAplus works in practice and what it might mean for someone using Multipaint, although it's not yet definite how it will work.

ULAplus is clever in that it does not make the Specrum incompatible, it simply changes what is done with the memory bits that make up the display file. So, I'm only talking about the most standard mode, which has the same old resolution of 256 x 192 and the 32 x 24 attribute resolution with 256 colours to choose from.

The attribute "clash" is not removed, there are still two colours inside an 8x8 area, and much like with the ZX Spectrum there are rules to how these colours can be chosen.

But as there are more colours and they can be combined in more flexible ways, the look of the graphics can be changed quite radically. I'd go as far as to say the ULAplus experience proves the colour clash wasn't such a huge problem with the original ZX Spectrum, the limited colour palette was.

Here's a diagram that may be more confusing than helpful, but let's try it out:

From Multipaint painter's perspective:

-There is an index of 64 colours.
-These 64 colours can be adjusted with RGB sliders from a total of 256 colours. It is a kind of semi-9-bits RGB palette.
-The 64 colours are really four sets of 16 colours. No colours from two different 16-colour sets can be mixed inside the 8 x 8 area.
-Each of the 16-colour sets are further split into two subsets of 8 colours. The colours inside the 8x8 must be from a different subset. ("INK" and "PAPER")

Just as in the normal ZX Spectrum mode, Multipaint does not care which colour is INK or which is PAPER. This is why I have described the mode in a bit idiosyncratic way.

The internal workings can be partly forgotten by the artist, but still ULAplus is more complex than the ZX Spectrum limitations and it would be better if the artist understood these rules.

My starting point for the ULAplus Multipaint engine was to first prevent any pixel drawing operations that cannot be done, and then attempt to fill in the gaps with some helpful intelligence, without going overboard with this "helpfulness".

An early test of the TAP export, shown on the screen of a ZX Evolution computer.
The 16-colour set is technically called a Colour Look-Up Table (CLUT) and I will now follow that terminology here.

So, if the pen colour is from another 16-colour set (CLUT) than the colours underneath, then Multipaint likely won't allow you to draw on it.

If there is no diversifying pixel information at all within the 8x8 cell (it is filled with 64 pixels of the same colour) and it is not legal to draw with the current pen colour, it will be "primed" by Multipaint with the chosen colour. The area will also belong from that point onwards to that CLUT.

However, if the pen colour is legal the pixels will be added on that square and from that point on it will have two colours in it.

So, two different halves of a CLUT combine to make the colours on the same 8x8 area. It doesn't matter which colours or bits are there internally, just as long as you use the same pen colours that already exist on the area, it will work.

Multipaint allows a small detour here: If there is a way to resolve the drawing operation by using different colours from the same CLUT, this will be attempted. If this won't work, a possible combination will be sought from another CLUT.

For example you might have the colour black (0,0,0) in both sides of the same CLUT, this would facilitate drawing black easily on any colours that belongs to that CLUT without having to pick the correct colour everytime.

If the colour black is present at all sides of all four CLUTs, you can freely draw with the colour black over any portion of the picture, the 2-colour rule of course applies.

Also, if you want to breathe freely and have 8 colours that behave like the Spectrum with no CLUT nonsense, define the colours 8-15 same as the colours 0-7, and draw away!

Powerdrome pitstop from Atari ST/Amiga. An adaptation, not a conversion.
Importantly, the palette will be visually separated to show the 16-colour sets as rows. The artist ought to internalize the idea that the colours within an 8x8 area have to be from within the same CLUT, and from different "sides".


Wednesday, 13 March 2019

QL Tetroid Super Gold Card Clone


First I bought the Tetroid Disk Interface when I should have had the Gold Card. Then I ordered the Gold Card and very soon noted that a Super Gold Card clone also existed. Sigh.

Well, after some waiting I now I finally have the ultimate (?) QL add-on, The Super Gold Card.

Back: The Super Gold Card. Front: The Gold Card
The Super Gold Card has a 68020 and 4 megabytes of memory. The board is somewhat physically larger than the Gold Card. Still, it is smaller than a 1980s version. Again, take care not to grab the computer from the card when carrying!

Looking at the card, it seems Tetroid has got rid of that old Gold Card INGOT chip. If a replacement has been found this promises there could be a supply of these cards as long as there are people to buy them.

Plugged in
This card is sometimes said to be 3 times faster than the Gold Card, which I felt was about 4 times faster than an unexpanded QL. In crude math the SGC would then be 12 times faster than a standard QL. Let's see...

Fiddling with SuperBASIC, the thought came to my mind: Is this really that much faster than the normal Gold Card? 

The experiential, qualitative leap from Gold to Super is not as huge as from the ordinary QL to the Gold Card was. Adding this new speed boost does not give the same feeling as when accelerating the QL the first time.

Having said that, it is clear that when booting up to my environment that copies the QED editor, assembler and source to RAM from the SD card, I can sense the improvement is substantial. Compiling time with QMAC assembler also appeared faster.

So, I did some stopwatch tests on a few BASIC line drawing loops and assembler compiling. I ran the same programs without a card, with GC and the SGC. All the time the QL-SD card reader is present and supplies the Minerva ROM.

A BASIC line drawing program that takes 30 seconds in the non-accelerated QL, took 8.25 seconds with the Gold Card. With Super Gold Card, this was reduced to ~4.5 seconds.

The assembler compilation+linking task that previously took about 5 seconds on GC was now 3 seconds on SGC. I couldn't test the compiling on the unexpanded QL in a comparable way. I guess I could use the Tetroid Disk Interface to get enough memory for that.

These times are not super-accurate, but I'd say in everyday practice the card might be closer to being twice as fast than the Gold Card rather than three. Compared to an unaccelerated QL it's 8 times fast. Possibly the 3x or faster speeds can be achieved in only certain contexts.

Below I have a comparison table between Tetroid Disk Interface, Gold Card clone, Super Gold Card Clone and the QL-SD.

                      TDI      GC       SGC       QL-SD
Card Reader:          YES(CF)  NO       NO        YES(SD)
68000/Acceleration:   NO       YES      020       NO
Memory:               800K     2MB      4MB       NO *)
Disk interface:       YES      YES      YES       NO
Battery-backed clock: NO       YES      YES       NO
Toolkit 2:            YES      YES      YES       NO
Minerva ROM:          NO       NO       NO        YES

*) The file allocation table requires memory

Saturday, 2 March 2019

Bare Metal Revolution (?)


Some years ago I asked myself, "surely someone must have written emulators directly for Raspberry Pi hardware?". At that time there were a couple of promising but incomplete attempts at writing a C64 emulators for the Raspberry Pi.

Now it seems in the meantime these projects have become more mature, and I am clueless about these recent developments (as usual). Now even I can easily try two "bare metal" emulators on the Raspberry Pi.

Bare metal sounds like it ought to be a musical genre, but really it's intended to mean that the emulator does not reside on top of a conventional operating system, like having Fuse Spectrum Emulator on top of Linux.

This is not to say the emulators are coded bit by bit on the processor, but at least without a full OS I guess spurious memory, swap or disc accesses can be avoided altogether and it becomes possible to achieve very fast boot time and rock solid frame rates.

I was also attracted by the possibility of composite video output which I expected to make the experience more 'real'. More about that below.

I tried two emulators, the ZXBaremulator and the BMC64.

In both cases, the relevant files are copied on a FAT32 microSD card. The C64 needs the kernal, chargen, basic and d1541II files too.

Lines in config.txt can be used to adjust how Raspi sets up the video image. Which leads me to give you a...


Foreword & Warning:

I may have ruined my old Sony portable TV by changing the display resolutions, overscan modes and their parameters for the composite video. The TV started smelling a bit bad and the composite image begun wobbling, turned yellow with color components misaligned. Ouch.

I can't say my fiddling with these emulators is what caused the death of a 30-year old TV, could easily have been a coincidence. I wouldn't blame the emulators or the Raspberry Pi in any case.

However I did try varieties of video modes that might not have been too friendly to the TV.

Progressive scan. The camera is what makes the screen look distorted.

ZXBaremulator


First one is the ZXBaremulator, a ZX Spectrum emulator. It's not clear to me if this is based on some existing software. Just a hunch it is not Fuse, looking at which options are there and which are absent.

Boot time is near-instant. Pressing F1 brings up the file menu, Alt-K gives keyboard help. 128K and +2 are also emulated, so enjoy those AY sounds. Tapes can be loaded by selecting them on the menu then using the LOAD "" or the 128 Tape Loader. A reset+auto-load would have been nice.

Thankfully the tape (TAP/TZX) loading has been speeded up. It's not instant like on big-computer emulators, but a lot better than no turbo at all.

With composite, Raspberry Pi outputs something like 480-pixel height screen through interlacing. This is somewhat helped by doubling the lines, so the Spectrum 256 x 192 screen area is really a 384 pixels tall, add borders to that and the vertical space is filled.

However doubling the lines doesn't quite get rid of the 'flickering' quality of the graphics, which becomes more obvious when white and black horizontal lines are repeated.

On my Pi2B+ and Pi3B+, the composite can output progressive scan, so I could get remove the flickering by changing a line in the config:

Instead of sdtv_mode=2

I can use

sdtv_mode=18    # progressive PAL

This is not without problems as the result can be blurry and/or has interference patterns from scaling.

Using disable_overscan removed the interference type pattern but the blurry scaled result is not perfect either. The screen is solid and this at least proves to me the interference is not an inavoidable TV artefact but a result of the raspi scaling. Looking at checkerboard and horizontal line dithering patterns, these become overtly mixed, as if the dither really formed a new color.

When playing games, the slight blurriness does not matter as much as the flickering did, but fonts can look a bit garish and the end result is not especially authentic.

+128K modes and AY sounds too
+SD directory structure supported
+Helpful key overlay & menu screen

-Can't load snapshots (z80, sna)
-No support for 9-pin joysticks


Watching that Gianna Sisters smooth scrolling
BMC64

Emulating Commodore 64 is no small feat, and here the results are also admirable. The frame rate is smooth, as can be proven by looking at the Great Gian(n)a Sisters intro screen for minutes and minutes. The emulation is based on Vice, so it ought to be pretty good.

The overlay menu is nice but apparently there are no key shortcuts?
The C64 palette is not as harsh as the ZX, so the flickering on composite is not as immediately apparent. However, it's there and using black/white line patterns shows it.

Using sdtv_mode=18 in the config.txt again kills the flickering, but no amount of fiddling with the disable_overscan and overscan values can remove the interference pattern like could be done with the ZXBaremulator.

Thinking of a real case, the large texts made from thin horizontal lines in Wizard of Wor become affected by the scaling.

I'm unsure if this is a result of the emulator author making a choice or not. The supposedly 'real' aspect ratio is not in my opinion as important as getting a resolution that scales well.

So the results are not as promising as with the Spectrum in this area. So here I'd say endure the default 480i flickering if you want to use the composite. The interference pattern is there too but it's maybe less conspicuous.

Scaling artefacts.
The Raspberry Pi GPIO pins can be connected to real Atari/Kempston 9-pin joysticks. This was easy to do without soldering, using a suitable connector and jumper cables. Just remember the GPIO numbers are not the pin numbers, check the GPIO-numbered pins within the connector of the particular make of Pi. They ought to be similar though.

Using a 9-pin joystick such as TAC-2, it became easier to judge whether there is a lag or not in the emulation. Using the composite connector with a CRT and the GPIO-connected TAC-2 joystick, I felt the lag was negligible or non-existent, I really couldn't complain at all.

Using the HDMI television, I felt the presence of a noticeable lag in games with very crisp controls, such as Buck Rogers. Whether the particular TV is to blame (most likely) or if the HDMI connection always produces some delay, I can't say. Still I'd think even this lag is acceptable for many games.

Maybe more about this later...
The disk loading is real time, so get used to waiting. Ok, it's possible to use an Epyx Fastload cart image to get a faster loading speed (for me a 25 second waiting time was reduced to 11) but that's an extra stage too.

An Action Replay VI cart image did not work as I would have hoped. Carts obviously run instantly but I only tried some 8K and 16K cart images for now. (It's not an accident the test games mentioned here are cart images, they load instantly.)


+Nice overlaid menus
+Selection of palettes
+Support of 9-pin joysticks via GPIO

-SID emulation could be better? No 6581/8580 selection?
-No SD directory structure support
-No PRG loading support?


But why?

These emulators are a fantastic job overall. But do *I* need something that lies somewhere in-between real hardware and an emulator running inside normal OS, especially as I have both options already?

Well, it's another interesting project to mess with, and it would be fun to build a case for a new ZX or C64 as the Pi is so tiny. It might be handy to carry and show 8-bit games and demos to people without having to lug all that old hardware, yet having something more than just an emulator on a laptop.

The composite image modes turned out to be a bit of a mixed bag, so perhaps I'd go with HDMI here after all.

Again, I have to warn about the dangers of fiddling with the video modes too much on an silly old TV. I'm not sure if framebuffer_width affects the composite image at all but I had that included on my BMC config when I fried my TV.