Computer Chronicles and MotorWeek were fixtures of my Saturday afternoons as a young kid in the 80s. 35+ years later both shows became fascinating and priceless time capsules of the era.
For me it was those two, but also Bob Ross (of course!) and Star Gazers (Keep looking up!). I enjoyed drawing and astronomy and the entire reason I got into computers was to program the equations from the astronomy with your pocket calculator book.
That's also why Apple renamed OpenStep to Cocoa. Java was supposed to be the primary development language for Mac OS X (because Java and Cocoa go great together).
For a while you could write OSX stuff in Java. I did. They also had some pretty okay JNI bindings for stuff like quicktime, so I was able to write a java application that used quicktime to load and display videos. I needed to analyze video streams for my dissertation, so I wrote some custom visualization stuff in java that used the quicktime bindings. Good times.
When you hear people complaining about Time Machine you can stop listening once they mention their NAS. Time Machine over the network has never been properly supported and is inherently unsafe.
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.
I'm very surprised it's organized as just a single 162 kB source document instead of being divided into smaller modules to make the code easier to work with, speed up build times, etc.
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?
I don’t think TECO is inherently bad for this size of file. What might be tough is, if anything were compute-bound, and the processor were loaded down with other jobs, you could have the usual timeshare-related problems. If you wanted to look at a chunk of text, it would be a problem to send it to your TTY.
If you were using a KA10 variant, your process could get evicted pretty easily because the core memory requirements of all the running jobs had to be less than 256K words. The variants with paging would have a more efficient method for virtual memory.
Compile times would be affected by the same issues.
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.
> Sequential data transfer rates are faster than the C64 disk drive
The C64 disk interface is notoriosuly broken. The C64 and the 15x1 drives effectively had the same relatively fast processor but with a tiny pipe connecting the two.
It's not odd at all for a machine that was designed in 1976/77.
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.
This game achieves its smoothness by synchronizing to the video refresh. That's not a particularly challenging thing to do, but it wasn't a viable option for commercial games back in the day due to uncertainty of how to do it properly across the different Apple II models.
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.
