Monday, 30 April 2018

Adding weights to chess pieces


A proper Retrogaming mod: I added weight to my cheap chess set.

This required a lot of boring stuff with a power drill and a crap selection of drill bits.

First I removed the felt, evened the surface a bit and punched entry point markers using a drill tip. Already removing the unevenness and the poor felt the pieces kept more firmly upright.

I then drilled all pilot holes with a thin 2-3mm drill. It would be good to get these straight, but as I did not want to build a setup for this I had to accept some deviation.

Then, 6mm holes. This was maybe the easiest part of the whole drilling process, as the 6mm drill cuts the material pretty easily. The drill needs a tape marker or a limiting piece to avoid drilling too far. I did think I could "feel" my way but after a couple of mistakes I had to attach the tape. A very simple measure that avoids a lot of hassle.

Not to scale
I drilled all 10mm holes using a two-piece jig to hold the piece more firmly, then inserted the screw.

The simple jig only half-does the job, I had to secure the pieces with my other hand. Luckily the piece bottoms are all the same size, not really how it ought to be, but at least this way they all fit the same jig.

The 10mm drilling was quite tough and kludgy to do, I found it useful to switch between reverse and forward gear while drilling.

It would have been much better to drill the 10mm holes before the 6mm ones to preserve the function of the pilot holes. But the 10mm is already a bit tricky with a power drill and the drill head is not the best quality. So I reasoned the 6mm holes could be done first to remove material and make it a bit easier for the 10mm.

The jig hole is covered with furniture pads, so I did not really need to unclamp the thing.
I used longer screws for the Kings and Queens so they have a teeny bit more weight to them than the other pieces.

The light bolts do not radically add weight, but it's enough to give a bit of a feel to them. For a while I thought about using some kind of lead pellets, but the screws have less work stages to consider and I already had enough of them. Even if the machine screws do not properly attach to the wood they still stay firmly enough on their own.

I also made some changes to the appearance of the pieces, I'll get back at that when the set is more finished.



Sunday, 15 April 2018

AKAI MidiMIX & Processing Midibus



I got this AKAI MIDImix USB controller. It's principally meant for Ableton, like apparently half the stuff nowadays is. My only real interest is to connect it to my computer with the Processing MidiBus library.

Previously I have have been messing with MicroKORGs, Electribe and a Nanokontrol 2, so a controller like this is not a big deal. Compared to synths, the major difference is that the lights can be set independently of the key presses. They even need to be set because the physical button presses only send information about the key press itself and do not change the light state.

I'll look at the Processing midi library a bit and then at the AKAI mapping.


Midibus

MidiBus is a clever library for Processing that eases the use of MIDI considerably. It handles input, output, program change, control change, raw midi data on multiple channels. Here I'm not going into song player routines, which are a bit tricky but doable. (The Midibus does not have a player).

After installing MidiBus to the Processing install, this will activate it in the source:

import themidibus.*;

void setup()
{
  MidiBus.list();
  mybus=new MidiBus(this,1,2);
  println(mybus);
}

The "(this,1,2)" can be adjusted to input and output of the given list of MIDI devices you get from running the sketch.

The MidiBus.list() produces a list to the console with the relevant information. My USB/MIDI interface is an UM1G, and as the AKAI MIDImix works through a separate USB cable (not a MIDI cable) it will be listed as a separate device:

Available MIDI Devices:
----------Input----------
[0] "UM1G [hw:2,0,0]"
[1] "Mix [hw:3,0,0]"
[2] "Real Time Sequencer"
----------Output----------
[0] "Gervill"
[1] "UM1G [hw:2,0,0]"
[2] "Mix [hw:3,0,0]"
[3] "Real Time Sequencer"


After the Midibus has been set correctly, sending a note is simple:

mybus.sendNoteOn(midi_channel, pitch, velocity);

You need to shut the notes too:

mybus.sendNoteOff(midi_channel, pitch, velocity);

For example, these could be directly inserted within the Processing keyPressed() and keyReleased()events to facilitate a simple MIDI keyboard.

Control Changes for things like Modulation Wheel, Cutoff, Resonance, can be sent like this:

output.sendControllerChange(midi_channel, CC, value);

Just as an aside, some devices use NRPN (Non-Registered Parameter Number) for similar things. In such cases the data has to be sent as raw MIDI information. This worked for my Korg Electribe:

output.sendMessage(0xb0, 0x63, 0x05);
output.sendMessage(0xb0, 0x62, NRPN);
output.sendMessage(0xb0, 0x06, VALUE);  

The 0xb0 signifies MIDI channel 1, whereas 0xb1 would be 2, and so on. Good manufacturer manuals and datasheets should give Control Change and NRPN values for each device.

But it's also possible to find out the CCs and note values by displaying the incoming MIDI data. The values can shown by adding controllerChange() and noteOn() events to the sketch:

