12 Nov
2007
12 Nov
'07
10:24 p.m.
The I/O
on a full blown system is where a modern system might have emulation
problems
This is exactly where simulation has been hung up for years. The mass storage
and terminal system is complex, with microcoded controllers for tape and disk
and dedicated front end processors for terminal/network I/O. KL10 simulation
is a cakewalk compared to this (and the KL10 was no small feat of programming).
I've dug up some additional information Olin Siebert didn't have, but there is
still a lot of internal Honeywell HW/SW documentation on the I/O that hasn't been
found.
This whole issue has been bounced around on the Multics mailing list and alt.os.multics
for years.
13 Nov
13 Nov
6:21 a.m.
On Monday 12 November 2007 17:24, Al Kossow wrote:
This sort of thing is exactly the area where I'm fuzziest when it comes to any
sort of a real understanding of big iron. Aside from seeing references to
such stuff from time to time, I really don't have a clue as to why you'd
_want_ something like a separate dedicated processor to handle I/O, for one
example. Or mass storage. Or whatever. And I really don't have that much
of a handle on how the architecture of those sorts of machines differs from
the micros I'm familiar with. Even that bit of time I got to spend with the
Heath H11 was very alien to the rest of what I'm familiar with.
I realize that I'll never get as familiar with some of this stuff as some of
you guys that have actually worked with it, but can any of you point me
toward some resources that might let me understand some of it better than I
do now?
--
Member of the toughest, meanest, deadliest, most unrelenting -- and
ablest -- form of life in this section of space, ?a critter that can
be killed but can't be tamed. ?--Robert A. Heinlein, "The Puppet Masters"
-
Information is more dangerous than cannon to a society ruled by lies. --James
M Dakin
The I/O on a
full blown system is where a modern system might have
emulation problems
This is exactly where simulation has been hung up for years. The mass
storage and terminal system is complex, with microcoded controllers for
tape and disk and dedicated front end processors for terminal/network I/O. 
6:58 a.m.
Roy J. Tellason wrote:
On Monday 12 November 2007 17:24, Al Kossow wrote:
This sort of thing is exactly the area where I'm fuzziest when it comes to any
sort of a real understanding of big iron. Aside from seeing references to
such stuff from time to time, I really don't have a clue as to why you'd
_want_ something like a separate dedicated processor to handle I/O, for one
example.
The Multics system was designed to be scaled to very large numbers of
processors and thousands of users.
It was recognized that all of the tasks to handle the disk i/o which was
very important to performance
need not all go thru the processors in all cases.
Multics was a virtual memory system. The nature of this sort of system
was researched by students
at MIT and ideas to enhance performance showed that a lot of the
activities could be carried out by
subsystems which were dedicated to just the specific task of moving data
to and from the memory.
Early systems also had three level storage systems which incorporated a
swapping drum to allow
the same performance of a large amount of core memory w/o having the
actual core available by
swapping user spaces to the drum. Disk was sufficiently fast to allow
the virtual memory approach
to start to be used in a timesharing system, but not fast enough to
match the drum storage performance.
When the system I worked on was configured the threshold was crossed and
the USL Multics
system was configured with no drum and a large (1 or 2mb I think) or
memory rather than a drum.
The I/O
on a full blown system is where a modern system might have
emulation problems
This is exactly where simulation has been hung up for years. The mass
storage and terminal system is complex, with microcoded controllers for
tape and disk and dedicated front end processors for terminal/network I/O.
Or mass storage. Or whatever.
The
communications front end handled a lot of the mundane tasks of
interfacing with terminals
and transmitted in streams of character data to and from the terminal
rather than dealing with
character transfers.
And I really don't have that much
of a handle on how the architecture of those sorts of machines differs from
the micros I'm familiar with. Even that bit of time I got to spend with the
Heath H11 was very alien to the rest of what I'm familiar with.
I realize that I'll never get as familiar with some of this stuff as some of
you guys that have actually worked with it, but can any of you point me
toward some resources that might let me understand some of it better than I
do now?
C. Gordon Bell's books are a good place to start. One oriented towards
DEC systems is at
http://research.microsoft.com/~GBell/CGB%20Files/Computer%20Engineering%207…
This book which is online covers all computers for the time it was
published and is very useful
to read.
http://research.microsoft.com/~GBell/CGB%20Files/Computer%20Structures%20Pr…
Also on that site is a listing of computer companies he compiled which
is very useful if you can't
quite think of the name of the computer company you have a part for.
(off the subject but useful)
http://research.microsoft.com/~GBell/CGB%20Files/91_US_minicomputer_compani…
I find his web site is useful in general to pour over for reading. The
links above are from books he has had put online
since going to work for Microsoft.
http://research.microsoft.com/~GBell/
5:24 p.m.
On Tuesday 13 November 2007 01:58, jim s wrote:
Looks like some reading material, there... :-)
Roy J. Tellason wrote:
That's the OS. And then there's the hardware, with which some stuff scales
well and some doesn't, and I'm still trying to figure out what the factors
are that get invovled in that.
On Monday 12 November 2007 17:24, Al Kossow
wrote:
This sort of thing is exactly the area where I'm fuzziest when it comes
to any sort of a real understanding of big iron. Aside from seeing
references to such stuff from time to time, I really don't have a clue
as to why you'd _want_ something like a separate dedicated processor to
handle I/O, for one example.
The Multics system was designed to be scaled to very large numbers of
processors and thousands of users. The I/O
on a full blown system is where a modern system might have
emulation problems
This is exactly where simulation has been hung up for years. The mass
storage and terminal system is complex, with microcoded controllers for
tape and disk and dedicated front end processors for terminal/network
I/O. It was recognized that all of the tasks to handle the
disk i/o which was
very important to performance need not all go thru the processors in all
cases.
Makes sense.
Multics was a virtual memory system. The nature of
this sort of system
was researched by students at MIT and ideas to enhance performance showed
that a lot of the activities could be carried out by subsystems which were
dedicated to just the specific task of moving data to and from the memory.
This is where I get a little puzzled sometimes. Like that BB2 I mentioned,
that uses DMA to send a string of bytes to the disk controller chip rather
than using the processor to do those transfers. Why is not immediately
apparent to me since the processor isn't doing anything else at that point
anyhow...
Early systems also had three level storage systems
which incorporated a
swapping drum to allow the same performance of a large amount of core memory
w/o having the actual core available by swapping user spaces to the drum.
Disk was sufficiently fast to allow the virtual memory approach to start to
be used in a timesharing system, but not fast enough to match the drum
storage performance.
A lot of the early textbooks I was able to get my hands on (mostly the sorts
you could find in a public library) mentioned drum storage, but they never
really got into the performance and capacity comparisons between those and
disk. And then there was mention briefly of those systems that had multiple
fixed heads for R/W rather than moving a single one -- I believe some of the
DEC literature I got my hands on back when also talked about such devices,
but I never really saw hard numbers to be able to compare them. Never
actually saw a drum or a system that used one, either...
When the system I worked on was configured the
threshold was crossed and
the USL Multics system was configured with no drum and a large (1 or 2mb I
think) or memory rather than a drum.
Speaking of crossing a threshold I can still remember years ago, when the
only computer I had was my Osborne Executive, and I was sitting there using
Wordstar, and hit the point where the file I was working on would no longer
fit completely within memory. The transition was so completely seamless and
transparent to me as the user I was impressed. :-)
And on this current linux box, it continues... Though when I run out of
swap, thats another story. It's still pretty seriously robust, though.
Or mass
storage. Or whatever.
The communications front end handled a lot of the mundane tasks of
interfacing with terminals and transmitted in streams of character data to
and from the terminal rather than dealing withcharacter transfers.
And I really don't have that much of a
handle on how the architecture of
those sorts of machines differs from the micros I'm familiar with. Even
that bit of time I got to spend with the Heath H11 was very alien to the
rest of what I'm familiar with.
I realize that I'll never get as familiar with some of this stuff as some
of you guys that have actually worked with it, but can any of you point
me toward some resources that might let me understand some of it better
than I do now?
C. Gordon Bell's books are a good place to start. One oriented towards
DEC systems is at
http://research.microsoft.com/~GBell/CGB%20Files/Computer%20Engineering%207
809%20c.pdf
This book which is online covers all computers for the time it was published
and is very useful to read.
http://research.microsoft.com/~GBell/CGB%20Files/Computer%20Structures%20Pr
inciples%20and%20Examples%201982%20ng%20c.pdf Also on that site is a listing of computer companies
he compiled which
is very useful if you can't quite think of the name of the computer company
you have a part for. (off the subject but useful)
http://research.microsoft.com/~GBell/CGB%20Files/91_US_minicomputer_compani
es_1960-1982+44_minisupers_superminis_scalables_1983-1995.htm
I find his web site is useful in general to pour over for reading. The
links above are from books he has had put online since going to work for
Microsoft.
http://research.microsoft.com/~GBell/
I'll have a look there when the downloads are finished. Thanks for the
pointers...
--
Member of the toughest, meanest, deadliest, most unrelenting -- and
ablest -- form of life in this section of space, ?a critter that can
be killed but can't be tamed. ?--Robert A. Heinlein, "The Puppet Masters"
-
Information is more dangerous than cannon to a society ruled by lies. --James
M Dakin
11:05 p.m.
It was thus said that the Great Roy J. Tellason once stated:
On Tuesday 13 November 2007 01:58, jim s wrote:
Here's an example, using some old vintage home based computers. The Tandy
Color Computer had a serial port, but at the hardware level, it was
basically three one-bit ports, one bit for input, one bit for output, and
one for carrier detect. The code to transfer a byte looked something
like this (I don't have my notes handy at the moment):
BSR XMITLOW
LDA #byte-we-want-to-transfer
LDB #8 * 8 bits
LOOP RORA
BCS LOOP1
BSR XMITLOW
BRA LOOP2
LOOP1 BSR XMITHIGH
LOOP2 DECB
BNE LOOP
BSR SETHIGH
RTS
XMITLOW PSHS A,X
LDA #OUTPORTLOW
STA SERIALOUT
LDX BAUDPAUSE
BSR PAUSE
PULS A,X,PC
XMITHIGH PSHS A,X
LDA #OUTPORTHIGH
STA SERIALOUT
LDX BAUDPAUSE
BSR PAUSE
PULS A,X,PC
PAUSE LEAX -1,X
BNE PAUSE
RTS
Well, something close to that. Anyways, the upshot is that the CPU has to
spend the time serializing all the bits, sending it out the port, and
waiting around to make sure the timing is correct. That means that the
Color Computer can't be doing anything else while sending (and receiving for
that matter) data over the serial port. Add some intelligence (like the
8251 used in PCs (I think I got that right)) and sending now becomes
something like:
push ax
push dx
push si
mov si,[xmitbuffer]
lodsb
mov [xmitbuffer],si
mov dx,[serialport]
out dx,al
mov al,$20
out $20,al
pop si
pop dx
pop ax
rti
Here, the hardware can interrupt the PC when it's ready to send the data, so
all the PC has to do is give the UART the data, then signal the end of the
interrupt. The UART can then spend the time doing other things, like oh,
waiting for you to hit the keyboard. And it's easier to deal with; you just
need to write the data to the UART, and it handles all the nasty details.
You still might think this is a bit overkill, but it's nice to have. Very
nice.
The PCjr, unlike every other PC, had to have the CPU handle the serial
stream from the keyboard (much like the Color Computer having to deal with
the serial port above). Not much of an issue normally, but it did interfear
with disk IO, since the CPU had to handle THAT as well. So you couldn't
type while the disk was busy. And due to the lack of disk IO, that meant
that downloads where a bit slower than on a PC (since the PCjr couldn't save
the previous block of data as the next one was coming down).
An even better example is the C-64. The disk drives on that are
netoriously slow, but were computers in their own right, having a CPU as
part of the drive electronics. One trick (assuming you have at least two
disk drives) was to program the disk drives to copy a disk, thus leaving the
C-64 free for something else, like playing Mule.
-spc (Gah! I've forgotten the Return-From-Interrupt mnemonic for
Intels ... )
Multics was a virtual memory system. The nature
of this sort of system
was researched by students at MIT and ideas to enhance performance showed
that a lot of the activities could be carried out by subsystems which were
dedicated to just the specific task of moving data to and from the memory.
This is where I get a little puzzled sometimes. Like that BB2 I mentioned,
that uses DMA to send a string of bytes to the disk controller chip rather
than using the processor to do those transfers. Why is not immediately
apparent to me since the processor isn't doing anything else at that point
anyhow... 
11:17 p.m.
An even better example is the C-64. The disk drives
on that are
netoriously slow, but were computers in their own right, having a CPU as
part of the drive electronics. One trick (assuming you have at least two
disk drives) was to program the disk drives to copy a disk,
The 64 was emblematic of the best and worst features of this. The
intelligent serial peripherals could talk amongst each other, such as
the disk drive becoming commanded to TALK and the printer to LISTEN,
which is essentially a print spooler.
On the other hand, there was the 6551 ACIA emulation in software for
the user port, which was buggy to boot. People may make fun of the Plus/4
but at least it had a real ACIA.
--
------------------------------------ personal: http://www.cameronkaiser.com/ --
Cameron Kaiser * Floodgap Systems * www.floodgap.com * ckaiser at floodgap.com
-- 1-GHz Pentium-III + Java + XSLT == 1-MHz 6502. -- Craig Bruce --------------
15 Nov
15 Nov
4:29 a.m.
On Tuesday 13 November 2007 18:17, Cameron Kaiser wrote:
This reminds me of one particular disk-copying program, which would have the
lights on both drives on solid. You could, once you'd kicked off a copying
process, have unplugged the computer and it would just keep on going.
An even better
example is the C-64. The disk drives on that are
netoriously slow, but were computers in their own right, having a CPU as
part of the drive electronics. One trick (assuming you have at least two
disk drives) was to program the disk drives to copy a disk,
The 64 was emblematic of the best and worst features of this. The
intelligent serial peripherals could talk amongst each other, such as
the disk drive becoming commanded to TALK and the printer to LISTEN,
which is essentially a print spooler. On the other hand, there was the 6551 ACIA emulation
in software for
the user port, which was buggy to boot. People may make fun of the Plus/4
but at least it had a real ACIA.
They did? (Looking in handy box of manuals, but plus 4 isn't in there...)
--
Member of the toughest, meanest, deadliest, most unrelenting -- and
ablest -- form of life in this section of space, ?a critter that can
be killed but can't be tamed. ?--Robert A. Heinlein, "The Puppet Masters"
-
Information is more dangerous than cannon to a society ruled by lies. --James
M Dakin
4:47 a.m.
On 14 Nov 2007 at 23:29, Roy J. Tellason wrote:
This reminds me of one particular disk-copying
program, which would have the
lights on both drives on solid. You could, once you'd kicked off a copying
process, have unplugged the computer and it would just keep on going.
Both USB and SCSI have the device-to-device capability written into
some specs, but it's rarely implemented. ("USB on the go").
Cheers,
Chuck
5:20 a.m.
On Wednesday 14 November 2007 23:47, Chuck Guzis wrote:
On 14 Nov 2007 at 23:29, Roy J. Tellason wrote:
Which reminds me of a comment I saw somewhere about the possibility of having
a SCSI bus with more than one host adapter on it. Is that even possible?
--
Member of the toughest, meanest, deadliest, most unrelenting -- and
ablest -- form of life in this section of space, ?a critter that can
be killed but can't be tamed. ?--Robert A. Heinlein, "The Puppet Masters"
-
Information is more dangerous than cannon to a society ruled by lies. --James
M Dakin
This reminds me of one particular disk-copying
program, which would have
the lights on both drives on solid. You could, once you'd kicked off a
copying process, have unplugged the computer and it would just keep on
going.
Both USB and SCSI have the device-to-device capability written into
some specs, but it's rarely implemented. ("USB on the go"). 
5:36 a.m.
Roy J. Tellason wrote:
On Wednesday 14 November 2007 23:47, Chuck Guzis
wrote:
Possible, and has been done fairly often in storage arrays.
Google "multi-initiator scsi" and rock on. :)
Doc
On 14 Nov 2007 at 23:29, Roy J. Tellason wrote:
Which reminds me of a comment I saw somewhere about the possibility of having
a SCSI bus with more than one host adapter on it. Is that even possible? This reminds me of one particular disk-copying
program, which would have
the lights on both drives on solid. You could, once you'd kicked off a
copying process, have unplugged the computer and it would just keep on
going.
Both USB and SCSI have the device-to-device capability written into
some specs, but it's rarely implemented. ("USB on the go").
6:30 a.m.
On Thursday 15 November 2007 00:36, Doc Shipley wrote:
Possible, and has been done fairly often in storage arrays.
Google "multi-initiator scsi" and rock on. :)
Hehe. Did that and the first two hits say "not recommended" and "not
supported" in the text that google is showing me there...
Another thought, though, is that might make for some interesting
possibilities with that Bigboard II, which has that SASI port that seems (as
far as I can tell from just looking at signal names) to be fairly compatible
with SCSI, maybe hooking _that_ into a SCSI bus might have some serious
uses. Sure beats trying to transfer any nontrivial amount of data over a
serial link, and has the potential for going one heck of a lot faster!
So many things to look at, and never enough time...
--
Member of the toughest, meanest, deadliest, most unrelenting -- and
ablest -- form of life in this section of space, ?a critter that can
be killed but can't be tamed. ?--Robert A. Heinlein, "The Puppet Masters"
-
Information is more dangerous than cannon to a society ruled by lies. --James
M Dakin
Both USB and SCSI have the device-to-device capability
written into
some specs, but it's rarely implemented. ("USB on the go").
Which reminds me of a comment I saw somewhere about the possibility of
having a SCSI bus with more than one host adapter on it. Is that even
possible? 
3:32 p.m.
Roy J. Tellason wrote:
On Thursday 15 November 2007 00:36, Doc Shipley
wrote:
Possible, and has been done fairly often in storage arrays.
Google "multi-initiator scsi" and rock on. :)
Hehe. Did that and the first two hits say "not recommended" and "not
supported" in the text that google is showing me there...
I've got a feeling there's not even the code there for it Linux - it just
doesn't know how to handle commands sent to the HBA at all. Few years ago when
I looked though; maybe it's different now...
It's certainly technically possible - I used to look after a pair of SGI O200
machines which have a bunch of disk storage shared between them on the same
SCSI bus.
Both USB and SCSI have the device-to-device capability
written into
some specs, but it's rarely implemented. ("USB on the go").
Which
reminds me of a comment I saw somewhere about the possibility of
having a SCSI bus with more than one host adapter on it. Is that even
possible? Another thought, though, is that might make for some
interesting
possibilities with that Bigboard II, which has that SASI port that seems (as
far as I can tell from just looking at signal names) to be fairly compatible
with SCSI, maybe hooking _that_ into a SCSI bus might have some serious
uses.
Hmm. I think SASI's sufficiently different that you'd be hacking your own SCSI
drivers to do it - from memory there were some extra phases in the SCSI
protocol which weren't in SASI. That's assuming whatever HBA you use doesn't
try and do the work for you and then barf because the device isn't SCSI. Plus
I don't think SASI had any concept of parity, so you'd probably have to hack a
bit of hardware there to generate the parity bit (assuming you couldn't
disable it via software).
Note that Linux chokes on devices that don't respond to the identify command -
which is every SASI device and some early SCSI ones too. I'm not sure how
deeply set that is into the 'core' SCSI layer, but I don't think it's down
to
driver behaviour (i.e. you can't get around it by hacking your own HBA
driver). No idea what other OSes are like...
I'm sure it *could* be done though, but it's a reasonable amount of work. It'd
be simpler to build your own SASI interface and drive it from a suitable I/O
board (a PC parallel port doesn't quite have enough lines unfortunately) from
user-land. After all, the sort of data transfer rates for SASI stuff isn't
exactly blinding, so some sort of polled-I/O bit-twiddling should be good enough.
Sure beats trying to transfer any nontrivial amount
of data over a
serial link, and has the potential for going one heck of a lot faster!
Been there done that with a few ST-412 drives (via Adaptec SCSI bridge
boards). Think it was about 8 hours per 20MB or thereabouts.
So many things to look at, and never enough time...
Yep... I got a PC SASI interface all designed and then halfway wired up ages
ago, then just haven't had the time to do anything more with it for 6 months
or so :-(
cheers
Jules
6:19 p.m.
On Thursday 15 November 2007 10:32, Jules Richardson wrote:
Yikes.
And I'm due to start a new job shortly, which also involves a couple of hours
a day drive time, which is only going to make it worse.
--
Member of the toughest, meanest, deadliest, most unrelenting -- and
ablest -- form of life in this section of space, ?a critter that can
be killed but can't be tamed. ?--Robert A. Heinlein, "The Puppet Masters"
-
Information is more dangerous than cannon to a society ruled by lies. --James
M Dakin
Roy J. Tellason wrote:
I saw some mention in there someplace of support in the kernel, but they
weren't very explicit about support for what, exactly.
On Thursday 15 November 2007 00:36, Doc Shipley
wrote:
Hehe. Did that and the first two hits say "not recommended" and "not
supported" in the text that google is showing me there...
I've got a feeling there's not even the code there for it Linux - it just
doesn't know how to handle commands sent to the HBA at all. Few years ago
when I looked though; maybe it's different now... > Both
USB and SCSI have the device-to-device capability written into
> some specs, but it's rarely implemented. ("USB on the go").
Which reminds me of a comment I saw somewhere about the possibility of
having a SCSI bus with more than one host adapter on it. Is that even
possible?
Possible, and has been done fairly often in storage arrays.
Google "multi-initiator scsi" and rock on. :) It's certainly technically possible - I used to
look after a pair of SGI
O200 machines which have a bunch of disk storage shared between them on the
same SCSI bus.
Yeah, but you're talking protocol, of which there currently isn't any at the
BBII end.
Another thought, though, is that might make for
some interesting
possibilities with that Bigboard II, which has that SASI port that seems
(as far as I can tell from just looking at signal names) to be fairly
compatible with SCSI, maybe hooking _that_ into a SCSI bus might have
some serious uses.
Hmm. I think SASI's sufficiently different that you'd be hacking your own
SCSI drivers to do it - from memory there were some extra phases in the
SCSI protocol which weren't in SASI. That's assuming whatever HBA you use doesn't
try and do the work for you and
then barf because the device isn't SCSI.
Thankfully I seem to have a number of different choices available to me here.
Plus I don't think SASI had any concept of parity,
so you'd probably have to
hack a bit of hardware there to generate the parity bit (assuming you
couldn't disable it via software).
I'm not sure what the deal is with that offhand.
Note that Linux chokes on devices that don't
respond to the identify
command - which is every SASI device and some early SCSI ones too. I'm not
sure how deeply set that is into the 'core' SCSI layer, but I don't think
it's down to driver behaviour (i.e. you can't get around it by hacking your
own HBA driver). No idea what other OSes are like...
I'm sure it's in the source tree somewhere, but I haven't dug into that at
all lately and have no idea where it might be located, if it's even in
there.
I'm sure it *could* be done though, but it's a
reasonable amount of work.
It'd be simpler to build your own SASI interface and drive it from a
suitable I/O board (a PC parallel port doesn't quite have enough lines
unfortunately) from user-land. After all, the sort of data transfer rates
for SASI stuff isn't exactly blinding, so some sort of polled-I/O
bit-twiddling should be good enough.
I'm not sure I'm up to building hardware to sit on the peecee side of things,
though.
Sure beats
trying to transfer any nontrivial amount of data over a
serial link, and has the potential for going one heck of a lot faster!
Been there done that with a few ST-412 drives (via Adaptec SCSI bridge
boards). Think it was about 8 hours per 20MB or thereabouts. So many things
to look at, and never enough time...
Yep... I got a PC SASI interface all designed and then halfway wired up
ages ago, then just haven't had the time to do anything more with it for 6
months or so :-(
6:37 p.m.
On 15 Nov 2007 at 13:19, Roy J. Tellason wrote:
I'm not sure I'm up to building hardware to
sit on the peecee side of things,
though.
I have an old Ampex SASI card for the PC that you're welcome to. It
has a BIOS EPROM, but you'll have to figure out how it works--I
haven't much more than a pinout on the 50-pin header on it--but it's
all MSI TTL 7400 stuff; no PALS or ROMS. But you can also get a data
acquisition board with several 8255s on it in either ISA or PCI and
just use that (I know that some hate the 8255, but it shouldn't be a
problem in this application).
If you have ISA slots, building a SASI adapter is easy with a
prototype card that does all of the signal decoding for you.
Cheers,
Chuck
8 p.m.
On Thursday 15 November 2007 10:32, Jules Richardson wrote:
Roy J. Tellason wrote:
There's a generic framework for implementing SCSI targets on SCSI/FC
cards in Linux:
http://scst.sf.net
It requires changes to host adapter drivers in most cases, but they have
some target-enabled drivers in the project for a couple of cards.
Now, it's meant to let you export "LUNS" over SCSI or FC, so you could
implement a software raid controller on a Linux box, but you could use
it to do whatever you wanted, with enough extra programming. :)
Pat
--
Purdue University ITAP/RCAC --- http://www.rcac.purdue.edu/
The Computer Refuge --- http://computer-refuge.org
On Thursday 15 November 2007 00:36, Doc Shipley
wrote:
Hehe. Did that and the first two hits say "not recommended" and
"not supported" in the text that google is showing me there...
I've got a feeling there's not even the code there for it Linux - it
just doesn't know how to handle commands sent to the HBA at all. Few
years ago when I looked though; maybe it's different now... > Both
USB and SCSI have the device-to-device capability written
> into some specs, but it's rarely implemented. ("USB on the
> go").
Which reminds me of a comment I saw somewhere about the
possibility of having a SCSI bus with more than one host adapter
on it. Is that even possible?
Possible, and has been done fairly often in storage arrays.
Google "multi-initiator scsi" and rock on. :)
5:37 a.m.
On 15 Nov 2007 at 0:20, Roy J. Tellason wrote:
Which reminds me of a comment I saw somewhere about
the possibility of having
a SCSI bus with more than one host adapter on it. Is that even possible?
Absolutely, as long as the two (or more) host adapters have different
addresses. There are some computer systems that share disk units in
that manner. Of course, the driver software on all hosts needs to be
aware of the need. AFAIK, one can even talk controller-to-
controller.
The problem with multiple controllers arises when low-end or spottily
implemented driver software is used. For example, it's the rare
cheap SCSI card that will respond to an IDENTIFY--or even allow one
to change the host address.
Let's see ya do that with IDE/ATA!
Cheers,
Chuck
6:36 a.m.
On Thursday 15 November 2007 00:37, Chuck Guzis wrote:
On 15 Nov 2007 at 0:20, Roy J. Tellason wrote:
What I was thinking...
Which reminds me of a comment I saw somewhere
about the possibility of
having a SCSI bus with more than one host adapter on it. Is that even
possible?
Absolutely, as long as the two (or more) host adapters have different
addresses. There are some computer systems that share disk units in
that manner. Of course, the driver software on all hosts needs to be
aware of the need. AFAIK, one can even talk controller-to-
controller. The problem with multiple controllers arises when
low-end or spottily
implemented driver software is used.
I guess that depends on what platform we're talking too. I really hate the
idea of having to just go out and snag a driver off the 'net for something
and hope it works (the usual windoze approach?) but with linux being one of
the platforms in question the source is right at hand.
For example, it's the rare cheap SCSI card that
will respond to an
IDENTIFY--
That a software or hardware issue? (It's been a *really* long time since I've
looked at the details of that stuff.)
or even allow one to change the host address.
I don't think I've had too much of a problem with that, but then most of what
I have on hand here is Adaptec stuff, some of it ISA, some PCI. And then
as I mentioned in that other post, there's the SASI port on the BIgboard II,
which at this point is nothing at all, but seems to offer some nontrivial
potential...
Let's see ya do that with IDE/ATA!
:-)
The only reason I use as much of that stuff as I do is because I keep getting
it basically for free. And it's handy. But I am accumulating a pile of
SCSI stuff too. Including a whole mess of 2G drives -- anybody have a need
for those?
--
Member of the toughest, meanest, deadliest, most unrelenting -- and
ablest -- form of life in this section of space, ?a critter that can
be killed but can't be tamed. ?--Robert A. Heinlein, "The Puppet Masters"
-
Information is more dangerous than cannon to a society ruled by lies. --James
M Dakin
4:54 p.m.
But I am accumulating a pile of SCSI stuff too.
Including a whole
mess of 2G drives -- anybody have a need for those?
Need, no, but I do find 2G plenty big enough to be useful; if you're
planning on tossing 'em, let's see if we can't work out a rescue
mission for at least some of them.
/~\ The ASCII der Mouse
\ / Ribbon Campaign
X Against HTML mouse at rodents.montreal.qc.ca
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
6:22 p.m.
On Thursday 15 November 2007 11:54, der Mouse wrote:
I don't, as a general rule, toss stuff like that as long as it still works.
And sometimes not even when it doesn't, if I can get some useful bits out of
it.
I mentioned it in here because it came up in conversation with somebody in the
list a while back and they said something about the 1-2G range of sizes being
particularly useful for some things, though I can't recall at the moment
just what those things were offhand.
--
Member of the toughest, meanest, deadliest, most unrelenting -- and
ablest -- form of life in this section of space, ?a critter that can
be killed but can't be tamed. ?--Robert A. Heinlein, "The Puppet Masters"
-
Information is more dangerous than cannon to a society ruled by lies. --James
M Dakin
But I am
accumulating a pile of SCSI stuff too. Including a whole
mess of 2G drives -- anybody have a need for those?
Need, no, but I do find 2G plenty big enough to be useful; if you're
planning on tossing 'em, let's see if we can't work out a rescue
mission for at least some of them.
6:35 a.m.
Which reminds me of a comment I saw somewhere about
the possibility
of having a SCSI bus with more than one host adapter on it. Is that
even possible?
Yes.
However, a lot of host adapters do not support target mode, and some
don't even support using an ID other than 7. The former is somewhere
between ignorable and fatally crippling, depending on what you want to
do; the latter is fatal. (Well, almost; I have toyed with the idea of
wiring up the data lines in a different order, and permuting the bits
in software to make up for it, so that each bit of SCSI hardware thinks
it is ID 7. But I've never tried doing it; it's possible there's some
reason it couldn't work....)
After all, the only special thing about a host adapter is that it
usually is an initiator rather than a target (in most systems, it is
the only device that is ever an initiator, and is never a target).
/~\ The ASCII der Mouse
\ / Ribbon Campaign
X Against HTML mouse at rodents.montreal.qc.ca
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
8:30 a.m.
On Thu, 2007-11-15 at 00:20 -0500, Roy J. Tellason wrote:
On Wednesday 14 November 2007 23:47, Chuck Guzis
wrote:
It's done all the time with samplers. A sampler and a computer can
share a disk as long as only one is using it, and the sampler can flip
to being a target so you can blat samples across from the computer very
quickly.
Gordon
On 14 Nov 2007 at 23:29, Roy J. Tellason wrote:
Which reminds me of a comment I saw somewhere about the possibility of having
a SCSI bus with more than one host adapter on it. Is that even possible? This reminds me of one particular disk-copying
program, which would have
the lights on both drives on solid. You could, once you'd kicked off a
copying process, have unplugged the computer and it would just keep on
going.
Both USB and SCSI have the device-to-device capability written into
some specs, but it's rarely implemented. ("USB on the go"). 
11:56 a.m.
On 15/11/2007, at 4:20 PM, Roy J. Tellason wrote:
Which reminds me of a comment I saw somewhere about the possibility
of having
a SCSI bus with more than one host adapter on it. Is that even
possible?
VMS has allowed SCSI clusters for quite a while that allow multiple
host adapters - typically you set the first host adapter to address 7
and the next to 6 (and I guess 5 if you have three hosts - I've only
done it with two).
This has been re-invented for Integrity (aka Itanium) servers but I
think it's limited to two hosts.
Works and works well with supported SCSI adapters.
Huw Davies | e-mail: Huw.Davies at kerberos.davies.net.au
Melbourne | "If soccer was meant to be played in the
Australia | air, the sky would be painted green"
2:37 p.m.
Huw Davies wrote:
Works even better with DSSI, since disks can be quorum members.
Peace... Sridhar
Which reminds
me of a comment I saw somewhere about the possibility of
having
a SCSI bus with more than one host adapter on it. Is that even possible?
VMS has allowed SCSI clusters for quite a while that allow multiple host
adapters - typically you set the first host adapter to address 7 and the
next to 6 (and I guess 5 if you have three hosts - I've only done it
with two).
This has been re-invented for Integrity (aka Itanium) servers but I
think it's limited to two hosts.
Works and works well with supported SCSI adapters. 
2:19 p.m.
Roy J. Tellason wrote:
Which reminds me of a comment I saw somewhere about
the possibility
of having a SCSI bus with more than one host adapter on it. Is that
even possible?
I'm sure that there was talk of having VMS Clustering running over
a SCSI interconnect. I think the main problem with using it for
VAXen was that most of them (all of them?) would reset the SCSI bus
whenever they felt like it. For Alphas, though, it was certainly
possible to do this. I don't recall whether the code was ever
released though ...
Antonio
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.5.503 / Virus Database: 269.15.33/1132 - Release Date:
15/11/2007 09:34
2:24 p.m.
Roy J. Tellason wrote:
Which reminds me of a comment I saw somewhere about the possibility of having
a SCSI bus with more than one host adapter on it. Is that even possible?
Yes. I've had machines talking to each other over a SCSI bus. If
memory serves, one had to be configured as the master and the others as
targets.
Peace... Sridhar
This reminds me of one particular disk-copying
program, which would have
the lights on both drives on solid. You could, once you'd kicked off a
copying process, have unplugged the computer and it would just keep on
going.
Both USB and SCSI have the device-to-device capability written into
some specs, but it's rarely implemented. ("USB on the go"). 
2:59 p.m.
On Nov 15, 2007, at 12:20 AM, Roy J. Tellason wrote:
Which reminds me of a comment I saw somewhere about the possibility
of having
a SCSI bus with more than one host adapter on it. Is that even
possible?
Absolutely...SCSI is a (mostly) peer-to-peer bus. You can easily
set up multiple "masters" ("initiators" in SCSI parlance) on a SCSI
bus if the hardware implements the spec in a reasonable way and the
OS' drivers can do something useful with the capability.
Communication between host adapters is also possible; I'm sure
I've even heard of "IP over SCSI" having been implemented.
-Dave
--
Dave McGuire
Port Charlotte, FL
Farewell Ophelia, 9/22/1991 - 7/25/2007
This reminds me of one particular disk-copying
program, which
would have
the lights on both drives on solid. You could, once you'd
kicked off a
copying process, have unplugged the computer and it would just
keep on
going.
Both USB and SCSI have the device-to-device capability written into
some specs, but it's rarely implemented. ("USB on the go").
5:56 p.m.
On Thursday 15 November 2007 10:49, Doc Shipley wrote:
Dave McGuire wrote:
There appears to be a sourceforge page on it, but the latest date on there is
in 2001...
--
Member of the toughest, meanest, deadliest, most unrelenting -- and
ablest -- form of life in this section of space, ?a critter that can
be killed but can't be tamed. ?--Robert A. Heinlein, "The Puppet Masters"
-
Information is more dangerous than cannon to a society ruled by lies. --James
M Dakin
Communication between host adapters is also
possible; I'm sure I've
even heard of "IP over SCSI" having been implemented.
There was an IP over SCSI project for Linux awhile back. Cheap[er]
FC pretty much killed it, I think. 
8:46 p.m.
On 15/11/2007 15:49, Doc Shipley wrote:
Dave McGuire wrote:
There was an IP over SCSI project for Linux awhile
back. Cheap[er] FC
pretty much killed it, I think.
This can get quite amusing, because not only is there a standard for IP
over SCSI, there's one for SCSI over IP.
--
Pete Peter Turnbull
Network Manager
University of York
9:06 p.m.
Pete Turnbull wrote:
SCSI over IP over SCSI, anyone?
Peace... Sridhar
There was an
IP over SCSI project for Linux awhile back. Cheap[er]
FC pretty much killed it, I think.
This can get quite amusing, because not only is there a standard for IP
over SCSI, there's one for SCSI over IP. 
9:23 p.m.
On Thu, 15 Nov 2007, woodelf wrote:
Sridhar Ayengar wrote:
Rafting photographers have been known to do that. See
http://en.wikipedia.org/wiki/IP_over_Avian_Carriers.
--
David Griffith
dgriffi at cs.csubak.edu
A: Because it fouls the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?
SCSI over IP over SCSI, anyone?
I think
getting a carrier pidgen to carry you data would be faster
than waiting for the software development.Just stick it on a USB
stick and find a bird going in the right direction. :)
9:29 p.m.
woodelf wrote:
iSCSI over CPIP! What an idea!
Peace... Sridhar
SCSI over IP
over SCSI, anyone?
I think getting a carrier pidgen to carry you data would be
faster
than waiting for the software development.Just stick it on a USB
stick and find a bird going in the right direction. :)
9:30 p.m.
Pete Turnbull wrote:
On 15/11/2007 15:49, Doc Shipley wrote:
Both of which could be described as "solutions looking for a problem"....
I get to work with a lot of iSCSI storage. I've grown to loathe it,
mostly because it's usually either not suited to the need, or just plain
misconfigured. Or both.
Doc
Dave McGuire wrote:
There was an IP over SCSI project for Linux
awhile back. Cheap[er]
FC pretty much killed it, I think.
This can get quite amusing, because not only is there a standard for IP
over SCSI, there's one for SCSI over IP.
10:02 p.m.
On Thu, 2007-11-15 at 15:30 -0600, Doc Shipley wrote:
Pete Turnbull wrote:
Take a look at AoE - ATA over Ethernet. The spec for it is eight pages
long, and is basically describing an ATA packet wrapped in an Ethernet
frame.
Hm. Can you get at raw Ethernet frames with a DEQNA or DELQA card?
Looks like RT-11 disk drivers are nice and simple...
Gordon
On 15/11/2007 15:49, Doc Shipley wrote:
Both of which could be described as "solutions looking for a problem"....
I get to work with a lot of iSCSI storage. I've grown to loathe it,
mostly because it's usually either not suited to the need, or just plain
misconfigured. Or both. Dave McGuire wrote:
There was an IP over SCSI project for Linux
awhile back. Cheap[er]
FC pretty much killed it, I think.
This can get quite amusing, because not only is there a standard for IP
over SCSI, there's one for SCSI over IP.
16 Nov
16 Nov
12:28 a.m.
On Thu, 2007-11-15 at 14:26 -0800, Chuck Guzis wrote:
On 15 Nov 2007 at 22:02, Gordon JC Pearce wrote:
Yeah, coupled to a single-platter 33 1/3rpm drive...
Gordon
Take a look at AoE - ATA over Ethernet. The spec
for it is eight pages
long, and is basically describing an ATA packet wrapped in an Ethernet
frame.
How about ATAoAL? ATA over Aldis Lamp? Should be doable...
15 Nov
15 Nov
8:43 p.m.
On 15/11/2007 14:59, Dave McGuire wrote:
I can't remember if it was Cumana or SJ Research, but one of those
companies had a system where a disk was shared on a single SCSI bus
between multiple BBC Micros (or maybe Archimedes) and the bus was also
used as a sort of network between the computers. As I recall it, the
principle limitation in practice wasn't the obvious one of 8 devices on
a narrow SCSI bus, but how close together the machines had to be because
of the limited length you could make the bus.
--
Pete Peter Turnbull
Network Manager
University of York
On Nov 15, 2007, at 12:20 AM, Roy J. Tellason wrote:
Which reminds
me of a comment I saw somewhere about the possibility of
having
a SCSI bus with more than one host adapter on it. Is that even possible?
Absolutely...SCSI is a (mostly) peer-to-peer bus. You can easily set
up multiple "masters" ("initiators" in SCSI parlance) on a SCSI bus
if
the hardware implements the spec in a reasonable way and the OS' drivers
can do something useful with the capability.
Communication between host adapters is also possible; I'm sure I've
even heard of "IP over SCSI" having been implemented.
6:43 a.m.
On the other
hand, there was the 6551 ACIA emulation in software for
the user port, which was buggy to boot. People may make fun of the Plus/4
but at least it had a real ACIA.
They did? (Looking in handy box of manuals, but plus 4 isn't in there...)
7:01 a.m.
New subject: Multics thread a bit off topic... can someone re-title it to Multi Processor (maybe i missed three or 4 other threads too).
The Multics source code release will let people enjoy such fun stories
as the Latin error message that came out occasionally when booting the
system
http://www.multicians.org/hodie-natus-est.html
I believe there are quite a number of source modules with Latin comments
as well.
I know that a lot of people have concerns about an emulator being
possible due to the number of processors that have to be emulated, but
one only has to look as far as the Mame emulator to see that is not so
big a deal. The real problem will be finding the information to figure
out what each component really has to do, since Multics was a study in
how to get things working even if it was not working so well.
Not exactly the approach that can be used for IBM hardware used where
one just has to have access to the POO and you can get an emulator
pretty much going.
Jim
7:37 a.m.
On Thursday 15 November 2007 01:43, Cameron Kaiser wrote:
Yup. Memory escapes me, but I think Commodore even managed to screw that up
somehow with some lines missing or something (Jim Brain might know, I can't
find my Plus/4 notes a/t/m). Still, I used a Plus/4 as a terminal for
awhile until I got a SwiftLink. That Plus/4 even did the apartment budget
back then. Not a bad computer, and the graphics were nice, just strange and
incompatible.
I have some number of those in storage, but don't recall what the problems
were with them. I might even have one that works, though I'm not at all
sure about that. They were nice compact little cases, for sure, much more
nicely made than the c64 was. But when those started hitting the shop we
were starting to slide out of the c= business, and I don't think I ever did
see a c16 come in there.
--
Member of the toughest, meanest, deadliest, most unrelenting -- and
ablest -- form of life in this section of space, ?a critter that can
be killed but can't be tamed. ?--Robert A. Heinlein, "The Puppet Masters"
-
Information is more dangerous than cannon to a society ruled by lies. --James
M Dakin
On the other hand, there was the 6551 ACIA emulation
in software for
the user port, which was buggy to boot. People may make fun of the
Plus/4 but at least it had a real ACIA.
They did? (Looking in handy box of manuals, but plus 4 isn't in
there...) 
8:32 a.m.
New subject: Intellegent peripherals (was Re: MIT provides MULTICS source and documentation (DPS-8 simulation))
On Wed, Nov 14, 2007 at 11:29:59PM -0500, Roy J. Tellason wrote:
On Tuesday 13 November 2007 18:17, Cameron Kaiser
wrote:
This reminds me of one particular disk-copying program, which would have the
lights on both drives on solid. You could, once you'd kicked off a copying
process, have unplugged the computer and it would just keep on going.
The PET was even better for that... in the case of the C-64, you could load
a small copier program into an unused buffer on each drive to do manage
reading and writing each sector without the C-64 itself participating, but
it meant that you couldn't then use the bus for something else, printing,
say.
Until the 2031, PET IEEE drives were dual-drive units, presumably to
amortize the cost of the intellegent controller, the power supply, the
case, over two spindles (a dual 5.25" ~170K-diskette drive was well over
the cost of the computer it was attached to in 1979, in the range of $2200).
The DOS for the 2040/3040/4040/8050/8250 drives had a "copy drive N to drive
M" command (I'd quote chapter and verse, but I don't have access to the
'net
right now). One of the CPUs on the drive (before the 1540, there were
multiple 6502-family CPUs in the box) would read one drive, then write
that buffer to the other drive without extra buffer copying and without
putting the traffic on the bus. You could then, say, use your IEEE-488
acoustic coupler to logon to a BBS while disks were copying, or print to a
printer, or whatever, since the IEEE bus was not involved in that disk-to-disk
copy.
Yes, the C-64 could do it, and yes, it was cheaper than the way the PET
did it, but it wasn't the first nor was it the fastest.
-ethan
--
Ethan Dicks, A-333-S Current South Pole Weather at 15-Nov-2007 at 08:21 Z
South Pole Station
PSC 468 Box 400 Temp -41.3 F (-40.7 C) Windchill -65.9 F (-54.4 C)
APO AP 96598 Wind 7.9 kts Grid 119 Barometer 681.6 mb (10568 ft)
Ethan.Dicks at usap.gov http://penguincentral.com/penguincentral.html
An even
better example is the C-64. The disk drives on that are
netoriously slow, but were computers in their own right, having a CPU as
part of the drive electronics. One trick (assuming you have at least two
disk drives) was to program the disk drives to copy a disk,
The 64 was emblematic of the best and worst features of this. The
intelligent serial peripherals could talk amongst each other, such as
the disk drive becoming commanded to TALK and the printer to LISTEN,
which is essentially a print spooler. 
2:16 p.m.
New subject: C64 w/2+ disk drives (was: Re: MIT provides MULTICS source)
And thusly were the wise words spake by Roy J. Tellason
On Tuesday 13 November 2007 18:17, Cameron Kaiser wrote:
This reminds me of one particular disk-copying program, which would have the
lights on both drives on solid. You could, once you'd kicked off a copying
process, have unplugged the computer and it would just keep on going.
I believe there were a few disk-copying programs like this that would
also prompt you to change disks by flashing the LEDs in some way.
Cheers,
Bryan
An even
better example is the C-64. The disk drives on that are
netoriously slow, but were computers in their own right, having a CPU as
part of the drive electronics. One trick (assuming you have at least two
disk drives) was to program the disk drives to copy a disk,
The 64 was emblematic of the best and worst features of this. The
intelligent serial peripherals could talk amongst each other, such as
the disk drive becoming commanded to TALK and the printer to LISTEN,
which is essentially a print spooler. 
2:30 p.m.
New subject: C64 w/2+ disk drives (was: Re: MIT provides MULTICS source)
2007/11/15, Bryan Pope <bpope at wordstock.com>:
I believe there were a few disk-copying programs like
this that would
also prompt you to change disks by flashing the LEDs in some way.
..Or to inform you that your disk was truly fsck'ed.
2:49 p.m.
New subject: C64 w/2+ disk drives (was: Re: MIT provides MULTICS source)
I believe there were a few disk-copying programs like
this that would
also prompt you to change disks by flashing the LEDs in some way.
Didn't the MSD AutoCopy ROMs do that too? I have an AutoCopy MSD around here
somewhere but all I can find is my "virgin" MSD right now.
--
------------------------------------ personal: http://www.cameronkaiser.com/ --
Cameron Kaiser * Floodgap Systems * www.floodgap.com * ckaiser at floodgap.com
-- The new Tourette Syndrome movie: Twitch and Shout! -- John Waters ----------
3:10 p.m.
New subject: C64 w/2+ disk drives
And thusly were the wise words spake by Cameron Kaiser
Hmm.. I wonder if my MSD Dual disk drive has that as it has a little
box attached to it that has a switch and a push-button. Maybe that
is why only one drive in it works when I tested it last.
Cheers,
Bryan
I believe there were a few disk-copying programs
like this that would
also prompt you to change disks by flashing the LEDs in some way.
Didn't the MSD AutoCopy ROMs do that too? I have an AutoCopy MSD around here
somewhere but all I can find is my "virgin" MSD right now.
4:20 p.m.
New subject: C64 w/2+ disk drives
Bryan Pope wrote:
And thusly were the wise words spake by Roy J.
Tellason
Fast Hack 'Em did both of these. There was a 1541 Auto-Copy feature.
It would work with drives that were all set to Device 8 (the default).
You would load the program from the FHM boot screen (Option M or so)
It would ask you to turn off one drive, and hit enter. That would load
the code into what would end up as device 9, and soft change the dev number
You would turn back on the other drive, and it would load the code into
that drive
Then, it would ask you to unplug the 64 from the drives.
The drives then checked the write protect signal of the source drive to
understand when a disk was inserted.
The LEDs would blink during formatting and copying ina regular way.
When you were changing disks and when it was preparing to start, it
would toggle the LEDs in a pattern that provided feedback.
A little known fact with FHM is that the first step of assigning soft
dev number 9 and loading code to the target drive would work with
multiple drives. It was possible to chain 4 or 5 drives off a 64 and
turn off 1 drive (the source), allowing 3 or 4 drives to become
"targets". Then, you would end up making multiple copies of a source disk.
knowing what I now know about the Commodore IEC protocol, I am amazed
that works. I can only assume that FHM specifically planned for that to
occur.
Jim
--
Jim Brain, Brain Innovations (X)
brain at jbrain.com
Dabbling in WWW, Embedded Systems, Old CBM computers, and Good Times!
Home: http://www.jbrain.com
On Tuesday 13 November 2007 18:17, Cameron Kaiser
wrote:
This reminds me of one particular disk-copying program, which would have
the
lights on both drives on solid. You could, once you'd kicked off a copying
process, have unplugged the computer and it would just keep on going.
I believe there were a few disk-copying programs like this that would
also prompt you to change disks by flashing the LEDs in some way.
Cheers,
Bryan
An even
better example is the C-64. The disk drives on that are
netoriously slow, but were computers in their own right, having a CPU as
part of the drive electronics. One trick (assuming you have at least two
disk drives) was to program the disk drives to copy a disk,
The 64 was emblematic of the best and worst features of this. The
intelligent serial peripherals could talk amongst each other, such as
the disk drive becoming commanded to TALK and the printer to LISTEN,
which is essentially a print spooler.
16 Nov
16 Nov
1:14 a.m.
New subject: "intelligent" disk drives
the C= disk drives were pretty much all smart drives weren't they? the big dual
drive units had a controller card in them that was basically a small computer (IIRC)
also Atari disk drives had a 650x IIRC in them as well as a disk controller chip
(once again IIRC.)
1:29 a.m.
New subject: "intelligent" disk drives
On Thu, Nov 15, 2007 at 05:14:34PM -0800, Geoff Reed wrote:
the C= disk drives were pretty much all smart drives
weren't they?
Yes.
the big dual drive units had a controller card in
them that was
basically a small computer (IIRC)
"Controller card" might not be the best term, but yes, there was a
one board inside with one or more 6502-family microprocessors
(depending on the drive model). Older, dual drives tended to have
a couple of processors (6504s were common) with a few K of shared
memory; newer drives tended towards one microprocessor (a full 6502
was common), with a software scheme to simulate the multi-processor
model of the older drives.
The older, dual drives also had one analog board for both drive
mechanisms. Newer drives had the analog circuitry on the mainboard
with the processor.
-ethan
--
Ethan Dicks, A-333-S Current South Pole Weather at 16-Nov-2007 at 01:20 Z
South Pole Station
PSC 468 Box 400 Temp -40.9 F (-40.5 C) Windchill -68.0 F (-55.6 C)
APO AP 96598 Wind 9.7 kts Grid 139 Barometer 680.6 mb (10606 ft)
Ethan.Dicks at usap.gov http://penguincentral.com/penguincentral.html
1:49 a.m.
New subject: "intelligent" disk drives
At 07:29 PM 11/15/2007, Ethan Dicks wrote:
On Thu, Nov 15, 2007 at 05:14:34PM -0800, Geoff Reed
wrote:
While dumpster-diving the just-closed Los Gatos office of Amiga,
I found a 1541. Afterwards I asked one of the engineers about
it and he said that the 1541 was one of the better computers
made by Commodore. I think he was joking, of course, given the
horrendous bottlenecks in its software and its bus protocol.
That night, the Amiga sign from the front lawn disappeared and somehow
made its way to Topeka.
- John
the C= disk drives were pretty much all smart
drives weren't they?
Yes. 
17 Nov
17 Nov
12:40 a.m.
New subject: "intelligent" disk drives
[CBM disk drives]
"Controller card" might not be the best
term, but yes, there was a
one board inside with one or more 6502-family microprocessors
(depending on the drive model). Older, dual drives tended to have
a couple of processors (6504s were common) with a few K of shared
memory; newer drives tended towards one microprocessor (a full 6502
was common), with a software scheme to simulate the multi-processor
model of the older drives.
The older, dual drives also had one analog board for both drive
mechanisms. Newer drives had the analog circuitry on the mainboard
with the processor.
I've never seen a 2031, but all the GPIB-interfaces double drives contain
2 processors I think. The 8050/8250 contain a pair of full 6502s, one to
handle the disk data itself, the other the run the DOS and talk to the
GPIB port. They communicate via shared memory, IIRC 4K of it (the unit
uses the well-known trick that a 6502 only drives the address lines when
the clock input is in one of its states, so by feeding inverse clocks to
the 2 processors you can easily get them to interleave access to memory).
The control processor ROM is in one of those 6530 RRIOT chips, which
makes replaicng it a little problematic, although my 8250LP (half-height
drives, plastic case) has a daughterboard in the 6530 socket containing,
IIRC, a 6530, the ROM part of which is never addressed and a normal ROM
chip, along with a very little glue logic.
In all the GPIB dual drives that I've seen, therre is a separate
'analogue board' containing the motor control circuits, the read/write
chain, etc.
The serial-interfaced drives used in the C64 processor contain a single
processor (6502 in all that I've seen) and have all the electronics
(apart from the spindle motor control) on one PCB.
-tony
1:42 a.m.
New subject: "intelligent" disk drives
On Sat, Nov 17, 2007 at 12:40:25AM +0000, Tony Duell wrote:
I've never seen a 2031, but all the
GPIB-interfaces double drives contain
2 processors I think.
The 2031 is very much like a 1541, but with an IEEE-488 interface rather
than C= IEC.
The 8050/8250 contain a pair of full 6502s, one to
handle the disk data itself, the other the run the DOS and talk to the
GPIB port. They communicate via shared memory, IIRC 4K of it (the unit
uses the well-known trick that a 6502 only drives the address lines when
the clock input is in one of its states, so by feeding inverse clocks to
the 2 processors you can easily get them to interleave access to memory).
Prior to the 8050/8250, I think the arrangement was one 6502 to talk to
the bus, and one 6504 to talk to the drives, but in other respects, the
same.
The control processor ROM is in one of those 6530
RRIOT chips, which
makes replaicng it a little problematic...
I have, I think, a full set of 2040 ROMs, including the right 6530, but
most of my pre-8050 drives were originally 2040s that were later upgraded
to the same ROMs as a 4040 (the only difference AFAIK is the label on the
outside).
although my 8250LP (half-height
drives, plastic case) has a daughterboard in the 6530 socket containing,
IIRC, a 6530, the ROM part of which is never addressed and a normal ROM
chip, along with a very little glue logic.
I have seen those daughterboards before.
In all the GPIB dual drives that I've seen, therre
is a separate
'analogue board' containing the motor control circuits, the read/write
chain, etc.
Yes.
The serial-interfaced drives used in the C64 processor
contain a single
processor (6502 in all that I've seen) and have all the electronics
(apart from the spindle motor control) on one PCB.
Yes... serial-interfaced drives and the 2031.
-ethan
--
Ethan Dicks, A-333-S Current South Pole Weather at 17-Nov-2007 at 01:30 Z
South Pole Station
PSC 468 Box 400 Temp -40.9 F (-40.5 C) Windchill -67.2 F (-55.1 C)
APO AP 96598 Wind 9.1 kts Grid 97 Barometer 681.8 mb (10560 ft)
Ethan.Dicks at usap.gov http://penguincentral.com/penguincentral.html
9:59 p.m.
New subject: "intelligent" disk drives
On Sat, Nov 17, 2007 at 12:40:25AM +0000, Tony Duell wrote:
Interesting. As I said, I've never seen one, in fact the only CBM GPIB
drives I've been inside are the 8050 and 8250LP.
I've never seen a 2031, but all the
GPIB-interfaces double drives contain
2 processors I think.
The 2031 is very much like a 1541, but with an IEEE-488 interface rather
than C= IEC. Prior to the 8050/8250, I think the arrangement was
one 6502 to talk to
the bus, and one 6504 to talk to the drives, but in other respects, the
same.
I wonder why they changed? I've not got the data book in front of me,
what was the address space of the 6504? The 8050 needs 8K, I think (4K
shared RAM + ROM + I/O devices). Did the earlier drives have less shared
RAM or something?
The control processor ROM is in one of those 6530
RRIOT chips, which
makes replaicng it a little problematic...
I have, I think, a full set of 2040 ROMs, including the right 6530, but
most of my pre-8050 drives were originally 2040s that were later upgraded
to the same ROMs as a 4040 (the only difference AFAIK is the label on the
outside).
18 Nov
18 Nov
12:40 a.m.
New subject: "intelligent" disk drives
As an aside, IMHO one of the worst mistakes commodore
made was that the
8050 could not at least read the disks of the earlier drives.
But then there might have been a situation like the 4040 and the 1540/1541,
where the gap is enough to let each read the other's floppies but too much to
allow successful writing. There was a lot of cussing about that early on after
a perfectly normal drive would eat a previously good disk because it was
originally written with one drive and then written again to with the other.
--
------------------------------------ personal: http://www.cameronkaiser.com/ --
Cameron Kaiser * Floodgap Systems * www.floodgap.com * ckaiser at floodgap.com
-- Shell scripting: the ultimate open source software. ------------------------
7:45 p.m.
New subject: "intelligent" disk drives
As an aside, IMHO one of the worst mistakes
commodore made was that the
8050 could not at least read the disks of the earlier drives.
But then there might have been a situation like the 4040 and the 1540/1541,
where the gap is enough to let each read the other's floppies but too much to
allow successful writing. There was a lot of cussing about that early on after
17 Nov
17 Nov
12:26 a.m.
New subject: "intelligent" disk drives
the C= disk drives were pretty much all smart drives weren't they? the big dual
drive units had a controller card in them that was basically a small computer (IIRC)
also Atari disk drives had a 650x IIRC in them as well as a disk controller chip
(once again IIRC.)
The Epson TF20 is a double 5.25" drive used with their early laptops
(HX20, PX4, PX8, etc), it communicates with then over an RS232-level
serial link at 38400 buad.
The TF20's controller board is packed with chips. As well as the disk
controller chip, there's a Z80A, 64K of DRAM (more than the host computer
in some cases!), a boot ROM that is paged out after the drive unit has
booted, and lots of glue logic. A daugterhboard contains a 7201 chip and
the RS232 drivers/receivers.
I am told it boots a modified CP/M from the disk in the A: drive at
power-on.
The drives themselves are somewhat interewting, being the Epson 1/3rd
height units with a voice-coil head positioner.
-tony
11:41 p.m.
New subject: "intelligent" disk drives
The Atari 8bit computer disk drives, were were SIO Bus (Serial I/O Bus -
what amounts to a very early version of USB) were the 810 and Atari 1050
disk drives which used 6507's for communicating to/from the host Atari
PC as well as a WD floppy controller (Atari 810 - 1771, Atari 1050 -
2793 or 2797 depending on revision of model)
The later XF551 Atari 8bit disk drives used an 8040/8050 and WD 1772
Everything on the Atari SIO bus were essentially "Intelligent
Peripherals" that had to have their own CPU chip in order to talk across
on the SIO Bus. It was a nice design and its over-sized trapezoid
connectors made hooking up (Daisy Chaining) peripherals an easy
no-brainer/no mistake setup. However, these intelligent peripherals
ended up hurting the Atari 8bit line because of their inherently high
expense. It was interesting - in 1983 you could buy an Atari 800XL
computer for around $299, but the 1050 XL series disk drives cost $359
or higher, so the cost of owning a disk drive was a luxury, owning two
such devices was a rare sight to see for many Atari users at the time.
The 1772 were also used on most of the 16/32bit Atari ST computers.
Atari would later develop a custom IC called "Ajax" for high density
floppy drive usage. (Atari IC part#'s C302096, C302434)
Curt
The Atari XF551
Geoff Reed wrote:
the C= disk drives were pretty much all smart drives
weren't they? the big dual
drive units had a controller card in them that was basically a small computer (IIRC)
also Atari disk drives had a 650x IIRC in them as well as a disk controller chip
(once again IIRC.)
18 Nov
18 Nov
7:42 p.m.
New subject: "intelligent" disk drives
The Atari 8bit computer disk drives, were were SIO Bus (Serial I/O Bus -
what amounts to a very early version of USB) were the 810 and Atari 1050
disk drives which used 6507's for communicating to/from the host Atari
PC as well as a WD floppy controller (Atari 810 - 1771, Atari 1050 -
2793 or 2797 depending on revision of model)
I suppose I should mention the HP HPIB and HPIL drives, which all had
intellegent controllers.
The only HPIL driv I know about is the 9114. It contains an HPIL chip
(1LB3 for the HP types here), a 68B09 processor, 2793 controller, and
glue logic to control a Sony 3.5" floppy drive. It's battery-powered
(2.5Ah lead acid pack), much of the electronics powers down when the
drive is not being accessed (only the HPIL chip and RAM remain active) to
save power.
The 5.25" HPIB floppy drive I've seen (82901 I think) uses a 6802
processor + Fujitsu (WD-like) floppy controller chip, glue, etc. Mains
powered (as are all the HPIB dries I know of), it uses a pair of
HP-speced (gold-plated PCBs, etc) TM100-2 drives.
The dual 3.5" HPIB drives again use a 68B09 + much the same disk
controller circuit linked to a pair of the Sony full-height 3.5" drives.
The combined 3.5" floppy + 5.25" winchester units (9133) come in many
forms. Later ones have a combined cotnroller board with a 68B09 + WD1010
hard disk controller + floppy controller, etc. The drives are a Sony 3.5"
floppy drive and a stnadard winchester drive (ST412 interface). The
earlier ones are stranger, they have 2 separate disk controllers in them,
simply linked to the same HPIB connector. Each has a 68B09 and the
appropriate contreoller stuff. THis is where I learnt that the ST412 is
actually a member of a family including the ST406 (single platter, 2
heads, 6Mbyte unformatted) and ST419 (3 platters, 6 heads, 19Mbytes
unformatted) drives. I'd never heard of an ST406 before.
Even later, there was the 9153 (floppy/winchester) and 9154 (winchester
only) unit. Again 98B09 based, but now everything in SMD packages (the
68B09 is a PLCC package). The winchesters are HP custom units with a
strange interface -- fairly high level for positioning the heads, but
still the raw bit stream for reading and writing.
Their cartridge tape drives also have intellegent controllers. Mostly
68x09 based, but the 9145 I have has what appears to be a 68000 inside
-tony
19 Nov
19 Nov
9:54 a.m.
New subject: "intelligent" disk drives
On Sun, 18 Nov 2007, Tony Duell wrote:
Even later, there was the 9153 (floppy/winchester) and
9154 (winchester
only) unit. Again 98B09 based, but now everything in SMD packages (the
68B09 is a PLCC package). The winchesters are HP custom units with a
strange interface -- fairly high level for positioning the heads, but
still the raw bit stream for reading and writing.
Recently the drive in my HP 7958A unit failed (it was a Micropolis 1355)
and I've replaced the drive with another ESDI drive. The 7958A contains a
68B09 (I guess) and a NatSemi DP8466 disk data controller.
I had to find a way to lowlevel format the drive so that the firmware of
the 7958A wouldn't fault after power-on and so I have disassembled the
firmware. There are three documented options to the Init Media command
(0=keep all spares, 1=keep only primary spares, 2=keep no spares) which
all wouldn't correctly lowlevel format the drive. The firmware needs
additional tracks (called maintenance tracks) at the beginning and at the
end of the disk. By disassembling I've found out that there is another
option 3 which will work as option 2 but also format the maintenance
tracks. So here we go: replace the HDA (in my case I took a CDC WREN IV),
attach the 7958A to an HP box (HP 9000/840 with HP-IB) and call mediainit
in guru mode and pass it the initialize option 3. The command terminates
after a while, and after power-cycling the drive the firmware will pass
all self-tests now! The self-tests contain read/write tests and ECC tests.
BTW one can use ESDI drives with any capacity as the firmware will read
the geometry information from the disk drive and setup its internal tables
accordingly. You have to make sure to jumper the drive to hard sectored
mode, 64 sectors/track!
Christian
11:13 p.m.
New subject: "intelligent" disk drives
On Sun, 18 Nov 2007, Tony Duell wrote:
Interesting. I'd momentaarily forgotten aout the ESDI drive units. I haev
one (I forget the model numbnr), I am darn sure it's an ESDI drive both
Even later, there was the 9153
(floppy/winchester) and 9154 (winchester
only) unit. Again 98B09 based, but now everything in SMD packages (the
68B09 is a PLCC package). The winchesters are HP custom units with a
strange interface -- fairly high level for positioning the heads, but
still the raw bit stream for reading and writing.
Recently the drive in my HP 7958A unit failed (it was a Micropolis 1355)
and I've replaced the drive with another ESDI drive. The 7958A contains a
68B09 (I guess) and a NatSemi DP8466 disk data controller. from looking at it and from reading the boardswapper
guide. But the
controller oard is mostly custom HP chips, along with some RAM, an
EPROM,
and, of course, the 68B09. Even the HPIB chip is HP (the 1TL1 'Medusa' chip).
The drive is also HP. I am pretty use it's not based on a Micropolis
unit, either...
BTW one can use ESDI drives with any capacity as the
firmware will read
the geometry information from the disk drive and setup its internal tables
accordingly. You have to make sure to jumper the drive to hard sectored
mode, 64 sectors/track!
That's well worth knowing. I am pretty sure the ST412-based units, which
of course can't read the drive geometry from the drive hardware, have
tables in ROM of the allowable geometries (link-selected o nthe
controller board) and check it against the drive at power-on (try
selecting non-existant heads, etc). Which means if you put in a larger
drive the darn thing will fualt and a low-level format won't fix it, even
though you only want to use the original capacity of the drive.
-tony
15 Nov
15 Nov
9:11 p.m.
On the other
hand, there was the 6551 ACIA emulation in software for
the user port, which was buggy to boot. People may make fun of the Plus=
/4
but at least it had a real ACIA.
They did? (Looking in handy box of manuals, but plus 4 isn't in there..=
.) 
14 Nov
14 Nov
3:17 a.m.
From: rtellason at verizon.net> > This is where
I get a little puzzled sometimes. Like that BB2 I mentioned, > that uses DMA to send a
string of bytes to the disk controller chip rather > than using the processor to do
those transfers. Why is not immediately > apparent to me since the processor isn't
doing anything else at that point > anyhow...>
Hi
I once wrote code to take avantage of DMA to disk. I was doing a search
that required a case insensitive search. I found that on the processor
I was running, it took almost as much time to read a track as it
did to search the data on the track. I'd only have to wait, doing
nothing on the first read. After that, I would just have to wait a
little while until the next track was read, because I'd started
the second DMA before I started searching the first buffer.
In a multi user system, one could be handling all kinds of
activities while the buffer was being loaded.
Dwight
_________________________________________________________________
Climb to the top of the charts!? Play Star Shuffle:? the word scramble challenge with star
power.
http://club.live.com/star_shuffle.aspx?icid=starshuffle_wlmailtextlink_oct
15 Nov
15 Nov
4:36 a.m.
On Tuesday 13 November 2007 22:17, dwight elvey wrote:
> From: rtellason at verizon.net> > This is
where I get a little puzzled
> sometimes. Like that BB2 I mentioned, > that uses DMA to send a string of
> bytes to the disk controller chip rather > than using the processor to do
> those transfers. Why is not immediately > apparent to me since the
> processor isn't doing anything else at that point > anyhow...>
Why does your quoting not handle line breaks well?
Hi
I once wrote code to take avantage of DMA to disk. I was doing a search
that required a case insensitive search. I found that on the processor
I was running, it took almost as much time to read a track as it
did to search the data on the track. I'd only have to wait, doing
nothing on the first read. After that, I would just have to wait a
little while until the next track was read, because I'd started
the second DMA before I started searching the first buffer.
That makes sense.
In a multi user system, one could be handling all
kinds of
activities while the buffer was being loaded.
Multi-user in an 8-bit context doesn't sound real terrific to me, for some
reason, though I don't see a problem with multiprocessing if it's done
right.
--
Member of the toughest, meanest, deadliest, most unrelenting -- and
ablest -- form of life in this section of space, ?a critter that can
be killed but can't be tamed. ?--Robert A. Heinlein, "The Puppet Masters"
-
Information is more dangerous than cannon to a society ruled by lies. --James
M Dakin
4:47 a.m.
From: rtellason at verizon.net
On Tuesday 13 November 2007 22:17, dwight elvey wrote:
Hi
It is the new improved Hotmail. If I forget to select plain
text each time, it does this.
I've noticed that a few others are having the same problem.
I'll try to do better.
Dwight
_________________________________________________________________
Peek-a-boo FREE Tricks & Treats for You!
http://www.reallivemoms.com?ocid=TXT_TAGHM&loc=us
> From: rtellason at verizon.net>> This
is where I get a little puzzled
> sometimes. Like that BB2 I mentioned,> that uses DMA to send a string of
> bytes to the disk controller chip rather> than using the processor to do
> those transfers. Why is not immediately> apparent to me since the
> processor isn't doing anything else at that point> anyhow...>
Why does your quoting not handle line breaks well?
5:01 a.m.
Roy J. Tellason wrote:
Multi-user in an 8-bit context doesn't sound real
terrific to me, for some
reason, though I don't see a problem with multiprocessing if it's done
right.
Well the idea of muilt-processing on a 8 bit cpu (6809) sounds
nice. You know a floppy, hard drive, serial I/O (low speed) all going
at once could help a user use software effectively.
Still waiting ... too bad GIMIX is not around anymore.
Ben alias woodelf
PS. I don't want a COCO 3 instead, I want a REAL computer.
(Well I have PDP 8 for my real *classic* computer :).
5:23 a.m.
On Thursday 15 November 2007 00:01, woodelf wrote:
Roy J. Tellason wrote:
That name does sound vaguely familiar, though I couldn't tell you anything
more than that.
Multi-user in an 8-bit context doesn't sound
real terrific to me, for
some reason, though I don't see a problem with multiprocessing if it's
done right.
Well the idea of muilt-processing on a 8 bit cpu (6809) sounds
nice. You know a floppy, hard drive, serial I/O (low speed) all going
at once could help a user use software effectively.
Still waiting ... too bad GIMIX is not around anymore. Ben alias woodelf
PS. I don't want a COCO 3 instead, I want a REAL computer.
(Well I have PDP 8 for my real *classic* computer :).
Well, there were pluses and minuses about the CoCo. The big minus for me was
that the basic machine all by itself wasn't up to doing much. And by the
time you got everything al ltricked out, you were talking some decidedly
nontrivial money...
OTOH, that setup was actually pretty neat, once you got there. Or so it
seemed to me anyway, looking it it from the outside.
--
Member of the toughest, meanest, deadliest, most unrelenting -- and
ablest -- form of life in this section of space, ?a critter that can
be killed but can't be tamed. ?--Robert A. Heinlein, "The Puppet Masters"
-
Information is more dangerous than cannon to a society ruled by lies. --James
M Dakin
4:17 p.m.
New subject: 8-bit Multiuser (was Multics)
Well the idea of muilt-processing on a 8 bit cpu
(6809)
sounds nice. You know a floppy, hard drive, serial I/O (low
speed) all going at once could help a user use software effectively.
Still waiting ... too bad GIMIX is not around anymore.
Ben alias woodelf
PS. I don't want a COCO 3 instead, I want a REAL computer.
(Well I have PDP 8 for my real *classic* computer :).
Gimix built 6809 (and I believe, later, 68000)-based computers that ran
OS-9. Their machines were very well-designed and built, and had a
reputation for being true "data center quality" rather than hobbyist
machines, though they did market to the "high end" of the hobbyist
market.
OS-9 was a full multi-user operating system that ran on the 6809 (a
68K-based version which was dramatically enhanced over the 8-bit OS-9
was also marketed, which was quite powerful).
The 6809-based (8-bit) version of OS-9 could be run on the various
models of the Radio Shack Color Computer, but with floppy disc's I/O
bandwidth limitations, it was frustratingly slow on the Coco I. The
later Coco II and Coco III made improvements in the I/O architecture,
and added some "memory management" capabilities to address some of these
problems, and with a hard disk connected, could serve up a small office
multi-user environment, although they were hardly what I'd call "data
center" grade equipment.
OS-9 was made by a company called Microware, and was really quite
amazing for its time. Sometime in the 1980's (can't remember exactly
when, but I think it was after 1985) I built a homebrew 6809-based
computer that used OS-9, and could nicely service five users including
the console, all running simultaneously (terminals at 9600 baud), along
with background jobs that did things like printer spooling, a clone of
UUCP, and even a batch processing system. The system had a
DMA/Interrupt-based hard disk controller that I designed that interfaced
to a Micropolis 8" hard disk drive (can't remember the model number, but
I think it held something like 20MB, and used a pre-SCSI parallel
interface, that I got from the Tektronix company store for something
like $25), and an 8-port serial I/O card that had some local
intelligence (another 6809) that handled buffered input.
OS-9 had a very extensible and well-documented driver architecture that
made it possible to easily write device drivers for all of this custom
hardware. It utilized bank-switched memory (It had 256K of memory in
four banks with a common area (I think it was the upper 1K of the 64KB
address space) that wasn't bank switched for I/O (the 6809 uses a
memory-mapped I/O methodology) and boot ROM.
It was a fun project (that was when I had time...don't know where it
went, but it's definitely not here now), and I learned a lot by
tinkering with it. I still have most of the pieces of that system,
except the hard disk eventually died, which pretty much ended the
playing with it -- those old Micropolis 8" drives just aren't around
anymore, and there's no time to try to design a USB or SCSI interface
for it.
Those were the days...
Rick Bensene
The Old Calculator Museum
http://oldcalculatormuseum.com
5:04 a.m.
On 14 Nov 2007 at 23:36, Roy J. Tellason wrote:
Multi-user in an 8-bit context doesn't sound real
terrific to me, for some
reason, though I don't see a problem with multiprocessing if it's done
right.
It could be remarkably good, but you have to work within the
limitations of the architecture. The x80 CPUs didn't have any good
way to dynamically relocate code and data and had a fairly small
addressing space.
We simply went to a (pcode-type) interpreter that serviced all of the
users. It cut down on redundant code and since we were executing
BASIC programs, the speed penalty wasn't too awful.
I received a note last week from a one-time customer in Japan who
mentioned that they were talking about phasing out the old code
they'd written back in the 80's for the system we wrote in 1979 for
an 8085 (supporting 5 users) and later ported to SCO Xenix. He
remarked that they'd added to the programs over the years with no
problems. This is more than 20 years after the company offering the
language went out of business.
I've still got the source code somewhere.
Cheers,
Chuck
5:27 a.m.
On Thursday 15 November 2007 00:04, Chuck Guzis wrote:
On 14 Nov 2007 at 23:36, Roy J. Tellason wrote:
Maybe it was some fairly negative comments about MP/M I was remembering...
Multi-user in an 8-bit context doesn't sound
real terrific to me, for
some reason, though I don't see a problem with multiprocessing if it's
done right.
It could be remarkably good, but you have to work within the
limitations of the architecture. The x80 CPUs didn't have any good way to
dynamically relocate code and data
and had a fairly small addressing space.
I guess that depended a lot on how you coded things. The biggest single thing
that jumps out at me being absolute addresses, and I guess that it's
possible to avoid those to an extent. And if stuff was modular enough you
could make some small but effective modules that wouldn't take up all that
much room. Wasn't that what ZCPR was trying to do? At least that's the
impression I'm left with after having browsed some doc files, and that
wasn't recently...
We simply went to a (pcode-type) interpreter that
serviced all of the
users. It cut down on redundant code and since we were executing
BASIC programs, the speed penalty wasn't too awful.
Ok.
I received a note last week from a one-time customer
in Japan who
mentioned that they were talking about phasing out the old code
they'd written back in the 80's for the system we wrote in 1979 for
an 8085 (supporting 5 users) and later ported to SCO Xenix. He
remarked that they'd added to the programs over the years with no
problems. This is more than 20 years after the company offering the
language went out of business.
That's impressive!
I've still got the source code somewhere.
For the 8085? I'd be interested in seeing that, if that would turn out to be
convenient. I've always sort of liked that chip for some odd reason. What
else in terms of hardware did the system have that you ran this stuff on?
--
Member of the toughest, meanest, deadliest, most unrelenting -- and
ablest -- form of life in this section of space, ?a critter that can
be killed but can't be tamed. ?--Robert A. Heinlein, "The Puppet Masters"
-
Information is more dangerous than cannon to a society ruled by lies. --James
M Dakin
6:15 a.m.
On 15 Nov 2007 at 0:27, Roy J. Tellason wrote:
The x80 CPUs didn't have any good way to
dynamically relocate code and data
and had a fairly small addressing space.
I guess that depended a lot on how you coded things. The biggest single thing
that jumps out at me being absolute addresses, and I guess that it's
possible to avoid those to an extent. And if stuff was modular enough you
could make some small but effective modules that wouldn't take up all that
much room. Wasn't that what ZCPR was trying to do? At least that's the
impression I'm left with after having browsed some doc files, and that
wasn't recently...
I'd call MP/M "static" relocation--once you loaded a program, you
couldn't move it. MP/M used the simple scheme of assembling a
program twice--one off by 100H locations from the original one.
Compare the two, build a bitmap of the differences and you've got a
primitive relocation map. But once the program is loaded, the map is
useless--you have no way of knowing what addresses have been
generated during execution.
To make the best use of available memory, you have to be able to move
active programs to make room for other ones. If you *really* want to
do things right, you can load and unload programs to disk.
JRT Pascal did this pretty well--and it was p-code interpreted.
The other approaches were more hardware oriented--use bankswitched
memory to change context or multiple CPUs, one per user (e.g.
Molecular). Neither takes the best advantage of available resources.
Pcode allows you to do something that compiling to native code
doesn't--the ability to design your own machine. For example,
instead of having your P-code instructions reference locations in
memory, you can substitute an ordinal into a local descriptor table,
where all of the good stuff about a variable is kept (e.g. string
length, data type, dimension, location, etc.). When you need to
move, you know where to find all of the stuff that needs adjustment.
Your subroutines can be ordinals into table of descriptors that may,
for example, tell the interpreter that a subroutine isn't present in
memory yet. To the programmer, it all looks seamless; no silly
"CHAIN" statements--the interpreter does it all for you.
And, as long as you don't pollute your P-code, it's portable to just
about any platform.
For the 8085? I'd be interested in seeing that,
if that would turn out to be
convenient. I've always sort of liked that chip for some odd reason. What
else in terms of hardware did the system have that you ran this stuff on?
An 8085 running at (IIRC) about 4MHz, between 64 and 256KB of page-
mapped memory (1K pages). Console with keyboard and CRT controller
and 4 async comm terminals. The usual hard disk and floppies; a
printer. When it was moved to the 286, the runtime was reworked to
run under SCO and use special-firmware Beehive terminals.
In the compiler, we avoided writing a ton of 8085 assembly by
abstracting the compiling process into a "compiling machine" with its
own (fairly abstract) instruction set. You write the compiler in it,
then code a small interpreter to get it going and debugged, then
change the interpreted instructions into macros and generated code
directly. We wrote the macro processor in PL/M--and later in C.
I'd like to take credit for having the inspriation, but I learned it
from a fellow who worked on the original IBM COMTRAN
project and
developed his own methodology for cranking out COBOL compilers very
quickly.
Cheers,
Chuck
7:34 a.m.
On Thursday 15 November 2007 01:15, Chuck Guzis wrote:
On 15 Nov 2007 at 0:27, Roy J. Tellason wrote:
I seem to remember some stuff duing my CP/M days that actually had a bitmap of
which locations needed to be fixed, though I'm darned if I can remember just
now what that was.
The x80 CPUs didn't have any good way to
dynamically relocate code and
data and had a fairly small addressing space.
I guess that depended a lot on how you coded things. The biggest single
thing that jumps out at me being absolute addresses, and I guess that
it's possible to avoid those to an extent. And if stuff was modular
enough you could make some small but effective modules that wouldn't take
up all that much room. Wasn't that what ZCPR was trying to do? At least
that's the impression I'm left with after having browsed some doc files,
and that wasn't recently...
I'd call MP/M "static" relocation--once you loaded a program, you
couldn't move it. MP/M used the simple scheme of assembling a
program twice--one off by 100H locations from the original one.
Compare the two, build a bitmap of the differences and you've got a
primitive relocation map. But once the program is loaded, the map is
useless--you have no way of knowing what addresses have been
generated during execution. To make the best use of available memory, you have to
be able to move
active programs to make room for other ones. If you *really* want to
do things right, you can load and unload programs to disk.
JRT Pascal did this pretty well--and it was p-code interpreted.
Wasn't JRT the one that got some really bad reviews in Byte or one of the
other magazines? It was some early Pascal compiler anyhow. I can't say I
ever encountered it or ran across it or talked with anybody who had used it.
The other approaches were more hardware oriented--use
bankswitched
memory to change context or multiple CPUs, one per user (e.g.
Molecular). Neither takes the best advantage of available resources.
Molecular doesn't ring any bells offhand but I do recall a system (and almost
got a hold of one once) that had a system CPU card, one that ran the HD,
and one for each user, complete with serial ports for the user's terminal
and printer. And I think there was a system printer port as well. I think I
have a binder around here someplace that gets into that, but it's not handy
and I can't recall where it is offhand. (Too many books in boxes, not
nearly enough shelving to put them on.)
Pcode allows you to do something that compiling to
native code
doesn't--the ability to design your own machine. For example,
instead of having your P-code instructions reference locations in
memory, you can substitute an ordinal into a local descriptor table,
where all of the good stuff about a variable is kept (e.g. string
length, data type, dimension, location, etc.). When you need to
move, you know where to find all of the stuff that needs adjustment.
Your subroutines can be ordinals into table of descriptors that may,
for example, tell the interpreter that a subroutine isn't present in
memory yet. To the programmer, it all looks seamless; no silly
"CHAIN" statements--the interpreter does it all for you.
And, as long as you don't pollute your P-code, it's portable to just
about any platform.
This sounds pretty good...
I remember one of the floppies I got with my Osborne originally was
labeled "UCSD P-System" (or something pretty close to that). I vaguely
recall poking around with it once, but it had nothing at all to do with
CP/M, wasn't compatible with anything else at all, and at that point in
time I couldn't see the use of it. I probably still have it somewhere, and
some docs on it too.
--
Member of the toughest, meanest, deadliest, most unrelenting -- and
ablest -- form of life in this section of space, ?a critter that can
be killed but can't be tamed. ?--Robert A. Heinlein, "The Puppet Masters"
-
Information is more dangerous than cannon to a society ruled by lies. --James
M Dakin
8:02 a.m.
On 15 Nov 2007 at 2:34, Roy J. Tellason wrote:
I seem to remember some stuff duing my CP/M days that
actually had a bitmap of
which locations needed to be fixed, though I'm darned if I can remember just
now what that was.
If you put together CP/M from the OEM kit, you used it to make your
customized copy of MOVCPM.
Wasn't JRT the one that got some really bad
reviews in Byte or one of the
other magazines? It was some early Pascal compiler anyhow. I can't say I
ever encountered it or ran across it or talked with anybody who had used it.
I still have my 8" JRT disk. Yes, it was terrible and slow, but what
do you expect from a program that swaps to floppy? They advertised
that you could write programs of any size, not limited by the RAM of
your computer. While it was probably true that you could write
programs much larger than available RAM, the d*mned thing was buggy
enough to be useless.
Curiously, I was using it as part of a validation set of programs to
check out V20/V30 8080 emulation and turned up a big in the V20/V30.
I still have the NEC MicroNote describing the problem. AFAIK, the
bug was never fixed in the V-series uPs--there just wasn't enough
interest. As I recall, the problem was the JRT modularized its own
subroutines and set SP = subroutine entry point before each call to
keep the stack local to each subroutine. It broke the V20/V30 badly.
It was an object less in the fallacy of the "no one would ever want
to do that' approach.
I remember one of the floppies I got with my Osborne
originally was
labeled "UCSD P-System" (or something pretty close to that). I vaguely
recall poking around with it once, but it had nothing at all to do with
CP/M, wasn't compatible with anything else at all, and at that point in
time I couldn't see the use of it. I probably still have it somewhere, and
some docs on it too.
Yup, UCSD P-system was its own operating system as well as the
language support. Not a bad implementation for the time, but a world
unto itself. I think at one point IBM even flogged it for the PC.
Cheers,
Chuck
5:17 p.m.
On Thursday 15 November 2007 03:02, Chuck Guzis wrote:
It's the bugs that were reported back when, if I'm remembering right.
(Snip)
Apparently. A side-trip into wikipedia turned up some interesting reading on
that, and other somewhat related subjects, before I was too tired to
continue last night. :-)
--
Member of the toughest, meanest, deadliest, most unrelenting -- and
ablest -- form of life in this section of space, ?a critter that can
be killed but can't be tamed. ?--Robert A. Heinlein, "The Puppet Masters"
-
Information is more dangerous than cannon to a society ruled by lies. --James
M Dakin
On 15 Nov 2007 at 2:34, Roy J. Tellason wrote:
Right. But there was also some application software that did this as well.
I seem to remember some stuff duing my CP/M days
that actually had a
bitmap of which locations needed to be fixed, though I'm darned if I can
remember just now what that was.
If you put together CP/M from the OEM kit, you used it to make your
customized copy of MOVCPM. Wasn't JRT
the one that got some really bad reviews in Byte or one of the
other magazines? It was some early Pascal compiler anyhow. I can't say
I ever encountered it or ran across it or talked with anybody who had
used it.
I still have my 8" JRT disk. Yes, it was terrible and slow, but what do you
expect from a program that swaps to floppy? They advertised that you could
write programs of any size, not limited by the RAM of your computer. While
it was probably true that you could write programs much larger than
available RAM, the d*mned thing was buggy enough to be useless. I remember one
of the floppies I got with my Osborne originally was
labeled "UCSD P-System" (or something pretty close to that). I vaguely
recall poking around with it once, but it had nothing at all to do with
CP/M, wasn't compatible with anything else at all, and at that point in
time I couldn't see the use of it. I probably still have it somewhere,
and some docs on it too.
Yup, UCSD P-system was its own operating system as well as the
language support. Not a bad implementation for the time, but a world
unto itself. I think at one point IBM even flogged it for the PC. 
13 Nov
13 Nov
4:21 p.m.
New subject: MIT provides MULTICS source and documentation (DPS-8 simulation)
In article <200711130121.55804.rtellason at verizon.net>,
"Roy J. Tellason" <rtellason at verizon.net> writes:
This sort of thing is exactly the area where I'm
fuzziest when it
comes to any sort of a real understanding of big iron. Aside from
seeing references to such stuff from time to time, I really don't
have a clue as to why you'd _want_ something like a separate dedicated
processor to handle I/O, for one example.
Its still done to this day, just that the processors are standard
parts and are embedded (every modern keyboard has a microprocessor in
it!).
The reason you do it is because its silly to have your main CPU
polling the sense lines on a keyboard to detect keystrokes.
--
"The Direct3D Graphics Pipeline" -- DirectX 9 draft available for download
<http://www.xmission.com/~legalize/book/download/index.html>
Legalize Adulthood! <http://blogs.xmission.com/legalize/>
5:39 p.m.
On Nov 13, 2007, at 1:21 AM, Roy J. Tellason wrote:
This sort of thing is exactly the area where I'm
fuzziest when it
comes to any
sort of a real understanding of big iron. Aside from seeing
references to
such stuff from time to time, I really don't have a clue as to why
you'd
_want_ something like a separate dedicated processor to handle I/
O, for one
example. Or mass storage.
The use of dedicated processors to handle specific tasks within a
large system is beneficial in a great many ways. If you have a
processor handling disk I/O, for example, that processor can deal
with error handling, possibly RAID stuff, transfer reordering and
optimization, etc., thus offloading the main processor and freeing up
its cycles for applications.
Every cycle the main processor doesn't need to spend managing crap
like disk and terminal I/O is a cycle that can be spent executing
application code.
-Dave
--
Dave McGuire
Port Charlotte, FL
Farewell Ophelia, 9/22/1991 - 7/25/2007
6:30 p.m.
On 13 Nov 2007 at 1:21, Roy J. Tellason wrote:
I really don't have a clue as to why you'd
_want_ something like a separate dedicated processor to handle I/O, for one
example. Or mass storage. Or whatever. And I really don't have that much
of a handle on how the architecture of those sorts of machines differs from
the micros I'm familiar with. Even that bit of time I got to spend with the
Heath H11 was very alien to the rest of what I'm familiar with.
I can't imagine why anyone *wouldn't* want such a thing. Consider
one of the big iron systems of the 60's and 70's--the CDC 6600. A
CPU with 10 peripheral processors. Within these processors, much of
what we would call the operating system is resident. The file
system, job control and general I/O is handled without the
intervention of the CPU, which is left to do what it does best--
handle user computations with a minimum of interruption.
The PPUs handle the operator display, time (task switching/time of
day, etc.) and the basic I/O activities, including loading the
necessary programs to do so. PPUs can read and write CPU memory, but
the reverse is not true--the CPU cannot interfere with the activities
of the PPUs other than to post a request by writing to prearranged
locations in memory. It's very secure.
In any processor with pipelining, instruction look-ahead and caching,
branch prediction and all of those other little gimmicks that make
execution faster, the idea of interposing interrupts that bollix up
all of the above is pure insanity.
For example, suppose I wanted to read a disk file. After opening the
file, I issue a read request to the I/O subsystem, which performs the
necessary mapping of my logical request to a physical disk drive and
the process is begun. As long as I can remove data from the read
buffer quickly enough, the processor handling my disk I/O will
continue to read data and place it into the buffer.
If I wanted to copy from a disk to a tape, I'd set up two requests--a
read and a write and, as long as I could move data quickly enough,
the operation had the potential of being continuous, with two
processors attached to my job handling the I/O. The amount of CPU
time consumed is minimal.
A PPU will probably talk in turn to another specialized processor
that's attached to a specific I/O device that further simplifies the
interaction. Why should a PPU do all of the work to monitor the on-
or off-line states of a bank of disk drives when the processor in the
controller for the drives can do it?
We see this in modern PC's with GPUs--a processor that's distinct
from the CPU that does a better job of handling a
particular task
than the CPU.
It just makes sense. It's a shame we don't any modern PCs with a
standardized peripheral processor structure, particularly given the
cost of a microcontroller nowadays.
Cheers,
Chuck
8:05 p.m.
I really
don't have a clue as to why you'd _want_ something like a
separate dedicated processor to handle I/O,
I can't imagine why anyone
*wouldn't* want such a thing.
9:56 p.m.
On Tuesday 13 November 2007 13:30, Chuck Guzis wrote:
On 13 Nov 2007 at 1:21, Roy J. Tellason wrote:
Well, my admittedly limited experience with stuff is that the "main"
processor isn't doing much of anything while it's waiting for I/O to complete
anyhow, or at least that's what my perception has been. Now I'll be the
first to admit that my perceptions are very much skewed toward the 8-bit
micro and crudely-done DOS-based end of things, so maybe I just need to get
a good hard look at how some other stuff is done.
I know for example that when I was looking at that H11 setup we got a hold of
all sorts of software, one of which was "MUBASIC", which would supposedly
support 8 users. It was not at all clear to me at that point in time how it
was supposed to do that, or if it was even possible for it to do that with
the hardware we had there at the time, but this was seriously different from
much else of what I've ever encountered.
I really don't have a clue as to why
you'd
_want_ something like a separate dedicated processor to handle I/O, for
one example. Or mass storage. Or whatever. And I really don't have
that much of a handle on how the architecture of those sorts of machines
differs from the micros I'm familiar with. Even that bit of time I got
to spend with the Heath H11 was very alien to the rest of what I'm
familiar with.
I can't imagine why anyone *wouldn't* want such a thing. Consider one of the big iron systems of the 60's
and 70's--the CDC 6600.
Which is exactly the sort of thing I have absolutely zero experience with. :-)
A CPU with 10 peripheral processors. Within these
processors, much of
what we would call the operating system is resident.
Actually a distributed OS sounds pretty good to me...
The file system, job control and general I/O is
handled without the
intervention of the CPU, which is left to do what it does best--
handle user computations with a minimum of interruption.
This is part of where things get fuzzy for me. What I see a CPU typically
dealing with in the contexts that I'm familiar with is a lot of what you say
in the above that it's not having to deal with. So aside from
computationally-intensive tasks (I guess what the books used to
call "scientific" computing rather than "business" computing back when
that
distinction still meant something), what else is there for it to do?
The PPUs handle the operator display, time (task
switching/time of
day, etc.) and the basic I/O activities, including loading the necessary
programs to do so. PPUs can read and write CPU memory, but the reverse is
not true--the CPU cannot interfere with the activities of the PPUs other
than to post a request by writing to prearranged locations in memory. It's
very secure.
Now there are some particulars that I wasn't aware of. Is that shared memory
stuff how it was done, mostly?
In any processor with pipelining, instruction
look-ahead and caching,
branch prediction and all of those other little gimmicks that make
execution faster, the idea of interposing interrupts that bollix up
all of the above is pure insanity.
Yep. I don't see how you can make them be all that useful without some
serious tradeoffs, but then most of today's processors are horribly kludged
in terms of architecture as far as I'm concerned. At least that's the way
I've felt ever since I bumped into "segment registers" and similar nonsense
back when. :-)
For example, suppose I wanted to read a disk file.
After opening the
file, I issue a read request to the I/O subsystem, which performs the
necessary mapping of my logical request to a physical disk drive and
the process is begun. As long as I can remove data from the read
buffer quickly enough, the processor handling my disk I/O will
continue to read data and place it into the buffer.
Ok...
If I wanted to copy from a disk to a tape, I'd set
up two requests--a
read and a write and, as long as I could move data quickly enough,
the operation had the potential of being continuous, with two
processors attached to my job handling the I/O. The amount of CPU
time consumed is minimal.
Makes sense to me...
A PPU will probably talk in turn to another
specialized processor
that's attached to a specific I/O device that further simplifies the
interaction. Why should a PPU do all of the work to monitor the on-
or off-line states of a bank of disk drives when the processor in the
controller for the drives can do it?
We have that to some extent now, with proessing power in printers, disk
drives, and so forth.
We see this in modern PC's with GPUs--a processor
that's distinct
from the CPU that does a better job of handling a particular task
than the CPU.
It just makes sense. It's a shame we don't any modern PCs with a
standardized peripheral processor structure, particularly given the
cost of a microcontroller nowadays.
The way it's being done these days seems to me to be too driven by specific
applications, and specific things that the designers had in mind when they
came up with some of this stuff. That's fine and dandy for when you have say
a processor that's dedicated to a job like running a printer, or a disk
drive, but not so much for other things that could be a litlte more
generalized.
--
Member of the toughest, meanest, deadliest, most unrelenting -- and
ablest -- form of life in this section of space, ?a critter that can
be killed but can't be tamed. ?--Robert A. Heinlein, "The Puppet Masters"
-
Information is more dangerous than cannon to a society ruled by lies. --James
M Dakin
10:28 p.m.
On 13 Nov 2007 at 16:56, Roy J. Tellason wrote:
Well, my admittedly limited experience with stuff is
that the "main"
processor isn't doing much of anything while it's waiting for I/O to complete
anyhow, or at least that's what my perception has been. Now I'll be the
first to admit that my perceptions are very much skewed toward the 8-bit
micro and crudely-done DOS-based end of things, so maybe I just need to get
a good hard look at how some other stuff is done.
Well, why have a multi-gigahertz CPU if you're not going to do
computationally intensive things with it? A lot of graphics and
multimedia is very computationally intensive in today's world, even
with gigaflop GPUs.
In the CDC 6600, I should probably say that Seymour Cray rigged
things to give the *appearance* of 10 PPUs. Core back then was 1
microsecond and the CPU used it interleaved by a factor of 10, so a
cycle time of 100 nsec was possible. The "10" PPUs all shared a
common ALU--each had its own 1 microsecond 4Kx12 bit memory, P-
counter and accumulator, and each took a turn in the "barrel" so that
each appeared to be an independent CPU. Access to central memory (60
bits wide) by the PPUs was obtained through what was called the "read-
write pyramid" where up to 5 CPU words could be in various stages of
assembly or disassembly. It was very slick.
And yes, in its day, the 6600 was considered to be a computational
"monster" that used a lot of the tricks we use today to speed up CPU
execution. Slow functional units were segmented (early pipelining),
there was a read-ahead cache for instructions, so it was possible to
keep small loops entirely in cache, and elegant scheduling method was
used to control instruction scheduling. And the instruction set
itself was very simple; some refer to it as very RISC-like.
All this with core and discrete transistors, yet.
Cheers,
Chuck
10:37 p.m.
In the CDC 6600, I should probably say that Seymour
Cray rigged
things to give the *appearance* of 10 PPUs. Core back then was 1
microsecond and the CPU used it interleaved by a factor of 10, so a
cycle time of 100 nsec was possible. The "10" PPUs all shared a
common ALU--each had its own 1 microsecond 4Kx12 bit memory, P-
counter and accumulator, and each took a turn in the "barrel" so that
each appeared to be an independent CPU. Access to central memory (60
bits wide) by the PPUs was obtained through what was called the "read-
write pyramid" where up to 5 CPU words could be in various stages of
assembly or disassembly. It was very slick.
Low end IBM mainframes also used this trick, stealing the ALU away
from the processor to do channel stuff. It is almost
like the
processor emulated the channel you were too cheap to buy.
--
Will
15 Nov
15 Nov
4:22 a.m.
On Tuesday 13 November 2007 17:28, Chuck Guzis wrote:
On 13 Nov 2007 at 16:56, Roy J. Tellason wrote:
I don't have anything here nearly that fast. This is a 500 MHz machine, and
my _server_ is a K6-200. I have a few other boards that I need to test, and
set up some newer stuff, but mostly I'm a ways behind the bleeding edge...
Well, my admittedly limited experience with
stuff is that the "main"
processor isn't doing much of anything while it's waiting for I/O to
complete anyhow, or at least that's what my perception has been. Now
I'll be the first to admit that my perceptions are very much skewed
toward the 8-bit micro and crudely-done DOS-based end of things, so
maybe I just need to get a good hard look at how some other stuff is
done.
Well, why have a multi-gigahertz CPU if you're not going to do
computationally intensive things with it? A lot of graphics and
multimedia is very computationally intensive in today's world, even
with gigaflop GPUs. In the CDC 6600, I should probably say that Seymour
Cray rigged things to
give the *appearance* of 10 PPUs. Core back then was 1 microsecond and the
CPU used it interleaved by a factor of 10, so a cycle time of 100 nsec was
possible. The "10" PPUs all shared a common ALU--each had its own 1
microsecond 4Kx12 bit memory, P-counter and accumulator, and each took a
turn in the "barrel" so that each appeared to be an independent CPU. Access
to central memory (60 bits wide) by the PPUs was obtained through what was
called the "read-write pyramid" where up to 5 CPU words could be in various
stages of assembly or disassembly. It was very slick.
Since some really fast static RAM parts are out there these days (stuff that
can be pulled off old 386 and 486 boards ferinstance) maybe I can play some
of those sort of games with some 8-bit parts that have comparatively long
cycle times... :-)
And yes, in its day, the 6600 was considered to be a
computational
"monster" that used a lot of the tricks we use today to speed up CPU
execution. Slow functional units were segmented (early pipelining),
there was a read-ahead cache for instructions, so it was possible to
keep small loops entirely in cache, and elegant scheduling method was
used to control instruction scheduling. And the instruction set
itself was very simple; some refer to it as very RISC-like.
There was a lot of clever thought and a lot of elegance in early hardware and
software that seems sadly lacking in more current stuff. My recent comment
about WordStar's so apparently seamless switch from all-in-memory to using a
bunch of disk space I commented on recently being one example. I have
patched the living hell out of the copy of ws.com I used, doing all sorts of
stuff to it -- because I could! :-) Sure it took some doing, but these
days a lot of knowledge of that sort seems to be just about lost
completely. :-(
All this with core and discrete transistors, yet.
Yup...
--
Member of the toughest, meanest, deadliest, most unrelenting -- and
ablest -- form of life in this section of space, ?a critter that can
be killed but can't be tamed. ?--Robert A. Heinlein, "The Puppet Masters"
-
Information is more dangerous than cannon to a society ruled by lies. --James
M Dakin
2:38 p.m.
On Nov 14, 2007, at 11:22 PM, Roy J. Tellason wrote:
There was a lot of clever thought and a lot of
elegance in early
hardware and
software that seems sadly lacking in more current stuff. My recent
comment
about WordStar's so apparently seamless switch from all-in-memory
to using a
bunch of disk space I commented on recently being one example. I have
patched the living hell out of the copy of ws.com I used, doing
all sorts of
stuff to it -- because I could! :-) Sure it took some doing, but
these
days a lot of knowledge of that sort seems to be just about lost
completely. :-(
What, you can't patch ws.com anymore? ;)
-Dave
--
Dave McGuire
Port Charlotte, FL
Farewell Ophelia, 9/22/1991 - 7/25/2007
5:49 p.m.
On Thursday 15 November 2007 09:38, Dave McGuire wrote:
On Nov 14, 2007, at 11:22 PM, Roy J. Tellason wrote:
I don't think people know how, or that software is being written to deal with
doing things like this to it...
--
Member of the toughest, meanest, deadliest, most unrelenting -- and
ablest -- form of life in this section of space, ?a critter that can
be killed but can't be tamed. ?--Robert A. Heinlein, "The Puppet Masters"
-
Information is more dangerous than cannon to a society ruled by lies. --James
M Dakin
There was a lot of clever thought and a lot of
elegance in early hardware
and software that seems sadly lacking in more current stuff. My recent
comment about WordStar's so apparently seamless switch from all-in-memory
to using a bunch of disk space I commented on recently being one example.
I have patched the living hell out of the copy of ws.com I used, doing
all sorts of stuff to it -- because I could! :-) Sure it took some
doing, but these days a lot of knowledge of that sort seems to be just
about lost completely. :-(
What, you can't patch ws.com anymore? ;) 
14 Nov
14 Nov
5:48 p.m.
On Nov 13, 2007 1:56 PM, Roy J. Tellason <rtellason at verizon.net> wrote:
Well, my admittedly limited experience with stuff is
that the "main"
processor isn't doing much of anything while it's waiting for I/O to complete
anyhow, or at least that's what my perception has been. Now I'll be the
first to admit that my perceptions are very much skewed toward the 8-bit
micro and crudely-done DOS-based end of things, so maybe I just need to get
a good hard look at how some other stuff is done.
If the processor isn't doing other things while waiting for I/O to
complete, it's either a case where 1) the OS or computer architecture
doesn't allow such things, 2) the application would not be helped by
doing other things during I/O, 3) cross machine compatibility
prevented it from being implemented or 4) the programmer was too lazy
to implement it.
It the case of MS-DOS (the term DOS is insufficiently specific) it
could be any of the four. Interrupt driven I/O or DMA were not
available on all MS-DOS machine to all devices. If it was available,
it wasn't too terribly difficult to implement non-blocking I/O by
difficult to setting up a transfer and doing other things while the
transfer completed.
Most multitasking operating systems implement blocking and
non-blocking I/O as system calls. Blocking I/O usually only blocks
the calling process. The transfer is set up and a task switch is
executed to transfer control to another process. Each time the
process reawakens, it checks to see if the I/O is complete. If not it
executes as task switch.
I would assume that Multics is set up this way as well. Each time a
process request I/O, the CPU tells the I/O processors what to do and
then transfers control to another process.
So aside from computationally-intensive tasks what
else is there for it to do?
Whatever another process wants it to do. If no other process wants
anything to be done, then it will execute the idle process. What the
idle process does is OS dependent. It might do housekeeping tasks, it
might make das blinkenlights show pretty patterns, or it might halt
the processor until the next interrupt.
> In any processor with pipelining, instruction
look-ahead and caching,
> branch prediction and all of those other little gimmicks that make
> execution faster, the idea of interposing interrupts that bollix up
> all of the above is pure insanity.
Yet that's still how it is done. You just try to execute as few
interrupts as possible by making transfers larger. Although you have
to watch out because SOME operating systems will default to 1
interrupt per word transferred. Watch your key presses, because
there's probably and interrupt AND a task switch every time you press
one.
Not that it matters that much anyway since a modern processor on
non-trivial code is spending 90% of its cycles waiting for memory.
A few thousand cycles for an interrupt is nothing...
I'm basing that number on FLOPs per cycle for typical medium sized
(64MB working set) scientific computing applications. Spending a lot
of time optimizing (transposing arrays when necessary to make memory
accesses ordered, precaching the correct things at the correct time,
choosing not to cache the correct things at the correct time) you can
get that down to 65% of the time waiting on memory. It sound like a
lot of work for minimal gain, but please realize the difference
between 90% waiting and 65% waiting is a factor of 3.5 in execution
speed.
Ah, the good old days when processor and memory operated at nearly the
same speed.
Maybe not so good when you consider that loading a 16 bit word on an
8086 took 10 times longer than loading a half kilobit cache line does
now.
--
Eric
6:53 p.m.
On 14 Nov 2007 at 9:48, Eric J Korpela wrote:
Ah, the good old days when processor and memory
operated at nearly the
same speed.
That hasn't been true probably since the 1950's. Core was slow
compared to CPU speeds and drum was even slower, particularly if
random access was employed. Modern memory is actually a closer match
to CPU speed than drum ever was.
That CDC 6600 I described (circa 1964) had 1 usec memory and an
instruction issue rate of 100 nsec. Memory had a 10-way interleave,
so it cost only 100 nsec to fetch successive words. On the STAR-100,
we used 7600 core modules, interleaved and a 512-bit (actually 544
with ECC bytes) memory word size. Memory was slow in 1970 and still
is.
Maybe that's one of those "laws"...?
Cheers,
Chuck
4:52 p.m.
Chuck Guzis wrote:
On 14 Nov 2007 at 9:48, Eric J Korpela wrote:
I'm reasonably sure that the MicroVAX II (KA630) didn't use a cache
because
the CPU cycle time matched the memory cycle time exactly. 200ns is the
time that sticks in my mind for some reason ...
Antonio
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.5.503 / Virus Database: 269.15.31/1130 - Release Date:
14/11/2007 09:27
Ah, the good old days when processor and memory
operated at nearly
the same speed.
That hasn't been true probably since the 1950's. Core was slow
compared to CPU speeds and drum was even slower, particularly if
random access was employed. Modern memory is actually a closer match
to CPU speed than drum ever was.
9:15 p.m.
I'm reasonably sure that the MicroVAX II (KA630)
didn't use a cache
because the CPU cycle time matched the memory cycle time exactly.
Well, it does have cache of a kind. When I was working on my KA630
emulator, I found that it has an instruction prefetch buffer which is
not cleared by setting $MAPEN. (An I-stream prefetch buffer is not a
cache in one usual sense of the term, but is in another.)
/~\ The ASCII der Mouse
\ / Ribbon Campaign
X Against HTML mouse at rodents.montreal.qc.ca
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
11:42 p.m.
On Nov 14, 2007 10:53 AM, Chuck Guzis <cclist at sydex.com> wrote:
On 14 Nov 2007 at 9:48, Eric J Korpela wrote:
It seemed in the late 70s that microprocessor instruction speeds were
pretty well matched to the memory access time. 4MHz processors and
250 ns DRAM Of course this could be an artifact of the design (the
processors may have been slowed down from their potential speeds in
order to match the memory speed).
Now you've done it. I'm having "wait state" flashbacks. I remember
being impressed by a 7.16 MHz V30 running with no wait cycles so long
as you didn't want to play a game...
Eric
Ah, the good old days when processor and memory
operated at nearly the
same speed.
That hasn't been true probably since the 1950's. Core was slow
compared to CPU speeds and drum was even slower, particularly if
random access was employed. Modern memory is actually a closer match
to CPU speed than drum ever was.
15 Nov
15 Nov
12:36 a.m.
On 14 Nov 2007 at 15:42, Eric J Korpela wrote:
It seemed in the late 70s that microprocessor
instruction speeds were
pretty well matched to the memory access time. 4MHz processors and
250 ns DRAM Of course this could be an artifact of the design (the
processors may have been slowed down from their potential speeds in
order to match the memory speed).
Microprocessors, yes, but the technology was still very young. Try
something mature like big iron--cycle times in the tens of
nanoseconds. Memory had a long way to go, then.
Cheers,
Chuck
14 Nov
14 Nov
7:31 p.m.
Eric J Korpela wrote:
Maybe not so good when you consider that loading a 16
bit word on an
8086 took 10 times longer than loading a half kilobit cache line does
now.
I got a game playing under XP and every so often you get a nice crash[1]
and every thing stops cold.About the only thing that works is the power
off switch on the case.Then you have the Serial Botch as another source
of interupts.Some how I still get the fealing IRQ's are hack under any
windows version.
Ben.
[1] 15 to 15 minutes or so.
7:43 p.m.
On Nov 14, 2007, at 12:48 PM, Eric J Korpela wrote:
Not that it matters that much anyway since a modern
processor on
non-trivial code is spending 90% of its cycles waiting for memory.
A few thousand cycles for an interrupt is nothing...
This isn't the case with some architectures. Intel's
HyperThreading is designed to address this problem, but it is broken
in its current implementation. Sun's Niagara architecture
(UltraSPARC-T1 and -T2) deals with it successfully.
Ah, the good old days when processor and memory
operated at nearly the
same speed.
Those days are back, with modern architectures like UltraSPARC/
Niagara. It's very tasty stuff. Zoom!
-Dave
--
Dave McGuire
Port Charlotte, FL
Farewell Ophelia, 9/22/1991 - 7/25/2007
8:40 p.m.
New subject: TU-81+ and KLESI help sought
My apologies if I asked this before, but still can't find the answer or any
responses in my overstuffed inbox :)
I have a TU-81+ that I'd like to hook up to my 11/44.
1) I can find no documentation for the KLESI-UA board (M8739). Can someone
kindly point me to what the switch/jumper settings are for that board? I do
see much mention of the M8739 in the TU81 manual, but nothing about
jumper/switch settings. Maybe I'm just missing it :\
2) The disc currently connected to the 11/44 has RT11 v5.04 on it. Does that
version of RT11 support the KLESI-UA attached tape drive or do I need to
upgrade RT11 or get an additional driver for it?
Really I'm just wanting to see if the 11/44 "sees" the TU81+. I was hoping
to see it under "SH DEV", but if it's not supported on 5.04 perhaps theres a
toggle in I can use to see if it's there?
Any suggestions or advice is most appreciated!
Jay West
11:30 p.m.
New subject: TU-81+ and KLESI help sought
Thanks to the two folks who responded on my KLESI-UA stuff! The particular
TU81 manual I was pointed to wasn't on bitsavers. It pretty much answered
all my questions so far.
RT11 at least sees the board at 174500 now (thanks to switch settings!).
When the system boots it tried to do R MSCPCK which hangs now... probably
not a good sign. If I break out of the bootstrap before that, a copy to MU0:
hangs as well. Hrm....
ZTU2?? isn't happy though, I tried two different KLESI-UA's with no
different results. Both halt during test 1.
I guess first question is the cable. From KLESI-UA to bulkhead I had a
70-18652. The round DD50 from the tape drive plugs in to that. In looking at
the docs provided, it appears I should be using a 70-19923. Aren't all these
just 50 pin straight through cables, or is there a difference that is
catching me? Thinking it was just 50 pins straight through with a DD50, I
also tried a 70-20691 which also appears to just go straight to the DD50.
Same problem with all of them. Is this supposed to be a specialty cable?
Failing that... either both KLESI's are dead, or there's something seriously
amiss with the TU81 itself. I shall dig into the TU81+ manual given above
and see I can figure out the troubleshooting steps. Advice appreciated :)
Thanks!
Jay West
15 Nov
15 Nov
4:58 a.m.
New subject: TU-81+ and KLESI help sought
Hi Jay,
I'm still up to my neck in you know what, and am sorry about not getting
back to you sooner. I'll still have to verify, but I think the TU81+ was
set up for cluster systems, and the TU81 was for stand alone.
Paul
On 11/14/07, Jay West <jwest at classiccmp.org> wrote:
Thanks to the two folks who responded on my KLESI-UA stuff! The particular
TU81 manual I was pointed to wasn't on bitsavers. It pretty much answered
all my questions so far.
RT11 at least sees the board at 174500 now (thanks to switch settings!).
When the system boots it tried to do R MSCPCK which hangs now... probably
not a good sign. If I break out of the bootstrap before that, a copy to
MU0:
hangs as well. Hrm....
ZTU2?? isn't happy though, I tried two different KLESI-UA's with no
different results. Both halt during test 1.
I guess first question is the cable. From KLESI-UA to bulkhead I had a
70-18652. The round DD50 from the tape drive plugs in to that. In looking
at
the docs provided, it appears I should be using a 70-19923. Aren't all
these
just 50 pin straight through cables, or is there a difference that is
catching me? Thinking it was just 50 pins straight through with a DD50, I
also tried a 70-20691 which also appears to just go straight to the DD50.
Same problem with all of them. Is this supposed to be a specialty cable?
Failing that... either both KLESI's are dead, or there's something
seriously
amiss with the TU81 itself. I shall dig into the TU81+ manual given above
and see I can figure out the troubleshooting steps. Advice appreciated :)
Thanks!
Jay West
5:44 a.m.
New subject: TU-81+ and KLESI help sought
Paul wrote...
I'm still up to my neck in you know what, and am
sorry about not getting
back to you sooner.
No problem at all.
I'll still have to verify, but I think the TU81+
was
set up for cluster systems, and the TU81 was for stand alone.
If I'm reading
the manuals right, you're thinking of the difference between
TU81 and TA81. TU81 was TMSCP while TA81 "supported" multiple hosts via
STI/HSC. I think the difference between TU81 and TU81+ is that the + version
has a cache to help keep the unit streaming?
Jay
14 Nov
14 Nov
11:32 p.m.
On Nov 14, 2007 11:43 AM, Dave McGuire <mcguire at neurotica.com> wrote:
On Nov 14, 2007, at 12:48 PM, Eric J Korpela wrote:
You are correct, I should have said "modern single-threaded
processor." If you multithread your
application code and run it on a CPU with multiple hardware threads
you should be able (best case) to turn than 90% into 90%^N where N is
the number of truly independent hardware threads. In other words,
with two threads each thread spends 90% of the time waiting, so overal
the processor is only spending 81% of the time waiting, which would
nearly double the processor performance.
In reality you probably won't get there, though. Especially in Intel
(Prescott?) hyperthreading where the threads share a register file and
execution unit, you're lucky to get down to 87% of time waiting for
memory. That also assumes you've designed your code properly so that
the threads don't contend for the same cache lines.
Don't know too much about the Niagara equivalent, but for my purposes
(numerics) the flaw of Niagara was all the cores shared the same FPU.
I guess that was fixed in Niagara II, though.
Eric
Not that it matters that much anyway since a
modern processor on
non-trivial code is spending 90% of its cycles waiting for memory.
A few thousand cycles for an interrupt is nothing...
This isn't the case with some architectures. Intel's
HyperThreading is designed to address this problem, but it is broken
in its current implementation. Sun's Niagara architecture
(UltraSPARC-T1 and -T2) deals with it successfully. 
23 Nov
23 Nov
10:22 p.m.
On Tue, 13 Nov 2007 10:30:10 -0800
"Chuck Guzis" <cclist at sydex.com> wrote:
It just makes sense. It's a shame we don't
any modern PCs with a
standardized peripheral processor structure, particularly given the
cost of a microcontroller nowadays.
There was. Unfortunately it faild:
http://en.wikipedia.org/wiki/I2O
There is or was a 100 MBit/s or 1 GBit/s Ethernet chip that used a build
in MIPS core as controler.
The DEC DEF[QTEP]A FDDI card uses a M68k to implement the complex SMT
(Station MangemenT) in "hardware". Similar for the SGI GIO FDDI cards,
they are driven by an AMD 29k.
The Symbios / NCR SCSI chips have some sort of RISC core inside. I saw
DEC PCI DSSI cards with 53C825 on them. So DEC rewrote the firmware of
that RISC core to implement DSSI instead of SCSI. (AFAIK DSSI and SCSI
are quite different as DSSI is just a cheap parallel physical transport
for CI...)
--
tsch??,
Jochen
Homepage: http://www.unixag-kl.fh-kl.de/~jkunz/
6253
days inactive
6264
days old
96 comments
35 participants
participants (35)
-
aek＠bitsavers.org -
arcarlini＠iee.org -
ard＠p850ug1.demon.co.uk -
bfranchuk＠jetnet.ab.ca -
bpope＠wordstock.com -
brain＠jbrain.com -
cc＠corti-net.de -
cclist＠sydex.com -
curt＠atarimuseum.com -
dgriffi＠cs.csubak.edu -
dkelvey＠hotmail.com -
doc＠mdrconsult.com -
ethan.dicks＠usap.gov -
fu3.org＠gmail.com -
geoffr＠zipcon.net -
gordonjcp＠gjcp.net -
huw.davies＠kerberos.davies.net.au -
jfoust＠threedee.com -
jkunz＠unixag-kl.fh-kl.de -
julesrichardsonuk＠yahoo.co.uk -
jwest＠classiccmp.org -
jwstephens＠msm.umr.edu -
korpela＠ssl.berkeley.edu -
legalize＠xmission.com -
mcguire＠neurotica.com -
mouse＠Rodents.Montreal.QC.CA -
pat＠computer-refuge.org -
pete＠dunnington.plus.com -
ploopster＠gmail.com -
rickb＠bensene.com -
rtellason＠verizon.net -
spc＠conman.org -
spectre＠floodgap.com -
useddec＠gmail.com -
wdonzelli＠gmail.com