C64 wi-fi modem

I received this wi-fi modem for the Commodore 64 already a few years ago. The board has no identification on it, but it looks like a bare-bones version of the same design that has been going around, like WiFi-64 and Strikelink.

Although there are various C64-cartridges that read SD cards, there are not that many direct file transfer solutions between PC<->C64. So I'm mostly looking at the modem from this angle. The modem sticks into the user port so it doesn't take the cartridge space.

The first time round I had some success with contacting a BBS, but the ftp, wget and other internet functions failed to work for me.

This was all because of not knowing one command! Re-reading the manuals, I found out I can upgrade the firmware directly with the terminal, connected to the internet (as it could do that much). After moving from version 2.62 to 3.6.4 I got the wget file transfer working.

From here you can download the disk image with C64NET WiFi apps by Bo Zimmerman. These are BASIC programs for various tasks. The site also has more comprehensive manuals. 

A better terminal, such as the CCGMS, is useful for contacting Bulletin Board Systems, but that's not my focus here. The minimal CBMTERM included in the apps disk is enough for adjusting the modem parameters.

From the same disk, CONFIGURE is for the first-time setup of the modem. It didn't do anything meaningful now that it seems I've run it before. Sadly I didn't make notes then. After the basic configuration has been done, the CBMTERM can be used for changing the network and the network password.

Terminal

CBMTERM is a simple terminal mostly useful for sending those AT commands to the modem.

Here are some of the commands to try:

ATE1 for command echo might be needed if you don't see the characters you are typing.

ATW lists available and compatible wi-fi networks, together with signal strength.

ATW "[SSID],[PASSWORD]" will connect to a wi-fi network.

Note that this will respond with "ok" if it was succesful, and with "error" if the SSID is wrong or the password is wrong. 

The CBMTERM runs in lowercase, but everything you type in lowercase is actually uppercase in the outside world. So if your wi-fi network name is XYZ5235, you'll type xyz5235. Same with the password. 

My network name had a _ character, this shows as a left arrow on C64, and can be typed in as such.

ATI gives information on firmware and the wi-fi network.

AT&U shows if you can download a newer firmware.

AT&U6502 then actually downloads and installs the firmware. Despite instructions I didn't need to physically reset the modem. Of course if the service ceases to exist, the firmware update can't be done.

Moving files

Again from C64NET WiFi apps disk, the WGET can be used for downloading a file from a web address. The output filename and type has to be defined here too. The default suggests a sequential file, but if you download a prg the line has to read something like @0:myprog,p 

I first tested the wget with the default example, downloading index.html from Bo Zimmer's page. Then I moved to downloading a C64 program file available elsewhere on the internet.

Of course, downloading a file from a web server on your local network is ok, using the IP address. So if the server is set up then for me http://192.168.###.###/index.html could be downloaded.