void noteOn(int channel, int number, int value){
  println("Received note channel:" + channel);
  println("Received note number:" + number);
  println("Received note value:" + value);
}

void controllerChange(int channel, int number, int value) {
  println("Received CC channel:" + channel);
  println("Received CC number:" + number);
  println("Received CC value:" + value);
}  


AKAI midimix

Ok, back to the MIDImix. Physically, the knobs could have been taller, it's not easy to get a good grip of them. Also the faders could have been a bit longer but this is less of a problem. Yet the MIDImix is compact and quite cheap, although not as cheap as a Nanokontrol might be.

The nice thing with these modern controllers is that the data is transmitted through an USB cable and it's also USB-powered, so no power cable / MIDI cable hassle.


AKAI works on MIDI channel #1, and I didn't see how it could be changed. For the purposes of my tests I simply disconnected the MIDI cable from my UM1G box.

All potentiometer and slider values are Control Change messages with the value 0-127 with them.
The buttons are "keys" that send a velocity of 127 with them.

Potentiometer CCs:

I   II III  IV   V  VI VII VIII
16  20  24  28  46  50  54  58        TOP ROW
17  21  25  29  47  51  55  59        MIDDLE ROW
18  22  26  30  48  52  56  60        BOTTOM ROW

Slider CCs:

19  23  27  31  49  53  57  61  (62 = MASTER)

MUTE button Note values:

01  04  07  10  13  16  19  22  (27 = SOLO)

Individual SOLO button Note values: *)

02  04  08  11  14  17  20  23

REC ARM button Note values:

03  06  09  12  15  18  21  24

Bank Left Note value:

25

Bank Right Note value:

26

Solo button Note value:

27

*) Holding down the "SOLO" key shows the individual SOLO status for each channel instead of the MUTEs. So, sending a SOLO light change only shows up if the "SOLO" key is held. In other MIDImix devices there may even be separate lights for the SOLOs. Pressing the "SOLO" key does send a note value, though.

Sending note-ons to MUTE, REC ARM or Bank button values with velocity 127 will turn the associated lights on. Sending note-ons with velocity 0 will turn the lights off. Sending note-offs does nothing. The "SOLO" key cannot be lit this way, possibly there's no LED at all.

Pressing SEND ALL will cause the MIDImix to send all the above values in succession. This key also may not have a LED in it.


Tuesday, 3 April 2018

QL Tetroid Gold Card clone


Last year, I was so eager to get Tetroid's Disk Interface for the QL I didn't notice Tetroid's Miracle Gold Card clone - that would have been more interesting for me. I cursed myself a bit, waited for some time, then decided to order it anyway.

The Gold Card has a 68000 processor, a floppy disc interface, battery for backing up the clock/date and 2 megabytes of memory. I had a slow moment, thinking, "How can this be, the QL cannot address more than 1MB?" But of course the 68000 can access more memory than the 68008, that's the whole point.

The speed increase (~4x they say) is the main reason I was interested in the Gold Card. The speed is not about processor frequency, it's just that the 68000 does not need to "convert" 16/32 bit instructions to a 8-bit data path the way the 68008 does.

Theoretically, if a program is coded in a way that avoids 68008 bottlenecks, it might not be radically faster on the 68000.

The even faster Super Gold Card is probably eventually going to be cloned too (I'm hoping), but I just could not wait.

Unlike the Tetroid Disk Interface (TDI), there is no Compact Flash card reader built in. The Gold Card has a floppy disk interface which together with my HxC Floppy Emulator is enough for loading programs from an SD card. But the card seems to work well with the QL-SD and Minerva ROM, so I can have both FLP and SDC connected.

To make the difference between the three products clearer, I've created this table:

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

*) The file allocation table takes memory

The QL-SD is not really comparable, but I included it to make clear how these devices might complement each other. Note also that none of the solutions enable a direct file-transfer between a PC/MAC file system and the card reader.

Looking at the Gold Card board, it is the same professional quality as the TDI. Installing was easy. There are no jumpers or settings to consider, nothing to screw or un-screw, just remove the extension port cover and push the card in gently along the rails.



The card is a bit longer than the TDI, although it does not extend over the computer footprint.

When connected, take care: Do not grab the card when picking up the computer, as this can bend the boards inside.


Booting & BASIC test drive

Although the booting sequence must be technically faster, there is also more memory to check and therefore it takes a tiny while. Then I get the "Gold Card v 2.49" message and I'm off to superBASIC.

With the Minerva ROM, I have to look at the added boot option screens - the QL-SD also needs a short waiting time. For some reason I had to do my mode selection "twice" if I go for the F4/Dual screen. But the Minerva boot and memory check have been optimized so it's pretty quick.

It's instantly clear the speed makes it much more pleasurable to work in the BASIC environment. I no longer have a feeling the system stays behind my moves. Before the upgrade, all listing, editing, typing, scrolling and similar actions were about bearable, now they are quite slick.

