Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Did the PDP-11 series of computers have anything like the PC's BIOS?
276 views
Skip to first unread message
Mark Longridge
Oct 4, 2015, 3:51:08 PM10/4/15
to
Hi Folks,
I've been wondering about the PDP-11 series of computers and I figure it must have had something analagous to the PC's BIOS, for example the PDP-11/45 which ran early Unix.
I don't think it had any framebuffer or anything like video display like a PC does. Do we have PDP-11 ROM source code?
Mark
I've been wondering about the PDP-11 series of computers and I figure it must have had something analagous to the PC's BIOS, for example the PDP-11/45 which ran early Unix.
I don't think it had any framebuffer or anything like video display like a PC does. Do we have PDP-11 ROM source code?
Mark
Guy Sotomayor
Oct 4, 2015, 4:17:11 PM10/4/15
to
The closest the PDP-11s had to BIOS was the boot ROMs (and not all of them had those). The boot ROMs could have various boot loaders that would load the OS from some device. Each device had it's own boot ROM. A device boot loader was typically not very long, it was fairly easy to "toggle" it in from the front panel. The ROMs are fairly simple (and small) so disassembling a number of them shouldn't be too much of a chore.
All of the OS's had a console on a serial port (SLU) and it's configuration was standard so printing something out was fairly easy.
There were frame buffers available at the end of the PDP-11's production life, (likely carried over from the various smaller VAXen) they weren't all that common. At the time vector driven displays were more common (VT11).
TTFN - Guy
All of the OS's had a console on a serial port (SLU) and it's configuration was standard so printing something out was fairly easy.
There were frame buffers available at the end of the PDP-11's production life, (likely carried over from the various smaller VAXen) they weren't all that common. At the time vector driven displays were more common (VT11).
TTFN - Guy
Bob Eager
Oct 4, 2015, 4:31:42 PM10/4/15
to
others) that had a simple ROM monitor that effectively replaced the hand
keys. This allowed examine, deposit, boot, etc.
Don North
Oct 4, 2015, 6:46:56 PM10/4/15
to
device, or doing very simple load/store memory operations. Once the boot rom
transferred control to the operating system it booted, the boot rom on the
PDP-11 was never used again by a PDP-11 O/S. This is very different from how the
BIOS is used on a PC. So in reality there was no such thing as a BIOS for the
PDP-11 computer.
Johnny Billquist
Oct 4, 2015, 8:31:40 PM10/4/15
to
Anyone looking for something BIOS-like on a PDP-11 is just looking for
something that never existed.
We could go on for hours about why not, but let's just leave it where it
is. Any comparison with broken hardware (PC) is not going to be
meaningful anyway.
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: b...@softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
terry+go...@tmk.com
Oct 4, 2015, 9:48:14 PM10/4/15
to
On Sunday, October 4, 2015 at 4:31:42 PM UTC-4, Bob Eager wrote:
> There were some models (the 11/34 was one, and probably quite a few
> others) that had a simple ROM monitor that effectively replaced the hand
> keys. This allowed examine, deposit, boot, etc.
Most of the "classic" (pre-J11) Unibus systems used A9-series device PROMs which were 64 words (actually, 256 nybbles). These were only able to boot from a specific device type (like RL01/RL02) and often only unit 0 on the first controller. Before the A9 PROMs, a "boot board" was a quad-sized module with hundreds of individual diodes to form the words. I have one around somewhere. Back in those days, a boot board was unusual as operators were cheaper than boards.
> There were some models (the 11/34 was one, and probably quite a few
> others) that had a simple ROM monitor that effectively replaced the hand
> keys. This allowed examine, deposit, boot, etc.
The ASCII console PROM (248F1) was a whole 256 words. Whenever I worked on an 11/70, I would replace its 616F1 with a 248F1 to give it an ASCII console.
Q-bus systems and J-11 Unibus systems usually used larger 27xx-series EPROMs instead of the bipolar PROMs on the older Unibus systems. This provided a much richer console environment, though a lot of the space went to diagnostics.
The EPROM bootstraps were actually not as "good" as the discrete A9 chips - for example, the "MS" (TS-11 and derivatives) boot in the EPROM just wrote "MS" to the CSR which was a magic signal to DEC-branded MS controllers to load the first block of the tape to memory. It didn't work with most 3rd-party controllers as they didn't implement the magic signal. The A9 EPROM actually used a real bootstrap program, as the original TS-11 didn't implement the magic either - only the later MS controllers did.
Johnny Billquist
Oct 5, 2015, 12:07:06 PM10/5/15
to
On 2015-10-05 03:48, terry+go...@tmk.com wrote:
> On Sunday, October 4, 2015 at 4:31:42 PM UTC-4, Bob Eager wrote:
>> There were some models (the 11/34 was one, and probably quite a few
>> others) that had a simple ROM monitor that effectively replaced the hand
>> keys. This allowed examine, deposit, boot, etc.
>
> Most of the "classic" (pre-J11) Unibus systems used A9-series device PROMs which were 64 words (actually, 256 nybbles). These were only able to boot from a specific device type (like RL01/RL02) and often only unit 0 on the first controller. Before the A9 PROMs, a "boot board" was a quad-sized module with hundreds of individual diodes to form the words. I have one around somewhere. Back in those days, a boot board was unusual as operators were cheaper than boards.
Well, not entirely true. Most of them can actually boot from any unit
> On Sunday, October 4, 2015 at 4:31:42 PM UTC-4, Bob Eager wrote:
>> There were some models (the 11/34 was one, and probably quite a few
>> others) that had a simple ROM monitor that effectively replaced the hand
>> keys. This allowed examine, deposit, boot, etc.
>
> Most of the "classic" (pre-J11) Unibus systems used A9-series device PROMs which were 64 words (actually, 256 nybbles). These were only able to boot from a specific device type (like RL01/RL02) and often only unit 0 on the first controller. Before the A9 PROMs, a "boot board" was a quad-sized module with hundreds of individual diodes to form the words. I have one around somewhere. Back in those days, a boot board was unusual as operators were cheaper than boards.
number, and some of them were able to boot more than one type of devices
as well. But it was always a bit more tricky to boot a unit which was
not #0. (You needed to set the switch register more specifically, and
start at a different address.)
> The ASCII console PROM (248F1) was a whole 256 words. Whenever I worked on an 11/70, I would replace its 616F1 with a 248F1 to give it an ASCII console.
Johnny
glen herrmannsfeldt
Oct 5, 2015, 12:47:01 PM10/5/15
to
(snip)
> Well, not entirely true. Most of them can actually boot from any unit
> number, and some of them were able to boot more than one type of devices
> as well. But it was always a bit more tricky to boot a unit which was
> not #0. (You needed to set the switch register more specifically, and
> start at a different address.)
Or renumber the disks.
I remember AED disk drives on LSI-11s where each drive had a thumbwheel
to select its drive number. You could change which one was 0.
As I remember the boot sequence, you press the IPL button on
the drive, then start the LSI-11. It starts executing at the address
that would be ROM, but which is actually the AED controller, which
returns a jump instruction to itself. The controller logic then
reads the first sector off the disk into low memory. When it is
done, instead of returning a jump to self, it returns a jump to zero
(or some other address), and off it goes.
>> The ASCII console PROM (248F1) was a whole 256 words.
>> Whenever I worked on an 11/70, I would replace its 616F1 with
>> a 248F1 to give it an ASCII console.
For some systems, you key in the boot loader from front panel
switches. With magnetic core memory, you wouldn't have to reload
on every power up, though it was likely usual to keep machines
running as much as possible.
-- glen
>> These were only able to boot from a specific device type
>> (like RL01/RL02) and often only unit 0 on the first controller.
(snip)
>> (like RL01/RL02) and often only unit 0 on the first controller.
> Well, not entirely true. Most of them can actually boot from any unit
> number, and some of them were able to boot more than one type of devices
> as well. But it was always a bit more tricky to boot a unit which was
> not #0. (You needed to set the switch register more specifically, and
> start at a different address.)
I remember AED disk drives on LSI-11s where each drive had a thumbwheel
to select its drive number. You could change which one was 0.
As I remember the boot sequence, you press the IPL button on
the drive, then start the LSI-11. It starts executing at the address
that would be ROM, but which is actually the AED controller, which
returns a jump instruction to itself. The controller logic then
reads the first sector off the disk into low memory. When it is
done, instead of returning a jump to self, it returns a jump to zero
(or some other address), and off it goes.
>> The ASCII console PROM (248F1) was a whole 256 words.
>> Whenever I worked on an 11/70, I would replace its 616F1 with
>> a 248F1 to give it an ASCII console.
switches. With magnetic core memory, you wouldn't have to reload
on every power up, though it was likely usual to keep machines
running as much as possible.
-- glen
Don North
Oct 5, 2015, 4:54:53 PM10/5/15
to
On 10/4/2015 6:48 PM, terry+go...@tmk.com wrote:
> On Sunday, October 4, 2015 at 4:31:42 PM UTC-4, Bob Eager wrote:
>> There were some models (the 11/34 was one, and probably quite a few
>> others) that had a simple ROM monitor that effectively replaced the hand
>> keys. This allowed examine, deposit, boot, etc.
>
> Most of the "classic" (pre-J11) Unibus systems used A9-series device PROMs
> which were 64 words (actually, 256 nybbles). These were only able to boot
> from a specific device type (like RL01/RL02) and often only unit 0 on the
> first controller. Before the A9 PROMs, a "boot board" was a quad-sized
> module with hundreds of individual diodes to form the words. I have one
> around somewhere. Back in those days, a boot board was unusual as operators
> were cheaper than boards.
Not quite true. All of the A9-series (ie, M9312 module, PDP-11/44 boot) boot
> On Sunday, October 4, 2015 at 4:31:42 PM UTC-4, Bob Eager wrote:
>> There were some models (the 11/34 was one, and probably quite a few
>> others) that had a simple ROM monitor that effectively replaced the hand
>> keys. This allowed examine, deposit, boot, etc.
>
> Most of the "classic" (pre-J11) Unibus systems used A9-series device PROMs
> which were 64 words (actually, 256 nybbles). These were only able to boot
> from a specific device type (like RL01/RL02) and often only unit 0 on the
> first controller. Before the A9 PROMs, a "boot board" was a quad-sized
> module with hundreds of individual diodes to form the words. I have one
> around somewhere. Back in those days, a boot board was unusual as operators
> were cheaper than boards.
proms supported booting from any unit number 0..7, default was zero. Each
devices boot code was stored in an individual 512x4 prom that appeared in
program space as 64 16b words. Only the low half of the physical device was
used, the last half was not accessible. In fact a 256x4 prom works also.
Enter the command 'XXn' at the '@' prompt to boot from device id 'XX' unit 'n'.
Enter just 'XX' at the '@' prompt to boot from unit '0'.
Each of the boot proms had a header that supported this functionality, and the
248F1 ascii console support rom for the 11/04-34-... provided the command
decoder that took user typed input and called the boot prom accordingly.
Between the A9 boot prom board (the M9312) and the diode-based board there was
an intermediate prom-based board (M9301) that used the same 512x4 proms in a
cluster of four devices to implement 512 16b words of memory. These prom devices
were not individually swappable however; the 512 word space had a mixture of
various device bootstrap codes. There were lots of variations of the module
(M9301-YA, -YB, -YC, ...) to handle various boot and system scenarios.
Charles Richmond
Oct 5, 2015, 5:59:23 PM10/5/15
to
"Don North" <na...@spam.com> wrote in message
news:musa56$751$1...@dont-email.me...
And on the LSI-11 that I used, if the OS crashed (we ran RT-11), the system
was thrown into this boot monitor. Input was in octal for the monitor.
--
numerist at aquaporin4 dot com
news:musa56$751$1...@dont-email.me...
was thrown into this boot monitor. Input was in octal for the monitor.
--
numerist at aquaporin4 dot com
Charles Richmond
Oct 5, 2015, 6:04:07 PM10/5/15
to
"glen herrmannsfeldt" <g...@ugcs.caltech.edu> wrote in message
news:muu9i1$6fv$1...@speranza.aioe.org...
>
> [snip...] [snip...]
> [snip...]
news:muu9i1$6fv$1...@speranza.aioe.org...
>
> [snip...] [snip...]
> [snip...]
>
> As I remember the boot sequence, you press the IPL button on
> the drive, then start the LSI-11. It starts executing at the address
> that would be ROM, but which is actually the AED controller, which
> returns a jump instruction to itself. The controller logic then
> reads the first sector off the disk into low memory. When it is
> done, instead of returning a jump to self, it returns a jump to zero
> (or some other address), and off it goes.
>
Except did DEC ever use the term "IPL"??? I thought that was an IBM'ism.
> As I remember the boot sequence, you press the IPL button on
> the drive, then start the LSI-11. It starts executing at the address
> that would be ROM, but which is actually the AED controller, which
> returns a jump instruction to itself. The controller logic then
> reads the first sector off the disk into low memory. When it is
> done, instead of returning a jump to self, it returns a jump to zero
> (or some other address), and off it goes.
>
Richard
Oct 5, 2015, 6:26:00 PM10/5/15
to
[Please do not mail me a copy of your followup]
Johnny Billquist <b...@softjar.se> spake the secret code
<musgdb$gc9$1...@Iltempo.Update.UU.SE> thusly:
>Any comparison with broken hardware (PC) is not going to be
>meaningful anyway.
LOL.
Yeah, the PC is so "broken" they barely sold any units.
--
"The Direct3D Graphics Pipeline" free book <http://tinyurl.com/d3d-pipeline>
The Computer Graphics Museum <http://computergraphicsmuseum.org>
The Terminals Wiki <http://terminals.classiccmp.org>
Legalize Adulthood! (my blog) <http://legalizeadulthood.wordpress.com>
Johnny Billquist <b...@softjar.se> spake the secret code
<musgdb$gc9$1...@Iltempo.Update.UU.SE> thusly:
>Any comparison with broken hardware (PC) is not going to be
>meaningful anyway.
Yeah, the PC is so "broken" they barely sold any units.
--
"The Direct3D Graphics Pipeline" free book <http://tinyurl.com/d3d-pipeline>
The Computer Graphics Museum <http://computergraphicsmuseum.org>
The Terminals Wiki <http://terminals.classiccmp.org>
Legalize Adulthood! (my blog) <http://legalizeadulthood.wordpress.com>
glen herrmannsfeldt
Oct 5, 2015, 6:36:54 PM10/5/15
to
Charles Richmond <nume...@aquaporin4.com> wrote:
(snip, I wrote)
>> As I remember the boot sequence, you press the IPL button on
>> the drive, then start the LSI-11. It starts executing at the address
>> that would be ROM, but which is actually the AED controller, which
>> returns a jump instruction to itself. The controller logic then
>> reads the first sector off the disk into low memory. When it is
>> done, instead of returning a jump to self, it returns a jump to zero
>> (or some other address), and off it goes.
> Except did DEC ever use the term "IPL"??? I thought that was an IBM'ism.
This was an AED (non-DEC) disk drive, which did use the term.
As well as I understand it, the drives use IBM standard single
side double density floppy disk formats, with the controller
and formatter inside the drive box. The Q-bus card is just
an adapter card and doesn't do much work. (Similar to
the usual ISA to IDE card, which is just a bus buffer.)
This would have been close to when the LSI-11 became available,
RX01 and RX02 were very expensive, and so there was demand
for cheaper systems that weren't DEC compatible.
The disks held more than RX01 but less than RX02. I knew of
one machine with both AED and RX02 drives, so we could copy
between them when needed. But more often, we used Kermit.
Well, the machine was a few years old by the time I got there.
Kermit was new, and RT-11 v5.0 was needed, as it allowed for
one to use more than one terminal line, I believe multi-terminal
support.
-- glen
(snip, I wrote)
>> As I remember the boot sequence, you press the IPL button on
>> the drive, then start the LSI-11. It starts executing at the address
>> that would be ROM, but which is actually the AED controller, which
>> returns a jump instruction to itself. The controller logic then
>> reads the first sector off the disk into low memory. When it is
>> done, instead of returning a jump to self, it returns a jump to zero
>> (or some other address), and off it goes.
> Except did DEC ever use the term "IPL"??? I thought that was an IBM'ism.
As well as I understand it, the drives use IBM standard single
side double density floppy disk formats, with the controller
and formatter inside the drive box. The Q-bus card is just
an adapter card and doesn't do much work. (Similar to
the usual ISA to IDE card, which is just a bus buffer.)
This would have been close to when the LSI-11 became available,
RX01 and RX02 were very expensive, and so there was demand
for cheaper systems that weren't DEC compatible.
The disks held more than RX01 but less than RX02. I knew of
one machine with both AED and RX02 drives, so we could copy
between them when needed. But more often, we used Kermit.
Well, the machine was a few years old by the time I got there.
Kermit was new, and RT-11 v5.0 was needed, as it allowed for
one to use more than one terminal line, I believe multi-terminal
support.
-- glen
terry+go...@tmk.com
Oct 5, 2015, 11:41:55 PM10/5/15
to
On Monday, October 5, 2015 at 12:07:06 PM UTC-4, Johnny Billquist wrote:
> Well, not entirely true. Most of them can actually boot from any unit
> number, and some of them were able to boot more than one type of devices
> as well. But it was always a bit more tricky to boot a unit which was
> not #0. (You needed to set the switch register more specifically, and
> start at a different address.)
For systems with front panels and pushbutton boot that would involve either someone being taught how to operate the front panel, or calling Field Service to change the jump address on the boot card. And you normally couldn't boot a device with an alternate CSR (second controller, etc.). If you had an ASCII console life was a lot easier.
> Well, not entirely true. Most of them can actually boot from any unit
> number, and some of them were able to boot more than one type of devices
> as well. But it was always a bit more tricky to boot a unit which was
> not #0. (You needed to set the switch register more specifically, and
> start at a different address.)
My memory is developing bitrot, but weren't the 2 entry addresses into the A9 PROM for "run diags and boot" vs. "just boot" (where diagnostics were on the F1 PROM)?
> And loose all the built in self tests... :-)
Even XXDP wouldn't find many (I'm tempted to say "most") problems in an 11/70 unless something was catastrophically wrong. Whereas RSTS/E would quickly barf if there was the slightest thing wrong. For a while "back in the day", Fred Knight was flying back and forth between his office at DEC and my site as we debugged some odd RSTS/E 11/70 interactions. I learned a lot about what can go wrong on an 11/70, undocumented changes that were necessary but never released as FCOs, etc.
Earlier on, I found a microcode bug in the 11/44 which DEC declined to fix. Contrast with a much older IBM 370 which had a similar odd issue around the same time, and they sent one of the original CPU designers out.
Johnny Billquist
Oct 6, 2015, 5:51:37 AM10/6/15
to
On 2015-10-06 00:26, Richard wrote:
> [Please do not mail me a copy of your followup]
>
> Johnny Billquist <b...@softjar.se> spake the secret code
> <musgdb$gc9$1...@Iltempo.Update.UU.SE> thusly:
>
>> Any comparison with broken hardware (PC) is not going to be
>> meaningful anyway.
>
> LOL.
>
> Yeah, the PC is so "broken" they barely sold any units.
Commercial success have nothing to do with technical merit.
> [Please do not mail me a copy of your followup]
>
> Johnny Billquist <b...@softjar.se> spake the secret code
> <musgdb$gc9$1...@Iltempo.Update.UU.SE> thusly:
>
>> Any comparison with broken hardware (PC) is not going to be
>> meaningful anyway.
>
> LOL.
>
> Yeah, the PC is so "broken" they barely sold any units.
Johnny Billquist
Oct 6, 2015, 6:01:08 AM10/6/15
to
On 2015-10-06 05:41, terry+go...@tmk.com wrote:
> On Monday, October 5, 2015 at 12:07:06 PM UTC-4, Johnny Billquist wrote:
>> Well, not entirely true. Most of them can actually boot from any unit
>> number, and some of them were able to boot more than one type of devices
>> as well. But it was always a bit more tricky to boot a unit which was
>> not #0. (You needed to set the switch register more specifically, and
>> start at a different address.)
>
> For systems with front panels and pushbutton boot that would involve either someone being taught how to operate the front panel, or calling Field Service to change the jump address on the boot card. And you normally couldn't boot a device with an alternate CSR (second controller, etc.). If you had an ASCII console life was a lot easier.
>
> My memory is developing bitrot, but weren't the 2 entry addresses into the A9 PROM for "run diags and boot" vs. "just boot" (where diagnostics were on the F1 PROM)?
Not that it would be meaningful, but you could have 64 entry addresses
> On Monday, October 5, 2015 at 12:07:06 PM UTC-4, Johnny Billquist wrote:
>> Well, not entirely true. Most of them can actually boot from any unit
>> number, and some of them were able to boot more than one type of devices
>> as well. But it was always a bit more tricky to boot a unit which was
>> not #0. (You needed to set the switch register more specifically, and
>> start at a different address.)
>
> For systems with front panels and pushbutton boot that would involve either someone being taught how to operate the front panel, or calling Field Service to change the jump address on the boot card. And you normally couldn't boot a device with an alternate CSR (second controller, etc.). If you had an ASCII console life was a lot easier.
>
> My memory is developing bitrot, but weren't the 2 entry addresses into the A9 PROM for "run diags and boot" vs. "just boot" (where diagnostics were on the F1 PROM)?
if you wanted to. There were usually more than two. But yes, the most
known ones would be boot from unit 0, with and without running diags.
The M9312 manual is online, which includes details of addresses for lots
of roms. You can read up, if you want to refresh your memory.
>> And loose all the built in self tests... :-)
>
> 11/70s were complex enough that I don't think there was enough space in the F1 PROM to even do a complete verification of the data paths, let alone any sort of complete diagnostic.
any roms, but the self test in the boot roms of the 11/70 have about 30
tests. And will catch things like broken cache, which you even can
recover from. Also testing the basic instructions and addressing modes,
and a small part of memory. Enough to be somewhat confident that you can
actually boot and run something.
> Even XXDP wouldn't find many (I'm tempted to say "most") problems in an 11/70 unless something was catastrophically wrong. Whereas RSTS/E would quickly barf if there was the slightest thing wrong. For a while "back in the day", Fred Knight was flying back and forth between his office at DEC and my site as we debugged some odd RSTS/E 11/70 interactions. I learned a lot about what can go wrong on an 11/70, undocumented changes that were necessary but never released as FCOs, etc.
you sometimes really have to let the diagnostics run for hours and very
many passes. Which essentially means that some errors are rather
sporadic and annoying...
> Earlier on, I found a microcode bug in the 11/44 which DEC declined to fix. Contrast with a much older IBM 370 which had a similar odd issue around the same time, and they sent one of the original CPU designers out.
Jerome H. Fine
Oct 6, 2015, 9:34:22 AM10/6/15
to
>glen herrmannsfeldt wrote:
>Well, the machine was a few years old by the time I got there.
>Kermit was new, and RT-11 v5.0 was needed, as it allowed for
>one to use more than one terminal line, I believe multi-terminal
>support.
>
I ran Multi-User Basic (MUBASC) under V04.00 back in 1981.
>Well, the machine was a few years old by the time I got there.
>Kermit was new, and RT-11 v5.0 was needed, as it allowed for
>one to use more than one terminal line, I believe multi-terminal
>support.
>
A SYSGEN was required for multi-terminal support and each
user was assigned to its own VT100 terminal on one of the
terminal lines. A Mapped Monitor (RT11XM.SYS) was used
and a foreground job was also used to communicate with 6 other
terminals via serial DL lines which were NOT under multi-terminal
support.
It is possible that RT-11 had multi-terminal support prior to
V04.00 of RT-11 prior to 1980, but I can't remember at this
point in time - 35 years ago.
Jerome Fine
Richard
Oct 6, 2015, 11:11:17 AM10/6/15
to
[Please do not mail me a copy of your followup]
Mark Longridge <cub...@gmail.com> spake the secret code
<3ab2dcbe-7133-42dd...@googlegroups.com> thusly:
>I don't think it had any framebuffer or anything like video display like
>a PC does. Do we have PDP-11 ROM source code?
memory mapped framebuffer standard.
<https://en.wikipedia.org/wiki/Terak_8510/a>
Richard
Oct 6, 2015, 11:14:44 AM10/6/15
to
[Please do not mail me a copy of your followup]
Johnny Billquist <b...@softjar.se> spake the secret code
<mv05j8$rcm$1...@Iltempo.Update.UU.SE> thusly:
Johnny Billquist <b...@softjar.se> spake the secret code
>On 2015-10-06 00:26, Richard wrote:
>> [Please do not mail me a copy of your followup]
>>
>> Johnny Billquist <b...@softjar.se> spake the secret code
>> <musgdb$gc9$1...@Iltempo.Update.UU.SE> thusly:
>>
>>> Any comparison with broken hardware (PC) is not going to be
>>> meaningful anyway.
>>
>> LOL.
>>
>> Yeah, the PC is so "broken" they barely sold any units.
>
>Commercial success have nothing to do with technical merit.
Had you said inelegant instead of broken, I wouldn't have bothered.
Technical elegance or merit is not the only thing that matters. If that
was the case, we'd all be using an ancestor of the Amiga and not the
IBM PC on our desks.
While I appreciate technical elegance, mass market appeal and volume
manfuacturing have done far more to make computers accessible to more
people at less cost.
In other words, what good is technical elegance if I can't afford it?
Al Kossow
Oct 6, 2015, 11:58:46 AM10/6/15
to
On 10/6/15 8:11 AM, Richard wrote:
>
> The Terak workstation circa 1976/1977 used an LSI-11 CPU and had a
> memory mapped framebuffer standard.
>
There were also all of the Soviet PDP-11 microcomputers.
>
> The Terak workstation circa 1976/1977 used an LSI-11 CPU and had a
> memory mapped framebuffer standard.
>
I don't know enough about them to know how much code was in firmware.
Should probably find out more, though.
glen herrmannsfeldt
Oct 6, 2015, 3:34:24 PM10/6/15
to
Jerome H. Fine <ever...@nospam.com> wrote:
(snip, I wrote)
>>Well, the machine was a few years old by the time I got there.
>>Kermit was new, and RT-11 v5.0 was needed, as it allowed for
>>one to use more than one terminal line, I believe multi-terminal
>>support.
(snip)
> It is possible that RT-11 had multi-terminal support prior to
> V04.00 of RT-11 prior to 1980, but I can't remember at this
> point in time - 35 years ago.
Now I think I remember what I forgot yesterday.
It was 5.0 that allowed multiterminal support for SJ.
We didn't have the MMU or memory needed for XM, I am not sure
now about FB, but we wanted SJ.
So someone sysgenned a 5.0 SJ with multiterminal support.
-- glen
(snip, I wrote)
>>Well, the machine was a few years old by the time I got there.
>>Kermit was new, and RT-11 v5.0 was needed, as it allowed for
>>one to use more than one terminal line, I believe multi-terminal
>>support.
> It is possible that RT-11 had multi-terminal support prior to
> V04.00 of RT-11 prior to 1980, but I can't remember at this
> point in time - 35 years ago.
It was 5.0 that allowed multiterminal support for SJ.
We didn't have the MMU or memory needed for XM, I am not sure
now about FB, but we wanted SJ.
So someone sysgenned a 5.0 SJ with multiterminal support.
-- glen
terry+go...@tmk.com
Oct 6, 2015, 4:03:54 PM10/6/15
to
On Tuesday, October 6, 2015 at 11:58:46 AM UTC-4, Al Kossow wrote:
> There were also all of the Soviet PDP-11 microcomputers.
> I don't know enough about them to know how much code was in firmware.
> Should probably find out more, though.
A lot of them were very similar copies of DEC hardware. For example, compare these 2 11/73 boards:
> There were also all of the Soviet PDP-11 microcomputers.
> I don't know enough about them to know how much code was in firmware.
> Should probably find out more, though.
DEC: https://www.tmk.com/transient/dec-j11.jpg
Soviet: https://www.tmk.com/transient/soviet-j11.jpg
Given that they were perfectly happy to copy the IC masks as-is, I would expect the firmware to get a similar treatment (possibly changing any message text).
Charles Richmond
Oct 6, 2015, 5:51:58 PM10/6/15
to
"Richard" <legaliz...@mail.xmission.com> wrote in message
news:mv0oh4$bfq$3...@news.xmission.com...
>> [snip...]
"Broken" does *not* just imply non-functional or unusable. Broken implies
that it performs *so* badly... no one in their right mind would desire to
use it!!! Saying that PC are "broken" means that these PCs are training
the "unwashed masses" to expect poor performance and defective software.
news:mv0oh4$bfq$3...@news.xmission.com...
>
> Johnny Billquist <b...@softjar.se> spake the secret code
> <mv05j8$rcm$1...@Iltempo.Update.UU.SE> thusly:
>>
>> [snip...] [snip...]
> Johnny Billquist <b...@softjar.se> spake the secret code
> <mv05j8$rcm$1...@Iltempo.Update.UU.SE> thusly:
>>
>> [snip...]
>>
>>Commercial success have nothing to do with technical merit.
>
> Broken implies that it is non functional or not useful.
>
> Had you said inelegant instead of broken, I wouldn't have bothered.
>
> Technical elegance or merit is not the only thing that matters. If that
> was the case, we'd all be using an ancestor of the Amiga and not the
> IBM PC on our desks.
>
> While I appreciate technical elegance, mass market appeal and volume
> manfuacturing have done far more to make computers accessible to more
> people at less cost.
>
> In other words, what good is technical elegance if I can't afford it?
>
What good is "accessable" if what is accessable is a piece of crap!!!
>>Commercial success have nothing to do with technical merit.
>
> Broken implies that it is non functional or not useful.
>
> Had you said inelegant instead of broken, I wouldn't have bothered.
>
> Technical elegance or merit is not the only thing that matters. If that
> was the case, we'd all be using an ancestor of the Amiga and not the
> IBM PC on our desks.
>
> While I appreciate technical elegance, mass market appeal and volume
> manfuacturing have done far more to make computers accessible to more
> people at less cost.
>
> In other words, what good is technical elegance if I can't afford it?
>
"Broken" does *not* just imply non-functional or unusable. Broken implies
that it performs *so* badly... no one in their right mind would desire to
use it!!! Saying that PC are "broken" means that these PCs are training
the "unwashed masses" to expect poor performance and defective software.
Johnny Billquist
Oct 6, 2015, 10:10:04 PM10/6/15
to
that it had the IBM logo on it was the first reason for survival. Cheap
later became the second reason. And by the time the second reason became
relevant, we started seeing people who never knew better.
And today it's mostly irrelevant, since people no longer see, or are
aware of some of the sick stuff in there. And some of the stuff have
slowly disappeared as well, along with the sick buses they used to use.
(Anyone still recall how the memory layout actually looks like on a PC?
Or the ugly architecture that x86 is? Or the strange and silly IRQ and
DMA setups you needed to do on cards on the ISA bus, or the dependecies
on the BIOS, which in the old days had the geometry of every kind of
disk in tables in the BIOS, fixed even... Or the various video cards
with incompatible interfaces and peculiarities... I could go on, but
anyone just take a trip down memory lane, and be amazed at what the PC
actually was (is)...
Richard
Oct 7, 2015, 12:13:42 PM10/7/15
to
[Please do not mail me a copy of your followup]
"Charles Richmond" <nume...@aquaporin4.com> spake the secret code
<mv1fm3$4hn$1...@dont-email.me> thusly:
>What good is "accessable" if what is accessable is a piece of crap!!!
>"Broken" does *not* just imply non-functional or unusable. Broken implies
>that it performs *so* badly... no one in their right mind would desire to
>use it!!! Saying that PC are "broken" means that these PCs are training
>the "unwashed masses" to expect poor performance and defective software.
0 new messages