Saturday, 3 March 2018

Amiga 500

Ah, the Amiga. What can I say? Amiga 1000 may have been the first, but it's the relatively affordable Amiga 500 that won over people's hearts in the late 1980s and early 1990s.

Yes, it's easy to get a bit emotional about the Amiga. Somehow it was possible just to stick in floppies, play games, watch demos, draw with Deluxe Paint, and not care too much about the world. With A500, Workbench appeared great but unnecessary, Amiga BASIC was laughable, Assembler simply could not be learned by mortals. The software sometimes crashed a bit too easily, with that immortal line "Guru Meditation - Software Failure". But you could play minesweeper while your file downloaded from a BBS. There was a speech synthesizer that could be made to utter truths about your brothers. A clockface that could be displayed while there was another window open. Directory Opus. CygnusEd. Multitasking.

Amiga was the games machine. Interceptor, Time Bandit, Pandora, Wild Streets, Sky Chase, Firepower, Sword of Sodan, Cosmic Pirate. Crazy PD games like the Egyptian RunZerg and Top Hat Willy. Workbench games, Unix conversions, PC conversions, 8-bit conversions.

I hope he got that extra ram.
It's been said the demoscene was properly born on Amiga. But from the periphery, we'd happily watch any old presentation in early 1990s, whether from "legit" sceners or not. Gaudy copper bars, spherical bobs, wireframe vector graphics, ripped game graphics, glenz vectors, silvery metallic logos, tracked music with Italo disco samples, Garfield scans co-existing with Kraftwerk, Jean-Michel Jarre, Axel F, Miami Vice theme, Acid House, digitized Star Trek, copies or tributes of Larry Elmore, Hajime Sorayama and Boris Vallejo.

Long sinewave scrollers, multiple scrollers, circular scrollers, stretching scrollers, unreadable scrollers, copper-colored scrollers, endless scrollers, vector scrollers, star wars scrollers, scrollers that start with "yyeeaaaoooooaaaahh!!!", scrollers with accusations of lamery and calling your arch-enemy a "faggot" (an unfortunate aspect of the early demoscene).

Time's not been kind, but at the time it was better than TV.
Megalo from Wild Copper, and the Deathstar Megademo were some of the earliest material I saw. For me the first demo that showed some kind of consistent styling was Universal Pictures from Unique. Clearly it's not aged that well, and neither has that Miami Vice remix from HCC.

As the 1990s progressed, I learned about demoparties (but did not attend), Scoopex: Mental Hangover, Enigma from Phenomena, Spaceballs: State of the Art and 9 Fingers, 242, Kefrens: Desert Dream and so on and on, and although it was all very grand something had already vanished. Suddenly it was all techno/breakbeat/funk and "design" and by the way aren't the best demos always something you had seen back in the day?

Naturally, with blitter filling.
Having an Amiga was bit like enrolling into a media school: I'd learn first hand a bit about graphic design, composing music, sampling sounds, creating animations, 3D-modelling, programming. AMOS Basic teached me something about planning larger programs and writing games but maybe also prevented from learning other languages sooner. I tried my hand in assembler but could only write small subroutines to support the BASIC code.

Emulation really started with Amiga and emulators like ZXAM showed that simpler computers like the ZX Spectrum could run games, although you'd need A1200 speeds to do that. Many hours were spent with revisiting ZX Spectrum classics and also the ones I thought I'd never see in my life.

Many times seeing this, too
I'm wondering if the later developments did Amiga much good. Sure it was great to have a hard disk and a faster processor, but PC envy started to hit hard, and the concern was trying to better the PC in it's own game plus some.

PC games like Ultima Underworld and Falcon 3.0 were pretty worrying, but especially Doom seemed like a watershed moment, Amiga had lost the (bouncing) ball. At the same time console games appeared to do that other thing better, too. Doom was eventually ported to Amiga, but then 3D cards entered the scene and eventually homogenized graphics across all platforms.

Yes, a TRS-80 conversion. Why not?
And that brings me to a difficult point. Although one hears rumors of Amiga's comeback over the years, something about the idea of an Amiga revival seems a bit off. Can the new Amiga now do WWW properly? Javascript and HTML5? Can it play HD video? Can you plug a GPU to it? Can you stick USB devices to it? If not, then it's too off mainstream to gain any real traction. If yes, then it would be a bit similar to any current computer. Perhaps a well thought-out decidedly hobbyist computer built around a specific genealogy of a GPU might represent an "Amiga" these days but don't expect many to buy it.

Thinking it now, the Amiga happened in such a short time. Generously, one could say the overall Amiga phenomenon was relevant for about a decade. But that intense time with the A500, a few summers, really. Maybe it really does get a bit emotional here.

Sunday, 25 February 2018

Chess memories

Although we played chess as kids, it was initially nothing more but another diversion among Monopoly, Rubik's Cube and the Finnish evergreen board game Africa's Star. But the longevity and richness of chess became evident quite soon. For some time in the early 1980s, we loaned chess books from the library, my father built chess sets, we played chess against friends, family and against the computer.

Some memories about children playing chess:

-We played a few games with the assumption that a player can 'eat' the enemy king if the other player does not notice it is under threat, winning the game.

-Castling was initially unknown, and even then it was quite long misunderstood. We probably used it as a means to escape with a threatened king, which is not a legal move.

-The en passant move was unknown to us. Also, for a long while a misinterpretation of a book illustration made me think the move is only doable on the edge of the board.

-The checkmate was pretty difficult to plan so it usually involved locking the king with two towers or the queen after the board had become suitably empty.

