7 Aug
2002
7 Aug
'02
10:48 p.m.
I've finally gotten the drive 0 reverse motor on my TU-56 tape drive
working. It required the replacement of two transistors on the Motor Drive
Control Board. The problem I now have is that the motor only runs at high
(18V) speed, even when it should be running at low (9V) speed. Any hints as
to where to look next?
As an aside, I think fixing the things is more fun than running them.
8 Aug
8 Aug
12:43 a.m.
Christopher McNabb wrote:
I've finally gotten the drive 0 reverse motor on
my TU-56 tape drive
working. It required the replacement of two transistors on the Motor Drive
Control Board. The problem I now have is that the motor only runs at high
(18V) speed, even when it should be running at low (9V) speed. Any hints as
to where to look next?
As an aside, I think fixing the things is more fun than running them.
Jerome Fine replies:
As a software person, I can't help with the tape drive.
But your comment about fixing the hardware is interesting.
I find that my personal experience with software is about
the same - I enjoy fixing the bugs plus enhancing the
software I use (I am an RT-11 addict) more than just
using the programs. Although I must admit that I have
found that some of the enhancements I have made to
the Single Line Editor (SL:) as well as to the Binary
Compare utility (BINCOM) have been extremely helpful
when I use them to help with other work.
Sincerely yours,
Jerome Fine
--
If you attempted to send a reply and the original e-mail
address has been discontinued due a high volume of junk
e-mail, then the semi-permanent e-mail address can be
obtained by replacing the four characters preceding the
'at' with the four digits of the current year.
11:54 a.m.
A non-text attachment was scrubbed...
Name: not available
Type: text
Size: 765 bytes
Desc: not available
Url :
http://www.classiccmp.org/pipermail/cctalk/attachments/20020808/fa4bbfda/at…
1 p.m.
Tony Duell wrote:
So do I. I often spend weeks repairing all the faults
in a machine, and
then when I get it working, I rarely power it up again :-). Faultfinding
is fun -- it's like solving puzzles.
Jerome Fine replies:
Maybe that is why software can be even more fun - for those
of us who enjoy the challenge. With software, there is never
any end of enhancements. So after all the bugs are fixed, a
program can still provide a great deal of enjoyment.
And I even found a bug in RT-11 operating system software
that is almost 20 years old. What is curious is that it was found
when I was looking at the code and realized it would not function
correctly the way it was written. In normal operation, the bug
probably occurs so rarely that it can't even be duplicated. As
a result, it probably gets chalked up to random radiation on the
rare chance it does occur.
But I certainly seem to be in the minority on the list which
seems to feel that hardware is .....
Sincerely yours,
Jerome Fine
--
If you attempted to send a reply and the original e-mail
address has been discontinued due a high volume of junk
e-mail, then the semi-permanent e-mail address can be
obtained by replacing the four characters preceding the
'at' with the four digits of the current year.
9 Aug
9 Aug
11:41 a.m.
A non-text attachment was scrubbed...
Name: not available
Type: text
Size: 1325 bytes
Desc: not available
Url :
http://www.classiccmp.org/pipermail/cctalk/attachments/20020809/902c0b5e/at…
10 Aug
10 Aug
12:55 p.m.
Tony Duell wrote:
Jerome Fine
replies:
Maybe that is why software can be even more fun - for those
of us who enjoy the challenge. With software, there is never
any end of enhancements. So after all the bugs are fixed, a
program can still provide a great deal of enjoyment.
And you think this
doesn't also apply to hardware? Any interesting
computer (heck, any interesting calculator as well) has some kind of
expansion bus. So there are always more interfaces to design and build :-) And there are internal hardware mods to try out too.
But my impression was that the definition of hardware for
a specific computer is a given. I would never even dream
of attempting to modify the hardware for my PDP-11 so
that it could do something different. Of course, not being
able to even consider that does lower my horizon.
In addition, I don't consider that limitation when I am dealing
with an emulator. I have asked John Wilson to modify E11
to allow a number of items:
(a) Be able to identify E11 via a PDP-11 instruction
(b) Add 32 bit integer arithmetic - at least add and subtract
(c) Add 64 bit integer arithmetic - at least add and subtract
In addition, there already is the capability to add a "dll" (don't
ask me exactly how is is done - and it is ONLY for the FULL
version) which is able to directly access the memory of the PC
via "emulated hardware registers" (addresses in the I/O page)
using PDP-11 instructions. Doing that with a real PDP-11
would probably be very easy these days - just add a board
that contains the required hardware - and with memory so
inexpensive, it could use the same memory chips that the PC
uses.
I guess that with software there are 2 main things you
can do (apart from
use it!). You can fix origianl bugs. Or you can modify it to do
something (slightly?) different.
Or even something very different, especially to add code which can
do something very different.
With hardware there are _3_ main areas. Fix design
bugs (and yes there
are plenty of those in some machines). Redesign bits to add nrew
features, etc. But you can also trace and fix component failures --
circuits that should work correctly but don't because a transistor is no
longer a transistor, or whatever. There doesn't seem to be an equivalent
for that in software.
If I thought about each hardware item, I am sure that an equivalent
software item could be found. That might possibly be because the
definition of hardware and software has become blurred due to
firmware. Hardware on the outside sees a firmware change as
a software mod. Software from the inside sees a firmware change
as a hardware mod.
I have a great example of an OLD bug in the firmware for the
CQD 220/TM which was corrected over ten years ago.
As for your last example, I think that a bug that is in the RT-11
operating system (been there for almost 20 years) could also be
equivalent to the hardware difficulty you mention. In this case,
the problem is almost impossible to duplicate, so it might even
seem to be a random hardware failure - especially since the
cause is unknown - and the fault which occurs could not easily
be traced to the software bug which causes the problem.
In that aspect, such intermittent problems are the most difficult
to trace and find the cause.
About the only real difference between hardware and software
problems is the essential nature of what is software and hardware.
Hardware can break in an individual manner and the problem would
then be with just one computer. Software can also cause such
problems, but only if there is a pre-existing bug.
Sincerely yours,
Jerome Fine
--
If you attempted to send a reply and the original e-mail
address has been discontinued due a high volume of junk
e-mail, then the semi-permanent e-mail address can be
obtained by replacing the four characters preceding the
'at' with the four digits of the current year.
11 Aug
11 Aug
6:24 a.m.
A non-text attachment was scrubbed...
Name: not available
Type: text
Size: 6902 bytes
Desc: not available
Url :
http://www.classiccmp.org/pipermail/cctalk/attachments/20020811/1b242847/at…
8:44 a.m.
Tony Duell wrote:
Tobe honest, it would probably be easier to make a new
processor from
scratch if you wanted to do something like this to the hardware. Just as,
I susepct, if you wanted to design an emulator for a ficticious
processor, then you wouls wnt to start by designing a clean, orthogonal,
instruction set. But it would be possible to start from an existing
'machine' in either case.
Not in all cases. Working on a homebrew FPGA 12/24 bit cpu
I don't really have a base machine to work from. The current
machine I am working on will not have a emulator but be rather
debugged on-line. I do have a earlier similar CPU design but
it was not clean as I liked but since I have a emulator
written and mostly debugged hardware I can use this for software
testing and debuging for the new machine.
But no real PDP11 has those instructions. So if you
add them to a PDP11
emulator, then the result is no longer a PDP11 emulator, in that there is
a sequence of instructions that behaves differently on the PDP11 and the
emulator. Just as if you wire up a 32 bit ALU and registers to a PDP11
processor board, the resulting machine is no longer a true PDP11.
No it would be just a PDP-11 with strange I/O board. While I have not
looked at the PDP-11 instruction set in depth there does not seem to
be room for more instructions.
There have been all sorts of interefaces proposed and made over the years
to let one computer have access to the memory of another. People have
designed cards that appear as I/O ports to the 'master' system and act
as proper bus master on the other side (so they can request the bus from
another genuine processor on, say, a VME bus and then access the memory
and peripherals over there). Simpler ones just insist on being the only
master on the 'slave' side -- there have been many attempts to add ISA
slots to other machines in this way to allow the use of cheap ISA I/O
cards, for example.
But really other than video or network stuff what is there?
You are better off building your own card as ISA I/O sucks!
In the second case you'll find things like a
2N3904 transistor that's
open-circuit base-emitter, and which is therefore not a transistor at
all. Or a 10uF capacitor that behaves as though it has a 100 ohm resistor
in series with it, inside the can (this is what's mean by ESR --
effective series resistance). The components are not what they claim to
be any more. If you rebuilt this cirucit with known-good components then
it would behave as originally intended. I really can't think of a
software equivalent of this.
True, but data formats can change over time requiring software tweeks now and then.
12 Aug
12 Aug
1:10 p.m.
Tony Duell wrote:
In one sense it is. It would be possible to modify a
PDP11 and add (say)
transcendental functions (SIN, COS, TAN, etc) to the floating point
coprocessor (yes, I do realise this is not at all a trivial modification,
but it's certainly possible). But the result would probably not be called
a PDP11. Certainly if I modified a PDP11 to have 32 bit registers and
ALU, then the result wouldn't be a PDP11.
Jerome Fine replies:
The answer I am giving is NOT practical in general, but for specific cases
can be helpful.
First, I was not ever suggesting that the basic underlying hardware registers
be modified when I mentioned 32/64 bit integer arithmetic. Rather that
existing registers/memory be used in a manner which could still hold the
32/64 bit results - and then the only change would be that a single instruction
within the "PDP-11" code be used to replace multiple instructions. Exactly
the same thing could be done within a current "real" PDP-11 to implement
what "seems" to be that capability as is done with "impaired" PDP-11
CPUs
such as an 11/03 which do NOT implement some of the instructions that
more intelligent CPUs have such as the 11/23 or the 11/73. In that case,
a TRAP SUBROUTINE handles the missing instruction and it is emulated,
at of course an even higher overhead as opposed to inline code or a normal
subroutine call.
That approach with a "real" PDP-11 IS worth while when the feature is
used extensively since even calling a subroutine has overhead. The saving
over inline code is often worth the extra overhead.
HOWEVER, when an emulator is being used, it is possible to "implement"
a different solution. Rather than using a TRAP SUBROUTINE, it is
possible to actually have our cake and eat it at the same time. The
emulator can be "instructed" to recognize the "new instruction" and
because
that level of implementation is MUCH more efficient and much faster,
there is much more benefit.
I could provide other examples, but this one is simple and clear-cut.
Either the method is acceptable or it is not. The key is that ONLY
what a TRAP SUBROUTINE can do is allowed - nothing more.
But I feel the same restriction applies to emulators
too. A PDP11
emulator has to do what a real PDP11 would do. If you start adding extra
instructions, then it's no longer emulating a PDP11. It's emulating an
enhanced processor that was based on the PDP11. Which is exactly what
hardware mods would give you.
I agree. But I still suggest that under an emulator, the approach I
am suggesting can often be useful. I agree that it would need to be
backed up with the equivalent code that a TRAP SUBROUTINE
would use with real PDP-11 systems.
Tobe honest, it would probably be easier to make a new
processor from
scratch if you wanted to do something like this to the hardware. Just as,
I susepct, if you wanted to design an emulator for a ficticious
processor, then you wouls wnt to start by designing a clean, orthogonal,
instruction set. But it would be possible to start from an existing
'machine' in either case.
Now that seems interesting - at least for hardware. Is it relatively
that easy these days to implement a PDP-11 instruction set and all
the interrupts? I know that at least two companies have done that.
QED is one and Osprey might be another.
In addition, I
don't consider that limitation when I am dealing
with an emulator. I have asked John Wilson to modify E11
to allow a number of items:
(a) Be able to identify E11 via a PDP-11 instruction
OK, that's reasonable,
because you could identify some later models of
PDP11 in that way IIRC. (b) Add 32
bit integer arithmetic - at least add and subtract
(c) Add 64 bit integer arithmetic - at least add and subtract
But no real PDP11
has those instructions. So if you add them to a PDP11
emulator, then the result is no longer a PDP11 emulator, in that there is
a sequence of instructions that behaves differently on the PDP11 and the
emulator. Just as if you wire up a 32 bit ALU and registers to a PDP11
processor board, the resulting machine is no longer a true PDP11. In addition,
there already is the capability to add a "dll" (don't
ask me exactly how is is done - and it is ONLY for the FULL
version) which is able to directly access the memory of the PC
via "emulated hardware registers" (addresses in the I/O page)
using PDP-11 instructions. Doing that with a real PDP-11
would probably be very easy these days - just add a board
that contains the required hardware - and with memory so
inexpensive, it could use the same memory chips that the PC
uses.
There have been all sorts of interefaces proposed and made over the years
to let one computer have access to the memory of another. People have
designed cards that appear as I/O ports to the 'master' system and act
as proper bus master on the other side (so they can request the bus from
another genuine processor on, say, a VME bus and then access the memory
and peripherals over there). Simpler ones just insist on being the only
master on the 'slave' side -- there have been many attempts to add ISA
slots to other machines in this way to allow the use of cheap ISA I/O
cards, for example. I guess that with software there are 2 main things you
can do (apart from
use it!). You can fix origianl bugs. Or you can modify it to do
something (slightly?) different.
Or even something very different, especially to
add code which can
do something very different. As for your
last example, I think that a bug that is in the RT-11
operating system (been there for almost 20 years) could also be
equivalent to the hardware difficulty you mention. In this case,
Not really. The
software bug was always there. It was a design defect
really. We have those in hardware too, and some of them occur _very_
infrequently. But software doesn't fail with time (OK, the media
it's stored on can
fail, but then you can restore from a backup and have a perfect copy
again). If something worked right once, then it will always work right.
If there's a design bug, then that bug will be there until it's cured.
And if the programmer tells the program to do the wrong thing,
then the computer will do that as well - and every time. A long time
ago, the definition I was told of a computer (A SPEEDY MORON)
does not seem to have changed.
This is not true of hardware. You can have a circuit
which was correctly
designed, and which worked perfectly for 10 years (say). And then a
component fails. It stops working. You have to find that faulty component
and replace it.
That does seem to be the one big difference. While hardware can be
built to detect its own failures, presently that is very unusual.
The differece (at the hardware level) between the 2
sorts of bugs is
really that in the first case all the components are still what they
claim to be. A resistor with brown, black, orange bands is still a 10k
resistor. A 2N3904 transistor is still an NPN transistor meeting the
characteristics given in the data sheet. A 74LS00 is still a quad 2-input
NAND gate. It's just that the way they are connected together produces a
circuit that doesn't do what the designer intended. That's a design bug.
Very similar in software.
In the second case you'll find things like a
2N3904 transistor that's
open-circuit base-emitter, and which is therefore not a transistor at
all. Or a 10uF capacitor that behaves as though it has a 100 ohm resistor
in series with it, inside the can (this is what's mean by ESR --
effective series resistance). The components are not what they claim to
be any more. If you rebuilt this cirucit with known-good components then
it would behave as originally intended. I really can't think of a
software equivalent of this.
But that is why there is a difference between hardware and software,
just as you stated above. You are entirely correct.
In that
aspect, such intermittent problems are the most difficult
to trace and find the cause.
That is certainly true of hardware problems also.
Faults that 'stay put'
when you are looking for them are much easier to find :-)
1:56 p.m.
Jerome H. Fine wrote:
But I am totally unable to solve hardware problems, so
it would
be interesting to know how long the average hardware fix takes?
It really depends
on A) How fast can you be without a computer or
radio or whatever. B) Finding the bug and getting parts to repair.
I would suspect software and hardware bugs take the same magnitude
of time to find.It is when you have software interacating with
hardware the fun begins are you are now not sure what works.
3:08 p.m.
New subject: [movie] On Guard! The Story of SAGE
I just noticed this up at www.archive.org. It's a short film from
1956 put out by IBM about SAGE. This is a great little film with a
nice overview of SAGE and the modular computers used on B-52 bombers.
The following links point to different formats of the same film. I was
able to play the MPEG-1 file under Quicktime on Mac OS X without any
problems.
MPEG-1 (128.1MB): http://ftp.archive.org/movies/vcd/06855.mpg
AVI (38.8MB): http://ftp.archive.org/movies/divx/06855.avi
-brian.
3:57 p.m.
Ben Franchuk wrote:
Jerome H. Fine
wrote:
But I am totally unable to solve hardware problems, so it would
be interesting to know how long the average hardware fix takes?
It really depends
on A) How fast can you be without a computer or
radio or whatever. B) Finding the bug and getting parts to repair.
I would suspect software and hardware bugs take the same magnitude
of time to find.It is when you have software interacating with
hardware the fun begins are you are now not sure what works.
13 Aug
13 Aug
11:49 a.m.
A non-text attachment was scrubbed...
Name: not available
Type: text
Size: 1869 bytes
Desc: not available
Url :
http://www.classiccmp.org/pipermail/cctalk/attachments/20020813/5748c176/at…
12:21 p.m.
On Wed, 14 Aug 2002, Tony Duell wrote:
As Ben (?) said, the fun really starts when you have designed (and
constructed) both the hardware and the software yourself. Say you've
built a little microcontroller system and written the firmware for it.
You can have :
A hardware design problem (you used the wrong components)
A hardware construction problem (you wired to the wrong pin on the IC,
you shorted to connections together with a solder blob by mistake)
A software desgin problem (you used the wrong algorithm)
A software construction problem (you mis-coded that algorithm in the
machine code for the CPU you are using. A trivial example would be
assuming that an instruction affects CPU flags when, in fact, it doesn't,
or vice versa).
Actually it can get worse... because you may well have your own (maybe buggy
and always changing) software tools for creating or debugging the firmware...
Problems noted when trying to debug some FPGA based microcontroller firmware:
Firmware error (since I dont write the firmware I always blame this first ;-)
Bad FPGA hardware definition file (CPU or peripheral -- Stiffware error?)
Wrong hardware (Stiffware?) revision for firmware
CPU/assembler version mismatch
CPU/single stepper/dissasembler mismatch
I guess its time to have a CPU revision register in my CPU...
I would suspect software and hardware bugs take the
same magnitude
of time to find.It is when you have software interacating with
hardware the fun begins are you are now not sure what works.
Jerome Fine replies:
Fortunately I can't remember having that problem very often.
When I first started to program computers, I found it difficult
to find software bugs. While it is still difficult, I now realize that
hardware rarely fails. Although I have found a one or two bugs
You have to be able to isolate what's going on, and quickly, to have any
chance of fixing it. It's best to assume that nothing is correct at the
start, and then to verify everything a bit at a time.
Peter Wallace
(a) I once found a sticky bit - defined as a bit
which was always
ONE when it was supposed to be ONE, but sometimes a ONE
when it was supposed to be zero. The quick solution was to be
sure to place an instruction at that location which required that
the sticky bit be a ONE - that way, the program always worked.
Hardware Hacker's solution : Replace that darn RAM chip. It will 'bite'
you sometime. Other bits might fail too...
-tony
14 Aug
14 Aug
11:54 a.m.
A non-text attachment was scrubbed...
Name: not available
Type: text
Size: 620 bytes
Desc: not available
Url :
http://www.classiccmp.org/pipermail/cctalk/attachments/20020814/7e5f4012/at…
5:25 p.m.
On Thu, 15 Aug 2002, Tony Duell wrote:
Our firmware is in assembler, the problem is what version of the
assembler, since the CPU may change daily... I do pretty well know the opcodes
in hex, ( I deliberately made add = AXXXXh, NOP = 0000h) but whenever I change
some bit field definition I forget what the machine code looks like anymore...
My CPU sort of looks like a pipelined 16 bit PIC so architecture wise
it dates from an on-topic time...
I used to remember most of the TMS9900 machine language (My first
Micro was a Technico 9900 based system, bought in 1976) because at first I
didnt have anything but a hex monitor to input programs with. Just found a
TI99/4 at the flea market for $2.00 so maybe I'll mess around a little with
9900 assembler again...
soorry for the ramble, past my bedtime.....
Actually it
can get worse... because you may well have your own (maybe buggy
and always changing) software tools for creating or debugging the firmware...
Well, I guess I'm way behind the times, as usual, but I still create my
microcontroller firmware in assembly language. And I _alway_ read the hex
file produced by the assembler and check that it really is a correct
assembly of the source code (I particularly check that labels have been
correctly interpretted, etc).
Sure it takes a bit of time to do that (but not as much as you might
think), but it does remove one possible source of problems.
-tony
Peter Wallace
15 Aug
15 Aug
5:20 a.m.
New subject: OT-DIY CPU's
Peter C. Wallace wrote:
Our firmware is in assembler, the problem is what
version of the
assembler, since the CPU may change daily... I do pretty well know the opcodes
in hex, ( I deliberately made add = AXXXXh, NOP = 0000h) but whenever I change
some bit field definition I forget what the machine code looks like anymore...
Hex what is that. OCTAL is the way to go!
Ban all 8/16/32/64 bit computers ... Bring back 18/36 and 12/24 cpu's!
A 18 bit PDP-11 would have been so nice!
My CPU sort of looks like a pipelined 16 bit PIC so
architecture wise
it dates from an on-topic time...
I designing a 12/24 bit cpu that is in the 1980-1985 time frame.
http://www.jetnet.ab.ca/users/bfranchuk/index.html
We have a lot of 16 bit cpu's so what is the advantage of your design
over others. 64K byte memory is the minumum useful memory for a computer.
12K operating system, 48K data & program space. While that is two chips
nowdays for 32KB ram / 32 rom memory even for a controler that is limited memory.
6:33 a.m.
New subject: OT-DIY CPU's
On Thu, 15 Aug 2002, Ben Franchuk wrote:
Peter Wallace
Peter C. Wallace wrote:
Our firmware is in assembler, the problem is
what version of the
assembler, since the CPU may change daily... I do pretty well know the opcodes
in hex, ( I deliberately made add = AXXXXh, NOP = 0000h) but whenever I change
some bit field definition I forget what the machine code looks like anymore...
Hex what is that. OCTAL is the way to go!
Ban all 8/16/32/64 bit computers ... Bring back 18/36 and 12/24 cpu's!
A 18 bit PDP-11 would have been so nice!
My CPU sort of looks like a pipelined 16 bit PIC
so architecture wise
it dates from an on-topic time...
I designing a 12/24 bit cpu that is in the 1980-1985 time frame.
http://www.jetnet.ab.ca/users/bfranchuk/index.html
We have a lot of 16 bit cpu's so what is the advantage of your design over
others. 64K byte memory is the minumum useful memory for a computer. 12K
operating system, 48K data & program space. While that is two chips nowdays
for 32KB ram / 32 rom memory even for a controler that is limited memory.
Well actually we considered a 24 bit design, Heck I like 24 bit
designs, and since our application is motor control, 24 bits is fine for
most position ranges, but for a simple pipelined (1 clock per inst) RISCy
Harvard architecture processor you get into this tradeoff that depends on how
much of your code does math where the 24 bits is an advantage and how much is
simple logic or I/O where 8 bits would be preferable. !6 bits seems about the
right compromise for us.
BTW we only have 1K or 2K of program and RAM space (all BlockRAM on
chip ) If we had to use external RAM we would do things another way. As it is
we have a 4 axis servo motion controller with quadrature inputs, PWM outputs,
32 bit motion parameters, 64 bit accell and velocity DDAs, PID+Accel and Vel
feed forward control loop, position and programable external event
breakpoints, parabolic and cubic rampup-slew-rampdown profiles and s sample
rate (all 4 axis in motion) of about 35 usec, not bad for a $19.55 FPGA
chip...
17 Aug
17 Aug
8:36 p.m.
New subject: OT-DIY CPU's
Hex what is that. OCTAL is the way to go!
Ban all 8/16/32/64 bit computers ... Bring back
18/36 and 12/24 cpu's!
A 18 bit PDP-11 would have been so nice!
Hey! Many 16-bit minicomputers use octal notation -
PDP11, HP1000. Just because your word size is a
multiple of 4 doesn't mean you can't still use octal.
Lee Courtney
--- Ben Franchuk <bfranchuk(a)jetnet.ab.ca> wrote:
> Peter C. Wallace wrote:
>
> > Our firmware is in assembler, the problem is what
> version of the
> > assembler, since the CPU may change daily... I do
> pretty well know the opcodes
> > in hex, ( I deliberately made add = AXXXXh, NOP =
> 0000h) but whenever I change
> > some bit field definition I forget what the
> machine code looks like anymore...
>
Hex what is that. OCTAL is the way to go!
Ban all 8/16/32/64 bit computers ... Bring back
18/36 and 12/24 cpu's!
A 18 bit PDP-11 would have been so nice!
>
> > My CPU sort of looks like a pipelined 16 bit PIC
> so architecture wise
> > it dates from an on-topic time...
> >
> I designing a 12/24 bit cpu that is in the 1980-1985
> time frame.
> http://www.jetnet.ab.ca/users/bfranchuk/index.html
>
> We have a lot of 16 bit cpu's so what is the
> advantage of your design
> over others. 64K byte memory is the minumum useful
> memory for a computer.
> 12K operating system, 48K data & program space.
> While that is two chips
> nowdays for 32KB ram / 32 rom memory even for a
> controler that is limited memory.
>
>
>
__________________________________________________
Do You Yahoo!?
HotJobs - Search Thousands of New Jobs
http://www.hotjobs.com
18 Aug
18 Aug
4:01 a.m.
New subject: OT-DIY CPU's
lee courtney wrote:
Lets not forget the 8080 too.
I was talking about word size being a power of 3.
Still with FPGA's and 36 bit wide memory 36 bit computers
could make a come back. :)
Hex what is
that. OCTAL is the way to go!
Ban all 8/16/32/64 bit computers ... Bring back
18/36 and 12/24 cpu's!
A 18 bit PDP-11 would have been so nice!
Hey! Many 16-bit minicomputers use octal notation -
PDP11, HP1000. Just because your word size is a
multiple of 4 doesn't mean you can't still use octal.
5:01 a.m.
New subject: OT-DIY CPU's
On Sun, 18 Aug 2002, Ben Franchuk wrote:
Lets not forget the 8080 too.
I was talking about word size being a power of 3.
Ahh yes, all those 9-trit, 27-trit, and 81-trit systems from that
parallel universe in which trinary computing won the day.
Still with FPGA's and 36 bit wide memory 36 bit
computers
could make a come back. :)
There are always software emulators, too.
-brian.
5:26 a.m.
New subject: OT-DIY CPU's
Brian Chase wrote:
On Sun, 18 Aug 2002, Ben Franchuk wrote:
Using -1,0,+1 has advantages, but nobody has come up with a
single bit memory storage for it. It takes two bits of data
to store it.
Here is a few links on it how ever.
http://www.trinary.cc/
http://www.americanscientist.org/Issues/Comsci01/Compsci2001-11.html
(Don't expect more)
PS. this is on topic because a FEW trinary computers have been built.
Lets not forget the 8080 too.
I was talking about word size being a power of 3.
Ahh yes, all those 9-trit, 27-trit, and 81-trit systems from that
parallel universe in which trinary computing won the day.
There are always software emulators, too.
But emulators have lousy front panels.
They don't have the feel
of the big iron. Also a PDP-8 in modern techology would really tell
if your latest intel product is fast or not.
6:57 a.m.
New subject: OT-DIY CPU's
A non-text attachment was scrubbed...
Name: not available
Type: text
Size: 1263 bytes
Desc: not available
Url :
http://www.classiccmp.org/pipermail/cctalk/attachments/20020818/62e97761/at…
6:12 a.m.
New subject: OT-DIY CPU's
I was talking
about word size being a power of 3.
Ahh yes, all those 9-trit, 27-trit, and 81-trit
systems from that
parallel universe in which trinary computing won the day.
6:50 a.m.
New subject: OT-DIY CPU's
A non-text attachment was scrubbed...
Name: not available
Type: text
Size: 574 bytes
Desc: not available
Url :
http://www.classiccmp.org/pipermail/cctalk/attachments/20020818/120d3b30/at…
7:01 a.m.
New subject: OT-DIY CPU's
On Sun, 18 Aug 2002, Tony Duell wrote:
Ah, yes.
And lets make all word sizes prime numbers, just so that split words
(such as "nybbles") will be more fun, and not all the same size.
It is obvious (at least to me) that any power of 3 (other than 3 itself
;-)) cannot be a prime number...
You can't have it both ways. Either a power (or multiple?) of 3 as your
word size _or_ a prime number word size.
You are, of course, quite correct. That should have read
"BUT lets make all word sizes prime numbers", to provide even MORE fun and
confusion than powers (or multiples) of 3.
I was talking
about word size being a power of 3.
Ahh yes, all those 9-trit, 27-trit, and 81-trit
systems from that
parallel universe in which trinary computing won the day. 
5:21 a.m.
New subject: OT-DIY CPU's
Ben Franchuk <bfranchuk(a)jetnet.ab.ca> wrote:
I was talking about word size being a power of 3.
I think you mean "a multiple of 3". 12, 18, 24, and 36 aren't
integral powers of 3. If you really want a power of 3, try a 9-bit
or 27-bit machine. I imagine you won't want to build an 81-bit, 243-bit,
or larger machine, but who knows.
6:47 a.m.
New subject: OT-DIY CPU's
A non-text attachment was scrubbed...
Name: not available
Type: text
Size: 160 bytes
Desc: not available
Url :
http://www.classiccmp.org/pipermail/cctalk/attachments/20020818/dfd17e16/at…
6:54 a.m.
New subject: OT-DIY CPU's
On Sun, 18 Aug 2002, Tony Duell wrote:
I think that he meant a multiple of 3, but a POWER of 3 would add the
extra fun that splitting a word into smaller equal pieces would then be
limited to only powers of 3.
I was talking
about word size being a power of 3.
Do you mean a 'multiple of 3' here, or
are you thinking of 3, 9, 21, 81,
... bit machines only?
6:30 a.m.
New subject: OT-DIY CPU's
A non-text attachment was scrubbed...
Name: not available
Type: text
Size: 872 bytes
Desc: not available
Url :
http://www.classiccmp.org/pipermail/cctalk/attachments/20020818/f17772b5/at…
8:18 a.m.
New subject: OT-DIY CPU's
Of course if you have a 12 bit or 24 bit word, then
either octal or hex
are natural (3 hex digits = 4 octal digits). Again I guess which one you
use depends on the format of the instruction word.
The fun then comes with something like the ICT/ICL 1900 series* where the
24-bit word and the 7-bit opcode were "always" expressed in octal but the
instruction
F X N(M) was physically laid out as
X(3 bits)F(7 bits)M(2 bits)N(12 bits) [branches being slightly different]
which did not appear naturally in the octal expression.
* originally the FP6000 originating in Canada
Andy
9:37 a.m.
New subject: OT-DIY CPU's
Andy Holt wrote:
The fun then comes with something like the ICT/ICL
1900 series* where the
24-bit word and the 7-bit opcode were "always" expressed in octal but the
instruction
F X N(M) was physically laid out as
X(3 bits)F(7 bits)M(2 bits)N(12 bits) [branches being slightly different]
which did not appear naturally in the octal expression.
* originally the FP6000 originating in Canada
Know of any information on the web?
5:56 p.m.
New subject: OT-DIY CPU's
Andy Holt wrote:
A Google search for ICL.1900 finds quite a lot
the most interesting link is probably
http://www.personal.leeds.ac.uk/~ecldh/ccs/g34ever.html
describing a simulation project able to run George 3 - one of the most
advanced operating systems of the era. The emulator "cheats" somewhat by
emulating the executive interface rather than the raw hardware and so is
unsuitable for the other 1900 series operating systems which used a
different executive.
I have several of the hardware manuals and have a theoretical project (ie,
not really started!) to build a 1900 using an FPGA. A problem being that it
seems that none of the other 1900 series operating systems (Operators
executive, George 1,2, and 2+, Minimop, Maximop) seem to have survived.
Andy
The fun then comes with something like the
ICT/ICL 1900 series*
where the
....
* originally the FP6000 originating in Canada
Know of any information on the web? 
20 Aug
20 Aug
7:04 a.m.
New subject: OT-DIY CPU's
Hi,
"Andy Holt" <andyh(a)andyh-rayleigh.freeserve.co.uk> said:
Interesting. I wasn't directly involved with it, but we had an ICL1904 at
work (as did most local authority bodies!) running George 3.
Changed to Univac later.
Andy Holt wrote:
A Google search for ICL.1900 finds quite a lot
the most interesting link is probably
http://www.personal.leeds.ac.uk/~ecldh/ccs/g34ever.html
describing a simulation project able to run George 3 - one of the most
advanced operating systems of the era. The emulator "cheats" somewhat by
emulating the executive interface rather than the raw hardware and so is
unsuitable for the other 1900 series operating systems which used a
different executive.
The fun then comes with something like the
ICT/ICL 1900 series*
where the
....
* originally the FP6000 originating in Canada
Know of any information on the web? I have several of the hardware manuals and have a
theoretical project (ie,
not really started!) to build a 1900 using an FPGA. A problem being that it
seems that none of the other 1900 series operating systems (Operators
executive, George 1,2, and 2+, Minimop, Maximop) seem to have survived.
If I run into any of the old gang, I see if they have any tales to tell.
The only ICL stuff I have left is a ring binder.
--
Cheers,
Stan Barr stanb(a)dial.pipex.com
The future was never like this!
13 Aug
13 Aug
11:48 a.m.
A non-text attachment was scrubbed...
Name: not available
Type: text
Size: 9113 bytes
Desc: not available
Url :
http://www.classiccmp.org/pipermail/cctalk/attachments/20020813/7c8e7afe/at…
12:43 p.m.
----- Original Message -----
From: "Tony Duell" <ard(a)p850ug1.demon.co.uk>
To: <cctalk(a)classiccmp.org>
Sent: Wednesday, August 14, 2002 8:37 AM
Subject: Re: Dec TU-56 Question
I re-wrote an old 'joke' (about a drop of oil,
originally) the last time
somebody moaned that I'd charged them \pounds 50.00 to replace a 2N3904
transistor. I gave them the following itemised bill :
2N3904 transistor : \pounds 0.07
Figuring out which transistor to replace, considering that I had no
service information, would _never_ be able to find said information, and
had never seen a similar machine before : \pounds 49.93
I can relate to that, my old boss' reaction to customers who bitch about a
$50 bill for an open circuit resistor was "Ok let me show you".
Then he'd take the back off, point at the board, hold up the dead resistor
and say it's "It's 2c for the resistor and $49.98 for
knowing WHICH resistor." This usually got the message across.
The same must apply to software too. Anybody can
retype a line of code
and recompile/reassamble the program. It's figuring out which line to
change, and what to change it to, that takes the time and expertise.
Same same.
Cheers
Geoff in Oz
14 Aug
14 Aug
11:56 a.m.
A non-text attachment was scrubbed...
Name: not available
Type: text
Size: 882 bytes
Desc: not available
Url :
http://www.classiccmp.org/pipermail/cctalk/attachments/20020814/5f3172a7/at…
8113
days inactive
8125
days old
37 comments
12 participants
participants (12)
-
andyh＠andyh-rayleigh.freeserve.co.uk -
ard＠p850ug1.demon.co.uk -
bfranchuk＠jetnet.ab.ca -
charlesleecourtney＠yahoo.com -
cisin＠xenosoft.com -
cmcnabb＠4mcnabb.net -
eric＠brouhaha.com -
geoffrob＠stmarks.pp.catholic.edu.au -
jhfinepw4z＠compsys.to -
pcw＠mesanet.com -
stanb＠dial.pipex.com -
vaxzilla＠jarai.org