|
carry on then posted:there are old issues of byte in the internet archive and the ads and reviews for things like dos memory managers make the experience of using a pc back then sound dire. there's no way i wouldn't have been a mac user if i were born early enough to have to make that decision back then That would very much depend on how much money you had.
|
#
¿
Jan 17, 2022 17:17
|
|
|
|
| # ¿ May 22, 2024 19:17 |
|
|
Kazinsal posted:not particularly because the pinout is the same and the die is the same size, just the 8088 has an 8-bit data bus controller and the 8086 has a 16-bit data bus controller so maybe it was a couple bucks less per unit at the "buying by the thousands" scale. Yeah, if I recall, it's not so much the cost of the CPU itself - it's that wiring up an 8 bit databus is cheaper and involves fewer components and possibly less glue logic than 16 bits. You're only driving half the lines! And you don't have to worry about stuff like high and low byte lane selects.
|
|
#
¿
Jan 19, 2022 13:44
|
|
|
eschaton posted:that’s a weird assertion since the 68000 has had 6800-series peripheral support from the start 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.
|
|
#
¿
Jan 20, 2022 11:51
|
|
|
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 IIRC architecturally it's very nice, which means in practice it's slow, for the same reason STREAMS on System V was slow. Having lots of different layers of encapsulation looks lovely on a whiteboard in much the same way a microkernel looks nice in theory, but you end up paying for that. (Asynchronous by default, though, that bit's legit and I wish Unix had gone with that to start with)
|
|
#
¿
Feb 1, 2022 14:55
|
|
|
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) ...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?!
|
|
#
¿
Feb 1, 2022 14:59
|
|
|
Sweevo posted:plz tell me more about VAX i/o vs unix because i know nothing about either Classic unix model - call the read() syscall to get some data from a file handle. Blocks until that data has arrived, your (back in the day) single threaded process is sitting there doing absolutely nothing until it does. Or until you get an error. Like the dreaded EINTR which means 'you got a signal, no i'm not going to just restart the system call so ask me again'. VMS model - call read(), give it a callback, VMS will call your callback when your data arrives. In the meantime you can go about your day, do calculations, even kick off a bunch more I/O operations, and the kernel will do its best to schedule them for maximum efficiency, quite possibly in parallel (consider if you're reading from two different physical discs for eg). The latter is a bit more complicated to implement and to work with but more efficient. Importantly, though you can turn it into the former system by doing your read() and then just waiting for the callback anyway, but you can't do the reverse.
|
|
#
¿
Feb 3, 2022 14:52
|
|
|
sb hermit posted:Thanks for the explanation of the evolution of the x86 memory model. It really explains all those compile switches in early Linux kernels. ACPI seems like a real shitshow. I've done embedded powerpc development so I always wondered if the i/o address space for x86 is still in use, since it seemed so clunky. I'm sorta happy that it was just an ISA thing. It was in use for a long time for graphics card stuff, because VGA is defined in terms of it. Hence why Linux graphics drivers had to do the iopl() thing (yes, I might have written a couple back in the day) as recently as early PCI or even I think AGP days because that was still part of the mode switching process for most hardware, even for better modes than SVGA. And if you didnt have a specific driver for your card, well, that's all you had to work with in that case hope you enjoy 800x640 resolution.
|
|
#
¿
Mar 11, 2022 13:42
|
|
|
|
| # ¿ May 22, 2024 19:17 |
|
|
eschaton posted:business software written in COBOL may have fared better, I know FORTRAN code did; my rx2660 with DEC FORTRAN running some numeric benchmarks did really impressively for the era in which it was made, on par with some much newer x86-64 hardware About the only thing it had going for it was some pretty impressive floating point performance for its time, yeah. I think it was used in some of the top supercomputers for a bit. Shame if you're using it for anything that isn't that, though.
|
|
#
¿
Mar 11, 2022 13:46
|
|