Orel BK-08

It was quite common practice to clone foreign computers in Russia in the 1980s and 1990s, as the copyright laws were quite "flexible" and the trade of computers between Soviet Union and the western Europe was a bit problematic. Most of these hobbyist computers were virtually unknown outside Soviet Union, though Finnish magazines sometimes reported rumors of professional CP/M and MS-DOS clones.

Nowadays it is known that a huge variety of 8-bit models had been in production. Most were based on the ZX Spectrum, a choice which is explained by the fact that Speccy was quite cheap to begin with and did not have a huge amount of dedicated chips. Some computers were produced by enthusiasts in electronics factories in-between the normal work, and some were built from scratch, in piecemeal fashion by hobbyists.

Enough documents, stamps and signatures to get you through Checkpoint Charlie.

It's not that hard to buy one from the eBay, although prices can be steep. The Orel BK-08 is one such Spectrum "clone" made in Russia in early nineties that has been lately available.

I bought the computer in its original packaging. For fans of "soviet chic", the graphics on the box and in the manuals are of course a treat. The documents go in quite a detail, and the package also included sheets of circuit diagrams, which however are bit too crudely printed to be really readable.

Besides the instruction manuals and technical documents, the box also had all the necessary cables and the Power Supply Unit. This makes the Orel a quite friendly entry into Russian retro-computing, as some other models can take a bit of fiddling to make them work, and documentation can be scarce. I was quite happy to have this model as there was relatively little hassle in getting it up and running. On the down side one might say the OREL is not as street-credible as some of the more adventurous DIY clones.

The main board. There are two more boards for the keyboard and power input.

Looking inside, there is a Korean Goldstar Z80 chip, and two brown ROM(?) chips that seem quite common in Russian computers. Compared to some other models I've seen the casing is quite sturdy and the circuit boards are clean and neatly ordered. The biggest question is of course, how has the Spectrum ULA, the only really Spectrum-specific chip, been implemented? (Though I have to add ULA is also a kind of customizable chip.) There seems to be no single ULA chip as such, so I have to assume the functionality has been replaced by a broader array of chips.

BK-08 and RGB

Although the package had all the cables, they are not exactly the same is in Europe. It seems to have been quite common in the Soviet Union to connect all peripherals with DIN-DIN cables. I managed to build a RGB-SCART connector to connect the RGB signal to my Sony TV, so I can say a little about my first experiences with the Orel.

From left to right: Power (24V), 7-pin RGB, 5-pin Tape out, 5-pin Tape in, 2x7-pin Joysticks.

Below is my cable connections but I cannot guarantee it works. My TV is not too picky but who's to say what might happen with some other display. Resistors may be needed to get the 12V down to the 3V for the Blanking pin at the display end. I used a series of resistors because one would get too hot too quickly in my opinion.

In any case, you should know what you are doing, and do not leave your retro-computers or power supplies connected without supervision!

Clockwise, from the top, the video output connector pins are (looking from the outside):

Edit: I realised this is misleading or even erroneous. The following is true if you look at your RGB-cable pins end, the one that you will stick into your Orel.

If you look at the computer video connector, that is a mirror image. I added a picture that should make this clearer.

12V - Scart RGB 16. I used resistors (5 x 33R) here, but my TV works without too.
BLUE - Scart RGB 7
RED - Scart RGB 15
SYNC - Scart RGB 20
GREEN - Scart RGB 11
SOUND - Scart RGB 6
GND - Scart RGB 5,9,13,17 or 18. One should be enough.

This should be clear!

Basic and Keyboard

The keyboard feels okay, perhaps a bit better than a Spectrum+. There's some trickery that allows the entry of "extended mode" keywords by pressing keys together with a CTRL key. Indeed, the extended mode does not seem to work even if it's sort of there.

The keyboard has cyrillic letters, but does not indicate the Spectrum BASIC keywords and generally does not follow the same terminology. Interestingly, the cyrillic alphabet has also been integrated to the BASIC ("BEISIK SISTEMA REV. 2.0") and the error messages have been localised. It's possible to turn on a RUS mode, which works much like the GRAPH mode. Both upper and lower case are included.

The keyboard module can be separated from the rest of the case, for no useful purpose.

