Pages

Thursday, 17 January 2019

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.

Thursday, 3 January 2019

2018

As last year, I try to recap the year.

Firstly, what I said in the 2017 post, the idea of platform-specific pages for the blog has not proceeded, although I've updated the existing Sinclair QL one. I'll have to look into it some more.

I have avoided buying more old computer hardware, although I did buy that atrocious hand held console and a crappy flea market NES-clone. And just at the end of 2018, a C128D motherboard. Oh well.

On with the show!


Releases, Coding, Events

At the end of 2017 I was quite enthusiastic about Sinclair QL, but it turned out I did not spend that much time with it after the beginning of 2018. Even the work on the still unreleased QLDD software was mostly done in late 2017.

Commodore 64 has kept its position as my retro favorite, and the building of a new desktop case for the computer has occupied much of my hobby-time (and this blog). I recently got my IRQhack64 transfer working and a more in-depth blog post is already in the works.

Multipaint was revised into a 2018 version, and a nice version it is. I'm beginning to see the need for better file handling (e.g. recent/last file, autosaves, overwrite warnings) and possible GUI updates.

Panasonic JR-200 returned in a more virtual form, with starting the work on an emulator. I hope this eventually results in something new for the platform.
As usual, I also produced some pixel/text graphics. One was sent to a disk cover competition, the first time I made a 5'25" disk cover. This type of scene output was quite unfamiliar to me, I've probably never seen demoscene disk covers before the 2010s.

The demogroup Desire asked me to make a picture for their X-party demo called C 64, Hear 64, and make it I did!


I didn't do that much graphics in 2018, it seems. But after Christmas, I released a new Commodore 64/plus4 game, Digiloi, following the footsteps of Fort Django. Another PETSCII showcase, it turned out much more popular than I thought it would be.

It also made the blog post about the game easily the most read entry in 2018 and one of the most read altogether.


I'm the first to say there's much more potential in PETSCII games than what I was able to put together here, as even I could see in hindsight it might be coded better in parts. Even as it is, more stuff could be moved on-screen, but the game was getting a bit crowded.

Also, the plus/4 conversion proved to me finally that this computer is something to explore a bit further.


Games, books, films

From the beginning of the year I have put more attention to Chess, playing puzzles and computer matches at Lichess.org, acquiring sets and reading literature. I even went to a beginners' tournament.

But I'm starting to waver a bit. The amount of time it would take to improve my skills might be disturbingly high. So far I've not seen reason to stop altogether. I'll blog about my experiences at some point.


During summer I played some Atari 2600, and recently I've enjoyed old Commodore 64 games such as Blue Max, Rambo and Raid Over Moscow, also taking mental notes about what makes these games click.

Of more modern games I played Tomb Raider 2013 version, as it worked quite nicely on my Linux. I also had a peep at Life is Strange, but it didn't catch my interest. At the very end of the year I put some effort to try to solve Zak McKracken and the Alien Mindbenders, but it's still going on. I still play Larn every now and then.

On the book front, I read a bunch of sci-fi books, with emphasis on bestsellers and famous books I might have missed earlier. Turns out there is quite a lot. Some of this I also documented in the blog, noting how many plots and ideas in these books have found their ways into various games.


Westworld was the most important TV series. I expected more nods to western cliches & classics, but the concept is less about the west and more about the responsibility towards the imaginary worlds we create. The parallels and connections to video game culture are obvious.

I liked the season 2 less, it felt more of a mixed bag and less purposeful than the first season.

W was an enjoyable Korean "paranormal romance" (genre made popular by Twilight, I guess) TV series which I learn is a quite common there. It's from 2016 but now shown on Finnish net TV. A comic book artist discovers a doorway into the comic world, bit like in that A-Ha video. The daughter of the artist gets involved with the tragic yet resourceful hero of the series and the indefinite murderer.

Take ... on ... me ..
The new Doctor Who with Jodie Whittaker was enjoyable TV somewhat in the same way the 1st new Who season (Eccleston) was, except with higher production. What I mean the writers have given up complex overarching plots and mysteries and concentrated on the one-off episodes, with less metaphysics. The format and storytelling was more straightforward.


This was clearly the most brutal reboot of the series in the 2000s. There was something of a post-Brexit and post-Trump vibe with the season. Instead of pushing the proud Britishness every now and then it tried to be a bit more considerate and inclusive in more ways than just adding a minority companion.

After the New Year's Eve episode I am even more convinced that the writers have decided to 'stretch' the narrative. What would have taken a few episodes at best for each new doctor, now takes a whole season. As the doc returns in 2020, they have plenty of time to think of a follow-up.

Solo: A Star Wars Story. To me it was a pleasant small surprise, even if the film does not add much to the broader 'Wars lore. Well, Lucas was originally influenced by early movie serials, and in Star Wars we now have them. Is that a good thing?

As Solo was the character that most embodied the "space cowboy" side of Star Wars, it makes sense to make his film a western. The space scenes on the other hand were a bit messy. What with the candy-colored Maelstrom and the Maw, it's like there never was a good clean space shot, the kind that made the original films so stylish.



On with 2019...!