C64 client: login, scrolling, chars and sprites

July 8, 2025

First I had to fix some bugs with the main protocol, and extend it a little bit.

But finally we have our first command: the LOGIN!

This is how the login process looks like from the server side:

The main protocol requires for the client to send an initial handshake command, what is exactly 4 bytes, as "8BIT". (56, 66, 73, 84)

Server replies with also 4 bytes: "RULZ" (82, 85, 76, 90) (Why not? I'm funny as hell 😉)

From now, the client and server also knows the connection is estabilished, and seems reliable. Now the client can send its commands.

First it sends the "L" command (byte 76), following by a 6 digit One Time Password, and the username. If these can be found in the database. server sends back a status code. In our case it's bye 64, and it indicates everything is fine. (It's the default "OK" status code, but more about it in a later post)

There are other commands under implementation, like the "C" (client) command, to notify the server about the clients capabilities. For eg: client baud rate, PETSCII/ASCII, UPPER/lowercase capable, color capable, and optionally a client name and version. I'm thinking about a computer indicator. It should be fun for statistical purposes to see who is connecting from a C64 or an Apple2, or a Speccy :D

In the past week I was using my highly professional artistic skills to make a tileset for the game. First I wanted to use 16x16 pixel tiles, but with this, I could use only 64 different ones... It doesn't seems to much.

Because big dreams require a big number of tiles!! 😎

So I voted for the 8x8 pixel single character sized one, and started to draw some (not so) cool grafix. 

My thoughts were fine, because I already have 87(!!) tiles now. But MAN, I want a detailed world 😁

After that, I could focus on the most important features: scrolling. And ofc raster IRQs...

It was much more easier than I thought at first. I've never did that before, and I'm still (re)learning to code on the C64. TRSE is a really great tool, but also it has its learning curve. I have glitches and flickering here and there, but it's working almost flawlessly. Not as bad as I expected.

Unfortunately on the low framerate GIF screencapture it cant be seen, but trust me, the scrolling is very fine. Up/down scrolling causes some weird glitches at the raster split, I have to find the reason behind it. Currently I'm only using 0-7 pixel scrolls, just to test the hardware scrolling with the IRQ.

Left/right - OK ✅

Up/down - glitches 😄

And maybe you've already found the little guy at the center. He will be our hero, represented as a hardware sprite. 😄

Oh, and why I need this fancy IRQ screen split thingy? Because I want some menu in the game, text, buttons, and similar. And I will not have any text characters in the main tileset, because they need a lot of space. 

Just the main alphanumerical characters and the basic symbols eat up 64 chars. And also it will be cool to have lowercase characters also. It will cost +26 extra tiles. ( = 90 of the total 256 = 35% )

So if I split the screen at somewhere and change to a regular character set, I will be able to print out normal text. Now it's happenin just above at the last 4 regular text lines. (~ rasterline 218) And at the top of the screen (at rasterline 0) I already switch back to the "graphical" charset to display the world. This magic is done in every frame, and when it's done perfectly, it should not flicker 😛

I also realized too late that I want the player to explore the world always in fullscreen mode, and only switch to this text menu mode only at interactions. (Use something, chop tree, etc) While interacting, the player will never move, so maybe I really don't need this difficult splitscreen scrolling method at all 🤣

Why fullscreen mode exploration? Because big dreams need big screen size 😉

That's all for today. Have fun 🖖