Re: RCA 1802s available

[Guy Sotomayor Jr via cctalk]

According to the website, they are “genuine” original RCA parts.

TTFN - Guy

> On Dec 17, 2019, at 11:22 AM, crufta cat via cctalk  
> wrote:
> 
> They are likely later than the 70s and even more likely Intersil made parts
> from
> the 80s and even later.  Same for 1806s.
> 
> People forget that Chrysler used them for engine controls int he late 80s.
> 
> There is also "refurb parts" of questionable quality and origin.
> 
> Allison
> 
> On Tue, Dec 17, 2019 at 1:56 PM Al Kossow via cctalk 
> wrote:
> 
>> 
>> 
>> On 12/17/19 9:30 AM, Will Cooke via cctalk wrote:
>>> An ad was emailed to me today with an interesting item:  RCA 1802
>> processors.
>> 
>> Not a bad price, did you buy any?
>> Were they actually RCA-branded parts from the 70's?
>> 
>> 
>> 

Re: Bad heads on RL02: Worth replacing

[Guy Sotomayor Jr via cctalk]

> On Dec 16, 2019, at 3:07 PM, Chris Zach via cctalk  
> wrote:
> 
> So one of my RL02 drives (bought on Ebay years ago) is eating RL02 packs. 
> Makes tings, then the disks have errors in my other RL02 drive. Took a bit to 
> figure out which drive was eating what, but I'm 100% certain it's this newer 
> drive.
> 
> So pulled the heads. The top one had significant gunk on it, the bottom one a 
> bit. Pics below.
> 
> Top: https://i.imgur.com/FELhF9X.jpg
> Bottom: https://i.imgur.com/Tmsf5Nd.jpg
> 
> With alcohol and lintless swabs I managed to clean both of the heads up.
> 
> Top: https://i.imgur.com/gmACM4R.jpg
> Bottom: https://i.imgur.com/SfZQV5F.jpg
> 
> Then put them back in the drive and mounted a scratch pack. With finger on 
> the load/run I let the drive spin up and when I heard tinging I immediately 
> spun down. Hopefully I didn't trash my scratch pack.
> 
> Top head has gunk, bottom one had a few flecks, but looks pretty ok.
> Top: https://i.imgur.com/EAvgmuH.jpg
> Bottom: (picture didn't upload)
> 
> Obviously the head is crashing, any idea why and if it's worth replacing the 
> head or should I put this drive out for parts? Yes I cleaned the RL02 pack 
> before putting it in.
> 
> Never dull.

I would try replacing the head(s).

TTFN - Guy

Re: SMD disk specifications

[Guy Sotomayor Jr via cctalk]

Thanks Eric, I somehow missed that one.

TTFN - Guy

> On Dec 13, 2019, at 11:42 AM, Eric Smith  wrote:
> 
> On Fri, Dec 13, 2019 at 10:55 AM Guy Sotomayor via cctalk 
> mailto:cctalk@classiccmp.org>> wrote:
> I’ve been trying to find *detailed* specifications (mainly detailed signal 
> timings) for the SMD disk interface but all I’ve found so far are the 
> interface specifications for individual disks (CDC, Fujitsu, etc).  I’ve 
> looked in the usual places (bitsavers mostly) and haven’t found the spec 
> itself.  If anyone has any pointers, I’d appreciate it.
> 
> You've seen that the SMD spec (as of March 1981) is on Bitsavers?
> pdf/cdc/discs/interface_specs/64712400_SMDCableSpec_Mar81.pdf 
> 
> That doesn't cover later enhancements such as SMD-E.
> 

Re: Converting C for KCC on TOPS20

[Guy Sotomayor Jr via cctalk]

I think the challenge will be does binutils (where nm, objcopy and objdump 
live) support for the object file format used by TOPS20.

I haven’t looked at the TOPS20 object file format but it seems like the best 
approach would be to have the C compiler generate symbols as it normally would 
and write a utility to “fixup” the too long symbols rather than munging the 
source (which is basically what you’re proposing using the stuff from 
binutils…just a bit more work.

TTFN - Guy

> On Dec 11, 2019, at 9:07 AM, Guy N. via cctalk  wrote:
> 
> On Wed, 2019-12-11 at 00:25 +, David Griffith via cctalk wrote:
>> I'm trying to convert some C code[1] so it'll compile on TOPS20 with KCC. 
>> KCC is mostly ANSI compliant, but it needs to use the TOPS20 linker, which 
>> has a limit of six case-insentive characters.  [...] Does anyone here have 
>> any knowledge of existing tools or techniques to do what I'm trying to do?
> 
> Is "objcopy --redefine-syms" any help?  Compile the code as-is to
> produce object files, use nm or objdump to find all of the global
> symbols, generate unique six-character names for them, and then use
> objcopy to create new object files with the new names.
> 
> Or have I completely missed the point?  I'm not familiar with KCC, does
> it produce object modules in a format objcopy doesn't support?
> 
> I know someone who was working on gcc support for the PDP-10, I wonder
> if he's still doing that or has given up
> 

Re: FPGA based 3174 replacement

[Guy Sotomayor Jr via cctalk]

I have several Zynq boards that I’m using (or will be) for other projects but 
having a replacement
for the 3174 would be nice.

TTFN - Guy

> On Nov 18, 2019, at 9:51 AM, Dave Wade via cctalk  
> wrote:
> 
> Chris,
> I have several Spartan boards, no Zync...
> ... but would be interested to see how it works...
> Dave
> 
>> -Original Message-
>> From: cctalk  On Behalf Of cw via cctalk
>> Sent: 18 November 2019 17:43
>> To: cctalk@classiccmp.org
>> Subject: FPGA based 3174 replacement
>> 
>> As it happens I wrote a Verilog module last week for serializing and
>> deserializing 3270 coax frames, without realizing someone had already done
>> this with an arduino. What I’ve written is intended for a zynq device but is
>> general enough to be used in other designs.
>> 
>> At the moment I have petalinux installed and can send frames with a small 
>> test
>> program and see them on my scope. A loop back configuration also seems to
>> work. I haven’t build the coax driver circuit yet so I can’t be sure of it’s 
>> correct
>> operation.
>> 
>> I’d be willing to make this code available tonight. Although I’m not sure how
>> many people have the right hardware lying around.
>> 
>> Chris
> 

Re: 3270 controller simulation

[Guy Sotomayor Jr via cctalk]

Yes, I have my 3174 communicating with Hercules (as well as my MP3000).

TTFN - Guy

> On Nov 18, 2019, at 8:45 AM, Al Kossow via cctalk  
> wrote:
> 
> 
> 
> On 11/18/19 8:22 AM, Grant Taylor via cctalk wrote:
> 
>> I believe the *Remote* 3174 (et al.) is one of these devices from IBM.
> 
> The bigger 3174s have ethernet as an option, as did the Memorex/Telex 1174
> More commonly, 3174s had token ring and people have gone Cisco to 3174 to
> get coax terminals talking to Hercules. I believe Guy S., Dave W. and Jay W.
> have done this. I have the parts to do either token ring or ethernet on a
> 3174, and just got probably one of the last 1174s in the world with ethernet
> (but no docs)
> 
> One of my projects is to try to get something similar going that is 
> open-source
> which is why I was interested in ajk's arduino project
> 
> 

Re: LISP implementations on small machines

[Guy Sotomayor Jr via cctalk]

> On Oct 3, 2019, at 10:26 AM, Paul Koning via cctalk  
> wrote:
> 
> 
> 
>> On Oct 3, 2019, at 12:39 PM, Chuck Guzis via cctalk  
>> wrote:
>> 
>> On 10/3/19 9:01 AM, Noel Chiappa via cctalk wrote:
>> 
>>> The PDP-6 and KA10 (basically a re-implementation of the PDP-6 architecture)
>>> both had cheapo versions where addresses 0-15 were in main memory, but also
>>> had an option for real registers, e.g. in the PDP-6: "The Type 162 Fast
>>> Memory Module contains 16 words with a 0.4 usecond cycle." The KA10 has
>>> a similar "fast memory option".
>> 
>> A bit more contemporary example might be the low-end PIC
>> microcontrollers (e.g. the 12F series).   Harvard architecture (14 bit
>> instructions, 8 bit data), but data is variously described as
>> "registers" (when used an instruction operand) or "memory" when
>> addressed indirectly.   That is, the 64 bytes of SRAM can be referred to
>> as either a memory location or as a register operand.
> 
> Then again, the PDP-10 has that "two ways to refer to it" as well.  In that 
> case, you do have dedicated register logic, and what happens is that memory 
> addresses 0-15 are instead redirected to the register array.  The same 
> applies to the EL-X8.  The way you can address things doesn't necessarily 
> tell you what sort of storage mechanism is used for it.
> 

So does the PDP-11.  The 8 registers are mapped to the top 8 words of memory so 
you can do some quite interesting things.  It is also possible to run a (small) 
program in only the registers (e.g. no memory at all).

TTFN - Guy

Re: Early Univac Commercial

[Guy Sotomayor Jr via cctalk]

Yea, I recall having to take that test.  I almost didn’t because my degree is 
EE but then
they realized I was applying for SW positions.  Go figure!  ;-)

Worked there for 17+ years.

TTFN - Guy

> On Sep 20, 2019, at 8:52 AM, Chuck Guzis via cctalk  
> wrote:
> 
> On 9/20/19 8:16 AM, William Sudbrink via cctalk wrote:
>> Isn't there also one that's a "help wanted" for programming positions?
>> I seem to recall that they didn't say anything about professional training
>> or experience, just things like "do you have a logical, ordered way of
>> thinking?"
> 
> I don't recall, but IBM had a "computer aptitude test" that it
> administered to just about anyone involved in sales or the technical
> end, regardless of education.   I recall taking such a test, though I
> turned down IBM's job offer.
> 
> --Chuck
> 

Re: [Simh] Fwd: VAX + Spectre

[Guy Sotomayor Jr via cctalk]

> On Sep 18, 2019, at 9:59 AM, Chris Elmquist  wrote:
> 
> On Wednesday (09/18/2019 at 09:19AM -0700), Guy Sotomayor Jr via cctalk wrote:
>> 
>> 
>>> On Sep 18, 2019, at 12:42 AM, Liam Proven via cctalk 
>>>  wrote:
>>> 
>>> On Wed, 18 Sep 2019 at 02:19, Paul Koning via cctalk
>>>  wrote:
>>>>> ...
>>>> Speaking of timing, that reminds me of two amazing security holes written 
>>>> up in the past few years.  Nothing to do with the Spectre etc. issue.
>>>> 
>>>> One is the recovery of speech from an encrypted VoIP channel such as 
>>>> Skype, by looking at the sizes of the encrypted data blocks.  (Look for a 
>>>> paper named "Hookt on fon-iks" by White et al.)  The fix for this is 
>>>> message padding.
>>>> 
>>>> The other is the recovery of the RSA private key in a smartphone by 
>>>> listening to the sound it makes while decrypting.  The fix for this is 
>>>> timing tweaks in the decryption inner loop.  (Look for a paper by, among 
>>>> others, Adi Shamir, the S in RSA and one of the world's top 
>>>> cryptographers.)
>>>> 
>>>> It's pretty amazing what ways people find to break into security 
>>>> mechanisms.
>>> 
>>> ... Wow.
>>> 
>>> *Wow.*
>>> 
>>> Thanks for those!
>> 
>> In the deep dark days of yore, I recall an actual demonstration of being 
>> able to read/replicate the contents of the screen (CRT) of a PC by looking 
>> at the AC (e.g. mains) that the PC was plugged into.  Admittedly it was 
>> relatively low fidelity, but yikes!
> 
> https://en.wikipedia.org/wiki/Van_Eck_phreaking 
> <https://en.wikipedia.org/wiki/Van_Eck_phreaking>

Cool!

Yea, I had to make a trip to a “secure facility” once and there were entire 
“tempest” rooms with conditioned power and no external communications 
equipment.  The room itself (think *large*) was a faraday cage with a vault 
door that was kept closed when ever there was sensitive stuff going on.  Since 
I didn’t have a security clearance, the door was open and everywhere I went 
there were red lights in the rooms/halls that I was in that would be on to 
indicate that no sensitive information should be discussed (makes you feel 
really wanted).  ;-)

TTFN - Guy

Re: [Simh] Fwd: VAX + Spectre

[Guy Sotomayor Jr via cctalk]

> On Sep 18, 2019, at 12:42 AM, Liam Proven via cctalk  
> wrote:
> 
> On Wed, 18 Sep 2019 at 02:19, Paul Koning via cctalk
>  wrote:
>>> ...
>> Speaking of timing, that reminds me of two amazing security holes written up 
>> in the past few years.  Nothing to do with the Spectre etc. issue.
>> 
>> One is the recovery of speech from an encrypted VoIP channel such as Skype, 
>> by looking at the sizes of the encrypted data blocks.  (Look for a paper 
>> named "Hookt on fon-iks" by White et al.)  The fix for this is message 
>> padding.
>> 
>> The other is the recovery of the RSA private key in a smartphone by 
>> listening to the sound it makes while decrypting.  The fix for this is 
>> timing tweaks in the decryption inner loop.  (Look for a paper by, among 
>> others, Adi Shamir, the S in RSA and one of the world's top cryptographers.)
>> 
>> It's pretty amazing what ways people find to break into security mechanisms.
> 
> ... Wow.
> 
> *Wow.*
> 
> Thanks for those!

In the deep dark days of yore, I recall an actual demonstration of being able 
to read/replicate the contents of the screen (CRT) of a PC by looking at the AC 
(e.g. mains) that the PC was plugged into.  Admittedly it was relatively low 
fidelity, but yikes!

TTFN - Guy

Re: UNIBUS FTGH: EMM / CMU MICRORAM memories

[Guy Sotomayor Jr via cctalk]

> On Sep 17, 2019, at 8:17 AM, Stefan Skoglund  wrote:
> 
> mån 2019-09-16 klockan 11:17 -0700 skrev Guy Sotomayor Jr via cctalk:
>> 
>> And that’s just the HW.  Hydra (the OS that ran on C.MMP) was a
>> capability based system (so you needed the proper capability to do
>> anything).  I recall at one point the grad student who was doing work
>> on the file system, “lost” the root capability to the file system…so
>> it was no longer possible to create new file systems.
>> 
>> 
> 
> Which also means that for boot-strap you need to create a correct fully
> populated binary dump of all the file system in the system.
> A dump which is sane which regards to capabilities and user
> capabilities 
> 
> It is a little like kick-starting a database system ie writing the
> system database (pg_system) into such a state that is it possible to
> correctly run for example:
> ---
> create tablespace 'stefan';
> create schema 'pg';
> ---
> and so on…
> 

The problem (and I’d be thrilled to be wrong) is that the probability of having
a binary dump of Hydra is 0 for small values of 0.  Part of the issue is that 
the
C.MMP has a few RP06 drives (4-6?).  If it were ever saved, it would have to
be to 9-track tapes and I don’t recall any sort of backup facilities.  The RP06
packs *might* still be around but I wouldn’t hold out too much hope for them
either.

TTFN - Guy

Re: UNIBUS FTGH: EMM / CMU MICRORAM memories

[Guy Sotomayor Jr via cctalk]

11/40’s were pretty ubiquitous at CMU when I was there and at least as far as I 
could tell, were all configured pretty much the same (in that they all had 
custom writable control store).  I personally dealt with 3 different sets of 
11/40s:
A single 11/40 with WCS that I used for doing some image processing work
2 11/40’s tied together with a prototype of C.MMP’s cross point switch
C.MMP (16-way PDP11…I saw it running with 4 11/20s and 12 11/40s).  At the end 
the 11/20s were removed and just the 11/40s remained.

There were only 2 11/45s that I knew of.  The first was the “front end” that 
sat in front of all of the terminals and allowed connection to the various 10s 
(at the time there were 3: 2 KA10s and a KL10), C.MMP and CM*.  The other 11/45 
ran the XGP (Xerox Graphics Printer)…granddaddy of laser printers so that we 
could get “high quality” output (versus line printer).

TTFN - Guy

> On Sep 16, 2019, at 2:27 PM, Fritz Mueller via cctalk  
> wrote:
> 
> First off, I've had a couple of follow-ups on these units, so they are spoken 
> for at this point.
> 
> The member with first dibs has also offered to scan the docs and see that 
> they make their way to Al.
> 
> I was wondering if these were c.mmp cast-offs?  Guy: I encountered these in 
> the CMU computer club hardware room (Doherty Hall basement, I think?) circa 
> 1986.  There were a couple of '11/40s adjacent, and those did have some sort 
> of custom writable control store cards.
> 
> The computer club was cleaning house, so I hauled off an '11/45 with CPU 
> spares that looked pretty stock, the aforementioned memory units, and a rack 
> mount Tek 'scope (about all I could convince my friends to help me haul off 
> campus at the time :-)
> 
> Not sure what ever happened to the rest of the equipment that was down there. 
>  I know they had a couple of working Altos, on a thick net segment with the 
> old vampire transceivers that had the little round glass windows in an 
> aluminum box.  And what must have been parts of an earlier PDP (I remember a 
> smallish teletype bolted on to a piece of white Formica desktop.)
> 
>   --FritzM.
> 

Re: UNIBUS FTGH: EMM / CMU MICRORAM memories

[Guy Sotomayor Jr via cctalk]

I don’t know.  It would be hard to replicate because of the custom HW and the 
custom uCode that ran on the 11/40s.  I even think that the 11/20s were 
modified as well.  So trying to figure that out would be “interesting”.  ;-)  
There is documentation on bitsavers that covers the custom uCode HW for the 
11/40s.  The MMU as I recall was also radically different than what was 
standard on 11/40s (and non-existant on 11/20s…the 11/20 changes started to get 
to be so large, I believe later on they just ditched the 11/20s and C. was just 
all 11/40s) to allow for  really large memory spaces…I don’t recall what the 
maximum possible memory on C. was, it did have 1.2MB while I was there.

And that’s just the HW.  Hydra (the OS that ran on C.MMP) was a capability 
based system (so you needed the proper capability to do anything).  I recall at 
one point the grad student who was doing work on the file system, “lost” the 
root capability to the file system…so it was no longer possible to create new 
file systems.

Since C.MMP was a “one off” system, don’t expect (even if the SW survives) that 
there’s an “installation guide”.  ;-)  It was pretty organic.  Last and not 
least, all of the code was either PDP-11 assembler or BLISS-11.  It was all 
cross built from the (heavily) modified TOP-10 systems that the CS department 
was running.

Hydra did a number of things that eventually lead to Accent and then Mach 
(which portions are still in use in the guts of OS X).  It was what we would 
call today a microkernel system in that the kernel was the only thing that ran 
in privileged mode.  Everything else were user processes (file system, drivers, 
terminal system, etc).  As I said, it was a capability based system, so to use 
something you needed to have a capability to it (files didn’t have Unix style 
permissions…if you had a capability to a file that capability determined what 
you could do to the file).  It had a number of reliability traits: it could 
detect failures in HW and in SW and restart the appropriate failed item.  In 
the case of CPUs and memory, it could “wall off” the failed component can cause 
diagnostics to be run to either isolate the problem further or determine that 
the failure is no longer present.

TTFN - Guy

> On Sep 16, 2019, at 10:59 AM, Paul Koning  wrote:
> 
> 
> 
>> On Sep 16, 2019, at 1:52 PM, Guy Sotomayor Jr via cctalk 
>>  wrote:
>> 
>> The only thing that I believe would have used these would have been C.MMP.  
>> It had 1.2MB of memory on it when I was there.
>> 
>> TTFN - Guy
> 
> It's been a long time since I've heard that reference.  Did any of that 
> software get preserved?  I wonder how hard it would be to make SIMH handle it.
> 
>   paul
> 

Re: UNIBUS FTGH: EMM / CMU MICRORAM memories

[Guy Sotomayor Jr via cctalk]

The only thing that I believe would have used these would have been C.MMP.  It 
had 1.2MB of memory on it when I was there.

TTFN - Guy

> On Sep 16, 2019, at 10:45 AM, Al Kossow via cctalk  
> wrote:
> 
> I would be interested in putting up the later docs
> I wonder if Guy remembers what these were used for at CMU
> 
> On 9/16/19 10:19 AM, Shoppa, Tim via cctalk wrote:
>> The Microram was a multipurpose solid state memory chassis sold by EMM 
>> (Electronic Memories and Magnetics) with what we called later in the 1970's 
>> a "personality board" that plugged it into each different CPU's backplane.  
>> They sold a similar system (maybe even plug compatible at some level) with 
>> core planes under "Micromemory" brand name. I see we already have a "emm" 
>> directory in bitsavers with docs about some of their core products.
>> 
> 

