I've just seen it by chance. These are memories of my childhood. The programme is from Data Becker. They were based in my home town Düsseldorf. As a child, I wanted to work there when I had grown up. 😂 Thank you very much for that!!
Came across your posting after posting about Data Becker 🙂 The one thing I can't say is who is the originator of this compiler and who licensed it from the other. Data Becker used to be a force on the market for all Commodore computers but especially the 8-bit systems and Amigas. Sadly some of their products seem to have vanished from the net. Searching a few minutes ago I was not able too find any trace about their C compiler for the C64. And their 1541 book (Das Große Floppybuch) seems to have gone missing as well.
Data Becker was one of the largest publisher for computer books in Germany back im the days. And the starting screen is colored as the German flag: 🇩🇪😁 Old memories ….
“Glacial” I love it. I use several CPU and drive access pigs. When using these, I nearly always run Vice on my M2. It has more than enough oomph to run them @ 800-1000X. Makes for far faster coding breaks, and much faster getting back to what broke your code this time. In one machine I have the capabilities that would have cost countless thousands back in the day. Don’t code much this time of year, but love seeing your new content. Thanks
I got this for Christmas one year, 1985 or 1986. That startup screen was an immediate flashback. I think I was more fascinated by the command shell than the language
Thanks for this video - I always wanted to try Super C on the C64, but I just found it too confusing and difficult. Your video is really clear - great work! I would love to see the 128 version, and see how that RAM disk function works - also, to confirm that you can't compile programs to be executed without Super C (that would have been a major limitation back them!), and also to see if it takes advantage of the other video modes on the C128.
Impressive compile time with Jiffydos! On the Atari ST I used to run the Sozobon C compiler from a big ramdisk. Much quicker than from floppies, but still around 40 seconds to compile a hello world.
@@ferrellsl Nah, stuff like PlatformIO take away a lot of the bite. I am currently working with the RP2040 with the SDK using JetBrains CLion and it works wonderful.
64K is plenty for just running logic. What eats memory these days is assets, like graphics and sound. I've worked with embedded systems with just 2K of RAM, and you'd be surprised how much you can actually do with that.
@@ugagnskraake I agree. ESP32 boards are magical. Imagine developers have been continuing developments for the C64 until today. Even with the same C64 hardware but with a fast internet connection, things can get interesting.
I claim we've burned 80% of the advances in compute speed and memory in the time since for graphics and user interface. A C64 just didn't have the umpf for a GUI. Nor did I miss it. I think my reaction to GEOS at the time must have been "get this sh*t of my computer" because the included software was so slow - and I had been infected with the UNIX virus at the time. And the OS was copy protected so the failure of the one medium it shipped with would have been catastrophic to a legitimate user. C64 code was most commonly written in assembly language and the 6510 (a variant of the 6502) did provide very dense, efficient code. Computer magazines at the time were stuffed with tricks on how to squeeze more out of the machine. If you were not around back then you can't even imagine to what extreme that was taken. And with at the time disastrous side effects such as software (games and demos that is) which was not binary compatible between the PAL and NTSC versions of the C64. The reason being the PAL version running at 0.985248 MHz and the NTSC version at about 1.02 MHz. Just one example. Talking about graphics. The C64 hass a resolution of 320x200. A modern system would allow the choice of a colour for each pixel without restrictions. Assuming 24-bit colrs such an image would require 192000 bytes. Not so on the C64 where in hires and multicolour mode only 9000 bytes were required at the price of some serious restrictions on which colours were possible for a particular pixel. Which explains some of the graphical artifacts in C64 graphics. And it created lots of work for artists to work around these restrictions. Some graphics demos and games eventually did things previously considered impossible at the price of causing grey hair and excess cola consumption for the coders.
This highlights the stark limitations of the C64. I still have my childhood C64, but using it for anything “serious” really is frustrating, whereas using an Amiga is much more like using any modern machine when it comes to being able to multitask and arguably much better when it comes to developing in C.
I wish someone told me in 1987 when I first got my C64. BASIC was such a pain the ass. Took two more years to start with assembler - the bottleneck was to get the right book to start with. There was no internet, and most magazines just did no assembler courses and did not introduce languages like Pascal or C.
Very cool to see early C development tools and how clunky it was. The unix command line tools and whole shell abstraction was very smart and it really stood the test of time. Wonder how it could look like if we would have BASIC terminals. Anyway, if you looking for ideas I would love to see any 3d related content, whether it would be some legacy software, games or maybe writing program displaying cube.
I've been waiting for this one. Excellent video and presentation, as always! A quick story. I had a C128 and then an Amiga 500 back in the day. I got myself the Manx Aztec C compiler for the Amiga and was heavy into learning C. I was in the 8th grade then. I went to my friend's house and he showed me one of his new computer magazines that had a review of C64 C compilers. I read the article and couldn't believe my eyes that the compilation times were on the order of 45 MINUTES! I had to read it twice to make sure I didn't misunderstand something. Fast forward to around 2006 when I start using a C64 emulator for my Mac. I found some disk images online for a C64 C compiler (I don't remember which one) and decide to try it out remembering the crazy compilation times. Sure enough, it was around 45 minutes! I've written several compilers, including two C compilers (one using lex-yacc, the other, a fully hand coded lexical analyzer, recursive descent parser). I've often wondered where it's spending its time. After watching this video, I suspect Super C has organized its I/O operations much more efficiently than whatever the other compiler has.
@@vcv6560 But you would need a few thousand for a PC and a hard drive which nobody had until 1990s. Abacus C64 compilers would truly the compilers for the masses not the classes. Much under appreciated.
@@ferrellsl no small bit of money for a $200 computer, but this video makes clear a lot of work went into its creation and probably sold a small number of copies.
@@vcv6560 Well, to be fair, the C64 cost a lot more than $200 in the when it was released. I paid $350 for mine, and the drives themselves, which are necessary for this compiler, cost more than twice what I paid for my C64 itself in 1984, so about a grand in total. Abacus Books and Abacus Software were very popular in the day and even more so once the Commodore Amiga was released. I still own the Amiga ROM Kernel Manuals (Abacus Books) for the Amiga and several other Abacus products but never purchased this C64 compiler because I had moved on to the Amiga by the time C became a popular language for home micros.
I've seen before (I don't know where) as well as in this video that the C64 can have up to 8 drives numbered 8 to 15. How would that work? Every drive I've seen can only be set for numbers 8 thru 11. And thanks for another video that's very thorough and easy to understand! If I'd had this program 30+ years ago I would probably have learned C as well as I did with C64 BASIC (and would probably have taken a C course in college instead of Pascal, COBOL, and FORTRAN).
Nice introduction to the Super C Like how you handle a 2 drive system. Ti beats swapping disk with one drive. My1541 drive still works with USB plugin. I looked at structs in the cdemo.c program and its complicated. Can you do a simple struct demo? I can't get the strcpy to work with it, or print out the results. All I get are errors. However, I have Spinnaker's Power C and structs work fine. Perhaps a struct named Book, with Title, Author as type char. Pages as integer, and Price as float. I'm using Vice Emulator to get the speed up benefit. Super C64 V2.02, which I don't have, works with Ramdisk program described in the Transactor. I simply copied the files to Ram disk manually and make a Vice Snapshot. Wayne
Pretty cool. I could have gotten a head-start on my programming career if I had known about this (and had known what C was.) Good that the pointers are 16-bit. But without malloc() you're only going to be able to get so far...
Writing your own malloc isn't that big of a deal, but I recommend not thinking too much about it unless you need to. It's very rarely of use to anyone how to do that.
The first and only C64 C compiler I tried was from the German software publisher Data Becker which I assume was identical to the Abacus version. I was a spoiled kid, used C before on a Perkin-Elmer 7/32 (aka Interdata 7/32) system with 30 MB disk and 512 kB of RAM running under UNIX V7. Compared to that a C64 with a single 1541 disk drive was a very frustrating experience. One had to load each of editor, compiler (assembler?), linker individually all at the well known 1541 speeds. Afair I hit a bunch of incompatibilities with UNIX C quickly even for rather basic programs so I ditched it.
Never heard of Blazin Forth, but I did quick google of it and it looks really neat. It appears to have a Plus/4 version as well included. I may have to look into this one.
@@johnsmith1953x he mentioned at the endof the video the C128 version of this product, he sounded open to trying it -- 80 columns video and 2MHz CPU speed - woot woot.
In theory C is suitable for all(most) all architectures. in practice a lot of code is written without careful consideration of data types. Such as 90% of variables being int while only 8 bits are actually being used. That's causing inefficient code generation. And even basic code optimizers quickly consume more memory than a C64 has and more CPU time than the user / developer is willing to wait for. Plus it's not fun without a 2nd floppy drive and probably a floppy accelerator.
What I'd like to know is, why did they make a font where "x" looks more like aleph? Actually, why did they feel the need to make such a distinct font in the first place? The ASCII characters the C64 doesn't already have, I can understand, but... Anyway, I was curious about sizes of the numeric types, so I checked them. Not surprisingly, int is 2 bytes (unheard of in most modern systems, but is allowed even in modern C standards), and long is 4. float is also 4, appropriately for single-precision FP. The interesting thing is the size of doubles: 6 bytes! Not actually double precision, but somewhere in between. (Though contrast this with C64 BASIC's FP type, which is 5 bytes, not including the variable name.) I didn't look at the exponent and significand sizes or the memory layout.
Well, after a while, I investigated the FP formats further, and I found they're a little unusual. To explain how, let me summarize how FP works in general and the usual format. FP is based on scientific notation, where e.g. 0.0358 might be written as 3.58 × 10^-2. The parts are the mantissa (the "3.58" part), which usually has one non-zero digit before the decimal point; and the exponential part, always with a base of 10. But since computers deal in binary numbers, the normal FP version modifies it to a base of 2; the first digit of the mantissa is always 1 instead of ranging from 1 to 9, since binary only has digits 0 and 1. FP formats pack the parts as bitfields in an integer value. You have the sign bit, the exponent, and the significand (different from mantissa in that the sign has been separated).* The IEEE 754 standard defines specific formats with different sizes of exponent and significand, as well as exponent bias (a constant value added to the exponent), and the leading 1 is implied, meaning it's not actually stored, because it's not really necessary to store a bit that never changes. But 2 is not the only base possible for the exponent. IBM used base 16 for some of its systems, yielding "hexadecimal floating-point" (HFP; to be clear, everything is still in binary numbers, it's just the exponential base that is changed). And so does Abacus Super-C. float has a 7-bit exponent with bias 64 and a 24-bit significand. Since the base is 16 and not 2, this yields the same range as a base-2 exponent that is 9 bits (because it covers 2^2 or 4 times as many bit shifts). There is no longer an implied bit, since things are more complicated with the most significant bits. As far as I can tell, this all exactly matches IBM's 32-bit HFP format. The double type is the same, just with 16 more bits of significand. * Unlike the most common integer formats that are designed so that adding any value to its additive inverse and ignoring the carry-out yields zero without any further processing (known as two's complement), with FP formats, additive inverses have the same bits in the significand and only differ in the sign bit (sign-magnitude... sort of). This has the interesting consequence that there is no true zero value; instead, there are two representations for infinitesimal values, often called positive and negative zero. There can also be positive and negative infinities, but these may or may not be handled; Super-C doesn't handle them, which is not surprising given the environmental constraints.
Another thing of interest: Modern C compilers are very good at generating highly optimized code, often said to be better than assembly programmers typically can write. But Super-C is definitely not a modern compiler. And its code is very unoptimized, unsurprisingly. But sometimes it's shockingly bad. I wrote a very simple loop to fill a range of memory with a pattern, which I had already done in assembly. The assembly version finishes too fast to time, so probably less than one frame. But the Super-C equivalent takes *more than 15 seconds* ! That's around 1,000 times slower! Still faster than BASIC, but not by much.
Suspect it would have been about as limited as every other high level language on the c64. Young lion might have discovered at an earlier age how bloated C could be in a constrained enough platform & gotten jaded about it. Sadly, no inline assembler so it seems to compile straight to byte code.
There is no thread support at all. You can execute another program; but the program can't return to the calling program. It transfers control to the new program.
@@MyDeveloperThoughts Haha OK. Sorry, I'm not a native speaker and whenever I hear something I've not heard before, I think it must be some kind of dialect 😂
I got a copy of that C manual at home. And the discs should be somewhere too. :-) And I do mean a copy.. discs was copies too.. but they was coppied back in the day.. maybe around 1990. So thats all forgotten.
Do you also use any modern languages? If so how do you find the time to also program c64? Is that like a hobby or something and how did you come to learn about the commodore 64?
Modern Languages: Yes. I am a software developer (25+ years). I worked in a lot of languages over my career, but currently it is mostly Java, JavaScript + Misc Web front end tech and a wide variety of backend data languages and technologies. C64 Programming: It's a new hobby. I got inspired to pick it up about a year ago when from a session I attended at the Vintage Computer Fair East in April 2023. They had a classroom full of C64s and they were teaching people BASIC like it was 1984. I loved it. I had a C64 growing up from age 10-16. I did not do any serious programing on it in my youth, but I ran a Bulletin Board on it for many years. I got serious about my passion for software development after I moved to the PC DOS Platform though.
@@MyDeveloperThoughts Ok thanks, I have a similar story, I grew up with a Commodore 16 and Commodore 64 and learned programming on those machines, Basic and Assembler (Using ZEUS Assembler on the 64, a very good and fast compiler) was pretty much what was there (I never heard of C back then), now I've worked as a software developer since 1997. Those were amazing machines to work with.
I'd like to see some benchmarks of the code produced by this compiler vs Commodore BASIC code. The compiled code should be faster but I'd like to see some proof.
Any compiled code would be faster, just by not having to re-parse every line every time, so even a poor compiler for basic or any other language would see gains compared to basic. Even simple stuff like FOR J = 1 to 1000 : NEXT will treat the variable and the numbers as floats while doing the "math" on them so simlpy having this construct be an INT would make this dummy loop lots faster. Same goes for tons of other things where BASIC isn't good for speed at all.
@@JanneJohansson Yes, I'm well aware of that as a professional C/C++ programmer. I'm interested in some benchmarks, even if they're synthetic. I'd like to see how this compiler fares against C64 BASIC vs the C64 version of Power C, or even Oscar 64.
Every video I watch makes me say "I wish I had seen this 30 years ago."
I've just seen it by chance. These are memories of my childhood. The programme is from Data Becker. They were based in my home town Düsseldorf. As a child, I wanted to work there when I had grown up. 😂 Thank you very much for that!!
lol same
Came across your posting after posting about Data Becker 🙂 The one thing I can't say is who is the originator of this compiler and who licensed it from the other.
Data Becker used to be a force on the market for all Commodore computers but especially the 8-bit systems and Amigas. Sadly some of their products seem to have vanished from the net. Searching a few minutes ago I was not able too find any trace about their C compiler for the C64. And their 1541 book (Das Große Floppybuch) seems to have gone missing as well.
@@ralfbaechle
Can be found under archivedotorg, incl. floppy and the compiler is under commodoredotsoftware
Data Becker was one of the largest publisher for computer books in Germany back im the days. And the starting screen is colored as the German flag: 🇩🇪😁 Old memories ….
“Glacial” I love it. I use several CPU and drive access pigs. When using these, I nearly always run Vice on my M2. It has more than enough oomph to run them @ 800-1000X. Makes for far faster coding breaks, and much faster getting back to what broke your code this time. In one machine I have the capabilities that would have cost countless thousands back in the day. Don’t code much this time of year, but love seeing your new content. Thanks
Then again, you might want getting straight into various cross-dev tools available.
I got this for Christmas one year, 1985 or 1986. That startup screen was an immediate flashback. I think I was more fascinated by the command shell than the language
I love how this vid happens to contain one the easiest explanations of pointers I’ve seen over the years.
Thanks for this video - I always wanted to try Super C on the C64, but I just found it too confusing and difficult. Your video is really clear - great work! I would love to see the 128 version, and see how that RAM disk function works - also, to confirm that you can't compile programs to be executed without Super C (that would have been a major limitation back them!), and also to see if it takes advantage of the other video modes on the C128.
I did all of my coding directly in 6510 machine code (hex code). There was no assember either.
Would love to explore this a bit more
I wish I had this ~40 years ago, but I didn't even have a drive and this would probably take weeks to do with tapes =)
Brit? ;-)
No, still in EU =)
Impressive compile time with Jiffydos! On the Atari ST I used to run the Sozobon C compiler from a big ramdisk. Much quicker than from floppies, but still around 40 seconds to compile a hello world.
This is very interesting and I love the C64 but I'm also very happy that programming is not that complicated today.
Agreed!
If you're a C programmer, it's still this complicated today, especially if you work on embedded systems or ESP32 boards.
Less complicated, no but certainty more integrated.
@@ferrellsl Nah, stuff like PlatformIO take away a lot of the bite. I am currently working with the RP2040 with the SDK using JetBrains CLion and it works wonderful.
You explanation of pointers was clear and concise. I wish it had been explained to me like that 20 years ago
Wow! It's unbelievable what the developers could do with 64K.
Have you never seen "FULL ZX-81 CHESS IN 1K"? It's a classic. 🙂
64K is plenty for just running logic. What eats memory these days is assets, like graphics and sound.
I've worked with embedded systems with just 2K of RAM, and you'd be surprised how much you can actually do with that.
@@ugagnskraake I agree. ESP32 boards are magical. Imagine developers have been continuing developments for the C64 until today. Even with the same C64 hardware but with a fast internet connection, things can get interesting.
I claim we've burned 80% of the advances in compute speed and memory in the time since for graphics and user interface. A C64 just didn't have the umpf for a GUI. Nor did I miss it. I think my reaction to GEOS at the time must have been "get this sh*t of my computer" because the included software was so slow - and I had been infected with the UNIX virus at the time. And the OS was copy protected so the failure of the one medium it shipped with would have been catastrophic to a legitimate user.
C64 code was most commonly written in assembly language and the 6510 (a variant of the 6502) did provide very dense, efficient code. Computer magazines at the time were stuffed with tricks on how to squeeze more out of the machine. If you were not around back then you can't even imagine to what extreme that was taken. And with at the time disastrous side effects such as software (games and demos that is) which was not binary compatible between the PAL and NTSC versions of the C64. The reason being the PAL version running at 0.985248 MHz and the NTSC version at about 1.02 MHz. Just one example.
Talking about graphics. The C64 hass a resolution of 320x200. A modern system would allow the choice of a colour for each pixel without restrictions. Assuming 24-bit colrs such an image would require 192000 bytes. Not so on the C64 where in hires and multicolour mode only 9000 bytes were required at the price of some serious restrictions on which colours were possible for a particular pixel. Which explains some of the graphical artifacts in C64 graphics. And it created lots of work for artists to work around these restrictions. Some graphics demos and games eventually did things previously considered impossible at the price of causing grey hair and excess cola consumption for the coders.
@@ralfbaechle Talking about experience. Thank you for sharing your knowledge and expertise.
This highlights the stark limitations of the C64. I still have my childhood C64, but using it for anything “serious” really is frustrating, whereas using an Amiga is much more like using any modern machine when it comes to being able to multitask and arguably much better when it comes to developing in C.
amazing how far motivation and teamwork can bring you and keep being alive in modern days
I wish someone told me in 1987 when I first got my C64.
BASIC was such a pain the ass. Took two more years to start with assembler - the bottleneck was to get the right book to start with.
There was no internet, and most magazines just did no assembler courses and did not introduce languages like Pascal or C.
Very cool to see early C development tools and how clunky it was. The unix command line tools and whole shell abstraction was very smart and it really stood the test of time. Wonder how it could look like if we would have BASIC terminals. Anyway, if you looking for ideas I would love to see any 3d related content, whether it would be some legacy software, games or maybe writing program displaying cube.
I've been waiting for this one. Excellent video and presentation, as always!
A quick story. I had a C128 and then an Amiga 500 back in the day. I got myself the Manx Aztec C compiler for the Amiga and was heavy into learning C. I was in the 8th grade then. I went to my friend's house and he showed me one of his new computer magazines that had a review of C64 C compilers. I read the article and couldn't believe my eyes that the compilation times were on the order of 45 MINUTES! I had to read it twice to make sure I didn't misunderstand something. Fast forward to around 2006 when I start using a C64 emulator for my Mac. I found some disk images online for a C64 C compiler (I don't remember which one) and decide to try it out remembering the crazy compilation times. Sure enough, it was around 45 minutes!
I've written several compilers, including two C compilers (one using lex-yacc, the other, a fully hand coded lexical analyzer, recursive descent parser). I've often wondered where it's spending its time. After watching this video, I suspect Super C has organized its I/O operations much more efficiently than whatever the other compiler has.
You would need several thousand dollars for a C-compiler that did this back in the mid-1980s.
How times have changed.
That's part of what made Turbo Pascal so transcendent, it did it all for $99 compared to $500 for something from Microsoft at the time.
@@vcv6560 But you would need a few thousand for a PC and a hard drive which nobody had until 1990s. Abacus C64 compilers would truly the compilers for the masses not the classes. Much under appreciated.
The Abacus price was $79 USD.
@@ferrellsl no small bit of money for a $200 computer, but this video makes clear a lot of work went into its creation and probably sold a small number of copies.
@@vcv6560 Well, to be fair, the C64 cost a lot more than $200 in the when it was released. I paid $350 for mine, and the drives themselves, which are necessary for this compiler, cost more than twice what I paid for my C64 itself in 1984, so about a grand in total. Abacus Books and Abacus Software were very popular in the day and even more so once the Commodore Amiga was released. I still own the Amiga ROM Kernel Manuals (Abacus Books) for the Amiga and several other Abacus products but never purchased this C64 compiler because I had moved on to the Amiga by the time C became a popular language for home micros.
I've seen before (I don't know where) as well as in this video that the C64 can have up to 8 drives numbered 8 to 15. How would that work? Every drive I've seen can only be set for numbers 8 thru 11. And thanks for another video that's very thorough and easy to understand! If I'd had this program 30+ years ago I would probably have learned C as well as I did with C64 BASIC (and would probably have taken a C course in college instead of Pascal, COBOL, and FORTRAN).
Nice introduction to the Super C
Like how you handle a 2 drive system. Ti beats swapping disk with one drive. My1541 drive still works with USB plugin.
I looked at structs in the cdemo.c program and its complicated.
Can you do a simple struct demo?
I can't get the strcpy to work with it, or print out the results. All I get are errors.
However, I have Spinnaker's Power C and structs work fine.
Perhaps a struct named Book, with Title, Author as type char.
Pages as integer, and Price as float.
I'm using Vice Emulator to get the speed up benefit.
Super C64 V2.02, which I don't have, works with Ramdisk program described in the Transactor.
I simply copied the files to Ram disk manually and make a Vice Snapshot.
Wayne
Pretty cool. I could have gotten a head-start on my programming career if I had known about this (and had known what C was.)
Good that the pointers are 16-bit. But without malloc() you're only going to be able to get so far...
Writing your own malloc isn't that big of a deal, but I recommend not thinking too much about it unless you need to. It's very rarely of use to anyone how to do that.
cumbersome but functional with interesting nuances and abilities.
The first and only C64 C compiler I tried was from the German software publisher Data Becker which I assume was identical to the Abacus version. I was a spoiled kid, used C before on a Perkin-Elmer 7/32 (aka Interdata 7/32) system with 30 MB disk and 512 kB of RAM running under UNIX V7. Compared to that a C64 with a single 1541 disk drive was a very frustrating experience. One had to load each of editor, compiler (assembler?), linker individually all at the well known 1541 speeds. Afair I hit a bunch of incompatibilities with UNIX C quickly even for rather basic programs so I ditched it.
Looks really interesting. I need to get my 1541's working.
Hmm, clunk clunk, I'd suggest an inexpensive SD2IEC or the like, I've one with the Fastload built-in. But to be truthful also I have three 1541s 😄
@@vcv6560 I have been after a 1570 and 1571 for ages but they are not common here and rather expensive. 1581's I have NEVER seen.
Im keeping up with Commodore!
Good software from Erlangen :)
Nice video! Please make a video of Laser Basic and its compiler from Ocean.
I like the editor, and the tiny shell for commanding the environment. Its defiantly worth a DL and try with the emulator.
Thanks for a great review of this product. Do you have any experience with Blazin Forth?
Never heard of Blazin Forth, but I did quick google of it and it looks really neat. It appears to have a Plus/4 version as well included. I may have to look into this one.
@@MyDeveloperThoughts Is there a C compiler for the C128 ?
@@johnsmith1953x Abacus made a Commodore 128 version of the software he showed in this video.
@@johnsmith1953x he mentioned at the endof the video the C128 version of this product, he sounded open to trying it -- 80 columns video and 2MHz CPU speed - woot woot.
This is excellent! Love it. You'd think C would be the native language of a Commodore 64 since C is the first letter in it
In theory C is suitable for all(most) all architectures. in practice a lot of code is written without careful consideration of data types. Such as 90% of variables being int while only 8 bits are actually being used. That's causing inefficient code generation. And even basic code optimizers quickly consume more memory than a C64 has and more CPU time than the user / developer is willing to wait for. Plus it's not fun without a 2nd floppy drive and probably a floppy accelerator.
That sprite looks like a blue euterus.
I really hoped for a makefile :D Its so tedious to invoke all these command by hand.
What I'd like to know is, why did they make a font where "x" looks more like aleph? Actually, why did they feel the need to make such a distinct font in the first place? The ASCII characters the C64 doesn't already have, I can understand, but...
Anyway, I was curious about sizes of the numeric types, so I checked them. Not surprisingly, int is 2 bytes (unheard of in most modern systems, but is allowed even in modern C standards), and long is 4. float is also 4, appropriately for single-precision FP. The interesting thing is the size of doubles: 6 bytes! Not actually double precision, but somewhere in between. (Though contrast this with C64 BASIC's FP type, which is 5 bytes, not including the variable name.) I didn't look at the exponent and significand sizes or the memory layout.
Well, after a while, I investigated the FP formats further, and I found they're a little unusual. To explain how, let me summarize how FP works in general and the usual format.
FP is based on scientific notation, where e.g. 0.0358 might be written as 3.58 × 10^-2. The parts are the mantissa (the "3.58" part), which usually has one non-zero digit before the decimal point; and the exponential part, always with a base of 10. But since computers deal in binary numbers, the normal FP version modifies it to a base of 2; the first digit of the mantissa is always 1 instead of ranging from 1 to 9, since binary only has digits 0 and 1.
FP formats pack the parts as bitfields in an integer value. You have the sign bit, the exponent, and the significand (different from mantissa in that the sign has been separated).* The IEEE 754 standard defines specific formats with different sizes of exponent and significand, as well as exponent bias (a constant value added to the exponent), and the leading 1 is implied, meaning it's not actually stored, because it's not really necessary to store a bit that never changes.
But 2 is not the only base possible for the exponent. IBM used base 16 for some of its systems, yielding "hexadecimal floating-point" (HFP; to be clear, everything is still in binary numbers, it's just the exponential base that is changed). And so does Abacus Super-C. float has a 7-bit exponent with bias 64 and a 24-bit significand. Since the base is 16 and not 2, this yields the same range as a base-2 exponent that is 9 bits (because it covers 2^2 or 4 times as many bit shifts). There is no longer an implied bit, since things are more complicated with the most significant bits. As far as I can tell, this all exactly matches IBM's 32-bit HFP format. The double type is the same, just with 16 more bits of significand.
* Unlike the most common integer formats that are designed so that adding any value to its additive inverse and ignoring the carry-out yields zero without any further processing (known as two's complement), with FP formats, additive inverses have the same bits in the significand and only differ in the sign bit (sign-magnitude... sort of). This has the interesting consequence that there is no true zero value; instead, there are two representations for infinitesimal values, often called positive and negative zero. There can also be positive and negative infinities, but these may or may not be handled; Super-C doesn't handle them, which is not surprising given the environmental constraints.
Another thing of interest: Modern C compilers are very good at generating highly optimized code, often said to be better than assembly programmers typically can write. But Super-C is definitely not a modern compiler. And its code is very unoptimized, unsurprisingly. But sometimes it's shockingly bad. I wrote a very simple loop to fill a range of memory with a pattern, which I had already done in assembly. The assembly version finishes too fast to time, so probably less than one frame. But the Super-C equivalent takes *more than 15 seconds* ! That's around 1,000 times slower! Still faster than BASIC, but not by much.
greatness
Suspect it would have been about as limited as every other high level language on the c64. Young lion might have discovered at an earlier age how bloated C could be in a constrained enough platform & gotten jaded about it. Sadly, no inline assembler so it seems to compile straight to byte code.
Have you tried this with fast loading cartridges like Super Snapshot or Epyx Fast Load? I wonder how they perform.
This is superb stuff. Would be nice if there are some hacks providing REU use.
Please do Laser BASIC and White Lightning (Forth), by Ocean/Oasis.
Thanks! I might have to check those two products out.
@@MyDeveloperThoughts you should be able to turn on REU in the emulator and sit the compiler tools in the ramdrive.
Do you know if Super-C come with a library that support lightweight threads? How about fork()?
There is no thread support at all. You can execute another program; but the program can't return to the calling program. It transfers control to the new program.
Dude, this is 8 k kernal ROM. fork() was NOT really an option to PC until the Commodore Amiga and OS/2.
@@johnsmith1953x That's good to know. Thank you!
Where are you from? I've never heard this pronunciation of "available" ("avable")
I'm from New Jersey. But it's more likely I was speaking too fast when I recorded that segment.
@@MyDeveloperThoughts Haha OK. Sorry, I'm not a native speaker and whenever I hear something I've not heard before, I think it must be some kind of dialect 😂
I am not sure why the UI gives me vibes of Textomat Plus (I never found out what it actually was and how to use it)
But the script kiddies will complain.
I got a copy of that C manual at home. And the discs should be somewhere too. :-)
And I do mean a copy.. discs was copies too.. but they was coppied back in the day.. maybe around 1990. So thats all forgotten.
Do you also use any modern languages? If so how do you find the time to also program c64? Is that like a hobby or something and how did you come to learn about the commodore 64?
Modern Languages:
Yes. I am a software developer (25+ years). I worked in a lot of languages over my career, but currently it is mostly Java, JavaScript + Misc Web front end tech and a wide variety of backend data languages and technologies.
C64 Programming:
It's a new hobby. I got inspired to pick it up about a year ago when from a session I attended at the Vintage Computer Fair East in April 2023. They had a classroom full of C64s and they were teaching people BASIC like it was 1984. I loved it.
I had a C64 growing up from age 10-16. I did not do any serious programing on it in my youth, but I ran a Bulletin Board on it for many years. I got serious about my passion for software development after I moved to the PC DOS Platform though.
@@MyDeveloperThoughts Ok thanks, I have a similar story, I grew up with a Commodore 16 and Commodore 64 and learned programming on those machines, Basic and Assembler (Using ZEUS Assembler on the 64, a very good and fast compiler) was pretty much what was there (I never heard of C back then), now I've worked as a software developer since 1997. Those were amazing machines to work with.
I'd like to see some benchmarks of the code produced by this compiler vs Commodore BASIC code. The compiled code should be faster but I'd like to see some proof.
From what I remember 4-10x at best, compiler technology wasn't very optimized in those small systems.
Any compiled code would be faster, just by not having to re-parse every line every time, so even a poor compiler for basic or any other language would see gains compared to basic. Even simple stuff like FOR J = 1 to 1000 : NEXT will treat the variable and the numbers as floats while doing the "math" on them so simlpy having this construct be an INT would make this dummy loop lots faster. Same goes for tons of other things where BASIC isn't good for speed at all.
@@JanneJohansson Yes, I'm well aware of that as a professional C/C++ programmer. I'm interested in some benchmarks, even if they're synthetic. I'd like to see how this compiler fares against C64 BASIC vs the C64 version of Power C, or even Oscar 64.