eschaton posted:

it’s a decent platform for that, that’s what Andy Tanenbaum & crew did to make MINIX and another group did to create PC/IX

I’d suggest a DEC RT-11 or HP RTE or MPE clone just to be different, should be just as easy

or heck TOPS-10 or TOPS-20 since those had lots of fans

Gun Metal Cray posted:

oh man, I wish I had the time to spare to do something weird like this

what would be a good simulation setup to get started?

feedmegin posted:

Well, 16 bit data lines. Original 68k at an architectural level had a 32 bit address space but only ran out 24 address lines (limiting maximum addressable memory to 16 megabytes) - the top byte in an address would thus be ignored. This caused problems down the line when addressable memory was increased because people would use that top byte for stuff like type tags; a similar thing happened with early ARM, which is why modern 64 bit architectures that don't use all their theoretical address space specify exactly what the unused bits should be and fault if you put anything else in there.

Kazinsal posted:

SIMH is a good simulator for all sorts of vintage mainframes and minicomputers. PCem is pretty much the gold standard for reasonably accurately emulating vintage x86 machines through the 80s and into the early 90s

currently fighting with openwatcom to try to get it to actually link a 16-bit flat binary where I want it to but its linker script format is completely different than standard ld and frankly really loving sucks.

Gun Metal Cray posted:

I take it that openwatcom is the only viable option for doing a C targeting 8088/86 from a relatively modern system, right?

gonna check out PCem, cheers

Gun Metal Cray posted:

oh man, I wish I had the time to spare to do something weird like this

what would be a good simulation setup to get started?

DuckConference posted:

i think the pointer authentication stuff on arm uses the whole space

JawnV6 posted:

DEC teams survived long after the company itself went under, there were specific projects where decades later there was significant resistance to the intel way of doing things

idk how A20 looms in my head as a giant complication on everything ever, but it wouldn't surprise me if practitioners rarely had to gently caress with it

epitaph posted:

wasn’t NT developed by ex-DEC people? i remember one of the architects expressing particular scorn at unix for its i/o model (DEC had famously hitched their wagon to VMS)

JawnV6 posted:

DEC teams survived long after the company itself went under, there were specific projects where decades later there was significant resistance to the intel way of doing things

idk how A20 looms in my head as a giant complication on everything ever, but it wouldn't surprise me if practitioners rarely had to gently caress with it

epitaph posted:

wasn’t NT developed by ex-DEC people? i remember one of the architects expressing particular scorn at unix for its i/o model (DEC had famously hitched their wagon to VMS)

epitaph posted:

wasn’t NT developed by ex-DEC people?

quote:

i remember one of the architects expressing particular scorn at unix for its i/o model (DEC had famously hitched their wagon to VMS)

Kazinsal posted:

Dave Cutler was lead on both VMS and NT and he fuckin hates unix with an ahabian passion

Lady Radia posted:

i gotta hear stories come ONNnn

Kazinsal posted:

- anecdotally, the Windows kernel team told Intel to make resets via triple faulting on the 80286 faster after getting their hands on some engineering samples because they were using it as a hack to enable multi-tasking with MS-DOS programs under Windows/286, since the 286 didn't actually have a native way to return to real mode from protected mode. the Intel engineers didn't believe them at first until they showed them how it was working and they were reportedly both impressed and horrified enough to go back and do exactly that, so the Windows 2.x and 3.x kernels in 286 protected mode are constantly resetting the CPU. there's a vague reference to this in the 80286 programmer's manual and Larry Osterman has reported it to have been a meeting that actually happened so I'm inclined to believe it

Kazinsal posted:

I've never met the guy but DEC folks who worked with him said he thought the entire I/O and userspace processes/daemons model of Unix was obsolete before it even left Bell Labs and it held back small-scale computing for years, and a book that interviewed some folks who worked on NT with him described him as considering Unix system design as his Moriarty a la Sherlock Holmes as well as considering it "a junk operating system designed by a committee of PhDs". steve ballmer pretty much got him on board by telling him it was a chance to write a microcomputer OS that scaled up to servers and minicomputing that would displace Unix. he doesn't do interviews really so it's hard to get first-hand accounts from the man