The different "mode" (Graph/True/Inv.) keys have been given their own zone at the right of the keyboard. These keys are the only surface indication of the Spectrum heritage. The EDIT key is quite conveniently next to the cursor keys cluster. At the left side, there is a tilde key, which curiously brings up the VERIFY keyword in BASIC. Similarly, the tab key brings up... the keyword TAB, which is kind of funny.  Generally, all of the additional keys seem to work in a new "contextual" fashion, which may feel weird to a Spectrum user but is quite logical in the end. For example, READ, RESTORE and DATA have single-key commands at the right side of the keyboard, grouped into the zone that accommodates the rest of the cyrillic alphabet.

Some slight speed improvements might be expected because the memory is being handled a bit differently. (Something too technical for me to understand at the moment) I lazily eyed Orel BASIC loops side-to-side with a Spectrum emulator and it appears indeed a bit faster, but such a comparison is hardly conclusive. I also noticed the speed of the FLASH attribute is faster than on a normal speccy, but this is more of a timing issue than any indication of increased speed.

Edit: I made some side-to-side tests with the Orel and a 48k ZX Spectrum, both in BASIC and in machine code. The tests seem to confirm that the Orel is marginally faster, but the speed is not easily traceable to any obvious difference in memory speed or such. A task that takes about a minute can be expected to be a few seconds faster on an Orel.

Loading tapes, MZ80 and the Shadow RAM

A 5-pin DIN cable was included for both loading and saving.
Viewing the connector at the back of the computer, from left-to-right:

(1,2,3,4,5)
3=GROUND
5=SIGNAL

I succesfully loaded few pieces of software from my Mac soundcard. I tried Bruce Lee, Green Beret and Starion. The last one crashed, but it may be because of pressing the Z/Print screen key (feature of the game). Starion uses some border effects on starting the game, and predictably the timing was a bit off so it was not exactly true to Spectrum. But on the basis of these three games I'm actually surprised the Orel seems quite compatible with the Sinclair.

Maybe the least professional part of the packaging...

The OREL BK-08 has an interesting feature, a Shadow RAM, portion of memory that resides under the normal ROM. The only way to test is was to load the MZ80 monitor from the supplied tape. I made it into a .wav audio file and loaded this to the OREL using the Mac soundcard.

The MZ80 is the last chunk of code in the included tape. Use LOAD ""CODE to load it. (Press J, then "", then CTRL+J) When the loading has been finished, the program locates automatically in the Shadow RAM. Pressing the NMI key, the program residing in the Shadow RAM will be run.

I'm a bit clueless about the manual so I do not know how to display memory but I'm quite sure there is no disassembler. G seems to return to the program, but at least Bruce Lee refused to continue properly. The monitor exits cleanly to BASIC programs, though.

Here I have entered the MZ80 via the NMI button. X displays register contents.

