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.

Atari ST

I had an Atari STE in the beginning of the 1990s and alongside with the Amiga it was my entry point to 16-bit computers.

The Atari ST and Atari STE

Powered with a Motorola 68000 chip, typically equipped with 512 or 1024 Kilobytes of memory and a 3.5 inch floppy disk drive. The display resolutions were 320x200 with 16 colours or 640x200 with 4 colours. Initially, these colours were selected from a total of 512, whereas the later STE extended this to 4096, as in an Amiga. With a special monochrome monitor you could have 640x400 black and white display. Sound came by courtesy of the Yamaha YM2149 chip or DMA sample playback on the Atari STE, which also brought in hardware scrolling.

More advanced models such as Mega ST, Atari TT and Atari Falcon would have better specs, but I'm only really talking about the ST/E.

You could plug a mouse and a joystick into it and play games or run programs. With the MIDI ports built-in, it became a cheap alternative for amateur and professional musicians alike.

A semi-naked Atari STE, with the disk drive removed.

The Atari ST desktop

The graphical desktop with the green background is called the GEM. The operating system is called TOS (Apparently, The Operating System). Both are included in the Read-Only-Memory, which is a bit unconventional but handy for a floppy-disk based user.

I have a bit mixed feelings about the GEM in its simplest forms. Funnily enough, it kind of resembles what we now have in touch screens: simple graphical means for launching apps, and not much else. In huge hindsight, the ST might have benefitted from having a BASIC in the ROM, 8-bit style, instead of this wonky desktop that cramped creativity.

Positively, as the GEM was stuck into the ROM it was really quite universal for Atari ST. With this in mind it was good that the GEM could be customized with software such as RAM disks, command shells, alternative file selectors, virtual hi-resolution etc. With some luck these could be integrated together with all properly written GEM software, adding more sophistication to the system than there seems to be.

Which isn't much, to be honest.

There were also full desktop alternatives such as KAOSdesk. For a graphic journey through the TOS versions and alternate desks go here.

Typically, a poor Atari user would have 3.5 inch floppy disks with 720Kb capacity. The Atari ST uses DOS-style filenames, with 8 letters and a 3-letter extension. So, TXT and DOC files can reasonably be expected to be text files. Rather generously, the GEM can display text-files and readmes without a separate program.

PRG, TOS and TTP (TOS-Takes-Parameters) files can be run as executables. The TTP file expects typed arguments which sometimes worked with ARC, LZH, LHA and ZIP archivers. (Or even ZOO... anyone remember ZOO?)

TOS/GEM upgrade

I just upgraded my STE ROM chips from 1.06 to 2.62, the final version for STE. The upgrade is not difficult but requires some soldering as the jumper settings have to be changed. This also limits somewhat the switching between ROMs. There are a lot of tiny improvements and the GEM feels generally slicker. Some incompatibility may arise, though.

The ROMs are under the floppy drive. The jumpers are on the right (here not set correctly)

WIth these earlier TOS versions, there is no multi-tasking, but there are some workarounds to this in the GEM environment. It can seem toy-ish compared to an Amiga Workbench, but if I had to pick between the two as purely floppy-based systems, I would prefer the Atari GEM.

Desk Accessories

Programs with the .ACC extension, when placed in the root directory of a floppy disk, will be run automatically upon booting and added to the list of resident "accessories".

These can be then called from the GEM top left menu. Control panel, calculators, tiny text editors, games and so on somewhat compensated for the lack of multitasking.

The AUTO folder

The auto folder was a neat way of auto-booting any file on disk without the need to edit any scripts. Create a folder named AUTO. Place an executable file inside it so your Atari ST will run it when booting. *.TTP and *.TOS filename extensions have to be changed to PRG.

If I remember correctly at least some TOS versions occasionally refuse to load the accessories, another glitch I think.

AUTOSTART.PRG

Sadly, the running order inside the AUTO folder depends mostly on which order the files were chucked there. A special software could be used for re-ordering them.

STE_FIX.PRG

One of the silly bugs in version TOS 1.06 in Atari STE messed with the resolution so that the medium resolution (the most useable for TOS) setting would not work when booting. Place the STE_FIX.PRG inside the AUTO folder mentioned above. Or get another version of TOS.

Command shell?