The bytes will mosey down the tubes to your Commodore 64 drive. Even if the interface was improved (and why not, it's in BASIC), the downloading won't be especially fast.

After setting up an ftp server on a Linux over the local network, I could also try the FTP program supplied for moving files between my Linux and the C-64. The program asks for the ftp address (in this case an IP address), the username and the user password. Then it's ftp commands all the way.

The ftp is already more handy for transfering multiple files, but I have to say that handling the switch between passive/binary mode and such, also takes time.

Some observations

A wi-fi modem that runs on 1200 or 9600 baud max, isn't going to be the final solution for immediate transfer between PC and C64. But I can see it could reduce the need for swapping that microSD card.

Now I simply tested the features and downloaded everything on the mounted C64NET apps disk image. Later, I'll have to think about how and what I am going to mount on the SD card reader and when.

As the programs are in BASIC (with shared M/L libraries), some ease of use could be achieved by rewriting the programs to apply to my local situation. For example I could modify the program to default to my local ftp server address, or just making the connection directly.

I mostly used the modem in conjunction with the SD2IEC+Epyx Fastload combo catridge, with the fastload on. This worked fine, although it seemed to me that after I'd broken out of a "modem session" using RUNSTOP/RESTORE, the SD2IEC lost the disk mounting.

Using the Ultimate 1541 II with the Action Replay VI cart, I couldn't get the software to run. Moving over to using the Epyx Fastload cartridge all seemed to work better. 

However, with Ultimate, on occasions the FTP app produced hiccups and a file refused to load completely. This is not a final judgment about these cartridges, it might just be bad luck and the problems could just as well appear with the SD2IEC+Epyx. I could try to test this more.

But certainly I'd recommend testing the modem first with a more "clean" Commodore 64.

SD2IEC+Epyx Fastload combo cartridge

SD2IEC + Epyx Fastloader cartridge

SD2IEC has long been the sort of standard inexpensive way of accessing C64 files from a modern media. But it only becomes powerful when combined with a fastload cartridge such as Final Cartridge III or Epyx Fastload.

Juggling with the carts and power cables can be a chore, so someone got the clever idea of combining the fastload ROM with the SD2IEC for the Commodore 64. Here's a DIY version, my cart was based on this design. This was acquired from a certain tinkerer from Akaa, which I'm beginning to think is the C64 capital of Finland.

So, one-cart does all, and as a bonus it gets rid of the 5V power cable. As is usual with drive emulation, the serial needs to be connected.

Just as the plain SD2IEC, the cart has buttons for mounting the next/previous disk image and DIP switches for setting the device number. The Epyx combo comes with a reset button, drive reset button and a serial through-port has been included so for example a real drive can still be connected.

Switch the fastload on and turn on the C64, you'll see the minimal "fastload" message.

Epyx fastload cart isn't the most comprehensive or user-friendly cartridge, but it has enough functions, mostly single-character shortcut commands, a DOS wedge, disk operations menu and even a minimal monitor. It's worth reading through the manual.

LEDs shouting. At top, prev/next buttons and the drive reset. At right, C64 reset.

%filename loads machine code files, $ brings up the directory without erasing your BASIC listing. C= together with Run/Stop loads the first file on the drive.

My tiny gripe with Epyx is that $ for viewing directory is quite slow, and the loading commands don't auto-run files. Unlike other carts, the function keys do nothing. But then again the SD2IEC system works fine with the fileselector.

Plain SD2IEC also works with VIC-20, Plus/4, C16, C128, whereas this combo cart only works with the C64, so bear this in mind if you have more hardware.

Ahhhh.... weekend

For example, I copied my old SD2IEC card contents to my computer, then copied only my C64 folder to the new microSD card and the fb64 fileselector. This way, using C= + Run/stop keys I can run the selector almost instantly after turning on the computer.

There's a button on the cartridge that resets the drive. So if you have previously mounted a disk using the fileselector, you can reset the cart, press this button and bang, you are at the root and can run fileselector again.

Most people probably get the SD2IEC to load games and demos, but as a drive emulator it's also versatile for development on the C64, for saving and loading BASIC files for example. In this case it's maybe better to work with the root directory, even if it can get cluttered eventually.

It has to be remembered the SD2IEC is not 100.0% compatible with a C64 floppy drive and especially fastloaders give trouble, but it's true enough and if you find a game that doesn't load there's usually a version somewhere that does.

I've also seen a variant with changeable EPROM, which could be nice for that added tinkering value.

Physically the SD2IEC+Epyx cart looks like a heavy deal, and it is quite close to the core functionality of the mighty Ultimate: a drive emulation with built-in fastload. However, the Ultimate also offers much, much more, such as injecting PRGs directly to memory, choice of cartridges and so on.

Still, the Epyx combo is very neat and not too expensive package for the Commodore 64.

Finlux TV

Again, supporting the local fleamarket, a television for the glorious price of 8,50€

The model is a Finlux 24" 24FLK274SVDN, it doesn't appear to have any simpler marketing name. 

It's possible the same tech appears under various different brand names. ("Finlux" has little to do with Finland nowadays.)

The feel is plasticky and it doesn't weigh much. I could easily carry it in a bag.

Last time, I whined about the lack of 50hz displays for my Raspberry Pi Amibian Amiga setup, so I figured this would do at least something to amend it, and if it didn't then the price wouldn't be high.

As a bonus it might even do composite for a real C64 and work as a computer display too?

It has two HDMI connectors, a SCART, a tiny AV and a VGA. Two USBs and an internal DVD player. The internal info-sheet shows a plethora of different modes, video file formats and inputs the TV can supposedly handle.

And that's not nearly all

I punched it in to the Amibian Raspberry using HDMI->VGA adapter, and got some kind of ugly picture to begin with.

Then I took a step back and started experimenting with the options.

Bad news

The TV fares rather poorly as a computer display. I'm not sure if I expected it to do 1080p, the specs (provided in the internal documentation) says it can but in reality the native vertical resolution is 768 pixels. (Or 720, actually)

So the TV can camouflage itself into a 1080p and 1920x1200 resolution, but the scaled picture quality is not impressive on a HDMI. I'm not fully convinced with the framerate either.

Using a Displayport->HDMI adapter a laptop refused to recognize it as a second display, which wasn't nice either.

The VGA produced quite a bad image but this is something I'm now forced to use if want it as a display for the 2nd computer, as they don't have HDMI. (It might not be too horrible as I have only very specific purposes for the 2nd comp).

Removing all kinds of automation (not that there's much) and sharpening, the image can be improved a little.

Good news

After teaching the Raspberry Pi Amibian to do 50hz, scrolling was smooth. For this, I uncommented the 50hz HDMI portion of the Amibian boot/config.txt

This wasn't initially very satisfying as the display scaling would produce artefacts for scrolling games. For this purpose I adjusted the hdmi_cvt line (for custom HDMI resolution).

hdmi_cvt=768 768 50 1

The 1 gives aspect of 4:3, 4 would give 5:4 (Amibian recommended) but does it matter as the TV sets does what it wants anyway?

In the Amibian GUI config display panel, I selected 768 x 256, unticked "correct aspect ratio" and also gave -16 v.offset (maximum), but this depends a bit on the Amiga software. Sadly there's not more offset as some modes won't fit the screen even though the height is unlikely to be more than 256.

Of course, it's worth checking if the TV is in the 4:3 state, and not for example zoom 14:9!

This way, there's at least 1:1 correspondence between display pixels and scrolling doesn't "scale" and games like Battle Squadron, scrolling in multiple directions, now scroll smoothly with no jittering and "living" lines.

Edit: I think the vertical height of the display is 720, which gives a 240*3 as a 256-height screen will be cropped a bit. I don't get how the Raspberry setting of 768 works, maybe it reverts to 720.

Ugly news

Checking the composite and RGB options, I noticed the TV can't handle these signals really, but sort of combines two frames instead of having a proper progressive display. For example if the computer flashes a black and a white frame repeatedly, the result will be a solid gray. Apparently anything that is a non-HDMI mode behaves this way.

With a "life gives you lemons" attitude I could start seeing this as some sort of extra colour mode for ZX Spectrum, but to be honest the idea of building something on a poor display doesn't appeal to me.

Edit: I tried a real Amiga RGB output too, just in case it would produce something different. The picture was actually surprisingly bearable and the frame conflation is not immediately apparent when watching games and demos. Sadly, there was a tiny hiccup all the time in the frame rate. Also, flashing black/white screens finally reveals the same result as with all the RGB and composite modes.

BMC64 and THEC64

It gets a bit weird, trying to get a "fake" C64 to work with a "fake" display. But why would it be more fake than the Amibian+HDMI? Perhaps I find the idea of connecting an Amiga to a modern display more acceptable as it has a history of pretending to be a serious computer.

Also, the THEC64 is by definition mean to interact with a HDMI so it makes sense to see if the BMC64 really functions as a complete alternative to that product.

For the BMC64 c64 emulator I had to at first activate hdmi_safe=1 to verify a HDMI image at all. This produced a 640x480 image.

I then removed the safe mode and advanced towards a custom resolution. I found it's easy to come up with a mode that looks ok at first but again "blurs" two frames together as in the aforementioned RGB and composite modes.

So I copied the parameters from the Amibian config.txt and found the BMC can live with the same 768 x 768 setup. (The config.txt scheme is common to all Raspberry installs) 

With this the 50hz flickering test is passed. Then the display border sizes and stretch factors are adjusted from within BMC. There's still something a bit un-perfect about the horizontal size but at least it matches the pixel resolution somehow.

So I ripped these lines from the Amibian config.txt:

hdmi_cvt=768 768 50 1
hdmi_group=2
hdmi_mode=87
hdmi_drive=2
scaling_kernel=8

I have this Commodore 64 videotest software exactly for this kind of purposes. (1=horizontal scroll, 2=flickering screen (the 50hz test), 3=horizontal alternating lines, 4=vertical alternating lines, 5=checkerboard)

The text is part of the BMC overlay, C64 produces the test image.

I don't see how I'm no longer allowed to "Apply scaling parameters at boot", though. 

Admittedly the "screen ratio" test would be nice to have.

With THEC64, the TV is obviously recognized by the computer and the picture is nice and clean. The 50hz test is passed, horizontal lines are ok but vertical lines have some scaling trouble. This is probably because the device insists on a correct aspect ratio. 

It is more revealing in horizontal scrolling, such as the Giana Sisters intro scroll. Playing Giana Sisters, it doesn't really bother that much.

It's pointless to try to photograph how good the display is

A more thorough head-to-head between BMC64 and THEC64 will have to wait, but I'm now thinking both have benefits. But at least with this particular TV, the BMC64 again comes up with the goods.

The verdict

Had the TV been even slightly more costly, it might have been a disappointment.

But it suits well for the originally intended purpose, connecting the Raspberry/Amibian to a 50hz TV. It even exceeds my initial expectations in that area. For these lower resolutions, HDMI mode colors are good, crisp enough and the black is extremely, deeply, black.

There's soul-searching to do, as it is now the TV would cater both as a semi-retro display and a poor man's computer display, winning more space on the desk. But it's a clear step down for some uses, as it is not CRT and not a real computer display either.

C=key adapter 3.0a quick look

About a year ago, I had a go at rigging an Arduino to work as a PS/2 adapter. That adapter is working, but the software needed patching. I got it into semi-decent state but it still leaves a lot to be desired. (Shift+cursor keys etc work a bit randomly.)

In the meantime, I also ordered this ready-made solution from Retro Innovations, the C=key 3.0A.

Apart from modest soldering skill you will need some sense in building electronics, as the (not included) instructions need some deciphering. But if you follow them step-to-step precisely it should come out good. I guess you can also order them soldered. I perhaps wanted to avoid having the PS/2 connector positioned, but as it turns out it was a better idea to use that part anyway.

The board has provisions for both female & male 20-pin connector. I could have avoided soldering the other part in, had I given it a bit more thought.

Because there was a capacitor in the way, I could not fit the board directly on the C64. So I went for a long-ish drive cable. I once found a bunch of these from a flea market.

Bonus points for including proper holes in the board for easy attachment in your own projects. I'm not yet sure where I'll use this.

The adapter worked at the first attempt. My impressions were that this is much smoother and bug-free than that DIY board.

But it turns out this C=key adapter is not without problems either.

Although the key mapping felt great at first, I soon found the cursor keys did not work. Then I learned I need to change the keymapping style. I can enter the "menu" by pressing CTRL+ALT+BACKSPACE.

There,

1. C64 Symbolic
2. C64 Positional
3. C128 Symbolic
4. C128 Positional

(CTRL+ALT+BACKSPACE exits the menu.)

Using selection 1. (C64 Positional) the cursor keys started working and all keys are mapped according to the PC keyboard. ...according to an US keyboard, that is. Sigh! So the keys work but everything is in an alien place.

While testing the keyboard I sometimes came up with gibberish. I also managed to get the adapter locked quite easily, which often followed from pressing Return, but other keys too. Using the CTRL+ALT+BACKSPACE combo a few times the adapter recovered.

The site does say "This is still considered a project, not a complete product. I’ll try to help with issues, but it’s still a work in progress."

I did clean the adapter up and wiggled the cables a bit and got a better response out of it. Who knows, it might be my soldering and construction was a bit botched. I'll have to make sure the board and the cable do not move when pressing the keys.

These were of course the very initial responses to this adapter, and further examination should reveal how well it works in the long run. Possibly, a PS/2 to C64 keyboard adapter is a device that simply cannot be made to work 100% reliably and in a satisfying way, but this is already quite good.

Zoo 2019

Some recollections from my participation at the Commodore 64-only demoparty, Zoo, held at Akaa during 4th-6th of October. Again, not really a party report, I'm mostly talking about my own works.

Not the general theme of the weekend.

My pre-party mood was a bit pessimistic, after not catching a hotel room. Another thing I worried about a bit was not having any prods for the compos by the time I arrived. But I managed, as usual, do something on the spot.

It turned out the common accommodation at the nearby building was much better than I expected. The airbeds are cozy and the space was not jam-packed. It actually has a few pros compared to the hotel room, mainly it is very silent (the party noise won't reach there) but it's also cheap. If only I hadn't forgotten to pack the roll-up bed...

The unsuspecting Viiala neighbourhood, somewhere in Finland.

SID

SID was a general theme of the event. Grue gave an overall 'mythbusting' session about the SID and played concrete examples of playing the same songs on different SIDs. The differences were quite drastic, in some cases the wrong SID can even hide the lead instrument.

The bottom line is there is no overall 'best SID', some songs sound better on the 6581 and some better on 8580 - not even always the one the author intended! Your ears be the judge.

Flex gave a workshop on Goattracker. It's a complex piece of software, and SID is complex, so I doubt anyone could have started up Goattracker there and then and gotten finished results, but as I had at least some previous experience I could pick up one or two new things.

I mused that to be able to do SID music on C64, you have to have an understanding of many things, not just one thing:

• About SID features, behaviour and constraints
• The convention of "a SID" as a tracked format on Commodore 64
• How Goattracker (or some other editor) works

And maybe some musical knowledge too. Well, anyway, these SID presentations encouraged me to think that it does not matter so much if I don't achieve the perfect iconic SID sound, so I started tinkering on a crappy tune following some of Flex's tips.


VIC-II

Dr. TerrorZ: Light

I had a Multipaint presentation, but I found I couldn't really 'teach' anything at this point so I simply told what the program is for and showed the main features of the new version. This led me to have chit-chats with various sceners which was maybe the best outcome of the presentation.

The software is now already quite known in the scene but not everyone will adopt it. But I don't think I'm bragging if I say it is a good introductory-level software for making C64 graphics!

First time i saw the zoo from this angle.

My graphics entries were even less successful at the compos than last time.

Normally parties tend to go so that I pick a half-decent half-completed image from the archives and finish it, but this time my folder was rather empty. I also spent a lot of time getting a demo production working (see further below), time taken away from drawing.

The bitmap work was a quick experiment with drawing using wacom tablet with Multipaint.

Dr. TerrorZ: Spacesplash

I preferred the initial quick lines and was even afraid to lose them with too much detailing. So I actually like this image quite a lot (perhaps because I did not have time to grow tired of it) but it didn't go down that well in the compo.

Admittedly, a further session would have helped it a bit. (That's a damn long arm!)


CPU

I was greatly impressed with the amount of quality demos at Zoo. I recall the dry year 2013 when even a crappy PETSCII demo written in c by some idiots could win.

The Finnish Gold 'returning' with a full-size demo should/could have been a bit more grandiose. Although it was presented at the show-stealer last position, it was a bit on the short size and petered out in the end. Artline Designs demo Out of Contex delivered better overall and was the clear deserved winner. The Void Mind was still incomplete at the party but is clearly a memorable demo. PWP's Metadimension was an atmospheric generative-algorithmic work.

In the drunken tired atmosphere there was a tangible mood of having passed a turning point and a feeling of living amidst a new rise of the Finnish C64 demoscene. In a more sober hindsight, it's perhaps not all there yet... X'2020 will mark the spot.

I submitted my modest Nine Rings one-filer, based largely on re-writing Digiloi game routines. Digiloi object drawing system is naive in that it draws characters and colours separately to two buffers, and only combines them at the screen. Now I have the graphics stored in a reverse interleaved order for the drawing, and the buffer is also interleaved. So I could have 9 Digiloi-style 'sprites' on screen.

From Dr. TerrorZ: Nine Rings

The PETSCII mode is forgiving in that I can go with 1/3 framerate and it still looks kind of acceptable. The routine was in place before Friday but I did the scripting, music and some additional graphics at the partyplace.

After hitting the ring theme, my goal was to visualize the One Ring to Rule them all... poem, giving an outline to the demo script. But as time ran out I could not add more graphics and it was left more abstract. It was well enough received.


I/O

Apart from the above presentation, Kasettilamerit made an appearance, and the bid for making demoscene a part of UNESCO World Heritage was also presented here.

At the location I bought an external kernal replacement cartridge, a REX 9628 clone. Equipped with JiffyDOS and JaffyDOS and other jibba-jabba, I'm hoping it will make an interesting companion to SD2IEC or that Raspberry floppy emulator. More about these later.

Also I got a K&A paper magazine English edition with a Digiloi review :)

zooparty.org

Zoo 2019 at CSDb
..at Demozoo
..at pouët

(At the time of writing the listings were incomplete)

Bare Metal Revolution (?)

Some years ago I asked myself, "surely someone must have written emulators directly for Raspberry Pi hardware?". At that time there were a couple of promising but incomplete attempts at writing a C64 emulators for the Raspberry Pi.

Now it seems in the meantime these projects have become more mature, and I am clueless about these recent developments (as usual). Now even I can easily try two "bare metal" emulators on the Raspberry Pi.

Bare metal sounds like it ought to be a musical genre, but really it's intended to mean that the emulator does not reside on top of a conventional operating system, like having Fuse Spectrum Emulator on top of Linux.

This is not to say the emulators are coded bit by bit on the processor, but at least without a full OS I guess spurious memory, swap or disc accesses can be avoided altogether and it becomes possible to achieve very fast boot time and rock solid frame rates.

I was also attracted by the possibility of composite video output which I expected to make the experience more 'real'. More about that below.

I tried two emulators, the ZXBaremulator and the BMC64.

In both cases, the relevant files are copied on a FAT32 microSD card. The C64 needs the kernal, chargen, basic and d1541II files too.

Lines in config.txt can be used to adjust how Raspi sets up the video image. Which leads me to give you a...


Foreword & Warning:

I may have ruined my old Sony portable TV by changing the display resolutions, overscan modes and their parameters for the composite video. The TV started smelling a bit bad and the composite image begun wobbling, turned yellow with color components misaligned. Ouch.

I can't say my fiddling with these emulators is what caused the death of a 30-year old TV, could easily have been a coincidence. I wouldn't blame the emulators or the Raspberry Pi in any case.

However I did try varieties of video modes that might not have been too friendly to the TV.

Progressive scan. The camera is what makes the screen look distorted.

ZXBaremulator

First one is the ZXBaremulator, a ZX Spectrum emulator. It's not clear to me if this is based on some existing software. Just a hunch it is not Fuse, looking at which options are there and which are absent.

Boot time is near-instant. Pressing F1 brings up the file menu, Alt-K gives keyboard help. 128K and +2 are also emulated, so enjoy those AY sounds. Tapes can be loaded by selecting them on the menu then using the LOAD "" or the 128 Tape Loader. A reset+auto-load would have been nice.

Thankfully the tape (TAP/TZX) loading has been speeded up. It's not instant like on big-computer emulators, but a lot better than no turbo at all.

With composite, Raspberry Pi outputs something like 480-pixel height screen through interlacing. This is somewhat helped by doubling the lines, so the Spectrum 256 x 192 screen area is really a 384 pixels tall, add borders to that and the vertical space is filled.

However doubling the lines doesn't quite get rid of the 'flickering' quality of the graphics, which becomes more obvious when white and black horizontal lines are repeated.

On my Pi2B+ and Pi3B+, the composite can output progressive scan, so I could get remove the flickering by changing a line in the config:

Instead of sdtv_mode=2

I can use

sdtv_mode=18    # progressive PAL

This is not without problems as the result can be blurry and/or has interference patterns from scaling.

Using disable_overscan removed the interference type pattern but the blurry scaled result is not perfect either. The screen is solid and this at least proves to me the interference is not an inavoidable TV artefact but a result of the raspi scaling. Looking at checkerboard and horizontal line dithering patterns, these become overtly mixed, as if the dither really formed a new color.

When playing games, the slight blurriness does not matter as much as the flickering did, but fonts can look a bit garish and the end result is not especially authentic.

+128K modes and AY sounds too
+SD directory structure supported
+Helpful key overlay & menu screen

-Can't load snapshots (z80, sna)
-No support for 9-pin joysticks

Watching that Gianna Sisters smooth scrolling

BMC64

Emulating Commodore 64 is no small feat, and here the results are also admirable. The frame rate is smooth, as can be proven by looking at the Great Gian(n)a Sisters intro screen for minutes and minutes. The emulation is based on Vice, so it ought to be pretty good.

The overlay menu is nice but apparently there are no key shortcuts?

The C64 palette is not as harsh as the ZX, so the flickering on composite is not as immediately apparent. However, it's there and using black/white line patterns shows it.

Using sdtv_mode=18 in the config.txt again kills the flickering, but no amount of fiddling with the disable_overscan and overscan values can remove the interference pattern like could be done with the ZXBaremulator.

Thinking of a real case, the large texts made from thin horizontal lines in Wizard of Wor become affected by the scaling.

I'm unsure if this is a result of the emulator author making a choice or not. The supposedly 'real' aspect ratio is not in my opinion as important as getting a resolution that scales well.

So the results are not as promising as with the Spectrum in this area. So here I'd say endure the default 480i flickering if you want to use the composite. The interference pattern is there too but it's maybe less conspicuous.

Scaling artefacts.

The Raspberry Pi GPIO pins can be connected to real Atari/Kempston 9-pin joysticks. This was easy to do without soldering, using a suitable connector and jumper cables. Just remember the GPIO numbers are not the pin numbers, check the GPIO-numbered pins within the connector of the particular make of Pi. They ought to be similar though.

Using a 9-pin joystick such as TAC-2, it became easier to judge whether there is a lag or not in the emulation. Using the composite connector with a CRT and the GPIO-connected TAC-2 joystick, I felt the lag was negligible or non-existent, I really couldn't complain at all.

Using the HDMI television, I felt the presence of a noticeable lag in games with very crisp controls, such as Buck Rogers. Whether the particular TV is to blame (most likely) or if the HDMI connection always produces some delay, I can't say. Still I'd think even this lag is acceptable for many games.

Maybe more about this later...

The disk loading is real time, so get used to waiting. Ok, it's possible to use an Epyx Fastload cart image to get a faster loading speed (for me a 25 second waiting time was reduced to 11) but that's an extra stage too.

An Action Replay VI cart image did not work as I would have hoped. Carts obviously run instantly but I only tried some 8K and 16K cart images for now. (It's not an accident the test games mentioned here are cart images, they load instantly.)


+Nice overlaid menus
+Selection of palettes
+Support of 9-pin joysticks via GPIO

-SID emulation could be better? No 6581/8580 selection?
-No SD directory structure support
-No PRG loading support?

Edit 19.12.2020: I had a second look at a later version of BMC64 and it's become a lot better!


But why?

These emulators are a fantastic job overall. But do *I* need something that lies somewhere in-between real hardware and an emulator running inside normal OS, especially as I have both options already?

Well, it's another interesting project to mess with, and it would be fun to build a case for a new ZX or C64 as the Pi is so tiny. It might be handy to carry and show 8-bit games and demos to people without having to lug all that old hardware, yet having something more than just an emulator on a laptop.

The composite image modes turned out to be a bit of a mixed bag, so perhaps I'd go with HDMI here after all.

Again, I have to warn about the dangers of fiddling with the video modes too much on an silly old TV. I'm not sure if framebuffer_width affects the composite image at all but I had that included on my BMC config when I fried my TV.

IRQhack64 serial transfer

Previously I had only used my IRQHack64 to load files from the SD card. I now wanted to turn to the transfer functions, enabled by the 6 pins sticking out of the cartridge.

The transfer is something that potentially brings the cart to a whole new level. With this port it's possible to send a file over the serial and the C64 runs it automatically.

Just to make this clear, IRQHack64 is not a substitute for a C64 serial port, it doesn't connect a modem, internet or MIDI. Your PC communicates with the Arduino inside the cart, and the Arduino+EPROM work their magic with the C64.

But as the Arduino inside the cart is not limited by C64 hardware speeds, the files move at a nice 57600 rate, and they move over to C64 even faster.

I have postponed testing his because firstly I knew it would probably be a chore, as the IRQHack64 software is not very clearly documented. All the sources have been made available, but there's no overall comprehensive guide for what the cart is supposed to do and how.

Also, the Arduino code, the EPROM code and the irqhack64.prg need to have compatible versions or the cartridge likely won't work.

Connecting the PC to the cart using an FTDI board

More importantly, I needed the FTDI board, which makes it possible to communicate with the Arduino Pro Mini inside through serial, while the cart is on-line.


Converting the IRQHackSend

I used the IRQHack64Turbo project as a starting point for examining what the software is supposed to do. At least after compiling the Arduino source I get a working cartridge that plays nice with the current EPROM and the menu program.

The IRQHackSend in the Tools folder is a separate software for sending files from the PC end. It was simple enough to adapt to Processing.

The program opens a 57600 connection to the Arduino inside the IRQHack64, sends the "1" character which tells the Arduino at that end to start receiving. After this the Processing source sends the file length bytes, two header bytes and data bytes just as the original source does, with suitable delays here and there.

Immediately I got my software to talk with the cart, as the IRQHack transmits the menu and other responses over the serial. Using single character commands over the connection, the C64 can be reset with or without the cartridge, the cart menu software can be triggered remotely from the serial and so on. This remote control-reset was a nice bonus. So far so good.

However, using the file transfer mode was not a success, as the resulting bytes were often garbage. For a while I thought the serial transfer was to blame, and I spent hours messing around with the Arduino source.


The Obvious Solution

Umm, it turns out there is a speed toggle that apparently affects how the memory write works. The cart might have even have worked out of the box (not that it came with a box), but I could have changed that accidentally. The serial was not to blame at all, at least with these small file sizes.

The source seems to indicate it's possible to change the speed through the time-based button press interface using more than 5 seconds pressing. The source is also where I found this feature even exists.

I changed the Arduino source so I could send the speed toggle through a serial command, so I could be more sure that it has been received. After that, the serial-transferred files & memory writes started working!

Below is a Processing source for sending a file over to the IRQHack cartridge, using the FTDI board as a serial port.


import processing.serial.*;

Serial myPort;

void setup()
{
  int port = -1;
  for(int i=0;i<Serial.list().length;i++){
    String stn = Serial.list()[i];
    println (i+":"+stn);
    if(stn.indexOf("USB0")>=0)port=i; 
  }
  if(port>=0){
    String portName = Serial.list()[port];
    println (portName);
    myPort = new Serial(this, portName, 57600);}
  else{
    println("NO USB found");
  }
}

void waiter(int amount){
  for(int i = 0;i<amount/10;i++){
    if (myPort.available() > 0)print (char(myPort.read()));      
    delay(10);
  }
}

void keyPressed(){
   int k=key;
   if(k=='1')send_file("myfile.prg"); // send this file
   if(k=='r')myPort.write('3'); // reset c64
   if(k=='c')myPort.write('4'); // reset c64 nocart
   if(k=='d')myPort.write('2'); // enter dir menu remotely
}

void send_file(String fname)
{ 
  myPort.write('1'); // "type" the Receive prog command at Irqhack's menu via serial

  byte prgdata[] = loadBytes(fname);
  
  waiter(250); // 250*10 millis, original delay(2500) millis
  
  byte low = (byte)(prgdata.length % 256);
  byte high = (byte)(prgdata.length / 256);
  
  myPort.write((low)); // write length to receiving end  
  myPort.write((high));
  
  for(int i=0;i<2;i++){ // write prg header
    myPort.write(char(prgdata[i]));
    if((i%32) == 0)delay(10);
  }
  for(int i=2;i<prgdata.length;i++){ // write actual data
    myPort.write(char(prgdata[i]));
    if((i%32) == 0)delay(10);
  }
  // we're done here
  waiter(1000);
}

void draw()
{  
  if (myPort.available() > 0) print (char(myPort.read()));         
}

This is a minimal Processing sketch. I've only tried it on Linux. It scans the serial list for the presence of the string USB0, this may vary depending on your computer and serial adapter/FTDI hardware.

The program reads all incoming characters and prints them on the console. Pressing '1' will send a file myfile.prg over the serial, if it exists. R and C keys resets the C64 and D makes the IRQhack enter the file selector menu. If there's no Arduino source change, there's no point sending a 'speed toggle' command.

Now that I already made the work on Processing, I modded the PETSCII editor to save & upload the exported prg through a keypress, so I can do PETSCII graphics on PC screen and experiment with results on the C64 screen.

After reducing the pre-delay in my sending routine to 250ms, it takes about a second to transmit the 2K PETSCII prg, so I can do it as often as I like. This was initially at 2000ms. It may be that different C64 units need a slightly different delay.

I've worked on it a bit more for my own setup.

Using the same approach on my Multipaint, it obviously works but as the export file sizes are 10K it already takes closer to 4 seconds to see the results on the C64 screen. But that's not bad at all. I could also revise the Multipaint export so it would send a smaller file in case less than full screen area has is in use. Sending packed files isn't that useful as the C64 will take some time extracting them.

This is still a great improvement over the SD card switch-a-roo between PC and C64. This feels like a real professional Commodore 64 graphics workstation!


Not so fast

I came across problems when transferring some small scene demo and game programs that would normally run from the SD card. Although size is not the only cause, it seems larger files (20K+) are more likely to fail.

I have to stress there is no randomness here, trying to send the same file repeatedly does not help, nor do the small straightforward files really ever fail to send.

*

To extend my review of IRQHack64, I'd now say the serial transfer/remote features are a very nice addition to a developer's toolbox, but it doesn't add much value to a casual user or game player.

For the above purposes, sending simple & short files repeatedly, the cartridge transfer functions still performs fine. For longer files and demo/game collecting it is better to move them on the SD card anyway, from where they can be run more reliably.

The cart receives a file and run it, although it would be in some situations more useful to send memory areas to C64 without resetting or running any code, for example overwriting portions of the graphics memory. But, without changing the EPROM code this situation probably can't be changed.

PS/2 keyboard on the C64

(Or, the Pizza Box C64 part III)

After building a desktop case for the C64, I wanted an external keyboard.

Browsing the web I get the impression that people want to convert their existing C64 keyboard to work on a PC rather than the other way round, but still I was sure I had seen a PS/2 adapter for C64. And yes, there is the C=key Keyboard Interface, but it's quite expensive and not always available.

Then I came across Robert VanHazinga's solution at GitHub, which uses Arduino Uno/Due, MT8816 chip and a minimal amount of parts. Although it seemed confusing at first, after getting to know the chip a bit it is really quite clearly documented and can be compiled easily.


MT8816

As far as I understand it's not really possible or healthy to connect an Arduino directly to the keyboard header pins (the CIA chip in fact). An intermediary chip is recommended.

The MT8816 switch array chip comes in handy, as it can specifically produce a connection matrix (X0-15) out of X-Y coordinates (AX0-AX3 and AY0-AY2). The output is built through setting connections between the "coordinates" and setting the matrix using a combination of DATA and SWITCH. RESET clears the whole array.


Breadboarding

First I built everything on a breadboard at one go but it failed to produce other than random characters on screen and no visible reaction from the keyboard. This was still somewhat encouraging.

I slept over it, had a deep breath and put the C64 aside. I connected the PS/2 keyboard alone to the Arduino and powered it from the PC USB. I saw that on power-up the keyboard actually flashed its LEDs, something that had not happened before. So perhaps the problem had been some kind of oversight with the cables I guess.

I added a routine for blinking the internal LED to see if it receives the PS/2 keys, and sure it did. Sadly I had to remove this internal blinker as it shares the PIN13 which is needed by the software.

Then I rebuilt the setup on that and it worked!

It became quickly apparent not everything was perfect. Testing the keys, I saw that the 1st keypress after any reset always somehow fails. Left and up cursor are simulated and don't work that well with key repeat. Some keys such as pause/brk and prtscr/sysrq messed things up, and also result in a freeze.

Generally,  fast typing with shift, such as typing the " can result in a keyboard freeze. Actually, if I press shift, press the key to get the ", and if the shift is released before the other key, it freezes.

In this implementation F12/reset clears the freeze, which is a relief.

I also noted that with Final Cartridge III, the bypassing of the GUI by pressing run/stop while booting won't work - I suppose the Arduino software and/or the keyboard can't be yet online at that point.

On the positive side, typing with normal keys works and there were no random hiccups or system crashes. I started to warm to the idea that this could work well enough and most of the problems might be software-based.


Building the board

Satisfied at this, for the next stage I soldered the connections on a prototyping board, with a kind of Arduino "shield". The main connection between the C64 motherboard is with a hard drive ribbon cable, which has 20 pins wide connectors. With some more thought, the board could have been planted on top of the keyboard header but I felt more comfortable with the ribbon.

I thought about having the Arduino USB connector accessible from outside, but after aligning the chip, keyboard header and the Arduino on the board, I couldn't get it to where I wanted it so I gave up the idea for now.

Some day I will have some of that glow visible outside.

Soldering the headers and sockets was easy, but making about 50 connections with wire was boring. The composition was a bit too tight after all, which made the work more stressful. The learning from here was that when making a board by hand, I should make generous space for easier soldering rather than try to optimize prematurely.

Even then the board was not compact enough to fit inside the corner compartment of my case, but the middle suits just as well.

The first boot with the soldered board was a disappointment, but after carefully cleaning the spaces between connections and checking the cables I started to get characters out again.


Case fitting and cleaning up

There still remained the task of attaching the PS/2 connector to the case. This was done with a round screw-in PS/2 connector shown below.

I attached it to the right side, near the joystick ports. Behind the computer would have been perhaps more appropriate, but there's very little space there and I didn't want to pull any more cables across the motherboard.

Just about ok for the 3mm thickness

Inside the box, I also needed to cut the center wall a bit to make a passage for the ribbon cable.

For now I did not attach the keyboard adapter board, as I may still need to change it a bit.

For once, a part that behaved nicely.

More to do:

-Check if the software could be improved a bit and fix the keymap to suit my needs
-Paint the case, put a logo on it or something

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