imrannazar.com
Front-end #typescript developer, author of RFC 7168 (HTCPCP for teapots); occasional plumber, more than occasional #c64 #retrocomputing enthusiast, terrible at #piano.
Header photo is a verdant scene looking over the landscape near Buxton, England.
281 posts
142 followers
1,528 following
Regular Contributor
Active Commenter
comment in response to
post
For me it's about the piano sonatas. Nahre Sol described the slow mvt of the Pathetique as the most beautiful melody in all of music, and it's hard to disagree.
If you want modern reinterpretations, it's hard to do better than Tina S's Moonlight 3rd on electric guitar.
comment in response to
post
Mm, I remember thinking when I was looking for illustrations of the photoelectric effect: "Maybe I'm _too_ deep down this rabbit hole, should find a way back out..."
comment in response to
post
A whole lot of flying by the seat of one's pants back in the day.
comment in response to
post
Thanks for mentioning the MAX, it doesn't get nearly enough credit. I mentioned it (as the "Ultimax") in my Big Thread on the history of the 1541 recently: bsky.app/profile/imra...
comment in response to
post
It's a bridge account from here to Mastodon and the rest of the Fediverse, as they run on a different protocol over there.
comment in response to
post
I live on the Transpennine line, so obviously an upgrade to Manc Piccadilly would be nice. But if you can get Nottingham-York to go from two hours to 35 minutes, and for cheaper:
Screw it, do that instead, and reap the benefits sooner.
comment in response to
post
Oh, it's _over_ over for Assad.
comment in response to
post
#Alt4You
Illustration of a house of cards. At the top stands a person and their house, the person saying "Who cares if species go extinct?" The set of cards below show an apple, cow, pepper, ear of wheat; below that are insects and worms; and lower still are smaller insects.
comment in response to
post
Can IT give you a Yubikey or something that stays on your keychain, perhaps?
comment in response to
post
Crazy response on that post, goodness.
comment in response to
post
(Postscript: I bought a copy of the C64 Programmer's Reference at a yard sale when I was 12, and called the number on the back from a payphone. I was told that the number didn't go to Commodore any more, and that's how I learned they were no longer a going concern. Devastated.) 101/100
comment in response to
post
If anyone ever asks you "Why was the C64's disk drive so slow?", now you'll have an answer. A full list of sources for this tale is in the alt text; do drop me a note if you have any questions about the (even) finer technical details. Merry Christmas. 100/100
comment in response to
post
And then a patent troll sued over the use of mouse cursors in the Amiga, and incredibly, Commodore lost. That was 1993, they refused to pay up, and were banned from selling in the US; Commodore shut their doors in April of 1994, but the C64's sales record stands to this day. 99/
comment in response to
post
But profits didn't rebound by enough for Irving Gould, main investor in Commodore, to be happy; he fired the CEO, laid off half the staff, and directed work back to 8-bit machines. Only one of these ever saw the light of day: a 1991 rework of the C64 in a slimline Amiga-style case. 98/
comment in response to
post
Commodore's last gasp effort was to buy Amiga and develop their prototype 16-bit machine into the Amiga 1000, but even that faltered as Commodore demanded it be treated as a Serious Business Machine; it took until 1987 before the A500 was sold as a 16-bit home machine, and profits returned. 97/
comment in response to
post
The Plus-4 and 264 home machines with low prices and low specs to match performed badly; a new series of PET-derived 8-bit business computers didn't sell as the IBM PC and its clones started eating the business market; Tramiel went on to head Atari and release the ST line of 16-bits. 96/
comment in response to
post
And whatever happened to Commodore? Well, Jack Tramiel stepped down after the success of the C64, and he was very much in the mould of Steve Jobs: a driver of high concept. Without Tramiel, Commodore started to pull in multiple directions at once... 95/
comment in response to
post
Did this affect sales of the C64? Eh, not really. Being heavily advertised to the home market as a successor to the VIC-20, users were willing to wait a little while for their games to load, and even 400 bytes per second was better than the interminable wait for tapes to load. 94/
comment in response to
post
And there we have it: with the change from 19μs/bit to 60μs, we find the effective speed of the C64 and its disk drive comes out to 400 bytes per second. That leaves us with only a couple of questions... 93/
comment in response to
post
The final solution that Commodore landed on was to delay the C64 end of the serial bus so it sent a bit every 60μs, to be sure it wasn't catching a badline in its own CPU, and to leverage the serial bus's acknowledgement mechanism for any delays in reading data. 92/
comment in response to
post
Luckily, the serial bus is robust enough to handle this: it will hold a value on the data line until it's told by the other end that the value has been saved. If the CPU is locked out, the data stays there until it comes back from its short coma. 91/
comment in response to
post
If we take this same code and run it on the C64, it's going to miss bits: if it runs through every 19 cycles, but the CPU is occasionally locked out for 40 cycles, you can miss two or even sometimes three bits of data. 90/
comment in response to
post
If we count up the time taken by the instructions in the relevant section of this disassembly, we find it takes at least 19μs to read in a single bit from the serial bus; with the surrounding code, it can be more like 500μs to read a full byte, before the rest of the OS even sees it. 89/
comment in response to
post
Many people have done excellent work disassembling and annotating the VIC-20 ROM, and a complete set has been compiled by Lee Davison; the file is hosted by Matt Dawson here: www.mdawson.net/vic20chrome/... 88/
comment in response to
post
Let's detour real quick into what it means to camp on the data line: what is the CPU actually doing when it spins its wheels waiting for data to come in? To find out, we need to dig into the operating system that was burned into the VIC-20's ROM chips. 87/
comment in response to
post
Of course, this includes the serial bus's data line, so the CPU is locked out from camping on the serial bus 12.5% of the time during normal computer operation. This is often referred to as a "badline" condition, because the one in eight lines where this happens are the bad lines. 86/
comment in response to
post
By building an Address Enable Control line into both the VIC and the 6510 CPU, the VIC can steal access to memory by pulling the line from its default state of full voltage down to zero; when this happens, the 6510 puts its memory bus into high-impedance mode, which blocks any usage by the CPU. 85/
comment in response to
post
Fortunately, this problem was found before the hardware was finalised, so there was time for a hack: every eight lines, the VIC signals to the CPU that it's taking over the memory bus, and the CPU isn't allowed to do any work for 40 cycles. 84/