trouble imaging badblocks on rl02

[Jacob Ritorto via cctalk]

Has anyone modified Warren's VTServer to ignore errors (or at least keep
trying upon encountering them)?

I'm trying to image some rl02s I found and am getting flack on some tracks,
killing the whole recovery process.

200K received
wwrl(0,0,0)
err cy=14, hd=0, sc=28, rlcs=104275, rlmp=4
Copying done. Either reset the system, or hit
 to exit the standalone program.


Or is there a better way?

thx
jake

Re: 70's computers

[Tom Uban via cctalk]

On 10/25/18 12:45 PM, Chuck Guzis via cctalk wrote:
> On this subject, is there no interest in serial ALU designs?  At one
> time, if you wanted a low-cast implementation, that was the way to do
> it.  Also gives you a leg up on variable word-length designs.
>
>
> Didn't at least one of the more popular MPU designs employ a serial ALU?
>  TMS9900?
>
> --Chuck
>
Let's not forget the PDP8S.

Re: 70's computers

[Josh Dersch via cctalk]

On Thu, Oct 25, 2018 at 9:01 PM Al Kossow via cctalk 
wrote:

>
>
> On 10/25/18 12:02 PM, Josh Dersch wrote:
>
> > You might be thinking of the AMT DAP, which used arrays of 1-bit
> processors.
>
> yup.
>
> I know we have one, just can't find it in the CHM catalog
> I have some docs on bitsavers
>
>
>
Cool -- I have a pile of software that came with mine, the tapes images are
here:

http://yahozna.dyndns.org/scratch/dap/

in case anyone else has one of these.

- Josh

Re: 70's computers

[Jon Elson via cctalk]

On 10/25/2018 02:24 PM, allison via cctalk wrote:
Likely make a fortune off my stockpile of 2901s. Building 
machine from the earth up is not that hard, software to 
make them useful is a big deal.
Yes, and that's where my 32-bit 2903 project started to bog 
down.  I knew some people, OS security was a total joke, so 
I COULD have just stolen OS 360 MVT, but REALLY, who would 
do that to themselves?
I had a few more bits of logic to wire in, to make a 256-way 
branch from the OP-code field of the instruction register to 
decode instructions, and from the register fields of the 
instruction register to OR into the register address.  Then, 
I had to write the microcode.  I'd done some small test bits 
of microcode, including the multiply, and that worked.  
(IIRC, the 2903 has an extra shift register, so it can do 
the multiply step in one CPU cycle, the 2901 takes 2.)


Well, after that, I had a big decision to make.  Should the 
memory be on the system bus, like PDP-11 and VAX, or part of 
the CPU, like IBM-360 and PDP-10?  Then, I had to get memory 
wired to the bit slice system, and then build peripheral 
controllers.  I had a very rough concept scratched up, about 
30 chips to make a microcoded 16-bit machine, using fast 
EPROMS for the control store.  A SCSI interface would be 
pretty trivial, but a read-after-write mag tape control and 
an 8-channel serial multiplexer would be much more 
complicated project.  THEN, the big stuff would come, I'd 
need an OS and language compilers.  I could probably whip up 
a version of CP/M with hierarchical directories and 
time/date stamps, and maybe a simple editor, but the WHOLE 
REASON for this project was to move up to modern high-level 
languages.  And, I had badly underestimated how difficult 
that might become.  One scheme might be to start with my 
CP/M-like OS, and build a wrapper program that would allow 
me to run OS-360 compilers and linkers with whatever object 
libraries they needed, and then use them to compile 
something more to my liking like Pascal.   But, it was all 
looking like a LOT of work.


So, I managed to clone a Nat. Semi 32016 system and got it 
running, but it was amazingly slow.
I suspect that my kluged memory interface was not fully 
optimal, but even the original that I copied was pretty 
slow.  Then, I spent BIG BUCKS to buy a uVAX-II CPU board 
from a broker, and was finally in HOG HEAVEN!  It was 
certainly fast, almost the speed of the VAX-780's I used at 
work, and ALL MINE!


So, that's my story.

Jon

Re: 70's computers

[allison via cctalk]

On 10/25/2018 05:37 PM, Eric Smith via cctalk wrote:
> On Thu, Oct 25, 2018 at 11:45 AM Chuck Guzis via cctalk <
> cctalk@classiccmp.org> wrote:
>
>> Didn't at least one of the more popular MPU designs employ a serial ALU?
>>  TMS9900?
>>
> I don't think the TI TMS9900 was bit-serial internally, but the RCA CDP1802
No it the 9900 definitely is not.  The 9900 does have that odd serial
bit addressed CRU
interface.

The 1802 has been verified has a serial ALU.
> and National Semiconductor SC/MP (ISP-8A/500) and SC/MP II (ISP-8A/600)
> were.
I have no information that the SC/MP or SC/MP II more so are internally
serial.
The do have a serial register to the outside..

There are very few CPUs that had serial insides. 

Allison

Re: 70's computers

[Jon Elson via cctalk]

On 10/25/2018 01:40 PM, Paul Koning via cctalk wrote:



On Oct 25, 2018, at 1:45 PM, Chuck Guzis via cctalk  
wrote:

On this subject, is there no interest in serial ALU designs?  At one
time, if you wanted a low-cast implementation, that was the way to do
it.  Also gives you a leg up on variable word-length designs.

Didn't at least one of the more popular MPU designs employ a serial ALU?
TMS9900?

Serial ALU as a cost saver for low end makes sense in discrete transistor or 
early SSI machines, like the PDP-8/L.  It's hard to see how it would be useful 
in MPUs, given that transistors are so much cheaper there.