As the RAM area (0000-3FFF I'm told) overlaps the screen memory, exit from the Shadow RAM handily retrieves the screen. (Edit: Except that memory area does not overlap with the screen memory, so something else must be going on here. Possibly the storage and restoring is done by the MZ80. Another explanation might be that as RAM starts from 16384, this is also the Shadow RAM address.) So the Shadow RAM should not overlap program code. The Shadow RAM also survives RESET, so it's possible to invoke the monitor as often you want as long as you don't pull the plug.

I don't know how simple it is to load your own code into the Shadow RAM. Maybe the MZ80 instruction manual describes how to save binary in such a way, but I don't read Russian. A proper monitor or assembler/disassembler residing in the shadow might even come useful. I guess I can at least have a look at how the tape file is formed if there are any clues.

All in all

Although my experiments are hardly definitive, I'm already somewhat impressed with the compatibility and the tiny improvements compared to the original computer. Of course, this is a much newer computer than any official Spectrum so it's not that surprising. Yet it is a bit unclear where the Orel BK-08 fits in the broader picture and history of speccy clones. It's not a DIY clone, nor does it seem to point to the Pentagon/Scorpion lineage either, as there are no 128k features or a new sound chip.

A very informative page about the technical features of the OREL BK-08

An amusing video about the OREL from Austria
(There's also a 3D-version for those who have the glasses.)

Your ZX has evolved!

It seems I am never quite happy with the placement of my ZX Evolution board. This time I have placed the ZXevo inside a Spectravideo case. Previously, I have already changed the SVI keyboard circuit into a ZX Spectrum keyboard matrix, so it was not too much work to connect it to the ZXevo. Also the RGB and Joystick connectors were ready so I did not have to make them anew. (Fortunately the connectors could also be squeezed through the openings so I did not need to resolder them.)

With that old attitude of "trying out gets the things done" without pre-planning and measuring too much, I found that the evo board seemed to fit nicely inside the case. There never was any question about depth and width, but the height was a bit worrying. The keyboard block is rather bulky, and the pictured configuration leaves very little room between the board and the keyboard circuitboard.

It sure looks messy. The boards are fixed into place with screws, and for these I drilled new holes directly through the bottom. The SVI case is well elevated so it does not matter much if the screws stick out slightly. The board inside is slightly raised with plastic pieces, as the existing screw holders might otherwise get in the way. Besides, there's a metallic nut in each of the holders, and it would be a pity if these created some unexpected contacts with the board circuits... So I also put some cardboard between the case and the board.

To get all the connectors visible from the backside, some more cutting would be required, but here at least the VGA and the SD card are useable. Also, If I want to use a better PS/2 Keyboard, it's within reach.

Here's some of the details:

1. The joystick connector. This fits nicely into the existing opening, and screws hold it in place. The board end is shared with the keyboard connector. I made that part to be two separate chunks, so that the joystick wiring does not hang around uncomfortably when separating the keyboard part from the case.

2. The RGB connector. It's a bit pointless to use the ZXevo with a stupid VGA monitor, so RGB is preferable. I had to carve the SVI "TV" opening a bit to make the DIN fit. Now it fits so snugly it does not even need screws really. The SD card can be seen to the right, sticking out from the opening.

3.The Reset switch. This is the one almost absolutely necessary thing to make when working with Evo if you don't want to connect a PS/2 PC keyboard (=boring). Without a separate reset switch (to Jumper 6) it's not really possible to get at the service screen again without pulling the plug! This is just a simple microswitch that sticks out from the Spectravideo power switch opening. I used a separate plastic piece screwed in place to the bottom to hold the microswitch in place.

Only the basic keys are connected here, as connecting all the cursor keys and function keys and such would require a bit different kind of thinking. There's a possibility of using some of the keys for the Evo jumpers (such as the reset above), as they do not interfere with the keyboard logic, but dismantling the keyboard block gets a bit tiresome after a few times so I did not take this route.

Horace goes PETSCIIng

PETSCII is a variation and extension on the ASCII set of characters that has its origins in the 1970s. Behind the acronym stands the rather grandiose title of "PET Standard of Information Interchange." PET, again, was one of Commodore's first computers, and stood for Personal Electronic Transactor.

That's it. That's all you get. (Plus some colours, too)

As ASCII character sets only indicate 128 characters, and the sets can conveniently have 256 characters in 8-bit computers, it was meaningful to add precisely 128 new custom characters to the set, facilitating some rudimentary graphics for menus and games.

Different manufacturers favoured different ideas. The IBM set was quite commonly used in conjunction with ANSI colour and positioning codes for producing graphics in text terminals, bit similar to Teletext mode included on many TV sets. ANSI graphics was still quite popular in the 1990s with bulletin board systems, as there was no wide standard for transmitting pixel graphics over the slow telephone lines.

Just a mock-up...

One of the more inventive and useful sets was PETSCII from Commodore. Commodore was quite persistent in using their own variant: From PET computers to VIC-20 and Commodore 64 and all the later models, such as C16, C128 and PLUS/4 all use PETSCII. Although the set evolved slightly in the transition to the C64 and onward, it's essentially the same set. The PETSCII is not a simple ASCII extension. The lower case ASCII letters have been substituted for more graphic blocks. (It's possible to activate a text mode that includes both lower and upper case.)

Don't look up the original. Please.

The amount of colours and resolution changes between machines. Vic-20 has horizontal resolution of 22 characters, whereas the C64 has 40. I suppose the same set is usable in the more obscure 80-column mode supported by some C128 modes.

Although these text modes are arguably superceded by bitmap graphics, there's still quite a lot of interest toward these constrained graphical forms. Just as there is ASCII art and ANSI art, there's PETSCII art. The limitations provide an interesting challenge for creating illustrations and art.

Horace on a C64? Blasphemy! (A directly converted image)

One of the stranger limitations of the C64 character mode (though not unique to Commodore) is that only the foreground colour can be adjusted for each character position, whereas the overall background colour must stay the same. The VIC-20 has even more limits, only 8 of the 16 colours can be used for the foreground text. Although the C64 supports an extended character mode that enables both attributes for any screen character, it is essentially a modified bitmap mode and not considered pure PETSCII.

Despite the fairly narrow set of characters, there are still a satisfying number of visual genres that can be pursued through PETSCII. The actual resolution of a C64 PETSCII image is still 320x200, and the character set is so diverse that it offers a tantalizing possibility of looking like something else than "just" text graphics. There's also the fact that character graphics take up less memory than the resulting bitmap would, and lays a foundation for different animation styles.

Some artists favour a more purist text-art look with clearly indicated black background, whereas some might try to create realistic images converted from photographs or drawings. There are contexts where colours are not possible or appropriate, and this poses another starting point for expression. Colour areas are another starting point, and characters would be used sparingly, such as the surprisingly versatile 45-angle tiles. Some tricks are needed to get around the background colour limitation.

This picture uses almost exclusively square blocks, 45-angle triangles and lines.

How to go about creating PETSCII art? Well, Using a real C64 or an emulator is one starting point. The BASIC editor forms a rudimentary graphic scratchpad: all the characters and colours can be accessed from the keyboard. The real computer has the handy graphics printed on the keys, whereas on an emulator you would have to know the keys by heart. BASIC code could also be used for producing random PETSCII art, not a bad premise at all. In fact, there is a book that discusses various generative code approaches through one PETSCII example.

However, without a freeze cartridge, storing your work can become difficult on a physical computer. (Some cartridges also offer screen editing features.) It's also easy to lose the screen data by messing with the wrong keys.

Truth be told, there's only that much that can be sensibly done without a proper editor, be it on a C64 or on some modern computer. Copy/Paste, undo, file operations make life a bit easier. All the examples on this page have been made with an editor that runs on modern platforms, such as PC, Mac and Linux. (Link below)

A random mess

There is a fascination to PETSCII that is similar to low-resolution pixel art, yet the limitations are in ways more severe. In a strange way, the character art is more easy and liberating than pixel illustration. The other side of constraints is always their enabling nature, and the rapidness of the way PETSCII can be explored for interesting effects is the reward of these limitations. 

This somehow sums the value of old computers to me. Even though underpowered, there's always some features that surprise me with simple effectiveness, expression, personal style and flair.

Wikipedia on PETSCII

Marq's PETSCII editor and a gallery of art (The editor, written in Processing, is available for PC, Mac and Linux.)

A high quality competition of PETSCII graphics at CSDb.

Panasonic FS-A1WSX MSX2+

After ZX Spectrum, the MSX was the second computer I had some good hands-on experience with. I remember the BASIC programming environment fondly, it was a breath of fresh air after the idiosyncrasies of the Spectrum. Although I disliked the idea of a "screen mode" (A Speccy does not know the concept) sprites and sound commands made life much easier.

Now I have a look at the MSX2, a Panasonic FS-A1WSX MSX2+ (huh!) which indeed is a +. I never saw an MSX2 back in the day and the platform seemed a bit uninteresting given that Atari ST and Amiga existed. More memory, more screenmodes, (usually) better sound and other tiny improvements were what made the second generation of MSX computers.

"Case felt the edge of the deck sting his palm as he slapped MAX REVERSE. The matrix blurred backward..."

The outward design is quite rhetorical, bit like 1980s stereo units, it has an appearance of sophistication and complexity with all the labels, buttons and light indicators, not to speak of the muscular, jagged protrusions. It's what I expected a cyberspace deck to look like. Given how large and complex the machine seems, the connector options are actually quite sparse. Then again, it's the two cartridge ports that are really at the heart of the expandability of the MSX. I've also understood the joystick ports can be rigged for output too, so there's more than meets the eye here.

Although the MSX-DOS is not included with the computer itself, it seems to be quite an integral part of the MSX2 experience. The MSX-DOS is a disk operating environment with executable commands, compilers and editors, so the BASIC side of things can be skipped. In this respect the MSX2 might be compared to the Amstrad 6128/Commodore 128 generation of computers which had CP/M compatibility.

The old workhorse, the Z80, is showing its age. It's not that great for pushing stuff around, even if there is a turbo mode for roughly 1.5x speed. Fortunately the VDP video chip has new tricks up its sleeve and the sound chip works independently too. This particular MSX features MSX Music extensions, meaning that a synthesizer engine can produce up to 9 simultaneous channels of tunes and sounds.

This is what hits you upon boot-up if you're not careful...

The Panasonic's own ROM-bundle is filled with word processing, card file, address book, calendar and such. All work in kanji characters, so I don't have much hope of deciphering what each of them does. To be honest they seem a bit slow for what they are. The menu screen, complete with music, deserves a mention. It may seem frivolous but then again we're talking about a computer that probably needed to compete against typewriters which were less "gendered" products. The screen appearance is at odds with the overall technical appearance of the computer, though.

The "Color Word Processor"

This is a bit speculative, but having joyful and bit silly screens in a computer was in fact ahead of its time. In US and in Europe most electronic consumer products and especially computers were driven by an engineering/masculine ideology and aesthetic. This has changed ... for better or worse. Many people might be persuaded to buy a computer device for very limited out-of-the box uses, much like smartphones are nowadays. So in a way this kind of package foreshadowed the more "user experience" driven design of later days.

Sure, the ROM bundle seems a hindrance now and makes one suspect incompatibilities. Fortunately the creators had the great wisdom of including a physical switch that bypasses the software package. Exiting each of the tools is through the STOP key, and the ensuing menus are navigated with the keys left and right to the space key, so I suppose they work as OK/CANCEL or YES/NO keys.

Although some of the kanji were present in western MSX character sets, I don't recall if they could be actively used. Here, Japanese writing characters are much more integrated to the overall setup. There's a "kanji lock" key in the keyboard that enables the characters displayed on the keys. It's possible to CALL KANJI to enter a really chunky text-mode, with big 16x16 kanji characters.

The "Kanji Lock" key left to the Hardware PAUSE key.

The music extensions can be simply invoked by CALL MUSIC and then using PLAY #2,"CDEFG" and the like. The Music Macro Language is a rather complex way for creating tunes, especially for nine channels, so many would these days prefer to use a tracker software. 

Messing around in MSX-DOS.

The MSX-DOS itself is pretty solid and easy to learn if you've ever worked in CP/M or MS-DOS. An RGB cable gives a good enough picture to work on the 80-characters wide screenmode, but if it's hard on the eyes the MODE command may be used to switch to an arbitrary width. (And I mean arbitrary! Try MODE 1...)

The screenmodes are quite flexible. The aforementioned KANJI mode can also be used in DOS.

I tried compiling some z80 after typing in a piece of code in APED, a text editor. It's not unbearably slow, so developing software on the MSX2 itself is within the realms of possibility. Of course, cross-compilation from a more current platform (with an emulator) is more sensible, but there's a nice feeling writing small snippets and see them run directly on the hardware. This blog post serves as a little primer on different compilers and a rough estimate of their relative speeds. From a learning point of view it needs to be noted that the MSX does not have a straightforward memory-mapped screen modes. Getting stuff on screen with machine code is slightly more complex than with many other 8-bitters.

All in all, the MSX world is quite diverse. I'm really only a novice, as back in the day I just fiddled with BASIC and played some crappy European games. The direct Spectrum conversions (slower than the original) gave the platform a bad name around here... Yes, Konami cartridges were good but also expensive. It still is a pretty fun computer to mess with, and as with other popular platforms like C64 and Spectrum, new hardware and adapters make it that much more friendly for this day and age.

Development tools for MSX

Canon X-07

A little beauty, this one. The computer is book-sized and fits into a VHS-case sized plastic binder. It offers pretty much what a home micro would have around 1983, except in a very small portable size. The language is Microsoft BASIC, which was state of the art at the time. Well, the memory is not that impressive, only 8K of which roughly 6 are available to BASIC.

Despite the looks the X-07 is not really a scientific calculator. For example, the math symbols are not directly available but behind SHIFT-combinations as on an ordinary micro. It's of course possible to write some calculator software! The BASIC offers very direct access to screen features such as text and bitmap graphics with commands like PSET, LINE, CIRCLE and FONT$ which can be used for the 5x8 user character definition. I suppose for graphing purposes these are fine and to me this is more flexible than the clunky TI-BASIC found in Texas Instruments calculators, even the newer ones.

On the negative side, the connectors are a bit non-standard. For a tinkerer it's nothing, but of course an ordinary RS232 port would have been nice (It's not even that much smaller). Sadly the resolution is very small, 120x32 pixels, and the display is not backlit. Apparently there's a display adapter which would give an 8-colour display on a television. This would make X-07 even more interesting, although then it would no longer be portable.