he's probably a huge dick to work with/for but he did some phenomenal design and implementation work from the 70s through the 90s and even when he was managing the NT team he was still writing kernel code himself because he wanted to be hands-on. I think he still works at Microsoft on the Hyper-V team

eschaton posted:

VMS has a very good I/O model, especially for running a multi-user system on what would be considered a paltry amount of RAM for a server even 25 years ago

eschaton posted:

my real VAXstation 4000 VLC has a whopping 24MB of RAM and while it’s not like it’s super fast, it’s perfectly serviceable for both single-user graphical login or multi-user network login, about the only downside is no direct SSH (since even with an implementation it’d likely be too slow and low-memory to negotiate a connection)

feedmegin posted:

...my first PC at uni running Linux had 16 megs of RAM and that was actually twice what a low end system at the time would have. This was a time when EMACS was known as Eight Megabytes and Constantly Swapping because that was a lot of memory at the time.

You can't fit ssh in 24 megs?!

Kazinsal posted:

okay, time to talk about x86 memory management. this post is going to get a bit out of hand so I'm breaking it into sections.


way back before the 8086 the 8080 family had a 16-bit address space but no internal mechanism to manage it, so if you wanted more than 64KiB of RAM/ROM/MMIO you needed an external chip that you could frob to switch what a certain range of the address bus actually pointed at. this sucked but a lot of 8-bit CPU families did this and the chips are fairly simple. you hook them up to say a 16 KiB window and expose a couple I/O ports to the CPU so software can switch that 16 KiB bank to a different slice of whatever RAM chip is hooked up to it through the bank selector chip.

so when Intel designed the 8086 they realized how badly this sucked and even though they were still making a 16-bit CPU they stuck 4 more address lines onto it so they could basically do a sort of pseudo bank switching system in the standard address decoding logic. the 8086 has four 16-bit segment registers that are used in the address decoding logic to create a 20-bit address from a 16-bit segment and a 16-bit offset (usually formatted in documentation as eg. 1234:CDEF, where the word before the colon is the segment and the word after it is the offset. the logic is pretty simple: the segment word is shifted four bits to the left and the offset is added to it. in the above example we'd get this:

code:

segment << 4 | 12340
    + offset |  CDEF
------------ | -----
   = address | 1F12F

this is super advantageous over the bank switching chip thing for two reasons: one, you get full access to the whole 20-bit address space of the system at all times, and two, your code can always assume it starts at 0000 and goes to however much memory it needs in a 16-bit space since the OS can just give you a block of memory and say "your segment is 0x1234". all your indexes and offsets are from 0, no matter where in the 20-bit address space you actually are! and you get separate selectors for code (CS), data (DS and ES), and stack (SS), and segment override prefixes so you can access up to four 64K segments at any time without reloading the segment registers

Lady Radia posted:

i gotta hear stories come ONNnn

JawnV6 posted:

DEC teams survived long after the company itself went under, there were specific projects where decades later there was significant resistance to the intel way of doing things

idk how A20 looms in my head as a giant complication on everything ever, but it wouldn't surprise me if practitioners rarely had to gently caress with it

echinopsis posted:

i read female dating strategies so I know lvm means low value male (or man) but llvm? no idea

echinopsis posted:

i read female dating strategies so I know lvm means low value male (or man) but llvm? no idea

~Coxy posted:

just read UHH, probably

Sweevo posted:

is old (80s?) VAX hardware worth anything these days?

I might have a chance to get a substantial pile of stuff basically free (3400/3300/3100 MicroVAXes + tape drives + printers + loads of accessories), but it's two hours away and means hiring a van, so i'd only do it if i can sell off most of it semi-quickly because i don't want it sitting in the garage for 5 years

Lady Radia posted: