PDP-11: BC11-A cable dress between cabinets

[Fritz Mueller]

Hey folks,

I've gotten to the part of a PDP-11/45 restore I’ve been working on where I 
need to run a Unibus cable between the CPU box in one rack and an RK11-C 
controller at the top of the next rack over. I'm a bit puzzled about how best 
to run the bus cable to keep it out of harm's way, e.g. getting it accidentally 
pinched or crimped while sliding the CPU cabinet in and out for service.

I can see there's a nice cable exit at the back of the sliding CPU cabinet, but 
from there...??  Anybody have a picture or remember how this was usually done 
around the slide rails etc. to avoid trouble?

The RK05 manuals do have recommended dress for drive cables between drives and 
the controller, but I haven't seen any recommendations for the cabling Unibus 
between cabinets anywhere yet.

cheers,
--FritzM.

Re: IBM 7074 and then some: "Systems we love" conference

[Chuck Guzis]

On 01/24/2017 10:01 PM, Jon Elson wrote:

> And, the 7074 was a serious computer, given the vintage.  Either 4 or
> 6 us core cycle time was QUITE good in 1961 or so.  10 us
> instruction execution time was pretty decent.

I find the whole period amazing.   Consider that the 709 was introduced
in mid 1958.  It's only 6 years to the S/360.  It seems that when
transistor manufacture matured enough, the floodgates really opened.
After 1958, nobody but developing or Warsaw pact countries even
considered vacuum tube computing.

--Chuck

Re: IBM 7074 and then some: "Systems we love" conference

[Jon Elson]

On 01/24/2017 11:14 PM, Chuck Guzis wrote:
Given that the whole SMS thing was the common denominator 
among the 7000 and 1400 and 1620 lines, it's hard to say 
who was first. But the 7070 was first delivered. --Chuck 
Which is damned amazing, as the 7070 was a VERY ambitious 
machine. 30,000 transistors, 22,000 diodes on 14,000 circuit 
cards.  TOTALLY mind boggling.


And, the 7074 was a serious computer, given the vintage.  
Either 4 or 6 us core cycle time was QUITE good in 1961 or 
so.  10 us instruction execution time was pretty decent.


Jon

Re: IBM 7074 and then some: "Systems we love" conference

[Chuck Guzis]

On 01/24/2017 07:55 PM, Jon Elson wrote:

> Well, they were all built using SMS card technology, and a few
> pictures seem to show very similar backplane setup. I didn't know the
> 7070 was the first of that generation.  While the first 7030 was
> delivered after the 7070, development of the Stretch probably started
> first.

Yup, I was going by delivery dates.  "If you can't deliver it, it
doesn't exist".  IIRC, Gene Amdahl and friends originally proposed a
design using point-contact transistors (trying to get a uniform batch of
those was "interesting").  The proposal died a couple of times, until
IBM pitched what was then vaporware to LANL (then LASL).  Development
was started in 1956, according to WikiP.

Given that the whole SMS thing was the common denominator among the 7000
and 1400 and 1620 lines, it's hard to say who was first.  But the 7070
was first delivered.

--Chuck

Re: IBM 7074 and then some: "Systems we love" conference

[Jon Elson]

On 01/24/2017 08:57 PM, Chuck Guzis wrote:

On 01/24/2017 06:37 PM, Jon Elson wrote:

On 01/24/2017 12:38 PM, Chuck Guzis wrote:

Was the 7070 IBM's first machine with a wire-wrapped backplane?
--Chuck

No, all SMS machines used similar wire wrapping.  So, I think that
goes back to the 7030 (Stretch) and probably 1620, 1401 and others of
that time.  I'm pretty sure those preceded the 70xx series.

The 7070 was very early (1958) and is probably the first (or close to
the first) IBM transistorized computer.  The 1620 and 1401 were both
1959 introductions.  First delivery of STRETCH to LANL was 1961.


Well, they were all built using SMS card technology, and a 
few pictures seem to show very similar backplane setup.
I didn't know the 7070 was the first of that generation.  
While the first 7030 was delivered after the 7070, 
development of the Stretch probably started first.


Jon

Re: Anyone have the service guide for a Sanyo VM4209 monitor?

[ethan]

Never mind.  I took a picture of the internals of both and they are NOT at
all the same, unfortunately.
http://vintagecomputer.ca/sanyo-vm-4209-vs-hitachi-vm-909/
Good luck in finding the Sanyo schematics.  I'd love to have a copy myself.
Santo


Step #1. Replace all electrolytics?


--
Ethan O'Toole

Re: IBM 7074 and then some: "Systems we love" conference

[Chuck Guzis]