Re: SMD disks

[Guy Sotomayor Jr via cctalk]

I’m actively working on SMD and ESDI emulators.  However, given my work 
schedule this is a long term project.  :-(

TTFN - Guy

> On Aug 30, 2019, at 10:56 AM, Jonathan Haddox via cctalk 
>  wrote:
> 
> With SMD disks even harder to come by than MFM disks, has there been any 
> plug-in replacements developed for them? I've seen MFM disk emulators, 
> haven't seen SMD ones though, anyone know if they exist?  

Re: Shipping from Europe to USA

[Guy Sotomayor Jr via cctalk]

> On Aug 25, 2019, at 2:05 AM, Noel Chiappa via cctalk  
> wrote:
> 
>> From: Jon Elson
> 
>> I have NEVER had even the SLIGHTEST damage with FedEx, even their
>> ground service. This could just be statistical chance
> 
> This. I once had FexEx Ground destroy the entire packaging of a shipment (one
> of those rigid plastic tubs, sealed closed with those tension tapes) so badly
> they had to build entirely new packaging for it.
> 
> Assume _all_ shippers will throw your item across the room, and pack
> accordingly - because they will.
> 

I have found that if the item is packed *appropriately* in a crate and then put
on a pallet it receives much gentler handling than something that’s been stuffed
in a cardboard box.

It all comes down to what is the item worth to *you*.  Yes, doing what I 
proposed
will cost more in shipping but what is that cost relative to the value (to you) 
of the
item and the difficulty in replacing it?

TTFN - Guy

Re: S/23 machine update card

[Guy Sotomayor Jr via cctalk]

> On Aug 19, 2019, at 9:35 AM, Dennis Boone  wrote:
> 
>> The uCode in the S/23 is 8085 assembly code that is contained within
>> the ROMs.  The ROMs have the ability to be patched and the card
>> you’re referencing is used to hold those updates.  So without that
>> card you’re not able to apply any ROM updates (which are loaded each
>> boot).
> 
> Ah, ok, that makes sense.  It's only 16k of RAM.
> 
>> It’s been long enough that I don’t recall what (if any) updates there
>> are and when (and from what) they’re loaded.
> 
> When the machine powers up, it pre-enters a command (PROC START?  PROC
> INIT?  Brane faid.) which could presumably load firmware from diskette.
> There aren't a lot of other options.  They could be loaded from fixed
> disk if you had one, but they'd have to get there somehow.

Yea, that’s part of setting up the fixed disk.  I was working on other projects
(mainly the PC) at that point.

> 
>> The system architecture allows for *much* more than the 64KB normally
>> accessible by the 8085 CPU.  The memory is bank switched.  There is a
>> fixed ROM and fix RAM portion of the address space and a bank
>> switched ROM and RAM portion of the address space.  16KB of fixed
>> (for ROM/RAM) sticks in my head for some reason.  I don’t recall the
>> granularity of the bank switched areas.
> 
> Right, the memory map for all of that is in the service manuals.  The
> pageable sections each have 16 possible pages, and footnotes indicate
> that two ROM and one RAM (think I have that right way round) pages are
> not used.  A total of 32k of address space for each of ROM and RAM, so
> it would make sense that the pages are 16k, and that the fixed portions
> are 16k also.
> 
> What's not there is how the RAM on the card is paged in.  The base RAM
> card and the feature RAM card are mentioned, but I don't believe the
> details of their mapping is described.

I never actually used a version with actual ROMs (except for the one I have
sitting here in my shop).  All development was done with special RAM cards
in place of the ROM.  Made development *much* easier.

However, development was not without its pain.  When I started, a full build
of the base software (e.g. full ROM image) took a week (yep, 7 days).  So
we would carry around “patches”.  Both “blessed” patches and our own
individual test patches.

Getting those into the “official” build cleanly usually resulted in 2 or 3 
attempts
because how you needed to develop a patch was different than actually
putting in the change in built source.  So when a new build came out, tests
would be run and additional patches applied.  It was a real pain.

We were jumping up and down for joy when the build was moved to the
mainframe and we would get builds back in ~24 hours!

> 
>> The patching was accomplished by having each major or critical
>> function in the ROM be dispatched through a call table (that is
>> placed in RAM at boot and can be “patched” to point to a different
>> function).  It was *more* than just the ROM address as it also
>> contained the bank # of the ROM as well since (with few exceptions)
>> all calls were “long calls”.
> 
> Thanks for the enlightenment!  Were you involved in the development of
> these machines?

Yes, it was my first job out of college.  I wrote about 20% of the ROM code:
floating point code…which because it was a “business” machine was all done in 
BCD
formatting code (anything that is done via print and print using).  I don’t 
recall if I did anything on the “input” side.
unwinding expressions when you do a “list”.  The source is always thrown away 
and just the bytecode is retained so the source needs to be “recreated”.
a bunch of other stuff that I can’t recall now.

> 
> Presumably there's an I/O to be done to the mapping hardware as part of
> a "long call”?

That is correct.

TTFN - Guy

Re: S/23 machine update card

[Guy Sotomayor Jr via cctalk]

The uCode in the S/23 is 8085 assembly code that is contained within the ROMs.
The ROMs have the ability to be patched and the card you’re referencing is used 
to
hold those updates.  So without that card you’re not able to apply any ROM 
updates
(which are loaded each boot).

It’s been long enough that I don’t recall what (if any) updates there are and 
when (and
from what) they’re loaded.

The system architecture allows for *much* more than the 64KB normally 
accessible by
the 8085 CPU.  The memory is bank switched.  There is a fixed ROM and fix RAM 
portion
of the address space and a bank switched ROM and RAM portion of the address 
space.
16KB of fixed (for ROM/RAM) sticks in my head for some reason.  I don’t recall 
the
granularity of the bank switched areas.

There was a lot of confusion when the S/23 came out about what the ROM/RAM
specifications (192KB of ROM, 128KB of RAM) because an 8085 could only address
64KB.  ;-)

The patching was accomplished by having each major or critical function in the 
ROM 
be dispatched through a call table (that is placed in RAM at boot and can be 
“patched” 
to point to a different function).  It was *more* than just the ROM address as 
it also
contained the bank # of the ROM as well since (with few exceptions) all calls 
were
“long calls”.

TTFN - Guy

> On Aug 18, 2019, at 6:11 PM, Jon Elson via cctalk  
> wrote:
> 
> 
> On 08/18/2019 06:38 PM, Dennis Boone via cctalk wrote:
>> Folks,
>> 
>> I've determined that the piece of my S/23 that's causing the power
>> supply to blow its 12V fuse is the machine update card.  The manual says
>> this provides additional R/W storage for microprogram updates.  That
>> sounds like something that wouldn't be necessary for normal operation.
>> 
>> 
> Not knowing anything about this system, but you might check the card for a 
> bad Tantalum capacitor.
> 
> Jon

Re: Identification of an HP minicomputer

[Guy Sotomayor Jr via cctalk]

> On Aug 15, 2019, at 6:57 PM, Mark Linimon  wrote:
> 
> On Thu, Aug 15, 2019 at 02:27:16PM -0700, Guy Sotomayor Jr via cctalk wrote:
>> Between work and preparing for potential fire evacuations (they're
>> expecting ~300 wild fires in my area this fire season: we've only had 
>> about 6 so far so I expect *a lot* more soon)
> 
> Yikes!  Please stay safe.

That’s the plan.  Thanks.

We’ve had a fire (when I say fire, I mean wildfire and not what most folks are 
familiar with which are structure fires) near town yesterday and another one (a 
bit further away) today.  So it’s picking up.  To hit the expected 300 for this 
season, we’ll need about 2 per day!  Fortunately most so far have been fairly 
small (20-80 acres).  I know that sounds *large* (our property is 10 acres) but 
last year’s fire in Paradise was over 150,000 acres (~240 sq miles) and 
destroyed over 18,000 buildings.  It is really hard to imagine the scale of the 
devastation.

  So everyone is taking this *much* more seriously now.  Today’s fire had 6+ 
fire engines respond, 2 bulldozers and 2 air tankers respond.

TTFN - Guy

Re: Identification of an HP minicomputer

[Guy Sotomayor Jr via cctalk]

Thanks Marc.

