My Arcade Pocket Arcade Bubble Bobble

My Arcade Pocket Arcade

When will I ever learn? I just saw these on the shelf, and thought "Hey there's Bubble Bobble and Rainbow Islands together, well that's not too bad."

Again, it turns out these are NES versions of the games, not the arcade originals. This time it should have been obvious as the box screenshots make it very clear.

Now I have to add these are not necessarily bad versions, but this does fall a little short of my expectations.

Rainbow Islands

There are three games, Bubble Bobble, Bubble Bobble 2 and Rainbow Islands, which is the "Story of Bubble Bobble 2". The Bubble Bobble 2 doesn't seem to be "Bubble Symphony" either, which I learned is also sometimes called "Bubble Bobble 2". Discombobulating, isn't it?

Bubble Bobble does what Bubble Bobble does. Many have fond memories of it as a simultaneous two-player game, so the PocketArcade one-player environment can be seen as a limitation.

Bubble Bobble 2

Bubble Bobble 2 was perhaps the most interesting of the three as I had no expectations or anything to compare it to. It's a 1990s NES game, with bigger and more varied graphics, but basically it's quite similar to Bubble Bobble. Perhaps it serves a little better as an one-player game, as each of the screens provides a clear problem-like situation.

Rainbow Islands makes it most painfully obvious that it's not the arcade version. I still guess it's better than the ZX Spectrum and C64 adaptations, but it's a far cry from the near-arcade perfect Amiga conversion. The music no longer has the Somewhere Over the Rainbow quote which is sad.

With not one, but two battery compartments

Physically, Pocket Arcade is quite nice, colourful item and the horizontal layout is natural. It's not flimsy, especially with the batteries it has a reassuring weight to it. Recalling the Pixel Arcade Data East hits handheld, it's an improvement.

The buttons have a good feel to them, and the screen, although tiny, is bright and crisp.

You can power it with 4 AAA batteries or with a micro-USB connector. It's therefore possible to use an external power pack, which is good as I have a 20000mAh workhorse. There's also a headphone connector which can be helpful in some situations. The volume level can be adjusted and muted entirely.

Running with reserve juice

There's some of the usual laziness, you can generally only get back from games and game over screens by using the reset button, which also means the volume level setting becomes reset.

There's no real reason why the product of this size couldn't contain more games, just as the Pixel Arcade did, but maybe it's envisioned as some kind of collectible.

So, why not, a few moments of enjoyment with PocketArcade. For 30-40€ -ish. Gnnh.

8-bit joystick adapter using Arduino

One day, I was looking for a 9-pin joystick ("Atari" or "Kempston") to modern PC adapter. After some disappointments, I googled for a comparable DIY Arduino project and found what I wanted from here:

https://hackaday.io/project/9552-digital-joystick-8-bit-to-usb-adapter

There isn't anything to code, as the functioning joystick examples are already supplied with the library. But as the instructions are a little on the short side I thought I'd add my experiences.

Firstly, the Arduino I had installed from the Linux repository was too old. Most of my time was wasted trying to get the library to work, whereas if I'd just downloaded the latest IDE, I could have added the library very easily.

One way to do this is to download the library as a zip, then use the Add .ZIP library function from the Arduino IDE menu. It's possible the IDE may need to be re-run. If the library has been installed, the GamepadExample can be selected from the File -> Examples -> Joystick submenu.

Not just any Arduino board can do this. Arduino Micro and Leonardo are seen as HID devices, so they can pretend to be joysticks, mice and keyboards depending on what you tell them to do. I had to buy an Arduino Micro to even try this.

ArcadeStickExample may sound attractive, but it requires an Arduino Micro Pro instead! Obviously a single-button arcade style joystick could work here.

The hackaday page isn't very explicit about which wires to connect to which pins, although the GamepadExample.ino will give some pointers.

Adapter port view pins:

 1 - Up to Arduino digital pin 2
 2 - Down to Arduino digital pin 4
 3 - Left to Arduino digital pin 5
 4 - Right to Arduino digital pin 3
 5 - Not Connected
 6 - Fire to Arduino digital pin 6
 7 - 5V (Not Connected)
 8 - GND to Arduino GND
 9 - Not Connected

I'm unsure of connecting the 5V to Arduino 5V, it looks like it was enough to connect the ground (GND).

