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.

Sinclair QL EPROM

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

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

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

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

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

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

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

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

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

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

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

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

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

The parts list:

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

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

The board

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

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

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

The prototyping board and the blade for removing through-plating.

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

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

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

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

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

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

Sinclair QL Tetroid disk interface / memory expansion

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

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


Fitting inside the case

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

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

First boot up experience

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

Whaat....

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

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

Now I can move to writing on QL...

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


Without the CF Card

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

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

Left: Showing memory in BASIC, Right: after running the TK2

The Tetroid manual leaflet obviously does not explain how to use your QL or the extensions. It doesn't even describe the Trump card functions, so the manual for that device is recommended reading.

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

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

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

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


Using HxC Floppy Emulator

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

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

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

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

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

http://www.atari-forum.com/viewtopic.php?t=29580

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

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

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

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

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

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

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

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

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

Phew...

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


More

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

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

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

26.11.2017: Addendum

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

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

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

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

Zoo 2017

The grandeur of ZOO (not my computers)

Last weekend I went to the Commodore 64 demoscene party ZOO, held in Akaa, Finland. I participated in 2013, very much intended to participate in 2015 but that plan fell through, so it was nice to "return" to the ZOO atmosphere.

I've never felt like a huge scener, but I've started to recognize and connect a bunch of faces and names, so I guess something is happening :) This is not a party report/review about who was there and what cool shit happened, I'll just ramble about my own participation and the presentations and compos there.


At the Competitions

The PETSCII competition

There were numerous categories: demo, basic demo, graphics, music, wild, party, PETSCII and party feature. A sort of specialty of ZOO is the heavy emphasis on the PETSCII text art competition and the BASIC compo as an added flavor. Both usually have a spate of joke entries so I was surprised to see everyone had taken both quite seriously.

Dr. TerrorZ: Paradrone, C64 PETSCII

Although the standard of the PETSCII stuff was very high overall, I felt a bit weary about it. I guess I'm projecting my feelings about my own competent-yet-a-bit-tired work for the compo here. One novelty was Marq's stereoscopic PETSCII image, I guess a proof of concept that it's possible!

For the graphics compo, I had prepared a multicolor bitmap, again made with Multipaint. I'm quite happy about the process, this time I avoided spending hours and hours on anti-aliasing and dithering. Compared to my Inside Job with same subject matter from a few years back, the figure is much more dynamic.

Dr. TerrorZ: Infestation, C64 multicolor

Against some of the best of Finnish (and some international!) C64 talent, the pictures were not enough to reach prize positions. I also made a BASIC demo entry, but less I say about that the better - I had hoped there would have been only 2-3 entries.

The 2013 victory kind of made us responsible to participate, so it felt a bit bad we did not have a demo for the main event. I guess the main demo compo was ok, but it was getting a bit late I could not pay so much attention to it.


Presentations

Before the compos, there were presentations galore. Marq gave a presentation about PETSCII and the PETSCII editor, based partly on our academic work and partly on the development side of the editor. There was not that much news to me obviously. The creation of the editor was very much tied to the 2013 ZOO compo so it was nice to see it addressed here. But there can be such a thing as a PETSCII overdose :)

Juho Kuorikoski, the author of many Finnish gaming books, was pimping his new C64 book, which sadly was available only in very small numbers. The crowdsourcing campaign probably meant only the contributors receive the book first. Not obsessed with the C64, his relation to the computer could be defined as "normal", so perhaps he is the right guy to write a thorough popular book about the Commodore phenomenon in Finland.

Another enjoyable presentation was given by Pasi Hytönen, the guy who made the game Uuno Turhapuro Muuttaa Maalle back in 1986, pretty much the only Finnish film licence game in Finland in the 64 era. The batch was not too huge, so especially the disk version fetches high prices in net auctions nowadays. Pasi talked about his ORIC/BASIC days, and I was surprised to learn he had been quite involved in the game development scene ever since. (Including 1990s dead ends such as WAP/mobile/multimedia stuff)

It exists, it's real

Gideon, the Ultimate cart guy, gave a Q&A presentation about the new Ultimate 64. He had a functioning board with him, and although it's as good as finished the release is still some times off. He sold all the Ultimate cartridges he had with him, so I wasn't too tempted to buy one. Guess I'll save my money for that total machine, although the benefit of a cart version is that you can use it with any C64...

It would have been sweet if the new C64 and the new C64 book had been properly available at the party, but what's impossible is impossible. What with both the Uuno programmer and the musician ("Jori Olkkonen" back in the day) present I sort of half-expected some announcement of a new collaboration, but I guess that would have been too strange to happen.


Other stuff

The venue as a space is excellent, as the main hall is clearly designed for performative presentations. There's ample room for tables, there's a mezzanine, sauna and connected hotel rooms (for those quick enough to grab these).

