• Hello everyone,

    We're happy to announce that our forum is back online! We needed to take some time off to discuss and decide on how to handle sensitive topics in our community.

    The team has posted an in-depth comment regarding a recent incident and our stance on politics and sexuality in our forum. We also added a dedicated paragraph about this in the forum guidelines. This is part of our commitment to maintain a welcoming and inclusive environment for all our users. Your understanding and continued support in building a creative and respectful community are highly appreciated.

    Thank you, the CX Dev-Team

TheC64 Commodore 64 replica

Just a quick update regarding the input lag. It seems it was caused by the enhanced screen mode of my TV. In this mode the TV suppose to enhance the screen quality when you watch HD content. But in this case it is counter productive and seems to caused the input lag. When I switch back to standard and 4:3 aspect ratio, the 8 bit graphics actually looks better and things are more smooth, no input lag.

So regarding the joy is horrible, that was also an incorrect statement. It is not horrible. It is fine.
I have also tried some 3rd party games loaded from USB, no problem.

in Basic I have also tried some file operations, created a disk image in VICE, put it on to a USB and I did write files on to disk, read file from it, updated the file on the disk.

So far everything is fine.
 
So I am currently reading the official C64 user manual and I follow along and see how much of it is actually applicable to theC64.

I find it interesting the user manual call coding in Basic the "calculator mode" which makes total sense since I imagine most people did not write programs but performed advanced calculations and was managing some sort of business data. I have never thought of Basic as an advanced calculator but technically it is a calculator.

So far programming in Basic works perfectly as expected and the keyboard is really awesome. Despite the fact it may look very limited compared to modern IDEs, since the keyboard was designed to program in Basic, I find it very convenient to be honest. Coding experience is really great so far and I love the keyboard.

Now few problems with theC64:
Tried loading some games from Basic instead of the Carousel game launcher and unfortunately I did not had much success.
1. I was able to use Basic to launch games from disk images, but often the joystick does not work this way. if I launch the game from Carousel it is not a problem, the joy always works but not always if I launch it from Basic.
2. I was unable to launch any games from tape images using Basic because it is not possible to insert a tape image in the media access menu. It seems it got broken with the latest firmware and they didn't care to fix it since. I can launch tape images from Carousel the game launcher menu but not from Basic.
3. Even if I launch tape images from Carousel, the joy sometime does not work.
4. Multi disk images also not supported, it is not possible to swap disks.
5. Some of the 3rd party games I tried from USB also runs super fast it is unplayable. Maybe because they are the North American version.

Of course there are some work arounds, with the joy problem I can include _j1_j2 in the name of the image files and it should map the joy.
In some cases however it is not enough and we need to also specify in a configuration file which buttons are mapped.
It is possible to work around the disk swap by saving the disk state with disk1, insert disk2 and load the saved state with disk1 while disk2 is inserted, but it does not work with all games and we can save only 4 states, some games comes with 7 disks.

Anyway, this is all for now. Playing 3rd party games from USB on theC64 is a bit of a mixed bag. But programming in Basic is just awesome.
Once I finished with the user manual, next I'll look in to graphics and game programming, those books has arrived too.
 
I can't recall the manual mentioning a 'Calculator mode.' In reality, I don't think people actually used it for that purpose.

It felt difficult and unfamiliar to use computers for math so most people resorted to using calculators for everything, or, proper spreadsheets where used. On microcomputers we used the prompt for two things only; either we pressed run/stop LOAD to play games, or we programmed BASIC and it was quite the experience!

I originally owned the C64C, which had a newer manual, but it's supposed to be very similar to the original one. I will gladly help if you have ANY C64 questions whatsoever. Its an amazing machine. My personal favorites from that book were the bouncing ball and guessing the animal.

I think the new manual (C64C from 1986/1987) had a balloon sprite demo that I wrote in sooo many times, and programming the SID chip was so amazing. I think you will have a lot of fun with it.
 
Last edited:
I can't recall the manual mentioning a 'Calculator mode.' In reality, I don't think people actually used it for that purpose.

In Chapter 4 it is calling it immediate or calculator mode when you type in commands without line number and it is executed immediately. This manual was printed in 1984.

calculator mode.jpg


I can kind of imagine it some people may stored data on disk and used Basic to manage it. It is not that difficult, but certainly if there was also spreadsheet applications people used them. I know that my friends and I used it for nothing but to play games. It is honestly battle me why I never thought of programming at the time. But even if I did, I had access only once a week if I was lucky.

I originally owned the C64C, which had a newer manual, but it's supposed to be very similar to the original one. I will gladly help if you have ANY C64 questions whatsoever. Its an amazing machine. My personal favorites from that book were the bouncing ball and guessing the animal.

I am currently at the bouncing ball program, it is indeed a nice little program to introduce new users to programming. I am to be honest impressed by the manual. Really good book.
Thank you for the offer, I'll let you know if I have any questions about Basic.
 