What I’ve done is about all I have time for at the moment.  Between work and 
prep’ing for potential fire evacuations (they’re expecting ~300 wild fires in 
my area this fire season…we’ve only had about 6 so far…so I expect *a lot* more 
soon) all of my time is gone.  :-(

TTFN - Guy

> On Aug 15, 2019, at 2:22 PM, Curious Marc via cctalk  
> wrote:
> 
> I found Brent Hilpert’s site most useful in getting a quick meaning for these 
> numbers:
> http://madrona.ca/e/HP21xx/index.html
> http://madrona.ca/e/HP21xx/iointerfaces.html
> There is also a very useful series 1000 reference manual that lists most of 
> the configs and options and cards, I will get to it when I am home and try to 
> send you a link.
> 
> My experience is that you absolutely have to open them up to figure out what 
> they actually are. They are so modular and upgradable and interchangeable 
> that the original config sticker rarely matches what’s inside. Actually, I 
> have yet to see one that has a config that matches the factory sticker. 
> Sometimes the motherboard isn’t even the series that the front panel says!
> 
> Also you need to find out what optional microcode ROMs they are fitted with 
> (extended/virtual memory, fast fortran, vector, scientific, etc...) to know 
> what version of RTE they can actually run, and which boot ROMs are installed. 
> That said they are very easy to take apart, just open front and back, slide 
> out top and bottom covers, slide the cards out, and admire the modular 
> design. They are also very well documented.
> 
> Marc
> 
>> On Aug 12, 2019, at 3:21 PM, Norman Jaffe via cctalk  
>> wrote:
>> 
>> Perhaps these will help? 
>> https://www.hpmuseum.net/exhibit.php?hwimg=108 
>> http://www.datormuseum.se/computers/hewlett-packard/hp-21mx 
>> 
>> 
>> From: "Guy Sotomayor Jr"  
>> To: "myself" , "cctalk"  
>> Sent: Monday, August 12, 2019 3:04:31 PM 
>> Subject: Re: Identification of an HP minicomputer 
>> 
>> It’s a 9-slot variant that says HP-1000 M-Series on the front panel. From 
>> what I can tell the front panel appears to be the same as any of the other 
>> HP-1000 series. 
>> 
>> What I’m trying to figure out is what the actual CPU configuration is 
>> without disassembly (which I still need to figure out) so that I can 
>> actually examine the boards. 
>> 
>> Thanks. 
>> 
>> TTFN - Guy 
>> 
>>> On Aug 12, 2019, at 2:59 PM, Norman Jaffe via cctalk 
>>>  wrote: 
>>> 
>>> Can you provide a picture of the front panel? 
>>> 2113 implies a 21MX-E; the nine-slot version is a 2109 while the 
>>> fourteen-slot would be a 2113. 
>>> This might help - https://www.hpmuseum.net/display_item.php?hw=109 . 
>>> 
>>> From: "cctalk"  
>>> To: "cctalk"  
>>> Sent: Monday, August 12, 2019 2:52:18 PM 
>>> Subject: Identification of an HP minicomputer 
>>> 
>>> Hi, 
>>> 
>>> I have sitting in my pile of stuff an HP minicomputer that I’m trying to 
>>> identify (at least in terms of exactly what it is and what sort of 
>>> configuration it might have). 
>>> 
>>> As far as I can tell, it’s an HP-1000 M-Series minicomputer (that should 
>>> hopefully get us *some* details). The “asset tag” lists the part number as 
>>> 2113023-108. Looking at the back there’s space for 9 I/O cards (5 are 
>>> occupied). 
>>> 
>>> So my question is which of the several CPUs could this be and how do I tell 
>>> (for example) what the configuration is (e.g. how much memory, etc). 
>>> 
>>> Yes, I have looked on bitsavers, but short of disassembling the box to look 
>>> at the (at least) 2 boards that are below the I/O slots, I can’t tell 
>>> what’s there and I’d like to see if there’s a way to determine what this is 
>>> without resorting to disassembly. 
>>> 
>>> Thanks. 
>>> 
>>> TTFN - Guy 

Re: GW-DEC-1: A New DEC Prototyping Board

[Guy Sotomayor Jr via cctalk]

Speaking from experience from having done a few Unibus boards now (none of them 
available yet unfortunately) that providing a general Unibus interface on a 
quad board will consume a reasonable amount of the board space and limit 
flexibility on which driver/receiver/transceiver parts that can be used.  
That’s just for the Unibus drivers.  If you want to actually *run* the 
interface then you’re talking a lot more stuff.

Of course, the boards I’m doing are all SMD (with the exception of the unibus 
interface parts).  I also have to add in 5v to 3.3v conversion.  Even on a 4 
layer board there’s lots of “congestion” which limits the number of parts that 
can actually placed on the board.  :-(

TTFN - Guy

> On Aug 15, 2019, at 1:23 AM, emanuel stiebler via cctalk 
>  wrote:
> 
> On 2019-08-15 02:13, systems_glitch via cctalk wrote:
>> Connor Krukosky and I have been working on laying out a new quad-height DEC
>> protoboard, which can also be sheared down into a dual-height board. Full
>> announce on the VC Forums:
>> 
>> http://www.vcfed.org/forum/showthread.php?71177-GW-DEC-1-A-New-Quad-Height-DEC-Prototyping-Board=582892#post582892
> 
> Was always hoping somebody would do something like that, but with the
> bus interface already on it ...

Re: Electr* Engineering

[Guy Sotomayor Jr via cctalk]

I can attest to that.  ;-)

Where I went (CMU) the CS department grew out of the Math department…while I 
was there the only degree that the CS department granted was PhD.  So everyone 
else majored in something else (EE in my case…which had a bunch of digital 
stuff but still focused on a lot of theory…differential equations, 
electromagnetic fields/waves and communications theory) and took CS courses as 
electives (which focused on data structures, algorithms, etc…e.g. a lot of CS 
theory).

TTFN - Guy

> On Aug 12, 2019, at 11:05 PM, Adam Thornton via cctalk 
>  wrote:
> 
> At Rice in the early 90s the department was "Electrical and Computer 
> Engineering" if my hazy memory serves.
> 
> The genealogy of Computer Science departments (and their curricula) (at least 
> in the US) is also weird and historically-contingent.  Basically it seems to 
> have been a tossup at any given school whether it came out of the 
> Electr[ical|onic] Engineering department, in which case it was memories and 
> logic gates and a bottom-up, hardware-focused curriculum, or out of the 
> Mathematics department, in which case it was algorithms and complexity 
> analysis and a software-focused curriculum.
> 
> Adam

Re: Identification of an HP minicomputer

[Guy Sotomayor Jr via cctalk]

Cool!

Thanks.

TTFN - Guy

> On Aug 12, 2019, at 4:50 PM, Mike Loewen via cctalk  
> wrote:
> 
> 
>   Not a single reference, but these two directories should provide most of 
> what you need:
> 
> http://www.bitsavers.org/pdf/hp/1000/
> 
> http://hpmuseum.net/exhibit.php?hwdoc=108
> 
>   The CE Handbook, Loader ROMS, Interfaces, and Standard Memory manuals will 
> all be useful.
> 
> 
> On Mon, 12 Aug 2019, Guy Sotomayor Jr wrote:
> 
>> OK, thanks.
>> 
>> Is there a sheet somewhere that I can use to decode all of these part 
>> numbers?
>> 
>> TTFN - Guy
>> 
>>> On Aug 12, 2019, at 4:25 PM, Mike Loewen via cctalk  
>>> wrote:
>>> 
>>> 
>>>  Sorry, I mistyped.  12746A is a 64KB (32KW) memory module.
>>> 
>>> On Mon, 12 Aug 2019, Guy Sotomayor Jr wrote:
>>> 
>>>> Except that I don?t have a 12745A memory board, I believe it?s a 12746A 
>>>> which I think I saw was a 16K board.
>>>> 
>>>> Thanks.
>>>> 
>>>> TTFN - Guy
>>>> 
>>>>> On Aug 12, 2019, at 4:07 PM, Mike Loewen via cctalk 
>>>>>  wrote:
>>>>> 
>>>>> 
>>>>> 2102B is the Standard Performance Memory Controller
>>>>> 12745A is a 64KB (32KW) memory board
>>>>> 12897B is a DCPC (Dual Channel Port Controller)
>>>>> 12992B is a 7905/7906/7920/7925 disc loader PROM
>>>>> 12892B is a Memory Protect board
>>>>> 12944B is the Power Fail Recovery System
>>>>> 
>>>>> On Mon, 12 Aug 2019, Guy Sotomayor Jr wrote:
>>>>> 
>>>>>> Thanks all!
>>>>>> 
>>>>>> The trick was opening up the front panel (I?m used to keylocks that are 
>>>>>> only electrical and not just physical).
>>>>>> 
>>>>>> Here?s the HP label with the options:
>>>>>> CPU 2103
>>>>>> MEM BP 1713
>>>>>> IO BP 1727
>>>>>> Accessories
>>>>>> 12992B
>>>>>> 12944B
>>>>>> 2102B
>>>>>> 12897B
>>>>>> 12892B
>>>>>> 12746A
>>>>>> 
>>>>>> In opening the panel on the front card cage, I saw that it only had 16K 
>>>>>> of memory.  :-(
>>>>>> 
>>>>>> I?ll see about firing it up and if that goes well (anyone have 
>>>>>> suggestions for this type of mini?) I?ll see if I find more memory and 
>>>>>> suitable peripherals.
>>>>>> 
>>>>>> Thanks.
>>>>>> 
>>>>>> TTFN - Guy
>>>>>> 
>>>>>> 
>>>>>>> On Aug 12, 2019, at 3:29 PM, Mike Loewen via cctalk 
>>>>>>>  wrote:
>>>>>>> 
>>>>>>> 
>>>>>>> The original M-Series machines were the 2105A and the 2108A (9-slot), 
>>>>>>> which sound like what you have.  The early machines didn't say 
>>>>>>> "M-Series" on the front panel, and had a different lock than the later 
>>>>>>> models:
>>>>>>> 
>>>>>>> http://q7.neurotica.com/Oldtech/HP/2108A/HP2108A-8L.jpg (my model 2108A)
>>>>>>> 
>>>>>>> Early models had the power switch on the back panel, while later models 
>>>>>>> had it behind the front panel.
>>>>>>> 
>>>>>>> It sounds like you might have a later model M. It would be helpful to 
>>>>>>> see a closeup of the read card cage (with readable labels), as well as 
>>>>>>> the front card cage.  The front card cage is accessed by unlocking the 
>>>>>>> panel and removing the cover on the right side over the card cage.  
>>>>>>> That's where the memory boards live.
>>>>>>> 
>>>>>>> On Mon, 12 Aug 2019, Guy Sotomayor Jr via cctalk wrote:
>>>>>>> 
>>>>>>>> It?s a 9-slot variant that says HP-1000 M-Series on the front panel.  
>>>>>>>> From what I can tell the front panel appears to be the same as any of 
>>>>>>>> the other HP-1000 series.
>>>>>>>> 
>>>>>>>> What I?m trying to figure out is what the actual CPU configuration is 
>>>>>>>>

Re: Identification of an HP minicomputer

[Guy Sotomayor Jr via cctalk]

Fun!

I have 4 HP minis at the moment:
2116C that was running the last time I checked
2 2114B that are in various states of “not working”.  Interestingly the most 
promising one (e.g. the one that hasn’t had various parts clipped or otherwise 
buggered) is where I can’t get it to power up at all (not even the fan).  So I 
have to go and dig into the power supply a bit more…it could also be that the 
power cord is wired up incorrectly since it uses an old style hubble twist-lock 
that I may not have wired up quite right)
HP-1000 M Series

TTFN - Guy

> On Aug 12, 2019, at 4:38 PM, Guy Dunphy  wrote:
> 
> Hi Guy,
> 
> If you didn't see this, it may be of interest: 
>   http://everist.org/NobLog/20131112_HP_1000_minicomputer_teardown.htm
> 
> It won't help you identify your system model, but could be of help with 
> disassembly.
> 
> Funny coincidence that we have the same name, and similar HP-1000 
> minicomputers.
> 
> Sigh... 2019 slips by, and I still haven't returned to that project.
> 
> Guy
> 
> 
> At 02:52 PM 12/08/2019 -0700, you wrote:
>> Hi,
>> 
>> I have sitting in my pile of stuff an HP minicomputer that I’m trying to 
>> identify (at least in terms of exactly what it is and what sort of 
>> configuration it might have).
>> 
>> As far as I can tell, it’s an HP-1000 M-Series minicomputer (that should 
>> hopefully get us *some* details).  The “asset tag” lists the part number 
>> as 2113023-108.  Looking at the back there’s space for 9 I/O cards (5 are 
>> occupied).
>> 
>> So my question is which of the several CPUs could this be and how do I tell 
>> (for example) what the configuration is (e.g. how much memory, etc).
>> 
>> Yes, I have looked on bitsavers, but short of disassembling the box to look 
>> at the (at least) 2 boards that are below the I/O slots, I can’t tell 
>> what’s there and I’d like to see if there’s a way to determine what 
>> this is without resorting to disassembly.
>> 
>> Thanks.
>> 
>> TTFN - Guy

Re: Identification of an HP minicomputer

[Guy Sotomayor Jr via cctalk]

OK, thanks.

Is there a sheet somewhere that I can use to decode all of these part numbers?

TTFN - Guy

> On Aug 12, 2019, at 4:25 PM, Mike Loewen via cctalk  
> wrote:
> 
> 
>   Sorry, I mistyped.  12746A is a 64KB (32KW) memory module.
> 
> On Mon, 12 Aug 2019, Guy Sotomayor Jr wrote:
> 
>> Except that I don?t have a 12745A memory board, I believe it?s a 12746A 
>> which I think I saw was a 16K board.
>> 
>> Thanks.
>> 
>> TTFN - Guy
>> 
>>> On Aug 12, 2019, at 4:07 PM, Mike Loewen via cctalk  
>>> wrote:
>>> 
>>> 
>>>  2102B is the Standard Performance Memory Controller
>>>  12745A is a 64KB (32KW) memory board
>>>  12897B is a DCPC (Dual Channel Port Controller)
>>>  12992B is a 7905/7906/7920/7925 disc loader PROM
>>>  12892B is a Memory Protect board
>>>  12944B is the Power Fail Recovery System
>>> 
>>> On Mon, 12 Aug 2019, Guy Sotomayor Jr wrote:
>>> 
>>>> Thanks all!
>>>> 
>>>> The trick was opening up the front panel (I?m used to keylocks that are 
>>>> only electrical and not just physical).
>>>> 
>>>> Here?s the HP label with the options:
>>>> CPU 2103
>>>> MEM BP 1713
>>>> IO BP 1727
>>>> Accessories
>>>> 12992B
>>>> 12944B
>>>> 2102B
>>>> 12897B
>>>> 12892B
>>>> 12746A
>>>> 
>>>> In opening the panel on the front card cage, I saw that it only had 16K of 
>>>> memory.  :-(
>>>> 
>>>> I?ll see about firing it up and if that goes well (anyone have suggestions 
>>>> for this type of mini?) I?ll see if I find more memory and suitable 
>>>> peripherals.
>>>> 
>>>> Thanks.
>>>> 
>>>> TTFN - Guy
>>>> 
>>>> 
>>>>> On Aug 12, 2019, at 3:29 PM, Mike Loewen via cctalk 
>>>>>  wrote:
>>>>> 
>>>>> 
>>>>> The original M-Series machines were the 2105A and the 2108A (9-slot), 
>>>>> which sound like what you have.  The early machines didn't say "M-Series" 
>>>>> on the front panel, and had a different lock than the later models:
>>>>> 
>>>>> http://q7.neurotica.com/Oldtech/HP/2108A/HP2108A-8L.jpg (my model 2108A)
>>>>> 
>>>>> Early models had the power switch on the back panel, while later models 
>>>>> had it behind the front panel.
>>>>> 
>>>>> It sounds like you might have a later model M. It would be helpful to see 
>>>>> a closeup of the read card cage (with readable labels), as well as the 
>>>>> front card cage.  The front card cage is accessed by unlocking the panel 
>>>>> and removing the cover on the right side over the card cage.  That's 
>>>>> where the memory boards live.
>>>>> 
>>>>> On Mon, 12 Aug 2019, Guy Sotomayor Jr via cctalk wrote:
>>>>> 
>>>>>> It?s a 9-slot variant that says HP-1000 M-Series on the front panel.  
>>>>>> From what I can tell the front panel appears to be the same as any of 
>>>>>> the other HP-1000 series.
>>>>>> 
>>>>>> What I?m trying to figure out is what the actual CPU configuration is 
>>>>>> without disassembly (which I still need to figure out) so that I can 
>>>>>> actually examine the boards.
>>>>>> 
>>>>>> Thanks.
>>>>>> 
>>>>>> TTFN - Guy
>>>>>> 
>>>>>>> On Aug 12, 2019, at 2:59 PM, Norman Jaffe via cctalk 
>>>>>>>  wrote:
>>>>>>> 
>>>>>>> Can you provide a picture of the front panel?
>>>>>>> 2113 implies a 21MX-E; the nine-slot version is a 2109 while the 
>>>>>>> fourteen-slot would be a 2113.
>>>>>>> This might help - https://www.hpmuseum.net/display_item.php?hw=109 .
>>>>>>> 
>>>>>>> From: "cctalk" 
>>>>>>> To: "cctalk" 
>>>>>>> Sent: Monday, August 12, 2019 2:52:18 PM
>>>>>>> Subject: Identification of an HP minicomputer
>>>>>>> 
>>>>>>> Hi,
>>>>>>> 
>>>>>>> I have sitting in my pile of stuff an HP minicomputer that I?m trying 
>>>>>>> to identify (at least in terms of exactly what it is and what sort of 
>>>>>>> configuration it might have).
>>>>>>> 
>>>>>>> As far as I can tell, it?s an HP-1000 M-Series minicomputer (that 
>>>>>>> should hopefully get us *some* details). The ?asset tag? lists the part 
>>>>>>> number as 2113023-108. Looking at the back there?s space for 9 I/O 
>>>>>>> cards (5 are occupied).
>>>>>>> 
>>>>>>> So my question is which of the several CPUs could this be and how do I 
>>>>>>> tell (for example) what the configuration is (e.g. how much memory, 
>>>>>>> etc).
>>>>>>> 
>>>>>>> Yes, I have looked on bitsavers, but short of disassembling the box to 
>>>>>>> look at the (at least) 2 boards that are below the I/O slots, I can?t 
>>>>>>> tell what?s there and I?d like to see if there?s a way to determine 
>>>>>>> what this is without resorting to disassembly.
>>>>>>> 
>>>>>>> Thanks.
>>>>>>> 
>>>>>>> TTFN - Guy
>>>>>> 
>>>>>> 
>>>>> 
>>>>> Mike Loewen   mloe...@cpumagic.scol.pa.us
>>>>> Old Technologyhttp://q7.neurotica.com/Oldtech/
>>>> 
>>>> 
>>> 
>>> Mike Loewen mloe...@cpumagic.scol.pa.us
>>> Old Technology  http://q7.neurotica.com/Oldtech/
>> 
>> 
> 
> Mike Loewen   mloe...@cpumagic.scol.pa.us
> Old Technologyhttp://q7.neurotica.com/Oldtech/

Re: Identification of an HP minicomputer

[Guy Sotomayor Jr via cctalk]

Except that I don’t have a 12745A memory board, I believe it’s a 12746A which I 
think I saw was a 16K board.

Thanks.

TTFN - Guy

> On Aug 12, 2019, at 4:07 PM, Mike Loewen via cctalk  
> wrote:
> 
> 
>   2102B is the Standard Performance Memory Controller
>   12745A is a 64KB (32KW) memory board
>   12897B is a DCPC (Dual Channel Port Controller)
>   12992B is a 7905/7906/7920/7925 disc loader PROM
>   12892B is a Memory Protect board
>   12944B is the Power Fail Recovery System
> 
> On Mon, 12 Aug 2019, Guy Sotomayor Jr wrote:
> 
>> Thanks all!
>> 
>> The trick was opening up the front panel (I?m used to keylocks that are only 
>> electrical and not just physical).
>> 
>> Here?s the HP label with the options:
>> CPU 2103
>> MEM BP 1713
>> IO BP 1727
>> Accessories
>> 12992B
>> 12944B
>> 2102B
>> 12897B
>> 12892B
>> 12746A
>> 
>> In opening the panel on the front card cage, I saw that it only had 16K of 
>> memory.  :-(
>> 
>> I?ll see about firing it up and if that goes well (anyone have suggestions 
>> for this type of mini?) I?ll see if I find more memory and suitable 
>> peripherals.
>> 
>> Thanks.
>> 
>> TTFN - Guy
>> 
>> 
>>> On Aug 12, 2019, at 3:29 PM, Mike Loewen via cctalk  
>>> wrote:
>>> 
>>> 
>>>  The original M-Series machines were the 2105A and the 2108A (9-slot), 
>>> which sound like what you have.  The early machines didn't say "M-Series" 
>>> on the front panel, and had a different lock than the later models:
>>> 
>>> http://q7.neurotica.com/Oldtech/HP/2108A/HP2108A-8L.jpg (my model 2108A)
>>> 
>>>  Early models had the power switch on the back panel, while later models 
>>> had it behind the front panel.
>>> 
>>>  It sounds like you might have a later model M. It would be helpful to see 
>>> a closeup of the read card cage (with readable labels), as well as the 
>>> front card cage.  The front card cage is accessed by unlocking the panel 
>>> and removing the cover on the right side over the card cage.  That's where 
>>> the memory boards live.
>>> 
>>> On Mon, 12 Aug 2019, Guy Sotomayor Jr via cctalk wrote:
>>> 
>>>> It?s a 9-slot variant that says HP-1000 M-Series on the front panel.  From 
>>>> what I can tell the front panel appears to be the same as any of the other 
>>>> HP-1000 series.
>>>> 
>>>> What I?m trying to figure out is what the actual CPU configuration is 
>>>> without disassembly (which I still need to figure out) so that I can 
>>>> actually examine the boards.
>>>> 
>>>> Thanks.
>>>> 
>>>> TTFN - Guy
>>>> 
>>>>> On Aug 12, 2019, at 2:59 PM, Norman Jaffe via cctalk 
>>>>>  wrote:
>>>>> 
>>>>> Can you provide a picture of the front panel?
>>>>> 2113 implies a 21MX-E; the nine-slot version is a 2109 while the 
>>>>> fourteen-slot would be a 2113.
>>>>> This might help - https://www.hpmuseum.net/display_item.php?hw=109 .
>>>>> 
>>>>> From: "cctalk" 
>>>>> To: "cctalk" 
>>>>> Sent: Monday, August 12, 2019 2:52:18 PM
>>>>> Subject: Identification of an HP minicomputer
>>>>> 
>>>>> Hi,
>>>>> 
>>>>> I have sitting in my pile of stuff an HP minicomputer that I?m trying to 
>>>>> identify (at least in terms of exactly what it is and what sort of 
>>>>> configuration it might have).
>>>>> 
>>>>> As far as I can tell, it?s an HP-1000 M-Series minicomputer (that should 
>>>>> hopefully get us *some* details). The ?asset tag? lists the part number 
>>>>> as 2113023-108. Looking at the back there?s space for 9 I/O cards (5 are 
>>>>> occupied).
>>>>> 
>>>>> So my question is which of the several CPUs could this be and how do I 
>>>>> tell (for example) what the configuration is (e.g. how much memory, etc).
>>>>> 
>>>>> Yes, I have looked on bitsavers, but short of disassembling the box to 
>>>>> look at the (at least) 2 boards that are below the I/O slots, I can?t 
>>>>> tell what?s there and I?d like to see if there?s a way to determine what 
>>>>> this is without resorting to disassembly.
>>>>> 
>>>>> Thanks.
>>>>> 
>>>>> TTFN - Guy
>>>> 
>>>> 
>>> 
>>> Mike Loewen mloe...@cpumagic.scol.pa.us
>>> Old Technology  http://q7.neurotica.com/Oldtech/
>> 
>> 
> 
> Mike Loewen   mloe...@cpumagic.scol.pa.us
> Old Technologyhttp://q7.neurotica.com/Oldtech/

Re: Identification of an HP minicomputer

[Guy Sotomayor Jr via cctalk]

Thanks all!

The trick was opening up the front panel (I’m used to keylocks that are only 
electrical and not just physical).

Here’s the HP label with the options:
CPU 2103
MEM BP 1713
IO BP 1727
Accessories
12992B
12944B
2102B
12897B
12892B
12746A

In opening the panel on the front card cage, I saw that it only had 16K of 
memory.  :-(

I’ll see about firing it up and if that goes well (anyone have suggestions for 
this type of mini?) I’ll see if I find more memory and suitable peripherals.

Thanks.

TTFN - Guy


> On Aug 12, 2019, at 3:29 PM, Mike Loewen via cctalk  
> wrote:
> 
> 
>   The original M-Series machines were the 2105A and the 2108A (9-slot), which 
> sound like what you have.  The early machines didn't say "M-Series" on the 
> front panel, and had a different lock than the later models:
> 
> http://q7.neurotica.com/Oldtech/HP/2108A/HP2108A-8L.jpg (my model 2108A)
> 
>   Early models had the power switch on the back panel, while later models had 
> it behind the front panel.
> 
>   It sounds like you might have a later model M. It would be helpful to see a 
> closeup of the read card cage (with readable labels), as well as the front 
> card cage.  The front card cage is accessed by unlocking the panel and 
> removing the cover on the right side over the card cage.  That's where the 
> memory boards live.
> 
> On Mon, 12 Aug 2019, Guy Sotomayor Jr via cctalk wrote:
> 
>> It?s a 9-slot variant that says HP-1000 M-Series on the front panel.  From 
>> what I can tell the front panel appears to be the same as any of the other 
>> HP-1000 series.
>> 
>> What I?m trying to figure out is what the actual CPU configuration is 
>> without disassembly (which I still need to figure out) so that I can 
>> actually examine the boards.
>> 
>> Thanks.
>> 
>> TTFN - Guy
>> 
>>> On Aug 12, 2019, at 2:59 PM, Norman Jaffe via cctalk 
>>>  wrote:
>>> 
>>> Can you provide a picture of the front panel?
>>> 2113 implies a 21MX-E; the nine-slot version is a 2109 while the 
>>> fourteen-slot would be a 2113.
>>> This might help - https://www.hpmuseum.net/display_item.php?hw=109 .
>>> 
>>> From: "cctalk" 
>>> To: "cctalk" 
>>> Sent: Monday, August 12, 2019 2:52:18 PM
>>> Subject: Identification of an HP minicomputer
>>> 
>>> Hi,
>>> 
>>> I have sitting in my pile of stuff an HP minicomputer that I?m trying to 
>>> identify (at least in terms of exactly what it is and what sort of 
>>> configuration it might have).
>>> 
>>> As far as I can tell, it?s an HP-1000 M-Series minicomputer (that should 
>>> hopefully get us *some* details). The ?asset tag? lists the part number as 
>>> 2113023-108. Looking at the back there?s space for 9 I/O cards (5 are 
>>> occupied).
>>> 
>>> So my question is which of the several CPUs could this be and how do I tell 
>>> (for example) what the configuration is (e.g. how much memory, etc).
>>> 
>>> Yes, I have looked on bitsavers, but short of disassembling the box to look 
>>> at the (at least) 2 boards that are below the I/O slots, I can?t tell 
>>> what?s there and I?d like to see if there?s a way to determine what this is 
>>> without resorting to disassembly.
>>> 
>>> Thanks.
>>> 
>>> TTFN - Guy
>> 
>> 
> 
> Mike Loewen   mloe...@cpumagic.scol.pa.us
> Old Technologyhttp://q7.neurotica.com/Oldtech/

Re: Identification of an HP minicomputer

[Guy Sotomayor Jr via cctalk]

It’s a 9-slot variant that says HP-1000 M-Series on the front panel.  From what 
I can tell the front panel appears to be the same as any of the other HP-1000 
series.

What I’m trying to figure out is what the actual CPU configuration is without 
disassembly (which I still need to figure out) so that I can actually examine 
the boards.

Thanks.

TTFN - Guy

> On Aug 12, 2019, at 2:59 PM, Norman Jaffe via cctalk  
> wrote:
> 
> Can you provide a picture of the front panel? 
> 2113 implies a 21MX-E; the nine-slot version is a 2109 while the 
> fourteen-slot would be a 2113. 
> This might help - https://www.hpmuseum.net/display_item.php?hw=109 . 
> 
> From: "cctalk"  
> To: "cctalk"  
> Sent: Monday, August 12, 2019 2:52:18 PM 
> Subject: Identification of an HP minicomputer 
> 
> Hi, 
> 
> I have sitting in my pile of stuff an HP minicomputer that I’m trying to 
> identify (at least in terms of exactly what it is and what sort of 
> configuration it might have). 
> 
> As far as I can tell, it’s an HP-1000 M-Series minicomputer (that should 
> hopefully get us *some* details). The “asset tag” lists the part number as 
> 2113023-108. Looking at the back there’s space for 9 I/O cards (5 are 
> occupied). 
> 
> So my question is which of the several CPUs could this be and how do I tell 
> (for example) what the configuration is (e.g. how much memory, etc). 
> 
> Yes, I have looked on bitsavers, but short of disassembling the box to look 
> at the (at least) 2 boards that are below the I/O slots, I can’t tell what’s 
> there and I’d like to see if there’s a way to determine what this is without 
> resorting to disassembly. 
> 
> Thanks. 
> 
> TTFN - Guy 

Re: Control Data 9766 drive on epay

[Guy Sotomayor Jr via cctalk]

Well, crap.

I got rid of my 2 9766’s and all the packs that I had for them a couple of 
years ago for nothing what this guy is asking for his.  ;-)
I probably still have a pile of heads for them (but they’d probably go to the 
guy who purchased the drives/packs from me).

What are folks using these types of drivers for?  Media content recovery or 
just using them as intended?

TTFN - Guy

> On Aug 12, 2019, at 11:09 AM, William Donzelli via cctalk 
>  wrote:
> 
> There is a Make Offer option, and it does look like the seller does
> take offers fairly regularly. I will not be buying it.
> 
> If someone does, I have a huge amount of spares for 976x drives,
> including refurbished heads. It might take a while to find them in my
> mess, however.
> 
> --
> Will
> 
> On Mon, Aug 12, 2019 at 1:43 PM P Gebhardt via cctalk
>  wrote:
>> 
>> Hi list,
>> 
>> Just came across this:
>> 
>> https://www.ebay.com/itm/Vintage-Computing-CDC-Magnetic-Peripherals-Control-Data-9766-Storage-Module/143351908424?hash=item2160708848:g:3yEAAOSw1oJdTo9u
>> 
>> Haven't seen one listed in years. The price lets me assume that this offer 
>> addresses customers that may use these drives in a production environment or 
>> so...
>> I am not aware of museums or hobbyists who have such drives currently in a 
>> functional state to read and write from and to 80MB (CDC 9762) or 300MB (CDC 
>> 9766) disk packs. Maybe the CHM? ... not taking into consideration the CHM 
>> activities related to the Xerox disk cartidge  (2315-equivalent) software 
>> archive project.
>> Anybody out there? Would be interesting to know.
>> 
>> Best regards,
>> Pierre
>> 
>> -
>> http://www.digitalheritage.de

Re: IBM Series/1

[Guy Sotomayor Jr via cctalk]

I have what appears to be a nice one…I just haven’t had time to do anything 
with it yet.

It does have 2 discs (I think one is 40MB and the other is 300MB).  There is a 
big label on the system that says “DEV’T TOOLS”
so I’m hopeful that there’s some interesting SW on it.

TTFN - Guy

> On Aug 2, 2019, at 12:40 PM, Kevin Bowling via cctalk  
> wrote:
> 
> Anyone have one of these?  I'd like to find a system, but images of
> the OS media would be interesting.
> 
> Regards,
> Kevin

Re: "half-dollar"/"50 cent piece" Was: Recovering the ROM of an IBM 5100 using OCR

[Guy Sotomayor Jr via cctalk]

> On Jul 1, 2019, at 2:10 PM, Fred Cisin via cctalk  
> wrote:
> 
> 
> 
>>> A "Dime" is one tenth of a dollar.  Or ten cents.  Or $10 worth of drugs.
>>> The coin is 17.91mm diameter, and the smallest coin in circulation.
>>> A "Nickel" is five cents.  or $5 worth of drugs.
>>> The coin is 21.21mm, and is between a penny and a quarter in size.
>> I'm broadly aware but I can never remember which is 5¢ and which is 10¢.
> 
> Think of the "dime" as a "deci"
> 
> "nickel and dime" is used to mean small and irrelevant.
> "nickel" and "dime" are also slang for $5 and $10 respectively, except in 
> casinos, because while the casinos still had coin slot machines 

In terms of denominations that the US used, originally there was no nickel.  
There was a half-dime to represent $0.05.  It was a silver coin half the size 
of the dime.  The mint changed over to nickel because the half-dime was too 
small.  The original nickel was almost identical to the $5 gold piece of the 
time, so with some simple chemistry (basically gold plating the nickel) you 
could pass it off as a $5 gold piece.  The mint changed the design of the 
nickel so as to make the subterfuge more obvious to the causal observer.

US coinage is littered with denominations that are no longer used:
half-cent ($0.005) copper
“large” cent ($0.01 but the approximate size of a quarter but of copper instead 
of silver)
2 cent piece (copper)
3 cent piece (nickel)
half-dime (silver)
20 cent piece (silver)

And then of course there the gold coins:
$1 (about the size of a dime)
$5 (about the size of a nickel)
$10 (about the size of a quarter)
$20 (about the size of a half dollar)
$50 (rare and about the size of a silver dollar)

Each coin (be it silver or gold) was intended to approximately represent the 
value of the metal in the coin (that is a $10 gold coin was supposed to contain 
roughly $10 of gold).  I believe at the time an ounce of silver was $1.25 and I 
believe gold was $32/oz.  These are of course troy ounces - 12 troy ounces to a 
pound versus 16 avoirdupois ounce to a pound.

TTFN - Guy

Re: CDC Cyber 180-960 available

[Guy Sotomayor Jr via cctalk]

Sorry, I passed this along with the information I was given.  I just wanted to 
make sure that it was saved rather than scrapped if at all possible.

TTFN - Guy

> On Jun 28, 2019, at 3:31 PM, William Donzelli  wrote:
> 
> HOLD THE BOAT!
> 
> It is still not clear if the 960 is to be kept at Vandenberg! This is
> the US Air Force here.
> 
> I would advise that this be NIPPED IN THE BUD.
> 
> --
> Will
> 
> --
> Will
> 
> --
> Will
> 
> On Fri, Jun 28, 2019 at 4:22 PM Guy Sotomayor via cctalk
>  wrote:
>> 
>> Hi,
>> 
>> It has come to my attention that a CDC Cyber 180-960 is available.  
>> Apparently this is from a supplier that was supporting Vandenburg AFB 
>> (California) with spares.  Since Vendenburg is decommissioning it’s Cyber 
>> systems, the supplier wants to get rid of the spare machine that they have.
>> 
>> I think the supplier just want the machine “to go away” so the price is 
>> likely to be negligible.
>> 
>> Please contact me off-list if interested and I’ll get you in touch with the 
>> relevant folks.
>> 
>> TTFN - Guy

Re: Anyone have any info on the obscure MX11 PDP-11 option?

[Guy Sotomayor Jr via cctalk]

One place to look and see if there was anything, is to look for any hardware 
information
about C.MMP at CMU.  Since C. had a mix of modified 11/20s and 11/40s, there 
*may*
be some information on what they did.

Unfortunately I don’t think it would map directly because C. had (as I recall) 
1.2MW of
memory off of the cross point switch.  It was probably capable of more, but I 
know at
the time I was doing stuff on C., it had 1.2MW.

For those not familiar, C.MMP was a 16-way multiprocessor using PDP-11s that ran
an OS called Hydra.  As far as I remember, the individual 11’s had 8K of local 
memory
and everything else was accessible through the memory off of the cross-point 
switch
(basically think of it as 16-port memory).  The cross point switch was pretty 
spectacular
since there were LEDs at each “intersection” (processor and memory) for a total 
of
256 LEDs (in a 16 x 16 array).  The LED lit when a processor was accessing a 
particular
memory region.  It made for some spectacular light shows!

TTFN - Guy

> On Jun 24, 2019, at 1:38 PM, Noel Chiappa via cctalk  
> wrote:
> 
> While I asking on the TUHS list about the KS11, someone mentioned the MX11
> Memory Extension Option, described as "enabl[ing] the usage of 128 KW memory
> (18-bit addressing range) ... developed by the Digital CSS (Computer Special
> Systems)".
> 
> I'm not familiar with this, and I couldn't find anything about it. (It's not
> even in the Spare Modules Handbook, but then again, neither is the KS11 -
> although the KT11-B is). Some early UNIBUS device address lists (e.g. the '72
> "peripherals and interfacing handbook") list up to six, from #1 at 777600-06
> to #6 at 777650-56.
> 
> I can _guess_ what it did, from the description above (e.g. maps an 8KB block,
> since there can be up to 6), but I was wondering if anyone had any hard data;
> e.g. memories based on using one BITD, etc, etc.
> 
> Even a high level description (e.g. 'sat on the UNIBUS between the CPU and
> extra memory, and mapped a fixed block of low UNIBUS address space to a block
> controlled by a register') would be an improvement on what we have now, which
> is basically nothing.
> 
>   Noel

Re: Abandoned FACOM system in Italy?

[Guy Sotomayor Jr via cctalk]

> On May 29, 2019, at 8:00 AM, Al Kossow via cctalk  
> wrote:
> 
> 
> 
> On 5/28/19 7:39 PM, Evan Linwood via cctalk wrote:
> 
>> hopefully someone takes an interest!
>> 
> 
> considering 3178 keyboards are over $1000 on eBay, I expect the keyboard 
> collectors to take every keyboard that
> is there
> 

3278 keyboards.  ;-)

I’d be happy with a couple of sets of keycaps to turn my 3278 data entry 
keyboards into 3278 typewriter keyboards.  ;-)

TTFN - Guy

Re: DEC disc pack inspection unit on eBay

[Guy Sotomayor Jr via cctalk]

From looking at the accessories and the spindle, I believe that this is for 
examining multi-platter packs such has those for RP03/4 and RP06 and the like.  
It’s a useful find for folks who have those drives and packs and wish to 
actually use them.  ;-)

TTFN - Guy

> On May 10, 2019, at 8:59 AM, W2HX via cctalk  wrote:
> 
> What is this used for? RL02's or something? and what does it do?
> 
> From: cctalk  on behalf of Bob Rosenbloom via 
> cctalk 
> Sent: Friday, May 10, 2019 1:49 AM
> To: cctalk
> Subject: DEC disc pack inspection unit on eBay
> 
> There's a mis-categorized  disk pack inspection unit up on eBay. Might
> be of use to someone.
> 
> https://www.ebay.com/itm/Early-Digital-Equiment-Corp-DEC-Portable-Briefcase-Paper-Tape-Reader-Punch/303149714641?hash=item4695218cd1:g:ks8AAOSwEVZc1PQo
> 
> Bob
> 
> --
> Vintage computers and electronics
> www.dvq.com
> www.tekmuseum.com
> www.decmuseum.org
> 

Re: Control Console, but not PDP-10

[Guy Sotomayor Jr via cctalk]

You should talk to Carl as he’s created (or far along in the process) of a DSKY 
to interface to
an actual AGC that’s being restored (there are a number of videos on-line of 
the restoration
effort…mostly done by converting a hotel room into a lab).

TTFN - Guy

> On Apr 11, 2019, at 10:59 PM, Ethan Dicks via cctalk  
> wrote:
> 
> On Fri, Apr 12, 2019 at 1:23 AM Paul Birkel via cctalk
>  wrote:
>> Now consider a DSKY.  Currently at $27,500.00.  Auction estimate: $60,000+
> 
> I'd love to have a DSKY to fiddle around on, just for kicks, but my
> budget for a replica is a tiny fraction of that...
> 
> -ethan

Re: Another DEC UNIBUS signal adapter: UniProbe

[Guy Sotomayor Jr via cctalk]

Did you happen to take a look at my UA11?  It’s different in that it goes into 
an SPC slot.

TTFN - Guy

> On Feb 26, 2019, at 11:07 PM, Jörg Hoppe via cctech  
> wrote:
> 
> Hi,
> 
> most people dealing seriously with older PDP-11s have found means to monitor 
> the UNIBUS traffic.
> My latest approach is www.retrocmp.com/tools/uniprobe
> UniProbe is a M9302 terminator, a LED display, a probe for logic analyzer.
> It can be mounted in Standard or Modified UNIBUS sockets.
> 
> I'm ordering a batch of PCBs in a few days and will show this and other stuff 
> (UniBone, BlinkenBone) at VCFPNW in Seattle.
> https://vcfed.org/wp/festivals/vintage-computer-festival-pacific-northwest/
> 
> best regards,
> Joerg
> 

Re: BASIC for HP 1000, 21xx series

[Guy Sotomayor Jr via cctalk]

I’m glad I had kept it around.  I purchased a copy of the listing directly from 
HP while I was in High School
so that I could study how it worked and “hack” on it to make some changes.

I had kept the listing in a special binder.  After college I had misplaced the 
binder and thought it was lost.
During one of my moves (around 2006(or so) I discovered that I still had it.  I 
lent it to James Markevitch
(another list member) sometime after that who scanned it and OCR’d it and made 
it available to the 
community.

The binder containing the source listing sits prominently on one of the shelves 
in my office.  It is also
loaded into the core of my 2116C that I run from time to time.  ;-)

TTFN - Guy

> On Feb 24, 2019, at 10:18 AM, Brent Hilpert via cctalk 
>  wrote:
> 
> On 2019-Feb-24, at 2:03 AM, GerardCJAT via cctalk wrote:
> 
>> Back in ''70, sometimes we were running "basic" BASIC ( NOT Time sharing ) 
>> on 2116B, 2100A, just for FUN.
>> 
>> Is there some copy still around ??
>> 
>> I had a look in Google, Bitsavers, HPmuseum, with NO success.
>> 
>> Thank for help and/or advise.
> 
> 
> This is my own writeup about it, including assembler source and loader files, 
> but as noted there it's Guy Sotomayor (list member)
> that deserves the thanks for keeping it around and making it available:
> 
>   http://madrona.ca/e/HP21xx/software/hpbasic/index.html
> 
> The source files are also available on bitsavers, link included on above 
> page. 
> 

Re: 11/70 - original or 570 model more desirable?

[Guy Sotomayor Jr via cctalk]

I have both (though the H960 variant needs restoration).

I actually find that the corporate blue cabinets to be easier to deal with. 
One aspect is that it’s a “package” rather than multiple H960 racks.  Why
is that important?  Because the corporate cabinets did nice things like
provide cable runs to lay the various cables in so that they’re neat and
tidy.  Yes, it can be done with the H960 packaging but it’s more work as
it’s not already provided.  ;-)