It's also possible to have multiple joysticks, but I don't need that now.

Quick and unscientific lag-test: On Vice 64 I tried Buck Rogers, Commando, Decathlon, Giana Sisters, H.E.R.O. and Stunt Car Racer and Giana Sisters (again) on Amiga emulator.

With some of the more crisp C64 games I could perhaps see tiny bit of lag but not more than Raspi BMC64 or The 64 Mini/Maxi. All within sensible limits to me, and possibly not even because of the adapter really. Playing 50hz games on 60hz display is all kinds of wrong to begin with, anyway. Stunt Car Racer on the Amiga felt pretty good.

Building the box

I toyed with the idea of placing the Arduino inside my main PC, and have the 9-pin port through the casing. At the other extreme, I thought about putting the adapter inside a joystick.

But it's of course best to have it as a separate adapter after all.

For once, I thought it would be better to build the box from something else than chipboard or wood. Looking around, an old Mini-DV cassette case looked the right size.

I cut a prototyping board with 3x1 islands to the precise inside dimensions of the box so it would be held in place even without screws. The 9-pin connector required a large hole at the other end of the box. As the proto board was now in the way I simply cut a hole in it.

As the wires needed more space this proved to be insufficient and I cut the whole board shorter, as can be seen from the above picture. But it stays in place well enough.

Also, to save space the Arduino had to be soldered directly to the proto board. I cut excess pins from top and bottom as the wires needed some more room. A different positioning could have helped here. I didn't foresee it but in a way longer wires could have been easier to fit.

The micro-USB connector was initially meant to stick out neatly of the box, but because of all the mess with the wires, the port is a little deeper. Another idea was the box would also keep the USB cable in place, but the box is a little too flimsy to help keep the cable in place. Also I didn't want to make the cable a permanent part of the adapter.

So, the usual story, a relatively clean and well-intentioned project becomes messy at the point when soldering and wires are needed. I had to cut and whittle the box in so many places the end result is no longer very robust, but it will do. It keeps the things inside cleanly enough.

1541 Ultimate II

Finally I got the Ultimate cartridge for the C64.

Not the II+ mind you, but a second hand version of the II, with the tape emulation add-on and the Ethernet-USB dongle thrown in.

The adapter has the label "NO:usb 2.0 LAN JP208 MADE IN CHINA" and that's all I know of the brand and make of it. It's good to have an already proven solution included.

Firmware upgrade

I didn't really buy the cartridge for the Ethernet functions, but I was curious enough to want it to work. It happened the u1541 firmware was 2.6 and needed upgrading before this would work well. In any case it must be a good idea to update the firmware.

At this moment I realized the Ultimate cartridge, despite being highly rated and professional-looking hardware, has a rather scattered and a bit confusing documentation. Well, it's quite common for any of these hobbyist add-ons. As I got this second hand the docs may have been lacking.

So, an upgrade 2.6 version to 3.07beta needs an update.bin file in the root folder of the SD card (Usb stick is not enough). When booting, the update will run.

Afterwards, I could upgrade using u2u files. (I guess u2p files are for the plus) When I had my 3.4c version going, I could finally see the IP address on screen.


Remote control and file transfers

Now it's possible to telnet to that IP from another computer, using port 23.

PuTTy is fine, but correct settings are needed for display and cursor keys and backspace.

Initially arrow keys or function keys did not work without pressing Control at the same time. Changing PuTTy keyboard settings to VT100+ helped. "Initial state of cursor keys" is "normal".

Local echo and local line editing are both "force off". Backspace is set to "Control-H"

Also, the font did not display correctly despite changing it from UTF-8 to ISO-8859-1:

I fiddled with various settings, but apparently I needed to untick the box that says "override with UTF-8 if locale says so".

After this it started working properly:

The telnet connection is quite impressive and it's nice to have the remote for viewing files in quick succession. The software inside the cartridge does not care what state the C64 is in, so the menu can be operated all the time the power is on.

ftp is also possible, but any attempts to integrate it to caja (the Linux mint file browser) were not especially successful. I could see the folder but file transfers failed. The same with filezilla, a file manager, which seemed so convoluted I wouldn't probably use it even if I found the correct settings.

Instead, I got it to work using command line ftp to the IP address. First use 'binary' to set all further file transfers to binary, otherwise files will be sent with incorrect file lengths. (despite the system saying its switching to binary for the files.)

