Bringing the C64 online… part II

Friday evening 20h30, finally getting ready to hook my Commodore on the net and start sending “tweets” from that classic of the 80s.
I connect the C64TPC to the serial port of a PC, connect it to the serial port of the SX-64, jam in the Retro Replay cartridge with the RR-Net card attached to it in the cartridge slot and finally hook the card with a UTP-cable in the back of my router: it’s official, I’m ready to rock!

With the downloaded D64-image of Breadbox64 attached to a virtual drive 9, I type in ‘LOAD”*”,9,1 and wait for the program to load.  A “bleep” from the PC signals there’s something wrong… ah, I spot it immediately, it’s the virtual drive that got disconnected since it can’t cope with the turboloader from the Retro Replay.  No problem here, the turboloader is quickly disabled and I try again.  Now loading goes smoothly and actually quite fast (as the C64TPC has its own sort of fastloader), so the 131 block take less than 30 seconds.
This is it… I type in “RUN” and… nothing… just a READY-prompt.

Is maybe the D64-image faulty?  I test it with the CCS64 emulator and here the program boots up nicely.  I do spot that once loaded and running, the Breadbox64 application is accessing the drive on the emulator (the files IP.CFG and a couple of Contiki ETH-files).
Could it be that the program is somehow configured to load these files from drive 8, regardless of the fact that it’s loaded from another drive?

Let’s try it again I say to myself, and I load up the program again and indeed, I so see the application trying to access the drive of the SX-64.  This should be a breeze to fix, as I just need to copy the IP.CFG-file  and the ETH-files from the virtual drive 9 to the SX-64 drive.  I load the files one by one (they’re marked as PRG-formats so this should theoretically be possible) and after each load save them to drive 8, the drive of the SX.
Loading the application again I see it’s now successfully accessing the drive but still, I am greeted with the READY-prompt, and not with the Breadbox64 screen… what is wrong?
Maybe I also need to load the application itself from the SX-drive, so after loading and saving it to disk, I go through the process again, but now loading everything from my SX-64 directly.  Unfortunately, the same result.

To exclude any issues with the SX-64, I try the same process from a C64C and a classic C64 breadbox with a 1541-drive attached.  Both had the same result as the SX-64.

I decide to check if Contiki with the built-in webbrowser and webserver run (I downloaded the D64-images from  I realize that I also would like to run these disks directly from the SX-64, as otherwise I’ll probably run into the same issues I had with the diskaccess and the virtual drive on the C64TPC, so I first load up “Fast Hack’Em” to help me with the copying of the diskimage to a real disk (some files on the Contiki image are of the type “USR”, and you cannot simply load and save these like “PRG” types).
I got a bit of a cold shower as none of the tools worked, not even tried and tested applications such as “Turbo Nibbler”.  All of them, as soon as I stared the disk copy routines, made the C64TPC virtual drives disconnect.  Browsing some of the forums on the web, I found out that disk copy with the C64TPC is quite impossible… a bit of a setback!

The upside of this however, was that I noticed that both the CFG-files and ETH-files on the Contiki image were of the type “USR”, and the ones on the Breadbox64 image were “PRG”.  OK, I know the application ran on the emulator, but maybe the emulator is less picky when it comes to these file types in comparison with the 1541.
With the D64 Editor, I decided to change the file types of the CFG- and ETH-files to “USR”, commit the changes to the image and load the image again on the C64TPC.  Hang on there, I still need to copy these files to the actual disk on the SX-64 but wasn’t this impossible with the C64TPC (remember, you cannot load and save these files and disk copy tools don’t work…)


Maybe, just maybe, I need to set the IP.CFG file to the proper network address etc. before the application will load (I had my doubts, as it ran on the emulater), but it was already after midnight and I was getting tired.  So, I made a config-file, renamed it to IP.CFG and with the D64 Editor added it to the Breadbox64 image… again, trying all of the above, it didn’t run…
I decide to send a quick mail to Johan Van de Brande (the creator of the Breadbox64 application) to see if he’s come across this issue before and decide to call it a day (or night rather).

Saturday morning 11h00, received a reply from Johan.  He was not familiar with this issue but pointed out that Breadbox64 is pending a major update as changed its authentication mechanism from basic access authentication to OAuth.  Aarrrgh!

Nevertheless, I first need to get the application running before I can even try to log-on to, so of I go for another attempt at some other disk copy tools to get the image of the D64-file transferred to disk, as my intuition tells me it has something to do with the PRG vs. USR file type setting.
A couple of hours later, and a few utilities later, I’m still left with the same result… it doesn’t work… I close up for the day as we’re off to the city and I’m out of ideas.

Sunday afternoon, 16h00, have an idea!  If the disk copy tools fail to copy the image, perhaps I can copy the files one by one by using the GEOS Operating System!  I download an image, load it into a virtual drive with the C64TPC connected to the serial port of the SX-64, load it, run it.. and… nooooooooooooo it’s trying to access files on the drive as well and that’s not the strong point of the C64TPC… so in order to be able to copy the files, I first need to be able to disk copy the GEOS D64-image on a disk, but that’s just what I was trying to avoid… it seems I’m stuck between a rock and a hard place on this one…

The only thing I can think of to get the Breadbox64 files from PC (and GEOS or whatever image for that matter) transferred on a real disk (including those USR files) is by using a serial/parallel cable like the XA1541 and an application like Star Commander… I went of to buy one of those cables on eBay for € 15,00… so hopefully the cable will be here before next weekend so we can continue the big experiment!

Share This Post


One Response to Bringing the C64 online… part II

  1. Pingback: Bringing the C64 online… part III | A Commodore Geek's Blog

Leave a Reply

Your email address will not be published. Required fields are marked *