Hacker News new | ask | show | jobs
by jerf 1150 days ago
Hello! Thank you for starting me up! I'm the Kermit protocol and I'm happy to hel... wait, you want to transfer what file? What the hell is a gigabyte? Well, man, OK, you're the user so you know best, but man, this is going to take like, days man, settle in, here we gooo

ooooooo whooooooo OOOOOOOOO AAAAAAAAAAAAAAA !!!!!!!!!!1!! qcjqrjrcorRC!!!

WHAT THE HECK WAS THAT? Did I just do megabytes per second? Holy shit. Am I high or something? What is this hardware? What is going on here?

No... wait... is that the end? Am I done here? No! No, I want to transfer more! More! Megabytes per second! Gigabytes per second! I can see it now, I want it, I want more, please, let's transfer another file, come on man, I want to ride again, please ple

    EXECUTION COMPLETED
    $
2 comments

My Commodore 64 has a USB interface nowadays (and a few replaced caps). Originally it only had a tape "drive" ie cassette. After a few years we got a 1541 floppy disc unit. Tick, tick tick, whiirrrrrrrr (think: trilled r on speed), fut (etc). Instead of 10-15 mins to load a game it loaded in a fair few seconds. Bear in mind that the 64 refers to 64 kilobytes.

  $ ls -lh /usr/bin/cp
  -rwxr-xr-x 1 root root 123K Apr  3 19:00 /usr/bin/cp
The copy command on this laptop is 123Kb! ls is 135K. Elite on the C-64 has filled 3D polygonal space ships, space stations and stuff, a whopper of a galaxy and a HUD that gives you an excellent idea of what is where in 3D. You get a trading system and ship upgrades etc. Oh and music - The Blue Danube should play when one is docking with a space station. Obviously you'll need a driver for the joystick and keyboard too. You don't get the whole 64Kb to play with either - a fair bit of that is used by the system itself.

Before the C64 I used a ZX81 and before that a ZX80 - they had roughly 1 kilobyte of RAM. The ZX81 had a RAM pack upgrade which added 16Kb. It was a bit wobbly and required a strip of Bluetac to stop it crashing the computer when nudged. An uncle of mine calls "bloody luxury" on that - he learned programming with punched cards - probably ForTran.

This laptop's kernel is 12M and initramfs is 14M and a fallback image of 70M. Add to that a microcode image (7M).

You'll be glad to hear that Kermit weighs in at a svelte 26K (I've just installed it from the Arch AUR)

It's not that the programs are getting bigger. It's just that the bytes are getting smaller.
A byte just doesn’t go as far these days as it used to.
Elite on the C64 did not have filled polygons. It had hidden line removal. Still impressive.

Funny part about Elite is that they supposedly limited the number of galaxies to maintain the illusion that it was manually created instead of built at runtime using a pseudo random number generator with a preselected seed.

"Elite on the C64 did not have filled polygons."

You are correct - I was conflating it with the later PC effort. When you get to my age (etc).

Sadly, nowadays the plain text of the legalese bollocks that you don't even realise you've signed up to is larger than entire games of yesteryear.

What's in that initrd. Surely busybox doesn't take up 14M.
I've just discovered zstd! The cpio archive is 34M.

Busybox is 521K and udevadm is 572K. ext4.ko is 2.4M and libsystemd-shared-253.3-3.so is 3.5M. usr/lib has quite a lot of file in it eg libc.so.6 at 1.9M.

just the "cp --help" is around 5k (uncompressed)
Thanks for the laugh (but also kind of serious) - reminds me of https://xkcd.com/2221/ (what a fast floppy drive you have!)
A few decades from now we’ll start seeing interactive AIs on emulated platforms asking about president Jon Stewart and other 2030s trivia.
Now I'm wondering if there's ever been emulated software that crashed because it tried to calculate a data transfer rate, but the emulator transferred the data faster than the delta in the time measuring in the emulated machine, so it divided by zero.
The original Macintosh ROM does some floppy drive calibration routines on startup to measure jitter in the spin rate. A common source of errors when writing a Macintosh emulator is emulating a "perfect" floppy drive. If the spin rate jitter is zero, the ROM attempts to a divide by zero and crashes.
There's a bug like this in all versions of Windows 95, the original release of Windows 98, and all of the Nashville/Memphis beta releases in between: https://web.archive.org/web/20030819124031/https://support.m...

“The timing calibration code in the Network Driver Interface Specification (NDIS) driver causes a divide by zero if the CPU runs at 2.2 GHz or faster. This problem does not occur with CPUs that run at 2.1 GHz or slower.”

It was patched for Windows 98 (312108USA8.EXE), but '95 was left without an official fix due to its age: http://lonecrusader.x10host.com/fix95cpu.html

Well, certainly a lot of people running older software have had the joy of their disk size being larger than the software can handle. There's plenty of software that expects the disk size in bytes to fit into an signed or unsigned 32-bit int.

I also don't know about data transfer rates but if you want to emulate the really old stuff in DOSBox, you'll need to carefully examine pages like https://www.dosbox.com/wiki/Performance because there are plenty of games that do a divide-by-zero crash when they're trying to time the CPU for running at the desired speed.

Emulated or not, old Turbo Pascal programs would crash on any computer faster than about 200MHz. The initialization code for the CRT module would try to calibrate timing for the Delay function and the division would overflow if the processor was too fast. See https://retrocomputing.stackexchange.com/questions/12111/
Not emulated as such, but I seem to remember certain old computers having problems with compact flash adapters replacing the hard drive because they were too fast.