Sadly the GEM does not come with a command shell, more handy for many things. There are shells, though, and the GEM/TOS communicates quite well with them. The most extensive of them, the OKAMI shell, is a reasonable facsimile of a unix/linux type shell but this can be a bit too clever for its own good.

With OKAMI you can use ls, cd, more and so on for examining files and disk contents, but also more complex things like paths and shell scripts. OKAMI's a bit slow and cumbersome for floppy drive use on a standard Atari ST, and it takes nearly 100K so it does not boot instantly.

Games

What's good? Highly subjective. I maybe spent most time playing Larn, Midwinter, Knights of the Sky, Railroad Tycoon, M1 Tank Platoon, Damocles and Llamatron. A lot of people swear by Dungeon Master and Oids. Oh, and the games mentioned here are not particularly Atari ST-specific, as they were available for the Amiga and PC, too.

Recently I've played Larn and been able to get into M1 Tank Platoon too, Virus and Stunt Car Racer are not bad but honestly I'd say most 16-bit games, especially with 3D-graphics, are not highly playable.

SD card readers

It would be wise to throw away the floppy drive and get a card reader instead. A HxC floppy emulator does a pretty good job, whereas an Ultrasatan device can be more flexible for replacing a hard drive. (In fact, loading floppy games poses some, but not insurmountable, problems for the Ultrasatan)

HxC is simplicity itself: remove the internal floppy drive and connect the Floppy Emulator with the drive cable and the floppy drive power cable.

The Atari outputs composite video, but there is no direct connector for it.

Amiga/Atari ST combo mouse was a common sight in the past and should not be hard to get.

Here's a good site for deciphering all the connectors of an Atari ST. It seems a VGA for monochrome is not that hard to build, but the weird monitor cable plug may not be easily available.

Sinclair QL

I can't help adoring the Sinclair QL, despite its flaws. I never saw it back in the day, but having read Spectrum magazines I was vaguely aware of the QL. As a "business machine", it was awe-inspiring to a mere mortal, but also somewhat boring with its lack of games and entertainment.

Although it was marketed as a cheap alternative to other serious computers, it was still so expensive that I was just as likely to own one as I would an Cray X-MP. Now that I have one I can bring one more childhood fantasy to a closure...

Suprematist, constructivist, neo-plasticist... pick one.

The Sinclair QL is a very pretty object. Rick Dickinson's styling is deservedly award-winning. 80s designers were mining influences from early modernism, fundamental stuff like Van Doesburg, Rietveld and Mondrian. I think it also shows here, even if indirectly. The result is straightforward and stylish, yet somehow playfully geometric. None of this rounded-corners nonsense we have to bear today.

The integrated nature of QL strikes as somewhat odd, as Sinclair had previously promoted modularity to make home computing affordable. The cynic might say that was all a marketing ploy anyway, forcing people to build their "cheap" computer in a piecemeal fashion, ending up with an expensive kit with wobbly connectors. The approach also led to an undesirable diversity of peripheral standards.

With QL, pretty much everything that was sold separately for the Spectrum is found inside one casing: Two Microdrives and ports for serial, controllers and network. Happily, a cheap television set could still be used as a monitor.

OK, it might not be as good as a proper keyboard. But it looks so much more interesting this way! 

The execution was marred by the slow speed of the machine and the inclusion of the idiosyncratic storage format. Peripheral connections are mostly non-standard. Instead of a character display, there are only bitmap modes, which makes text display very slow. Also, there are still only 8 colours. The QL no longer suffers from the colour clash, but then again it does not benefit from the rapidness of a coarse character/attribute resolution.

BASIC, not so basic

Much has been written of the above flaws and I will not retread this territory further. I'll instead focus on using the QL with the built-in SuperBASIC, which is one of the more fascinating aspects of the computer. It is unusual to have a BASIC ROM in a machine touted as "serious" as the QL. To me the inclusion of BASIC shows that the QL design philosophy shares still more with the older generation of 8-bit home computers, rather than with the more serious machines and the16-bit generation of home computers that was to come after.

It was common in the early days to include a BASIC programming language in the home computer as the primary operating system. Some might think the BASIC scene of the 80s was one of the more laughable aspects of the home micros, but I'd say a BASIC in ROM is a pretty clever choice considering the limitations of the hardware. The BASIC home computer setup combines calculator, graphic notepad, data storage, text functions and of course, a programming learning environment. 