On 01/24/2017 06:37 PM, Jon Elson wrote:
> On 01/24/2017 12:38 PM, Chuck Guzis wrote:
>> Was the 7070 IBM's first machine with a wire-wrapped backplane?
>> --Chuck
> No, all SMS machines used similar wire wrapping.  So, I think that
> goes back to the 7030 (Stretch) and probably 1620, 1401 and others of
> that time.  I'm pretty sure those preceded the 70xx series.

The 7070 was very early (1958) and is probably the first (or close to
the first) IBM transistorized computer.  The 1620 and 1401 were both
1959 introductions.  First delivery of STRETCH to LANL was 1961.

--Chuck

Re: Anyone have the service guide for a Sanyo VM4209 monitor?

[Santo Nucifora]

Never mind.  I took a picture of the internals of both and they are NOT at
all the same, unfortunately.

http://vintagecomputer.ca/sanyo-vm-4209-vs-hitachi-vm-909/

Good luck in finding the Sanyo schematics.  I'd love to have a copy myself.

Santo

On Tue, Jan 24, 2017 at 8:32 PM, Santo Nucifora 
wrote:

> Hi Corey,
>
> Is it possible that the Sanyo monitor is a rebadged Hitachi VM-909 monitor
> (or the other way around)?   The Hitachi monitor user manual is only two
> pages, front and back but I also have schematic diagram for it too. The
> Hitachi monitor originally came as an option with the Polymorphic 8813.
>
> Santo
>
> On Tue, Jan 24, 2017 at 4:47 PM, Corey Cohen 
> wrote:
>
>> I need the schematics.  I'm not sure I trust all those "manual" sites on
>> the web that want to sell you a PDF for $15.
>>
>> My monitor seems to be acting up.
>>
>> Thanks in advance,
>> Cheers,
>> Corey
>>
>> corey cohen
>> uǝɥoɔ ʎǝɹoɔ
>
>
>

Re: recursive emulation

[Chuck Guzis]

On 01/24/2017 06:13 PM, Eric Smith wrote:

> The 432 chips were sampling in early 1981, and in limited production
> in mid-to-late 1981. (They were never in more than limited
> production.) They weren't $1000 even then.  Your salesman was either
> including the cost of a lot of other components he thought you'd
> need, or was off his meds, or something.

It could have been 1981--I'm a little fuzzy about dates back then.

It could be that Bill Davidow thought that the 432 was a lost cause and
wanted to discourage us--after all he was on our BOD.  But I do recall
the $1K chipset number and how that elicited a gasp.

--Chuck

Re: IBM 7074 and then some: "Systems we love" conference

[Jon Elson]

On 01/24/2017 12:38 PM, Chuck Guzis wrote:
Was the 7070 IBM's first machine with a wire-wrapped 
backplane? --Chuck 
No, all SMS machines used similar wire wrapping.  So, I 
think that goes back to the 7030 (Stretch)
and probably 1620, 1401 and others of that time.  I'm pretty 
sure those preceded the 70xx series.


Jon

Re: recursive emulation

[Eric Smith]

On Tue, Jan 24, 2017 at 6:59 PM, Chuck Guzis  wrote:

> Admittedly, this was before the 432 was released in any form, but I
> recall "Fast Eddie" our Intel sales guy quoting us about $1K for a
> chipset--this would have been about 1982.   That was expensive in
> anyone's book.
>

The 432 chips were sampling in early 1981, and in limited production in
mid-to-late 1981. (They were never in more than limited production.) They
weren't $1000 even then.  Your salesman was either including the cost of a
lot of other components he thought you'd need, or was off his meds, or
something.

Re: recursive emulation

[Chuck Guzis]

On 01/24/2017 05:49 PM, Eric Smith wrote:

> It actually wasn't *that* expensive.  Well, the development system
> was hideously expensive, but the chips weren't.  The General Data
> Processor (GDP, the "main" processor) was two chips, which together
> cost about $100 in modest quantities, and the Interface Processor
> (IP, an I/O channel interface that worked in conjunction with a 8-bit
> or 16-bit microprocessor) was about $50.  While that's a lot more
> expensive than an 8088, it was supposed to be a high-end processor,
> not a low-end processor like the 8088.  It's more appropriate to
> compare it to the early pricing of the 80286 with 80287.

Admittedly, this was before the 432 was released in any form, but I
recall "Fast Eddie" our Intel sales guy quoting us about $1K for a
chipset--this would have been about 1982.   That was expensive in
anyone's book.

--Chuck

Re: recursive emulation

[Eric Smith]

On Tue, Jan 24, 2017 at 3:27 PM, Chuck Guzis  wrote:

> Somewhere along the line, Intel's much ballyhooed 432 platform quietly
> sank under the waves (Micro-mainframe).  It was a multi-chip set and
> hideously expensive.
>