TTFN - Guy


> On Jan 31, 2019, at 1:33 AM, Pontus Pihlgren via cctalk 
>  wrote:
> 
> On Wed, Jan 30, 2019 at 10:49:12PM -0500, Bill Degnan via cctech wrote:
>> Random question
>> would you prefer having, if you had to pick only one, the original PDP
>> 11/70 or the newer "blue cabinets" PDP 11/70, assuming both were complete
>> configurations with racks of storage etc as they would have been sold, more
>> or less.
>> 
>> Assume space and power are not issues, consider just the machine itself.
> 
> Luckily for me the local computer club has both the maroon model in a 
> H960 as well as the blue corporate cab model. So while space is a bit 
> tight I don't have to consider it :)
> 
> I have spent more time with the H960, so I might be biased. But ignoring 
> any subjective preference for color I do prefer the H960 simply because 
> it is easier to work with, less bulky metal panes to remove in order to 
> gain access to the CPU. And it is easier to move arround.
> 
> This seems like a very pleasant problem to have, are you facing the 
> choice?
> 
> /P

Re: IBM in TX

[Guy Sotomayor Jr via cctalk]

> On Jan 11, 2019, at 9:58 AM, William Donzelli via cctalk 
>  wrote:
> 
>> Looks like the "Mainframe" is an IBM Series/1 which is not a Mainframe, and
>> I would say has limited appeal to collectors as there are few resources out
>> there as the software is all fully licenced so its had to make legal copies.
> 
> It does not help that the OS software also sucks.

There once was a port of Unix to the Series/1.  Long story but the Unix center
of competency for IBM was first at Boca Raton (with Series/1 as the platform).
At the time AT offered to sell IBM the full rights to Unix and AT would get
out of the Unix biz.  Then there was a political battle between Boca Raton and
Austin.  Boca lost and the rest as they say is history.  As part of that *all* 
(as in
every shred of)  Unix for the Series/1 was destroyed (with IBM security looking
on to make sure nothing was missed).

TTFN - Guy

Re: OT? Upper limits of FSB

[Guy Sotomayor Jr via cctalk]

Some architectures (I’m thinking of the latest Intel CPUs) have a small loop 
cache
whose aim is to keep a loop entirely within that cache.  That cache operates at 
the
full speed of the instruction fetch/execute (actually I think it keeps the 
decoded uOps)
cycles (e.g. you can’t go faster).  L1 caches impose a penalty and of course 
there is
the instruction decode time as well both of which are avoided.

TTFN - Guy

> On Jan 8, 2019, at 2:43 PM, Chuck Guzis via cctalk  
> wrote:
> 
> On 1/8/19 1:23 PM, Tapley, Mark via cctalk wrote:
> 
>> Why so (why surprising, I mean)? Understood an unrolled loop executes
>> faster...
> 
> That can't always be true, can it?
> 
> I'm thinking of an architecture where the instruction cache is slow to
> fill and multiple overlapping operations are involved and branch
> prediction assumes a branch taken.  I'd say it was very close in that case.
> 
> --Chuck
> 

Re: Bogus "account hacked" message

[Guy Sotomayor Jr via cctalk]

I’ve been getting those messages for a few months now and nothing bad has 
happened yet.  ;-)

TTFN - Guy

> On Jan 8, 2019, at 12:03 PM, Peter Coghlan via cctalk  
> wrote:
> 
> 
> About two hours ago, I received an email to the address I only use for
> cctech/cctalk.
> 
> It claimed my email account had been hacked and threatened all sorts of
> dire consequences if I didn't deposit $1000 in bitcoins in some place within
> 48 hours.
> 
> I am 100% certain that the claims in the message are completely bogus and
> none of the threats will be carried out.
> 
> It is likely that email addresses belonging to other list members are also
> to be found wherever my email address was scraped from so I just wanted to
> warn other list members about this scam in case they receive similar emails.
> 
> (I received the scam email directly, not via the cctech listserver).
> 
> Regards,
> Peter Coghlan.

Re: off topic - capatob - saratov2 computer Russsian pdp8

[Guy Sotomayor Jr via cctalk]

> On Jan 6, 2019, at 6:10 PM, Jon Elson via cctalk  
> wrote:
> 
> On 01/06/2019 01:29 PM, Bob Smith via cctalk wrote:
>> Sorry, thanks for playing but
>> Actually half of a WORD is a BYTE, whatever the numerical length is.
>> Ready for this,half of a BYTE is a NIBBLE.
> Well, no.  On 32-bit machines such as IBM 360, VAX, etc. half a 32-bit word 
> is a halfword,
> the fullword is equal to FOUR bytes.  On a 360/65 and above, the memory word 
> was 64 bits, or a double-word, so half that was a fullword.  Just makes it 
> more confusing.

No it doesn’t.  The 360/65 was still a 32-bit processor (as defined by the 
ISA).  It makes no difference what the width to memory was.  Wider memory is 
only to improve the bandwidth to memory.  That’s like saying the current Intel 
ixxx CPUs (which are 64-bit ISA) are “confusing” because the width to memory is 
256-bits.

TTFN - Guy

Re: off topic - capatob - saratov2 computer Russsian pdp8? HELP

[Guy Sotomayor Jr via cctalk]

I think it’s also telling that the IETF uses the term octet in all of the 
specifications to
refer to 8-bit sized data.  As “byte” (from older machines) could be anything 
and is
thus somewhat ambiguous.

It *may* have been the IBM 360 that started the trend of Byte == 8-bits as the 
360’s
memory (in IBM’s terms) was byte addressable and the instructions for accessing
them were “byte” instructions (as opposed to half-word and word instructions).

TTFN - Guy

> On Jan 6, 2019, at 10:19 AM, Noel Chiappa via cctalk  
> wrote:
> 
>> From: Grant Taylor
> 
>> Is "byte" the correct term for 6-bits?  I thought a "byte" had always 
>> been 8-bits.
> 
> I don't claim wide familiary with architectural jargon from the early days,
> but the PDP-10 at least (I don't know about other prominent 36-bit machines
> such as the IBM 7094/etc, and the GE 635/645) supported 'bytes' of any size,
> with 'byte pointers' used in a couple of instructions which could extract and
> deposit 'bytes' from a word; the pointers specified the starting bit, and the
> width of the 'byte'. These were used for both SIXBIT (an early character
> encoding), and ASCII (7-bit bytes, 5 per word, with one bit left over).
> 
>> I would have blindly substituted "word" in place of "byte" except for
>> the fact that you subsequently say "12-bit words". I don't know if
>> "words" is parallel on purpose, as in representing a quantity of two
>> 6-bit word.
> 
> I think 'word' was usually used to describe the instruction size (although
> some machines also supported 'half-word' instructions), and also the
> machine's 'ordinary' length - e.g. for the accumulator(s), the quantum of
> data transfer to/from memory, etc. Not necessarily memory addresses, mind -
> on the PDP-10, those were 18 bits (i.e. half-word) - although the smallest
> thing _named_ by a memory addresses was usually a word.
> 
>   Noel

Re: Microcode, which is a no-go for modern designs

[Guy Sotomayor Jr via cctalk]

> On Jan 2, 2019, at 10:22 AM, Chuck Guzis via cctalk  
> wrote:
> 
> On 1/2/19 8:02 AM, Jon Elson via cctalk wrote:
> 
>> Random logic instruction decode was a REAL issue in about 1960 - 1965,
>> when computers were built with discrete transistors.  The IBM 7092, for
>> instance, had 55,000 transistors on 11,000 circuit boards.  I don't know
>> how much of that was instruction decode, but I'll guess that a fair bit
>> was.  The IBM 360's benefited from microcode, allowing them to have a
>> much more complex and orthogonal instruction set with less logic.
>> 
>> But, once ICs were available, the control logic was less of a problem. 
>> But, microcode still made sense, as memory was so slow that performance
>> was dictated by memory cycle time, and the microced did not slow the
>> system down.  Once fast cache became standard, then eliminating
>> performance bottlenecks became important.  And, once we went from lots
>> of SSI chips to implement a CPU to one big chip, then it was possible to
>> implement the control logic within the CPU chip efficiently.
> 
> I don't know--"microcode" in today's world is a very slippery term.   If
> you're talking about vertical microcode, then I'm inclined to agree with
> you.  But even ARM, which is held up as the golden example of
> microcode-less CPU design, is programmed via HDL, which is then compiled
> into a hardware design, at least in instruction decoding. So ARM is a
> programmed implementation.   I suspect that if x86 microcode were to be
> written out in HDL and compiled, Intel could make the same claim.
> 
> I think of it as being akin to "interpreted" vs. "compiled"
> languages--the boundary can be rather fuzzy (e.g. "tokenizing",
> "p-code", "incremental compilation"... etc.)
> 

Remember that ARM licenses it’s ISA as well as implementations.
Some ARM licenses, do their own implementations and those *are*
microcoded.

There are a number of reasons for doing micro-code and a number
of architectures use it especially if the micro-code can be “patched”
(which AFAIK they all do now) to allow for fixing “bugs” once the
chip has been released.  If the bug is severe enough (remember the
DIV bug in the early 80286?) to have a recall done then the overhead
of having patchable micro-code will pay for itself many fold.

It is also important to note, that today’s CPUs are not just a bare
CPU implementing an ISA.  They are embedded in an SoC with
potentially many other micro-controllers/CPUs that are not visible
to the programmer and those are all “micro-coded” and control
various aspects of the SoC.  The last SoC that I worked on had
(in addition to the 8 ARM application CPUs which are micro-coded
BTW) has over 12 other micro-controllers (mostly ARM R5s)and 
4 VLIW DSPs (not to mention several megabytes of SRAM that
is outside of the various caches).  After all you have to do something
with 7 *billion* transistors.  ;-)

Also, recall that there are different forms of micro-code: horizontal
and vertical.  I think that IBM (in the S/360, S/370, S/390, z/Series)
uses the term micro-code for horizontal micro-code and millicode
for vertical microcode.

TTFN - Guy

