On 5/3/2022 4:34 AM, Thomas Koenig wrote:
> BGB <cr88192@gmail.com> schrieb:
>
>> Well, that and it answers another mystery: "How could you have fit Unix
>> onto computers with only a few K of RAM?..." Apparently, they didn't,
>> they (somehow) had access to machines in the 70s with MB of RAM.
>
> This turns out not to be the case.
>
> The PDP-11 they started serious UNIX development on had 24 kB of
> memory and a half-megabyte disk.
>
> Source: UNIX: A History and a Memoir, Brian Kernighan, page 52.

OK, this turns it back into being a mystery how it could fit...

When I was trying to gather information, looking up PDP-11 was turning
up things like PDP-11 processor boards for an S-100 backplane with 2 MB
of RAM and similar.

Though, looking some more, I am guessing it is likely this was newer
technology or something... (Apparently both the S-100 backplane and DEC
J-11 processor/chipset were 1980s era technology).

In my case, I have a 32K ROM, of which I manage to fit all of:
A FAT16/FAT32 driver;
A PE/COFF loader;
An LZ4 and RP2 decoder;
Some processor sanity-test code.

How one could fit an OS kernel and still have enough usable space to run
programs into 24K of RAM seems like a mystery.

To make stuff fit, I had to make some compromises, like IIRC, the ROM
version of the FAT driver leaves out stuff like ability to create or
modify files, and also leaves out things like LFN support (so, eg, the
boot image is limited to an 8.3 name).

Granted, it is possible things could be shaved down some more (could
maybe omit things like VFS mount-points or support for directories,
since these are mostly N/A to the boot loader, which assumes the boot
image to be in the root directory).

It is possible that I could eliminate the use of the hardware font-ROM
by having the boot-loader, switch to using 8x8 pixel bitmap color cells
(like what TestKern currently does).

Font ROM would either be replaced with Font-RAM, or potentially this
could be eliminated entirely.

Though, Font RAM still has a few potential use-cases.

This would likely save some LUTs and BRAMs, but would require the Boot
ROM to store an additional 768 bytes for the font bitmap (assuming
20..7F are present).

Not sure of a good way to compact the font further:
A, Using a "7-segment" font, which could reduce storage cost somewhat;
Glyphs would be represented as 1 byte each.
B, Omitting part of the ASCII space:
Say, only having 21..5F, remapping 60..7F to 40..4F
Would save ~ 256 bytes but lose lower case letters.
C, Redraw glyphs as 5x6 pixels (needs 30b vs 64)

Both A and C would require an "unpacking" stage (to convert back to the
8x8 layout for display).

....

Had also had thoughts before that maybe one could do old-style
platformers by effectively using the color-cell display as a background
scene, then using screen offset registers to scroll the scene.

Possibly, the screen area, rather than being 80x25, could be expanded
96x32 or similar (with 80x25 visible), allowing for some off-screen
scratch area.

Or, could use the 80x50 mode (640x400 pixels), or 40x25 mode (320x200).

Had previously added a (mostly unused thus far) feature for hardware
sprites.

One other random idea would be, what if there were per-row offsets
(added to the master offset for each 8-pixel row of color-cells)? ...

Had also considered ideas to allow 2 layers of character cells, but this
would add some amount of "technical challenge" (would likely require
multiple ports into the VRAM; most likely splitting the VRAM into two
128-bit planes, each holding an 8x8x1b color cell and a pair of RGB555
endpoints and similar).

Well, all this as opposed to just using the 320x200 16bpp hi-color mode.
Though, if drawing into an off-screen buffer, and copying this to VRAM
each frame, a fair chunk of the total CPU time goes mostly into the code
for copying the off-screen bitmap into VRAM.

From stuff I heard, I guess a lot of 70s era CRT graphics were mostly
"racing the beam" style, with people configuring the contents of the
video registers ahead of the raster beam (say, copying a row of text at
a time from RAM into internal display memory whenever the raster beam
hits the next row).

Not sure if anyone was using CRT displays or doing graphics programming
on the PDP's, not heard much of this (most stuff I read was implying
that they were mostly using TTY terminals connected over a serial
interface or similar).

Then again, it is possible the "racing the beam to update a row of
character cells" stuff was mostly happening in the TTY terminal or similar.