-The endgame was pretty often reached by bashing together all the high ranking pieces on some contested square, turn by turn, until the forces were exhausted.

-There was a sadistic tendency to eliminate all enemy pieces and pawns before attempting checkmate, something that was prone to result in a stalemate instead!

-Sometimes it was fashionable to build a "cannon" by lining the two towers and the queen, then "launched" against the enemy lines. This was possible because both players were trying to do the same thing with little regard to what was happening on the other side.

-Similarly, one of the earliest notions of a fixed opening defensive strategy was to lay out all pawns in an annoying zig-zag pattern. Combined with the other quirk of mirroring other player's movements, this could lead to some very silly openings:

Now, the proper game can begin.
Later I nurtured a misperception that I might be a good chess player, despite never really winning more than low level computer opponents. When I got my ass handed to me by a human player I could never beat even by accident, I realized in a concrete way there were skill levels far above my play.

Recently I've benefited from annotated chess puzzles and reading more about chess strategies, such as the reasoning behind evaluating board conditions - it's not only about counting your piece values. Sacrifices are no longer just exchanges in a desperate bid towards a checkmate, but justifiable from different angles, such as improving positions, breaking the enemy lines, and gaining 'tempo'. Still, it seems my ability is fluctuating quite a lot, possibly depending on time of day, tiredness, stress level etc. 

I've also read a tiny bit of the history and the development of the openings and play styles. I'm glad to see there are varieties and schools of thought, so I might not have been too wrong in not concentrating overtly on classical openings or failing to grab the board center.

Chess connections

Although I never became a proper chess player it somehow connects to many things:

PSION's Chess on the ZX Spectrum
Retro-computing: Chess was among the first games I played on a ZX Spectrum computer. Chess computer devices were also one item among the early electric landscape of hand-held games, video games, pong TV games and toys etc. I never had a chess computer, though, as we leaped directly from non-electronic games to computer and video games. An old chess video game has a certain retro appeal, but the CPU thinks so slowly it's not too interesting to play against them. Later, the visuals in Amiga Battlechess was one memorable moment, but not as interesting as a game. I also played a version of Chessmaster on the PC for a while.

Making stuff: From craft and design point of view, it is fun to see how the appearance of chessmen have changed over times, depending on times and culture, eventually narrowing down to the Staunton and variants. A good set takes into account readability (color contrast and piece separation), handlability (those grooves and ridges), balance (weighted won't tip over) and sturdiness (so the chess pieces won't break when they fall).

There are also other constraints, such as the needs of a travelling set or a low-res computer display. Devising a chess set might be interesting too, but so far I've only doodled and worked on a PETSCII chess set with Marq.

Could get a bit confusing in a real game.
Games: Chess is a prototypical example of a game. Although it is themed as a war-game, the war theme is more of a learning device for showing the purpose of the game, the individual chessmen and how they move. Notably the later chess pieces became styled after the royal court rather than a battlefield as such, so the chess board might be also seen as a metaphor for political plotting and subterfuge.

Films and popular culture: Chess is shown in films and stories often as a kind of indicator of super intelligence, such as with Mr. Spock's 3D variant in Star Trek, or the few moves mentioned in Blade Runner.  More points if the players can play without the actual board, such as Holmes - Moriarty in Sherlock Holmes : A Game of Shadows. The "chess played with live chessmen" cliché goes also at least as back as Alice through the Looking Glass and variants come up regularly, as seen in Harry Potter, Twin Peaks and Kurt Vonnegut's All the King's Horses.

Recent computer versions

For a while I played some version of chess on an Apple iPad, but sadly I can't remember the title. As the novelty of touchscreens wore off for me I barely bother with installing 'apps', even though board games work rather well on them. Chess on Android is pretty ok, I've tried to beat level 7 without success.

Recently, I also installed gnome-chess on Linux which has extremely clear graphics, and excellent for reviewing pgn files. But apparently the difficulty level cannot be trusted to be equal across different computer setups. Edit: I now understand this depends on what kind of chess-engines have been installed on your computer, and this may vary depending on the install. HoiChess was easier than GnuChess, although it is not obvious why GnuChess is so damn hard on "easy".

Online, lichess is good for on-line head-to-head games and for editing the board. I also tried, but it seems to have all kinds of superfluous and confusing things on top of the actual game.

Wednesday, 24 January 2018

QL assembler

Lately I've turned into a bit of a QL-nut, and now I wanted to try coding assembler on it. Most of the files and initial info are from Dilwyn Jones's comprehensive QL web pages, particularly the assembler and archiver pages.

Although vasmm68k on Linux is very useful, there are limits to what kind of code can be run on an emulator. It's not easy to find an emulator that a) works on Linux, has b) cycle-exact scanline video emulation, has c) flexible transfer between it's own filesystem and the PC and is d) free. UQLX is nice to have, but as far as I know it does not do screen flipping/vsync in the way a real hardware does.

So I went the route of compiling 68000 code on the QL hardware platform itself. After all, it is a semi-16-bit architecture with 800K of memory. With modern media, it should not be excessively painful to code on this system.

First I tried a tiny assembler called Adder, but only on my unexpanded QL it goes past the initial screen, so I moved to the larger Qmac assembler/linker package. This is a bit of an overkill for the things I want to try out, but at least it is convenient and does what one would expect from a full assembler.

I also tested asm20 at some point, but after a promising start it seemed a bit too incomplete. I failed to find a way to include binaries, and as I could not turn off the listing (opt nolist does not work) it becomes quite slow for even small sources.