Re: Motorola M88K books & user manuals (looking for)

[Guy Sotomayor Jr via cctalk]

> On Jan 1, 2019, at 2:35 PM, Carlo Pisani via cctalk  
> wrote:
> 
>> I was never a fan of RISC architecture as does not fit the standard high
>> level language model. Everybody wants a 1 pass compiler, thus the RISC
>> model. If you are doing your own RISC model, you might consider a model
>> that supports Effective addressing better since we have got the point
>> where fetching the data is taking longer than processing it.
> 
> yup. I am a 68k programmer so I know what you mean.
> the 68k is more comfortable to be programmed in assembly, and even the
> EA modes (especially in the 68020 and CPU32) help a lot.
> 
> unfortunately, the 68K is very complex to be designed, and the first
> 68020 used microcode, which is a no-go for modern designs.

Umm.  Says who?  Intel x86 CPUs makes *heavy* use of microcode.  So do a number
of other processors (IBM S/370, et al).  The ISAs may be old but I would
argue that in both examples, the underlying designs are *very* modern.

TTFN - Guy

Re: Motorola M88K books & user manuals (looking for)

[Guy Sotomayor Jr via cctalk]

> On Jan 1, 2019, at 2:00 PM, ben via cctalk  wrote:
> 
> On 1/1/2019 8:58 AM, Carlo Pisani via cctalk wrote:
>> hi
>> on DTB we are designing a RISC-ish CPU, code name "Arise-v2"(1).
>> We are using the MIPS R2K and the RISC-V as the reference.
>> In the end, it will be implemented in HDL -> FPGA.
>> The page on DTB is related to a software emulator (written in C) for
>> the whole system. CPU + RAM + ROM + UART, etc. so we can test and our
>> ISA more comfortably.
>> As a second reference, I'd like to consider the first Motorola RISC:
>> 88K, which is very elegant and neat ISA; unfortunately, I have
>> difficulties at finding user manuals and books about it.
>> If someone wants to sell me a copy, it will be appreciated!
>> Thanks and happy new year!
> 
> I was never a fan of RISC architecture as does not fit the standard high 
> level language model. Everybody wants a 1 pass compiler, thus the RISC model. 
> If you are doing your own RISC model, you might consider a model
> that supports Effective addressing better since we have got the point
> where fetching the data is taking longer than processing it.

Huh?  I don’t understand the 1 pass compiler statement requiring RISC.  I was 
doing 1 pass compilers
in the mid-to-late 70’s (well before RISC).  So I’m not sure what you’re 
talking about.  It also depends
upon what you mean by “1 pass”.  Most compilers nowadays make only one pass 
over the source but
will make multiple passes over the intermediate form before finally generating 
code (even then it may
make another pass over the resulting generated code for peep-hole optimizations.

RISC is actually nice for a compiler because it’s simple and fairly regular 
(hard to actually generate code
automatically for complex instructions) and RISC has a large number of 
registers.  However, modern
CPUs are all out-of-order execution with register renaming with ridiculous 
numbers of registers (I think
current Intel Core x CPUs have 192+ registers for register renaming where the 
visible number of registers
is 8).  It also allows for speculative execution (following multiple paths 
through the code until the data
required for the various decision points is finally available).

> 
> The other thought is the pipeline seems has too high speed of a clock,
> what is the use a fast clock, if you got one or two gates of logic between 
> your clocks. Gate and line driving speed ratios  remind me of the Vacuum tube 
> era of computing.

Deep pipelines are needed to get clock speeds up so that timing can be met.  
The problem with deep
pipelines is that when any sort of exception (interrupts, etc) happen, there’s 
a lot of state that gets flushed
and then restarted when the exception handling completes.

Pipelines (especially if they’re not fixed depth for all operations) means that 
simple operations (those that
require a minimum number of pipeline stages) can be completed quickly where as 
complex operations
that require either a lot of logic or time to complete can be broken up in to 
multiple stages.  This allows
a higher clock rate and allows for the simple operations to be completed more 
quickly than if there was
a very shallow pipeline.

TTFN - Guy

Re: More old stuff incoming

[Guy Sotomayor Jr via cctalk]

Having worked at IBM “in the day”, the “official” reason (near as I could tell) 
was that IBM didn’t want to anthropomorphise computers.  So it was never 
“memory”, it was always “storage”.  So we didn’t have RAM or ROM, we had 
storage or ROS.  Disks were called DASD.  Main boards were called “planars”.

TTFN - Guy

> On Dec 19, 2018, at 1:16 PM, Fred Cisin via cctalk  
> wrote:
> 
> On Wed, 19 Dec 2018, Grant Taylor via cctalk wrote:
>> I always liked the PS/2 cases.  Just about every one I've seen is tool less 
>> down to, and sometimes including, the system planar (as IBM called it).
> 
> Typically unreliable source (my uncle who worked for IBM) said that the 
> reason that they REFUSED to call it a "motherboard" was due to some TV news 
> broadcasts from Merritt College where Black Panthers were saying "UP AGAINST 
> THE WALL, MOTHER!"
> I was there.  They said 'motherfucker", not "mother".
> (there was a New Yorker? cartoon with an elderly woman commenting that she 
> loved how they kept saying "mother")
> Nevertheless, s'posedly it caused IBM to choose a different name.
> 

Re: Core memory emulator using non volatile ram.

[Guy Sotomayor Jr via cctalk]

> On Dec 17, 2018, at 10:52 AM, Noel Chiappa via cctalk  
> wrote:
> 
>> From: Paul Koning
> 
>> For that matter, core memory details such as destructive read weren't
>> visible to the CPU
> 
> Umm, not quite. If you'd said 'core memory details such as destructive read
> weren't visible to the _program_', you'd have been 100% correct.
> 
> But as I suspect you know, just overlooked, most (all?) of the -11 CPU's do
> use 'read-modify-write' cycles on the bus (DATIP in UNIBUS terms, DATIO in
> QBUS) where possible precisely for the benefit of core memory with its
> destructive readout. (And there's some hair for interlocking the multiple
> CPU's on the -11/74 which I don't recall off the top of my head.)
> 
> And I have a vague memory of something similar on other early DEC machines;
> probably some -8 models.

But it does *no* harm if the underlying memory does *not* have a destructive
read-out.  Otherwise all of those (even DEC branded) MOS memory boards
wouldn’t work.  ;-)

The DATIP and friends were an optimization implemented in the bus protocol
to allow for it to take advantage of the behavior of core.  However, nothing
breaks if the memory doesn’t implement a destructive read-out.

TTFN - Guy

Re: Core memory emulator using non volatile ram.

[Guy Sotomayor Jr via cctalk]

> On Dec 16, 2018, at 10:40 PM, Chuck Guzis via cctalk  
> wrote:
> 
> On 12/16/18 11:21 AM, Paul Koning wrote:
> 
>> If you simply want non-volatile memory, the obvious answer is SRAM with 
>> battery backup and a small FPGA to do the interfacing.
> 
> I proposed nvRAM - CMOS SRAM backed by cell-for-cell flash.  Loads SRAM
> from flash on power-up and stores into flash at power-down.  All that's
> needed is a capacitor to extend the power-down cycle a bit.
> 
> Very fast, available in 8 to 32-bit wide architectures, up to 16Mbit per
> package.
> 
> Claims to be guaranteed for 1M power cycles and doesn't require a battery.

Except it is *much* more expensive than MRAM.  32x8 NVSRAM is $18.50 in qty 1 
from Digikey.
A 64Kx16 MRAM is $11.84 in qty 1 from Digikey.  MRAM requires no additional 
circuitry so that
also reduces the overall cost (and has unlimited write endurance).

If it sounds like I’m harping on MRAM, maybe I am.  I’ve looked at the various 
technologies in
detail (what’s available, cost, interfacing, etc, etc) for years and for 
anything that requires
non-volatility, MRAM wins until you get into seriously large sizes at which 
point you need to
go to FLASH for economics.

TTFN - Guy

Re: Core memory emulator using non volatile ram.

[Guy Sotomayor Jr via cctalk]

> On Dec 16, 2018, at 8:21 PM, allison via cctech  wrote:
> 
> On 12/15/2018 03:51 PM, Jon Elson via cctech wrote:
>> On 12/15/2018 02:45 PM, Anders Nelson via cctalk wrote:
>>> Serial flash has an endurance between 10K-100K writes per cell so I
>>> think
>>> that would break down quickly. Wear-leveling on a serial device would be
>>> very slow...
>>> 
>>> 
>> If you intend to use it as main core memory on an old CPU, it will
>> perform VERY poorly, as these memories need to erase a page at a time,
>> and the erase takes milliseconds.  So, writing ONE SINGLE word at a
>> time would invoke an erase cycle each time, slowing it to 1/1000 or
>> worse the speed of the original core memory.  Also, most old CPUs have
>> the memory timing built into the CPU, and can't handle a memory that
>> says "wait".
>> 
>> Jon
> The only place where Flash or similar tech fits is applied to the mass
> storage problem such as replicating
> a RF/DF32 multihead disk.
> 
> The cycle life is a limiting factor for things like swapping drums/disks
> but for something that's
> read mostly its ok.

Frankly even in those applications (RF11/DF32) I’d use MRAM (available in 2Mx8)
rather than FLASH because (a) it’s byte addressable (b) it has unlimited write 
endurance
(c) it looks like SRAM so there’s no erase cycle (or blocks) to deal with so it 
makes
the hardware easier (e.g. it should be possible to implement one of those 
controllers
just with logic and not require a microprocessor).

BTW, that’s what I use for the emulators that I’m working on (when I have 
time…in
short supply at the moment).

I also use them even when I do use FLASH as I can use it as a buffer/cache to 
help
absorb some of the write/overwrite cycles and to be able to handle 
(non-volatile) full
FLASH block operations and for wear leveling (tracking and block remapping).  
That
way I don’t have to deal with a PMIC and battery.  MRAMs also have a >20 year 
data
retention as well (something you don’t have with a battery…if the battery dies, 
you
loose everything).

TTFN - Guy

Re: Core memory emulator using non volatile ram.

[Guy Sotomayor Jr via cctalk]

> On Dec 15, 2018, at 7:09 PM, allison via cctech  wrote:
> 
> On 12/15/2018 01:01 PM, Guy Sotomayor Jr via cctech wrote:
>> FRAM or MRAM.  I make extensive use of them in my projects.
>> 
>> Everspin has a few (all SMT and 3.3v).  As I recall they run ~$20/ea for 4Mb 
>> (512K x 8 or 256K x 16).
>> 
>> TTFN - Guy
>> 
>>> On Dec 15, 2018, at 1:22 AM, Rod G8DGR via cctalk  
>>> wrote:
>>> 
>>> I have an idea to produce an MM-8  clone using RAM that acts like core when 
>>> turned off.
>>> Can anybody suggest a chip that will do this?
>>> 
>>> Rod Smallwood
>>> 
>>> 
>   Flash, EEprom and Magnetic FRAM and MRAM) types
> have many unacceptable
> properties for a random access read write memory. 

I think you’re mistaken about FRAM and MRAM.  They are byte oriented devices
and are designed to replace SRAM + battery.  Which in my mind makes them
preferable as they reduce parts count.  The current MRAM has unlimited write
endurance (same as SRAM) and depending upon the part is 35-55ns access/cycle
time.  FRAM has a similar access time but requires an internal restore so it’s 
cycle
time is about 2x (one of the reasons I prefer MRAM now).

TTFN - Guy

Re: Core memory emulator using non volatile ram.

[Guy Sotomayor Jr via cctalk]

> On Dec 15, 2018, at 1:18 PM, Warner Losh via cctalk  
> wrote:
> 
> On Sat, Dec 15, 2018, 1:51 PM Jon Elson via cctalk  wrote:
> 
>> On 12/15/2018 02:45 PM, Anders Nelson via cctalk wrote:
>>> Serial flash has an endurance between 10K-100K writes per cell so I think
>>> that would break down quickly. Wear-leveling on a serial device would be
>>> very slow...
>>> 
>>> 
>> If you intend to use it as main core memory on an old CPU,
>> it will perform VERY poorly, as these memories need to erase
>> a page at a time, and the erase takes milliseconds.  So,
>> writing ONE SINGLE word at a time would invoke an erase
>> cycle each time, slowing it to 1/1000 or worse the speed of
>> the original core memory.  Also, most old CPUs have the
>> memory timing built into the CPU, and can't handle a memory
>> that says "wait".
>> 
> 
> If you paired it with a microcontroller, you might be able to implement a
> log device and then manage to logical to physical translation ala FTLs in
> SSD land... but it would be ugly as heck and you'd still have the stall to
> worry about when you got to the end of the erase block... better
> performance, but maybe beyond a cheap uc…

And my question is why go through all of that pain when an FRAM or MRAM
device can do this with no hackery?

What you’re describing is the very definition of an “impedance mismatch”.
You’re trying to use a block oriented device as a byte device and attempting
to paper over the differences.  I think the end result would be less than
satisfactory in almost every measurable dimension.

TTFN - Guy

Re: Core memory emulator using non volatile ram.

[Guy Sotomayor Jr via cctalk]

> On Dec 15, 2018, at 12:51 PM, Jon Elson via cctalk  
> wrote:
> 
> On 12/15/2018 02:45 PM, Anders Nelson via cctalk wrote:
>> Serial flash has an endurance between 10K-100K writes per cell so I think
>> that would break down quickly. Wear-leveling on a serial device would be
>> very slow...
>> 
>> 
> If you intend to use it as main core memory on an old CPU, it will perform 
> VERY poorly, as these memories need to erase a page at a time, and the erase 
> takes milliseconds.  So, writing ONE SINGLE word at a time would invoke an 
> erase cycle each time, slowing it to 1/1000 or worse the speed of the 
> original core memory.  Also, most old CPUs have the memory timing built into 
> the CPU, and can't handle a memory that says "wait”.

Anything FLASH related is quickly going to have issues because of the limited 
write endurance (1000s of cycles only).  It’s one of the issues that I’m facing 
with the disk emulators that I’m (trying to) work on.  But it works better 
there because of the block nature of disks (and I’m using a larger FLASH than 
necessary to allow for wear leveling plus some really heavy duty error 
correction…had to refresh myself on error coding theory again).

For core replacements, as I’ve said previously, I prefer MRAM.  They’re as fast 
as SRAM (35-55ns) with unlimited write endurance, 10+ year data retention and 
non-volitive (implied by the data retention).  Other than the 3.3v interfaces 
(and SMT…but almost everything is SMT these days) they’re ideal.

TTFN - Guy

Re: Core memory emulator using non volatile ram.

[Guy Sotomayor Jr via cctalk]

FRAM or MRAM.  I make extensive use of them in my projects.

Everspin has a few (all SMT and 3.3v).  As I recall they run ~$20/ea for 4Mb 
(512K x 8 or 256K x 16).

TTFN - Guy

> On Dec 15, 2018, at 1:22 AM, Rod G8DGR via cctalk  
> wrote:
> 
> I have an idea to produce an MM-8  clone using RAM that acts like core when 
> turned off.
> Can anybody suggest a chip that will do this?
> 
> Rod Smallwood
> 
> 
> Sent from Mail for Windows 10
> 

Re: Interesting RK8E fault

[Guy Sotomayor Jr via cctalk]

> On Dec 8, 2018, at 10:36 PM, Josh Dersch  wrote:
> 
> On Sat, Dec 8, 2018 at 10:33 PM Guy Sotomayor Jr  > wrote:
> 
> > On Dec 8, 2018, at 8:50 PM, Josh Dersch via cctalk  > > wrote:
> > 
> > On Sat, Dec 8, 2018 at 7:24 PM Paul Anderson via cctalk <
> > cctalk@classiccmp.org > wrote:
> > 
> >> Are you using the same pack for the 8 and the 11
> >> 
> > 
> > I connected the drive I normally use with my 11/40 to the 8/e for testing
> > to help narrow down where the fault was.
> > I used a 16-sector pack in all cases.
> 
> You should be using 12 sector packs on the 11 and 16 sector packs on the 8.
> 
> I’m actually surprised the 16 sector pack worked on the 11.
> 
> In all cases /pertinent to this discussion/, i.e. with the RK8E attached to 
> both the 11/40's RK05 and the RK05 I've restored for the 8/e. 
> 
> I have 12-sector packs that I normally use with the 11/40.

OK, just so that I understand the problem:

Do you see the problem only on the RK05 you restored for the 8/e and don’t see 
it on the drives from the 11/40?
Or do you see the problem on all the drives when hooked to the 8/e and when 
using a 12 sector pack on the 11/40 you don’t see the problem when using any of 
the drives on the 11/40?
Or do you see the problem on the drive restored for the 8/e but not on the 
drives from the 11/40?

TTFN - Guy

> 
> 
> > 
> > 
> >> 
> >> On Sat, Dec 8, 2018 at 8:54 AM Bill Degnan via cctalk <
> >> cctalk@classiccmp.org >
> >> wrote:
> >> 
> >>> On Sat, Dec 8, 2018, 1:02 AM Josh Dersch via cctalk <
> >> cctalk@classiccmp.org 
> >>> wrote:
> >>> 
>  On Fri, Dec 7, 2018 at 9:58 PM Josh Dersch   > wrote:
>  
> > Hi all --
> > 
> > Finally got all the parts together (and my act together) to actually
> >>> get
> > an RK05 lashed up to my PDP-8/e -- only took a decade or so :).  I
> >>> fixed
>  a
> > few problems with the RK05 and it appears to be behaving very nicely.
> > 
> > The RK8E controller is mostly working properly but fails
> >> interestingly
> > when running the formatter, and during the exerciser -- on cylinder
> >> 128
>  and
> > 192 and very infrequently on cylinder 64 it will get a cylinder
> >>> mismatch
> > when doing the seek.  When running the formatter during the
> >>> verification
> > pass, on cyls 64 and 128 if I retry the read it'll continue without
>  issues,
> > but it's never successful on a retry on cylinder 192.  I tried
> >> hooking
> >>> it
> > to the RK05 in my 11/40 and it exhibits the same behavior, so I'm
>  guessing
> > the drive isn't at fault.  And the error is consistent across packs
> >> (of
> > which I have only two).
> > 
> > Apart from that fault the drive and controller seem to work fine -- I
> > wrote out an OS/8 pack with Adventure on it (or at least the first
> >> 191
> > cylinders of it) and it works without issue.
> > 
> > Reading the RK8E service docs and schematics, the cylinder address
>  compare
> > is done by reusing the CRC buffer, so I suspect the issue is in or
> >>> around
> > there -- the big problem is that debugging it is rather painful since
>  that
> > logic is in the middle board of a three board set, with jumper blocks
> >>> on
> > top -- so bringing it out on an extender isn't an option.  I'm
> >> curious
> >>> if
> > anyone's seen this issue or is so very familiar with the logic that
> >> the
> > fault is obvious.
> > 
> > I suspected the 7496 shift register at E14 which takes in the
> >> cylinder
> > address to be compared w/the header on disk, and I went ahead and
>  replaced
> > it in the hopes that I'd get lucky, but no go.
> > 
> > Anyone have any advice?
> > 
> > Thanks,
> > Josh
> > 
> > 
>  I'll add that during the format/verification the drive seeks properly
> >>> (i.e.
>  it's not missing a step or overstepping), which I've confirmed by
> >>> watching
>  the thing walk through the tracks with the cover off.
>  
>  - Josh
>  
> >>> 
> >>> Partitions as rka0 / rka1?
> >>> B
> >>> 
>  
> >>> 
> >> 
> 

Re: Interesting RK8E fault

[Guy Sotomayor Jr via cctalk]

> On Dec 8, 2018, at 8:50 PM, Josh Dersch via cctalk  
> wrote:
> 
> On Sat, Dec 8, 2018 at 7:24 PM Paul Anderson via cctalk <
> cctalk@classiccmp.org> wrote:
> 
>> Are you using the same pack for the 8 and the 11
>> 
> 
> I connected the drive I normally use with my 11/40 to the 8/e for testing
> to help narrow down where the fault was.
> I used a 16-sector pack in all cases.

You should be using 12 sector packs on the 11 and 16 sector packs on the 8.

I’m actually surprised the 16 sector pack worked on the 11.

TTFN - Guy

> 
> 
>> 
>> On Sat, Dec 8, 2018 at 8:54 AM Bill Degnan via cctalk <
>> cctalk@classiccmp.org>
>> wrote:
>> 
>>> On Sat, Dec 8, 2018, 1:02 AM Josh Dersch via cctalk <
>> cctalk@classiccmp.org
>>> wrote:
>>> 
 On Fri, Dec 7, 2018 at 9:58 PM Josh Dersch  wrote:
 
> Hi all --
> 
> Finally got all the parts together (and my act together) to actually
>>> get
> an RK05 lashed up to my PDP-8/e -- only took a decade or so :).  I
>>> fixed
 a