The Z80-compatible chip is likely to be on the slow side to conserve power, my hunch is 1mhz. (Edit: Nope, it seems the NSC800N variant is 2.5mhz) Printing and graphics commands are quite slow via BASIC. I don't know how long the battery life is, but I'd assume that the display is not that greedy.

What I like about this machine is that the "booting" time is non-existing. The RAM "disk" is permanent as long as the batteries last. The user chooses a suitable portion of the memory for the RAM files, and code snippets can be stored and retrieved via SAVE and LOAD commands. DIR brings up the file list. It's also possible to RUN "filename" to execute a file without loading it into the text memory.

The RAM is battery-backed and it's also possible to put the display to SLEEP and continue later from where you left. There are some interesting possibilities for using this computer to "upload" tiny pieces of data via the RS232, and I might be tempted to try this later. An "autobooting" command can also be created, for running the program in memory, for example. This makes me think the computer is meant to be customized into a variety of one-purpose devices, possibly a controller for industrial machines.

The eight bits between the nybbles. We've seen this before.

Tape options are of course available and using Audacity on my MiniMac I could store and reload a BASIC program. The format seems straightforward enough and if there's nothing about it on the internet I might examine it a bit further. (Edit: Actually, it's all in the manual. Silly me. Also, there's a webpage about the tape formats.)

