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.
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.
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.
> 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.
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.
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'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.
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.
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
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.
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 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://twitter.com/OldTechAdverts
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.