> few problems with the RK05 and it appears to be behaving very nicely.
> 
> The RK8E controller is mostly working properly but fails
>> interestingly
> when running the formatter, and during the exerciser -- on cylinder
>> 128
 and
> 192 and very infrequently on cylinder 64 it will get a cylinder
>>> mismatch
> when doing the seek.  When running the formatter during the
>>> verification
> pass, on cyls 64 and 128 if I retry the read it'll continue without
 issues,
> but it's never successful on a retry on cylinder 192.  I tried
>> hooking
>>> it
> to the RK05 in my 11/40 and it exhibits the same behavior, so I'm
 guessing
> the drive isn't at fault.  And the error is consistent across packs
>> (of
> which I have only two).
> 
> Apart from that fault the drive and controller seem to work fine -- I
> wrote out an OS/8 pack with Adventure on it (or at least the first
>> 191
> cylinders of it) and it works without issue.
> 
> Reading the RK8E service docs and schematics, the cylinder address
 compare
> is done by reusing the CRC buffer, so I suspect the issue is in or
>>> around
> there -- the big problem is that debugging it is rather painful since
 that
> logic is in the middle board of a three board set, with jumper blocks
>>> on
> top -- so bringing it out on an extender isn't an option.  I'm
>> curious
>>> if
> anyone's seen this issue or is so very familiar with the logic that
>> the
> fault is obvious.
> 
> I suspected the 7496 shift register at E14 which takes in the
>> cylinder
> address to be compared w/the header on disk, and I went ahead and
 replaced
> it in the hopes that I'd get lucky, but no go.
> 
> Anyone have any advice?
> 
> Thanks,
> Josh
> 
> 
 I'll add that during the format/verification the drive seeks properly
>>> (i.e.
 it's not missing a step or overstepping), which I've confirmed by
>>> watching
 the thing walk through the tracks with the cover off.
 
 - Josh
 
>>> 
>>> Partitions as rka0 / rka1?
>>> B
>>> 
 
>>> 
>> 

Re: PDP-8/e

[Guy Sotomayor Jr via cctalk]

I just use ‘cat’.  Seems to work fine.  ;-)

TTFN - Guy

> On Dec 7, 2018, at 4:57 AM, Pete Turnbull via cctalk  
> wrote:
> 
> On 07/12/2018 09:59, Rod G8DGR via cctalk wrote:
> 
>> OK now I need a little help.
>> Does anybody know of a terminal emulation program that will simulate the 
>> reader on an ASR33?
>> I know about   RIM and BIN loaders but how and what to feed them I have long 
>> forgotten
> 
> For a Unix or Linux machine, there's send and rsend, and several other 
> utilities, that you can find at Kevin McQuiggin's web page:
> http://highgate.comm.sfu.ca/pdp8/
> and on mine:
> http://www.dunnington.info/public/PDP-8/
> 
> -- 
> Pete
> Pete Turnbull

Re: i860: Re: modern stuff

[Guy Sotomayor Jr via cctalk]

> On Nov 4, 2018, at 9:37 AM, Todd Goodman via cctalk  
> wrote:
> 
> Yes, a company I was working for OEMed what because IBM's X25Net software and 
> it was ported to their RTIC i960 cards from our own homegrown i960 cards.
> 
> The IBM group we worked with was in La Gaude France but we heard the RTIC 
> cards were developed in Boca Raton, FL.
> 

Yes, the RTIC cards were developed in Boca Raton.  I had a number of friends 
that worked in that group over the years.  They were in a building off of the 
main site that was the last to be closed down when IBM decided to close the 
Boca Raton site down.

TTFN - Guy

Re: IBM Xstation 140?

[Guy Sotomayor Jr via cctalk]

If I recall correctly the Xstation 120 (the first of them) used an 8086 (might 
have been an 80186).  The big issue was that you couldn’t do anything with it 
because what was in ROM/FLASH was only smart enough to be able to TFTP the rest 
of the microcode (not terribly useful if you don’t have the image it wants to 
TFTP).

I think the 140 fixed that (and is somewhat telling from all of the Intel flash 
parts on the board).  But I don’t know what CPU it’s using.  The IBM metal can 
is probably the graphics controller.

TTFN - Guy


> On Nov 1, 2018, at 2:36 PM, Al Kossow via cctalk  
> wrote:
> 
> Wondering if this is an IBM Xstation 140 with token ring
> 
> Wonder what processor it uses..
> 
> https://www.ebay.com/itm/273538296972
> 

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?

[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: 70's computers

[Guy Sotomayor Jr via cctalk]

> On Oct 24, 2018, at 11:22 AM, ben via cctalk  wrote:
> 
> On 10/24/2018 11:57 AM, Al Kossow via cctalk wrote:
>> On 10/24/18 10:53 AM, ben via cctalk wrote:
>>> I have no idea what is in a modern home computer, but I suspect
>>> it still follows the same design of the IBM PC. Single CPU
>>> with segmented memory and bit of DMA here and there.
>> Wow...
>> You are out of touch, aren't you.
> 
> Am I really, every thing is so backwards compatable with the classic
> PC's I don't see much new other than what was hacked on.
> I am dealing with archiecture model here, the real hardware don't matter
> anyway. If it takes X cycles to read memory, it still X cycles where
> memory can be 10uS or 10pS. Ben.
> 
> 
Not so much anymore.  ;-)

None of the current OS’s have anything to do with the segmentation of x86
as it’s all gone as part of the 64-bit ISA.  It’s still there if you use the 
older
legacy modes but those are not used other than booting (and that will go
away soon too).

The lower level architecture is also significantly changed with out-of-order
execution, deep pipelines and large L1/L2/L3 caches.  Even though from
an ISA perspective, the x86 has only a few visible integer registers, with
OOO and register renaming (I think the current CPUs have 192 registers
that they can use for “renaming”) it isn’t much of an issue.

Oh, and I almost forgot.  You always have multiple CPUs (typically 2-8 on most
mobile and desktops…and that’s without hyper-threading enabled).
Servers are typically 16+ per socket and there can be upto 8 sockets
per server without getting esoteric (so for a typical 4 socket server you
can get 64-128 CPUs).

TTFN - Guy

Re: 70's computers

[Guy Sotomayor Jr via cctalk]

> On Oct 23, 2018, at 4:08 PM, Noel Chiappa via cctalk  
> wrote:
> 
>> From: Ben Bfranchuk
> 
>> I just can't find a clean simple design yet. ...
>> The PDP 11 is nice machine, but I am looking  for simpler designs
>> where 16K words is a valid memory size for a OS and small single user 
>> software.
> 
> There was a recent discussion about code density (I forget whether here, or
> on TUHS), and someone mentioned this paper:
> 
>  http://web.eece.maine.edu/~vweaver/papers/iccd09/iccd09_density.pdf
> 
> which shows that for a combo of benchmarks, the PDP-11 had the densest code
> out of all the ones they looked at. (They didn't look at the PDP-8, but I
> suspect that since it's a single-address design, it's almost ceertainly not
> as dense.)
> 
> The PDP-11 dates back to the days of core (it went through several generations
> before DRAM arrived - e.g. the -11/70 originally shipped with core), and given
> core prices, minimizing code size was pretty important - hence the results
> above.
> 
> So if you want to get the most bang out of 16K buck...
> 
> Not the simplest machine to implement, mind - the -8 is a lot simpler. Which
> axis is the most important to you?

For simplicity and reasonable density, you might want to look at J1 (which is
a Forth CPU).  It has been implemented in 300 lines of Verilog and the entire
CPU + 16KB of memory fits in a reasonably sized Spartan 3E FPGA (and you
have space for all of the other “cool” stuff).

Admittedly, you get to write in Forth which may be a minus for some folks.  ;-)

I did write a simulator for it (in Forth of course!) but I’m in the process of 
redoing
it in C so that I can have multiple threads of execution (for the various 
devices I
want to emulate).  For me it was important because I’m using this as the 
controller
in an FPGA so I wanted to have a better debug environment for developing the
code.  ;-)

TTFN - Guy

Re: Microsoft-Paul Allen

[Guy Sotomayor Jr via cctalk]

> On Oct 23, 2018, at 3:30 PM, Jim Manley via cctalk  
> wrote:
> 
> On Tue, Oct 23, 2018 at 12:55 PM Guy Sotomayor Jr  wrote:
> 
>> On Mon, Oct 22, 2018 at 3:59 PM Guy Sotomayor Jr 
>> wrote:
>> 
>>> An (optional) X server (and clients) can be added to the OS (I use them
>>> all the time) but is not part of the base install ...
>>> 
>> 
>> Apple has been using self-customized, optimized-for their-hardware
>> supersets of the VNC protocol (which is X based) for Screen Sharing since
>> early versions of OS X, if not from the beginning, and It's (still) In
>> There (per Prego spaghetti sauce ads) in the latest versions of OS X.
>> 
>> That’s distinct from the X server and apps that are available as a
>> separate download (and I believe that now they point to Xorg).
>> 
> 
> No, it's not.  You don't need any third-party X components to use Screen
> Sharing, and it works across all platforms, in both directions, that have a
> VNC-compatible client and/or server (depending on which direction you're
> looking from, remotely).  I could show you in the source, but, then I'd
> have to kill you, if Apple didn't get to both of us first.  There's what's
> in the public docs and especially marketing (including technical) material,
> and then there's what's actually In There.  It's the sort of stuff marked
> with "COMPANY PROPRIETARY" watermarks that, if you try to scan or run it
> through a photocopier, produces black output due to opto-molecular chemical
> overlays.

You’re not listening.  I said that X and Screen Sharing are separate.  I use 
both all the time.
X on OS X is *not* in any way shape or form using anything from Screen Sharing 
and is
currently sourced from Xorg.

You are also forgetting, that as an ex-Apple employee (working in the kernel) I
did get to see a lot of the source base.

> 
> 
>> BTW, the X server on OS X, interfaces not to the bit-map but instead to the
>>> native OS X display rendering framework.
>>> 
>> 
>> That's not possible, at least when communicating cross-platform, where
>> bitmaps are the only representation.
>> 
>> *sigh*
>> 
> 
> 
> 
> As far as OS X is concerned, X is just another OS X application that wants
>> to render to the screen.  I use it all the time and it works well along
>> side the normal OS X applications which wouldn’t be possible if the X
>> server wrote directly to the HW.
>> 
> 
> That's the case for your add-on X components - that's not how it can be
> done under the covers, but you apparently don't have access to that level.
> Screen Sharing isn't the only function that has this sort of capability, as
> also do 3-D graphics and video - they aren't constrained to the low-speed
> 2-D world for which Display Postscript/PDF, Quartz, etc., were developed.
> Performance is everything in these technologies, and they have their own
> APIs through which the hardware is accessed (the GPU), because going
> through the gobbledy-gook stack that's fine for documents and other
> high-drag data structures is a non-starter for them.

What I’m saying is that the X components render using the native OS X
rendering capabilities and does not access the HW directly.  Go look in
the Xorg sources.

TTFN - Guy

Re: Microsoft-Paul Allen

[Guy Sotomayor Jr via cctalk]

> On Oct 23, 2018, at 11:12 AM, Jim Manley  wrote:
> 
> On Mon, Oct 22, 2018 at 3:59 PM Guy Sotomayor Jr  > wrote:
> An (optional) X server (and clients) can be added to the OS (I use them all 
> the time) but
> is not part of the base install ...
> 
> Wrong.  Apple has been using self-customized, optimized-for their-hardware 
> supersets of the VNC protocol (which is X based) for Screen Sharing since 
> early versions of OS X, if not from the beginning, and It's (still) In There 
> (per Prego spaghetti sauce ads) in the latest versions of OS X.  I do have 
> some first-gen PowerPC systems that I need to see if they power up (ironic 
> name, PowerPC!), let alone boot, and then I'll have to find original OS X 
> boot media ... some of us have actual lives, though, so don't hold your 
> breath!

That’s distinct from the X server and apps that are available as a separate 
download (and I believe that now they point to Xorg).

> 
> BTW, the X server on OS X, interfaces not to the bit-map but instead to the
> native OS X display rendering framework.
> 
> That's not possible, at least when communicating cross-platform, where 
> bitmaps are the only representation.  Projects such as Wayland and Weston are 
> attempting to provide a modern alternative to X that fully supports vector 
> representations (using GPU hardware acceleration), through a protocol and 
> supporting library for a compositing window manager (Wayland) and a 
> compositor reference implementation (Weston).  XWayland implements a 
> compatibility layer to seamlessly run legacy X11 applications on Wayland.  A 
> few years ago, the Raspberry Pi Foundation was funding this effort, in part, 
> but it was too soon then, and I don't know what the statuses of the projects 
> are, at this point, although instructions for building the software for Linux 
> are Out There.  Support for Retina and HiDPI displays is mentioned, but I 
> didn't see anything explicitly about OS X or Windows support in a cursory 
> scan of the associated wikis - I assume they're talking about running 
> Wayland/Weston on Linux using Apple and PC hardware.  GNOME and KDE are fully 
> supported, since that's where development started.

*sigh*

Yes, it is.  Just as there exist X implementations that use the GPU to 
accelerate rendering.  It says *nothing* about the cross platform protocol.  
It’s how the X server communicates with the rendering hardware or in OS X’s 
case the software interface to do the rendering.  As far as OS X is concerned, 
X is just another OS X application that wants to render to the screen.  I use 
it all the time and it works well along side the normal OS X applications which 
wouldn’t be possible if the X server wrote directly to the HW.

TTFN - Guy

Re: Microsoft-Paul Allen

[Guy Sotomayor Jr via cctalk]

Some corrections related to Mach and Apple.

TTFN - Guy

> On Oct 22, 2018, at 2:40 PM, Jim Manley via cctalk  
> wrote:
> 
> 
> 
> BTW, MacOS X is based on Mach, the version of Unix that was designed for
> multiple, closely-coupled processors, and it, too, uses X as a basis for
> its GUI.  

No.  Mach is a microkernel based system that split apart BSD into “kernel”
portions and Unix portions.  It really didn’t have anything to do with SMP as
the premise behind Mach (which was a furthering of Accent) was message
passing between tasks.  I can dig up the original papers if anyone is 
interested.  ;-)

OS X does *not* use X as the basis of its GUI.  It stems from NEXT which
used display postscript (modern OS X uses display PDF).  An (optional)
X server (and clients) can be added to the OS (I use them all the time) but
is not part of the base install which belies the comment of X as the basis of
the GUI.

BTW, the X server on OS X, interfaces not to the bit-map but instead to the
native OS X display rendering framework.

TTFN - Guy

Re: Advice requested on proper disposal of Seagate ST3000DM001 disk drives

[Guy Sotomayor Jr via cctalk]

If I wanted to reduce a drive to slag, I’d just put it in a propane furnace 
(actually the drive would
go into the crucible).  They generate up to 2700F (~1500C) and they’re for 
melting gold, silver, copper,
etc.  So I suspect it would do the job.  ;-)  Plus you’d a nice molten mess 
that you can pour out.

TTFN - Guy


> On Sep 21, 2018, at 9:43 AM, Ed Sharpe via cctalk  
> wrote:
> 
> Hmmm...  OK   take a  giant  sledge and beat the living  hell out  of  it
> 
> 
> Great  physical release and   data  pretty well   toast... and the sound 
> is glorious!
>  
> And  besides you get  some  exercise!
>  
> Ed#
>  
>  
>  
>  
>  
>  
> In a message dated 9/21/2018 9:20:25 AM US Mountain Standard Time, 
> cctalk@classiccmp.org writes:
> 
>  
> On Fri, Sep 21, 2018 at 6:04 AM, Bill Gunshannon via cctalk <
> 
> cctalk@classiccmp.org> wrote:
> 
>> Or just throw it in the garbage.
> 
> 
> That's way too good for these 

Re: ISO 70's and 80's coax and twinax terminal docs/brochures

[Guy Sotomayor Jr via cctalk]

I just wanted to send this privately.

I have a number of 3278/79 keyboards that I could *loan* you (as I have exactly 
the
number of keyboards to match terminals) for documenting.

The problem is getting together.  I was just down in Santa Clara a couple of 
weeks ago
for work and I probably won’t be down again until either late October or early 
November.

My most common keyboard is the “data entry keyboard” but I do have a typewriter 
style
keyboard for my 3279 and the operator keyboard for the console on my 4331.

TTFN - Guy


> On Sep 19, 2018, at 9:35 AM, Al Kossow via cctalk  
> wrote:
> 
> 
> 
> On 9/19/18 9:03 AM, Alexandre Souza wrote:
>> time for a ps2-to-3274-terminal-adapter?
> 
> yes, or at least get all the 25-pin parallel keyboard protocols documented
> before a keyboard in thousands of dollars instead of hundreds.
> 
> Bob Rosenbloom let me borrow a 3178 keyboard to document.
> 
> I have also been thinking about something like the 3megabit ethernet cape 
> that Ken Schrriff did
> https://github.com/shirriff/alto-ethernet-interface except it would replace a 
> 3174.
> 3174-23R with ethernet option is complete overkill for a situation where you 
> want to attach
> one coax terminal to ethernet, like most people wanting a real console on 
> Hercules want to do.
> 

Re: ISO 70's and 80's coax and twinax terminal docs/brochures

[Guy Sotomayor Jr via cctalk]

> On Sep 19, 2018, at 9:35 AM, Al Kossow via cctalk  
> wrote:
> 
> 
> 
> On 9/19/18 9:03 AM, Alexandre Souza wrote:
>> time for a ps2-to-3274-terminal-adapter?
> 
> yes, or at least get all the 25-pin parallel keyboard protocols documented
> before a keyboard in thousands of dollars instead of hundreds.

Sorry, it’s already gotten bad.  There are a couple of 3278/9 keyboards on eBay
at the moment that have *insane* prices.

> 
> Bob Rosenbloom let me borrow a 3178 keyboard to document.

Hmm.  Isn’t that just a standard IBM 5 pin DIN keyboard?  That’s all I have for 
my
3179s and I thought that the 3178 had the same keyboard (but I could be 
mistaken…
hey, it could happen!).

> 
> I have also been thinking about something like the 3megabit ethernet cape 
> that Ken Schrriff did
> https://github.com/shirriff/alto-ethernet-interface except it would replace a 
> 3174.
> 3174-23R with ethernet option is complete overkill for a situation where you 
> want to attach
> one coax terminal to ethernet, like most people wanting a real console on 
> Hercules want to do.

Count me in!

TTFN - Guy

Re: The Ultimate Apollo Guidance Computer Talk

[Guy Sotomayor Jr via cctalk]

> On Sep 19, 2018, at 1:24 AM, CuriousMarc via cctalk  
> wrote:
> 
> 
>> On Sep 18, 2018, at 8:44 PM, Steve Malikoff via cctalk 
>>  wrote:
>> 
>> Haven't watched this video yet but am keen to do so as "ultimate" is a bold 
>> claim to make.
>> 
> 
> This an outstanding presentation. The bold claim is actually somewhat 
> justified…

Yes, they did a good job.

I worked with Michael when we were both at Apple (a really good/smart guy).  At 
the time
he was focused on 6502 related stuff and we had many discussions about old 
hardware.

TTFN - Guy

Re: I finally got to see a LMI Lambda in real life...

[Guy Sotomayor Jr via cctalk]

I finally dug up the link to the CADR stuff (there’s probably some other useful 
links there as well).
http://www.unlambda.com/index.php?n=Main.Symbolics 
<http://www.unlambda.com/index.php?n=Main.Symbolics>.

The CADR emulator and all of the microcode and OS (disk) images are in the 
download
directory.  Even if you don’t use the emulator, if you ever want to get the 
CADR running again
you’ll need the microcode and OS images.

TTFN - Guy