Again, TK2_EXT activates the Toolkit 2 extensions (the command itself is faster) and after that you can use the semi-fullscreen editor ED, FSERVE file server, or use WTV to set the BASIC window size to work better with a television.

Just eyeballing a couple of BASIC graphics routines shows the 4 x speed increase is quite real. Testing also highlights how slow the SuperBASIC is to begin with, so I'll have to say even now the BASIC does not give lightning-fast graphics.

When comparing an unexpanded QL with a Minerva ROM+68000, not all speed increases are due to the processor, as Minerva improves the ROM routines a bit. Taken together, SuperBASIC on Minerva+68000 is clearly 4 times faster and even more.

For example, the following line-drawing test could finish nearly 7 of the 8 color sweeps before the unexpanded QL without Minerva could finish even one.

100 MODE 8
110 PAPER 0: CLS
120 FOR I=0 TO 7
130 INK I
140 FOR Y=0 TO 100
150 LINE 0,0 TO 100,Y
160 NEXT Y
170 NEXT I

With output something like this.
QED text editor is smoother and begins to remind me of typing on ST/Amiga editors. My QMAC compiler setup works faster, and I guess the file access from RAM drive should also benefit from the acceleration.

The Qliberator-compiled BASIC increases the speed further. The compiler by itself does not do that much and my rough estimate is that even the non-compiled BASIC on 68000+Minerva is faster than compiled programs were on a completely unexpanded QL.

There are probably accurate benchmarks and testing software around, but this kind of simple observations are enough for me.


Final remarks

Decades after, it's easy to say that a full 68000 is what the QL should have had in the beginning. But old 68000 processors were costly and they also took up room on the board (64 vs 48 pins). QL would have jumped to a different price category and likely eaten up more desk space. The 68008 helped to make a very cheap and tiny computer with enough 16-bit sensibilities, yet more portable than many "portables" were back in the day.

But what about the Miracle Card Clone in this day and age? Because the card has a processor, memory and a disk interface, maybe Tetroid might clone a full computer, integrate the (Super) Gold Card and fit it all inside original QL case and connectors? That would be wonderful.

Saturday, 24 March 2018

KC901 Family Game



Following a tip-off, I bought this Chinese console from a flea market for 2 euros. It looks vaguely like a Sega Megadrive II but I suspected it was probably a NES clone.

The case is labeled as KC901 Family Game, but I could not find much about it on the internet. I did learn the polarity: tip is minus and the ring is plus. I tried with 9 volts and this appears to be ok. Also, some say the A-V plugs are not really connected so there is only RF. Looking closer at the circuit board this seems to be true, the parts are soldered in but there is no connection!

Left: the TV/power stuff, centre: the CPU/Cartridge, Right: Controllers/inputs
I stripped the cartridge of it's cover, which had come loose anyway, then went in into the console itself. There's a large "clamp" thingy that helps remove a cartridge with a push of a button.
I removed this and all non-essential parts and tried to connect the device to a TV, but got no picture.

Looking inside, I saw that someone had tried to re-solder a few connections and the RF, and the results are even uglier than my own solders. The circuit board surface had become damaged too.

I removed some with a solder pump, cleaned the connections and tried to get the thing running. Eventually I could get a hold of the picture via antenna, and it's a pretty solid image for an RF.

The controller and CPU compartments are quite clean, the power/TV not so much
I also tried whether the internal "video" pin could deliver a signal to the TV video, but although I saw a glimpse of a rolling dark ghost of a screen, this does not seem to be the way to go. If it were so easy, the A-V would probably have been connected.

Guess if there are really 150 games...
For some reason I could only get one controller working. Plug them both in and neither works. There's logic inside the controllers, they are not simply a bundle of switches, so a broken controller or a wrong connection might explain this.

What's a "Comnado"?
But it's enough to see this is a NES clone alright. The 150-in-1 cartridge is even a bigger rip-off than my other 8-bit "Powerstation 64" NES clone, here there are maybe a handful of games with zillion variants with different names.

Possibly the variants have been patched to create some negligible difference, but I could not be bothered to check this. The presence of Duck Hunt and Wild Gunman shows this system has been indeed sold with a light gun, but without one I can't really play them.

The power/ TV crap, showing some of my cable additions
Although I'm not 100% certain the 150-in-1 belongs with the console, I think that's the idea. Can't say if a NES clone like this runs real NES cartridges, and if it does, do they need to be Japanese, European or US? No clue.

Wild Gunman


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".

Further edit: At end of March, the Android 8th level was beaten, and also GnuChess "easy" was beaten. But it did raise questions about the stability of the gnu engine play level.

Online, lichess is good for on-line head-to-head games and for editing the board. I also tried betterthanchess.com, 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?


QMAC

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:

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

    MOVEQ #$0,D0        ; return to basic
    RTS
    END

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:

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

    MOVEQ #$0,D0
    RTS
    END

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.