I feel positive about this tiny computer. The build quality is high and the Canon competence in calculators also shows here. Everything there is, is pretty well made and thought out.


The memory upgrade:

A Toshiba TC5565PL-15 memory chip adds 8K memory, to a total of 16K. The whole system may need resetting before the memory becomes active. The RAMdisk use becomes a bit more reasonable with this expansion.

How to build an RS-232 cable between Canon X-07 and a PC:

Edit: I'd recommend NOT connecting this serial port directly to a Mac/PC! They have a different voltage level.

It is quite fortunate that a piece like the one below can be stuck into the existing port, by ever so slightly twisting the pins. However, the pin order is not standard so a special cable or an adapter needs to be built.

The diagram below shows how to connect between two port types. A cable between two Canons would of course be symmetrical. Note that the numbering in Canon port follows the order in the manual. (1=LTxD, FG, N.C., TxD, RxD, CTS, RTS, SG, VBB) 

The manual also tells the signal level is not standard, but this did not seem to cause problems when connecting between Canon and a Mac. I just went away and tried, although they should not be compatible. I'd be careful. What I see the RS232 in Canon is likely to be TTL level ("5v") whereas serial ports can be 12v. I suspect modern computers and USB/serial adapters may be accommodating, but I'd be wary of connecting different kinds of computers.