> On Sep 14, 2018, at 3:10 PM, Guy Sotomayor Jr via cctalk 
>  wrote:
> 
> Without the console doing much with the CADR is going to be tough.  Not 
> having the disk isn’t too terrible as the basic contents (uCode and system 
> code) are available.  There’s even an emulator for the CADR though I don’t 
> have the link handy at the moment.  Ping me if you have trouble finding it.
> 
> Good luck with the LMIs!  
> 
> I have several Symbolics machines (3620, 2 3640, 3650) that are more or less 
> complete.  The 3620 works (at least the last time I powered it on it did…not 
> enough time to “play”).  At least one of the 3640s has shown signs of life 
> and the 3650  (which came back to me after a vacation of 10 years or so) 
> needs some “love” but it’ll be worth it because in addition to the normal 
> console it has the “good” color frame buffer!  The biggest issue for me is 
> consoles.  I have 3 but one is in need of repair.
> 
> TTFN - Guy
> 
>> On Sep 14, 2018, at 12:55 PM, Daniel Seagraves via cctalk 
>>  wrote:
>> 
>> Two of them in fact, and a CADR - In my garage, no less!
>> 
>> The Lambdas are in bad shape, and the CADR is in very bad shape and missing 
>> its console and disk. It’s going to take awhile to get them cleaned up and 
>> see how viable they are.
>> 
>> On the plus side, I got a some spares and debugging equipment, and I have a 
>> working PDP-11 to debug the CADR with if it gets that far, so there’s a good 
>> chance I should be able to get at least one working.
>> 
>> I’ll post more as things develop.
>> 
> 

Re: I finally got to see a LMI Lambda in real life...

[Guy Sotomayor Jr via cctalk]

Without the console doing much with the CADR is going to be tough.  Not having 
the disk isn’t too terrible as the basic contents (uCode and system code) are 
available.  There’s even an emulator for the CADR though I don’t have the link 
handy at the moment.  Ping me if you have trouble finding it.

Good luck with the LMIs!  

I have several Symbolics machines (3620, 2 3640, 3650) that are more or less 
complete.  The 3620 works (at least the last time I powered it on it did…not 
enough time to “play”).  At least one of the 3640s has shown signs of life and 
the 3650  (which came back to me after a vacation of 10 years or so) needs some 
“love” but it’ll be worth it because in addition to the normal console it has 
the “good” color frame buffer!  The biggest issue for me is consoles.  I have 3 
but one is in need of repair.

TTFN - Guy

> On Sep 14, 2018, at 12:55 PM, Daniel Seagraves via cctalk 
>  wrote:
> 
> Two of them in fact, and a CADR - In my garage, no less!
> 
> The Lambdas are in bad shape, and the CADR is in very bad shape and missing 
> its console and disk. It’s going to take awhile to get them cleaned up and 
> see how viable they are.
> 
> On the plus side, I got a some spares and debugging equipment, and I have a 
> working PDP-11 to debug the CADR with if it gets that far, so there’s a good 
> chance I should be able to get at least one working.
> 
> I’ll post more as things develop.
> 

Re: Oddball Terminals (Was: Re: VT100's)

[Guy Sotomayor Jr via cctalk]

> On Sep 7, 2018, at 4:35 PM, Warner Losh  wrote:
> 
> 
> 
> On Fri, Sep 7, 2018 at 5:33 PM Guy Sotomayor Jr via cctalk 
> mailto:cctalk@classiccmp.org>> wrote:
> I also looked at the keyboards on my Symbolics machines, and where I’d like 
> to have the control key is the “rubout” key.  But given that there are no 
> fewer than 5 “shift” keys on the Symbolics keyboard (hyper, super, meta, 
> control, shift…I can’t recall at the moment if symbol is also a “shift” key), 
> it makes a bit of sense to have them all near each other.  ;-)
> 
> I think you forgot the "coke bottle" key :)
> 
> http://www.catb.org/jargon/html/S/space-cadet-keyboard.html 
> <http://www.catb.org/jargon/html/S/space-cadet-keyboard.html>

Yea, I don’t have a space cadet keyboard.  I have new and old Symbolics 
keyboards.  The “new” one is the one pictured on the referenced link.

TTFN - Guy

Re: Oddball Terminals (Was: Re: VT100's)

[Guy Sotomayor Jr via cctalk]

> On Sep 7, 2018, at 4:15 PM, Frank McConnell via cctalk 
>  wrote:
> 
> On Sep 7, 2018, at 12:00, Al Kossow via cctalk wrote:
>> interesting.. the vt71t has inverted-T cursor keys
> 
> And CAPS LOCK in the home row to the left of the A key.  The VT220 made it 
> w-i-d-e.  Can we now fix the blame for the two of the three worst ideas in 
> computer keyboard design on d|i|g|i|t|a|l?  (#3 would be sending CONTROL to 
> live in the spacebar row and I think maybe we need to blame IBM for that.)
> 

No, there were terminals that had a (small) control key down near the space bar 
long before IBM did it with the PC.  I can’t recall which at the moment (but I 
recall having to deal with them in the mid-to-late 70’s).

I also looked at the keyboards on my Symbolics machines, and where I’d like to 
have the control key is the “rubout” key.  But given that there are no fewer 
than 5 “shift” keys on the Symbolics keyboard (hyper, super, meta, control, 
shift…I can’t recall at the moment if symbol is also a “shift” key), it makes a 
bit of sense to have them all near each other.  ;-)

TTFN - Guy

Re: VT100's

[Guy Sotomayor Jr via cctalk]

My biggest complaint with DEC terminals (and clones) that came after the VT100
(such as the VT220/VT320/etc) is that the terminals are nice and small but the
keyboards are *huge* (almost twice the width of the terminal itself).

I like having a keyboard that matches the size of the terminal and the VT100 is
along those lines.

It is also the same complaint that I have with IBM 3178/9 terminals (e.g. 
connect
to IBM 370 mainframes), where the terminal is relatively small but the keyboard 
is
significantly wider (being a derivative of the IBM PC/AT keyboard) and IMHO
would have been far better if IBM had left off the number pad.

TTFN - Guy


> On Sep 6, 2018, at 9:16 AM, Chuck Guzis via cctalk  
> wrote:
> 
> We didn't have a single VT100 in the house when we were running a VAX.
> 
> C Itoh, CIT-220s in our case.   Nice terminals with 14" screens.
> 
> Lots of VT100/VT220 clones were popular.  I did some programming for a
> specific VT220 clone from TAB products.
> 
> --Chuck
> 
> 
> 
> 
> On 09/06/2018 09:03 AM, systems_glitch via cctalk wrote:
>> I'm personally interested in an original because it's the physical standard
>> that a lot of imitations and emulations decided to implement. For similar
>> reasons, I have a LSI ADM-3A -- not because it's the best terminal ever,
>> but because it is so interwoven into the history of UNIX.
>> 
>> I personally seem to use a VT220 for most of my general hacking. It's nice
>> to have the current loop interface!

Re: Unisys keyboards

[Guy Sotomayor Jr via cctalk]

> On Sep 2, 2018, at 2:49 PM, Andrew Luke Nesbit via cctalk 
>  wrote:
> 
> Dear Paul,
> 
> On 02/09/2018 08:12, Paul Anderson via cctalk wrote:
>> Two Unisys PCK105-SKB look unused, but one is yellowed.
>> 
>> Sorry, I forgot to describe them as keyboards.
> 
> I realized the beauty of mechanical keyboards earlier this year, and I
> am gradually changing my workflow to returning to using them.  This
> includes acquiring a small collection for comparison purposes,
> availability, and, more interestingly, RE work that involves the PS/2
> protocol.
> 
> I've searched the web for the PCK105-SKB but I have been unable to find
> a proper description or even images.
> 
> Normally I use ISO UK or Apple Mac UK layout, but a US layout is good too.
> 
> Please could you point me to details about these keyboards?  Thanks!!

For non-classic stuff (e.g. modern computers for work) I use DAS Keyboards.
They have several models including a Mac version. They use cherry mechanical
key switches.  I have 3 and I’m very pleased with how they feel.

TTFN - Guy

Re: RK05 spindle pulleys - trade 50Hz vs 60Hz?

[Guy Sotomayor Jr via cctalk]

> On Jul 25, 2018, at 11:17 AM, Tony Duell via cctalk  
> wrote:
> 
> On Wed, Jul 25, 2018 at 5:48 PM, Eric Smith via cctalk
>  wrote:
> 
>> I'm not sure about motors, but 60 Hz power transformers can't handle as
>> high a maximum power (or current) when used for 50 Hz. The maximum power
>> has to be derated. Some transformers are specified/sold with a single power
>> specification for both 50 and 60 Hz use, which just means that the vendor
>> has built the necessary derating into even the 60 Hz specification.
>> 
>> Some products were built using different transformers for 50 vs 60 Hz
>> models, and the 60 Hz models uses a transformer inadequate for 50 Hz
>> operation.
> 
> This may well be true (I think it is), but the original question was about a
> particular device, the DEC RK05 disk drive. According to the maintenance
> manual (on bitsavers), the coversion between 50Hz and 60Hz involves changing
> the motor pulley. No comment about replacing the motor, the start capacitor,
> or anything else.
> 
> Does anyone have an RK05 IPB (Illustrated Parts Breakdown) manual? It would
> be interesting to see if there are different part numbers for the motor (start
> capacitor, blower...) for 50Hz and 60Hz versions.
> 
> Going back to a much earlier comment, I think this pulley is something that
> would be a lot easier to turn (on a lathe) rather than 3D print.

A while ago (can’t recall how many years), I acquired a number of 50Hz RK05’s.
Since I live in a 60Hz country, getting the drives to work simply involved 
changing
the pulley from the 50Hz version to the 60Hz version and changing the voltage
jumpers (the drives have worked fine after that change).  I believe that the 
switch
over is documented somewhere…but it’s been *way* too long since I did it.

As far as I recall, the pulleys have the frequency stamped on them.

For the OP who started this thread.  Yes, I still have the 50Hz pulleys 
*somewhere*
but at this point they're not easy to find as they are packed in a tote in the 
basement
of my shop (which is packed floor to ceiling with boxes and totes…there isn’t 
even
an isle to walk around in…just a small area that you can almost turn around in).

TTFN - Guy

Re: BASIC (Was: Reading HP2000 tapes

[Guy Sotomayor Jr via cctalk]

I should also mention that for the IBM S/23, once the BASIC program is entered, 
the original
source is discarded and only the tokenized code remains (comments are retained 
as-is).   The
LIST command runs a de-tokenizer and reconstructs the original source (well 
close to it anyway).

TTFN - Guy

> On Jul 17, 2018, at 12:33 PM, John Foust via cctalk  
> wrote:
> 
> At 03:53 PM 7/14/2018, Fred Cisin via cctalk wrote:
>> On Sat, 14 Jul 2018, Ed Sharpe via cctalk wrote:
>>> isn't the  basic  programs  also stored in tokinized  forms!?!?
>> 
>> Yes.
>> And the tokens are not the same between different brand implementations, or 
>> even between different versions, such as MBASIC 4 and MBASIC 5.
>> http://fileformats.archiveteam.org/wiki/Tokenized_BASIC
> 
> I remember a detokenizer for RSTS BASIC-PLUS that's not on that list.
> 
> I think it was called a "decompiler" though.  Seemed like magic at the time.
> 
> Googling reveals "You may be remembering the BASIC PLUS
> decompiler under RSTS.  RSTS BASIC PLUS was interpreted from "push-pop" code.
> The symbol table was available in the compiled file, and the correspondence
> between push-pop operations and BASIC PLUS source was very close, so you
> could get back very reasonable code."
> 
> And our previous discussion of it a decade ago:
> 
> https://marc.info/?l=classiccmp=121804804023540=2
> 
> - John
> 

Re: HP 5061-6565 scsi loopback plug

[Guy Sotomayor Jr via cctalk]

Yea, it would have to be more than just a terminator as it would have to 
reflect back some
of the control signals to the “ack” equivalents otherwise the controller would 
just see a bus
with no devices on it.  Presumably, the controller also has a “loopback” mode 
so that all the
signals (including data) could be read/written and therefor checked.

TTFN - Guy

> On Jul 9, 2018, at 2:05 PM, Grant Taylor via cctalk  
> wrote:
> 
> On 07/09/2018 12:33 PM, Al Kossow via cctalk wrote:
>> No, it is specifically mentioned in the HP test tools manual 09800-90001 
>> page II-82.
> 
> Interesting.
> 
> Thank you for correcting me.
> 
> 
> 
> -- 
> Grant. . . .
> unix || die

Re: Modifying microcode

[Guy Sotomayor Jr via cctalk]

> On May 30, 2018, at 6:51 AM, Noel Chiappa via cctalk  
> wrote:
> 
>> From: Kyle Owen
> 
>> I do have an 11/45, though... so with this modification, I suppose one
>> could have some fun:
> 
> That's for the -11/40 - very different machine, one couldn't use the same
> technique on the /45; the /40 is prepared to accept additional ucode on
> additional CPU boards, that's how the EIA works:
> 
>  http://gunkies.org/wiki/KE11-E_Extended_Instruction_Set
> 
> And it's custom boards, the design for which is no longer extant (pity, as
> I'd love to play with one myself).
> 
> Finally, I have this vague memory that they had to put a few minor mods on
> some of the existing CPU boards (details also lost), although my memory may
> be misleading me on that.
> 

I’m *very* familiar with the 11/40E as all of our 11/40’s at CMU had been 
“upgraded”
to 11/40Es (including all of the ones on C.MMP).

I recall the updated micro-code board but I can’t recall if the main CPU boards 
needed
any mods.  I’ll look over the CMU docs again and see if what might be required.

Did a little bit of micro-programming on the 11/40E but quickly found it was 
better to
concentrate on efficient algorithms.  ;-)  But to speed up kcalls in Hydra 
there was at
one point a lot of custom micro-code on the 11/40Es on C.MMP.

TTFN - Guy

Re: Restoring a PC Server 500 P/390

[Guy Sotomayor Jr via cctalk]

> On May 15, 2018, at 1:29 PM, Dave Wade via cctalk  
> wrote:
> 
> 
> That’s, in effect, what I did. Whilst there were Microchannel IDE Controllers 
> I have never seen one. There are no IDE interfaces on the "Planar" so every 
> thing must be on the MCA bus.
> So I bought a BusLogic BT646 SCSI card on E-Bay. I also bought an Adaptec 
> card as a spare.  I think I struck lucky with the BT646. It is a simple 
> SCSI/2 card, no raid but it does have a BIOS with support for two bootable 
> drives and a >4GB drive option.
> OS/2 has drivers for it so it works out of the box. The OS/2 boot disks find 
> the drive and install the proper drivers. 
> To compensate for the slower "narrow" drives I bought a SCSI2SD card that 
> puts an SD card on the bus. OS/2 just sees it as a up two four drives 
> depending on how I configure it. At present I have two 4gb drives. The card 
> in it is 32gb so I can add 2 x 12gb drives or 1 x 24gb or some other mix. The 
> CD ROM sites on the same bus. I haven't tried the tape drive yet..
> 

Some time ago I acquired a PCI P/390 card (along with the various LIC files).  
I went down the same path as you to build a P/390 system with OS/2 but I kept 
running into problems with OS/2 versions and supported hardware.

I finally gave up and acquired a PCI based RS/6000 that I’ll install AIX on and 
have an R/390.  ;-)  I haven’t had the time yet to make any progress on it.

But it’s good to know that you’ve managed to do this if I decide to go back and 
attempt the PC route again.

TTFN - Guy

Re: Is This A Shill?

[Guy Sotomayor Jr via cctalk]

> On May 2, 2018, at 9:50 AM, Alan Perry via cctalk  
> wrote:
> 
> 
> 
>> On May 2, 2018, at 8:58 AM, Cory Heisterkamp via cctalk 
>>  wrote:
>> 

[snip]

>> Chuck makes a good point about the Make-Offer feature, and it should be
>> noted that sellers have this option available to them within the eBay
>> messenger system even if the button isn't present in the auction, so if you
>> have your eye on something and feel the price is too high (or your search
>> of completed auctions shows the item has been relisted several times with
>> no takers), there's no harm in sending the seller a message with a dollar
>> amount in mind. -C
> 
> YMMV. There is a type of system that I am interested in adding to my 
> collection. An eBay seller has a bunch in a number of BIN/Make Offer  
> auctions over months. I asked an expert on the systems his opinion on the 
> auctions, including what he would offer. I offer 50% more, but it was still 
> 2/3rd the BIN price. They countered by taking a bit over 10% off. I countered 
> by splitting the difference but they didn’t go for it. The auction closed and 
> I looked at the auction history. I saw that the systems had previously been 
> offered at a price less than my split-the-difference offer. When they came 
> back up for auction again, I offered the split-the-difference price and noted 
> that the lower price in a previous ‘no-takers’ auction run. They countered 
> with a higher price than their counter to my initial offer. They went unsold 
> again and I waited for the next auction run. I offered the 
> split-the-difference price again and they countered even higher. I got the 
> message and have stopped bidding. That was a couple months ago and they still 
> have sold any of those systems.
> 

I’ve also found that if a seller has a number of the same item for sale, I’ll 
offer to take the entire lot at a significant discount.  A number of the 
sellers will go for that (e.g. they can unload all of the items in one 
transaction).

TTFN - Guy

Re: Int 13h buffer 64k boundaries

[Guy Sotomayor Jr via cctalk]

> On Apr 19, 2018, at 8:55 PM, Chuck Guzis via cctalk  
> wrote:
> 
> On 04/19/2018 07:56 PM, Guy Sotomayor Jr wrote:
> 
>> As to why IBM entered the PC market, the rumor was (at least at the time
>> within IBM) was that T.J. Watson, Jr. was at an employee’s house and saw
>> an Apple II.  He said that he wanted to have IBM branded computers in IBM
>> employees homes.  That was how the IBM PC project was kicked off.
> 
> But it wasn't clear at all what IBM intended the PC for.  Cassette tape,
> TV interface and anything but state-of-the-art design
> 
> The best part of the 5150 IMOHO, was the keyboard.

It was a variant of the keyboard that was used on the System/23.  The basic
keyboard technology was used in a lot of IBM keyboards at the time.

[snip]

> 
> My general impression is that IBM made the 5150 product, without the
> faintest idea of how they were going to sell it.
> 

It was IBM’s answer to the Apple II and various S-100 systems so it was
stripped down for a “low” entry price and/or added with other stuff.  It was
designed to be easy to interface to so that others could make peripherals.

It was really following the model of what other “home” computers at the
time were doing.  It was also a bit of an experiment and in that respect
you’re correct.  They didn’t know what it would be used for nor how to
sell it as it was *so* far outside of the normal IBM product lines.

TTFN - Guy

Re: Int 13h buffer 64k boundaries

[Guy Sotomayor Jr via cctalk]

> On Apr 19, 2018, at 4:16 PM, Chuck Guzis via cctalk  
> wrote:
> 
> On 04/19/2018 12:14 PM, Fred Cisin via cctalk wrote:
> 
>> I have no difficulty admitting that I didn't, and don't, have
>> Chuck's level of experience and knowledge. My entire venture into
>> microcomputers was a hobby that got out of hand.
> It's not so much expertise, but where you start your investigations.
> 
> Right when I peered into the 5150, I saw the 8237 DMA controller (first
> cousin to the 8257) and recognized it from my 8-bit (8085) days.  It was
> immediately obvious that IBM had taken a bunch of legacy 8 bit
> peripheral chips and shoved them into the PC.   In fact, the 5150 was
> surprising in that how primitive the engineering was--something you
> didn't expect from a high-tech pioneer like IBM.  So the DMA address
> space had to be 16 bits with simple bank select--using a disk controller
> chip that was design to be used with 8 inch drives.

As I have mentioned previously, the 5150 was done by a relatively small
team and they leveraged hardware from a product that had been released
a short time prior to the 5150.  That product was the System/23 which was
based on the 8085.  The importance of the System/23 cannot be overstated
as it was the first IBM product that featured a non-IBM designed CPU.

It is also the case that the entire team that developed the 5150 HW and BIOS
were all from the System/23 team.  The XT-bus was the way it was because
it was the System/23 peripheral bus turned 180-degrees so that “cheap” PC
cards could not be used in the System/23.

The fact that it used “primitive” engineering was actually a design goal.  The
point of the 5150 was to create something that was simple to build and had
a simple design.  Due to the shoestring (for IBM) budget, the team leveraged
a lot from the System/23.

As to why IBM entered the PC market, the rumor was (at least at the time
within IBM) was that T.J. Watson, Jr. was at an employee’s house and saw
an Apple II.  He said that he wanted to have IBM branded computers in IBM
employees homes.  That was how the IBM PC project was kicked off.

BTW, I was on the System/23 team (wrote a fair amount of the ROM code)
and I knew all of the folks on the PC team.  Dr. Dave Bradley (of CTRL-ALT-DEL
fame) had the office across the hall from mine and discussed a lot of the
goings on for what would become the 5150.