I'm wondering why a quick editor/assembler/monitor setup like Asm-one or K-Seka on the Amiga/Atari ST does not exist for QL, or if it does, where is it hidden?


So, over to the Qmac/Qlink package. Installing is not too hard once you get the hang of transmitting files over to the QL. Just unzip the qmac package on your Sinclair QL drive.

It should be remembered that QL archives need to be unzipped on the QL filesystem, as PC/Linux extraction tends to mess with QL executable file headers. To get around this, there's an already-unzipped version of unzip, and a BASIC file that repairs the header for that file.

After this has been achieved,

exec_w flp1_unzip;'flp1_archive_zip' 

will start storing the files from the archive_zip to flp1_, if they are on that drive.

After the qmac file is unarchived, it is a good idea to copy the assembler, the linker and the source to a ram disk, if you have the memory to spare, as it should always be faster than any drive.

Afterwards, the executables can be run directly from the ram drive:

exec_w ram1_qmac;'ram1_source'

where 'source' is the assembler source text file with the name source_asm, here assuming it is in ram.

exec_w ram1_qlink;'ram1_source'

and this would result in a source_bin file.

Running the binary:

a=respr(size): lbytes ram1_source_bin,a: call a

For a relocatable code file, this would then reserve some unused memory space, load the file and call it. The size must be enough to contain the binary size. For non-relocatable code, the code should be loaded to a "safe" address and called from there, such as 196608 on an unexpanded QL.

ALCHP and LRESPR might be more handy but I tend to avoid running the Toolkit 2 extension unless I need it, as it's a few seconds more boot time :)

The commands above also show how to pass parameters to executable files. Note that EXEC_W executes the file and exits, whereas EXEC would run it as a job.

Running QED text editor

QED is a nice little text editor for writing the assembler sources. Loading QED, the file definition has to be a bit more explicit:

exec_w flp1_qed_exe;'flp1_source_asm'

Use F3 to enter the command mode in QED. X saves & exits the editor, Q exits.

By the way, with a television monitor the QED window size may need changing. Be sure to download a QED version that includes the BASIC configuration file. This config program brutally overwrites the QED binary with your chosen parameters, which is handy in that the QED can then always be copied as one file.

The configuring program may complain of a missing variable, as the window size function calls are part of yet another non-universal extension package. Insert something like this at the beginning:

10 SCR_XLIM=512: SCR_YLIM=256

Boot files

The above won't go very far in establishing an effortless edit/compile cycle.

But with boot files and the superBASIC procedures, much more can be done. Besides, creating useful boot files on Sinclair QL is somehow more fun than scripting on modern computers.  Use colors, graphics, whatever you like. Hey, it's BASIC - but with procedures!

My boot file will copy the assembler, linker and my current working source and related binaries to a ram disk. From there they run almost instantly.

They could be copied from the HxC Floppy Emulator disk image, but the QL-SD sdc1_ drive is much faster than the HxC, so the files are copied from there.

20 print "Copying to RAM..."
30 copy sdc1_qed_exe to ram1_qed
40 copy sdc1_qlink to ram1_qlink
50 copy sdc1_qmac to ram1_qmac
60 copy sdc1_source_asm to ram1_source_asm
70 copy sdc1_datafile to ram1_data_bin

Obviously these can be made into it's own function that gives on-screen information as the files move.

In absence of a real makefile, I have a defined procedure called MAKE, just to have a similar compiler command on QL as on my Linux:

100 def proc make
110 exec_w ram1_qmac;'ram1_source'
120 exec_w ram1_qlink;'ram1_source'
130 end def

After all this, MAKE will assemble and link the file source_asm, and as a result there will be ram1_source_bin.

Executing the result can be made into a procedure too, just remember to reserve enough memory to fit the binary, otherwise it will behave erratically=likely crash.

I called this procedure SYS to have it short and as a nod to the Commodore computers.

10 a=respr(8192)
200 def proc sys
210 lbytes ram1_source_bin,a
220 call a
230 end def

If the code is to be loaded to a fixed address, the LBYTES should load it directly and no RESPR is needed.

Also bear in mind that apparently plain BASIC is not able to free the memory taken up with RESPR. So the memory should be reserved once in the boot file, not inside the procedure. As long as you don't re-run or load another basic program (and you don't need to) the variable is kept in memory.

Some extensions have commands for allocating/deallocating memory from BASIC, such as the ALCHP mentioned above.

A procedure for launching QED with the current source is also desirable, as a sort of alias for the long command line.

250 def proc qed
260 exec_w ram1_qed_exe;'ram1_source_asm'
270 end def

Development environment options

So, after the boot file has been run, I can type QED to edit my current source file, MAKE to compile it, SYS to run the code. More shortcuts can be created for producing disc backups out of the RAM files, etc. Instead of command procedures I could also create a key-press based environment.

As Sinclair QL is a multitasking system, the QED text editor can also be run as a parallel job with EXEC instead of EXEC_W, flipping between QED and the BASIC prompt using CTRL+C. This has the advantage I don't have to exit QED so the cursor position is not forgotten. The self-defined BASIC procedures remain in effect. Also, I can view and edit the source as the compilation runs in the background.

Whenever screen update happens on another job, the QED screen gets messed, and there is no screen refresh when you switch a job. In QED, F5 key at least redraws the screen.

Dual QL setup

With the above setup, if the code returns to BASIC neatly, it's possible to go on modifying the source without having to boot up the QL after every code test. Obviously, if the program crashes the system has to be rebooted, but having all the current materials auto-copied at least reduces the chore.