It's hardly original these days to point out that something may have become lost in the transition to graphical desktop oriented computers. But what was that something lost? Perhaps the example of QL points in this direction. The QL BASIC is not as simplistic as those included in the smaller computers. It has features that make me think this approach might have grown to become something more significant.

QL allows a glimpse to an alternate history that never really came to be: An era where graphical interaction becomes important, not via mouse and icons, but through keyboard, powerful procedural command sets that can be used to access line graphics and windowing in a hierarchical way.

What's so neat about SuperBasic's procedures is the ease and transparency the programmer can add to the existing command set. Let's imagine: The QL is turned on. The computer automatically boots up a BASIC program from the Microdrive, which activates a command set I have prepared earlier. (We'll assume an ideal world where the drives actually work).

The set gives me customized commands for defining objects in three-dimensional space. WALL, ROOM, CHAIR, DOOR procedures have been defined in this way, and can be used for fooling around. Each command draws the corresponding object directly to the screen, rendered from the chosen viewpoint. Should I want the objects to behave differently, I can of course change the contents in the procedure definitions.

Left: Drawing on-screen with the created procedures. Right: A "house" written in BASIC.

A more hierarchical space can be defined by writing a program listing that makes use of these procedures. I create a building out of rooms and corridors, after I have reached some idea how I want to position them. The rooms are adorned with windows and doors, and also contain objects such as chairs and tables. I can use the BASIC program to give the rooms some logic of their own. For example, changing the room dimensions might even re-arrange the furniture within.

If I get tired with the conventional furniture objects, I can redefine the procedures to do something more interesting. Furthermore, all graphical output in the objects is driven through one self-defined procedure which draws the necessary lines. By changing this principal procedure, the outcome of all the other commands also changes. Depending on how the line procedure is written, the view becomes three-dimensional, overhead or an elevation... or the lines and coordinates are randomized and distorted, producing more unconventional outcomes.

Left: Changing the perspective to a side-view. Right: Changed foreshortening and background colour.

In principle, the above could be made to happen with the QL. As a matter of fact, I have tried to demonstrate how this could begin to work, even though this work hardly represents the idealized vision above. But I also specifically did not want to plan too much ahead, as I wanted to experiment with the fluidness of this process. There's something to be said for a mixture of interpreted commands and a program listing, which tends to become lost in a compiled-only language.

The pictures here are a result of about an hours work. It shows to me that the environment is "graphical", despite all the command lines, much like in a good LOGO environment. Without any dedicated drawing package, the QL BASIC could be used to create a rudimentary setting for spatial design exploration. In my mind, here's something more at play than the rather limited idea of a "office desk metaphor" that Apple was peddling to their customers.

With the QL, the graphical component is not presented as a way to make the computing experience easier, but more expansive. Of course, this vision is demanding, as it requires at least some programming skill and some understanding of design exploration.

The video below shows the reality: The lines are extremely slow.

So it might not look much, but this is on a cheap-ish computer from 1984 and pretty much possible out-of-the-box. The BASIC environment becomes a way to access all that the computer does, and it can get pretty interesting with the graphics built-in. In similar vein, the ZX Spectrum already provided a programmable graphics pad. But it is the procedure definitions in a language interpreter setting that bring the QL experience to a whole new level, and at least in principle, the Microdrive allows a rapid retrieval of these command sets. It becomes as easy to type WALL 100,0 as it is to type line drawing commands.

Now, if I were more interested in writing novels or calculating spreadsheets, the QL BASIC might offer less openings out of the box. The truth is, the QL BASIC environment is not enormously flexible towards all kinds of interests. But who knows, what might have happened if this approach had become the mainstream. Instead, we now have computers mostly as platforms for launching applications that achieve fairly limited things. Programming tends to be accessed through counter-intuitive development environments, not very encouraging for direct approaches. (Although it has to be said that projects such as Processing and Python have somewhat helped change that.)

Highlighting different objects with a variety of colours. The TABLEs are made from LEGs and PLANEs,  whereas the PILLAR is a ROOM with a fixed width and depth.

All in all I have liked to play around with the QL Basic, perhaps more so than with other old computers. What I've been here trying to say is that there is an underlying design vision in the QL that continues to intrigue me, and not so much the somewhat flawed computer QL turned out to be. It's of course not fair to criticize a 30-year old piece of electronics, and I know the story of QL did not end with the Sinclair machine. Perhaps I'll be able to get a later version some day, and see how the story continued.