The bar inside the main hall, next to the computer tables is a bit of a mixed blessing. Yes, sure it provides a constant atmosphere and is a very clear and professional way to access all merchandise/drinks. But the sound of bar chatter nearby can also be a bit distracting, especially when there are more "serious" presentations.

It's nice to have active lights, but truth be told I'd prefer if the display projection was a bit bigger.  I also sometimes wondered if the saturation from the C64 signal is a bit overblown with the projector. The C64 pics looked almost like ZX Spectrum sometimes. This seems quite common in parties, though. I guess an effort has been put to give a good quality image, and maybe the image is more "technically correct" in some ways, but does it correspond with a conventional monitor display?

Overall, amazing times. Maybe the 2013 event had more novelty and excitement for me, as it was the first time for me, but all the events, participants and programme kept it interesting.

The ZOO 2017 on the net:

http://csdb.dk/event/?id=2425

https://demozoo.org/parties/3080/

http://www.pouet.net/party.php?which=277&when=2017

Blender notes

I use Blender so rarely I keep forgetting some of the commands, so I thought I'd create a small summary for myself. These are mostly relevant for low-poly stuff I sometimes work with.

The first thing I always forget: creating new panels is done with the weird triangle in the corner of an existing panel.

Play a sliding puzzle game while you model!

Removing panels is done by pulling a panel from the triangle to the panel that shares the complete edge with that panel. I didn't find a way to remove the right-most panel in the image above, because this rule could not be fulfilled.


Some keys:

TAB = switch between object / edit mode

CTRL+hold left mouse = draw a freehand selection area

A graphic doohickey shows whether vertices, lines or faces are selected. The box with the highlighted corners adjusts whether back-face elements are selectable. The magnet thingy can be used for snapping the vertex movement to other vertices among other things.

Left: point, line, face selectors. Middle: transparent selection, Right: Snap to ...

a = select all / none

g = grab = move

e = extrude

shift+d = duplicate

r = rotate

s = scale

CTRL+r = loop cut X,Y,Z

alt+m = merge selected vertices

In "Cycles Render" mode, shift+z switches between cycles render view.


Direct texture painting

I bothered to learn the basics of painting directly on textures, so here are the notes:

-Drag two new windows into existence, the UV/image window and the Node Editor window (tick "use nodes").

-Use Cycles Render, otherwise the following material stuff won't work.

-Remove the existing material, create a new one, which will become visible in the Node Editor.

-Create new image in the UV/Image window.

-In edit mode, use 'u' to produce a smart UV map for the object. A tiny bit of island margin can help.

-Use shift+a in the Node editor to add texture image node, connect it to the material color and select the previously created texture map.

The mandatory first attempt weird-face

Texture mode should now allow painting directly into the chosen object.

Key 'f' works as a shortcut for resizing the brush, whereas 'shift+f' changes the effectiveness. The usual mix/color/blend/multiply options are available, as are some smearing tools.

The image has to be either stored separately, or using the Pack PNG option. I sometimes lost work because this was a bit ambiguous, so it might be better to store separately. In any case with Blender, save early, save often,

Once the setup is in place, painting directly to objects is strangely intuitive

Opening the Mac Classic

Memory and half-removed motherboard

I got a bit worried about a possible battery leak inside my Mac Classic, so I opened it for the first time.

It turned out to be much easier than I thought. Remove four torx screws, pull out the back of the case. Remove the memory sub-board, then remove all the drive and power cables from the motherboard. Now the motherboard can be slid out quite easily. 

This is a pretty neat design for that era, or for any era for that matter.

The memory sub-board and the motherboard fully removed. Red spot marks the battery holder.

Two of the torxes were in deep holes, so I used an screwdriver with removable tip and an extension which gave the screwdriver some added flexibility. 

The board is very small, even when considering the memory sub-board.

Putting it together was just as simple. Push the board in gently, plug in the relevant cords as you go along.

The other half

After I put the case back together, I checked if the computer still functions. It only gave an empty desktop backdrop. As it's missing a keyboard, a mouse and a battery, this might be normal. Still, it's a bit uncharacteristically unfriendly response from a Mac, so I hope there is nothing wrong.

Alive or dead?

Supposing it works, what to do with it? The Classic Mac is one of the last iterations of the original design, so it's not that old really, 1989-1990 maybe. But this also means it still has the 8Mhz 68000.

Compared to 8-bits, it is a bit cumbersome to get anything running on it, as all the interfaces and connectors are a bit weird from today's perspective, and there's no "load from tape" option to fall back on. HxC floppy emulator apparently won't work with it, and the SCSI interface is not as common as the IDE.