'ls' gives the remote folder contents. 'cd SD' is likely the first move, to get to the root folder of the drive. Then 'put' puts a file on the local current folder to the current remote folder, and 'get' does the reverse. 'bye' exits the ftp command line.

Apparently the telnet and ftp functions don't mesh together, so you can't upload a file using ftp while "in" with telnet.

Edit: Apparently they could work together, but it's just that messing back and forth multiple times with either ftp or telnet tends to lock the cartridge. A script that sends a file on ftp and launches it via telnet, may work one or two times. This could be related to a bug/oversight in the cartridge.


Some fooling around

One of the main functions of u1541 is the utility cartridge collection. For the purposes of using the cart for running files and general compatibility, the Retro Replay cartridge seems to be the standard.

But there are others, such as Final Cartridge III and my old friend Action Replay VI.

For fun, I did a code snippet on the monitor. (Invoked by MON).

Well, the monitor is in the Retro Replay version of the cart too.

AVI was the original environment where I learned the first steps of assembler in the early 1990s.

For a long time these were the last steps too, because I didn't understand how to structure these programs at all.

Now I see that it would be possible to write long programs using the monitor, giving enough room for subroutines and using a meticulous paper documentation/mapping.

There is another interesting cart, the Turbo Action ROM by Soundemon/Dekadence. This contains Turbo Assembler:

So the same code snippet can be written this way. The source can be assembled by pressing arrow left (the "esc" key, not the cursor key) followed by 3.

