81–90 of 199 posts
Apparently this person is referring to the available ram on a Commodore 64. The media (data) on disk or tape was much more than that.
Not much more. It all fits on a single side of a 1541 floppy. Even considering compression it couldn't be more than a couple hundred kilobytes. https://csdb.dk/release/?id=99145
I have got 1.1 GB of MP3s with just remixes of the music from the three games, some of which are from a Kickstarter from the composer for the second.
I grew up with and absolutely adore The Last Ninja series. I'm not going to comment on the size thing because it's so trite. Instead - here's [0] Ben Daglish (on flute) performing "Wastelands" together with the Norwegian C64/Amiga tribute band FastLoaders. He unfortunately passed away in 2018, just 52 years old. If that tickled your fancy, here's [1] a full concert with them where they perform all songs from The Last…
Earlier quoted context omitted.
Most software doesn’t consume multiple gigabytes of memory outside of games and web browsers. And it should be obvious why games and web browsers do.
Unfortunately "most software" might be a web browser these days.
And as I said elsewhere, I do consider Electron to be bloat.
But it’s also worth discussing Electron as an entirely separate topic because it’s a huge jump in memory requirements from even “bloated” native apps.
This I think is a core part of the problem when discussing sizes from C64 era to modern applications:
1. You have modern native apps vs Electron
2. Encryption vs plain text
3. High resolution media vs low resolution graphics and audio
4. Assembly vs high level runtimes
5. static vs dynamically linked libraries
6. Safety harnesses vs unsafe code
7. Expected features like network connectivity vs an era when that wouldn’t be a requirement
8. Code that needs to be supported for years of updates by a team of developers vs a one man code base that never gets looked at again after the cassettes get shipped to retail stores.
…and so on.
Each of these individually can contribute massively to differences in file sizes and memory footprints. And yet we are not defining those parameters in this discussion so we are each imagining a different context in our argument.
And then you have other variables like:
1. Which is large? 5 GB is big by today’s standards but even 5 MB would have been unimaginable by C64 standards and that is 4 orders of magnitude smaller. One commenter even discussed 250 GB as “big” which is unimaginable by today’s standard users.
2. Are we talking about disk space or RAM? One commenter discussed using GBs of GPU memory as a way to save sure memory but that feels like a cop out to me because it’s still GBs of system resources that the C64 used.
3. Software Complexity: it takes a lot more effort to release software these days because you work as a team, and need to adhere to security best practices. And we still see plenty of occasions where people get that wrong. So it makes sense that people will use general purpose libraries instead of building everything from scratch to reduce the footprint. Particularly when developers are expensive and projects have (and always have had) deadlines that need to be met. So do we factor in developer efficiency into our equation or not?
In short, this is such a fuzzy topic that I bet everyone is arguing a similar point but from a different context.
Earlier quoted context omitted.
DES wasn’t common place though (or at least not on the mainframes I worked on). But maybe than says more about the places I worked early on in my career? Also DES is trivial to crack because it has a short key length. Longer keys require more compute power and thus the system requirements to handle encryption increase as the hardware to decrypt becomes more powerful.
The box size at IBM was larger before standardisation. DES is trivial to break, because of NSA involvement in weakening all the corners. [0] > In the development of the DES, NSA convinced IBM that a reduced key size was sufficient; Minitel used DES, and other security layers, and was in use for credit cards, hospitals, and a bunch of other places. The "French web" very nearly succeeded, and did have these things in '…
I worked for one payroll mainframe in the 80s that didn’t have DES. So it wasn’t quite as ubiquitous as you might think. But it does still sound like it was vastly more widespread than I realised too.
Earlier quoted context omitted.
BASIC was slow in the 80s. Games for the C64 (and similar machines) were written in machine code. > By comparison, giving how they optimized the games for 8 and 16 bit machines I should have been able to compile Cataclysm DDA:BN under my potato netbook and yet it needs GIGABYTES of RAM to compile, it crazy that you need damn swap for something it required far less RAM 15 years ago for the same features. That’s not cr…
Compare Limbo+Tk under Inferno with current C#/Java. Or C++ against Plan9C. We have impressive CPU's running really crappy software. Remember Claude Code asking 66GB for a damn CLI AI agent for something NetBSD under a Vax (real or physical) from 1978 could do with NCurses in miliseconds every time you spawn Nethack or any other NCurses tool/game. On speed, Forth for the ACE was faster than Basic running under the ZX…
> On speed, Forth for the ACE was faster than Basic running under the ZX80. So, it wasn't about using a text-parsed language.
Forth and BASIC are completely different languages and you’re arguing a different point to the one I made too.
Also I don’t see much value in hypothetical arguments like “if Forth won instead of BASIC” because it didn’t and thus we are talking about actual systems people owned.
I mean, I could list a plethora of technologies I’d have preferred to dominate: Pascal and LISP being two big examples. But the C64 wasn’t a lisp machine and people aren’t writing modern software in Pascal. So they’re completely moot to the conversation.
Most of my games are roughly in that range though. I think my MMO was 32KB, and it had a sound effects generator and speech synth in it. (Jsfxr and SAM)
I built it in a few days for a game jam.
I'm not trying to brag, I'm trying to say this stuff is easy if you actually care. Just look at JS13K. Every game there is 13KB or below, and there's some real masterpieces there. (My game was just squares, but I've seen games with whole custom animation systems in them.)
Once you learn how, it's pretty easy. But you'll never learn if you don't care.
You have to care because there's nothing forcing you. Arguably The Last Ninja would have been a lot more than 40KB if there weren't the hardware limitations of the time.
They weren't trying to make it 40KB, they were just trying to make a game.
In my case, I enjoy the challenge! (Also I like it when things load instantly :)
I think I'll make a PS1 game next. I was inspired by this guy who made a Minecraft clone for Playstation:
https://youtu.be/aXoI3CdlNQc?is=sDNnrGbQGJt_qnV6
P.S. most Flash games were only a few kilobytes, if you remove the music!