The crashes and re-boots resulting from wrong code can be alleviated by having two Sinclair QLs connected with a net cable, one as the compiler and the other as the target. Although this is probably more trouble than it's worth, I had to try.

One approach might be to assign NET values to each of the QLs and use LBYTES neti_2,address type commands for loading in the resulting binary data.

It gets crowded in here...
But, after fixing my EPROM cartridge with an FSERVE-enabled Toolkit II, I can also finally enable a file server between the Minerva-equipped QL and the unexpanded QL with a TKII cartridge. (The fileserver does not work from a RAM-based toolkit.)

With the file server, it becomes possible to access files from drives connected to the first QL, referring it with n1_ or n2_, for example. Commands can take the form of EXEC_W n2_flp1_qed_exe

The file server works if you remember it's not all-powerful - trying to do complex things such as compiling across the server and editing text at the same time may result in the computer getting stuck. Trying to poll a file every few seconds over the server was not such a great idea either. Even if I managed to get the QL stuck, in most of the cases the actual server job survives, so files may be recoverable.

So, instead of the LBYTES neti_ - SBYTES neto_ approach I can use the file server to load and run the binary off the ram disk of the other QL.

The second QL does add some unwanted physical complexity to the setup, and obviously the crashing target QL needs to be re-booted too.

Another thing is the other QL does not have Minerva so my page-flipping routines need a different approach and the code can't simply return back to BASIC. But more of that some other time.

68008 assembler

A few snippets of my early code. I'm only here interested in plain QL coding, and my code likely won't work in the later variants.

Still, I try to be nice-ish, and make relocatable code, mostly because it's useful to have the code return to BASIC intact for further editing (see the setup above). But I've not loaded the screen address using the QDOS call and neither do I care about potential graphics screen variants.

The following code will fill the usual screen area and return to BASIC without an error message:

    MOVE.L #$20000,A0   ; starting from 131072
    MOVE.L #$3FFF,D0    ; $4000 words = $8000 bytes
    MOVE.W #$AA00,(A0)+ ; bit pattern
    DBRA D0,LOOP        ; loop until d0 is 0

    MOVEQ #$0,D0        ; return to basic

The Qmac likes to have SECTION and END.

Note that using + with MOVE.W will "hop" the A0 address in 2-byte steps. With MOVE.L it would be 4.

Next thing to ponder is why the following code might be faster than the previous:

    MOVE.L #$20000,A0
    MOVE.L #$7FF,D0
    MOVE.L #$AA00AA00,D7
    MOVE.L D7,(A0)+
    MOVE.L D7,(A0)+
    MOVE.L D7,(A0)+
    MOVE.L D7,(A0)+

    MOVEQ #$0,D0

With 68008, I'm told it would be wise to have as much as possible done through the registers, as the speed issues (versus 68000) are not such a huge problem.

Some have gone as far as to say the QL is "really 8-bit", but as the opcodes are equal to 68000 and much more than 65536 bytes of memory can be accessed without writing any paging routines, I'd say it's a true 16-bit world for the coder.

The verdict

I'm surprised it's still possible to get accustomed with coding on the QL itself. Today's card readers and the memory expansion are very helpful in this. The largest problem is that the Qmac is not that fast, especially as the source begins to grow, but it has been useful in getting to know 68000 and the QL.

The QED text editor block copy/paste functions are a bit primitive compared to modern editors, but overall the typing experience is not that bad. Sinclair keyboards are a bit of an acquired taste, but I've found I can live with the QL keys.

It's been a long and rocky road to get the Sinclair QL make these things. But it has also been quite rewarding. I've been working with a sprite routine, something I'll come back to later.

Sunday, 7 January 2018


I thought it would be nice to re-cap the year 2017, addressing some topics that did not quite make it into blog posts. Still, keeping to the theme of the blog, I won't flood this with personal notes and work-related stuff.

I'm usually able to maintain the twice a month pace with my blog. The most viewed posts are still the ZX sprites article years back, blog posts detailing Schneider EuroPC and Orel BK-08, and strangely enough, the piece about spaghetti western guns.

Although C64 and ZX Spectrum received most of my attention, Sinclair QL has re-emerged as another favorite, although a very challenging platform. I guess I'll be continuing with more detailed notes about QL in near future.

I'm also trying to expand the blog format with platform-specific pages, starting from a QL overview  that binds together relevant blog posts. I'm envisioning a kind of personal encyclopedia, but time will tell how this might develop.

Releases, coding, events

At the beginning of 2017, I revised my Multipaint paint program and released it as the Metal Edition. It's now beginning to be a usable software and I'm glad to see others have created great images with it.

I've received far more comments and queries about the software over the year than before. Most times I try to accommodate, but occasionally people ask for image formats that in my mind are out of the scope or spirit of the software (such as more modern RGB modes). The development continues and a new version can be expected in Spring 2018.

In addition I've created a few pics myself.

Earlier in the year, I contributed to Desire's Don't Mess with Texas TI/99-4A demo with a single picture. It was an interesting experience to make something with a "megagroup". Co-operating through a Slack channel and Facebook messenger, I found that the huge amount of comments, suggestions and discussions can be both a blessing and a bit of distraction. All in all it turned out good, but also reminded me how desperately Multipaint needs an aspect ratio switch...

