Commodore 64 BASIC and KERNAL on Atari 8-bit hardware | Hacker News Reader

Commodore 64 BASIC and KERNAL on Atari 8-bit hardware

github.com

92 pointsTMWNN38 comments

Talking about retro technology, I am shamelessly plugging my twitter account for retro tech adverts.

I've been posting those amazing old tech adverts out of magazines 90s, 80s and older. Looking at adverts for retro games, retro electronics and others. Hope to see you there.

Source: https://www.reddit.com/r/c64/comments/p24fo8/i_modified_the_...

Blasphemy.

Username checks out. :)

Old school gaming is just so great. Jelly Boy just got released on the Switch for Super Nintendo Online. I seriously can't believe that up until like 3 days ago, I had no idea this game existed. My get woken up every morning now by my 4 year old to play it. We go around the house saying JELLY BOYYYY, and fist punching through our t-shirts to make it look like the game. Just so fun to have those little flashes of when games where just quirky and fun.

I remember Atari basic was quite superior, so probably that's why there was no port. Awesome work!

It's unfortunate that Commodore shipped BASIC 2.0 on the 64. They already had shipped PETs with the much superior BASIC 4.0 years earlier. It was likely a cost saving measure: they had a more favorable licensing deal with MS on BASIC 2.0 and it fit on fewer ROM chips. Too late the C128 came with BASIC 7.0 which was actually quite good (for an 8-bit BASIC anyway).

Jack Tramiel was the OG of cutthroat business practices. He bought Basic for a flat fee from Gates in 1977, that included rights to modify and ship on any hardware platform he wanted.

>Doing business with Gates was decent, Tramiel said. "He came to see me, tried to sell me Basic, and he told me that I don't have to give him any money, all I had to give him was $3 per unit. I told him I was already married," Tramiel said.

>Tramiel instead told Gates he'd pay a flat fee of $25,000, rejecting the idea of paying $3 for each Commodore 64 sold. "In about six weeks [Gates] came and took that $25,000. Since then he did not speak to me," Tramiel said.

https://www.computerworld.com/article/2813900/innovators-rem...

> It's unfortunate that Commodore shipped BASIC 2.0 on the 64

There are many things that are unfortunate about the way the C64 was shipped. For Commodore, the entire point of the C64 was to slap it together and shove it out the door as quickly and cheaply as possible, to try and capitalize on the unexpected success of the VIC-20, which was itself slapped together when the VIC graphics chip didn't sell.

What's fascinating about the C64 is just how right that "slap it together and shove it out the door" strategy was.

Market price and timing were absolutely key to the C64's early success. All those bugs and missing features? The 3rd party developers would quickly take care of that.

The products that Commodore tried to make good, better than "shove it out the door" quality, like the Plus/4 and C128, were complete duds. Much better design, much better software, and irrelevant.

How was C128 not slapt together without any plan or adult supervision? You paid for 2 cpus and two graphic chips, one cpu only ran a reset routine?, and the second "graphic chip" had no graphic enhancements and required expensive monitor. Zero practical upgrades when running C64 software, no incentives to develop c128 native software. Price with floppy drive on par with Atari ST and 20% away from Amiga. As a bonus C128D was more expensive to manufacture than Amiga.

> It's unfortunate that Commodore shipped BASIC 2.0 on the 64.

It might also have contributed to the success of C64 by "encouraging" early use of machine language. BASIC is great, but to truly make C64 shine you do need assembly language.

Notably, it was also pretty trivial to expand BASIC capabilities. A lot of utilities did just that, like adding graphics commands and sprite extensions. Simons' BASIC is probably the most comprehensive example, and it also came as a cartridge.

Really, BASIC v2 is at its best as a scripting language to load and call machine language subroutines ...

It is quite good but it is also quite slow compared to BBC BASIC on the 2 MHz 6502-based BBC Micro.

Didn't it do something weird with strings where you had to periodically LIST and reload your program to prevent crashes?

Yeah, famous bugs. Atari BASIC source is fully documented in this book:

https://archive.org/details/ataribooks-the-atari-basic-sourc...

See appendix B, memmove() was broken.

Has anyone ever fixed this? It would be cool if they managed to speed it up some as well. Of course there is TurboBASIC XL but it isn't ROM-able.

Atari shipped a final Rev C basic both in the ROMs for the XE computers and on cartridges for people that requested it.

There were several derivations. The original authors of Atari Basic produced BASIC XL and BASIC XE on cartridge, each with additional language features. There's also the really cool Altirra BASIC (see https://virtualdub.org/downloads/Altirra%20BASIC%20Reference...) which ships with the Altirra emulator as a tokenized-code compatible, but faster and more featureful, implementation. A version of that was included in the ROM for the new 576NUC+ all-in-one Atari-compatible.

I think rev c as shipped on the XE models fixed it. But yeah, Turbo BASIC XL was the bomb.

If I remember right, Atari Basic had 4 byte floats and Commodore Basic has 4 byte floats. The extra precision mattered for some programs, but the small size made the Atari Basic faster.

CBM had 5 byte floats I think you meant--edit: maybe it was 6. 5 byte mantissa and 1 byte exponent??

CBM BASIC was a Microsoft product and I think more or less what all the Microsoft BASICs did was convert everything to floats internally--even when not really needed. For example the index in a FOR I=1 to 10 was dealt with internally (and slowly) as a float--including the operation to increment it by 1 or the STEP value.

If Atari BASIC didn't do that it would have made things faster in many situations. Apple's Integer BASIC was faster because it didn't support floats at all, if you could deal with the almost C-style strings IIRC.

CBM had 5 byte floats, but when they were copied into the floating point "registers", they were expanded into a 6 or 7 byte representation for speed. It was 8 bits of exponent, 1 bit sign, and 31 bits of mantissa (with one extra implicit bit since the leading bit is always 1).

It's true there was very little performance gain to using BASIC integer variables, since they'd be converted to floats internally almost always. The one real advantage of integers is that a DIMed array of ints was more compact than an array of floats.

I always thought it would be cool if the line numbers were floating point. You could always insert a line between any existing ones then.

I'm pretty sure Netflix queues used to work this way. For the DVD-by-mail service, I think.

Basically, the web page had a text field next to each movie, and you could type in numbers, then submit a form, and it would reorder your queue.

The obvious thing to do was swap "1" and "2" to flip the order of the top two items. But you could just set the second one to "0.5" and leave the first at "1". When you submitted the form, it would renumber them all with integers.

That would be JOSS or FOCAL:

https://en.wikipedia.org/wiki/JOSS

https://en.wikipedia.org/wiki/FOCAL_(programming_language)

We could add an imaginary part to line numbers. If you do a GOTO 200 + 20i, you’ll jump to a line that’s above the program in the imaginary axis and continue running from there.

With FOCAL, though, they were more like modules rather than floating point values; you could address blocks of code ("groups") by, for lack of a better expression, the integer portion of the number, with the fractional portion being the line number within that group.

This is why everyone use 10, 20 etc.

I think I remember there was a Renumber command that would reset any inserted numbers too?

There were BASIC extensions you could get that added renumber. The C128 had renumber as a builtin.

Integer variables were written I%. I%=I%+1 was certainly faster than I=I+1, but I am not sure if that extended to FOR loops.

Oh, you'd be surprised. Run this:

10 TI$="000000":J=.:FORI=0TO900:J=J+1:NEXT:PRINTTI

20 TI$="000000":J%=.:FORI=0TO900:J%=J%+1:NEXT:PRINTTI

I get, on VICE in PAL mode, 212 jiffies and 256 jiffies respectively.

The reason for this nonsense is that Commodore BASIC does the math in floating point, and converts it to integer after the fact. You can speed this up with

20 TI$="000000":J%=.:K%=1:FORI=0TO900:J%=J%+K%:NEXT:PRINTTI

which gives me 244 jiffies, but still slower, because even though K% is now already an integer and it costs "less" since it is now in a variable instead of being converted from BASIC text, it still requires a roundtrip to the floating point accumulator.

Bottom line: always benchmark.

Cool! I did remember benchmarking it, but it's been... a few years :)

The implementation issue with integers in Commodore BASIC 2 was that they were still stored in a 5 byte format, while actually using just the first two bytes. Meaning, unlike with other implementations of MS BASIC, they occupied 7 bytes in memory (with two leading bytes for the identifier), just like floating point variables, and there was no improvement on memory usage with integers.

Atari BASIC used 48-bit BCD floats and the routines were not well optimized, making it one of the slowest at the time(later retrohobbyists have made various patches as well as faster BASIC implementations). It was also Microsoft-incompatible which made it an odd duck among the microcomputer BASICs.

Atari had 6 byte floats, BCD. Commodore had 5 bytes, binary.

Atari BASIC's tokenization scheme should have made it faster than others. But it suffered from some poor implementation details which made it perform quite poorly.

https://en.wikipedia.org/wiki/Atari_BASIC#Performance

> but the small size made the Atari Basic faster.

The 6502 running at 2MHz also helped a lot.

Imagine a 6502 at 3.4 GHz.

These days you can get one that will go as high as 14MHz.

If Apple decided to do an Apple IV (kind of an apology for making the Apple ///) with that, it'd easily smoke an early 386...

Reply on news.ycombinator.com