Hidden Files in C64 OS | Hacker News Reader

Hidden Files in C64 OS

c64os.com

96 pointsingve25 comments

Freshman year of high school I took a class called "Business Computer Applications". It was 1983 and I was 13. We were using Apple II+ computers or their clones. I had an Apple II+ since they came out and knew lots of things by then. I "wowed" my teacher with 3 line programs and such. On our classroom floppy I had a file with a control character in it's name, it was a disk editor. Knowing the disk directory layout things (it was a linked list of blocks), I carved out a whole hidden set of directory entries. So each day of class I would load up the disk editor using the invisible control characters, patch back in my hidden blocks, play with my hidden files, then at the end of class I'd load the disk editor up again and hide my files. Teacher never saw what was really on that disk.

>classroom floppy

Wow

It's inspiring to watch people work on dead tech with such enthusiasm and energy. I'd love someone to do an AMA and explain how they manage their focus and enthusiasm to keep working on such tech

It's not "dead", it's "mature", "stable", or "known". You can build on it and focus on what you want to do without worrying that the foundation will be pulled out from under you.

Because it is fun. It is challenging, and interesting. And nostalgic.

Don't have a soul sucking job. Don't have kids. Or a relationship. Endless potential focus. But not everyone has a razor sharp passion.

The author has children. And a wife. https://www.c64os.com/legal/thanks-and-credits/

No wonder they're in his credits.

"Thank you for putting up with all my late nights programming, and all the money I've spent on old computers."

Sort of just co-exists with my point rather than refute it.

I see your argument in the sense that having kids and a relationship are a lot of work but they're also an inspiration. I have two children and I can say yes, you can still be a creative fulfilled individual. But it's not as easy with the extra responsibility. And one has to be more focused.

One way to gauge when I started in computing is that figures like https://s3.amazonaws.com/com.c64os.resources/weblog/hiddenfi... were what our textbook authors felt was really important for us to know, yet I have spent more than 3 decades since with absolutely no need to care about physical disk layout (the closest I ever got was video editing in the early 90s).

At some point Widlar's "Every idiot can count to one" stopped being pejorative and was wholeheartedly embraced by the entire industry.

Has anyone attempted to do a timeline of computing by "what no longer matters" in each decade?

> Civilisation advances by extending the number of important operations which we can perform without thinking of them. —ANW

I think mechanical sympathy is still useful, even in a world of 'plenty'.. it's people with that kind of understanding who are able to get current day computers to do things that others will have to wait until tomorrow to achieve.

When I was streaming audio and video in PlayStation 2 games, I had to care a lot about physical disk layout. But, even then it boiled down to: Seek times are huge, sector and cluster sizes are your atomic ops under the hood, inner rings are low-bandwidth-low-variance, outer rings are high-bandwidth-high-variance.

Since then, not so much.

These days with NVMe drives, things are much easier. But, there are still things to keep in mind. I haven't dug deep. But, my impression is: Even though 4K random reads are incredibly faster than they used to be, large (256K-2MB) reads are yet faster still. Maxing out modern drives requires having multiple requests in flight. So, multiple threads or async operations. Modern drives are so fast that the memory copies involved in buffered fread() can add 33ish% overhead. Consider memory-mapped read-only files. Even better: If you have millions of users, you need 1-in-a-million reliability. Consider SQLite or LMDB as alternatives to fwrite().

I completely forgot about that. I never directly worked on the audio side but I did hear a little from others and the relief that came with the Xbox and caching audio on the HDD. It essentially cut-down on a lot of those issues. And by the next generation, it was only the Wii that you still had to kind of worry about that stuff.

With spinning drives, there was an art to partitioning, where you would lay out your partitions to give some ideal spots on the disk. It probably did not really matter that much. but some people swore that putting your swap partition first was critical to having any sort of performance.

There's something to be said for learning the various effects virtualization layers can have, even if they're not affecting you today.

Something similar will happen again at another level.

I feel like schools have gotten a lot better about this over the years. Of course students are taught to walk using the rudimentary components when they are learning to program.

We had to write a B-tree implementation in Java when I was in school. I have used that knowledge exactly zero times. But I am betting algorithms are still important.

Yeah I got my undergrad CS degree (a good mix of theory and practice) about 20 years ago and I can't think of much that's truly outdated. I certainly don't use Java or MIPS32 assembly or Solaris these days, but that wasn't really the point of those classes.

Even with truly obsolete stuff like the details of hard drive technology, there's something valuable to be learned in examining how people solved problems at the time with the tools they had.

The B-tree has at least two lessons, independently of whether you ever re-implement one: (a) using trees instead of flat search gains an O(log n) over O(n) algorithmic factor, and (b) using chunky flat elements sized to the bandwidth-delay product of storage results in significant wall-clock (constant factor?) gains.

I fail to see how CHS provides equivalently valuable lessons? https://news.ycombinator.com/item?id=39826433

The principle still matters. Learning how underlying storage works helps optimize data layout, write and read for speed.

It’s just that storage has changed. Caches may be important now for instance

It has changed such that the "traditional" CHS order hasn't been the physical layout of HDDs for probably at least two decades now. Not long ago I posted an article with more details of that: https://news.ycombinator.com/item?id=39428728

I was thinking the lesson from CHS->LBA could be equally well drawn, without bringing in obsolete tech, by exercises involving H:M:S->S or perhaps even D.M.Y->Julian Day.

Fantastic write-up. I wish the documentation for all systems was this good.

I find it fascinating that the drive hardware manages the filesystem. When did it become that the OS software managed the filesystem, and in the end, which is better?

This was unique to Commodore. They owned MOS which made the chips so it was not as costly for them to do this. Honestly it sucked longer term because there was no way to really upgrade how the filesystem DOS worked unlike on the Apple or the Atari.

It was cool however because there were tools that offloaded things to the drive CPU. You could also write programs for copying disk that you loaded into the RAM on the drive and then disconnected them from the computer. You used the drive lights to tell you when to swap the disk.

When did it become that the OS software managed the filesystem

I think among early computers the C64 drive was somewhat of an exception; in some ways it's more like a NAS than a block device.

Reply on news.ycombinator.com