The bottom is empty as it's the play area
The most recent work is the above half-image for the International Karate graphics competition at CSDb. I chose to do the Helsinki Cathedral in spirit of the original game graphics. The perspective is problematic as here the fight would take place on the stairs, and the bottom/top half joining cannot be resolved so well. I'll see if I still have time to make another piccy...

Similarly, I continued to create text art in the form of PETSCII images, all the time using Marq's PETSCII editor.

Although the logo for Hokuto Force's Sliced Blue is from late 2016, I'll mention it here.

2017 was the first time I made C64 "dir art" and pure C64 BBS graphics, which brought some more limitations to the PETSCII format. BBS graphics work with control codes and generally use a lower-case variant of the set, with black background.

With this experience I realized a BBS pic doesn't need to have the ASCII/ANSI/2x2 aesthetic I often associate with BBS art.

BBS graphics for the Rapidfire BBS, possibly a WIP image
One more addition was the graphics part of the tiny Vammala Party C64 intro called Nothing but Pet Ski. This animloop was fun to make, and PETSCII editor supports this kind of animation creation rather effortlessly.

I also co-edited a journal issue with the theme of Text Art with Marq, including PETSCII, ASCII, teletext, typewriter art and boundary crossings between "high" & "low" art, history and the present.

As another PETSCII/Text Art related thing, I rewrote some of my 2016 Fort Django code on the C64 and released a 1.1 version with a complete new map and soundtrack. (Ooh, another firstie: a published C64 SID track!)

I'm sitting on another near-finished Commodore 64 game, but I could not release it in 2017. I'll try to look for a suitable outlet for it. Expect even more lo-fi and PETSCII aesthetics and crappy SID tunes.

Zoo Party 2017 was one of the scene/retro highlights of the year, and I wrote a bit about it too. All in all I managed to contribute to many small compos, either online or remote, which I won't mention here.

During 2017, I observed that my 8-bit assembler (6502 and Z80) coding has advanced to the point I no longer need to rely so much on c bits to structure my programs, as certain coding practices and a good assembler facilitates most of the necessary things anyway. Releases are still scarce, as finishing projects tends to be far more difficult than starting them!

In a more modern track, I've continued with with Javascript web coding, adding some threejs webGL to the mix. Browser-based code is becoming more potent all the time, so you don't have to be a coding guru to make nice interactive stuff. One could even say HTML+JS is the "BASIC" of our time.

I also made first time PHP code, which was a lot more straightforward than I thought. Certain needs also forced me to write a few Python scripts, which I also found quite amusing.

Games, Films, Books, etc.

I'll be quick with games, as I don't play that much. I probably spent most time with Larn at, and Clive Townsend's Saboteur 2 remake was also a very welcome diversion. I occasionally play through Ultima IV and this also happened last summer.

This year, I've watched less westerns than before, and even those were not that memorable. I'd say re-watching Dead Man was one of the highlights. On the western front, I'd rather revisit the classics than continue scraping the bottom of the barrel, although that will probably go on too. I tried to read a few western books but to be honest they didn't quite grab me.

The one stand-out fictional work of 2017 for me was Twin Peaks: The Return 18-part TV series.  Lynch/Frost et al. managed to create something emotionally so devastating, that the imagery and mood of the series lingered in memory weeks after it had finished. It simply made any other TV work seem stale and formulaic in comparison. The somewhat tough pre-requisite was the watching of the original series and the Fire Walk With Me film.

Time and Time again
Doctor Who continues to be one of my favorite series, although it might be said the last season was a bit overstaying its welcome. A few years back Peter Capaldi's more mature doctor (well, in appearance anyway) was a welcome turn for the series, but now the writing has struggled a bit and the showrunner/writer Steven Moffat has perhaps used up his box of tricks. Then again, as far as I know the ratings have been suffering for a few years and the problems may have resulted from trying to revitalize the series' popularity. With the oncoming 2018 season, I'm now expecting at least season 5 scale reboot, on with the new doctor!

At the movies. Valerian was a bit better than I expected. The world-view and the plethora of alien races are whimsical and Valerian-like, and the theme of technological/institutional/corruption versus "natural" harmony is also present. Casting wasn't as awful as I envisaged, but the characters have been rewritten as silly jerks and the charming dynamics between them in the original comics, has been lost. Also, a lot of time is spent on chaotic action scenes and awkwardly falling through floors / walls etc.

Blade Runner 2049 was stylistically interesting, but story-wise it felt a bit empty. With Interstellar/Arrival-style production and Hans Zimmer soundtrack, they were maybe playing it a bit safe. It was still quite gorgeous experience at the cinema, I'll admit that. Harrison Ford's involvement and the appearance of certain character from the original film could have been scrapped in my opinion. Unlike in the 1982 film, the bad guys were a bit poor show.

Coincidentally or not, I've been re-reading Philip K. Dick. Do Androids Dream of Electric Sheep?  was a much forceful work than I had remembered, and although the story lacks some of the film's crowning moments it also has some superb material that the film rejects. What motivated Deckard to have such a dangerous job? Well, he wanted to buy an expensive animal for himself. Although some aspects of the new film may have been influenced by the book, I am surprised they did not mine the original more for ideas. Oh, and the book mentions 3D-photographs :)

I read Frank Herbert's Dune for the first time, one of the last really major sci-fi works I had not experienced before. Sure, I've played the Amiga game a bit and seen the Lynch film years and years back so I kind of know what it's about. I enjoyed the world-building aspects of it, and can easily see how some themes found their way to Star Wars. Yet the story has quite silly bad guys, and some of it reads like a teenagers wish fulfillment fantasy, of how special and world-changing an individual can discover himself to be.