The serial port, seen from the outside.

On the Canon end, you do this to set the port:

INIT #1,"COM:",2400,"B"

4800 is the highest speed. The "B" combines the various parity and bit length parameters into a single letter. B seems to work ok with 8 bits, no parity.

After initializing the channel you can:

PRINT #1,"HELLO" to send a string of characters.

...or OUT #1,65 to send characters out.

...or LIST #1 to output the BASIC listing in ASCII.


Some good resources:

The Canon is quite well documented on the net. There seems to be a whole scene focusing on collecting and enthusing about hand-helds, calculators and even digital wrist watch computers.

Here's a page that tells everything you need to know about various peripherals and extension cards:

http://gtello.pagesperso-orange.fr/cx07_e.htm

Programs for creating tape files:

http://www.mvcsys.de/doc/casioutil.html

The Final Cartridge III and Action Replay VI

(I mostly wrote this quite a time ago, when I made very long pieces. Sorry.)

I have owned an Action Replay VI from back in the day (end of the eighties) to the present and it really did give a life extension to the good old C64. Fast loading, directory listing that does not destroy BASIC, facilities for backing up and copying almost any piece of software, a machine code monitor and flexible ways of loading and saving portions of memory, are among the many useful features that make the life of an 8-bitter that much easier.

Back then, I had to make a difficult choice between the Action Replay VI and the Final Cartridge III, which were in a sort of head-to-head competition between each other. Although AVI promised more features even on paper, the FCIII had an interesting attraction: A graphical desktop for the Commodore 64! One advert promised that it “would (almost) make the C64 into an Amiga”. Somehow I had the sense even back then it would be more of gimmick than a useful feature, yet the decision in favor of AVI was made grudgingly. I would have liked to see that desktop environment.

Now, about 25 years after that choice I have managed to get hold of a Final Cartridge III and get to see the other side of the fence. Furthermore, I bought a second hand mouse for Commodore, and although Computek GEOS-101 is not the definite Commodore mouse, it can (sort of) be used with the cartridge.

A joystick-emulating mouse. Avoid. It's not that great.

Physical appearances and anatomy

