Ya, but those worked. Wasn't it originally called Disk Doubler (think it might have changed names when MS purchased it).

I remember finding a bug in it that took forever to figure out. You had to install windows 3.1 before enabling it or it would fail to read one of the floppies.

Took me a LONG time to figure that one out....

Time is a flat circle

Is this like Ram-Rod?

I remember this trash:

I remember an old DOS utility called Ram Doubler. Sadly it also halved the speed.

this one was one of the bullshit ones. iirc, underneath it just made your swap bigger

they ain't doing it for us, they're doing it for themselves.

Yeah It looks like someone posted a picture of the old floppy disk.

Honestly though CPU processing is going to add almost no latency at all.

Almost all latency is sending to the RAM itself, so if you can compress it in a CPU cache before sending it, its nearly free RAM space.

Also systems are fucked fast these days you could probably make something responsive in pure python - other than millisecond timing scenarios like medical and audio stuff

Yeah wait how would you have read only RAM?

Loaded on boot for the OS I suppose?

Probably nice for running TV boxes off even less RAM than they're already starved for lmao

With great speed comes great accuracy and endurance?

Could already do that with zram!

There's at least one game I definitely know which benefits from zram, and will probably also benefit from cram.

If you run star citizen on a 32gb or lower linux system you'll need to enable zram, otherwise the game will grind to a halt. Setting zram to 0.5*ram it ends up being playable. I had to go that route before I changed to 64gb physical ram.

Zram compression isn't that bad, I don't mind a faster method tho :)

CRAM is an utterly goated name

Compressed CRAM

And this isn't the only cool thing to have it

This idea comes out of the woodwork ever time RAM gets expensive.

Why does it look like a heatmap of someone stroking their giant dick?

I feel like ZRAM showed up when prices were historically low

Compressed CCRAM

I can carry nearly 80 gigs of data in my head. One sixty if l use a doubler.

Ah, the old download more RAM trick. An oldie but a goodie.

Pshaw! Who needs zram when you could use RAM Doubler(tm)?

Aaaeh ya know, just use some lube or wd40 and cram it in there.

meh needs special hardware

Too bad, this isn't happening as a kernel patch.
Adding to that point:

The key detail is that CRAM is a hardware implementation of compression, meaning the logic is in the memory controller rather than in software, so it's not a pure software trick like ZRAM. However, it uses standard off-the-shelf DRAM and a normal memory bus, so no exotic modules or custom interfaces are required.

Guess read only RAM becomes... ROM? :D I have no clue either. Maybe there are protected areas in the memory no program has write access to, so it is read only from perspective of the application. Searching the web doesn't help, because every link I clicked just explains the difference between ROM and RAM.

Hmm... when I think about Rust programming (which is true in C too probably), there are two types of locations our variables can assigned to: Stack and Heap. In example if you have a text string as a literal like "Version 1.0", that string is located in the Stack memory, because it is unchanging. The Heap gets all those content that can vary and arbitrary long, but its slower. So the Stack content is much smaller, faster and basically read only RAM area (if I understand this correctly). Maybe that is it?

Neat

I'm drawing on some old memories here, so I could be mistaken, but I don't think the stack is read only, not in C anyway or in the underlying machine code. If it is faster it has to do with greater overhead needed managing the larger heap and perhaps being more efficient to push and pop with small offsets to a local stack frame vs large absolute addresses.

but I don’t think the stack is read only

I don't mean the stack is read only (edit: yes I meant that in my previous reply, but got confused myself, I actually never thought the entire stack being read only, I was only thinking about those specific variables and literal strings, sorry for confusion), but certain variables holding values that are only used to read and not change. In example you cannot change literals, therefore they are read only values. In example if you have a program that prints "Hello Lemmy", that string is a literal that cannot be altered, and it is found in the application itself, as part of the binary. That part maybe is marked as read only?

There is no mention of any extra hardware here though. The article even suggests this to benefit existing hardware like the steam deck.

In another comment, I posted a link to the CRAM presentation that mentioned a chip.

This article also mentions some hardware:

Because CRAM is stored in RAM and treated as RAM, with full cacheline/byte access, it can be accessed in a read-only fashion with little delay; just the cost of hardware-offloaded compression.

I don't think it would say that if they meant the CPU was doing the compression.

Ah I see. It might not be a requirement though. In the case that the numbers are given with hardware offloaded compression it might just be slower when running on CPU. But I guess time will tell.

Right, a stack that was itself read-only would be hard to use! :^D
C definitely lets you modify the things in the stack. (Ah the fun of bugs where you accidentally overwrite other shit on the stack!) I don't know Rust, but it would not surprise me if Rust only had immutable things on the stack.

No, its not only immutable things on the stack. I mean if you include a literal constant string such as "MIT LICENSE", that is part of the compiled binary file. So it is unchangeable. Because you cannot change a literal, a "1" is always a "1" in the compiled binary file. And those are basically read only by their nature and loaded into the stack. I think or guess in C it is the same. Or any language for that matter.

I started to think I was hallucinating. I guess what I was thinking is this part https://en.wikipedia.org/wiki/Data_segment . There are read-only data segments too.

Isn't it just ZRAM but with a C?

Allocating all memory as CRAM is also a nice idea since reads are at regular speed. It's just writes that take a 20% longer for a nice memory expansion.