Interesting that someone would write a modern compiler for such an old platform. I especially like that the code sample you showed was using #embed, so hopefully that means they'll support C23. Your loop on the starfield didn't need to use floor or floats at all. I rewrote it with a ternary which should make it more portable to systems that might not use ASCII or PETSCII. for ( int i = -9; i < 10; i++, fputc( ' ', stdout ) ) for ( int j = 0; j < 19; j++ ) fputc( ((i*i-j*j)%6)?' ':'*', stdout ); // This takes advantage of the fact that you're clearly just testing if there's a remainder and discarding the result of the division anyway.
Really interesting, I love the fact that you can compile generic code to multiple systems. If ever I decide to give C a go I'll look into Oscar, thanks Josip :)
Thank You Peter :) I never thought that we will be able to program in C for Commodore 64, but we have so many options these days. Not to mention BASIC for ATARI 2600 :) crazy...
The 6502 has this exception philosophy when it needs to carry over to the high byte. The GitHub about Oscar says that C needs to support datatypes > char . But often in my code I have small numbers. I cannot guarantee it, though. Or I have a loop and the high byte stays fixed most of the time. So usually you write an outer loop for the high byte. Pointers are either immediates or stored in the zero page. Both times: 16 bit. I argue about speed, not code density. Floats for example should stay in interpreted code.
Yes, Oscar64 is a 16bit based C language; latter in assembly it gets converted to 8bit. 8bit char, or 8bit int, or byte is the same or it should be. For execution speed; it's a ok for convenience of easy coding :) Thank You for watching :) Cheers!
The Oscar64 code for the diamonds didn't seem to run much faster than the BASIC, might you do a speed comparison of BASIC, cc65, Oscar64, and assembly?
Thanks for this! I saw Oscar64's repo, but since I lack experience with C on the C64/128, I wasn't sure how this measured up to cc65 in terms of speed and optimization. I'm still not sure which is better, honestly. Particularly for someone just diving into C on the 6502 architecture.
This is how I see it; CC65 if faster, but Oscar64 is a bit easier to use, especially for making games and working with VICII registers. Thank You for watching :) Cheers!
Is there a graphics package for this version of C? I converted an Atari Basic program to Commodore Basic and the lack of graphics commands in Commodore Basic made it very difficult and slow performing. Of course I could have added multi color, but compared to the Atari's graphic commands, reproducing the bitmapped graphics was much more difficult than it needed to be. With this C, can you specify an X,Y location and plot a point with or without color information?
Interesting that someone would write a modern compiler for such an old platform. I especially like that the code sample you showed was using #embed, so hopefully that means they'll support C23. Your loop on the starfield didn't need to use floor or floats at all. I rewrote it with a ternary which should make it more portable to systems that might not use ASCII or PETSCII.
for ( int i = -9; i < 10; i++, fputc( '
', stdout ) )
for ( int j = 0; j < 19; j++ )
fputc( ((i*i-j*j)%6)?' ':'*', stdout ); // This takes advantage of the fact that you're clearly just testing if there's a remainder and discarding the result of the division anyway.
Yes, it is amazing that we have so many languages to program for C64.
Nice code, I like it :) Thank You!
Thank you for taking a look at oscar, I always enjoy your videos
Thank You very much and sorry for my late reply :)
As much as this is a "we did it because we can" project, it seems surprisingly more useful and productive than I've expected. Very cool.
Seams like a very good project to me, but now it's a question of further development... not do die in vain :) Cheers!
Really interesting, I love the fact that you can compile generic code to multiple systems. If ever I decide to give C a go I'll look into Oscar, thanks Josip :)
Thank You Peter :) I never thought that we will be able to program in C for Commodore 64, but we have so many options these days. Not to mention BASIC for ATARI 2600 :) crazy...
The 6502 has this exception philosophy when it needs to carry over to the high byte. The GitHub about Oscar says that C needs to support datatypes > char . But often in my code I have small numbers. I cannot guarantee it, though. Or I have a loop and the high byte stays fixed most of the time. So usually you write an outer loop for the high byte. Pointers are either immediates or stored in the zero page. Both times: 16 bit.
I argue about speed, not code density. Floats for example should stay in interpreted code.
Yes, Oscar64 is a 16bit based C language; latter in assembly it gets converted to 8bit.
8bit char, or 8bit int, or byte is the same or it should be.
For execution speed; it's a ok for convenience of easy coding :)
Thank You for watching :) Cheers!
The Oscar64 code for the diamonds didn't seem to run much faster than the BASIC, might you do a speed comparison of BASIC, cc65, Oscar64, and assembly?
Yes, it was a bit slow, You are not the first how ask for speed comparison, So Yap, I should make a video about it :) Thank You for watching, Cheers!
From what I read it's an interpreted language. Just like basic.
This is a fun video! You could do a series: "Learn C the retro way"
Thank You very much. Perhaps I should, You think that people would be interested? Cheers!
I know I'd be. coding C on the c64 looks fun.
@@JosipRetroBitsbut use a PDP11, after all that is what C is based on
Great video Josip! Thank you.
Glad you liked it :) Cheers!
That looks really cool 😎
Thank You Lee :)
Thanks for this! I saw Oscar64's repo, but since I lack experience with C on the C64/128, I wasn't sure how this measured up to cc65 in terms of speed and optimization. I'm still not sure which is better, honestly. Particularly for someone just diving into C on the 6502 architecture.
This is how I see it; CC65 if faster, but Oscar64 is a bit easier to use, especially for making games and working with VICII registers. Thank You for watching :) Cheers!
@@JosipRetroBits Absolutely not. Oscar64 generate by far faster code than CC65. Don't use floating point on C64, use fixed point math.
great!
Thank You :)
Any idea on how well Oscar64 optimizes the code during the compile? The diamond program seemed kind of slow when you ran it.
It uses pre-written asembler routines. Yes, I've notice also, if You "printf" anything on the screen it's quite a slower then cc65. Cheers!
Is there a graphics package for this version of C? I converted an Atari Basic program to Commodore Basic and the lack of graphics commands in Commodore Basic made it very difficult and slow performing. Of course I could have added multi color, but compared to the Atari's graphic commands, reproducing the bitmapped graphics was much more difficult than it needed to be. With this C, can you specify an X,Y location and plot a point with or without color information?
I should watch the whole video and I'd get my question answered,
Now get Rust to compile for C64
Well, someone needs to write a compiler :) Or do something like Rust to C and C to C64 machine code.
The content of the video is great, but please try to improve your mic quality, as you're barely audible.
Lets compile better games now :)
Games get better and better every year, for sure :) Cheers!