We put a dune in your dune so you can.... nevermind
Speaking of Star Wars, I also saw Last Jedi. Count me in with the "meh" crowd. The new film attempts at undermining of the Star Wars and Jedi mythos, without necessarily giving anything substantial in return. An enjoyable ride nonetheless.

Instead of the common criticisms, I'm more worried about the haphazard structuring of the new films and a general disregard towards the coherence of the originals. Characters simply appear as force ghosts, holograms, disembodied presences and whatnot. Whatever character the creators want to bring in, can be brought to the screen at any moment by some contrived device. The distinct, simple physical spatiality of the original Star Wars universe seems to be gone.

2018? More of the same I think!

Friday, 15 December 2017

ak tronic EPROMkarte 256k

This is an ancient device for the Commodore 64 I got a few years back. The on-board chip appeared to be corrupt and only now I've had a chance to re-write the binary, which gave it life.

What is it? Truth be told, I'm not exactly sure what it is intended for. I guess it can be seen as an alternative storage device. It works as a 8-chip "carousel" cartridge EPROM switcher with the software-based selector menu burned in the 9th chip.

Hold your horses, though, it won't run your freeze/fastload cartridge collection. Even if the device accepts 8K, 16K and 32K chips, it will only run 8K-sized chunks which rules out most games. I tried Gateway to Apshai 16K binary, but it won't run.