It actually wasn't *that* expensive.  Well, the development system was
hideously expensive, but the chips weren't.  The General Data Processor
(GDP, the "main" processor) was two chips, which together cost about $100
in modest quantities, and the Interface Processor (IP, an I/O channel
interface that worked in conjunction with a 8-bit or 16-bit microprocessor)
was about $50.  While that's a lot more expensive than an 8088, it was
supposed to be a high-end processor, not a low-end processor like the
8088.  It's more appropriate to compare it to the early pricing of the
80286 with 80287.

What killed the 432 wasn't that it was expensive, but that it was extremely
slow.  Few people would have wanted it even if Intel sold it for $5.

Re: Anyone have the service guide for a Sanyo VM4209 monitor?

[Santo Nucifora]

Hi Corey,

Is it possible that the Sanyo monitor is a rebadged Hitachi VM-909 monitor
(or the other way around)?   The Hitachi monitor user manual is only two
pages, front and back but I also have schematic diagram for it too. The
Hitachi monitor originally came as an option with the Polymorphic 8813.

Santo

On Tue, Jan 24, 2017 at 4:47 PM, Corey Cohen 
wrote:

> I need the schematics.  I'm not sure I trust all those "manual" sites on
> the web that want to sell you a PDF for $15.
>
> My monitor seems to be acting up.
>
> Thanks in advance,
> Cheers,
> Corey
>
> corey cohen
> uǝɥoɔ ʎǝɹoɔ

Re: recursive emulation

[Chuck Guzis]

On 01/24/2017 03:05 PM, dwight wrote:
> They might have used the 80188.

Maybe, but the 80188 was even later than the 186.  Given the integrated
peripheral support on the 186, however, it probably wouldn't have
economized much on the support circuitry to use an 8 bit BIU.

--CHuck

Re: recursive emulation

[dwight]

They might have used the 80188.

Dwight



From: cctalk  on behalf of Chuck Guzis 

Sent: Tuesday, January 24, 2017 2:27:47 PM
To: General Discussion: On-Topic and Off-Topic Posts
Subject: Re: recursive emulation

On 01/24/2017 01:50 PM, Pete Turnbull wrote:


>> Many people think Intel was stupid to have the 80186 be incompatible
>> with the PC but they forget that this processor was practically finished
>> by the time the PC came out and was launched just a few months later,

We started getting samples of the 186 in 1981.  It was, as you might
imagine, pretty buggy--IIRC, we were getting a new stepping about every
month for a time.  Some of the bugs were really bizarre, such as DMA
clobbering the SI and DI registers during the DMA operation (at the
conclusion, they were restored correctly, which made tracking that one
down very difficult.)

What many people don't realize is that the 80286 development was going
on in parallel with the 80186.  It was even more buggy, as one might
expect, in the pre-release steppings than the 186.

Had IBM had working samples of the 186, I don't doubt for a second that
they would have used it as the CPU of the 5150--the advantages were too
great to ignore--integrated 20-bit DMA, timers, interrupt controller and
programmable chip selects would have certainly gone far toward reducing
the component count on the PC.

Somewhere along the line, Intel's much ballyhooed 432 platform quietly
sank under the waves (Micro-mainframe).  It was a multi-chip set and
hideously expensive.

The 8086 really was a 1970s CPU.

--Chuck

Re: recursive emulation

[Chuck Guzis]

On 01/24/2017 01:50 PM, Pete Turnbull wrote:


>> Many people think Intel was stupid to have the 80186 be incompatible
>> with the PC but they forget that this processor was practically finished
>> by the time the PC came out and was launched just a few months later,

We started getting samples of the 186 in 1981.  It was, as you might
imagine, pretty buggy--IIRC, we were getting a new stepping about every
month for a time.  Some of the bugs were really bizarre, such as DMA
clobbering the SI and DI registers during the DMA operation (at the
conclusion, they were restored correctly, which made tracking that one
down very difficult.)

What many people don't realize is that the 80286 development was going
on in parallel with the 80186.  It was even more buggy, as one might
expect, in the pre-release steppings than the 186.

Had IBM had working samples of the 186, I don't doubt for a second that
they would have used it as the CPU of the 5150--the advantages were too
great to ignore--integrated 20-bit DMA, timers, interrupt controller and
programmable chip selects would have certainly gone far toward reducing
the component count on the PC.

Somewhere along the line, Intel's much ballyhooed 432 platform quietly
sank under the waves (Micro-mainframe).  It was a multi-chip set and
hideously expensive.

The 8086 really was a 1970s CPU.

--Chuck

Re: recursive emulation

[Pete Turnbull]