Both Final Cartridge and Action Replay VI are cased inside a nearly identical plastic box, very likely from the same manufacturer. If the AVI module ever had a label it has by now gone missing. The freeze button gives access to the cart main functions, whereas the reset simply resets the machine, a feature lacking in the C64. The Final Cartridge buttons are further apart than the AVI ones, which is good thinking. I do remember the occasional mis-aim back in the day, which could be really infuriating.

Left: FCIII, Right: AVI

I am not an electrical engineer, but the circuit board in FCIII gives a less professional appearance. The FCIII has a LED on it, which I suppose is able to show whether the LED is working. In the dark it can be handy for reaching the buttons, though.

Final Cartridge desktop

When the cart is inserted, the initial start-up screen of Commodore 64 will be changed. In AVI’s case there are four key options, whereas the FCIII provides a desktop experience. Even if the FCIII is visual, the ways of working are not particularly “graphical”. Instead of having disc icons on screen, all disk operations are accessed through a clunky window. Mostly this involves multiple clicks on various text icons, followed with clicking a “DO” icon.

Back in the day, the Amiga Workbench-like environment made convincing screenshots what with all the calculator and clock displays superimposed on the disk windows. The somewhat clumsy FCIII calculator shows that a graphical calculator is not necessarily an improvement, as the C64 BASIC is simply one of the best calculators around.

The Seeming complexity of the Final Cartridge desktop. Mostly nonsense.

Interestingly, some of the desktop experience is also present in BASIC. If I hold down the joystick or mouse button, the menu bar and the pointer appear on top of the screen, and various basic extensions and commands can be accessed from drop-down menus. Allegedly, this feature somewhat cripples the BASIC as regards interrupts and user defined characters, but it is kind of neat.

Final Cartridge notepad

The notepad is one of the desktop functions that cannot be displayed in a window. In fact, entering the notepad clears the desktop, so it can be considered as another part of the cartridge altogether. The mouse and color preferences are transported there, though. A text editor on a cart is a very good idea and is a definite plus of the package. The notepad boasts proportional font and intelligent word wrap, both quite a state-of-the art for a 1980s 8-bit home application. Considering these features the typing and text insertion is relatively slick.

The poorness of the photography is meant to expressively describe the quality of the editor.

Sadly, the feature list of the notepad kind of stops here. Sure, the mouse pointer can help move the cursor to a desired point of the text, and I felt the mouse was at least somewhat useful here. But the editor has no text selection functions such as cut, copy or paste. Find and replace are also absent. Ultimately I would have preferred a simple character display editor with more powerful functions and better integration to the rest of the package.

The monitor

The machine code monitor is one of the more useful cartridge features. What little machine code I learned during my 8-bit days is pretty much thanks to the Action Replay monitor. One can proceed in learning-by-doing fashion, through trial and error. If the computer crashes spectacularly, no worry, just reboot. It is instructive to see visible results of your code, and with the 8-bit computers it was still possible to manipulate the screen memory with only a very few machine code commands. Changing the border colour very rapidly or moving a text message into the screen memory are easily done even without a dedicated assembler package. Reputedly some games were even written entirely with a monitor!

Compared to the Action Replay, the FCIII monitor stands pretty much on equal footing. There are some things on the AVI monitor I learned to like, so I’m bit biased towards that. Action Replay allows typing assembler directly on the visible disassembly listing, whereas in FCIII one has to invoke the A command. Furthermore, the FCIII monitor insists that both the start memory address and the end memory address are defined when listing memory areas. In AVI, it's enough to type the start address and the monitor will happily start listing the disassembly from that address onwards.

The Final Cartridge variant has bit more on offer when it comes to displaying the memory contents in different ways. It is possible to display memory in “sprite” or “character” format, making the monitor into a rudimentary graphics editor. This is quite a well thought-out feature. The AVI instead has a separate sprite viewer which can be used to scan the memory for graphics more effectively. However it does NOT work as an editor despite being marketed as such. It’s possible to flip, invert and erase sprites, though. I suppose the AVI sprite viewer was probably meant for clearing sprite data for game cheating purposes.

Neither of the carts have a proper assembler package, which might have made these peripheral into real killer apps among coders.

BASIC extensions

Most of the added BASIC extensions on both carts focus on disk access. Of the two, the Final Cartridge boasts perhaps the larger set of BASIC extensions. They are somewhat superfluous as they cannot be accessed from inside program listings. Then again making them work in the listings would create incompatible code.

