I've recently been playing around with some of the old Logo implementations from the 80s and I've been really charmed by just how powerful and elegant that language can be once you've wrapped your head around it. It makes BASIC look barbaric by comparison.

Let's say that back in 1930s when they were assigning frequencies for the broadcast television channels, they allocated enough extra bandwidth for a future color (chroma) signal, apart from the existing monochrome (luma) signal.

If the bandwidth was available, would it have been possible to include separate chroma and luma components in the broadcast signal without the two interfering with each other, thereby producing a much cleaner color image while maintaining backward compatibility with the original B&W TV sets?

- Design Patterns by the Gang of Four

- Modern C++ Design by Andrei Alexandrescu

- Code Complete from the Microsoft Press

That's enough old paper to raise the display height to a comfortable level.

Surprisingly, this version does not require MacOS 26 (Tahoe).

Time Machine to a local drive connected via USB is great.

If you want to backup over the network you will have to find another solution.

Were PDP-10 text editors of the day able to easily work with such large documents? And how long would it typically take to assemble all of that code in one go?

Here's a little 6 minute clip: An acid trip, and the origins of Hypercard.

https://www.youtube.com/watch?v=bdJKjBHCh18

While it's true that early production machines had reliability problems, the same was also true for the C64. The machine we got for xmas 1983 was as solid as a tank.

The tapes were extremely robust and resistant to abuse, much more so than floppy disks. I tried to fry tapes, and couldn't.

For games, the tape drives were surprisingly effective. Sequential data transfer rates are faster than the C64 disk drive, and unlike the C64 they operate independently from the main CPU, with DMA access to the full 64 kB address space.

This means that many games were up and running in seconds and could load upcoming levels in the background while you were playing the game.

(The tape drives were much less effective for random-access, file-based storage, as the seek times were obviously atrocious compared to a disk drive.)

First-party software was also very high quality.

The problem was the business plan. Coleco made the same mistake as Atari and Texas Instruments, in that the business plan was modelled after the game console business. The tapes were expensive and proprietary when they didn't need to be, and the 3rd-party software ecosystem was completely locked down. Technical info was unavailable for hobbyists and independent developers.

By the time the Adam is released, the C64 and Apple IIe are already entrenched in the home markets with exponentially expanding library of independent software. The Adam's locked-down ecosystem couldn't complete.

It only took one year for hobbyists to completely reverse engineer the Adam, at which point some interesting independent software starts to appear. But by that time the business was already dead.

However, for a machine released in 1983 (the Apple IIe) it is indeed very odd. But the IIe is an odd machine in many ways.

The Apple II platform stagnated as Apple poured all their resources into the Apple III (which has all those features and much more).

The Apple II refused to die, so Apple assigned a pair of engineers to design a cost-reduced version of the Apple II, and this became the IIe. The goal was only to minimize manufacturing costs, so the new features like timers were off the table.

The IIe became an unexpected smash hit in the home and education markets (stealing those markets from the 128k Mac), and only then did Apple devote some new resources to the platform (and reposition the 128k Mac as a laughably underpowered productivity machine).

The Apple IIc (1984) was the first Apple II to get a proper modern makeover. Of course it was a flop, while the odd-ball IIe continued to fly off the shelves.

Apple added VBL polling with the IIe in 1983, and then broke it a year later with the IIc. And an unfortunate typo in the IIc technical reference manual meant that developers couldn't figure out how to do it properly.

The only official, cross-platform way to do it was through the mouse firmware, but most users didn't have the mouse hardware installed.

This game uses the mouse firmware, if available (II+ w/ mouse card, IIc, IIgs), to generate VBL interrupts. On the IIe without a mouse card, it polls for VBL.

By the way, if you're running this game on the Virtual ][ emulator for MacOS, be sure to disable the mouse card. Its emulated mouse card only generates VBL interrupts at 30 Hz, so the game runs at half speed.

After Google Reader shut down paid for Feedly for a while before switching to self-hosted FreshRSS. (https://freshrss.org)

I'm not a web guy and I detest all forms of system administration, but I had no trouble setting it up on my host. I've got it configured to update its feeds one per hour from 6AM to 8PM. It just does its thing, and works fine on both desktop and mobile.

https://groups.google.com/g/comp.sys.hp48/c/BS7c8hRAau0/m/P5...

Do you use single, easy-to-remember plain-text passwords for all of your accounts and services? If not, you need to understand what the recovery process is when your passkey/2FA/pw-manager is unavailable or lost.

I guess it takes 10 Watts to maintain the Thunderbolt controller, USB hub, A13 processor, and run the fan.

Power usage does drop to <1 Watt when the Mac is actually sleeping, unless anything is plugged into the USB hub. Even an empty iPhone cable will cause the display to draw 5 Watts. It's disappointing.

Use https://48calc.org/db48x/index.html