On 24/01/2017 22:19, Jecel Assumpcao Jr. wrote:

Pete Turnbull wrote:

Interesting.  You know that Acorn had a software PC emulator for the
Archimedes called PCEmu, on sale in late 1987?



I don't remember if I was aware of this at that time, but it is very
likely and that could have been the inspiration for our project.



In the RiscPC era they used actual Intel processors instead of (or was
it as an alternative to) software emulation.


Instead of.  There were third-part hardware addons using Intel CPUs by 
1989 or thereabouts.



Amusingly, it ran MS-DOS better than  [...] custom MS-DOS on an 80186.



Many people think Intel was stupid to have the 80186 be incompatible
with the PC but they forget that this processor was practically finished
by the time the PC came out and was launched just a few months later,


And it was evidently really meant for embedded applications rather than 
as a CPU for IBM-compatible PCs.


--
Pete
Pete Turnbull

Anyone have the service guide for a Sanyo VM4209 monitor?

[Corey Cohen]

I need the schematics.  I'm not sure I trust all those "manual" sites on the 
web that want to sell you a PDF for $15. 

My monitor seems to be acting up.  

Thanks in advance,
Cheers,
Corey 

corey cohen
uǝɥoɔ ʎǝɹoɔ

Re: tu58fs - PDP-11 file sharing with TU58 tape emulator

[Jörg Hoppe]

Am 24.01.2017 um 14:26 schrieb Mouse:

Can't believe that FreeBSD has no baudrate > 38400 !

serial.c:443:44: error: use of undeclared identifier 'B300'
serial.c:444:16: error: use of undeclared identifier 'B250'
serial.c:445:16: error: use of undeclared identifier 'B200'

At least some systems don't use B constants except for
compatability - they simply stick the baudrate in c_ospeed and/or
c_ispeed.  (I don't use FreeBSD myself; I don't know whether it's one
of them or not.)