Perhaps the best bet is to use the 1.44Mb floppies for file transfer, which at this stage ought to be PC compatible.

Uncomfortable perspective: the case from below, with the board removed.

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.

XORin' in the Free World

One day, I thought it might be possible to re-create my Fort Django on the ZX Spectrum. I abandoned this exact goal as there's not that much material that can be re-used and some of my findings discouraged me from this route.

Instead the code became an exercise in game sprite graphics. I wanted to have three huge-ish characters on screen with a smooth framerate, with a game that would again float somewhere near the Saboteur!, Bruce Lee and Dan Dare territory.

I decided on XORed sprites, so I don't have to do masks. XORing graphics means that the underlying pixels are inverted with the sprite pattern. It's a nice method in that with XOR the sprite drawing and erasing routines are exactly the same, because re-drawing on the same position leaves the screen as it was before drawing.

Granted, it can look a mess whenever the sprites overlap. Many complained about colour clash in ZX Spectrum games, but I guess XOR was partly to blame, too. Atic Atac is maybe the best game that uses the XOR approach, and it's very fast.

Early days. Using sprites adapted from Fort Django

I needed to plan the graphics and the game around the XORing artefacts, so it would not get too bothersome. This was the reason to move away from the Fort Django concept, as the ladders and furniture might create too many disturbances around the moving, overlapping graphics.

Another weird technique is to draw the sprites when entering the frame and erasing them on the way out. With a Commodore 64 you could simply check for the suitable scanline, but with a ZX Spectrum this is not possible. I'll simply have to ensure that each frame still does the same things even if there are no enemies on screen. This also means the game is fixed for the 3.5MHz timings. Such an approach is not very elegant nor portable, but it's justified to get a silky-smooth game in a closed environment that the 8-bit computer is.


The sprites, actually

Although XORing is a fast technique, I still had to revise my approach a bit. My initial target of 40x64 sprites with smooth framerate were clearly out, so I went for 40x48 instead, which is the size of the Saboteur human characters.

I can't even have true 40x48 sprites, but by doubling the vertical pixel size it is possible. Not only are the pixels doubled, but the underlying vertical screen resolution needs to be divided by two to make the XOR draw/redraw logic work. So I'm working with 256x96 screen with 1x2 proportioned pixels.

Drawing one "line" of the sprite data as 1x2 pixels.

This has the benefit that as I fetch the sprite graphics, I can assume the two subsequent screen line contents are the same, so the routine does not have to read them separately.

The sprite graphics are drawn from left to right, zig-zagging the two lines. The stack is pointed to a table that has the vertical screen addresses sorted out for every other pixel row coordinate, and these addresses are pop'ed for each sprite line. The horizontal component of the address needs to be added, too.

1x2 pixelled sprite data pictured in GIMP, with one data line highlighted.

The sprite Y-coordinates are also constrained to multiples of 2. This has the benefit that there is never a troublesome screen address boundary between the zig-zagged vertical pixel rows. Within the line, the zig-zagged pixel row can be changed with just incrementing or decrementing the address high register.

Other good things came out of the 1x2 pixels: Instead of needing 256 bytes for each sprite frame, I could fit a graphic frame inside 128 byte boundaries. The 40x64 sprites would not have fit in a 256-byte boundary anyway.

The pixel ratio is not that limiting, as the sprites can be drawn deal with it rather than stubbornly make something that does not fit. My current sprites are hardly the pinnacle of ZX graphics, but it looks promising. And of course the screen portions where the sprites are not drawn, can be in 1x1 pixel format.

Toying around with some gfx pretty much ripped from Dan Dare.

With this tweaking of the resolution I could draw apparent 40x48 pre-shifted pixel areas three times, after which the scanline is at the 16th line of the Display File. This would mean that a moving sprite at the top of the screen could become distorted.

I could use a portion of the screen for a dashboard, as in the image above, and these 16 lines might not matter. I am making a game after all, and not a generic sprite routine.

But then the silly me realized that if the sprites are drawn in a certain order, the scanline intrusion can be made nearly meaningless: If the first sprite to be drawn is at the top of the screen, the second at the middle of the screen and the third in the bottom of the screen, all happens smoothly by "racing the beam". I only have to take care that not all sprites move near the top or bottom at the same time.

The diagram below shows what happens during one frame. These are not based on actual values, the picture is exaggerated for clarity. In this example only the second sprite is truly both a: drawn before the scanline enters the pixel drawing area, and b: erased after the scanline leaves the pixel drawing area.

This brings certain limitations to what can be performed with the sprites in the game. For example, only the player character has full freedom to move all around the screen, whereas the other sprites would stay within invisible "cages". Yet these cages are so lax that by switching sprite positions these cages do not matter much.