....

As noted, I wasn't there, pretty much my whole life has been in the era
of x86 desktop PCs and similar. As noted, my first (semi successful)
forays into graphics programming what when I was in high-school, mostly
using OpenGL and similar (with the great migration from raster graphics
to 3D acceleration having happened a few years earlier).

(Well, games that were around during high-school were mostly things like
Quake 3, Half-Life, ...). IIRC, games like Quake 1/2 and similar came
around when I was in elementary school. Portal and similar didn't come
out until I was taking college classes.

In my early years, I played Wolf3D and Doom and similar as well (*1),
and partly found them interesting because the source was available
(though, when I was at that age, I couldn't make much sense of the
Wolf3D or Doom source, so my C programming journey mostly got going with
prodding around with the Quake and GLQuake source, and mostly just
breaking stuff at the time...).

*1: Mostly because Quake was pretty much unplayable on a 486 DX2-66,
which is what I had access to at the time. Doom and Wolf3D and similar
ran pretty good though. It was also running DOS + Windows 3.11, but
newer PCs were generally running Win9x. DOS + Win 3.11 was still pretty
common on school computers at the time (though, by high-school things
had mostly moved over to Win98 and occasionally WinXP).

In elementary school, I also had an 8088 which I got second-hand from a
relative (the 486 being my parents' computer at the time).

This relative had a Pentium, which (unlike the 486) could get playable
framerates in Quake. IIRC, they were also running Win9x.

I had a few relatives (mostly aunts and uncles; generally Gen-X) who had
Genesis and SNES and similar, and also my parents had a NES (the NES
existed before I did). Never really got much into console gaming though.

But, in my projects, I ended up taking some inspiration from these eras
of hardware (and the "clever hacks" people used to program it all, ...).

Though, in some areas, the "line of demarcation" between 1970s and 1980s
technology is a little fuzzy (a lot of the 1970s tech being "like 1980s
tech, just generally worse...").

Technically a world I had only ever seen through the lens of TV shows
and similar.

One can usually identify something is 70s aligned because the decade
mostly followed an "everything is brown" color scheme:
Brown or wood-grain finish, probably 70s;
Particularly if it has big/obvious buttons or toggle switches;
No LEDs on 70s tech;
Also TV cables used 2 parallel wires rather than coax;
These being connected using screw-terminals and spade connectors;
Presumably non-polarized;
...
Gray or Beige, 80s to 90s;
Smaller buttons, LEDs (red/yellow only for 80s);
No toggles, replaced with dual-state buttons;
Lots of molded plastic;
Coax and RCA connectors;
...
Black, mostly 2000s.
Blue or Purple LEDS show up here;
Also glowing 16-segment displays were popular;
2000s: Pointy molded plastic and internal LED glow appear;
...
2010s to present:
Still mostly black, replace constant-color glows with cycling RGB;
Lots more HDMI and similar.

I guess, further back:
60s: No real tech in the modern sense.
There were apparently cabinet-sized TVs, rotary phones, and record
players I guess;
Also people having overly elaborate hair-styles and bright-colored clothes.

Though, the bright-colored clothes thing returned in the late 80s /
early 90s for a while, albeit with more "funky molding" and big pointy
shoulders. The 80s "big hair" was more poofed and bleach-blonde, rather
than 60s where they would make it look like a big hair helmet or molded
shape or similar.

Older decades:
Pre-1900: N/A, no TV or movies;
1900s-1920s: Black and white, captions only.
1930s-1940s: Black and white, with sound;
Except "Wizard of Oz" being both color and 1930s.
1950s+: Usually color.

I guess at one point, there were also telephones that were a wooden box
with a hand-crank and similar, or:
Wooden box: 1800s ?
Rotary phone: ~ 1910s .. 1970s
Touch-tone phone: ~ 1970s .. 1990s.
Cordless phone: 1990s;
Flip-phone: roughly 2000s (*3);
Smartphone: 2010s .. present.

Sometimes seen in movies:
A giant brick phone and/or suitcase with a handset (roughly 70s).

*3: Though, I think I started seeing flip-phones around middle school.
Though, I think only some people had them.

I have a memory from this era of someone in one of my classes in middle
school having a flip phone with a small dangling plush toy of Kenny from
South Park tied onto it with a string.

....