But there were a bunch of other undefined symbols too, many of which
(eg, CRDLY, NLDLY) I don't recognize and which are not present in at
least one other termio implementatino (NetBSD's).  So at least part of
the problem is that the code isn't all that portable.

I notice you used gmake, from which I infer the Makefile is
GNU-make-specific, which makes it at least somewhat likely the code was
written for Linux, which makes the nonportabilities less surprising.
(Code being written for Linux correlates positively, in my experience,
with it assuming every system matches the developer's.  Not that this
is necessarily bad - I've done it myself often enough, though not often
with Linux - but it does, to some extent, explain what you're seeing.)

You're right, it's Linux.
And for other systems we must start to #ifdef lots of Unix-flavour 
specific termios code into serial.c.


Joerg

Re: IBM 7074 and then some: "Systems we love" conference

[Chuck Guzis]

On 01/24/2017 09:25 AM, Jon Elson wrote:

> I wonder how late IBM still supported the 7074 microcode emulation?
> And, of course, anybody could write a software-level emulation for
> the 7074, in IBM or other hardware.  One reason maybe to not run simh
> on a PC is if the data comes in on old mag tapes (gasp, maybe even
> 556 BPI NRZI half-inch tapes)?

That would seem to me to be an insane decision also.  How many 2400' 556
 bpi 7-track tapes can you fit on a 1TB PC drive?  Why fool with
maintaining a bank of drives in that light?

The biquinary coding used on the 7070 different from that of the 650.  A
two-out of 5 bit scheme was used (01236, with 0 being represented as
12).   IIRC, the 650 used 7 bits.  A word was 10 digits plus sign; a
reference to 55 bit length is made, which would seem to devote a whole
digit to the sign--it's not clear why this was done, as the sign appears
to have only 2 values.

https://www.computer.org/csdl/proceedings/afips/1959/5054/00/50540222.pdf

Has a good detailed run-down.  There are some interesting details; for
example, although it employed a digit-sequential ALU, circuitry
apparently did leading nonsignificant zero detection, so that only the
number of significant digits was operated upon.

Another interesting aspect was the scatter/gather tape I/O facility.
One normally thinks of this as a feature on later gear; to see it in
1959 is a bit surprising.  Also interesting is hardware prioritizing of
I/O operations.

Was the 7070 IBM's first machine with a wire-wrapped backplane?

--Chuck

Re: Parallel computation

[Paul Koning]

> On Jan 23, 2017, at 8:33 PM, Paul Koning  wrote:
> 
>> 
>> On Jan 23, 2017, at 5:09 PM, Toby Thain  wrote:
>> 
>> On 2017-01-23 6:55 PM, Paul Koning wrote:
>>> 
 On Jan 23, 2017, at 3:52 PM, Chuck Guzis  wrote:
 
 ...
 It's just that I bridle a bit when hearing the young 'uns refer to any
 physically large machine as a "supercomputer".
 
 It's the same feeling that I get when I see press releases today that
 relate that David Gelernter single-handedly developed the parallel
 computation.  He's not old enough; at 61, he was still in high school
 during the ILLIAC IV era.
>>> 
>>> Even earlier...
>>> 
>>> From what I've read, ENIAC supported parallel computing, but in practice it 
>>> wasn't used because it was too hard to get the code right.  At least, 
>>> that's what a computer design course from 1948 states.
>>> 
>> 
>> Has this been scanned anywhere?
> 
> Yes, it's on the CWI website in Amsterdam.  The trouble for most readers is 
> that it's in Dutch.  I'm working on translating it.  Report CR3, Principles 
> of electronic computers, course Feb 1948, by A. van Wijngaarden.
> 
> His comments on ENIAC should be able to be confirmed (or refuted) from ENIAC 
> documentation.

Here is a translation of the relevant text from that report (page 6):

General strategy.

A very important question is how many operations are performed in
parallel in the machine.  Here we must distinguish between large scale
parallelism and small scale parallelism.

Large scale parallelism means the possibility of performing multiple
arithmetic operations on distinct operands at the same time.  This of
course requires multiple arithmetic elements, for example 4 adders or
2 multipliers.  The immediate benefit is faster calculation.  In
addition, such multiple arithmetic elements have a significant
additional storage capacity.  In the Eniac essentially the entire fast
storage capacity is implemented by its adder elements.  However, the
distribution of the calculation program among these elements is not a
trivial matter if we really want the whole system to be working
efficiently.  For this reason, the most effective approach to make
Eniac a more manageable machine is that of von Neumann, in which 19 of
the 20 adders are simply demoted to memories.  In some machines (for
example the relay machine of Stibits) great ingenuity has been applied
to allow the machine to be split arbitrarily into a number of
independent machines, or to acts as a single unit.



So the implication is that Eniac is a 20 unit MIMD computer.  Amazing.

paul

Re: tu58fs - PDP-11 file sharing with TU58 tape emulator

[Jon Elson]

On 01/24/2017 01:33 AM, Jörg Hoppe wrote:


Hmmm, anyone out there who understands FreeBSD termios(4) .
Can't believe that FreeBSD has no baudrate > 38400 !

Hmmm, I use minicom all the time at 115200 baud.  Depending 
on what actual serial hardware you have, this may be a 
hardware limit.  If it uses a baud rate divisor chip rather 
than a more flexible divider, it may not be able to go faster.


Jon

Re: IBM 7074 and then some: "Systems we love" conference

[Jon Elson]

On 01/24/2017 12:00 AM, Chuck Guzis wrote:

On 01/23/2017 09:42 PM, Jon Elson wrote:

On 01/23/2017 07:45 PM, Jon Elson wrote:

This blog seems to indicate that there is NO 7074, but an emulator
running on 370 hardware.

http://nikhilism.com/post/2016/systems-we-love/

This makes a lot more sense, some of these microcode emulations were
still available of fairly late machines.  Also, it probably would not
be real hard to write a decent emulator for the 7074 and run it on
modern hardware.  Once you are using emulation, why not keep the host
hardware current?

Too bad the excerpts from the original talk are totally scrambled.

It wouldn't surprise me if the IBM S/370 isn't being emulated as well.
It wouldn't be the first time for "nested" emulation.

Is there a "recursive" emulator setup wherein one machine emulates
another one...where the final emulation is for the original hardware?


I have no idea, although VM/370 systems tended to have a LOT 
of instances of OS'es and virtual machines running.


I wonder how late IBM still supported the 7074 microcode 
emulation? And, of course, anybody could write a 
software-level emulation for the 7074, in IBM or other 
hardware.  One reason maybe to not run simh on a PC is if 
the data comes in on old mag tapes (gasp, maybe even 556 BPI 
NRZI half-inch tapes)?


Jon

Re: IBM 7074 and then some: "Systems we love" conference

[Jon Elson]

On 01/23/2017 11:46 PM, Chuck Guzis wrote:

Bob Bener has written a short squib about how the 7070 came into being:

http://www.bobbemer.com/BIRTH.HTM

Funny, in a tragic way.


WOW!  But, at the end, he says the 707x is a 6-bit machine.  
It seems, in fact, that the 707x was a WORD machine, not a 
character machine.  There is a fair amount of info on it 
that seems to confirm this.  Also, the stated speeds seem to 
be invariant for short vs. long (10-digit) operations, 
pretty much proving it was a word machine.


Jon

Re: recursive emulation

[Pete Turnbull]

On 24/01/2017 16:46, Jecel Assumpcao Jr. wrote:

In 1988 I designed an ARM2 based computer (my Merlin 4, which was only
built in 1992 when the ARM2 was already obsolete) and wondered if it
could emulate a PC fast enough to be usable. I had written an ARM
assembler and a friend did an ARM emulator running in QNX on the PC, so
we wrote an 8088 emulator in ARM assembly. We then ran some simple 8088
programs on the PC emulator running on the ARM emulator running on the
PC. This allowed us to figure out that an 8 MHz ARM2 would be able to
run PC programs at nearly the speed of a 4.77 MHz 8088.


Interesting.  You know that Acorn had a software PC emulator for the 
Archimedes called PCEmu, on sale in late 1987?  In 1988 they sold it 
bundled with an Archimedes A310 (8MHz ARM2, 1MB of RAM) called the A310M 
(M for MS-DOS).  It ran at just a little less than the speed of a 
4.77MHz 8086.  Amusingly, it ran MS-DOS better than the then-current 
Nimbus PC from their arch competitor Research Machines - PCEmu would 
happily run things like Borland Sidekick, Lotus 1-2-3, Microsoft's 
Flight Simulator etc where the RM PC often failed because it had a 
custom MS-DOS running on an 80186.


--
Pete
Pete Turnbull

RE: Compaq foam rot keyboard SOLVED

[Electronics Plus]

-Original Message-
From: cctalk [mailto:cctalk-boun...@classiccmp.org] On Behalf Of Al Kossow
Sent: Tuesday, January 24, 2017 10:16 AM
To: cctalk@classiccmp.org
Subject: Re: Compaq foam rot keyboard SOLVED



On 1/24/17 12:24 AM, Randy Dawson wrote:
> take a look in you junk bin for a IBM PC compatible keyboard, it worked
for me.
> 

The BTC 5339R is a bit more common on eBay and is foam and foil
https://geekhack.org/index.php?topic=77030.msg1935636#msg1935636

I didn't see it anywhere on geekhack, it would be nice if they had a table
of what BTC keyboards were foam and foil.

https://deskthority.net/wiki/Category:BTC_keyboards
https://deskthority.net/wiki/BTC_foam_and_foil

DT will tell you which ones are foam and foil.

Re: Compaq foam rot keyboard SOLVED

[Al Kossow]

On 1/24/17 12:24 AM, Randy Dawson wrote:
> take a look in you junk bin for a IBM PC compatible keyboard, it worked for 
> me.
> 

The BTC 5339R is a bit more common on eBay and is foam and foil
https://geekhack.org/index.php?topic=77030.msg1935636#msg1935636

I didn't see it anywhere on geekhack, it would be nice if they had a table of 
what
BTC keyboards were foam and foil.

Re: recursive emulation (was: IBM 7074 and then some: "Systems we love" conference)

[Paul Koning]

> Chuck Guzis asked on Mon, 23 Jan 2017 22:00:15 -0800
>> Is there a "recursive" emulator setup wherein one machine emulates
>> another one...where the final emulation is for the original hardware?

An example where that could be useful is in validating an emulation.  I did 
that recently: running an EL-X8 emulation implemented in ALGOL (by Dick Gruene) 
on an EL-X8 emulation in SIMH.  Run the test program that comes with it both on 
the nested emulation, and "standalone" on the outer emulation.  Compare the 
outputs from the two runs, and fix or justify any differences.  It helped 
significantly, especially because the inner emulation came with a bunch of 
important details about strange machine quirks.

paul

Re: recursive emulation

[Toby Thain]

On 2017-01-24 2:46 PM, Jecel Assumpcao Jr. wrote:

Chuck Guzis asked on Mon, 23 Jan 2017 22:00:15 -0800

Is there a "recursive" emulator setup wherein one machine emulates
another one...where the final emulation is for the original hardware?


In 1988 I designed an ARM2 based computer (my Merlin 4, which was only
built in 1992 when the ARM2 was already obsolete) and wondered if it
could emulate a PC fast enough to be usable. I had written an ARM
assembler and a friend did an ARM emulator running in QNX on the PC, so
we wrote an 8088 emulator in ARM assembly. We then ran some simple 8088
programs on the PC emulator running on the ARM emulator running on the
PC. This allowed us to figure out that an 8 MHz ARM2 would be able to
run PC programs at nearly the speed of a 4.77 MHz 8088.


Was this a JIT emulator (like Apple's later versions of 68K emulation), 
or a simple interpreter?


--Toby


> Though there

were much faster PCs at the time, the original configuration was still
being sold and was popular enough that this would have been considered
usable. It was not enough to convince my partner, however, which is why
the machine was not finished in 1988.

-- Jecel

ISO Altos 586 firmware

[Al Kossow]

I've been working on documenting the hardware in the early Altos x86 machines
and it would be nice to find a copy of the eproms from a 586.

I tried asking Dave Dunfield about this, but never got a reply. Has anyone
heard anything from him lately?

I know Eric Smith was trying to contact him a few months ago about extending
the known disk types in Imagedisk (specifically adding M2FM as one of the 
formats)
but I don't think he ever heard anything back.

recursive emulation (was: IBM 7074 and then some: "Systems we love" conference)

[Jecel Assumpcao Jr.]

Chuck Guzis asked on Mon, 23 Jan 2017 22:00:15 -0800
> Is there a "recursive" emulator setup wherein one machine emulates
> another one...where the final emulation is for the original hardware?

In 1988 I designed an ARM2 based computer (my Merlin 4, which was only
built in 1992 when the ARM2 was already obsolete) and wondered if it
could emulate a PC fast enough to be usable. I had written an ARM
assembler and a friend did an ARM emulator running in QNX on the PC, so
we wrote an 8088 emulator in ARM assembly. We then ran some simple 8088
programs on the PC emulator running on the ARM emulator running on the
PC. This allowed us to figure out that an 8 MHz ARM2 would be able to
run PC programs at nearly the speed of a 4.77 MHz 8088. Though there
were much faster PCs at the time, the original configuration was still
being sold and was popular enough that this would have been considered
usable. It was not enough to convince my partner, however, which is why
the machine was not finished in 1988.

-- Jecel

Re: tu58fs - PDP-11 file sharing with TU58 tape emulator

[Mouse]

> Can't believe that FreeBSD has no baudrate > 38400 !

>> serial.c:443:44: error: use of undeclared identifier 'B300'
>> serial.c:444:16: error: use of undeclared identifier 'B250'
>> serial.c:445:16: error: use of undeclared identifier 'B200'

At least some systems don't use B constants except for
compatability - they simply stick the baudrate in c_ospeed and/or
c_ispeed.  (I don't use FreeBSD myself; I don't know whether it's one
of them or not.)

But there were a bunch of other undefined symbols too, many of which
(eg, CRDLY, NLDLY) I don't recognize and which are not present in at
least one other termio implementatino (NetBSD's).  So at least part of
the problem is that the code isn't all that portable.

I notice you used gmake, from which I infer the Makefile is
GNU-make-specific, which makes it at least somewhat likely the code was
written for Linux, which makes the nonportabilities less surprising.
(Code being written for Linux correlates positively, in my experience,
with it assuming every system matches the developer's.  Not that this
is necessarily bad - I've done it myself often enough, though not often
with Linux - but it does, to some extent, explain what you're seeing.)

/~\ The ASCII Mouse
\ / Ribbon Campaign
 X  Against HTMLmo...@rodents-montreal.org
/ \ Email!   7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B

Re: Transformer part ID please

[Adrian Graham]

On 24/01/2017 06:06, "Tony Duell"  wrote:

>> 
>> and it's 0.6ohm max.
> 
> Are you telling me that if you put 2 logic analyser inputs on 2 points on the
> same trace (which tests as continuous with an ohmmeter) that said 2 LA
> channels don't show the same thing? If so, the LA needs repairing!

...or binning given how much they cost. Thinking about it, with the 'simple
parallel' decoding option of the software I can clock the sampling using the
external 8085 clock on pin 37. If THAT gives inconsistent results then I can
only assume it's not up to the job.
 
> Given the problems I've had with even clean old sockets, I would have
> replaced those. Corroded sockets must be worse. And I can't believe
> they used turned-pin sockets in something like this.

Yes, it surprised me too. They do seem to have used decent components though
which is probably why it was so expensive back in 1984. I'll change the
sockets tonight.

-- 
Adrian/Witchy
Binary Dinosaurs creator/curator
Www.binarydinosaurs.co.uk - the UK's biggest private home computer
collection?

Compaq foam rot keyboard SOLVED

[Randy Dawson]

I posted yesterday about my attempt to weld a IBM PC keyboard to my Compaq 
model 1 - the 'luggable'.


Well, it did not work, even though I saw clock and data on both Compaq and IBM 
keyboards that looked the same.  I did not dig into the decoding, but somehow 
they are different.


OK so I already cut into the PC keyboard, a BTC 5100.  I let my son play with 
it and a screwdriver, and as he gets it apart, I see capacitive foam pads 
inside.


Well guess what, they are the same size and fit for the Compaq Keytronics 
keyboard!


I popped out all the pads and transplanted them, you push them in and snap the 
plastic disk in the guides with an exacto, and they work perfectly.


I think a lot of these early keyboards before the switch to elastomeric rubber 
have these foam pads, and they are a standard size.


If you are stuck with a Tandy, Lisa, Sun with keyboard foam rot, take a look in 
you junk bin for a IBM PC compatible keyboard, it worked for me.


Randy

Re: tu58fs - PDP-11 file sharing with TU58 tape emulator

[Jörg Hoppe]

Hmmm, anyone out there who understands FreeBSD termios(4) .
Can't believe that FreeBSD has no baudrate > 38400 !

Joerg


On Fri, Jan 20, 2017 at 8:51 PM, Jörg Hoppe  wrote:

If you like to have a look (and play beta tester):

Docs on http://retrocmp.com/tools/tu58fs
C sources and makefile on https://github.com/j-hoppe/tu58fs

FWIW, It doesn't compile on FreeBSD (yes, I do not know if it is supposed to)
tingo@kg-core1$ gmake
cc -I. -c -UWINCOMM  -ggdb3 -O0 -m64 main.c -o freebsd-amd64/main.o
cc -I. -c -UWINCOMM  -ggdb3 -O0 -m64 getopt2.c -o freebsd-amd64/getopt2.o
getopt2.c:228:20: warning: using the result of an assignment as a
condition without parentheses [-Wparentheses]
 for (i = 0; odesc = _this->option_descrs[i]; i++)
 ~~^
getopt2.c:228:20: note: place parentheses around the assignment to
silence this warning
 for (i = 0; odesc = _this->option_descrs[i]; i++)
   ^
 (  )
getopt2.c:228:20: note: use '==' to turn this assignment into an
equality comparison
 for (i = 0; odesc = _this->option_descrs[i]; i++)
   ^
   ==
getopt2.c:364:21: warning: using the result of an assignment as a
condition without parentheses [-Wparentheses]
 for (i = 0; odesc = _this->option_descrs[i]; i++)
 ~~^
getopt2.c:364:21: note: place parentheses around the assignment to
silence this warning
 for (i = 0; odesc = _this->option_descrs[i]; i++)
   ^
 (  )
getopt2.c:364:21: note: use '==' to turn this assignment into an
equality comparison
 for (i = 0; odesc = _this->option_descrs[i]; i++)
   ^
   ==
getopt2.c:439:20: warning: using the result of an assignment as a
condition without parentheses [-Wparentheses]
 for (i = 0; odesc = _this->option_descrs[i]; i++)
 ~~^
getopt2.c:439:20: note: place parentheses around the assignment to
silence this warning
 for (i = 0; odesc = _this->option_descrs[i]; i++)
   ^
 (  )
getopt2.c:439:20: note: use '==' to turn this assignment into an
equality comparison
 for (i = 0; odesc = _this->option_descrs[i]; i++)
   ^
   ==
getopt2.c:646:16: warning: using the result of an assignment as a
condition without parentheses [-Wparentheses]
 for (i = 0; s = odesc->fix_args[i]; i++) {
 ~~^~~~
getopt2.c:646:16: note: place parentheses around the assignment to
silence this warning
 for (i = 0; s = odesc->fix_args[i]; i++) {
   ^
 ( )
getopt2.c:646:16: note: use '==' to turn this assignment into an
equality comparison
 for (i = 0; s = odesc->fix_args[i]; i++) {
   ^
   ==
getopt2.c:651:16: warning: using the result of an assignment as a
condition without parentheses [-Wparentheses]
 for (i = 0; s = odesc->var_args[i]; i++) {
 ~~^~~~
getopt2.c:651:16: note: place parentheses around the assignment to
silence this warning
 for (i = 0; s = odesc->var_args[i]; i++) {
   ^
 ( )
getopt2.c:651:16: note: use '==' to turn this assignment into an
equality comparison
 for (i = 0; s = odesc->var_args[i]; i++) {
   ^
   ==
getopt2.c:751:20: warning: using the result of an assignment as a
condition without parentheses [-Wparentheses]
 for (i = 0; odesc = _this->option_descrs[i]; i++) {
 ~~^
getopt2.c:751:20: note: place parentheses around the assignment to
silence this warning
 for (i = 0; odesc = _this->option_descrs[i]; i++) {
   ^
 (  )
getopt2.c:751:20: note: use '==' to turn this assignment into an
equality comparison
 for (i = 0; odesc = _this->option_descrs[i]; i++) {
   ^
   ==
getopt2.c:754:26: warning: the value of the size argument in 'strncat'
is too large, might lead to a buffer overflow [-Wstrncat-size]
 strncat(linebuff, " ", sizeof(linebuff));
^~~~
getopt2.c:754:26: note: change the argument to be the free space in
the destination buffer minus the terminating null byte
 strncat(linebuff, " ", sizeof(linebuff));
^~~~