It was the PDP-8/S  (not 8/L) that had the serial ALU.  The 
8S was a discrete transistor machine, the 8/L used 
integrated circuits.  I think the core on the 8/S was also 
really slow, like 6-8 us cycle time, so having the CPU take 
its time made little difference.


Jon

Re: modern stuff

[Jacob Ritorto via cctalk]

Tangent:
  I have a large bin of perhaps a hundred working (last checked circa 2002)
single board computers in the warehouse (Western Pennsylvania) with i960
cpus if anyone's interested.

  They were the Switch Control Processors from FORE Systems ASX200
switches, quite fully functional little computers and all self-sufficient
on one board.  When we ported to x86, the poor i960 ones became unwanted
extremely rapidly; hence the surplus.  Never had the heart to remand them
to the skip.

  There's Serial, Ethernet, 7 segment display array, flash, RAM, clock,
etc. and a VME bus interface.  Guys used to hook them naked to a couple
wires for power source and run them in their office window to scroll
messages.  Would make for a swell massively, if lethargically, parallel
compute project.

  Would enthusiastically trade for pdp11 stuff, or donate to interesting
project even if you have nothing to offer.
thx
jake


On Thu, Oct 25, 2018 at 6:16 PM Al Kossow via cctalk 
wrote:

>
>
> On 10/25/18 11:23 AM, Jecel Assumpcao Jr. via cctalk wrote:
>
> > Didn't at least part of the team continue the project as the BiiN /
> > 960MX?
>
> Yes.
> Eric Smith can explain the whole history if he chooses to.
>
> Here is what he has on line for the 432
> http://www.brouhaha.com/~eric/retrocomputing/intel/iapx432/
>
>
>
>

Re: Scan of Micro Peripherals Inc MPI 91/92 Product Manual Avail?

[Al Kossow via cctalk]

On 10/25/18 4:16 PM, Al Kossow via cctalk wrote:
> 
> 
> On 10/25/18 4:00 PM, Eric Smith via cctalk wrote:
> 
>> If you need a sheet-fed duplex scanner for B-size, expect to spend a pretty
>> good chunk of change even for a used one.
>>
> 
> I've been through several million pages with my Panasonic KV-3065CW
> duplex tabloid color scanner
> 
> They can be found used for <$500 now
> 
> https://www.ebay.com/itm/292774459578
> 

They also can scan LONG drawings (up to 100")

Re: Scan of Micro Peripherals Inc MPI 91/92 Product Manual Avail?

[Al Kossow via cctalk]

On 10/25/18 4:00 PM, Eric Smith via cctalk wrote:

> If you need a sheet-fed duplex scanner for B-size, expect to spend a pretty
> good chunk of change even for a used one.
> 

I've been through several million pages with my Panasonic KV-3065CW
duplex tabloid color scanner

They can be found used for <$500 now

https://www.ebay.com/itm/292774459578

Re: Scan of Micro Peripherals Inc MPI 91/92 Product Manual Avail?

[Eric Smith via cctalk]

On Thu, Oct 25, 2018 at 1:28 PM Bill Degnan via cctalk <
cctalk@classiccmp.org> wrote:

> So that brings me to the question - Should I buy a nice scanner that
> handles two sided and schematic prints?...I have so many things more I
> could scan if I had something cost effective.  That's the last time I do
> the Kinkos thing.   I prefer to do this kind of work on my own.
>

I occasionally have to scan B-size (11x17 inch) drawings, and the cheapest
scanner I know of that can do that is the HP OfficeJet Pro 7740 all-in-one,
which is also a B-size inkjet printer. It costs about $250 retail, but can
sometimes be found for $200.

The scanner only does a single side, so you have to flip the page over
manuall. There is a sheet feeder for A-size and similar only; for B-size
you have to use it as a flatbed.

If you need a sheet-fed duplex scanner for B-size, expect to spend a pretty
good chunk of change even for a used one.

Re: 70's computers

[Eric Smith via cctalk]

On Thu, Oct 25, 2018 at 11:45 AM Chuck Guzis via cctalk <
cctalk@classiccmp.org> wrote:

> Didn't at least one of the more popular MPU designs employ a serial ALU?
>  TMS9900?
>

I don't think the TI TMS9900 was bit-serial internally, but the RCA CDP1802
and National Semiconductor SC/MP (ISP-8A/500) and SC/MP II (ISP-8A/600)
were.

Re: modern stuff

[Eric Smith via cctalk]

On Thu, Oct 25, 2018 at 12:48 PM Chuck Guzis via cctalk <
cctalk@classiccmp.org> wrote:

> (the 432 is not a single chip
> microcomputer--the basic family, as I recall was no less than three
> (43201, 43202 and 43203) QIP chips.


The General Data Processor (GDP) was split between two chips, the 43201 and
43202. It is the real "processor" of the 432 system.

The Interface Processor (IP), is a single chip, the 43203. It is used with
a conventional microprocessor, typically an 8086, known as the Attached
Processor (AP),

An iAPX 432 system could potentially contain up to 255 processors in total,
with an arbitrary mix of GDPs and IPs. You need at least one GDP. A system
to run the iMAX 432 operating system generally needed two IPs.


>   The cost for the set given to us in
> the range of 4 figures.
>

The chips weren't actually that expensive; they were roughly $150 each for
the 7 MHz speed grade. The board- and system-level products were quite
expensive.

The i860 RISC CPU at one time was even being
>
endorsed by BillG as a possible personal computer basis.  I think that
> the follow-on, the i960 was somewhat successful.
>

Note that the i960 was totally unrelated to the i860. The i960 is actually
a follow-on to the iAPX 432.

The 432 led to the BiiN joint venture with Siemens. The BiiN processor was
a RISC but with 33-bit memory words containing a tag bit to distinguish
data from capabilities, to allow the 432-style object architecture with a
RISC base.

BiiN was unsuccessful, so Intel disabled the tag bit of the processor and
called it the i960. A later version of the i960 had the tag bit enabled.

Re: 70's computers

[Chuck Guzis via cctalk]

On 10/25/18 12:15 PM, allison via cctalk wrote:

> The 1802 is claimed to be serial.

Ah, that was it.  Ultra-low power (for the time) CMOS.  Simple
instruction set.

Thanks,
Chuck

Re: Scan of Micro Peripherals Inc MPI 91/92 Product Manual Avail?

[Bill Degnan via cctalk]

Hi - I finished the scan of the MPI 91/92.  I did it at Kinkos and it cost
me $54, and wow that's expensive.  I should have asked before I dropped off
the manual.  I kind of assumed it'd be more like $20.  I don't have an easy
way to scan a plastic spiral-bound two sided document with pull out
schematics unless I do each page by hand.

If anyone wants the file, it's real nice and suitable for archive.org, and
includes schematics
https://www.vintagecomputer.net/MPI/

So that brings me to the question - Should I buy a nice scanner that
handles two sided and schematic prints?...I have so many things more I
could scan if I had something cost effective.  That's the last time I do
the Kinkos thing.   I prefer to do this kind of work on my own.

Also of note I just finished the RCA COSMAC Microkit manual MPM 103,
obtained from the Hagley Museum archives in Wilminton, Delaware.  They have
a treasure trove there.  It's impossible to assemble the Microkit without
the manual, each card has a specific slot in the backplane.  This is a
computer made with an early version of the two-chip 1801 CPU card, before
it was called "1801".  More info is on my web site.  So far I have the
current loop operating but the terminal card appears to be on the fritz or
altered for some other purpose that originally designed.  I cannot yet
interact with a teletype.  The COSMAC Microkit is a complete microcomputer
that pre-dates by a month or two the MITS Altair.  A worthy project.

Next - a nice ROHM 1601 sales brochure.

I try to scan only what appears to not already be available on the
better-known archiving sites.

Bill
vintagecomputer.net/contact.cfm



On Fri, Oct 19, 2018 at 4:32 PM Bill Degnan  wrote:

> just an update, I have not forgotten this task, I just need to find time
> to get to a two-sided printer.  I really need to get one for my self with
> big copy bay to handle schematics.  That would really accelerate my archive
> work
> b
>
> On Sat, Oct 6, 2018 at 1:55 AM Chuck Guzis via cctalk <
> cctalk@classiccmp.org> wrote:
>
>> One last tidbit on the Micropolis floppy drives--the early drives (1014,
>> etc.) used a body/chassis made of steel plate.   The later drives (1115)
>> used cast body parts.
>>
>> It's also worth observing that the leadscrew positioner is probably the
>> best, as it's the dominant technology in 135 tpi 3.5" drives.
>>
>> --Chuck
>>
>

Re: 70's computers

[Chuck Guzis via cctalk]

On 10/25/18 12:04 PM, Al Kossow via cctalk wrote:
> 
> 
> On 10/25/18 12:02 PM, Josh Dersch wrote:
> 
>> You might be thinking of the AMT DAP, which used arrays of 1-bit processors.
> 
> yup.
> 
> I know we have one, just can't find it in the CHM catalog
> I have some docs on bitsavers

Danny Hillis' CM-1 also used lots of 1-bit processors.

--Chuck

Re: 70's computers

[allison via cctalk]

On 10/25/2018 01:28 PM, ben via cctalk wrote:
> On 10/24/2018 9:00 PM, Jon Elson wrote:
>> On 10/24/2018 01:11 PM, ben via cctalk wrote:
>>> On 10/24/2018 10:31 AM, Marc Howard via cctalk wrote:
 You know that since you mentioned possibly using CMOS 22V10's why
 not just
 build a board around AMD 29XX bit slice parts.  They actually predate
 22V10's by quite a bit and you can pretty much implement what every
 you
 want to without rewiring.

 Marc
>>>
>>> * LOW POWER and REPROGRAMABLE * reglar 22V10's are 100 ma per chip,
>>> and I can buy them online. I have 5 2901's but I can only find them
>>> on ebay now. If I design a register based machine I have them, other
>>> wise
>>> TTL is better for odd sized word lengths.
>>> Ben.
>>>
>>>
>>>
>> Well, I built a 2903 + 2910 32-bit microcoded machine in 1982 or so. 
>> See
>> http://pico-systems.com/stories/1982.html
>> for gory details.  But, today, it would make WAY more sense to do it
>> with FPGAs.  Want to try an experiment?  Don't get out the wire-wrap
>> gun or soldering iron, make a copy of the FPGA files and edit away.
>> If it doesn't work, you don't have to undo the wiring changes! Also,
>> the FPGA version might be as much as 10 times faster.
>
> I just orderd 4 2901's off ebay, So I do plan to build something up to
> 32 bits.

Likely make a fortune off my stockpile of 2901s. 

Building machine from the earth up is not that hard, software to make
them useful is a big deal.

> I have a DE1 FPGA setup for proto typing, but free pcb board layout
> programs all seem to suck for me. There is nothing for doing things
> like switches or card edge foot prints, but a gizzion and one surface
> mount that common people never use.
>
The problem is you need to hunt down the libraries or use a tool that
has libraries.  Kicad and Eagle are
work for me.

Once you have libraries that have those doing it become easy.  IF not
draw them!
 
Allison
>
>
>> Jon
>>
>

Re: 70's computers

[allison via cctalk]

On 10/25/2018 01:45 PM, Chuck Guzis via cctalk wrote:
> On this subject, is there no interest in serial ALU designs?  At one
> time, if you wanted a low-cast implementation, that was the way to do
> it.  Also gives you a leg up on variable word-length designs.
>
>
> Didn't at least one of the more popular MPU designs employ a serial ALU?
>  TMS9900?
>
> --Chuck
No, 9900 was byte wide.

The 1802 is claimed to be serial.

Allison

Re: 70's computers

[Al Kossow via cctalk]

On 10/25/18 12:02 PM, Josh Dersch wrote:

> You might be thinking of the AMT DAP, which used arrays of 1-bit processors.

yup.

I know we have one, just can't find it in the CHM catalog
I have some docs on bitsavers

Re: 70's computers

[Al Kossow via cctalk]

On 10/25/18 11:48 AM, Al Kossow via cctalk wrote:

> Arrays of single-bit processors have been tried.
> CHM has one, I'm blanking on the company name.
> We had one in Apple ATG.
> 

Active Memory Technology DAP-500

Re: 70's computers

[Josh Dersch via cctalk]

> On Oct 25, 2018, at 11:48 AM, Al Kossow via cctalk  
> wrote:
> 
> 
> 
>> On 10/25/18 11:40 AM, Paul Koning via cctalk wrote:
>> 
>> 
>>> On Oct 25, 2018, at 1:45 PM, Chuck Guzis via cctalk  
>>> wrote:
>>> 
>>> On this subject, is there no interest in serial ALU designs?  At one
>>> time, if you wanted a low-cast implementation, that was the way to do
>>> it.  Also gives you a leg up on variable word-length designs.
>>> 
>>> Didn't at least one of the more popular MPU designs employ a serial ALU?
>>> TMS9900?
>> 
>> Serial ALU as a cost saver for low end makes sense in discrete transistor or 
>> early SSI machines, like the PDP-8/L.
> 
> PDP-8/S
> Saul Dinman's machine, who founded GRI
> 
> https://books.google.com/books?id=1jTUBwAAQBAJ=PA52=PA52=gri+computer+saul=bl=Qqd_woK8KO=Ii8W_8Stxwuo2kHY4uJU6DJXYzc=en=X=2ahUKEwiF0NeLoKLeAhWTCjQIHbIFB84Q6AEwAHoECAYQAQ#v=onepage=gri%20computer%20saul=false
> 
> 
> Arrays of single-bit processors have been tried.
> CHM has one, I'm blanking on the company name.
> We had one in Apple ATG.
> 

You might be thinking of the AMT DAP, which used arrays of 1-bit processors.  
(32x32 or 64x64).  10mhz each.  I have a 610, it is the most interesting SCSI 
peripheral I own...

- Josh

Re: 70's computers

[Chuck Guzis via cctalk]

On 10/25/18 11:53 AM, Al Kossow via cctalk wrote:

> There is the moto MC14500
> 
> http://bitsavers.org/components/motorola/14500/MC14500B_Industrial_Control_Unit_Handbook_1977.pdf

No, not the ICU--it'd be a real stretch calling it a computer.

It'll come to me at some point.

--Chuck

Re: 70's computers

[Al Kossow via cctalk]

On 10/25/18 11:49 AM, Chuck Guzis via cctalk wrote:

> Dunno, the mind is foggy on this detail, since I never played with the
> beast.  But it seems to me that there was at least one "too slow" MPU
> out there in production at some point.

There is the moto MC14500

http://bitsavers.org/components/motorola/14500/MC14500B_Industrial_Control_Unit_Handbook_1977.pdf

Re: 70's computers

[Chuck Guzis via cctalk]

On 10/25/18 11:33 AM, Al Kossow via cctalk wrote:
> 
> 
> On 10/25/18 10:45 AM, Chuck Guzis via cctalk wrote:
> 
>> Didn't at least one of the more popular MPU designs employ a serial ALU?
>>  TMS9900?
> 
> You've mentioned this a couple of times.
> 
> Are you confusing this with the serial CRU I/O scheme TI computers used?
> I double-checked and the 960,980 and 990 minicomputers are all 16 bit 
> parallel machines.
> 
> The 9980/1 and 9995 had an 8 bit memory bus but internally are 16.
> 
> I double-checked, and the TMS9900 has a 16 bit ALU (page 6 in
> TMS_9900_Microprocessor_Data_Manual_May76.pdf on bitsavers)

Dunno, the mind is foggy on this detail, since I never played with the
beast.  But it seems to me that there was at least one "too slow" MPU
out there in production at some point.

--Chuck

Re: modern stuff

[Chuck Guzis via cctalk]

On 10/25/18 11:06 AM, Jim Manley via cctalk wrote:

> Obviously, he returned to academia before the project collapsed in a heap,
> and he might have had to scramble and compete with other departing CS PhDs
> (who would also have hung around too long).  Many would probably be looking
> at another job where microprocessor microcode, assembler, linker, compiler,
> and system-level library development experience would have been highly
> desirable, and perhaps where the EEs were more reasonable.  Plus, he didn't
> have to put "Served on what became the sunken shipwreck iAPX 432" on his
> resume/CV.  That's because it wasn't yet at the Sixth Phase in the Six
> Phases of a Project, "Punishment of the Innocent, and Rewards for the
> Non-Participants".

Sigh, I remember the 432 being talked up by "Fast Eddie" our Intel
inside sales guy.   "Micro mainframe" will be the best thing since the
bread knife.

We began to get an inkling of trouble when we requested ballpark
estimates of the cost of the various chips (the 432 is not a single chip
microcomputer--the basic family, as I recall was no less than three
(43201, 43202 and 43203) QIP chips.  The cost for the set given to us in
the range of 4 figures.

As time went on, Eddie talked less and less about this and then went
completely silent--his response was basically "you don't want to know".
I don't recall if this was before or after performance benchmark numbers
started to appear.

While this was a failure on a spectacular level, it was by no means the
only misstep by Intel.   The i860 RISC CPU at one time was even being
endorsed by BillG as a possible personal computer basis.  I think that
the follow-on, the i960 was somewhat successful.

One thing you need in this business is a good back-of-the-neck sense.
Sometime in the late 1970s, I was invited up to Beaverton by Tek to
interview for the position of project manager for their new color
graphics display terminal.  I don't recall many technical details--it
was a one-day visit.  Tek was enthusiastic about getting me on board and
had even scheduled the movers.  About 4 days before they were set to
arrive, I called off the offer--I'd had a really terrible dream about
the project and couldn't shake the cold sweats.

It turned out that the project came in late and way above estimates for
Tek, with layoffs resulting.  A bullet dodged by a dream.

--Chuck

Re: 70's computers

[Al Kossow via cctalk]

On 10/25/18 11:40 AM, Paul Koning via cctalk wrote:
> 
> 
>> On Oct 25, 2018, at 1:45 PM, Chuck Guzis via cctalk  
>> wrote:
>>
>> On this subject, is there no interest in serial ALU designs?  At one
>> time, if you wanted a low-cast implementation, that was the way to do
>> it.  Also gives you a leg up on variable word-length designs.
>>
>> Didn't at least one of the more popular MPU designs employ a serial ALU?
>> TMS9900?
> 
> Serial ALU as a cost saver for low end makes sense in discrete transistor or 
> early SSI machines, like the PDP-8/L.

PDP-8/S
Saul Dinman's machine, who founded GRI

https://books.google.com/books?id=1jTUBwAAQBAJ=PA52=PA52=gri+computer+saul=bl=Qqd_woK8KO=Ii8W_8Stxwuo2kHY4uJU6DJXYzc=en=X=2ahUKEwiF0NeLoKLeAhWTCjQIHbIFB84Q6AEwAHoECAYQAQ#v=onepage=gri%20computer%20saul=false


Arrays of single-bit processors have been tried.
CHM has one, I'm blanking on the company name.
We had one in Apple ATG.

Re: 70's computers

[Paul Koning via cctalk]

> On Oct 25, 2018, at 1:45 PM, Chuck Guzis via cctalk  
> wrote:
> 
> On this subject, is there no interest in serial ALU designs?  At one
> time, if you wanted a low-cast implementation, that was the way to do
> it.  Also gives you a leg up on variable word-length designs.
> 
> Didn't at least one of the more popular MPU designs employ a serial ALU?
> TMS9900?

Serial ALU as a cost saver for low end makes sense in discrete transistor or 
early SSI machines, like the PDP-8/L.  It's hard to see how it would be useful 
in MPUs, given that transistors are so much cheaper there.

The other place I can think of serial arithmetic is in the Orthogonal computer 
architecture, sold by Sanders Associates from a 1960s invention by Bill 
Shooman.  That's an interesting design that does vector arithmetic row-parallel 
but bit-serial.  Goodyear STARAN used some of those ideas, I believe, though I 
know very little of the details.

paul

Re: modern stuff

[Al Kossow via cctalk]

On 10/25/18 11:23 AM, Jecel Assumpcao Jr. via cctalk wrote:

> Didn't at least part of the team continue the project as the BiiN /
> 960MX?

Yes.
Eric Smith can explain the whole history if he chooses to.

Here is what he has on line for the 432
http://www.brouhaha.com/~eric/retrocomputing/intel/iapx432/

Re: 70's computers

[Al Kossow via cctalk]

On 10/25/18 10:45 AM, Chuck Guzis via cctalk wrote:

> Didn't at least one of the more popular MPU designs employ a serial ALU?
>  TMS9900?

You've mentioned this a couple of times.

Are you confusing this with the serial CRU I/O scheme TI computers used?
I double-checked and the 960,980 and 990 minicomputers are all 16 bit parallel 
machines.

The 9980/1 and 9995 had an 8 bit memory bus but internally are 16.

I double-checked, and the TMS9900 has a 16 bit ALU (page 6 in
TMS_9900_Microprocessor_Data_Manual_May76.pdf on bitsavers)

Re: modern stuff

[Jecel Assumpcao Jr. via cctalk]

Jim Manley wrote about a professor's experience in the iAPX432 team.

Didn't at least part of the team continue the project as the BiiN /
960MX?

-- Jecel

Re: modern stuff

[Jim Manley via cctalk]

One of my postgraduate school CS professors worked on the iAPX 432 and his
tidbit about the history of its development was that, whenever the EEs were
confronted with a hardware-level problem by the CSs, the EEs would
universally respond with, "Oh, well, that can be fixed by you software guys
with a SMOP (small matter of programming).", in the microcode, and Intel's
reference assembler, linker, and compilers.

Obviously, he returned to academia before the project collapsed in a heap,
and he might have had to scramble and compete with other departing CS PhDs
(who would also have hung around too long).  Many would probably be looking
at another job where microprocessor microcode, assembler, linker, compiler,
and system-level library development experience would have been highly
desirable, and perhaps where the EEs were more reasonable.  Plus, he didn't
have to put "Served on what became the sunken shipwreck iAPX 432" on his
resume/CV.  That's because it wasn't yet at the Sixth Phase in the Six
Phases of a Project, "Punishment of the Innocent, and Rewards for the
Non-Participants".


On Wed, Oct 24, 2018 at 6:35 PM Eric Smith via cctalk 
wrote:

> On Wed, Oct 24, 2018, 17:45 ben via cctalk  wrote:
>
> > On 10/24/2018 3:58 PM, Eric Smith wrote:
> > > On Wed, Oct 24, 2018 at 2:18 PM ben via cctalk  > > > wrote:
> > >
> > > Well I can still run DOS BOX and get my nice 8086 instruction set.
> > >
> > >
> > > I've heard many different adjectives used with regard to the 8086
> > > instruction set, but this is the first time I've heard it described as
> > > "nice".
> > >
> > > Admittedly there are worse ones.
> > >
> >
> > What about Intel's forgotten object oriented kitchen sink processor.
> > IAPX-432 better or worse?
> >
>
> I wouldn't call it a "kitchen sink processor"; some of it's problems are
> actually with things that are missing. However, it's a VCISC, and the
> instruction set isn't really comparable to anything else.
>
> If I had to design a computer for either general-purpose or embedded use,
> I'd definitely choose 8086 over iAPX 432, but that isn't because I consider
> the 8086 instruction set to be particularly good.
>

Re: 70's computers

[Chuck Guzis via cctalk]

On this subject, is there no interest in serial ALU designs?  At one
time, if you wanted a low-cast implementation, that was the way to do
it.  Also gives you a leg up on variable word-length designs.


Didn't at least one of the more popular MPU designs employ a serial ALU?
 TMS9900?

--Chuck

Re: 70's computers

[ben via cctalk]

On 10/24/2018 9:00 PM, Jon Elson wrote:

On 10/24/2018 01:11 PM, ben via cctalk wrote:

On 10/24/2018 10:31 AM, Marc Howard via cctalk wrote:
You know that since you mentioned possibly using CMOS 22V10's why not 
just

build a board around AMD 29XX bit slice parts.  They actually predate
22V10's by quite a bit and you can pretty much implement what every you
want to without rewiring.

Marc


* LOW POWER and REPROGRAMABLE * reglar 22V10's are 100 ma per chip, 
and I can buy them online. I have 5 2901's but I can only find them on 
ebay now. If I design a register based machine I have them, other wise

TTL is better for odd sized word lengths.
Ben.




Well, I built a 2903 + 2910 32-bit microcoded machine in 1982 or so.  See
http://pico-systems.com/stories/1982.html
for gory details.  But, today, it would make WAY more sense to do it 
with FPGAs.  Want to try an experiment?  Don't get out the wire-wrap gun 
or soldering iron, make a copy of the FPGA files and edit away. If it 
doesn't work, you don't have to undo the wiring changes! Also, the FPGA 
version might be as much as 10 times faster.


I just orderd 4 2901's off ebay, So I do plan to build something up to 
32 bits.
I have a DE1 FPGA setup for proto typing, but free pcb board layout 
programs all seem to suck for me. There is nothing for doing things like 
switches or card edge foot prints, but a gizzion and one surface mount 
that common people never use.





Jon

Re: does a reverse-engineering EDA tool exist?

[Guy Sotomayor Jr via cctalk]

> On Oct 25, 2018, at 10:05 AM, Al Kossow via cctalk  
> wrote:
> 
> 
> 
> On 10/25/18 9:48 AM, Al Kossow via cctalk wrote:
>> 
>> 
>> On 10/25/18 9:18 AM, Guy Sotomayor Jr via cctalk wrote:
>>> Now that I think about it, a flying probe may be easier for us hobbyists to 
>>> construct.  The trick will be getting sufficient x/y resolution and not 
>>> having the two probes interfere when the two probes are close to each other.
>>> 
>> 
>> I hadn't thought about that.
>> Two probes, one on the front and one on the back of the board...
>> No interference.
> 
> you could use two of these
> 
> https://shop.evilmadscientist.com/productsmenu/846
> 
> 
Very cool!

TTFN - Guy

Re: does a reverse-engineering EDA tool exist?

[Al Kossow via cctalk]

On 10/25/18 9:48 AM, Al Kossow via cctalk wrote:
> 
> 
> On 10/25/18 9:18 AM, Guy Sotomayor Jr via cctalk wrote:
>> Now that I think about it, a flying probe may be easier for us hobbyists to 
>> construct.  The trick will be getting sufficient x/y resolution and not 
>> having the two probes interfere when the two probes are close to each other.
>>
> 
> I hadn't thought about that.
> Two probes, one on the front and one on the back of the board...
> No interference.

you could use two of these

https://shop.evilmadscientist.com/productsmenu/846

Re: does a reverse-engineering EDA tool exist?

[Al Kossow via cctalk]

On 10/25/18 9:18 AM, Guy Sotomayor Jr via cctalk wrote:
> Now that I think about it, a flying probe may be easier for us hobbyists to 
> construct.  The trick will be getting sufficient x/y resolution and not 
> having the two probes interfere when the two probes are close to each other.
>

I hadn't thought about that.
Two probes, one on the front and one on the back of the board...
No interference.

Re: does a reverse-engineering EDA tool exist?

[Al Kossow via cctalk]

On 10/25/18 9:18 AM, Guy Sotomayor Jr via cctalk wrote:

> I’m wondering if a “bed of nails” could be built that would allow for 
> automated scanning of the traces to at least get the netlist.

yup

that's the latest iteration of what I'm working on

16 bit open drain drivers, low voltage comparators, to a shift register output 
configured
as two long scan chains. You turn one of the open drain drivers on, then sense 
if any of
the pins are low through pogo pins

I had started with DIP clips, but they are too expensive, and they can't be 
used on the
IBM boards because the DIPS are only .1" apart.

Re: does a reverse-engineering EDA tool exist?

[Guy Sotomayor Jr via cctalk]

> On Oct 25, 2018, at 9:02 AM, Jon Elson via cctalk  
> wrote:
> 
> On 10/25/2018 12:44 AM, Chuck Guzis via cctalk wrote:
>> On 10/24/18 8:06 PM, Jon Elson via cctalk wrote:
>> 
>>> Hmmm, you COULD actually use a schematic tool to do this!  Maybe create
>>> the components to look like DIPs.  I know I could do this in Protel 99
>>> without a great deal of trouble.  Then, just draw in all the wires.
>>> I suspect a few other good schematic entry tools could also do this.
>> I know that I've asked about this on one of the EDA boards and got
>> nowhere.  It seems that it would be possible to construct a schematic
>> from a netlist, but I've never seen such a tool.
>> 
>> I wonder if such a beast exists.
>> 
>> 
> Well, not totally automatic, but many EDA systems have "back annotation", 
> where changes to the PCB are taken back to the schematic.  This is generally 
> used to allow easy reassignment of the identical sections in multi-gate 
> packages, but at least some of them can do MUCH more.  I know Protel 99 
> essentially turns the whole board into a spreadsheet, where everything is 
> available for reassignment.  I suspect that if you laid out all the chips and 
> then provided the interconnect info, it would create a VERY messy schematic, 
> which you could then reorganize by hand.  You could also make a PCB design, 
> draw in the wiring, and it would then be able to make a netlist and take that 
> back to the schematic.
> 

I’m wondering if a “bed of nails” could be built that would allow for automated 
scanning of the traces to at least get the netlist.  I do know that PCB fab 
houses use either a “bed of nails” or a flying probe to validate the 
construction of the boards.  Now that I think about it, a flying probe may be 
easier for us hobbyists to construct.  The trick will be getting sufficient x/y 
resolution and not having the two probes interfere when the two probes are 
close to each other.

TTFN - Guy

Re: does a reverse-engineering EDA tool exist?

[Jon Elson via cctalk]

On 10/25/2018 12:44 AM, Chuck Guzis via cctalk wrote:

On 10/24/18 8:06 PM, Jon Elson via cctalk wrote:


Hmmm, you COULD actually use a schematic tool to do this!  Maybe create
the components to look like DIPs.  I know I could do this in Protel 99
without a great deal of trouble.  Then, just draw in all the wires.
I suspect a few other good schematic entry tools could also do this.

I know that I've asked about this on one of the EDA boards and got
nowhere.  It seems that it would be possible to construct a schematic
from a netlist, but I've never seen such a tool.

I wonder if such a beast exists.


Well, not totally automatic, but many EDA systems have "back 
annotation", where changes to the PCB are taken back to the 
schematic.  This is generally used to allow easy 
reassignment of the identical sections in multi-gate 
packages, but at least some of them can do MUCH more.  I 
know Protel 99 essentially turns the whole board into a 
spreadsheet, where everything is available for 
reassignment.  I suspect that if you laid out all the chips 
and then provided the interconnect info, it would create a 
VERY messy schematic, which you could then reorganize by 
hand.  You could also make a PCB design, draw in the wiring, 
and it would then be able to make a netlist and take that 
back to the schematic.


Jon

Re: does a reverse-engineering EDA tool exist?

[Al Kossow via cctalk]

On 10/24/18 11:51 PM, Guy Dunphy via cctalk wrote:

>  - ICs containing multiple functional blocks (eg 6 x inverters.) These may be 
> used all over
>the place in a schematic. You don't want to be forced into drawing them 
> together at any
>stage of schematic derivation.

Actually you do, when creating nets from random logic and you don't want to 
miss the use of any
small logic in a package. I need to look at the spreadsheet methodology used on 
the Amiga board
trace.

This is the tedious part. Tracing buffers, muxes, decoders is fairly 
straightforward, it is figuring
out the glue logic that is tedious. It is really easy to lose your place doing 
it. You end up probing
an output and then sweeping nearby ICs hoping to find something connected.

It's much easier on a bus, where you know the source and there is a high 
probability it will connect
to a 20 pin buffer or latch somewhere. There is also a pretty high probability 
these devices will
either be near a microprocessor, or a board connector.

Re: VAX Lisp, Macsyma, Maxima

[Zane Healy via cctalk]

If going for something non-VAX, Lisp is available on Multics.

I’m feeling a bit frustrated at the moment, I’ve run into an interesting issue 
with SecureCRT on iOS, and emacs on Multics.  The key for ‘ and “ works fine 
from the command line, but not from emacs.  I’ve verified this with both the on 
device “keyboard”, and a real Apple “Magic” keyboard.

Zane
 

Sent from my iPad

> On Oct 24, 2018, at 10:21 PM, Lars Brinkhoff via cctalk 
>  wrote:
> 
> How about NIL?  There are some bits and pieces from ITS backups, but I
> don't know if there's enough to get it started, much less run a real
> application like Macsyma.
> 
> Off on a tangent, I see T supports VAX and there was a T revival project
> some time ago.

Re: VAX Lisp, Macsyma, Maxima

[Lars Brinkhoff via cctalk]

How about NIL?  There are some bits and pieces from ITS backups, but I
don't know if there's enough to get it started, much less run a real
application like Macsyma.

Off on a tangent, I see T supports VAX and there was a T revival project
some time ago.

Re: does a reverse-engineering EDA tool exist?

[Christian Corti via cctalk]

On Thu, 25 Oct 2018, Guy Dunphy wrote:
Keep the objective in mind. What you want to end up with is a schematic, 
that is laid out in a way that aids comprehension of how the circuit 
works. Typically this means overall left to right functional or power 
flow, with separate functional blocks visually separate, visual emphasis 
where appropriate, and so on. Something like the original designers 
drew, if they were any good.



When you have only a PCB and want to reverse engineer the schematic, the 
tasks are:

[...]

This is actually the way how I reverse-engineered the MINCAL 523. Identify 
the address and data busses, registers, latches, functional sections (e.g. 
ALU, interrupt related, I/O, ...) and put that all together. And yes, it 
involves a lot of paper and pencil work, and that is faster and much more 
intuitive than doing it with the computer.

To create the schematics I use gschem from the gEDA suite.

Currently, I have started to reverse-engineer the Digico computer. I have 
only looked at the CPU board so far, but that leads to a dead-end as I am 
not able to unambiguously identify the address and data busses. So I have 
to continue with the front panel, start with the display/keypad where you 
can select the individual registers for entry/display and go back to the 
front panel connector back to the CPU board. There, I hope to find the 
instruction register and continue with the instruction decoder section.


Christian

Re: does a reverse-engineering EDA tool exist?

[Guy Dunphy via cctalk]

At 10:06 PM 24/10/2018 -0500, you wrote:
>On 10/24/2018 04:25 PM, Al Kossow via cctalk wrote:
>> To draw out the schematics for the Displaywriter I have a bunch of boards to 
>> trace out,
>> and I don't want to do the usual "scribble on yellow pad"
>> to do it. Has someone written a graphical tool for doing this?
>>
>> What I would like to find is a tool that puts up a bunch of footprints with 
>> internal IC functions
>> shown, then a way to rapidly enter the buzzed out interconnections, 
>> generating a netlist.
>>
>> This is exactly backwards workflow from normal schematic entry and pcb 
>> layout.
>>
>> I suspect I'm just going to have to bite the bullet and write it..

>Hmmm, you COULD actually use a schematic tool to do this!  
>Maybe create the components to look like DIPs.  I know I 
>could do this in Protel 99 without a great deal of trouble.  
>Then, just draw in all the wires.
>I suspect a few other good schematic entry tools could also 
>do this.
>
>Jon



The idea of creating a lot of 'IC puppet' graphics showing internal functions 
connected to
footprint pins to help in reverse engineering PCBs, may sound nice at first but 
probably
won't be worth the effort in practice.

It falls down in several cases: 

 - ICs containing multiple functional blocks (eg 6 x inverters.) These may be 
used all over
   the place in a schematic. You don't want to be forced into drawing them 
together at any
   stage of schematic derivation.

 - Complex IC functions, in which physical pin arragements bear no resemblance 
to a sane
   functional symbol. Again, you don't want to be drawing schematics forced 
into physical
   pin arrangements. Pretty much every IC from simple counters and latches, on 
up are like this.

 - Even simple elements like op-amps - you want to be able to draw the + and - 
inputs
   whichever way up is appropriate for good schematic practice for the circuit 
form.

 - Power pins should appear on the schematic as sensible for the specific case. 
Usually
   not on actual circuit symbols.


Keep the objective in mind. What you want to end up with is a schematic, that 
is laid out
in a way that aids comprehension of how the circuit works. Typically this means 
overall
left to right functional or power flow, with separate functional blocks 
visually separate,
visual emphasis where appropriate, and so on. Something like the original 
designers drew,
if they were any good.


When you have only a PCB and want to reverse engineer the schematic, the tasks 
are:

 1. Find data sheets for all the semiconductors/complex parts, so you have 
diagrams of pin
functions. Extract just the pin diagrams to one convenient location, for 
easy reference
while tracing tracks. Paper, or 2nd screen while using primary screen for 
PCB overlays.

 2. Trace PCB copper connectivity, drawing schematic fragments as you go.
Every component drawn in the fragents must have a designator. Use the ones 
from the
PCB if there are any, or make them up if not. 
During this process it can be helpful to know the functions, but usually 
not essential.
At this stage you're aiming to achieve something like a 'netlist with 
circuit fragments'
that doesn't have to make sense on more than a very low level. 
The number one priority is to do this without errors. The only way to do 
that is to have
a visual copy of the PCB on which you can mark node paths and components as 
you identify
them (to 100% certainty) without fail.

 3. Once you have a bunch of sheets of drawn circuit fragments, then integrate 
them into a
sensible circuit diagram. This can be a multi-stage process, and I don't 
think can be
automated. It requires comprehension of how the circuit functions, since 
that's what the
schematic should be trying to convey.
I like it when I achieve a schematic in which the component designators 
(from the original
PCB) run in an orderly fashion across the derived schematic, since that's 
how the designer
will have assigned them on their schematic.

For stage 2 I use photoshop, with overlaid layers for the front and back of the 
PCB, and more
layers for traced copper tracks, component designators (where there are none on 
the PCB and you
have to make them up), notes, 'component done' dots, color codes for power 
rails, etc.

Start with a hi-res photo of the board front, taken from some distance away to 
reduce component
parallax and barrel distortion.
In PS, add some guide lines for the board edges and use 'distort' to make the 
PCB image rectangular.
Overlay a layer with the board rear photo. Flip it, make semi transparent, 
align and distort it
to exactly align with the board front side image. If your photos were OK you 
should be able to
get all pads right across the PCB to line up very well.
You can adjust the colors of the PCB front and back layers to get a red/blue 
effect when viewing
them both as overlaid transparencies.

Btw older versions of photoshop tend to be more 

Re: does a reverse-engineering EDA tool exist?

[r.stricklin via cctalk]

On Oct 24, 2018, at 2:25 PM, Al Kossow via cctech wrote:

> What I would like to find is a tool that puts up a bunch of footprints with 
> internal IC functions
> shown, then a way to rapidly enter the buzzed out interconnections, 
> generating a netlist.
> 
> This is exactly backwards workflow from normal schematic entry and pcb layout.

FWIW I am also quite interested in such a tool.

ok
bear.

-- 
until further notice