I am to be honest impressed by the manual.
You should take a look at the Acorn BBC A/B, Acorn Master 128, the Sinclair ZX81, ZX Spectrum 16/48K, Sinclair ZX Spectrum +2/3 and the Sinclair QL manuals. They make the ones for the Commodore 64 and VIC-20 look cheap.
 
In Chapter 4 it is calling it immediate or calculator mode when you type in commands without line number and it is executed immediately. This manual was printed in 1984.

View attachment 1560

I can kind of imagine it some people may stored data on disk and used Basic to manage it. It is not that difficult, but certainly if there was also spreadsheet applications people used them. I know that my friends and I used it for nothing but to play games. It is honestly battle me why I never thought of programming at the time. But even if I did, I had access only once a week if I was lucky.

I think it's the same manual, but evne though I've read that page 100 times but somehow missed the "calculator" part.

Btw, If you want some interesting YT-videos about the machine and BASIC, I would reccomend this guy. He has loades of prgramming-related videos, along with other C64-related things.

 
They make the ones for the Commodore 64 and VIC-20 look cheap.
I can imagine because of the popularity and many 3rd party books they figured lot of people write books about it anyway so why bother. Guess this is how the world works.

With today computers we get no handbook at all. Now that I think about it, I never received any manual with any Windows computer I have purchased. They could include a book on how to write programs in C# or Visual Basic, that would be nostalgic a Basic handbook comes with all Windows computers.
My Mac guess we could say it did come with a free Swift programming manual but you have to download it, it is not included.

The last time I've seen any manual included was with the Haiku operating system. That OS comes with a PDF on how to use the OS and how to write programs for it in Yab (its own Basic) or C++, but again it is not popular, nobody write books about it and so the developers kind of forced to include one with the OS.
Guess we could say the Haiku manual is way better than the Windows and Mac manual since the Windows and Mac has none :D

If you want some interesting YT-videos about the machine and BASIC, I would reccomend this guy. He has loades of prgramming-related videos, along with other C64-related things.
Thanks. I like the way the guy explain how to write the program in Basic. I'll keep an eye on that channel.
 
Back then manuals were amazingly detailed and I kind of miss that bit. An that was the only way to get any information except for the ocassional magzine (mostly English and German ones). Okay I found one local (Swedish) magazine and actually it was quiet good but it was quickly sold out every single time.

I rememeber how I bought German magzines despite of the fact that I know not a single word of German. It was a real treat to find good literature. It didn't really matteer what language it was written in, if it had BASIC.. you would pick it up, absolutely.

Today, whenever you get some "manuals" it will say stuff like.. "Do not wash this T-shirt with the baby inside", the End.
 
but it was quickly sold out every single time.
Didn't they offer subscriptions and back issues? Or get the local news agent to set one up?
That's what I used to do.
 
Today, whenever you get some "manuals" it will say stuff like.. "Do not wash this T-shirt with the baby inside", the End.
I like the ones on packets of peanuts.... "Warning! May contain nuts"
 
Didn't they offer subscriptions and back issues? Or get the local news agent to set one up?
That's what I used to do.
You're right you coudl subscribe but we where so poor so I could only buy them sporadically. Later my uncle subscribed to them when he got his Amiga500 so that was an amazing resource. Not even the libraries had that much. Internet would have been an amazing thing to have in the 80's, but on the other hand, today an disadvantage in that everything is so complex and change all the time. You're always abit lost, and to rub it in.. no manuals :LOL:

That's probalby why so many people love these older machines. They don't have PS5 graphics but they do have the qualities that counts. You know what you get, and it's loads of fun!
 
Hi guys!

So I am getting in to how to work with graphics, create sprites and I have some weirdness happening.

One of them is that, in the bouncing ball example when we move the ball right to left, we do it this way (I’m using [] as the ball):

PRINT " (CRSR LEFT)(CRSR LEFT)[](CRSR LEFT)";

It works, I have no problem with this code.
However, I was thinking if I come back to this code later, I am going to have a hard time to recognise the characters and instead I want to use the character code and this is what I did:

PRINT " ";CHR$(157);CHR$(157);"[]";CHR$(157);

In my head it is the same thing as " (CRSR LEFT)(CRSR LEFT)[](CRSR LEFT)"; but if I run it, for some reason the ball is blinking.
My guess would be the space " " override the ball character sometime, but I have no idea why.

Would anyone have any idea what could possibly cause the blinking?
What is the difference between

PRINT " (CRSR LEFT)(CRSR LEFT)[](CRSR LEFT)"; and
PRINT " ";CHR$(157);CHR$(157);"[]";CHR$(157);?

Thank you.
 
I remember that first version of the ball that comes just before the POKE. I did not quiet like it back then bc it felt
less elegant. Of course today I can see how these codes can be a quiet elegant solution for some things.

There's no C64 machine or emulator to test on right now but I would guess that it's about
atomicity; things are not happening all at once. You can do quick things such as simple sprite multiplixing with BASIC but it can also be VERY slow. This might be an example of that.

I believe that what you have is the same as :
Code:
PRINT " ";
PRINT CHR$(157);
PRINT CHR$(157);
PRINT "[]";
PRINT CHR$(157);