After assembling the source, the cart can be reset, and after activating the Tasm again the source is still in place. (If it's not overwritten I guess).

Perhaps this would have been helpful back in the day. However I must say that it would be really painful to write long sources with this one and writing code directly in machine code monitor might even have some advantages compared to an assembler. There were of course various techniques for splitting the code, and in the end it might require the kind of forethought and paper mapping as with the monitor.

Overall

The core functions of the cart are supreme and I probably won't look too much back at SD2IEC and IRQHack.

Yet, it seems the cart is trying to be a bit too many things, yet some obvious things are missing (if I'm not wrong). Effort has been put into areas that are not that interesting to me, like printing or some weird audio extensions.

For example, from what I've read and experienced, the cartridge does not seem to allow straight-up transfer+execution of the transferred file. You have to manually launch the ftp-transferred file from the menu. This doesn't sound a lot, but it's an unnecessary step and a more direct result would been better for building and executing code.

This is something the IRQhack could do (although again in a limited way) and I don't see a reason why the Ultimate would not if the software was put into place. Maybe I am wrong and the function is there somewhere.

"Data East Hits" 8-bit Gaming My Arcade Pixel Classic mini console

Disclaimer: Your kid might in actual fact eventually become bored

Over the years I've seen a bunch of "50 games" type handhelds at supermarkets or department stores. As the games and physical design are always so bland and generic, I've avoided them.

Now I was lured in by a Data East-branded "308 games in one" cheap device that comes in various attractive shapes, notably the horizontal Lynx/Gameboy Advance form and the more obviously Game Boy shaped hand held console. There's also a mini arcade shape that I did not look at twice.

Options. Oh the buttons can be lit up too. Why?

I went for the Gameboy shape for novelty's sake, although to be honest the horizontal form might be better as a controller and for connecting the leads.

Ergonomics to hell, the case has been shaped with "pixel arty" corners, but this matters very little. Designers take note, perhaps this is an indication we've got past that roundening-era of design styling.

The plastic feels a bit flimsy, but the buttons give an adequate response. There's a 5V micro-USB style power connector, AUX out and AV out. The device works on 4 AAA batteries, but the other options sort of sold this to me, even though no cables or batteries were included with the price. (about 30€)


The game collection

The Data East name is boldly visible on the package, and as their back catalog boasts some really iconic stuff (Burger Time and Bad Dudes vs. Dragonninja) I was prepared to expect at least a good bunch of playable games.

I prefer Mr. Do's Castle (not included)

The word "arcade" might mislead you to think these are arcade version of the games, not to speak of the screenshots in the inlay card.

I can't believe that in this day and age I could still get duped by a "wrong platform screenshot". Thanks for making me feel like a child again, but perhaps not the way I expected...!

Screenshots may vary.

Yet the shots are made in a way that although built from arcade screens they might arguably represent "game covers" rather than actual gameplay, hence the logo overlays. And it DOES say on the cover, "8 Data East + 300 games", but that "plus" is also quite easy to miss. And it DOES say "8-bit" which should clue in that the games can't be arcade quality.

Let's make it clear: About 95% of the games are simplistic, NES bootlegs or otherwise very poor quality.

Real screenshot for comparison

On the first page we get Dragon Ninja, Break Thru, Caveman Ninja, Heavy Barrel, Side Pocket, B-Wings, Karate Champ, Burger Time... These are up to the quality of the NES versions of these games, which is to say they are not all that hot but mostly they play well enough.

But after the first couple of pages it goes downhill. So, enjoy the excitement of iconic 8-bit games the likes of Man in Red, Repair Urgently, Speed Man, Unusual Space, Girl, Tactful Monkey, Devildom Doom and so on!

There's pages and pages of this shift

Many of the games are old bootlegs and hacks of licensed games, like Dada is obviously Popeye, Primitive Woman is supposedly a Tom and Jerry game and Sunken Ship is worked from 2005's Titanic, which in turn is a hack of a Tom and Jerry again. Astro Robo To To is Astro Robo Sasa. Aether Kadass is Macross. Sky Invader is Sky Destroyer. These bootlegs can be semi-playable or interesting as such because the game content is kind of there. But I'm wondering how this particular collection of games got to be curated.

There are many scrolling vertical shooters, the best might be F22, with actual power ups, boss fights and varying levels. I guess it is another rework of something else.

The bootleg of a bootleg

I'm prepared to say some might even be filler crap made specifically for this device, varying a base source code to produce simple shooters and jump'n'runners.

Some games have visuals that go beyond NES, like Cut Fruit and Curly Monkey 2, but design-wise, there's not much thought on the gameplay or level design.

Some games are so simple it's harder to fault for what they are, like Horse Racing where you simply duck and jump with the horse. However there's a bunch of boring sprite-shoots-sprite stuff, guy jumping on platforms, or collects stuff falling from heaven, with slight variations and different skins. There's even a digital paper/rock/scissors game, which must be the pinnacle of sadness.

Dark Castle. Wasn't this Thunder Castle on the Intellivision? Looks crappier.

At least one track'n'field-type game has been blown up into a dozen, with javelin, long jump, hurdles etc., even making Breast Stroke and Butterfly Stroke into separate games. Although I have to admit it may be a better idea than try to endure a full decathlon. A panda takes the place of the sportsman, possibly a clue about the country of origin of these games.

Then there are card games and board games such as mah jong, reversi, checkers, sudoku and so on. These can't be overtly blamed if they are simply bootlegs of once commercial games. Sadly there's no chess, though. Other genres are absent too, there's no Tetris or Columns clone for example, and no proper top-down driving game with rotational controls either.

Dark square at right = Portuguese draughts? Your move.

Then there are doubles, that is the same game with different graphics. This is a bit irksome as usually both graphic variants are just as visually uninspiring.

Overall the games boast very mediocre, bland and unimaginative visuals and sounds, while the game titles convey an idea of non-IP-infringing nothingness. It's almost as if I'm witnessing a relic from an alternative universe Earth culture that had strangely failed to invent any of the central video game brands we have.

You go... eh, girl!

All in all, the Data East games are probably the most playable of the bunch and Burger Time might indeed be the best game on the entire device.

I'll review all the 308 games later.


Final verdict

I took the device to a composite video TV. As I don't have a proper 2,5mm AV cable I used a single tip/sleeve version which produced only a black and white image. Or is the output only B/W? This was enough to show that the device does produce a smooth frame rate for the TV, which is nice. Of course a few of the games give jerky scrolling or flickering sprites due to programming techniques.

A 5V 1A phone recharger cable seems to be sufficient for powering the device (no specs in the manual) so the absence of a cable in the package might be justified. However the 2.5mm TV cables are less often seen.

One annoying thing is the device can't remember the volume setting when returning to the menu. it can remember the menu positions so why it can't keep silent? Wading through the 308 game menu can be tiresome, even if it can be scrolled sideways too.

So, is the My Arcade 8-bit Gaming Pixel Classic any kind of value for money? Despite all the misguidance, I could still be generous and say there are about 30 reasonable quality games in it. Even then 1€ for each might still be a bit too much!

It's a bit sad considering the hardware might be capable of doing justice to the arcade versions of the games, but the conversion job would have been overbearing. I doubt the device is good enough to really emulate the suggested arcade platforms.

Perhaps if the game ROMs can somehow be rewritten, the device might be much more interesting because the physical hardware is OK-ish and the screen and sound quality is not that bad. I am a bit doubtful if anything inside can be easily upgraded, though. Missed potential I'd say.


Addendum 18.6.2018

As I saw the device might be easily opened, I had a peek inside:

For those interested in subduing the sound, this might be achieved by physically blocking the loudspeaker a bit more. (There are like 2 loud sound levels + silent)

The parts are not especially neatly connected so it was a bit of a bitch to put back together. So I'm probably not going to open it again.

The game ROMs are likely buried inside that alien tar shit thing. (Hmm the SPANSION S29GL256P10TF is memory, though). Putting the screen back, it has to be straightened by hand. Luckily it can be done after the board has been screwed back in.

ak tronic EPROMkarte 256k

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

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

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

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

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

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

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

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

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

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

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

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

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

cat filename1 filename2 > output_filename



Switching EPROMs from software:

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

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

X=PEEK(57280): SYS 64738

BIT $DFC0
JMP $FCE2

Card addresses:

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

This way an EPROM can be selected:

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

The user EPROM needs to be on too.

The half/slot value is construed this way:

2764 8KB chip:$30 = 48

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

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

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

In assembler, this subroutine selects/deselects an EPROM:

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

Then call $C000 (49152).

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

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

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

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

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

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

IRQHack64 impressions

The IRQHack 64 may not be as widely known as the SD2IEC disk emulator or the Ultimate cartridge. The IRQHack loads Commodore 64 programs (prg) super-fast and does small cartridge (crt) files too. I also hear about a possible serial transfer between a PC and the C64.

As can be seen, IRQHack uses ready-made Arduino components (A Pro Mini or a variant). The IRQHack is developed and prototyped by Nejat Dilek, with schematics and PCB design by Özay Turay.

http://www.tepetaklak.com/IRQHack64/

I bought this one as assembled inside a neat 3D-printed casing, with the EPROM burned beforehand. The only thing left to do was to format a FAT32 microSD card and put the necessary files there. Without a prg loader menu, the cart doesn't do much.

http://www.tepetaklak.com/data/IRQHack64Turbo.zip

The archive has two separate file menu alternatives:

C64\Menu\I_R_on\irqhack64.prg
C64\Menu\wizofwor\irqhack64.prg

One is needed in the root folder of the SD card. The I_R_on menu is simpler, the wizofwor version has a moving graphics effect. Both have background music which I guess is ok for showing that the sound works, but it feels a bit unnecessary.


Up and running

Pressing the button rapidly, the menu will be activated. Pressing it for a tiny bit longer generates a normal reset. Pressing it 2-5 seconds (it gets complicated!) the current selected software can be made to autostart the next time the computer is powered on.

Using the cartridge reset or reset from a separate device did not result in the prg autostart. I guess it could bring complications, but an auto-run from the reset would be useful too.

The mess in the right is from running it as a prg from the other menu for shows. It doesn't do that really.

The menus don't have much functionality in them. Both menu alternatives use + and - keys for up and down, which I felt was slightly clumsy, arrow keys might have been better. The SD file folder structure is supported.

I also noted that some game prgs crashed, although they worked with the SD2IEC. I've not looked deeper to this, but I did try a different C64 and removing the peripherals, with no result.

For the single purpose of loading prgs fast, IRQHack is very handy. It's also nice to boot directly to the program you want. Make the C-64 boot directly to a SID tracker, image editor, or a comprehensive file menu system?

Not that I can get it to do anything.

I thought about comparing the IRQHack with the SD2IEC but it's a bit pointless as I can connect both at the same time. The IRQHack potentially complements the SD2IEC setup, except as I can't have the Final Cartridge or Action Replay I lose monitor and fastload functions.

As a small consolation a RAM version of Jiffydos can give a fastloader at least, but in this form it can have some limitations. It could load a single-file game from the SD2IEC rather nicely, but on another occasion a program failed to run properly with the Jiffydos in RAM. It can still be helpful in supporting common file operations.

As the IRQHack does not do disk emulation, and the cartridge image loading is limited, it is far from an end-all solution for your favorite games and demo library. It might fall uncomfortably between Ultimate (which I still don't personally own) and the SD2IEC, but it is a reasonably cheap & nice tool for someone like me who dabbles in C64 code and graphics cross-development.




Until the next time

These were my surface impressions, I'll get back to the serial transfer function when I have a USB-TTL serial cable for the Arduino pins. In my eyes this would improve the worth of this cartridge a lot if the transfer works as smoothly as I hope it would.

In the future I might also get into the sources a bit more. I installed 64tass assembler to my Linux, and using the .bat files as guidance, I had some success with compiling irqhack64.prg. 

The version I compiled could not in the end access folders from the SD card so I'll forget about it for a while. It might be that the C64 menu program, the EEPROM stuff and Arduino code all have to be corresponding versions (the included script compiles everything) and I currently don't have the gear and patience to do all that.

Part 2: IRQHack64 and serial transfer

TAC-2 fire button microswitched

A tiny project, but food for thought never the less.

The Suncom TAC-2 is very nearly the perfect joystick for 8-bit games. Tiny, crisp, with short travel. Yet I have to admit the fire buttons have a slightly vague response and are prone to dirt problems.

So I thought it could be interesting to replace the fire button contacts with a microswitch. I'm not a big fan of microswitches as they tend to be a bit noisy in the home environment (I'm looking at you Quickshot II Turbo) but I suppose one fire button would not result in a cacophony.

The bigger switch was chosen. This is the first with the overdone groove!

Then I opened the joystick, admired the insides and spent some time trying to find a good location for the switch box. I had two varieties of microswitch, the bigger comes with a metal lever actuator on top of the box and I saw this would be easier to set to place. I have no idea if these switches are well suited for video game controllers.

It appeared that the simplest route was to carve a slot in the thin vertical protrusions. I also made small grooves to both sides of the micro switch box, so it would not fall out of the slot.

The carved slot. The existing metal flaps & connectors are good for inserting cables.

My first attempt was a bit too hasty, and the slot ended up too far from the fire button metal plate. Fortunately TAC-2 has very neatly designed insides, so I could insert the original part back over the failed groove. Attempt 2 hit closer to the mark and the resulting hole was more accurate besides.

The above image shows a not-to-exact scale of the microswitch position in relation to the plastic protrusions under the fire button. The grooves made to the switch are exaggerated. With the cables I did not break any existing parts, I inserted the new cabling to the pieces holding the metal flaps.

TAC-2 insides, complete with the switch, un-wired.

Although a levered switch is quite lenient, it still needs careful vertical positioning. Strangely enough placing the metal contacts against the floor of the TAC the metal lever is in pretty much correct position.

Much to my chagrin it did not work. Yes, the button gives a satisfying audible-tacticle response. But the C64 I tried this on seemed to miss button presses. The old fire button works so it's not a problem with the joystick plug.

Being a bit lazy I did not test the situation more closely. The switch itself appeared to work. Here's my thoughts:

• The groove at the side of the microswitch was too deep & the side of the slots pressed the insides of the switch
• The switch did not have enough room for a proper release, even though it sounded ok

Ends well

Well, I took another microswitch, took a care not to overdo the grooves, widened the slot a bit to compensate, adjusted the positioning a bit. As a result the switch box is not as tightly stuck to the slot, but it ought to stay in place.

Is it good? Well, I played the best game of Paradroid ever on my Commodore 64. I was surprised to find that after the ship "Paradroid" there is another ship, "Metahawk". Well, it's the same layout all over so I got tired and gave up. Guess I was a Paradroid noob after all.

The mod is well suited to this game where it's quite crucial how and when you use the fire button. The micro switch is not that much noisier either.

I modded only one of the buttons, to preserve some of the historical crappiness.

Multipaint Metal Edition

Notice: The Multipaint site should be now ok.

Notice 2: Mac users, if you can't get Multipaint to work, check the website (link below) and check the comments too.

***

It's time I gave this 8-bit paint program (works on PC, Linux, Mac) a public update.

Largest change is the new color model, which is perhaps now a bit more sensible. If there is no "room" for a new color inside a color resolution area (say 8x8 pixels), the color under the pointer will be changed to the current color.

The old mode, which prevented color changes if there was no "room" inside color area, is still retained as the 'b' mode, as it can be useful when painting fast or using the geometry tools. (it's the huge B icon at the bottom of the tool box)

Demoing the new preset dither patterns and adjustable offset:

Multipaint supported custom dithers ("rasters") before, but having these presets might come in handy. The offset can only be changed by using the bracket [ ] keys, for horizontal and vertical.

Using a loose dither and changing the offset as you go along can produce nice results quickly, as in the image above.

However I believe that almost all mechanical approaches to dithering are bound to be more or less exploratory tools, and the real work is nearly always about making pixel-level decisions.

The keysheet, highlighting the key shortcuts I think could be most useful to learn first:

u/U for undo/redo

g for grid on/off, G for grid size switch

c for grid constraint on/off.
j for spare page (alternative page for holding brushes, fragments etc.)

m for magnify=zoom

, for pick color (also middle mouse button)
ctrl for force color (change underlying 8x8 area)

A couple of tips I forgot to mention in the manual:

-This type of drawing can benefit from having a slow mouse setting. Personally, I can't draw with very fast mouse.
-I often use VICE for previewing C64 images every now and then, because it's able to predict the color blurring of a monitor. This is also why I'm not too keen to add a preview window, because it wouldn't do it's job properly. However, it may arrive one day.
-If you draw a circle with a loose dither, then grab it as a brush and draw with the dither off, you can get a kind of "airbrush".

In the future

There still remains many items and known issues on my to-do list. Preview window, aspect ratio (That MSX!), better CPC output, more flexible UI, etc., but they'll have to wait for some time yet.

Overall changes for this version:

-Changed the color behavior to a more straightforward model. Old behavior retained as ‘b’ mode.

-Overall color behavior is more uniform between formats, multicolor and otherwise

-Changes to mouse event handling should make the program a bit more useable across platforms and computer speeds

-Added preset dither (raster) patterns and offset adjustment

-A bit more visible grid (not in plus4 and CPC modes)

-Metal User Interface. Why? I wanted some program changes to be visual. Tiny adjustments to icon graphics and visual behavior. Visible dither on icon, visible spare page on icon.

-Bug fix: UI elements overlapped in CPC mode when using ZOOM=3

-Bug fix: Machine selection through prefs.txt did not really work

-Bug fix: In CPC mode palette changes could not be undoed (in loading pngs for example)

The website:

http://multipaint.kameli.net/

Icon driven

When Apple Macintosh made a splash on the computer scene with its mouse/icon desktop interface in 1984, the occasion had a curious side effect. Software on humble 8-bit computers such as ZX Spectrum and C64 started to feature icons too. Not only utility programs but games were suddenly adorned with an interpretation of the WIMP (Windows, Icons, Mouse, Pointer) approach.

Of course, graphical interface elements had been hanging around for a while in different forms, but the Xerox Parc/Apple approach was the one that became, er, iconic.

It was exciting to have a peep into an icon-driven windowed environment on your cheapo Speccy or C64, as a Mac would be a very expensive ride. It makes me think that early 1980s home computer games were not only entertainment but demonstrative showcases of computer tech you could not otherwise have.

Here I've tried to include some of the more important, curious or representative icon-controlled games from this early period. Sometimes it's hard to distinguish the boundary between "icon-driven" games and point-and-click adventures, and I've only tried to include the most interesting borderline cases.


Alien

Arguably, Alien might not have been that much influenced by the Mac phenomenon. It is more reminiscent of earlier graphic CAD workstation displays, with a schematic plan main screen and text-based menus at the side. You don't have a floating cursor but menu items are highlighted. So, in effect the game can be played with two keys.

You are in control of multiple characters, and actions are afforded depending on whether there are exits or objects present. This is pretty much a semi-real time adventure game with rooms, items and locations. On occasions you may be presented with a graphic depiction of the Alien or Jones the cat scuttling across the screen. These incidents can be pretty startling, despite the primitive graphics.

As the scenario plays in real-time, icons serve better than text-based commands. It would be rather unfair to punish the player for slow typing speeds... Also, the relevant commands need not be remembered as they are displayed on screen.


Shadowfire

On the heels of Alien, Shadowfire was one of the earliest successful icon-driven 8-bit games, where the graphical environment was used as a selling point. Here, as in many games, the icons largely replace text adventure-style commands, for example using a combination of "pick up" and afterwards the icon for the object to be picked up.

The icon screens work pretty smoothly, but the arrangement is where the age shows. You need to click "computer" screens to get to the movement, battle and inventory screens and these computer icons are only differentiated with color. Some icons are puzzling initially, with added detail where a simpler graphic might have served better.

In hindsight it would seem obvious that a half-formed action could be cancelled by clicking the already clicked icon, but instead you have to go and select the "back" icon.

Even though the icon system is very slick, moving and managing six characters around a large map becomes a daunting task, constantly switching between screens and character selection. It's mind-numbing, and I start to wish there was at least a short-cut key to each character.


Enigma Force

This sequel to Shadowfire used the same icon system, but the main game plays in a real-time arcade adventure type screen. The complexity of Shadowfire is reduced, with only 4 main characters with 4-direction movement. The icon layout now scrolls when the cursor is pushed left or right, giving a more streamlined set of actions than in Shadowfire.

The characters can be given pre-programmed motion instructions, should you know before-hand how the map lays out, that is. There's also a "mind control" icon that allows direct control of a character via joystick.

The icons themselves don't look that much clearer, and in addition to the "back" icon there is also an "oops" icon to remove actions from the queue.


Aliens

Aliens from Electric Dreams took game elements from Alien/Shadowfire/Enigma Force, transforming the influences into an intense semi-first person action adventure.

Not an icon controlled game, though, which is just as well. The lineage and a game screen layout that is suggestive of multi-window environment makes the game worth including here. Perhaps it started to dawn on the designers that certain things were better done with keyboard.


Fourth Protocol

A Frederik Forsyth tie-in, the game is visually very reminiscent of the Apple Mac environment, but in motion it is a quite simplistic interpretation. The pointer does not move freely but is switched between icons, much like in Alien, opening up iterations for your decision tree.

The game is in reality quite text-heavy and at points you have to type in names and numbers. As the game opens you find yourself reading files and memos, assigning watchers to potential cases and getting reports out of them. Later on you go on a physical-world adventure which is extremely minimal in its descriptions. (i.e. "Victoria, Tube Station, Ticket Office")


Mission Omega

A very complete implementation of a windowed environment with drop down menus, the game could even be played with a mouse. The Commodore 64 version is especially nice-looking, but it's also imitating the Mac interface very heavily. The section where you build your droids is impressive.

After this section, I have to say the game content is rather minimal. You move around in a boring maze, giving orders to each of the robots.


Star Trek: The Rebel Universe

Admittedly, this is a 16-bit game, but it also appeared on the Commodore 64.

This is a complete icon-controlled game, without any drop-down menus or much text for that matter. One interesting idea is that multiple roles of the Enterprise crew are shown as mini-screens around the main screen, again something you might have seen in a CAD program.

Something similar was on the drawing board of the Electric Dreams' Aliens game. Sadly the Star Trek screens don't update in any real time, but that might have been the goal at one time.

There's something left of this idea in how further option screens come available as character screens are opened. Bringing these out (solar system, engineering, star chart) re-customizes the surrounding screens, but arguably these are just big icons.


Stifflip & co.

A very bog-standard example of an icon-driven adventure game, showing some elements of a nascent "point'n'click" adventure: the characters are shown on-screen. The humorous and big graphics makes Stifflip more memorable. The aesthetic has more to do with comic strips and silent movies than with Apple Mac.

Much like with Fourth Protocol, it's more of a graphic multiple-choice game with windowed sub-selections, and you'll be picking actions from text-based menus a lot.


Icon Jon

An obscure Amstrad CPC game that plays something like the Magic Knight games but the icons are more visually defined (and Apple style).

The game is controlled using a set of icons but also has computers, computer architecture and programming as the topic of the game. Bit like in TRON, the game depicts life inside computer circuitry. You can pick up and manipulate items and 'chat' with the cast of characters.

The title and game idea goes to show how intense the whole icon phenomenon was at the time.


Zoids

Four command icons placed around the main radar screen. As activities take place, new windows "pop up" around the screen with live sequences and further information. The windows "multitask" to some extent, so not all action stops just because you choose an icon.

You control a smoothly moving cursor, much like in Shadowfire. On occasion the Commodore 64 goes full on with the window overload, as every action seems to bring up multitudes of windows for iterating your action. The ZX Spectrum version is less impressive.