(As an aside, it seems some early C64 games were a bit minimal not because the programmers couldn't do more, but because they wanted to fit the games inside a 16K cartridge space...)

This is model 2140 from ak tronic, perhaps from around 1984. There's some info on net but less binaries to replace the corrupt chip. After some searching, I could find the binary for the on-board EPROM, for a similar REX 9574 card from Rex Datentechnik.

The device binary was inside a D64 disk, so I had to take two bytes off the beginning to get the 8192 byte length. A similar procedure needs to be done for any emulator cartridge files (.crt), but more bytes have to be stripped off. The CBM80 identifier is helpful, but I don't see it in all binaries, what's with those carts?

The file length is usually the best clue, 16384 for true 16K binary, 8192 for 8K and so on.

Running the C64 I am greeted with a menu for selecting one of the 8 chip slots, show the directory or enter the "modul master", which I guess is a tool for annotating the chip contents.

After selecting the chip I have to select what kind of chip it is, a 2764, 27128 or 27256. If the chip is larger than 8K, I also have to select which half or quadrant of the chip I am running.

A couple of boring 8K things I got up and working:

-Assembler and Monitor (SYS 700 for asm and SYS 32777 for monitor)
-Calc Result (needs a disk so it's a dongle really)

If you insert 8 x 32Kb EPROMs on board, you get the theoretical 256k, but in 32 x 8k portions.

For burning a 16K EPROM I can append two 8K files to make up a 16K binary with the cat command on Linux:

cat filename1 filename2 > output_filename

Switching EPROMs from software:

Looking at the manual, there are a couple of routines to access the chip memory without resorting to the main menu.

After exiting the card menu, this should run it again (if the control EPROM has been selected).

X=PEEK(57280): SYS 64738


Card addresses:

$DFC0 (57280) : Switch the card on/off
$DFE0 (57312) : Switch control/user EPROM
$DFA0 (57248) : Select the EPROM chip #

This way an EPROM can be selected:

POKE 57248, half/slot
X=PEEK(57280): REM switch on/off the card

The user EPROM needs to be on too.

The half/slot value is construed this way:

2764 8KB chip:$30 = 48

27128 First half: $10 = 16
27128 Second half: $30 = 48

27256 1/4: $00 = 00
27256 2/4: $10 = 16
27256 3/4: $20 = 32
27256 4/4: $30 = 48

The lower nybble indicates the eprom slot 0-7. So $31 (49) selects the second half of the 27128 at slot #2.

In assembler, this subroutine selects/deselects an EPROM:

* = $C000
C000        LDA #$10        A9 10
C002        STA $DFA0       8D A0 DF
C005        BIT $DFE0       2C E0 DF
C008        BIT $DFC0       2C C0 DF
C00B        RTS             60

Then call $C000 (49152).

The first half of the first 27128 EPROM now occupies space from 32768 onwards. Then SYS 64738 ($FCE2) runs the cartridge if that's what is needed.

For some reason, selecting slots was not always successful, the manual indicates $10 and $30 for selecting the 8K halves of a 27128 chip, I tend to find that $20 and $30 work more consistently... but perhaps not always.

I've not been able to reproduce these anomalies reliably. I found myself checking whether the cart memory was truly present, scanning the memory contents from $8000 (32768) onward. Possibly I don't understand something, or the card is a bit faulty from age.

For this reason I've not tried to change the control EPROM code, because the selector there at least works reliably. This also makes me think there is more to know about the routines.

Oh, and when the cart is on (57280), Basic seems to behave erratically and the disk device fails to work.

Sooo... Maybe it's not a too useful device in these days, but let's see if I can come up with something fun. As the EPROM memories can be paged in via software, for example some kind of animation could be played back from the chips.

Thursday, 30 November 2017

Sinclair QL EPROM

A 28C128 EPROM chip can be connected to the Sinclair QL through the 16K plug-in cartridge ROM port. The memory occupies the space (0xC000-0xFFFF).

I can't guarantee this is the 100% definite way to do it, as I haven't been able to compare this to an existing EPROM cartridge. But it worked for me.

The diagram below shows the basic connections between the QL ROM port pins and the EPROM, with a 7400 chip between.

The 7400 IC should be connected to the 5V and GND too. In addition, two capacitors should be connected to 5V / GND near the two ICs. I had 100nF, which I hope to be ok.

In the above diagram, the NAND gates represent the activity of a 7400 IC for combining the signal of A14, A15 and ROMOEH, connecting the final output to the pin that controls the EPROM enable state. (Low=enable) The data lines should only be active when all of the A14, A15 and ROMOEH signals are high.

I was unsure about the role between -G (gate control) and -E (standby), as the device works when connecting both together. According to the EPROM datasheet the -G is used to set output enable/disable whereas the -E can be held low for device selection.

"Data is available at the outputs after the falling edge of G, assuming that E has been low [...]" makes me think that it's not a big deal timing-wise but it might be clearer if E was low all the time.

I have three QLs, and my first cartridge attempt worked in one of them. This led me to waste time thinking the "fault" could have been something about the differences in the QL models. In this version I had left the A14 and A15 floating, assuming the ROMOEH signal is enough to indicate the 16K area is addressed.

However as it should have been quite obvious from the start, the signals of A14 and A15 need to be combined with the ROMOEH, as the ROMOEH signal is high whenever the whole ROM area (0x0000-0xFFFF) is being read, not just the 16K area.

I used a Toolkit II ROM as a guinea pig. The onboard ROM (version JS) seems to find it "twice" which I hope is normal. The TK2 functions can be activated with the TK2_EXT command and all seemed to be ok.

An EPROM cart like this isn't especially useful these days, as many modern expansions do not work at the same time. Full 64K on-board ROM? Can't use the port. QL-SD? Can't use the port. Tetroid Disk Interface? Can't use the port. So, I'm left with a QL that can have a 16K EPROM and pretty much nothing else.

However this might be the beginnings for making something else, a transfer device etc.

Edit 14.12.2017: I burned 2.20 version of the Toolkit II, which has the FSERVE fileserver. The file server works nicely from the ROM module and is a quite powerful function to have. It alone justifies this little project, maybe I'll write about it later.

The parts list:

-27C128 EPROM + 28 pin socket
-7400 NAND chip, such as SN74LS00, + optional 14 pin socket
-2 x capacitor, I used 100nF

(Ignore the top image which has all kinds of unnecessary things added to it.)

The board

I have been hunting for a good PCB prototype board that would suit the project. It should be obviously with 2.54mm raster and double-sided so that it may have something that works as an edge connector.

I ordered a set from eBay with different sizes. The 50 x 70mm board with 18 x 24 raster is simply a perfect fit for the QL ROM cartridge slot, and there are 16  pads at the edges that just about work for the connector after modifying the board a bit.

The sixth position is cut off, to a depth that includes only the first through-hole. The QL case slot is wide enough for the 50mm width so nothing else needs to be cut.

The prototyping board and the blade for removing through-plating.
The raster holes are plated through, and as the pads are very short, this means the holes would immediately short the top and bottom connector pins. I suppose a variant without through-plating might exist, but it is difficult to tell from the eBay listings.

I rotated a paper/exacto knife blade from both sides of the hole, this way I could get rid of the through-plating from the row nearest to the pads. After all it is a very thin layering. This needs to be done briskly enough so that the chipping away can be felt, yet carefully enough so that the holes don't get ruined.

In the first row I need to be certain there is no contact between the two sides, no dust or thin filaments. This phase adds a bit of tedious handiwork.

The cut could be deeper but then the next row of through-plating should be removed too. One row is just enough for holding the cart in place. The pad width acted as a good guide for the cut width in this prototyping board.

What follows after is likewise tedious connecting of the pads to the chips by wire, for both sides. There shouldn't be too much solder on the pads, so I tinned the wires beforehand and tried to carefully connect them to the pad edges. Even then I made a bit of a mess, and I cut away extra solder with the paper knife.

There's a method for creating paths by solder for this type of board, but it's also slow and results in huge lumps of solder. I used wires for connecting nearly everything.

Friday, 3 November 2017

Sinclair QL Tetroid disk interface / memory expansion

The Tetroid Disk Interface is a memory expansion, disk interface and card reader for the Sinclair QL. It adds 768K memory to the 128 of the plain vanilla QL, totaling the memory to 896 kilobytes.

I ordered this from Russian Federation via eBay, with a Compact Flash (CF) card thrown in. The seller is identified as "tetroid" around forums and SellMyRetro site, so the interface is called Tetroid Disk Interface. The device can be considered an extended clone of a Miracle Trump card for the QL.

Fitting inside the case

Looking at the board, I check the jumpers are in good position for the plain QL, as instructed by the manual leaflet. Three jumpers turn on/off the disk interface, the QUBIDE/QUBATA interface and the extra memory.

Before I could get the card to fit, I had to whittle away just a tiny amount of the plastic from the QL with a paper knife. After this the card slides easy along the rails and fits comfortably to the extension port. The card sinks in completely, only the CF card protrudes slightly over the QL footprint: beautiful.

First boot up experience

Booting the QL with the included Compact Flash card, my first thought was: "It takes a bit long to get to the BASIC". But the CF card is filled with goodies and extensions that load on start-up, so the QL eventually ends up with a sort of graphical desktop.

Glancing at all the start-up messages, there are ToolKit 2, Q_Liberator (basic compiler?) , TURBO TOOLKIT (another basic compiler?), Pointer Toolkit, Qmenu, Scrap, History Device...  The CF card contents are a very thoughtful inclusion and makes me already feel I have something new to explore. (Edit: It seems I've maybe misunderstood this a bit, it's not that all the above software is on the card, but the related runtime libraries needed. Anyway, there's a bundle of things on the card)

As the QL has multi-tasking, a notepad, a calculator and a BASIC command line window can be open at the same time. The GUI is a very early effort, many windows often show functions and technical details that are text-based anyway. All this is very interesting, but not my focus now. Perhaps at a later time...

Now I can move to writing on QL...
Funny to see that there is less than 480Kb left after everything has been loaded. That's still three times more than the normal 128, which wasn't all usable anyway.

Without the CF Card

Next I took the CF card out and booted the QL again. (Don't insert/remove the CF card when the power is on).

Boot time to SuperBASIC is fast, but I guess checking the 800K memory adds a bit to the process. I shed a tiny tear for every second added to the boot time, because for me directness is a major charm of old computers.

Left: Showing memory in BASIC, Right: after running the TK2
The Tetroid manual leaflet obviously does not explain how to use your QL or the extensions. It doesn't even describe the Trump card functions, so the manual for that device is recommended reading.

The PRINT (PEEK_L(163872)/1024-128) command I found from a QL forum can prove the 896 K of memory is there. But to make things more simple, the Toolkit II can be summoned from the interface. TK2_EXT command gives the command set. Now I can PRINT FREE_MEM to show the remaining memory. JOBS shows the multitasking jobs, FSERVE starts the file server, ED runs the improved BASIC line editor.

The floppy drive, if it is connected, can be accessed from FLP1_ and the Compact Flash card is WIN1_. If the FLP1_ is present the QL will run the boot file from there.

With this amount of memory, a RAM disk starts to make sense. Multiple microdrive contents could easily be run from the memory. The default virtual drive is RAM1_ and again the Trump Card manual is your friend.

It's also possible to break out of the CF card boot basic file (SPACE+CTRL). This way I can have a peek at the WIN1_ drive from SuperBASIC without loading all the files into memory. The boot file can of course be altered to stop the commands from running next time.

Using HxC Floppy Emulator

The Compact Flash card does not show up on my Linux system, as the CF card is apparently in a format that can only be accessed with a Windows-only image editor and the QL itself. As far as I understand, there's no way to read/write files directly like you would with the mountable images inside a ZX Spectrum DivIDE CF cards. There's also probably no easy way to access the image file with Linux at the moment.

Well, I have my HxC Floppy Emulator. It took some steps to set up, though, so I'll put my notes here for future use.

The basis for the following is the document Using an SD Memory Card with the Sinclair QL, which contains information about the disk format parameters.

There are a bunch of Jumpers at the backside of the HxC. The organisation of these may vary from model to model, I have a boxed one with the pins bending backward. To make the HxC work with my QL, the jumper needed to be at the top left corner:

To get the HxC Floppy emulator windowed utility working on Linux, I followed these instructions exactly:

(I have Linux Mint 18 Sarah 64-bit). The command line version does not seem to be sufficiently detailed to generate these kind of images.

After running the HxC Floppy Emulator, I followed the how-to document mentioned above.

Use settings to tick out "auto", and choose Generic Shugart, which probably is the default anyway.

At the HxC main panel, use Load RAW Image to get to the screen below. Configure the format according to the specifications from the "Using an SD card..." document, or follow this image at your peril.

I ignored all the parameters that could not be followed from the document.

I tried to generate an empty image with "Create Empty Floppy", but although the HxC accepted the image, the QL did not recognize it. (Edit: It might have needed formatting)

I then used Load RAW File to load an existing DD raw image that is based on an emulator file. This I did not create myself, but downloaded from a QL forum. It may or may not be available.

After OK'ing the result, it can then be exported from the HxC main menu as a .hfe file. Copy this to the SD card.

On the QL end, the HxC device is connected to the Tetroid. Turn on power for the HxC device. Select the hfe image. Turn on Sinclair QL. The drive is recognized as FLP1_ in SuperBASIC.

Here I have powered the HxC from the 5V / GND pins of an Arduino, which has no other purpose here. When powered with an 9V adapter, the 5V output should have enough amperes to run the HxC. Powered from an USB, maybe not so much. Anyway this may not be ideal and I'll move to a PC power unit when feasible.


I once looked at an SD card reader device called QL-SD. This was a very cheap alternative, a replacement for a microdrive, including the Minerva ROM upgrade in the deal. However it also took out some memory away so for a 128K machine it was also a bit of a downgrade. Moving files from and to the SD was also not straightforward as the files were inside a disk image, again not so easily accessible from Linux.

The Tetroid interface also adds RAM and the floppy interface, an all Trump card functions, something the QL-SD did not offer.

Do these devices work at the same time? I have not yet tested, but I think there's no reason why not.

26.11.2017: Addendum

I inserted the TDI to my QL-SD equipped Sinclair QL, which has the Minerva ROM (JSL1) that came with the QL-SD. The TDI works nicely, and depending on the three TDI jumper settings, I can get one or two of the drives on-line, but never all three of them.

Jumpers on:
J1: Memory : SDC1_ is available
J1+J2: Memory + Floppy : FLP1_ and SDC1_ are available.
J1+J3: Memory + CF : WIN1_ is available
J1+J2+J3: Memory + CF + Floppy : WIN1_ and FLP1_ are available.

At least all drives can be reachable in some ways. With configuration J1+J2 I could move files between HxC and the QL-SD, and with J1+J2+J3 between the CF and the HxC.