TTFN - Guy

Re: cctalk Digest, Vol 42, Issue 14

[Guy Sotomayor Jr via cctalk]

> On Mar 14, 2018, at 2:03 PM, Fred via cctalk  wrote:
> 
> 
>> Date: Tue, 13 Mar 2018 14:28:11 -0600
>> From: Grant Taylor 
>> Subject: Re: cctalk Digest, Vol 42, Issue 13
>> Message-ID:
>>  <6a172546-d8f1-13b9-f843-8fdba5799...@spamtrap.tnetconsulting.net>
>> 
>> If power / cooling / noise wasn't an issue, I'd also be interested in an
>> Multiprise 3000.
> 
>> But, I'm happily married and I would like to keep it that way.
> 
> The power requirements aren't that bad, are they?
> 
> I think Guy Sotomayor (spelling, apologies if I'm butchering ...) has a
> MP3K that I believe I bid against him on eBay once, and he ended up
> getting it (which made me feel a bit better).  It's what I call a 1/4
> fridge size.

Spelling’s correct!

Realistically, none of these are really that big power hogs.  MP3K runs on a
normal 120v/20A circuit (I believe it’s about ~1500W when fully configured).

I don’t run it 24/7 (actually I haven’t run it in a while…too much other stuff 
going
on at the moment).

My 4331 (whose peripherals required 208v 3-phase) all told needs ~20KVA.
That *will* put a dent in my power bill.

> 
> There were/are multi MP3K's on eBay currently that I've been watching, and
> one didn't know if there was an OS on it (Not sure I'd want to fight that
> battle with IBM, although a corner of the Internet lengthy forum post
> (yes, anecdotes are not evidence) leads me to believe they at least are
> "sympathetic" to hobbyists, but they won't publically admit it.   ... but
> I still didn't want to chance getting a paperweight.  The other one is way
> too much for me $ wise.

I think one of them is an Enterprise Server and not an MP3K.

> 
> I have a basement and 220V available.   For an IBM Mainframe of my own,
> damn the power bill.  :)   As long as it doesn't have the awful whine of
> an Alpha DS10-L I don't think my wife would mind.

That’s also why all of my “stuff” (junk as my wife calls it) is in a separate 
building
on our property.  Out of sight/out of mind.  ;-)

My shop has dedicated 220V @ 200A, so I have a “reasonable” amount of power.  
;-)

> 
> I will admit to myself that at some point there will be a limit to how
> many systems I can have at the house though running 24/7 :)

;-)

The only stuff that I run 24/7 is my network infrastructure, work machines
and my iMac that is our media server (which is getting perilously close to
completely filling a 16TB RAID).

TTFN - Guy

Re: XT/370 microcode

[Guy Sotomayor Jr via cctalk]

> On Mar 12, 2018, at 9:57 AM, Eric Smith via cctalk  
> wrote:
> 
> On Mon, Mar 12, 2018 at 10:54 AM, emanuel stiebler via cctalk <
> cctalk@classiccmp.org> wrote:
> 
>> On 2018-03-12 15:49, Eric Smith via cctalk wrote:
>>> As the most obvious example of the impedance mismatch between 370
>>> architecture and 68000 microarchitecture, the 68000 is hardwired to have
>>> eight each data and address registers, not sixteen GPRs, and microcode
>>> can't easily paper over that.
>> 
>> I wouldn't bet on that ...
>> 
> 
> I'm fairly sure of it, based on microarchitectural details in the US
> patents on the 68000 design.

I think there was also an article in the IBM Systems Journal when the XT/370
was announced that basically described how this was done and how everything
worked.

TTFN - Guy

Re: Writing emulators (was Re: VCF PNW 2018: Pictures!)

[Guy Sotomayor Jr via cctalk]

> On Feb 21, 2018, at 12:19 PM, Rich Alderson via cctalk 
>  wrote:
> 
> From: Guy Sotomayor Jr
> Sent: Wednesday, February 21, 2018 11:24 AM
> 
>>> On Feb 21, 2018, at 10:59 AM, Paul Koning via cctalk 
>>> wrote:
> 
>>> Typically you'd emulate the I/O device functionality, regardless of whether
>>> that is implemented in gates or in co-processor firmware.  That's the
>>> approach taken with the MSCP I/O device emulation in SIMH, or the disk
>>> controller emulation in the CDC 6000 emulator DtCyber.
> 
>> It’s also what’s done in Hercules (S/370, 370/XA, 390, Z simulator) and the
>> mainframe I/O is complex to say the least.
> 
> Also the method used by the KLH10 emulator (KS-10, KS-10/ITS microcode, 
> KL-10).
> There, each device type runs in a separate fork, using System V style memory
> mapping.  This of course means that it only runs under certain Unix variants.

I haven’t looked at KLH10 in a long time, but Hercules runs on a lot of 
different platforms
including Windows (and I would not call that a Unix variant by any stretch of 
the imagination).

TTFN - Guy

Re: Writing emulators (was Re: VCF PNW 2018: Pictures!)

[Guy Sotomayor Jr via cctalk]

> On Feb 21, 2018, at 10:59 AM, Paul Koning via cctalk  
> wrote:
> 
> 
> Caching doesn't change user-visible functionality, so I can't imagine wanting 
> to emulate that.  The same goes for certain error handling.  I've seen an 
> emulator that included support for bad parity and the instructions that 
> control wrong-parity writing.  So you could run the diagnostic that handles 
> memory parity errors.  But that's a pretty uncommon thing to do and I 
> wouldn't bother.

I disagree, especially if you’re using an emulator for development.  Caching is 
one of those things that can go
horribly wrong and not having them emulated properly (or at all) can lead to 
bugs/behaviors that are significantly
different from real HW.  The same goes for error reporting/handling.  There are 
cases where errors may be expected
and not having them can cause the SW to behave differently.

> 
>> There's a lot to consider.  The CPU(s), any co-processors, I/O
>> devices/busses, peripherals/terminals, etc.  Are you going to emulate
>> every co-processor in software, or is the system documented enough so
>> you can emulate just the protocols that the main CPU(s) use to talk to
>> those devices?  For example, many systems have some sort of storage
>> processors.  You could emulate everything 100% in software, but for that
>> you'd need disk and firmware dumps of everything.  Or, if the firmware
>> on those is fairly fixed, just emulate the functionality.
> 
> Typically you'd emulate the I/O device functionality, regardless of whether 
> that is implemented in gates or in co-processor firmware.  That's the 
> approach taken with the MSCP I/O device emulation in SIMH, or the disk 
> controller emulation in the CDC 6000 emulator DtCyber.  All those use 
> coprocessors, but the internals of those engines are much more obscure and 
> much less documented than the APIs of the I/O devices, and finding executable 
> code may also be very hard (never mind source code and assemblers).  For 
> example, I have only seen UDA50 firmware once, on a listing on a desk in CXO 
> back around 1981.

It’s also what’s done in Hercules (S/370, 370/XA, 390, Z simulator) and the 
mainframe I/O is complex to say the least.

However, it is my belief (and I think others have also stated) that assuming 
infinitely fast I/O (e.g. no delays what so ever) can cause issues because in 
many cases the SW expects to be able to do some work between the time that the 
I/O is started and when it completes.

TTFN - Guy

Re: LMI Lambda Lispmachine Keyboard aka Space Cadet Keyboad

[Guy Sotomayor Jr via cctalk]

I haven’t seen an emulator for an LMI, but here’s a link to a CADR emulator 
that was the precursor to both Symbolics and LMI so it might be worthwhile to 
try out.

TTFN - Guy

> On Feb 17, 2018, at 7:29 AM, Marc Holz via cctalk  
> wrote:
> 
> Hello,
> 
> 
> 
> I have the keyboard for a LMI Lambda Lispmachine but I'm missing the
> computer itself.
> 
> Is there a simulator or similar available?
> 
> 
> 
> The keyboard is similar like here
> http://world.std.com/~jdostale/kbd/SpaceCadet.html.
> 
> On the left side there is lable with "LMI" and a sticker "Scientific
> Computers Limited".
> 
> 
> 
> Here is a picture showing the actual layout:
> http://www.covingtoninnovations.com/michael/blog/1402/140208-keyboard.jpg
> 
> 
> 
> Best Regards,
> 
> Marc
> 
> 
> 
> 
> 
> 
> 
> 
> 

Re: HP 9816 CP/M-68K

[Guy Sotomayor Jr via cctalk]

> On Feb 12, 2018, at 3:00 PM, Chuck Guzis via cctalk  
> wrote:
> 
> 
> Most don't believe me what I say that the floppy disc dates from 1946.

And the fax was invented in 1842 (yes *before* the telephone)!

TTFN - Guy

Re: Sun3 valuations?

[Guy Sotomayor Jr via cctalk]

> On Jan 22, 2018, at 5:03 PM, Noel Chiappa via cctalk  
> wrote:
> 
> 
>> From: Guy Sotomayor Jr
> 
>> The XGP printed on roll paper. It was a laser type process
> 
> Plain paper? Well, my memory of it being thermal paper could easily be wrong;
> it's been a _long_ time, and I didn't use it much.
> 

It’s been longer for me!  ;-)

But I *did* use it *a lot* when I was there.

Missed using it until one of my co-workers at IBM started “playing” with an IBM 
4250
electro-erosion printer (I believe it was 600dpi H and 600dpi V).  It used 
aluminized
mylar (rolls again) — hence the electro erosion.  He wrote a bunch of SW for it 
and
ran it off of his PC-AT (at the time) and could produce “camera ready” results. 
 You
could also do limited print runs (100-500 copies) directly from resultant 
mylar.  Very
cool device…not really fast though.

TTFN - Guy

Re: Sun3 valuations?

[Guy Sotomayor Jr via cctalk]

> On Jan 22, 2018, at 4:08 PM, Noel Chiappa via cctalk  
> wrote:
> 
>> From: Grant Taylor
> 
>> What makes the copies of papers printed on them special?
> 
> Well, the Dover was the first device (that I know of) that could print _very_
> high-quality graphical/multi-font output, and on ordinary paper. It was also
> pretty darned fast - a couple of seconds per sheet, IIRC. The whole package
> just blew us all away (I was a MIT when we got ours).
> 
> There was a prior device (from quite a few years before) called a 'Xerox
> Graphics Printer', but i) IIRC it printed on thermal paper (think
> poor-quality thermal fax paper); ii) the resolution was nothing like as high
> as that of the Dover (which was, IIRC, in the 100's of DPIs - which it needed
> to produce the very-high quality printout with type-faces), and iii) it was
> quite slow.

The XGP printed on roll paper.  It was a laser type process and used a modified
Xerox copy engine.  It had a cutter to cut the roll paper to size (computer 
controlled
natch).  The cutter caused *no* end of troubles.

AFAIR it wasn’t particularly slow given the output quality.  Ours at CMU was
driven by an 11/45.  All of the CMU docs produced by the CS department were
printed by the XGP (and typeset by Scribe).  I still have various docs 
(including
my copy of the Hydra Songbook) and they look quite good.

TTFN - Guy

Re: GT-40 etc.

[Guy Sotomayor Jr via cctalk]

> On Jan 21, 2018, at 11:47 AM, Al Kossow via cctalk  
> wrote:
> 
> HP1311A is what was used in Galaxy Game
> https://www.hpmuseum.net/display_item.php?hw=732
> 
> The actual GG controller is a microcoded 2903 bitslice that sits on the Unibus
> Supposed to be similar to the VT-48
> 
> Didn't James build something (FPGA based?) to play the game?

James may have done something on this.  I’m not sure.

I do know that the CMU GDP did not have any VLSI (or LSI) in it.  It was pretty 
straight
SSI and MSI TTL from what I can recall with a bunch of custom built DACs.  The 
GDP
was connected to the UNIBUS but it was a separate box (1U/2U) from the 11/20.

TTFN - Guy

> 
> 
> On 1/21/18 10:48 AM, Guy Sotomayor Jr wrote:
> 
>> HP made some wonderful 17” and 19” electrostatic deflection vector displays. 
>>  We had a pile of them at
>> CMU driven by a custom GDP (some had 10-bit DACs, some had 12-bit DACs) that 
>> was front-ended by
>> a PDP-11 (usually an 11/20).  It was a *wonderful* combination!
>> 
>> TTFN - Guy
>> 
> 

Re: GT-40 etc.

[Guy Sotomayor Jr via cctalk]

> On Jan 21, 2018, at 10:13 AM, Al Kossow via cctalk  
> wrote:
> 
> 
> 
> On 1/21/18 10:12 AM, Al Kossow via cctalk wrote:
>> 
>> 
>> On 1/21/18 10:04 AM, Paul Koning via cctalk wrote:
>> 
>>> Remember that the GT40 is a vector drawing display, not a raster scan.  So 
>>> you need a tube and associated deflection machinery that can handle high 
>>> frequency X and Y deflection waveforms accurately.  This is not easy, 
>>> especially with magnetic deflection.  I don't know what DEC used
>> 
>> Electromagnetic
>> 
>> The deflection amps on vr14s and 17s were notorious for blowing out.
>> 
>> 
> 
> the phosphor is long-persistance green

HP made some wonderful 17” and 19” electrostatic deflection vector displays.  
We had a pile of them at
CMU driven by a custom GDP (some had 10-bit DACs, some had 12-bit DACs) that 
was front-ended by
a PDP-11 (usually an 11/20).  It was a *wonderful* combination!

TTFN - Guy

Re: GT-40 etc.

[Guy Sotomayor Jr via cctalk]

> On Jan 20, 2018, at 8:07 PM, Ethan Dicks  wrote:
> 
> On Sat, Jan 20, 2018 at 8:58 PM, Guy Sotomayor Jr  wrote:
>> As I understand it, the power for the DACs actually comes from the monitor 
>> (VR12/4/7) and
>> thus you can’t use any monitor without some additional circuitry to provide 
>> the power to the
>> DACs.
> 
> Interesting.  I didn't know that about the VT11.  Seems that it
> wouldn't be that hard to make an external PSU to replace that.

I looked into it a while ago (since I have a VT11 somewhere but no tube).  Too 
many
other projects and *work* have gotten in the way.  I’ll get back to it 
eventually unless
someone beats me to it.  ;-)

TTFN - Guy

Re: GT-40 etc.

[Guy Sotomayor Jr via cctalk]

As I understand it, the power for the DACs actually comes from the monitor 
(VR12/4/7) and
thus you can’t use any monitor without some additional circuitry to provide the 
power to the
DACs.

TTFN - Guy

> On Jan 20, 2018, at 5:32 PM, Paul Anderson via cctalk  
> wrote:
> 
> I think just the VR12, VR14, and the VR17.
> 
> I might have an extra VT11 backplane.
> 
> On Sat, Jan 20, 2018 at 7:10 PM, Ethan Dicks via cctalk <
> cctalk@classiccmp.org> wrote:
> 
>> On Sat, Jan 20, 2018 at 6:46 PM, Marc Howard via cctalk
>>  wrote:
>>> There was a guy in the Netherlands (I believe) who was trying to sell a
>>> GT40 for $14K with no delivery option.
>> 
>> Oof!
>> 
>>> If I were on the east coast (or just not very busy) I would have higher
>> on
>>> the ebay system just to get the GT40 + monitor.
>> 
>> What monitors work with the GT40?  I happen to have the boardset (and
>> an 11/05) but not the CRT (and no lightpen).  What could I drive with
>> those boards?
>> 
>> -ethan
>> 

Re: Power plugs and cables for the IBM 3420

[Guy Sotomayor Jr via cctalk]

Those cables came with my 4331 system.  I’ll go and dig them out and maybe 
there will be some sort of part number.
At worst I’ll post some pictures.  You might also want to look up the various 
IBM docs on the 3420 and 3803.  They
should specify those cables.  I also have all the docs in an IBM FE cart, so 
when I have time, I’ll see if there’s anything
there.

TTFN - Guy

> On Jan 20, 2018, at 12:23 PM, Curious Marc via cctalk  
> wrote:
> 
> Can any of you identify which power plugs models these are. They are on my 
> IBM 3420 tapes and connect to the IBM 3803 controller, 3 phase:
> 
> https://www.dropbox.com/s/ftfpg0owdvb173u/IMG_5066.JPG?dl=0
> 
> https://www.dropbox.com/s/uyzpwcp6sjkvrpf/IMG_5067.JPG?dl=0
> 
> These are for the large vacuum column tapes seen in this video here:
> 
> https://youtu.be/yaPVkw8dnaI
> 
> 
> 
> And if anyone knows where to get these power cables...
> 
> 
> 
> Marc
> 

Re: non-PC Floppy imaging

[Guy Sotomayor Jr via cctalk]

Thanks Lyle.

My biggest impediment at the moment is not actually having a PC that has a 
floppy
drive.  :-o

The other is time…work has been crazy as indicated by Jensen’s CES keynote
tonight where the chip that I’ve been working on was just announced!  yea!
9,000,000,000 transistors!

TTFN - Guy



> On Jan 7, 2018, at 10:33 PM, Lyle Bickley  wrote:
> 
> Hi Guy,
> 
> I just copied several IBM 8" Maintenance Device (MD) Diskettes - and
> verified that the copies work on the IBM MD. They seem to be in an IBM
> 3x0 format (with a standard IBM VTOC).
> 
> Track 0 on the diskettes is 128 byte sectors,
> Tracks 1 through 76 are 256 byte sectors.
> The diskettes are DSSD.
> 
> (So you need a Shugart 850/851 (or equivalent) to make the copies).
> 
> I used both Teledisk and IMD - and both successfully captured and
> re-created the diskettes correctly.
> 
> More in editing IBM images later...
> 
> Cheers,
> Lyle
> 
> 
> On Fri, 5 Jan 2018 11:52:56 -0800
> Guy Sotomayor via cctalk  wrote:
> 
>> Hi,
>> 
>> I now have a number of uCode diskettes for my IBM 4331.  I would
>> somehow like to image them so: a) I have backups in case the floppies
>> themselves go bad b) be able to investigate their contents in case I
>> have to “merge” the contents of multiple floppies to make a single
>> good one
>> 
>> These are all 8” diskettes.
>> 
>> The complicating factors in all of this are:
>> a) any text (e.g. strings) are going to be in EBCDIC rather than ASCII
>> b) each uCode diskette was presumably serialized to the CPU it was for
>> c) not sure what the “on-disk” structure looks like
>> d) the only 8” diskette drives that I have are in IBM (non-PC)
>> equipment
>> 
>> Any ideas/comments would be welcome.
>> 
>> Thanks.
>> 
>> TTFN - Guy
>> 
> 
> 
> 
> -- 
> 73  AF6WS
> Bickley Consulting West Inc.
> http://bickleywest.com
> 
> "Black holes are where God is dividing by zero"

Re: non-PC Floppy imaging

[Guy Sotomayor Jr via cctalk]

> On Jan 6, 2018, at 2:42 AM, Dave Wade via cctalk  
> wrote:
> 
> 
> 
>> -Original Message-
>> From: cctalk [mailto:cctalk-boun...@classiccmp.org] On Behalf Of Jon Elson
>> via cctalk
>> Sent: 06 January 2018 02:50
>> To: Guy Sotomayor ; gene...@ezwind.net;
>> discuss...@ezwind.net:On-Topic and Off-Topic Posts
>> 
>> Subject: Re: non-PC Floppy imaging
>> 
>> On 01/05/2018 01:52 PM, Guy Sotomayor via cctalk wrote:
>>> Hi,
>>> 
>>> I now have a number of uCode diskettes for my IBM 4331.  I would
>> somehow like to image them so:
>>> a) I have backups in case the floppies themselves go bad
>>> b) be able to investigate their contents in case I have to “merge” the
>> contents of multiple floppies to
>>>  make a single good one
>>> 
>>> 
>> Any possibility the 4331 can write to a floppy?  I know next to nothing of 
>> this
>> hardware.  But, I know the VAX 11/780 really well. You could make copies of
>> its console floppy on that drive, once the OS was up.
>> 
> 
> Yes it can, it writes error log data to the floppy. It’s a pity most of the 
> operating guides to the 43xx boxes are lost which would be usefull as they 
> will have instructions on how to back up the diskettes,

I was reading that last night (as well as the CE being able to “patch” the 
uCode and save it on the floppy).

I have an entire FE cart (both sides) full of manuals for various parts of my 
4331 (and peripherals).  I haven’t looked through all of them (including 
various other manuals in a several foot long holder) to see if there’s an 
operating guide in there or not.

TTFN - Guy