Both allow a more direct way of feeding the disk drive commands. It’s quicker to type DOS than the OPEN 15,8,15 rigmarole afforded by standard 64 BASIC. AVI goes a bit further and allows feeding of DOS commands via using a @ prefix, handily a direct key on the C64 keyboard.

Cumbersome "visual" entry to disk operations.

Both cartridges allow the entering of hexadecimal in the BASIC interpreter, which is a nice thing. There is no way to return decimal as hex strings, though, although the AVI monitor does have a command for converting between formats.

All in All

The common wisdom is that AVI is the superior of the two, and I am not going to argue much against that. Yet either of the two perform the core operations almost equally, though, and the FCIII is not a miss by any means. The Final Cartridge has a nice PACK function and some of the editing capabilities of the monitor are better thought out than in AVI (whereas some are not) but the desktop tends to be more of a disruptive technology than an assistance. Fortunately you can skip the desktop by holding the Commodore key when booting.

Concerning the desktop of the Final Cartridge, I have been perhaps overtly critical of a product that was made more than 20 years ago! The disk versions of Macintosh, Atari and Amiga desktops of that time, looking back, also appear slow and inconsistent nowadays. For what it is, FCIII visuals are quite well made. However, overall the graphical desktop seems a bit pointless exercise as nothing can be stored permanently, no preferences or window positions, anything. Even transitioning between notepad and the desktop loses the window positions. I can enter BASIC from the desktop and return to the cartridge only to find that all preferences are reset. So it indeed is a bit of a gimmick.

Edit: Additional note in favour of Final Cartridge III is that the fast loader is compatible with SD2IEC card reader, whereas AVI's fast loader is not. So, although I like the AVI features better, I tend to use FCIII for this reason.

Boxed Raspberry Pi

I put my Raspberry Pi into a plywood box to create this 1980s-inspired integrated "home computer". This time I'll spare the details. I used almost similar approach with the ZX Evolution. 

A slight annoyance when casing the Rasp' in this way is that the different ports and inputs are scattered to all four winds. Yet I wanted to avoid soldering. I positioned the board to the back right side of the box, allowing the SD card, power and HDMI ports to be visible from direct openings. I extended the other ports with off-the-shelf parts and led them to the backside. My aim was not to spoil any existing parts, so basically the casing holds a huge amount of cables which could have been in principle shortened and re-soldered. For this reason, the box is quite tall, 58 mm at the highest point. (The footprint is 330x195.)

The keyboard cable is contained in the box in its entirety. Likewise, the audio jack is continued with a ridiculous extension piece, because I did not have a shorter one. The USB ports are simply a Targus USB hub screwed in place, cable and all. I continued the RJ-45 with a short piece. Only thing I soldered was the TV composite lead into the "port" at the backside. The audio could have been connected to these RCA sockets, but for my use I find the headphone jack more convenient.

From left to right: opening for HDMI. Composite. (7 unused) Stereo audio jack. Internet. 3 USB ports.

Compared to the Evo project, this time I had a clearer idea about how to do the box. The cover panel and the side and front panels form one part. The sides and the front are again from the 9mm plywood. The bottom is similar to the material used as backsides for cheap bookshelves. The top is made from material taken from the backside of a photomount. Both about 3mm thick. (Apologies for the unprofessional description. I just can't know what exactly these chipboards are made of.) 

The keyboard (A Fuj:tech/ Deltaco) is very similar to the one I used previously, so I knew what to expect. The keyboard, with the plastic cover removed, is connected to the box cover. The bottom and backside of the computer are joined together, so only the keyboard cable crosses the bottom-top boundary. The box is held together with four 3mm machine screws from the sides. This way, the case can be closed and re-opened with relative ease.

A nut for receiving the machine screw. It is overlayed with a thin veneer or balsawood strip that keeps the nut in place.

I'm quite pleased with the result. The rough and simple look has its charm. It is vaguely similar to BBC B, C64 and maybe some MSX models. Granted, it might not be a very wild, innovative or original use for the Pi. Perhaps some other time!

To be honest, I'm not a huge Linux or Raspberry fan, nor did I look into any existing projects when doing this. It might seem a bit silly to put such a small computer into a box this big, but I find it neater to have all the required parts in one convenient place. And yes, the retro nostalgia factors heavily here. I'm running a RetroPie installation on one SD card and messing around with OpenELEC Mediacenter (The NOOBS install in fact) on another. Although the Linux terminal is a bit hard on the eyes on a TV, the games look more "warm".

The existing keyboard LEDs needed some air...