The binking might be because of the slow action of multiple PRINTS. I can't come up with any other reason, I'm as confused as you.
The speed of BASIC can give this kind of effects. Everyone wil run into it at some point. I remember smething similiar bothered me for a long time and I just.. nope.. It's all POKE rom now on.

It's an interesing solution though. But I'm not 100% sure. These are just my 5 cents. It's my akilleas heal of the C64. The PRINT codes
 
The binking might be because of the slow action of multiple PRINTS. I can't come up with any other reason, I'm as confused as you.
The speed of BASIC can give this kind of effects. Everyone wil run into it at some point. I remember smething similiar bothered me for a long time and I just.. nope.. It's all POKE rom now on.
Thank you for the reply. Yes the book did actually mentioned that POKEing in to memory is faster than BASIC. But the second bouncing ball example is using POKE to put the ball directly on screen using

POKE 1024+X+40*Y,81

And I still get the blinking. I was hoping if I can figure out why is the first example blinking, then maybe I can figure out why the second blinking too.

The examples do actually use empty for loops to slow down the program execution. I have tried if I remove that it helps but the ball is moving way too fast.
 
Are they blinking in the same way? Is it the exact same issue?
I'm confused becuase it should word, I mean they are inherenly blinky but they should be okay of course.

Instead of a basic delay, you can try something that I did in machine code but I now know that it cal also work in BASIC, although slower. You wait for the raster beam to reach a specific position, and this will create a 50Hz or 60Hz delay.

Try to put a WAIT 53265, 128, 0 after the POKE 1024+X+40*Y, 81 and make sure there is no other delays anywhere.

EDIT: This command will cause the cpu to wait for the raster beam until it reaches the bottom position. The 'WAIT' function essentially consists of a quick internal loop that reads a specific address using 'PEEK' along with an included 'AND 128' operation.
 
Last edited:
Are they blinking in the same way? Is it the exact same issue?
It is not the same. In the first example with PRINT, the blinking is consistent like it is an error in the code repeated over and over again but the only thing is different is that I use character code instead of character. What you told about the PRINT command being slow, makes lot of sense and the book did also mentioned that.

In the second example with POKE, the blinking is incosistent, it is sometime blink 3 times, 2 times, 4 times or completely disappear from the screen for 2 seconds. It feels more like a bug somewhere.

Try to put a WAIT 53265, 128, 0 after the POKE
I have tried but unfortunately I get the same result, but thanks for mentioning this command good to know about it.
 
If you get the same result despite you use raster, that might indicate that the blinking happenes every other frame, if that's true then the logic of the PRINT is somehow different. I shouldn't be, I see your CHR conversion and see no mistake with it. But there's somthing subtle going on here. It must be some kind of error in the logic.

If I were you I would cut up the instructions as much as I could and put a huge delay between each command and look for what atually happens.
 
cut up the instructions as much as I could and put a huge delay between each command and look for what atually happens.
Thanks, I’m going to try that. For now I don’t worry too much about it because I don’t plan to move characters around the screen. I was hoping it is a common problem or something obvious I’m missing.

I don’t have this problem with sprites but I noticed when I repeat instructions in a loop, sometimes data left in memory can cause some weirdness with sprites too and I need to manually wipe memory to make sure it works as expected. Maybe something similar is happening.
 
Thanks, I’m going to try that. For now I don’t worry too much about it because I don’t plan to move characters around the screen. I was hoping it is a common problem or something obvious I’m missing.

I don’t have this problem with sprites but I noticed when I repeat instructions in a loop, sometimes data left in memory can cause some weirdness with sprites too and I need to manually wipe memory to make sure it works as expected. Maybe something similar is happening.

The tiles/Chars are as safe to use as sprites and I'm not entirely sure why I've never come across this peculiar 'bug' before, but as I mentioned, I've never been particularly fond of using PRINT. What concerns me more is that you had similar blinking when using POKE. Of course it will not be amazinly pleasing when you're moving objects on an 8x8 grid, but it should look okay.

But don't worry.. when you're working with memory from 1024 to 2024 (40x25 tiles) they are directly affected by you, there's no doublebuffer of any kind; you're in direct control of the true hardware.

That makes me 99.9% certain that this is a PRINT peculirity or some faulty logic slipped into the code, however unlikely in such a small example. The character/tile memoery works like in most Retro computers and the Nintendo NES etc.
If you perform a POKE for at least a few raster lines above where you're making changes, the effect will become visible in the current frame even if it's halfway down the screen. If the POKE happened "too late", the changes will be visible in the next frame.
 
Do remember that TheC64 is an emulated Commodore 64 and will not be 100% cycle exact, so you may have some issues.
You also have to remember that it's also using a modern television. It's one of the reason why those that collect vintage computers will try to get hold of CRT monitors and televisions. Liquid Crystal Displays reaction time are not as fast as an electron beam and a phosphorus coated piece of glass.
 
Last edited:
Back
Top Bottom