| ▲ | trollbridge 6 hours ago |
| Not to disrespect this, but it used to be entirely normal to have a GUI environment on a machine with 2MB of RAM and a 40MB disk. Or 128K of ram and 400 kb disk for that matter. |
|
| ▲ | maccard 6 hours ago | parent | next [-] |
| A single 1920x1080 framebuffer (which is a low resolution monitor in 2025 IMO) is 2MB. Add any compositing into the mix for multi window displays and it literally doesn’t fit in memory. |
| |
| ▲ | snek_case 5 hours ago | parent | next [-] | | I had a 386 PC with 4MB of RAM when I was a kid, and it ran Windows 3.1 with a GUI, but that also had a VGA display at 640x480, and only 16-bit color (4 bits per pixel). So 153,600 bytes for the frame buffer. | | | |
| ▲ | beagle3 an hour ago | parent | prev | next [-] | | The Amiga 500 had high res graphics (or high color graphics … but not on the same scanline), multitasking, 15 bit sound (with a lot of work - the hardware had 4 channels of 8 bit DACs but a 6-bit volume, so …) In 1985, and with 512K of RAM. It was very usable for work. | | |
| ▲ | mrits 39 minutes ago | parent [-] | | a 320x200 6bit color depth wasn't exactly a pleasure to use. I think the games could double the res in certain mode (was it called 13h?) | | |
| ▲ | krige 16 minutes ago | parent [-] | | For OCS/ECS hardware 2bit HiRes - 640x256 or 640x200 depending on region - was default resolution for OS, and you could add interlacing or up color depth to 3 and 4 bit at cost of response lag; starting with OS2.0 the resolution setting was basically limited by chip memory and what your output device could actually display. I got my 1200 to display crisp 1440x550 on my LCD by just sliding screen parameters to max on default display driver. Games used either 320h or 640h resolutions, 4 bit or fake 5 bit known as HalfBrite, because it was basically 4 bit with the other 16 colors being same but half brightness. The fabled 12-bit HAM mode was also used, even in some games, even for interactive content, but it wasn't too often. |
|
| |
| ▲ | bobmcnamara 4 hours ago | parent | prev | next [-] | | It's so much fun working with systems with more pixels than ram though. Manually interleaving interrupts. What joy. | |
| ▲ | echoangle 6 hours ago | parent | prev | next [-] | | Do you really need the framebuffer in RAM? Wouldn't that be entirely in the GPU RAM? | | |
| ▲ | jerrythegerbil 5 hours ago | parent | next [-] | | To put it in GPU RAM, you need GPU drivers. For example, NVIDIA GPU drivers are typically around 800M-1.5G. That math actually goes wildly in the opposite direction for an optimization argument. | | |
| ▲ | jsheard 5 hours ago | parent | next [-] | | Doesn't the UEFI firmware map a GPU framebuffer into the main address space "for free" so you can easily poke raw pixels over the bus? Then again the UEFI FB is only single-buffered, so if you rely on that in lieu of full-fat GPU drivers then you'd probably want to layer some CPU framebuffers on top anyway. | | | |
| ▲ | Rohansi 5 hours ago | parent | prev | next [-] | | > NVIDIA GPU drivers are typically around 800M-1.5G. They also pack in a lot of game-specific optimizations for whatever reason. Could likely be a lot smaller without those. | | |
| ▲ | monocasa 5 hours ago | parent [-] | | Even the open source drivers without those hacks are massive. Each type of card has its own almost 100MB of firmware that runs on the card on Nvidia. | | |
| ▲ | jsheard 4 hours ago | parent [-] | | That's 100MB of RISC-V code, believe it or not, despite Nvidias ARM fixation. |
|
| |
| ▲ | hinkley 2 hours ago | parent | prev [-] | | Someone last winter was asking for help with large docker images and it came about that it was for AI pipelines. The vast majority of the image was Nvidia binaries. That was wild. Horrifying, really. WTF is going on over there? |
| |
| ▲ | maccard 4 hours ago | parent | prev | next [-] | | You’re assuming a discrete GPU with separate VRAM, and only supporting hardware accelerated rendering. If you have that you almost certainly have more than 2MB of ram | |
| ▲ | 4 hours ago | parent | prev | next [-] | | [deleted] | |
| ▲ | znpy 6 hours ago | parent | prev | next [-] | | Aren’t you cheating by having additional ram dedicated for gpu use exclusively? :) | |
| ▲ | sigwinch 6 hours ago | parent | prev | next [-] | | VGA standard supports up to 256k | |
| ▲ | ErroneousBosh 4 hours ago | parent | prev [-] | | Computers didn't used to have GPUs back then when 150kB was a significant amount of graphics memory. |
| |
| ▲ | ohhellnawman 6 hours ago | parent | prev [-] | | [dead] |
|
|
| ▲ | forinti 5 hours ago | parent | prev | next [-] |
| The Acorn Archimedes had the whole OS on a 512KB ROM. That said, OSs came with a lot less stuff then. |
| |
| ▲ | xyzzy3000 4 hours ago | parent | next [-] | | That's only RISC OS 2 though. RISC OS 3 was 2MB, and even 3.7 didn't have everything in ROM as Acorn had introduced the !Boot directory for softloading a large amount of 'stuff' at boot time. | |
| ▲ | psychoslave 5 hours ago | parent | prev [-] | | If that is a lot less of things not needed for the specific use case, that is still a big plus. | | |
| ▲ | pastage 5 hours ago | parent [-] | | It was GUI defined manually by pixel coordinates, having more flexible guis that could autoscale and other snazy things made things really "slow" back then.. Sure we could go back... Maybe we should. But there are lots of stuff we take for granted to day that were not available back then. | | |
| ▲ | xyzzy3000 an hour ago | parent | next [-] | | RISC OS has the concept of "OS units" which don't map directly onto pixels 1:1, and it was possible to fiddle with the ratio on the RiscPC from 1994 onwards, giving reasonably-scaled windows and icons in high-resolution modes such as 1080p. It's hinted at in this tutorial, but you'd have to go through the Programmer's Reference Manual for the full details:
https://www.stevefryatt.org.uk/risc-os/wimp-prog/window-theo... RISC OS 3.5 (1994) was still 2MB in size, supplied on ROM. | |
| ▲ | masfuerte 4 hours ago | parent | prev [-] | | The OS did ship with bezier vector font support. AFAIK it was the first GUI to do so. P.S. I should probably mention that there wasn't room in the ROM for the vector fonts; these needed to be loaded from some other medium. |
|
|
|
|
| ▲ | Perz1val 6 hours ago | parent | prev | next [-] |
| Yea, but those platforms were not 64bit |
| |
| ▲ | monocasa 5 hours ago | parent [-] | | 64 bit generally adds about 20% to the size of the executables and programs as t to last on x86, so it's not that big of a change. |
|
|
| ▲ | taylodl 5 hours ago | parent | prev | next [-] |
| When I first started using QNX back in 1987/88 it was distributed on a couple of 1.4MB floppy diskettes! And you could install a graphical desktop that was a 40KB distribution! |
|
| ▲ | 1vuio0pswjnm7 5 hours ago | parent | prev | next [-] |
| I would like to have this again I prefer to use additional RAM and disk for data not code |
| |
| ▲ | oso2k 2 hours ago | parent | next [-] | | There’s an installation option to run apps off disk. It’s called “The Mount Mode of Operation: TCE/Install”. | |
| ▲ | beng-nl 5 hours ago | parent | prev [-] | | To think that the entire distro would fit in a reasonable LLC (last level cache).. | | |
| ▲ | bobmcnamara 4 hours ago | parent | next [-] | | I've been wondering if I could pull the DIMM from a running machine if everything was cached. Probably not due to DMA buffers. Maybe a headless machine. But would be funny to see. | |
| ▲ | veqq 2 hours ago | parent | prev [-] | | Like the k language! |
|
|
|
| ▲ | croes 4 hours ago | parent | prev | next [-] |
| With 320x240 pixels and 256 colors |
|
| ▲ | nilamo 4 hours ago | parent | prev | next [-] |
| "640k ought to be enough for everyone!" |
|
| ▲ | embedding-shape 6 hours ago | parent | prev [-] |
| > Or 128K of ram and 400 kb disk for that matter. Or 32K of RAM and 64KB disk for that matter. What's your point? That the industry and what's commonly available gets bigger? |