Texas Adios

Just a quick peek at the computer called Texas Instruments TI99/4A. It's pretty old, from 1981, based on the earlier TI99/4 from '79. This makes it something of a contemporary to Sinclair ZX81 and Commodore VIC-20.

From what I had seen from pictures, I assumed this to be a more fun-sized computer. Possibly the TI brand made me expect something a bit more calculator-like. But really, it's huge, easily MSX-sized. The appearance is quite polished and the keyboard is very solid. It seems to me that quite a few US computers went for the "aluminum/black" look, don't know what is the origin for that. (TRS-80 and Timex Sinclair spring to mind.)

Despite the good physical quality, the keyboard lacks some crucial editing keys, like backspace and arrow keys. These are hidden behind FUNC-combinations. Curiously, the " character is via FUNC+P and not SHIFT+P, inconsistent with other characters. My unit is somewhat prone to double-type, but this could be the keyboard showing its age.

For a company that is renowned for its calculators, the TI calculation keys are surprisingly not very prominent. On the right side, in front of the front-loading cartridge port, there is a flat surface which to modern eyes might look like some kind of trackpad, but is really just a flat surface. There could have been some room for a keypad, who knows. I've read on the net people call it lovingly the "cup warmer" for the heat it gives, which is good to know because otherwise I might have been worried about the warmth.

The BASIC shows numbers "as they are" up to 9999999999, which is nice.

To my liking, this computer is bit too much like a video game console with an added keyboard and a BASIC added for a good measure. The BASIC does not integrate with the computer in the way it would do in most other home computers, so it seems more like an add-on that just happens to be included with the machine. Although the expandability of the machine is apparently very good, the built-in facilities and connectors are poor, really almost nothing. For these various reasons I've not been inspired to explore this computer too much, even if it is something of a minor classic.

If I've understood correctly, the computer uses the video chip memory as its main memory. From what I've read, the central processing unit can really only access 256 bytes of memory, and the processor is - get this - 16 bit, a first in home computers! Although the setup makes it sound like TI could be potentially a fast computer, as it happens this does not seem to be the case at all. I don't have any games but at least the BASIC is extremely slow, possibly the slowest I've yet encountered. It takes virtually seconds to print a bunch of numbers in a FOR-NEXT loop. LISTings are almost like teletyped.

Using CALL CHAR to re-edit the empty character.

The command affords quite nice pixel graphics, but this was all I could bother to do for now.

I'm usually quite intrigued to explore various BASIC dialects in the old computers, and I was lucky enough to get the computer with the BASIC manual. Curiously enough the manual is a Finnish version published by Salora, who also branded Laser 200 as Salora Fellow in Finland at around the same time, but that is another story.

I was eager to find out whether the BASIC had some similarities with the "TI BASIC" included in their later calculator lines. Alas, there does not seem to be any meaningful relation. This BASIC is not really geared towards calculation any more than other similar languages back in the day. The BASIC displays large numbers in somewhat more user friendly format but that's about it.

Looking at the manual and trying out the commands it strikes as weird that there are no PEEK or POKE commands that could access the memory directly. So, the programmer can forget about inserting machine code statements via BASIC. Also, as the video chip is the famous VDP as used in MSX and the like, there's no straightforward "character memory" to mess with either. Instead, there are CALL commands for doing various helpful things that would otherwise be far too slow to do in TI Basic, such as filling portions of the screen and re-editing the character set.

As a separate product, there was some kind of "extended" BASIC and an assembler too, which presumably give more freedom to the programmer. As it is, the access to the hardware is very limited, and it's even a bit uncertain how much memory there even is. The manual boasts of the 16k memory available to the user in addition to the memory used by the TI BASIC, which really cannot be the 256 bytes the processor uses? So, what is that memory about? Also, one part in the manual warns that the memory upgrades available do not extend the available memory for the BASIC, but are instead used for the other (separately sold) extensions. Wow.

TI 99/4a is a kind of a neat kit, but allows for very little exploration and experimentation. This makes it somewhat dull, even if the BASIC command set is quite potent for its time. Although the TI is in some ways superior to both ZX81 and VIC-20 I mentioned early on, the available potential to the user is clearly inferior, at least from out of the box. To assess the gaming potential, I'd have to see some actual games. Due to the VDP chip I expect them to be quite close to MSX and Colecovision in visual appearance.