Technically, it would even be possible to draw more sprites than the three, if the sprite drawing order is well managed. This is somewhat equivalent of multiplexing sprites on computers that have real sprites and good scanline routines. But I felt this might become a bit too complex programming exercise or limit the "cages" a bit too much.

So, there are now three "big sprites" and the player sprite is always the second sprite to be drawn. The game, whatever it might be like, has to be designed around the small limitation that the enemies can't go everywhere.

Animation frames were another source of trouble. I wanted to save frames by "baking in" the leg motion inside the shifted frames. But this produced too fast animation. So instead of four shifted frames there would be eight sprite frames for simply making the guy walk on screen. The eight frames make a total of 1K graphics laid out in 128-byte address boundaries.

What else? I didn't make a clipping routine, even if it's not too slow to check the coordinates and divert to another sprite drawing routine. I wanted to negotiate some programming time out of this project.

Dude, where's my game?

So, after making the to-hell-with-portability sprite engine, I could concentrate on the game. All I've made since the sprite routines is a tile-drawing/collision routine, a bit more joystick stuff and experimenting with ways to draw unobtrusive objects. It looks nice, but currently a bit limited for a proper game. I'll get back to this in some form, but it doesn't seem to happen anytime soon.

The summer holidays Ultima IV bash-through

Much like returning to some books and films time and time again, I feel occasionally compelled to complete Ultima IV. This is not as time-consuming as it sounds, as DOSBox makes the game very fast. I also use any help available on-line, such as the dungeon maps. The last few times I've played the 256-color modded game, but now I chose the more vanilla version. I know there's the luscious Commodore 64 update, but I can't bring myself to play a slow version any more.

It's always wise to keep the party small in the beginning, but this time I tested a theory that I would be better off without recruiting anyone until absolutely necessary (i.e. the very end). This makes the solution even faster, as the combat sequences and dungeon rooms are more simple to navigate with just the one guy. The battles are generally so easy in this game a fully maxed party is not really needed even in the final Abyss dungeon.

I picked a class that can use magic and can wield the magic wands (Mage, Druid, Bard). This time I chose a Druid, although I usually go with a Mage. I upped the character XP and gold by repeatedly exploiting dungeon rooms with a good monster/treasure ratio. The first room in Dungeon Despise is a pretty good starting point for this, it's near the British Castle and you don't need to waste torches to find the room.

When I had the ship and enough gold I went to Buccaneer's Den and bought that Magic Wand plus some of those oh-so-necessary lock picks.

After I had the 8th level character with 800 HP, I simply collected all the runes, all the stones, all keys, all special items (book, bell, candle), all "bonus" items (horn, wheel, skull) and gained Avatarhood in all virtues.

Rune locations I could still remember, but I had forgotten some of the mantras, this wasn't the case last time...

For the end, the party has to have eight characters, and levelling them up is a very tedious business. The game doesn't care if the characters are dead, though. So maybe having three persons with good-ish stats would be enough for the Abyss?

When my party had two members, I tried to educate Iolo by having my main player killed, so as to have an one-member party again. However with my (dead) character at 8th level I could easily encounter Balrons and stuff so it was a bit dangerous. I was happy with Iolo at 6th level and Mariah at 5th level. Then I recruited everyone else, mixed a huge amount of useful spells and headed to the Abyss.

When approaching the Abyss Isle pirate hideout, I came across a bug, shown above. I'm not sure if it is in the original code or a DOSBox (speed) artefact, but amidst proper ship-to-ship buccaneer battles I had to fight a bunch of miniature ships! The game resolved them as "phantoms", which is OK, but they could not move in the water. This means the south-easternmost ship could not be killed as it is out of reach for the players. However, I was lucky to have a couple of Tremor spells which destroyed the phantom shiplet.

And yes, the party was good enough to get through the eight levels of the Stygian Abyss, with on-line help to guide me of course. A couple of dudes died, but this only served to make the combat a bit more bearable. My party began starving inside the dungeon, but that's not a big deal as it's mostly combat rooms anyway.

Then I thought, perhaps the Abyss could be beat with just one character. I reloaded the game, killed off the party except my main character and entered the volcano of Abyss again. I kept my guy in good health and M.P, and also poisoned to avoid the enemy sleep spells. Quickness spells come in handy in certain situations, as having a bunch of Daemons around you can still be dangerous. But yes, it's silly how much easier and faster it is with just one character!

The Poison status preventing Sleep status can be considered a bit of a bug, but it's also a clever counter-move in an otherwise simplistic game engine. Why would there be the poison fountains in the Abyss, if not to offer a chance to gain immunity to the Sleep spells? There are versions that "fix" this feature, and I can understand the Abyss becomes reasonably difficult if this feature is removed, and the one-character approach probably would no longer work.