[cctalk] Re: MS-DOS am I the only person who liked the win 3.1 UI?

[Maciej W. Rozycki via cctalk]

On Wed, 31 Jul 2024, CAREY SCHUG via cctalk wrote:

> this is linux, right?  so I could have one be kde, one gnome and maybe a 
> third xfce?  might try playing with it someday, or good if I want to 
> transition gradually to a different UI, but unless 
> one of them could be like the win 3.1 UI, not being unable to join them 
> together and drag individual app windows from one physical screen to another 
> probably makes better to all be the same UI with joined screens.

 With Linux you can definitely have different window managers on different 
X11 instances running on different screens within the same machine.  I did 
this before (running two instances of Gnome on :0 and :1 respectively, and 
olvwm on :2) and it's only down to the individual window managers whether 
they are happy about it or not.  You can have some remote screens such as 
via XDMCP as well, each using its own window manager.

  Maciej

[cctalk] Re: LCM auction pre-notice

[Maciej W. Rozycki via cctalk]

On Sat, 13 Jul 2024, Patrick Finnegan via cctalk wrote:

> I'm definitely a bit sad that Purdue's former CDC 6500 (priming that's what
> they meant) will probably go to some unknown high dollar bidder.

 Who'll then convert it or embed in pieces into a furniture set to impress 
guests, because why not.  Sigh.

  Maciej

[cctalk] Re: Delay slots, was: Re: Re: early microprocessor limited pipelining [was: Intel 8086 - 46 yrs. ago]

[Maciej W. Rozycki via cctalk]

On Thu, 13 Jun 2024, Henry Bent via cctalk wrote:

> > I always assumed that was because the latency of multiply, let alone
> > divide, was far too many cycles for anyone to plausibly schedule "useful"
> > instructions into. Wasn't r4000 divide latency over 60 cycles? Wasn't r4000
> > divide latency more than 60 cycles?
> >
> 
> The MIPS R4000 manual
> https://groups.csail.mit.edu/cag/raw/documents/R4400_Uman_book_Ed2.pdf
> says that double precision divide is 36 cycles, and double precision square
> root is 112 (!).

 Note that these figures are for floating-point arithmetic.

> What's interesting about that is that GCC's model of the R4000 says that
> divide is 69 cycles; I'm not sure of the reason for the discrepancy.
> https://gcc.gnu.org/git/?p=gcc.git;a=blob_plain;f=gcc/config/mips/4000.md;hb=HEAD

 And this is for integer arithmetic, that's the reason.

  Maciej

[cctalk] Re: Delay slots, was: Re: Re: early microprocessor limited pipelining [was: Intel 8086 - 46 yrs. ago]

[Maciej W. Rozycki via cctalk]

On Thu, 13 Jun 2024, Jonathan Stone wrote:

> > The architecture designers cheated however even in the original ISA in
> > that moves from the MD accumulator did interlock.  I guess they figured
> > people (either doing it by hand or by writing a compiler) wouldn't get
> >that right anyway. ;)
> 
> I always assumed that was because the latency of multiply, let alone 
> divide, was far too many cycles for anyone to plausibly schedule 
> "useful" instructions into. Wasn't r4000 divide latency over 60 cycles? 

 Well, overflow and divide by zero checks will often take many cycles in 
parallel with MDU executing the operation, but you're of course correct in 
that the designers have made a reasonable decision there.  I just put it 
differently.  The net result however is the architecture has never been 
fully without pipeline interlocks, although indeed it used to be close.

 Performance figures for the R3000 would be more appropriate for the MIPS 
I initial ISA revision and reportedly said CPU executed a 32-bit division 
in 35 cycles.  I can imagine the R4000 could need over 60 cycles to run a 
64-bit division.  Figures vary among more modern implementations, but MDU 
operations continue having significant latencies.

  Maciej

[cctalk] Re: early microprocessor limited pipelining [was: Intel 8086 - 46 yrs. ago]

[Maciej W. Rozycki via cctalk]

On Thu, 13 Jun 2024, Paul Koning via cctalk wrote:

> MIPS, perhaps?  It has "delay slots".  The one that remains is the 
> branch delay slots, which in modern designs is presumably merely an 
> annoying crock that requires extra pain to implement but is actually 
> required because it changes the meaning of the code.  There also used to 
> be load (?) delay slots, which sounds like what you're describing.  

 Yes, MIPS I load delay slots.  Gone by the MIPS II/III ISAs, though 
coprocessor move delay slots remained (e.g. for moving data between the 
GPRs and the FPRs), having only been removed with the MIPS IV ISA.  For 
the remaining missing interlocks there are now instructions in the ISA to 
clear the hazards resulting (i.e. possibly stall the pipeline) explicitly, 
so there is no need to count instructions anymore.

 Also various extensions and revisions of the ISA have added the so called 
compact branches that have no delay slot, starting with the MIPS16e ASE.  
And then the microMIPSr6 ISA encoding only has compact branches available.

> That was ancient history by the time I started working on MIPS machines, 
> fortunately.

 MIPS I cores and variations were still around by late 1990s in embedded 
use, and of course the GNU toolchain continues to support all the arcana 
to this day, as do community-maintained OSes.

  Maciej

[cctalk] Re: Delay slots, was: Re: Re: early microprocessor limited pipelining [was: Intel 8086 - 46 yrs. ago]

[Maciej W. Rozycki via cctalk]

On Thu, 13 Jun 2024, Jonathan Stone via cctalk wrote:

> MIPS is of course (allegedly) an acronym for "Microprocessor without 
> Interlocked Pipeline Stages".
> 
> No interlocking between pipeline stages mean no hardware avoidance 
> (delays, pipeline bubbles) of hazards. So hardly surprising that authors 
> of MIPS assembly-level code are/were responsible for scheduling that 
> code to avoid what would otherwise be pipeline hazards.

 The architecture designers cheated however even in the original ISA in 
that moves from the MD accumulator did interlock.  I guess they figured 
people (either doing it by hand or by writing a compiler) wouldn't get 
that right anyway. ;)

  Maciej

[cctalk] Re: interlace [was: NTSC TV demodulator ]

[Maciej W. Rozycki via cctalk]

On Mon, 20 May 2024, Wayne S via cctalk wrote:

> The setup on the earlier monitors was sometimes call “ODB” , don‘t know 
> why.  Was equivalent to setup.

 As a counterexample my first PC monitor had nothing like that.  It was a 
dual-frequency B CRT and only had three controls: a power-on switch, a 
brightness control rheostat and a contrast control rheostat.  That was it. 
It accepted both interlaced and non-interlaced analogue video input, 0.7V 
p-p, separate sync.  Earlier on I came across numerous digital (TTL) input 
PC monitors and they had similar controls.  Some had additional rheostats 
to adjust vertical position and sync.  There was no setup in any of them.

  Maciej

[cctalk] Re: PCs in home vs businesses (70s/80s)

[Maciej W. Rozycki via cctalk]

On Sat, 25 May 2024, Chuck Guzis via cctalk wrote:

> > I think it was indeed the way to tell NEC V20 and other x86 chips apart: 
> > good if you wanted to make seamless use of the 8080 emulation mode).
> 
> Is this something you've actually verified?   Seems to be a bit of an
> urban legend.  I can test it on a V20 system if you don't have one.

 You mean the 8080 emulation mode or the CPU detection via AAD/AAM?

 If the latter, then I'm fairly sure I verified that as we had a lab full 
of V20 PC/XT clones back at the university (mind it's been ~30 years now 
though) and here's a piece of code of mine I could find from back in the 
day, dated Mar 10th, 1996:

; -  = 00:
;   00 - 8088
;   01 - 8086
;   02 - V20 (NEC)
;   03 - V30 (NEC)
;>= 04 - reserved (do not use)
[...]
;   8088, 8086, V20 or V30

MOV AH,001H
AAD 000H
JZ  CHKBUS
ADD [CPUDSC],002H

;= 00 or 02

CHKBUS: CALLDETBUS

;incremented if 16-bit data bus

ADD [CPUDSC],AL
JMP EDTCPU

This replaced older code going back to Oct 11th, 1993 that instead did:

MOV AL,040H
MUL AL
JNZ CHKBUS

I cannot remember anymore why I made this change: it may well have been 
for the sake of it as I was eager to experiment with odd stuff.  I can't 
imagine myself making a change though that would regress things.

 As to the former I meant to try it and had documentation, but that has
never materialised.  I did a little 8080 programming, but not much and 
with actual 8080 hardware only.

 Feel free to make any tests you want with your V20 though as my memory 
could be tricking me after so many years.  I haven't come across a V20 
ever since 1990s.

  Maciej

[cctalk] Re: PCs in home vs businesses (70s/80s)

[Maciej W. Rozycki via cctalk]

On Sat, 27 Apr 2024, Fred Cisin via cctalk wrote:

> How many know that AAM is a two byte instruction, with te second byte beint
> 0Ah?
> Changing the second byte to 8 gave division by 8, etc.

 It's the kind of a question you can't really answer, but the feature has 
been known since forever.  Myself I've found this out in early 1990s, soon 
after I switched from the Z80 to x86.  And now it's a documented feature:

Opcode Instruction   Op/ 64-bit  Compat/ Description
 En  ModeLeg Mode
D5 0A  AAD   A   Invalid ValidASCII adjust AX before
  division.
D5 ib  (No mnemonic) A   Invalid ValidAdjust AX before division to
  number base imm8.

Opcode Instruction   Op/ 64-bit  Compat/ Description
 En  ModeLeg Mode
D4 0A  AAM   A   Invalid ValidASCII adjust AX after
  multiply.
D4 ib  (No mnemonic) A   Invalid ValidAdjust AX after multiply to
  number base imm8.

(from "Intel 64 and IA-32 Architectures Software Developer's Manual").  I 
did use these instructions in a bunch of my programs; by 1990s it hardly 
mattered that some early x86 clones did not support these encodings (and 
I think it was indeed the way to tell NEC V20 and other x86 chips apart: 
good if you wanted to make seamless use of the 8080 emulation mode).

 FWIW,

  Maciej

[cctalk] Re: 50 pins in three rows

[Maciej W. Rozycki via cctalk]

On Sat, 12 Aug 2023, Chuck Guzis via cctalk wrote:

> >  They are: .
> > People never give up on these things as this is not the first reference I 
> > have come across in the recent years about this connector being made new.  
> > I can't find the previous one, but overall I find it quite reassuring.
> 
> I wonder if these are from a group buy not long ago, where someone got a
> manufacturer to gin up a lot of them (minimum order was something like
> 1,000).

 I guess not:  (if you care 
to watch YT).

  Maciej

[cctalk] Re: 50 pins in three rows

[Maciej W. Rozycki via cctalk]

On Fri, 11 Aug 2023, Fred Cisin via cctalk wrote:

> I just called them D-23, since the shell size didn't seemto have been
> named/defined.
> 
> They weren't available when i got my Amiga, either.
> But, I guess that there was a period in between when they might have been
> available.

 They are: .
People never give up on these things as this is not the first reference I 
have come across in the recent years about this connector being made new.  
I can't find the previous one, but overall I find it quite reassuring.

  Maciej

[cctalk] Re: Is this a RIFA (uV3100-10 PSU)?

[Maciej W. Rozycki via cctalk]

On Wed, 2 Nov 2022, Peter Coghlan via cctalk wrote:

> > Did you have to replace the power LED at all? I've just bench-tested the PSU
> > I've swapped the X2 cap in (luckily it powers up without a load, so all I
> > did was hook up a DVM and check out the voltages), and I noticed that the
> > LED didn't light. I'm pretty sure I connected it back (and it is keyed!) so
> > I think I may be looking for a replacement. Something in the back of my mind
> > says that there is something that makes the replacement slightly non-trivial
> > (funny LED, odd housing it fits in, some trick to getting it out ... I can't
> > remember unfortunately).
> > 
> 
> The LED is more than just a power on indicator.  When it fails to light,
> it can indicate that something is not right in the PSU.  It may tie in
> with the "power good" output from the PSU.

 It does.  I have an H7821 PSU where the LED lights briefly upon power-on 
and then goes dark.  The PSU cannot be used to power a mainboard as it 
does not come up, however it works just fine with storage in an expansion 
box.  It is one of those that I recapped after leaks have appeared; in 
fact it is the one that made me aware of the problem in the first place.  
I'll have to get back to it sometime to get this sorted.

> It could be that it is failing to light because the regulation is not
> working properly because there is no load.  I'd try it with a load
> before anything else.  The H7822 may need a load on both boards.

 There's a 2Ω dummy load on the 5V line in storage expansion boxes powered 
by the H7821, so these do require minimum current to work correctly.

> > BTW was it just the 1800uF 25V 105degC caps (mine are brown) that you had to
> > replace? Mine look fine but there are some other large electrolytics in
> > there (two large brown 470uF voltage unclear, and one large black cap by the
> > mains input on which I cannot see any of the markings).
> > 
> 
> It was only the 1800uF 25V capacitors were bad (mine are all brown too).
> In an earlier posting I said there were six of them in a H7821 and ten of
> them in a H7822.  I should have said five in a H7821 and nine in a H7822.
> The 470uF 400V capacitors in my units were all fine.

 Same here, five 1800uF 25V caps to replace in the H7821 according to my 
notes.  Overall if you spot a cap that says SXF on it, then replace it 
right away whether already leaking or not.  These were made by Chemi-con.  
Other Chemi-con lines reported problematic are SXE and LXF, though from 
own experience they seem less prone.

 Also Nichicon PL and PF parts may have to be replaced, I have seen the 
former ones actually leaking in other DEC PSUs, such as the H7826, which 
is also infested by SXF parts in various capacitances.  Both kinds leaked 
in a generic industrial Bel Power PSU used with a Cisco device.

 Sadly the problem with component shortage has hit capacitors as well and 
some that used to be readily available are not anymore and prices have 
risen too.

 NB I wasn't aware about the problem with RIFA capacitors, it seems like I 
might have to replace them in several PSUs I have already recapped, sigh.  
I haven't seen any of them fail though, not at least in an obvious way.

 HTH,

  Maciej

[cctalk] Re: DECnet to be dropped from Linux

[Maciej W. Rozycki via cctalk]

On Tue, 2 Aug 2022, Wayne S via cctalk wrote:

> I naively assume that since Decnet is a mature product supporting it 
> just means testing it with new versions of Linux so not too much work is 
> needed.

 Someone has to do that, it doesn't happen automagically.  And if not for:

> It has been Orphaned in kernel since 2010.
> And the documentation link on Sourceforge says it is abandoned there.

I am sure this code would be kept.  We have older stuff there in the Linux 
kernel (in terms of first appearance; I remember DECnet support being 
contributed and it was pretty late in the game).

 Step in as a maintainer and the decision might be revisited.

> If a linux distro keeps it it adds value to that distro. So, in 
> the future, Redhat, for example, might be the only distro left 
> supporting it so if you need Decnet you’ll want Redhat. This Creates a 
> niche market by default.

 Again, someone has to be paid to maintain it.  If a company sees business 
justification for that, it will.

  Maciej

[cctalk] Re: Agenda VR3 MIPS cross-gcc

[Maciej W. Rozycki via cctalk]

On Sat, 30 Jul 2022, Tomasz Rola via cctalk wrote:

> suppose). Is there anything that indexes ftp sites, beyond, hum-hum,
> archie? Is there any archie server left?

 Yep, .

  Maciej

RE: DEC H7822 power supply

[Maciej W. Rozycki via cctalk]

On Thu, 12 May 2022, Peter Coghlan via cctalk wrote:

> > Wayne:  I just got an Dec AlphaStation 200. Look like its running NT 
> > though. 
> >
> 
> It's probably ok but check the power supply for leaky capacitors!

 Definitely, watch out for possible damage!

 Prompted I had a peek in mine (an Astec SA180-3505) and it does have lots 
of the dangerous Chemi-con LXF parts!  While mine looks clean and tidy yet 
(LXF series seem sturdier than older SXF ones), I need to get this sorted 
sooner rather than later.  Thankfully last time I booted it a couple weeks 
ago it worked just fine.

 (Strictly speaking I have either an AlphaServer 300 or an AlphaStation 
250 system, which are hard to tell apart and the only difference mentioned 
in DEC documentation between the two mainboards is the maximum amount of 
DRAM supported, 512MiB vs 256MiB.  However both are essentially the same, 
up to the dedicated sound connector (unused with the AlphaServer), so it's 
not clear to me if it was a manufacturing option such as a wire bridge put 
somewhere into the PCB or just a matter of software support.  Both kinds 
of systems use the same firmware, which does not report the system model!  
And in any case my mainboard has a 54-23787-01 designation, which I'm told 
is an AlphaStation 250 (an AlphaServer 300 would be 54-23787-02), and also 
an early version, dated week 51 of 1994, S/N 60, and with lots of hardware 
patching present, however without the sound option and with an AlphaServer 
300 badge and a 1997 date code on the case.  Which in any case is exactly 
the same as with the AlphaStation 200, so the PSU is likely the same as 
well, so again, do check yours!)

> Have a look around for batteries that might leak while it was/is in
> storage too!

 There's a 2032 Lithium coin cell in these systems only, so while it might 
have been depleted it won't do any harm.

  Maciej

Re: DEC H7822 power supply

[Maciej W. Rozycki via cctalk]

On Thu, 12 May 2022, Peter Coghlan via cctalk wrote:

> I replaced the capacitor in question with a blue Nichicon SE of the same
> value scavanged from another H7821 until I order some spares.  I now have
> 8.7V available on the 9V supply, a little less than I hoped for but it is
> enough to make the internal thinwire tranceiver happy.  Now there is just
> the seized fan to deal with.

 Tolerance is 5% on this line, so you're well within.

> Thanks again to you and Tony for leading me in the direction of the likely
> source of this fault.  I would never have thought of looking in the power
> supply to find it.

 You are welcome!  I wish I had the skills to actually diagnose a faulty 
PSU myself like you do.

 Experience has taught me to look into the PSU first for all kinds of odd 
phenomena.  For example I had a WiFi+5-port 100BASE-TX Ethernet bridge 
which stopped talking to one particular device, a 10BASE-T to 10BASE2 
media converter/repeater regardless of the port it was wired to; IIRC 
frame reception worked, but transmission did not make it through.

 It cost me a lot of hair pulling to sort it, including actually buying a 
brand new identical media converter, the first suspect, as it was the only 
device that caused the bridge to exhibit its odd behaviour.  Which did not 
help of course and the new device triggered exactly the same symptoms.

 Eventually it has turned out to be the bridge's PSU being on its way out. 
It was one of those nasty plug top PSUs that are not worth even looking 
inside, and just replacing it with a new one (which of course cost more 
than the bridge combined with its PSU originally did!) cured the problem.  
Out of 4 such bridges I bought ~15 years ago 3 are still in service, but 
all their PSUs had to be replaced.  At least they had a standard connector 
for the power plug (the newer replacement devices don't anymore, sigh).

 The 4th bridge, the same that caused problems, started having more issues 
with its wired ports later on if more than 2 devices were plugged IIRC, 
with no clear reason except for suspision of a power deficit, so I put it 
aside with a plan to recap it and see whether it helps (this discussion 
just reminded me about it, so maybe I'll try doing it over the coming 
weekend as I have since got the parts required).

 And it was just one of many incidents I had with PSUs playing tricks, so 
the PSU is now my first and primary suspect if a device misbehaves in a 
way that cannot be clearly attributed to a software bug (which is by far 
the most common case nowadays, a clear sign of a generation change to me).

  Maciej

Re: DEC H7822 power supply

[Maciej W. Rozycki via cctalk]

On Wed, 11 May 2022, Paul Koning wrote:

> > I guess especially for standard capacitors factories ordered whatever was 
> > readily available whereas with the high-ripple low-impedance/ESR parts the 
> > choice was much more limited.
> 
> I wonder if nowadays a good replacement for the case where low ESR is 
> needed would be a big ceramic capacitor.  Unlike the old days those now 
> can be had in many-µF capacitances.

 Possibly, in the lower capacitance range, if not for the horrendous 
price, e.g. $50/£40 each for a 470µF/25V part: 



(at least you get free shipping for just one piece).  There's still little 
choice for the higher range parts found in DEC PSUs, such as 1800µF/25V, 
4700µF/10V or 6800µF/20V even.  With aluminium organic polymer capacitors 
rated voltage also quickly drops for higher capacitances, so you won't get 
any of these as replacements either.  I don't know offhand to what extent 
these limitations come from current technology vs the laws of physics.

  Maciej

Re: DEC H7822 power supply

[Maciej W. Rozycki via cctalk]

On Thu, 12 May 2022, Peter Coghlan via cctalk wrote:

> Anyway, the good news is that I think I have found the source of the
> problem.  One of the capacitors used to filter the (DC?, pulsed DC?,
> rippled DC?, biased AC?) supply to the 9V regulator is marked 330uF/25V.
> It reads 6uF on the capacitance range on my multimeter.  This can't be
> helping the cause.  It's not showing any signs of leakage but it's got
> a brown sleeve and the same logo as the nasty, leaky SXF capacitors but
> it is marked KME.  (I said there was only one capacitor in the filter
> in a previous posting.  Originally I managed to spot a little 10uF/100V
> capacitor but somehow failed to notice the chubbier 330uF/25V capacitor
> completing a PI filter with a small choke...)

 Likely just a general purpose capacitor.  I only have 2 330uF/25V 85°C 
Nichicon SE parts listed for the H7821 (and I have a note about one PSU of 
this kind having a 220uF/35V part in place of one of those too).  Also no 
100V parts at all, but 4 10uF/35V 105°C parts, either Teapo SE or Daewoo 
RS.  Teapo SE and Chemi-con KME series are standard general purpose parts 
and given the low temperature rating Nichicon SE are likely such as well.

 I guess especially for standard capacitors factories ordered whatever was 
readily available whereas with the high-ripple low-impedance/ESR parts the 
choice was much more limited.

  Maciej

Re: DEC H7822 power supply

[Maciej W. Rozycki via cctalk]

On Sun, 8 May 2022, Tony Duell wrote:

> >  In the H7821 it's -9Vdc return pairing with -9Vdc supplied on the yellow
> > wire (an isolated circuit).  Pin numbers 14 & 13.  Try measuring voltage
> > across the suspicious connections as any reference to ground may not be
> > indicative.
> >
> >  This voltage is also present with the H7819 PSU.  It's not clear to me
> > what it is used for.
> 
> It's only a guess (this is rather more modern than the DEC hardware I
> have), but it may be a supply for a thinwire ethernet transceiver
> circuit. This would be insolated from system ground of course, and
> I've seen something similar in an X-terminal.

 That makes sense to me.  Both the VAXstation 3100 and the DECstation 3100 
systems (which are among the users of the H7821 PSU) and the VAXstation 
4000 system (likewise the H7819 PSU) have a built-in 10BASE2 interface.  
Where these PSUs are used for storage expansion boxes some voltages are of 
course unused.

 NB I have literally just recapped an H7816 PSU where I spotted a bunch of 
Chemi-con LXF parts starting to leak (both the DEC-usual 1800uF/25V parts 
and less common 2200uF/10V and 1000uF/25V ratings) as well as a pair of 
notorious Nichicon PL parts at 4700uF/10V (though these were clean and 
from the look of the closing cap a more modern variant; I've replaced them 
for extra safety anyway).

 Thankfully the PSU still was in a working condition and it was easy to 
get it disassembled enough to get at the parts, there was virtually no 
corrosion yet, and the PSU now continues working after the recap, so it 
was quite an easy task on this occasion.  The old parts, including the 
leaking ones, still showed in-range values of capacitance and ESR, not 
unusually, which is obviously why no damage to other circuitry has been 
caused.

 Lucky me, also to think to have a look inside!

  Maciej

Re: DEC H7822 power supply

[Maciej W. Rozycki via cctalk]

Hi Peter,

> > Right, my notes indicate Nichicon PL parts might be problematic too, e.g. 
> > one at 4700uF/10V on 5V output of the H7826 PSU.
> >
> 
> What is H7826 used in?  I don't think I have any of those.

 DECstation 5000/1xx systems and TURBOchannel Extender boxes.  Not sure if 
anything else.

> >  The symptom is exactly like with my broken H7821.  Check the power-good 
> > signal (brown wire with the H7821, possibly likewise with the H7822).  It 
> > should be driven high at the TTL level.
> >
> 
> The wire in the same position as the brown one on a H7821 is purple on a H7822
> and they both seem to have the same function.  I ended up temporarily fitting
> a two 1000uF/25V capacitors on the lower board of my H7822 and reconnecting it
> to the upper board.  This gave me +5.1V on the purple wire and the CPU then
> ran ok for test purposes.
> 
> I have a VAX 4000/100A which has a Zytec Model EP 071181 power supply.  The
> only Digital reference on it is 30-35042-01.  It is the same physical form
> factor as the H7822.  The output connectors look the same, including the
> wire colours except +12V is brown instead of orange and this one has an
> extra connector for 3.3V (which is not used for anything in the 4000/100A).
> The reason I mention it is there is a list of output voltages on the label:
> +5.1V, +12.1V, +3.3V, -12V and -9V.  By a process of elimination, the -9V
> supply must be the grey wire (which gives me -8.2V when I put the meter
> on it.  All the other voltages are much closer to specification).
> 
> I wonder if the grey wire in the same position on the H7822 is also supposed
> to be -9V?  When I try to measure it on my H7822, I get a negative voltage
> but it is wandering around -4V.  In contrast, the -12V supply on the blue
> wire is a steady -11.99V, probably due to the 7912 regulator.  The same wire
> as the grey on the H7822 is yellow on a H7821.  I measured the voltage on a
> working H7821 and found a steady -0.2V which seems odd.
> 
> Do you know what the white wire is for?  I originally thought it might
> be power-good but only because the white wire on a H7816 seems to be
> power-good.  On the 30-35042-01, it is slightly above 0V.  On my H7822
> it is about 5.6V and on my H7821 it is 8.8V.

 In the H7821 it's -9Vdc return pairing with -9Vdc supplied on the yellow 
wire (an isolated circuit).  Pin numbers 14 & 13.  Try measuring voltage 
across the suspicious connections as any reference to ground may not be 
indicative.

 This voltage is also present with the H7819 PSU.  It's not clear to me 
what it is used for.

  Maciej

Re: DEC H7822 power supply

[Maciej W. Rozycki via cctalk]

Hi Peter,

> I still have the leaky electrolytics I removed from the POWER-ONE PSU in my
> Cisco IGS a while back.  I stored them with their leads up and goo seems to
> be still oozing out of some of them despite their inactivity and orientation.
> These ones are marked Nichicon PL(M) 4700uF/63V, 2200uF/16V and 330uF/35V and
> also have markings like H8950, H9018 and H8946 - maybe these are date codes?

 Right, my notes indicate Nichicon PL parts might be problematic too, e.g. 
one at 4700uF/10V on 5V output of the H7826 PSU.

> I also removed the smaller ones like 47uF/35V PF(M) H8952 for example but it
> is less clear to me whether these were leaking too or just got leaked on by
> the others.  There were only a few of them so I decided they were better out
> than in.  They all have similar coloured brown sleeves like the faulty ones
> in the DEC power supplies too.

 I can confirm now Nichicon PF 47uF/35V parts to be the source of an issue 
with my Bel Power.  All four leaked.  Thankfully I was able to fully 
revive that PSU (now in 24/7 operation).

> There are also the leaky 10uF/35V axial electrolytics in my LK201 keyboard.
> Those are in orange sleeves and marked "ESZ", whatever that is.  They have
> date codes like 8612.  I thought this might be a widespread problem but
> so far I have only found it in one keyboard.

 These are likely standard type parts.  I've yet to come across a low 
impedance axial capacitor type.  I may have missed something of course.

> Looks like I need to go back and recheck everything I thought wasn't leaking
> last time I checked :-(
> 
> Thing is, to check them, they have to come out of the case and that involves
> at least some change in orientation, except for contortionists...

 I doubt a temporary reorientation of parts you want to replace anyway is 
going to cause any trouble in that short amount of time.

> > Heat dissipated by the cap itself under high ripple current never helps 
> > and will surely speed up cap deterioration.  After all its service life 
> > halvens with each 10°C temperature rise even with non-faulty parts.
> >
> 
> When I was shopping for replacements, I was a bit alarmed to find that
> the maximum specified "endurance" (whatever that is) I could find was
> 5000 hours.  This isn't much more than a long life incandescent light bulb.

 Mind that it's at 105°C.  If you keep such caps operating at 65°C (which 
is still rather hot), then endurance raises to 8h (~9 years continuous 
use).

 Anyway try to chase replacements specified for at least 1h at 105°C.
Nichicon HE/UHE and Panasonic FR seem suitable replacements for Chemi-con 
SXF, Nichicon PL, surpassing old parts in terms of ESR/impedance/ripple 
and dimension-wise.

> All the leaking ones in DEC H7821 and H7822 PSUs I have come across so far
> are 1800uF/25V Chemicon with brown sleeves.  I think mine are all SXF
> but I am not 100% sure of that.  There are lots of other electrolytic
> capacitors in these power supplies but I've only looked closely at the
> larger ones.  All of the reservoir capacitors attached to the mains bridge
> rectifiers that I have seen look fine.  Maybe I need to go back and check
> the smaller ones though :-(

 I don't have any H7822 PSU.  Your experience with the H7821 is the same 
as mine though (and I still need to figure out what's wrong with one which 
still doesn't drive its power-good line active after recapping).  I used 
Nichicon HE P/N UHE1E182MHD as the replacement for those.  There does 
appear to be COVID-related shortage of this part (600 expected at Mouser 
15/03/2023, ugh!), which used to be readily available in large quantities 
several years ago.  However Panasonic FR P/N EEUFR1E182 is available in a 
small quantity (and is better).

> I think I came across some LXF ones that seemed to be ok, I can't remember
> where though.  I probably need to go find these and check them again :-(

 I came across LXF parts in one H7826 only and they were clean, but I 
chose to replace them as a precaution anyway as I've got stuck with trying 
to repair a couple of broken H7826 PSUs already still not working after 
cleaning the mess and replacing broken caps (mind that I'm a software 
engineer with enough hassle to sort out on the software side already).

> Here's a thought.  Apart from the keyboard, all the ones I have seen that
> are leaking are filtering the outputs of switch mode power supplies.  I
> wonder does the higher frequency of the ripple they are dealing with have
> a bearing on this?

 I've seen leaks from SXF parts on the primary side too with the H7826, so 
it is not that they only fail on the secondary side.  Also it is lower 
frequency ripple that's more problematic, see frequency correction factors 
for ripple current in datasheets, because impedance is higher at lower 
frequencies.  That's an inherent property of capacitance.

> I replaced the five leaking capacitors on the upper board in my H7822,
> disconnected the input to the lower 

Re: DEC H7822 power supply

[Maciej W. Rozycki via cctalk]

On Tue, 3 May 2022, Peter Coghlan via cctalk wrote:

> > Would the system have been possibly stored upside down sometime?
> >
> 
> I don't think so.  It may have spent some time lying on it's side due to
> deteriorating rubber feet and for ease of access and but I can't see any
> reason for it ever being upside down.  Once I discovered this issue a few
> years ago, I checked all my power supplies, removed any leaking capacitors
> and changed to storing the machines the right way up in a vertical stack,
> with newspapers between them in place of the rubber feet.  I hoped this would
> prevent any capacitors which hadn't shown any signs of leaking from starting
> to leak.  (Now whichever machine I want to work on always seems to be at the
> bottom of the stack...)

 Lying on a side would also permit leaking, I've seen an H7821 damaged in 
storage that way.  Gravity only helps with the leads up.

> >  These nasty caps do leak even while in storage (and even if never used, 
> > not even soldered ever, according to one source, a repair professional).
> >
> 
> They are nasty and devious.  In my case, the ones that have been stored in
> any orientation but not used much seem to have fared better.  I only started
> using this machine with the H7822 for extended periods for the first time a
> few months ago.  One of the reasons I started using it more is because I
> thought it was immune to the leaky capacitor problem!  It never saw any
> serious use before that, even when it was new.

 From experience Chemi-con SXF caps used with many DEC PSUs need to be 
urgently replaced.  Other Chemi-con lines reported affected are LXF, SXE 
and KME.  Products of the time from other manufacturers may be affected as 
well.  I'd have to check what line were those that leaked in a Bel Power 
PSU that I had to fix (I reckon you had a similar experience, right?).

> I have at least two machines with H7822 power supplies.  Even though they
> have capacitors that look the same as the ones in the H7821, the ones in
> the H7822 power supplies didn't seem to be showing any signs of leaking
> when I examined them some time ago so I thought they might be from a batch
> that was unaffected by the problem.  It seems that this was not true :-(

 It was the composition of the electrolyte that was outright wrong, so I 
doubt it's batch-related.

> I unsoldered the other eight similar capacitors (four one each board) from
> the H7822 yesterday evening.  I found a small amount of leakage under most
> of them but it was was only evident after they were removed from the board.

 Yes, it's been a common case.

> In general, there was less damage visible under the ones on the lower board
> with leads facing down oddly enough.  I thought one of the capacitors from
> the upper board had not leaked at all.  I left the removed capacitors
> standing on the bench overnight with their leads upwards and they all have
> some signs of leakage visible on them today.  It's hard to draw any
> conclusions.

 Once the seal has broken I guess all odds are off.  I could imagine 
capillary action to take effect.

> The capacitor from the upper board that leaked enough for me to notice it
> might be under greater stress when operating than the others.  I think the
> same capacitor in the H7821 power supplies seems to leak more in those too.

 Heat dissipated by the cap itself under high ripple current never helps 
and will surely speed up cap deterioration.  After all its service life 
halvens with each 10°C temperature rise even with non-faulty parts.

> I don't have enough spare capacitors to replace the four on the lower
> board.  I am going to leave those out, leave the input lead to that board
> unplugged and plug the green LED into the upper board.  I hope it will then
> behave just like a H7821.  There won't be any power to the front disk drive
> connector but I am not using that so it doesn't matter unless the "power good"
> output is affected, in which case I will have to think of something else.

 As a matter of interest what capacitance/voltage are those?  Are they of 
the Chemi-con/SXF type too?

  Maciej

Re: DEC H7822 power supply

[Maciej W. Rozycki via cctalk]

On Mon, 2 May 2022, Peter Coghlan via cctalk wrote:

> Thankfully, it doesn't seem to have been there long and didn't get a chance
> to spread around the board.  Bizarrely this capacitor has it's legs pointing
> upwards and managed to leak while there are similar capacitors on the other
> board with their legs pointing downwards which don't seem to have leaked 
> (yet?).

 Would the system have been possibly stored upside down sometime?

 These nasty caps do leak even while in storage (and even if never used, 
not even soldered ever, according to one source, a repair professional).

  Maciej

Re: PCI floppy controller

[Maciej W. Rozycki via cctalk]

On Thu, 21 Apr 2022, Chuck Guzis via cctalk wrote:

> I suppose it might be possible to fashion a legacy floppy controller on
> a PCI card with enough supporting logic to make it compatible with
> existing software, but I'm not aware of such an effort.

 You can of course build a PCI FDD interface around the NEC uPD765 or an
equivalent controller, but you can't make it compatible with existing PC 
software, because too much PC specifics has been embedded there around the 
8237 DMA controller and DMA page registers at fixed port I/O locations, 
which is inherently incompatible with the PCI decoding model.

 A feasible solution is a SCSI FDD option, such as the DEC RX23 device
(which is actually a whole embedded microcomputer built around an 8080 CPU 
and using an 8237 DMA controller, an 8259 interrupt controller, a uPD765 
floppy drive controller and a 5380 SCSI interface), which works as a 
removable drive with any single-ended parallel SCSI host adapter, e.g.:

scsi 2:0:4:0: Direct-Access DEC  RX23 (C) DEC 0054 PQ: 0 ANSI: 1 CCS

Such SCSI host adapters remain widely available as PCI and PCIe options.

 HTH,

  Maciej

Re: Retro networking / WAN communities

[Maciej W. Rozycki via cctalk]

On Mon, 11 Apr 2022, Grant Taylor via cctalk wrote:

> > I think "hub" is another word for "repeater" (just like "switch" is another
> > word for "bridge").
> 
> Interesting.
> 
> Do you know of any documentation, preferably not marketing materials, that
> used "repeater" in lieu of "hub"?

 As I recall back in mid 1990s nobody around at the university used to 
call plain 10BASE2 repeaters hubs.  We'd only call multiport 10BASE-T 
devices hubs (aka concentrators), where each port only serves one device 
in a point-to-point topology (i.e. no shared medium such as with 10BASE5 
or 10BASE2).

 We had a bunch (4 or 5) of IIRC 5-port 10BASE2 repeaters for our network 
at our hall of residence.  Each 10BASE2 port served ~20 hosts so as not to 
exceed 10BASE2's maximum segment length.  I'm not sure anymore if the 
repeaters had an AUI port; I think they did, but if so, it wasn't used.  
They were connected into one network via a bridge, which was an 80286 PC 
equipped with a corresponding number of NE2000 clones and running a piece 
of DOS software called Kbridge.  It was to reduce network congestion, 
which often happened anyway when multiple groups of people played 
networked (IPX) Doom all at a time.

 Also nobody would call a device a switch if it didn't do cut-through.  
We'd call devices doing store-and-forward only bridges; after all there's 
no actual circuit switching in store-and-forward.

 I guess these terms became fuzzier with time as non-techies started 
confusing them.

 FWIW,

  Maciej

Re: VAX9000 unearthed

[Maciej W. Rozycki via cctalk]

On Fri, 18 Feb 2022, Paul Koning via cctalk wrote:

> From what was just reported, the 6000 series indeed did it that way.  
> But I think on the 9000 it was an I/O bus too.  I definitely remember 
> some work on XMI based I/O devices, in particular an FDDI card.  And 
> indeed you can find a spec for that device in 
> http://www.bitsavers.org/pdf/dec/xmi/ .

 Also: 
.

  Maciej

Re: More switchmode power supply grief - Cisco IGS router

[Maciej W. Rozycki via cctalk]

On Sun, 6 Feb 2022, Peter Coghlan via cctalk wrote:

> >  NB Mouser has the MAP80-4000G in stock actually, so if all else fails and 
> > you are determined to get the IGS running, you can pick a brand new one: 
> > .
> > 
> 
> Thanks again Maciej.
> 
> I've bit the bullet and unsoldered most of the electrolytic capacitors and
> other components that seem to be in trouble.  When I got the chopper
> transistor out, I found that if I hold it at exactly the right angle to
> the light, I can see that there are faint markings on it after all and it
> turns out to be an IRFPE50 HEXFET.  I was wrong about the cracked RIFAs
> not being mains filters too, they are actually across L-E and N-E and
> they seem to have between a few hundred kOhms and a few MOhms leakage too.
> The driver transistor looks like it might be ok.

 It seems like great progress!  Yes, those etched markings are sometimes 
hard to decipher, requiring looking at the correct angle with light coming 
from the right direction too and/or techniques used to take fingerprints 
at a crime scene.  With these details known you may be able to actually 
get this sorted just by yourself.  Good luck again!

  Maciej

Re: Wanted: Pinout IDT 49C402 PGA84

[Maciej W. Rozycki via cctalk]

On Thu, 10 Feb 2022, Holm Tiffe via cctalk wrote:

> Has anyone a databook newer than 1989 where the PGA84  Pinout is listed?

 It seems like datasheetarchive.com has a copy of a 1995 datasheet listing 
what you need ("IDT49C402/A/B 16-BIT CMOS Microprocessor Slice", IDT doc 
#9011; original, not a scan).  I have just downloaded it.

 Shall I send it to you or will you grab it yourself?

  Maciej

Re: More switchmode power supply grief - Cisco IGS router

[Maciej W. Rozycki via cctalk]

On Sat, 5 Feb 2022, Peter Coghlan via cctalk wrote:

> >  This PSU seems to have been used across various Cisco devices and I had 
> > one fail several years ago in a WS-C1202 Ethernet/FDDI switch, also having 
> > suffered from leaking caps.  Back then RS still had it in stock at a hefty 
> > price of £489.60: , so I 
> > chose to recap the failed one and thanfully it has continued working ever 
> > since.  You may try to enquire with the manufacturer.
> > 
> >  Good luck with bringing yours back to life!
> >
> 
> Thanks Maciej.  I'll be surprised if the manufacturer has records of
> what they used for the chopper in power supplies 30 years ago - who
> knows if their design has changed between then and now.  I'll be even
> more suprised if they will talk to me about it but I guess it's worth
> a try.

 I've checked their web site and they continue to offer a MAP80-4000G, 
which I suppose is just a minor update from the original, and is visually 
the same, as it seems from the datasheet dated 2021.  So I'm fairly sure 
they have all the data.  Those discrete semiconductor components do not 
change much, I was able to order exact replacements for another faulty 
device from 1990s a few years ago.

 They may offer you a paid repair or replacement service or if you're kind 
enough and they are reasonable, they may identify the single part for you.

 NB Mouser has the MAP80-4000G in stock actually, so if all else fails and 
you are determined to get the IGS running, you can pick a brand new one: 
.

 Good luck!

  Maciej

Re: More switchmode power supply grief - Cisco IGS router

[Maciej W. Rozycki via cctalk]

On Thu, 3 Feb 2022, Peter Coghlan via cctalk wrote:

> Today I finally managed to check it out.  The ceramic F4A mains input fuse
> beside the power switch on the back panel had blown.  When I opened it up,
> I found a POWER-ONE MAP80-4000 power supply.  The main chopper transistor
> labelled Q1 on the PCB is almost a dead short.  It is a large plastic
> packaged FET mounted on a piece of aluminium which is in turn screwed to
> the case for heatsinking.  Unfortunately, there are no markings on it so
> I have no idea what to replace it with :-(
> 
> As Q1 is shorted across all three terminals, whatever drives it may be
> damaged too :-(
> 
> After finding screw heads hidden under the label, I managed to extract
> the PCB from the case and found some corrosion underneath, possibly from
> leaking electrolytic capacitors :-(

 This PSU seems to have been used across various Cisco devices and I had 
one fail several years ago in a WS-C1202 Ethernet/FDDI switch, also having 
suffered from leaking caps.  Back then RS still had it in stock at a hefty 
price of £489.60: , so I 
chose to recap the failed one and thanfully it has continued working ever 
since.  You may try to enquire with the manufacturer.

 Good luck with bringing yours back to life!

 FWIW,

  Maciej

Re: Origin of "partition" in storage devices

[Maciej W. Rozycki via cctalk]

On Tue, 1 Feb 2022, Liam Proven via cctalk wrote:

> One of our favourite small PC builders, Panrix, questioned this. They
> reckoned that having the swap file on the outer, longer tracks of the
> drive made it slower, due to slower access times and slower transfer
> speeds. They were adamant.

 With contemporary ATA hard disks (and also SCSI disks) obviously the 
opposite was the case, due to the ZBR sector mapping scheme.  The outer 
cylinders had the fastest transfer speeds.  Verified many times with 
actual benchmarking of partitions placed at different parts of various 
disks (only with Linux however).

 I only ever came across a single very old WDC ATA disk that had a fixed 
sector count per track/cylinder like a floppy (and also a stepper rather 
than linear motor for the head assembly, which obviously affected seek 
characteristics) and consequently whose transfer speed was the same all 
across the surface.

 FWIW,

  Maciej

Re: Origin of "partition" in storage devices

[Maciej W. Rozycki via cctalk]

On Mon, 31 Jan 2022, Fred Cisin via cctalk wrote:

> File sizes were stored as the last 4 bytes of each DIRectory entry, with a
> signed 32 bit number. So, a file could be from
> -2,147,483,648 to 2,147,483,647
> Unfortunately, they never successfully finished the implementation, so copying
> a negative size file to the drive did not increase the free space.  Since they
> didn't make THAT work, perhaps they should have used an UNSIGNED 32 bit
> number, to permit files up to 4,294,967,295

 Consider the file seek operation however: with the file size limited to 
the 31-bit positive range of the signed 32-bit data type you can move the 
file offset backwards and forwards through the entire range with a single 
operation using the same data type.  It would not be possible if the data 
type was unsigned and all the 32 bits used for the file size.

  Maciej

Re: DEC 3000/600 Alphaserver problems

[Maciej W. Rozycki via cctalk]

On Wed, 12 Jan 2022, Jon Elson via cctalk wrote:

> > Thanks Jon.
> > 
> > Here is a badly focused picture of the suspect components:
> > 
> > http://www.beyondthepale.ie/cctech/p1010198.jpg
> 
> WOW, I don't know what those are!  They look like big ceramic caps to me, but
> if they don't have any polarity marking, then they can't be Tantalum.  Big
> multilayer ceramics are prone to cracking due to board flexing, and that can
> cause catastrophic failure, too.

 They do look like tantalum caps to me, e.g.:



The pointed end indicates polarity.

  Maciej

Re: Mounting ULTRIX CDROMs on Linux

[Maciej W. Rozycki via cctalk]

On Fri, 21 May 2021, Maciej W. Rozycki wrote:

>  ISTR upstreaming some fixes to Linux UFS support 20+ years ago to address 
> this very problem (IIRC OSF/1 or Digital Unix CD-ROMs were also UFS, and I 
> had a need to access them under Linux for some reason) and with them in 
> place I thought the loop device hack was not needed anymore.
> 
>  Perhaps my memory tricks me or something has since regressed though, e.g. 
> due to changes in the block layer, so I'll try to remember to see what's 
> happened here when I get to my Ultrix CDs when I'm in my remote lab next 
> time.  It's not a feature that's used on a regular basis after all, so any 
> regression can be long-lived.

 I remembered right.  An old Linux 2.4.26 kernel binary mounts a UFS CD 
here using the old IDE hardware driver just fine with no need for block 
size translation via the loop device:

# mount -t ufs -o ro,ufstype=old /dev/hdc /mnt/cdrom
# mount | grep ufs
/dev/hdc on /mnt/cdrom type ufs (ro,ufstype=old)
# uname -a
Linux (none) 2.4.26 #8 SMP Sat Aug 14 21:00:06 CEST 2004 i586 unknown unknown 
GNU/Linux
# 

Not anymore with Linux 2.6.18 or anything newer:

# mount -t ufs -o ro,ufstype=old /dev/hdc /mnt/cdrom
mount: wrong fs type, bad option, bad superblock on /dev/hdc,
   or too many mounted file systems
# dmesg | tail -n 1
UFS: failed to set blocksize
# mount -t ufs -o loop,ro,ufstype=old /dev/hdc /mnt/cdrom
# mount | grep ufs
/dev/hdc on /mnt/cdrom type ufs (ro,loop=/dev/loop0,ufstype=old)
# uname -a
Linux (none) 2.6.18 #9 SMP Sun Nov 26 18:31:10 GMT 2017 i586 unknown unknown 
GNU/Linux
# 

So we do have a regression here, sigh.  I'll see what I can do about it, 
but it'll have to wait a bit as I won't have local lab access for a while 
and I dare not leaving a CD in the drive while I am away.

  Maciej

Re: PCIe/PCI I/O access (was: Re: VT340 Emulation)

[Maciej W. Rozycki via cctalk]

On Sun, 27 Jun 2021, Kevin Bowling wrote:

> Thanks this was interesting learning.

 You are welcome!

 NB I think it is also worth noting that the presence of I/O instructions 
and corresponding bus cycles with x86 is most relevant for PCI as it is 
only *because* x86, or more importantly the PC/AT architecture, has had 
them in the first place that PCI (and consequently PCIe) has them as well. 
Likewise the interrupt acknowledge or the special cycle bus transactions 
-- they're both x86-specific, even if they may have been later repurposed 
in non-x86 PCI system designs.

 Intel was a key player in PCI design and surely their requirements were 
first-class citizens in the solution proposed.  While early PCI systems 
commonly had PCI and ISA/EISA buses arranged as peers on the CPU host bus, 
with the respective bridge chips being two of the three or more agents 
arbitrated there (the remaining ones being the CPU(s)), the ability to 
route x86-specific bus cycles over PCI eventually let the industry settle 
on PCI x86 systems of the common northbridge/southbridge architecture we 
saw so many specimens of, where I/O address space resources originating 
from the PC, PC/XT, and PC/AT architectures can be accessed behind a PCI 
bus segment just as if they were attached directly to the CPU, possibly 
via some bus buffers only, like with the original IBM design from 1981.

 Similarly an x86 CPU can send an interrupt acknowledge cycle over PCI to 
request an interrupt vector from an 8259A interrupt controller core 
present in the southbridge, or a shutdown special cycle, in response to a 
triple fault, so as to make the southbridge assert a CPU reset, just like 
the original discrete PC/AT circuitry did.  None of this is really needed 
by non-x86 systems, although again these features may have been repurposed 
now that they are present (Intel has since invented additional special CPU 
cycles too, used in power management and intepreted by the southbridge), 
and numerous host bridges used with non-x86 systems have dedicated CSRs in 
the memory address space for issuing these PCI bus cycles, which the CPU 
cannot natively produce.

 BTW it wasn't exactly obvious to me that a flood of:

LPC[000]: Got SYNC no-response error. Error address reg: 0xd0010014
IPMI: dropping non severe PEL event

messages produced by the system firmware to the console serial port was a 
symptom of a PCI device driver trying to poke at the port I/O address of 
0, correctly left by the OS in the relevant device's BAR (Base Address 
Register) along with the disabled status for I/O decoding in the device's 
PCI Command Register.  The driver, not platform-specific and unaware of 
the possibility of the inexistence of the PCI I/O address space in some 
systems, ignored the disabled status of I/O decoding with the device and 
just went ahead and poked at it, confusing the host bridge with the bus 
accesses that resulted (likely an OS bug too with port I/O address space 
accessors, though I wasn't inclined enough to chase it); of course the 
port I/O address of 0 itself has no particular meaning with non-x86 
systems and can be legitimately assigned and used with PCI devices.

 FWIW,

  Maciej

PCIe/PCI I/O access (was: Re: VT340 Emulation)

[Maciej W. Rozycki via cctalk]

On Sun, 27 Jun 2021, Paul Koning wrote:

> > However both serial and parallel ports remain reasonably available as 
> > PCIe option devices.  Though parallel ports seem to be made as legacy PCIe 
> > devices only, that is accessed with I/O rather than memory read/write bus 
> > cycles, which are not, as I have learnt the hard way recently, supported 
> > by all computer systems nowadays.  I guess x86 systems will continue to 
> > support them however as x86 CPUs have native I/O access instructions.
> 
> I/O cycles on PCI have no direct connection to I/O instructions.  I've 
> routinely used I/O operations in PCI on a MIPS platform, which of course 
> has no such concept; all that was needed is to send the memory cycles to 
> the address block that the PCI bridge maps onto I/O cycles rather than 
> memory cycles.

 That's not my point.  The host bridge has to implement them and some do 
not (e.g. the POWER9 PHB4).  For CPU architectures that do not have native 
I/O cycle support an MMIO window has to be defined by the host bridge for 
memory cycles decoded within that window to be forwarded downstream as 
PCIe I/O Read/Write TLPs (likewise with legacy PCI I/O Read/Write cycles).  
If you don't define such a window along with associated circuitry (like 
with the PHB4), then there's simply no way to produce I/O TLPs on PCIe.

 When you have a CPU architecture such as x86 that does do I/O cycles 
natively, then they're just forwarded by the host bridge as PCIe I/O 
Read/Write TLPs.  Of course one can envisage an x86 host bridge that won't 
forward I/O cycles produced by the CPU to PCIe and will either terminate 
them with a bus error or let them time out, but I find it highly unlikely.  
For one I suspect the circuitry required to terminate unclaimed host bus 
I/O cycles is no less expensive than one to just forward them downstream; 
after all a PCIe I/O TLP is told apart from a memory TLP merely by a 
difference in a bit pattern sent downstream that encodes the cycle type, 
one of several (likewise with PCI cycles).

 NB PCIe I/O Read/Write TLPs have been deprecated ever since the first 
revision of the PCIe specification and PCIe devices that do require I/O 
TLPs for operation have always been referred to as legacy PCIe devices.  
I guess support for such devices has been added to the specification so as 
to aid the industry with switching entirely to the MMIO operating model, 
with initial PCIe devices expected to be implemented by placing the 
original PCI/PCI-X ASIC behind a PCIe-to-PCI bridge, until new PCIe ASICs 
have been made.  For some option cards it seems the only way to date, e.g. 
PCIe ATM network adapters.

 As it has turned out actual PCIe ASICs have been manufactured that do 
require I/O Read/Write TLPs for their operation such as said IEEE 1284 
parallel ports.  It's not actually clear to me why, but a plausible 
explanation is they have been considered too niche at that point for the 
effort required for the OS drivers to be updated.

  Maciej

Re: VT340 Emulation

[Maciej W. Rozycki via cctalk]

On Fri, 25 Jun 2021, Paul Koning via cctalk wrote:

> > Well you can find mother boards with real COM port, but they are rare.
> 
> One place you can find them easily is on industrial computers.  My 
> firewall machine is one, because I wanted it to be fanless.  It has the 
> usual pile of USB ports and HDMI, but also 2 COM ports; another model of 
> that same line has 6 COM ports.
> 
> What seems to be harder to find is a parallel printer port, but there is 
> far less reason to want one of those.

 However both serial and parallel ports remain reasonably available as 
PCIe option devices.  Though parallel ports seem to be made as legacy PCIe 
devices only, that is accessed with I/O rather than memory read/write bus 
cycles, which are not, as I have learnt the hard way recently, supported 
by all computer systems nowadays.  I guess x86 systems will continue to 
support them however as x86 CPUs have native I/O access instructions.

  Maciej

Re: Mounting ULTRIX CDROMs on Linux

[Maciej W. Rozycki via cctalk]

On Thu, 20 May 2021, Christian Groessler via cctalk wrote:

> IIRC I had burned the Ultrix CD "normally" (means without fiddling with block
> size, so not 512), but changed the block size to 512 for booting it. IIRC #2,
> burning was done on another drive, not the Plextor.

 CD-ROM medium format has been standardised and what I guess the 512-byte 
sector size jumper only does is logical translation of sector addressing 
to fulfil weird OS requirements.  So that will not affect burning (unless 
you burn on a weird OS, which I guess does not support it anyway).

 ISTR upstreaming some fixes to Linux UFS support 20+ years ago to address 
this very problem (IIRC OSF/1 or Digital Unix CD-ROMs were also UFS, and I 
had a need to access them under Linux for some reason) and with them in 
place I thought the loop device hack was not needed anymore.

 Perhaps my memory tricks me or something has since regressed though, e.g. 
due to changes in the block layer, so I'll try to remember to see what's 
happened here when I get to my Ultrix CDs when I'm in my remote lab next 
time.  It's not a feature that's used on a regular basis after all, so any 
regression can be long-lived.

  Maciej

Re: Melted computer feet

[Maciej W. Rozycki via cctalk]

On Wed, 19 May 2021, Zane Healy via cctalk wrote:

> I’m trying to determine if I can revive the VAXstation 4000/90 I 
> received from a list member, back around 1998 (it’s never worked).  
> When I pulled it out, I discovered that its feet have melted, and I’m 
> assuming probably made a mess on the disk enclosure for my VAXstation 
> 3100 that it was on top of.

 I always use IPA with this stuff, as I did with my VAXstation 4000/90 
which suffered from this very problem many years ago.  I tend to use 3M 
replacement feet then, some of which I've had for 20+ years now with no 
sign of deterioration so far, longer than the original DEC feet survived.  
I'd have to look up the P/N though as I don't have it handy.

 HTH,

  Maciej

Re: That VAXStation4000vlc 3W3 video connector

[Maciej W. Rozycki via cctalk]

On Tue, 4 May 2021, Jonathan Stone via cctech wrote:

>  You need a video cable with a 3W3 connector on one end. Original was likely 
> a DEC BC29G-10.
> That, plus 5BNC-to-VGA cables, and 3 F/F BNC barrels, will work with a 
> multisync monitor that handles sync-on-green.
> 
> I just went through this with several DECstations, where the Turbochannel 
> graphics options have the same 3W3 connector.

 Or track down a 17-04816-01 part, which is a 6ft DA3W3M-to-DE15F adapter 
cable (original DEC designation "CABLE ASSY,RND,VIDEO,3W3, 15POS HD") you 
can wire an ordinary analog VGA cable directly to.  Much neater and easier 
than fiddling with bulky BNC adapters only to get to a VGA connector which 
is not a proper coax line anyway.

 Sadly I've got only two of those and would easily now have a use for at 
least four, but I considered $66 per piece ~20 years ago a tad expensive 
(and back then only had two video adapters that would require one anyway).

 Cf. .

 Failing either solution you can make your own adapter cable: 

 



(you'll also need a case for the connector, the other connector and a 
length of suitable cable of course).  They have a US site too.

 HTH,

  Maciej

Re: OT: Newsreader for Windows

[Maciej W. Rozycki via cctalk]

On Thu, 1 Apr 2021, Grant Taylor via cctalk wrote:

> There is probably also the option of using the TUI news readers in / via
> Windows Services for Linux (?is that the proper name for /today/?).

 I have never used that port myself, but there's PC-Alpine worth 
considering, which I believe uses native Windows networking services and 
also has a classic touch to it.  Compilation instructions are here: 
, or 
check:  or: 
 for 
64-bit and 32-bit x86 binaries respectively (checksums are published at 
).

 Naturally it handles both e-mail and news, and you can cross-post if you 
feel like.

 FWIW,

  Maciej

RE: VAXstation 2000 network & hardware guides (English & German)

[Maciej W. Rozycki via cctalk]

On Sat, 20 Mar 2021, Dave Wade G4UGM via cctalk wrote:

> These arrived this morning and they are scanned and OCR'd here:-
> 
> https://1drv.ms/u/s!Ag4BJfE5B3onlY9td7hHhHPnUKV2bA?e=hDKwES
> 
> I think I can scan at lower resolution and/or grey scale as these are a 
> bit on the huge side

 Storage is cheap nowadays so I'd keep whatever the master copy is at good 
quality.  You can always convert to a lower resolution or a lossy format 
later on if you need to save space, but you can't recover lost fidelity 
once you've done so.

  Maciej

Re: 80286 Protected Mode Test

[Maciej W. Rozycki via cctalk]

On Sun, 14 Mar 2021, Liam Proven via cctalk wrote:

> > I should also note, that the other way to get back to real mode from
> > protected mode is via a triple-fault.  What gets me (and I railed on
> > Intel when I worked there for a time) that it still existing in the
> > architecture even though they have a machine check architecture now
> > (which while at IBM pushed Intel to implement for the '386!).
> 
> (!)

 Well, software exists that relies on the triple-fault feature for reboots 
including current versions of Linux (you can trigger a triple-fault in the 
real mode too).  These days it is implemented by the southbridge catching 
the shutdown special cycle on PCI and asserting the reset pin to the CPU 
(the details might be slightly different for PCIe or HyperTransport).

 Back in the day I experimented with that stuff myself and all the weird 
ways to switch between modes with the x86, setting the IDTR in the real 
mode for interesting effects which would impress fellow students, etc.  I 
ended up writing this:  
as a result.  I wrote a simple resident VM86 monitor for DOS too, just to 
fiddle with processor features.

 Also resetting the CPU with the shutdown code of 0xa put at the location 
0xf of the RTC/NVRAM chip was the only way to get the family, model, and 
stepping ID in the EDX register for old processors that did not have the 
CPUID instruction (i.e. all 80386 and many 80486 implementations), unless 
the system BIOS clobbered it for no good reason in the short bypass code 
involved (sadly sometimes that did happen).  I just double-checked my old 
DOS assembly code to see if I got the details right!

 NB I didn't know LOADALL would not work for switching from the protected 
to the real mode and did not find out about the instruction until after I 
already lost access to any 80286 hardware, so I never experimented with it 
myself.

  Maciej

Re: 80286 Protected Mode Test

[Maciej W. Rozycki via cctalk]

On Sun, 7 Mar 2021, Noel Chiappa via cctalk wrote:

> > The 286 can exit protected mode with the LOADALL instruction.
> 
> Really? So why all the hullabaloo about Triple Faults:
> 
>   http://www.rcollins.org/Productivity/TripleFault.html
> 
> back in the day; and why did IBM set up the keyboard controller so it could
> send a RESET signal (so people could get out of protected mode)? Or is it
> that LOADALL (which was also undocumented early on, so maybe that's why the
> IBM thing) could be used to cause a triple fault?

 The existence of LOADALL (used for in-circuit emulation, a predecessor 
technique to modern JTAG debugging and the instruction the modern x86 RSM 
instruction grew from) in the 80286 wasn't public information for a very 
long time, and you won't find it in public Intel 80286 CPU documentation 
even today.  Even if IBM engineers knew of its existence at the time the 
PC/AT was being designed, surely they have decided not to rely in their 
design on something not guaranteed by the CPU manufacturer to exist.

 As to why they choose to add the keyboard controller hack I think the 
article referred gives a hypothesis that is as good as you can get: they 
were not clever enough.  Back in the day this wasn't the only fault they 
made and it was a harmless one anyway, because you didn't have to use the 
hack in your software if you knew the proper way.

 Much worse was the mess around the incorrect wiring of the FPU exception 
line (to IRQ #13 via additional glue logic rather than its dedicated CPU 
input), which could have been easily avoided while retaining PC/XT 
compatibility in a manner similar to how it was implemented in the BIOS 
for IRQ #13.  Consequently functionality of the exception was lost (the 
exception was supposed to be precise unlike obviously the external IRQ) 
and also if you were not careful enough in handling it, the machine would 
lock up hard and you'd have to hit the reset button.

 The mess with the FPU exception was actually one of the two reasons to 
drop 32-bit x86 Linux support for the original 80386 CPU several years ago 
(the other one was the lack of write protection in the kernel mode for 
user pages).  Support now starts from the 80486:

$ uname -mrsv
Linux 5.11.0+ #13 Mon Mar 8 00:14:59 CET 2021 i486
$ 

  Maciej

Re: Intel Developers' Insight CD-ROM collection archived anywhere?

[Maciej W. Rozycki via cctalk]

On Thu, 1 Oct 2020, Glen Slick via cctalk wrote:

> >  Sadly neither seems to be among the files I have copied.  I could yet
> > check Intel Dec 1995 Data on Demand discs I happen to have, and do have
> > here, but they are cumbersome to handle as they use a proprietary format
> > requiring a DOS app to access, and yet more hassle to get anything
> > exported (assuming I can recall how I did that many years ago), so it'll
> > take a little.
> 
> If you have some Intel "Data on Demand" CD-ROMs it would be nice if
> .ISO images of those could be captured and uploaded somewhere. Then
> leave it up to anyone interested to deal with extracting documents
> from them.

 Hmm, I'm not sure of the copyright status, even that those were available 
free of charge.  It would be good to have the stuff preserved though, so 
I'll see if I can get some ack from Intel.  I have good experience overall 
with such enquiries.  Ditto about the Insight CDs.

> I found this document while looking online. It's not clear to me if
> that is a list of documents that are contained on the December 1995
> "Data on Demand" CD-ROMs or if some of those are only available
> elsewhere.
> 
> http://alt.ife.tugraz.at/datashts/intel/litguide.pdf

 This looks to me like a list of orderable hardcopy documents.  I still 
have a long line of those on a bookshelf.  But indeed most if not all were 
available on said CDs, and some were only there.

 Anyway, sorry to take so long, but such is life.  I finally got to my set 
of Insight CDs and guess what?  First that I looked at was October 1996, 
my oldest, and it does have what you look for:

$ ls -la fbldr16*.zip
-r-xr-xr-x  1 root root 4619852 Jul  8  1996 fbldr16.zip
-r-xr-xr-x  1 root root 1359076 Jul  8  1996 fbldr16a.zip
-r-xr-xr-x  1 root root 1253664 Jul  8  1996 fbldr16b.zip
-r-xr-xr-x  1 root root 1076370 Jul  8  1996 fbldr16c.zip
-r-xr-xr-x  1 root root  930808 Jul  8  1996 fbldr16d.zip
$ 

 Do you still need it?  I have lost the FTP site I used to host things on
and I can't afford the time to set up a new one right away.  But I can 
e-mail you this stuff offlist if your mailbox can swallow it.  The choice 
is either one big file, first in the listing above, or the other four, 
which are the same contents, split, that I would send in a separate e-mail 
each.  I could split it further too, I know how it worked in the old days.

 By the look of it all the documentation included with FLASHBuilder is in 
the form of MS Windows help files rather than PDF.

 Either way please let me know.

  Maciej

Re: Atari ST diskettes

[Maciej W. Rozycki via cctalk]

On Wed, 2 Dec 2020, Liam Proven via cctalk wrote:

> If you don't get much response here, for many of whom I suspect the ST
> is a bit modern, let me know and I can share it on some relevant
> groups on FB for you. Anonymised or obscured as you prefer.

 Well, I guess for some anything that does not require you to toggle in 
the boot loader or doesn't have a teletype console terminal is surely too 
modern to even consider.

  Maciej

Re: The best hard drives??

[Maciej W. Rozycki via cctalk]

On Fri, 20 Nov 2020, Peter Corlett via cctalk wrote:

> That same $100 widget imported into the UK becomes $120 due to the 20% VAT
> rate, which comes to £90, but the UK has its own self-inflicted problems which
> cause importers loads of extra costs and £100 is easily believable.

 Don't forget a fixed per-clearance administrative fee, covering all the 
bureaucratic processing, will easily fill the missing £10 (exact amount 
varies by the carrier).  For an item worth $20 received via Royal Mail I 
recently paid £13.31 customs charges: £5.31 VAT + £8.00 handling fee -- 
almost doubling the nominal value of the item (and that does not include 
postage!).

  Maciej

Re: WTB: AUI cables

[Maciej W. Rozycki via cctalk]

On Tue, 17 Nov 2020, Grant Taylor via cctalk wrote:

> > Those seem rather high priced to me.
> 
> Ya.  They are actually (just barely) higher than I can find them on eBay
> ($20).
> 
> Maybe I'm being a cheapskate.  I like the $5 price a lot better.  I think
> that's much closer to what I paid at Peoria Super Fest years ago for them.
> They were falling off the back of multiple trucks.

 Well, you can't expect consumer prices for pro's stuff and then uncommon, 
niche one, can you?  Even if it once used to be consumer's and common.

 This is hardly more than I recently paid per piece, not including postage 
across the pond, for a bunch of suitably long three-way IEC 60320 C13/C14 
leads for use with a remotely controlled PDU.  Which is considerably less 
advanced a piece of technology than an AUI cable.

 And things do get yet worse if space constraints such as with some DEC 
gear mandate that you use a right-angle AUI cable.  Then you get this:

https://www.insight.com/en_US/shop/product/LCN216-0003/BLACK%20BOX/LCN216-0003/Black-Box-Ethernet-Transceiver-Cable-IEEE-8023--Ethernet-AUI-cable--3-ft--gray/

Mind that this is whole 3ft!

 And then if you're lucky enough, you get just about anything for free.

  Maciej

Re: WTB: AUI cables

[Maciej W. Rozycki via cctalk]

On Tue, 17 Nov 2020, Paul Koning via cctalk wrote:

> One is from Black Box, at an insane price, with actual AUI style (slide 
> lock) connectors.
> 
> There are several others that are much less expensive, with regular 
> screw lock DA-15 connectors.  And of course cables with those connectors 
> are readily available from the usual suspects (I like L-com).

 In maybe 2 minutes of clicking I found these reasonably priced and using
standard slidelock assemblies, sold brand new on both sides of the pond:

http://www.computercableinc.com/ccinc/products.jsp?sub=AUI+Transceiver=2041
http://www.pacificcable.com/Picture_Page.asp?DataName=TRAN-6
https://www.betterbox.co.uk/products/5m-thick-aui-transceiver-drop-cable-m-f-et0022.html

> FWIW, there exist adapters from slide latch to screw lock DA-15; I have 
> one I bought from L-com so I could attach a 10BaseT transceiver with 
> slide lock posts to my Pro-380, which has a screw lock DA-15 connector 
> for its Ethernet port.

 Slidelock assemblies and individual parts of those are sold separately, 
for all shell sizes actually, in retail quantities by the usual suspects 
(Mouser, Farnell/Newark, RS, etc.), so with suitably designed connectors 
(i.e. ones that accept 4/40 UNC jack posts rather than thumb screws only; 
not all unfortunately) these could be used to replace original screwlock 
bits.  I used these sources on a couple occasions to replace damaged or 
missing parts.

  Maciej

Re: FYI sunhelp.org down

[Maciej W. Rozycki via cctalk]

On Wed, 14 Oct 2020, Grant Taylor via cctalk wrote:

> > I suppose the list server relies on the same nameservers in a way that
> > prevents e-mail distribution from happening.
> 
> I don't think so.  At least I thought that the hot wiring that I did to my
> mail server only effected /sending/ of email.
> 
> The changes I made to the DNS server would have effected /receiving/ of email.
> 
> I have successfully sent a message to the geeks@sunhelp mailing list /and/
> received my copy of said message from said mailing list.
> 
> > I have since resubmitted the same message manually to sunhelp.org's SMTP
> > receiver (the original message is still in the outgoing mail queue:
> > 
> > smtp/sunhelp.org: B/W/23993316: (196 tries, expires in 2d17h) smtp; 466 (No
> > DNS response for host: sunhelp.org; h_errno=0)
> > 
> > ) to see what happens and got a DSN ack even, but the message did 
> > not get through.
> 
> Were you sending a message to geeks@sunhelp or a different address?

 It was to .  The resubmitted message eventually made 
it through last Tue, Oct 20th, after a week of being held:

Received: from ohno.mrbill.net ([184.94.207.190]:57765 "EHLO ohno.mrbill.net"
rhost-flags-OK-FAIL-OK-FAIL) by eddie.linux-mips.org with ESMTP
id S23991030AbgJTMxVN8USJ (ORCPT );
Tue, 20 Oct 2020 14:53:21 +0200
Received: from ohno.mrbill.net (localhost [127.0.0.1])
by ohno.mrbill.net (Postfix) with ESMTP id E173B1E0DF9;
Tue, 13 Oct 2020 22:55:12 -0500 (CDT)
X-Original-To: res...@sunhelp.org
Delivered-To: res...@mrbill.net
Received: from cvs.linux-mips.org (eddie.linux-mips.org
[148.251.95.138]) (using TLSv1 with cipher AES256-SHA (256/256 bits))
(No client certificate requested) by ohno.mrbill.net (Postfix) with
ESMTPS id 84C0D1E0915 for ; Tue, 13 Oct 2020
22:55:10 -0500 (CDT)

which I think does coincide with the revival of mrbill.net services:

   Domain Name: MRBILL.NET
   Registry Domain ID: 137_DOMAIN_NET-VRSN
   Registrar WHOIS Server: whois.namecheap.com
   Registrar URL: http://www.namecheap.com
   Updated Date: 2020-10-19T15:39:08Z

and makes me conclude my suspicion was right.

> > So local hot wiring of name resolution (which I suppose could be as easy as
> > adding a /etc/hosts entry rather than going through the hoops of setting up
> > a manipulated name server) might be good enough to get at the web pages, but
> > not to get the list going.
> 
> Ya ... email tends to be more reliant on DNS.  At least unless you explicitly
> tell it to not use it for specific domains.  And that's exactly what I did.  I
> hard (hot) wired email routing so that email for sunhelp.org goes to
> ohno.mrbill.net, which is resolvable do to my DNS hot wiring (forwarders).

 I wish it was the case.  The admin of linux-mips.org, a friend of mine, 
has vanished since the outbreak of the COVID-19 pandemic in Europe last 
March -- I do hope nothing wrong has happened to him and he does surface 
sometime.

 Anyway, he's the only one who can remove a stale /etc/hosts entry here 
for vger.kernel.org, which prevents me from posting to any Linux kernel 
mailing lists hosted there unless I resort to some horrible hacks, which 
in turn tend to randomly break sending e-mail elsewhere.  Sigh...

  Maciej

Re: non-shunting jumpers?

[Maciej W. Rozycki via cctalk]

On Thu, 22 Oct 2020, Wayne S wrote:

> I’ve just stripped off a short piece of insulation from hookup wire and 
> slipped it over the pin.Fits tight and can be removed and it's cheap.

 I guess it's as cheap as you can get. :)

  Maciej

Re: non-shunting jumpers?

[Maciej W. Rozycki via cctalk]

On Thu, 22 Oct 2020, Chuck Guzis via cctalk wrote:

> > A variation on the connector idea: use an insulation-displacement type 
> > connector (the kind that you mount onto a flat cable assembly) without 
> > the cable.  Just snap on the cover over the i-d pins and you have a 
> > fully insulated assembly with the pins acting as spring clamps for the 
> > jumper pins.
> 
> That's not terribly useful when you have only one or two positions to
> protect, is it?

 Following the idea however you can use a wire-to-board connector housing 
like from Harwin M20 series with just empty contacts inserted.  They are 
widely available and start from 1x1 even.



  Maciej

Re: FYI sunhelp.org down

[Maciej W. Rozycki via cctalk]

On Wed, 14 Oct 2020, Grant Taylor via cctalk wrote:

> > I posted to  and saw my message got stuck in the mail
> > queue.
> 
> When did you send your message?  I'm trying to judge when the problem started.

 Last Mon, Oct 12th.  The last message I received from the mailing list 
was on Oct 1st.  WHOIS has this though:

   Domain Name: MRBILL.NET
   Registry Domain ID: 137_DOMAIN_NET-VRSN
   Registrar WHOIS Server: whois.namecheap.com
   Registrar URL: http://www.namecheap.com
   Updated Date: 2020-10-11T07:01:46Z
   Creation Date: 1996-10-11T04:00:00Z
   Registry Expiry Date: 2021-10-10T04:00:00Z
   Registrar: NameCheap, Inc.
   Registrar IANA ID: 1068
   Registrar Abuse Contact Email: ab...@namecheap.com
   Registrar Abuse Contact Phone: +1.6613102107
   Domain Status: clientTransferProhibited 
https://icann.org/epp#clientTransferProhibited
   Name Server: DNS101.REGISTRAR-SERVERS.COM
   Name Server: DNS102.REGISTRAR-SERVERS.COM
   DNSSEC: unsigned
   URL of the ICANN Whois Inaccuracy Complaint Form: https://www.icann.org/wicf/

so I take it the original domain went down on Oct 11th at ~7am; OTOH 
sunhelp.org itself has yet two years to go (as you have also observed).

> > I can still reach Bill Bradford's personal page when I connect to the server
> > by its IPv4 address at: .
> 
> Thanks to John's quick thinking, it's now possible to hot wire things so that
> you can get to sunhelp.org, et al.
> 
> The hot wiring that I did seems to have been sufficient to allow email to flow
> to sunhelp.org.  I've since sent a message to a few people inquiring about the
> current state of the ongoing rescue operation.
> 
> The last I knew, some of Bill's co-workers were going to take things over.
> 
> If anyone cares to similarly hot wire things on their end, I configured my
> recursive DNS servers to forward Bill's domains to John K.'s DNS server
> (192.80.49.4).  I also configured my email server to route sunhelp.org
> directly to ohno.mrbill.net.

 I suppose the list server relies on the same nameservers in a way that 
prevents e-mail distribution from happening.  I have since resubmitted the 
same message manually to sunhelp.org's SMTP receiver (the original message 
is still in the outgoing mail queue:

smtp/sunhelp.org:
B/W/23993316: (196 tries, expires in 2d17h) smtp; 466 (No DNS response 
for host: sunhelp.org; h_errno=0)

) to see what happens and got a DSN ack even, but the message did not get 
through.  So local hot wiring of name resolution (which I suppose could be 
as easy as adding a /etc/hosts entry rather than going through the hoops 
of setting up a manipulated name server) might be good enough to get at 
the web pages, but not to get the list going.

  Maciej

Re: FYI sunhelp.org down

[Maciej W. Rozycki via cctalk]

On Wed, 14 Oct 2020, Diane Bruce wrote:

> He was an old friend of mine he died August 15 2019 of cancer. :-(
> https://www.gray329.org/bro-william-c-bradford-1974-2019/

 So sorry to hear that. :(

  Maciej

FYI sunhelp.org down

[Maciej W. Rozycki via cctalk]

Hi,

 I posted to  and saw my message got stuck in the mail 
queue.  Upon a further inspection I saw that the domain has expired along 
with `mrbill.net' where the nameservers used to reside and both have been 
taken by someone else, taking the name service down for `sunhelp.org'.  I 
can still reach Bill Bradford's personal page when I connect to the server 
by its IPv4 address at: .

 I do hope nothing bad has really happened to Bill in these difficult 
times.  Anybody knows?

  Maciej

Re: Remote job submission from PDP-11

[Maciej W. Rozycki via cctalk]

On Wed, 7 Oct 2020, Al Kossow via cctalk wrote:

> > Synchronous serial lines are not typically a feature in the sort of
> > machines people are likely to be running something like Simh on,
> > especially laptops.  I'm sure there were Sync serial cards for ISA but
> > probably not anything more recent.
> > 
> 
> you could get PCI V.35 cards
> https://www.ebay.com/itm/Barr-Systems-291456-Sync-Max-PCI-Rev-1-Card/264317672165

 Umm, PCI has become almost as legacy as ISA, but here's the first link: 
.
 
that came up with "PCIe HDLC" popped into a web search engine.

 If you were so inclined, you could probably wire it to a contemporary x86 
laptop via one of those Thunderbolt-to-PCIe thingies (for the record: I've 
had one of my older x86 laptops put on FDDI via a similar arrangement with 
a PCIe-PCI bridge wired via the docking station, and could do the same 
right away with my most recent one and its ExpressCard interface).

 FWIW,

  Maciej

Re: Intel Developers' Insight CD-ROM collection archived anywhere?

[Maciej W. Rozycki via cctalk]

On Thu, 1 Oct 2020, Maciej W. Rozycki wrote:

> > As one example of something that I was recently unable to find online
> > anywhere is a copy of either of these, which might have been available
> > on some of the Intel Developers' Insight CD-ROMs:
> > 297372 16-Mbit Flash Product Family User’s Manual
> > 297508 FLASHBuilder Design Resource Tool
> > Those are mentioned in various Intel flash memory datasheets and
> > databooks from around the 1995 timeframe.
> 
>  Sadly neither seems to be among the files I have copied.  I could yet 
> check Intel Dec 1995 Data on Demand discs I happen to have, and do have 
> here, but they are cumbersome to handle as they use a proprietary format 
> requiring a DOS app to access, and yet more hassle to get anything 
> exported (assuming I can recall how I did that many years ago), so it'll 
> take a little.

 That was fun.  I have since reconfigured the box a little hardware-wise, 
but all the configured DOS sofware setup remained the same, so things not 
quite worked, not at least all of them.  I ended up digging out my old 
serial mouse I had to replace the burnt out IR transmitters in a couple 
years ago and chasing 5.25" Windows 3.1 installation disks so as to move 
the mouse to COM2 (COM1 has been since consumed for the serial console 
used to control the system remotely when it runs Linux, its usual 
application).

 Anyway I managed to get Data on Demand apps going, both the DOS one, and 
also the Windows 3.1 one.  The latter is important as it allows one print 
individual document pages to PostScript, which can then then be further 
processed for something more useful.

 Unfortunately the bad news is neither document has been included in the 
set.  I did a little research and I suspect 297372 was one of the paid 
books; ISTR that was usually the case with documents Intel referred to as 
"manuals" rather than "databooks", "datasheets", "application notes" or 
"specification updates".  Paid books were naturally not included with 
documentation available free of charge.  The 1995 Flash Memory databook 
available online:



refers to 297372 as: "28F016SA User's Manual" or "28F016SA 16-Mbit 
FlashFile Memory User's Manual".  The part's corresponding datasheet is 
290489 and I have revs 3, 4, 5 available if that would help.

 I could yet check old printed Intel literature guides for any price 
quoted for the two documents to confirm or deny my suspicion, however just 
as the Intel Developers' Insight CD-ROMs I have them elsewhere.

 Now the FLASHBuilder is a software package, so it may yet be there on the 
Insight CD-ROMs, but it'll have to wait until I get at them unless someone 
else chimes in.

 Sorry to help so little if at all.

  Maciej

Re: Intel Developers' Insight CD-ROM collection archived anywhere?

[Maciej W. Rozycki via cctalk]

On Wed, 30 Sep 2020, Glen Slick via cctalk wrote:

> Does anyone have a collection of Intel Developers' Insight CD-ROMs in
> physical form or as images? The only physical CD-ROMs I have are a two
> disk set from February 1998. I don't know what time period these were
> available. Maybe mid or late 1990s to early 2000s? They have a variety
> of information on them such as datasheets and manuals that might not
> always be easy to find online anywhere anymore.

 I have physical discs, although apparently not here.  They were issued 
quarterly and I had a subscription, so I should have them all.  The span I 
have recorded is Oct 1996 through to May 1999.  Some 15 years ago I made 
copies of all the PDF documents, so I can reach for any right away.  For 
any other stuff I'd have to check the actual discs at my other site.

> As one example of something that I was recently unable to find online
> anywhere is a copy of either of these, which might have been available
> on some of the Intel Developers' Insight CD-ROMs:
> 297372 16-Mbit Flash Product Family User’s Manual
> 297508 FLASHBuilder Design Resource Tool
> Those are mentioned in various Intel flash memory datasheets and
> databooks from around the 1995 timeframe.

 Sadly neither seems to be among the files I have copied.  I could yet 
check Intel Dec 1995 Data on Demand discs I happen to have, and do have 
here, but they are cumbersome to handle as they use a proprietary format 
requiring a DOS app to access, and yet more hassle to get anything 
exported (assuming I can recall how I did that many years ago), so it'll 
take a little.

  Maciej

Re: Sun SPARCstation LX boot from CDROM?

[Maciej W. Rozycki via cctalk]

On Tue, 1 Sep 2020, Liam Proven via cctalk wrote:

> This and the rest of what you describe sounds quite like the damaged
> caused by electrolyte leaking from failed capacitors. This is probably
> the most common cause of failure in electronics after they get to 2-3
> decades old.
> 
> There was one particular time when this happened prematurely:
> https://en.wikipedia.org/wiki/Capacitor_plague

 There was the issue with the quaternary ammonium salt system earlier on 
too, e.g. with Chemi-Con SXF parts and several other ones from various 
reputable manufacturers in early 1990s.

  Maciej

Re: About to dump a bunch of Compaq SCSI disk caddies (and disks)

[Maciej W. Rozycki via cctalk]

On Wed, 8 Jul 2020, Peter Corlett via cctalk wrote:

> > If I needed one of those drives, I'd be willing to pay $1 / GB plus shipping
> > and handling if they were known to be good. (If I needed them) I would buy
> > them sight unseen if you ran SpinRite level 2 on the drives and said they
> > passed.
> 
> As a guideline, PostNL quote €18.20 (≈USD20.50) for its single grade of packet
> post to "world". The 2kg weight limit is good for two or three typical 3.5"
> hard disks of around 700g each. It's cheaper to the rest of Europe (and UK) 
> but
> the 2kg limit remains for anywhere outside the Netherlands. For more than 2kg,
> you're looking at expensive couriers and the price to the USA quickly rockets.

 FYI, DHL has interesting flat-rate offers for consumers across at least 
some European countries, e.g. taking your example of shipping from the 
Netherlands to the UK the rates are €10.00/€15.00/€20.00/€26.00 for a 
chunky parcel of up to 2kg/5kg/10kg/20kg respectively.  More details and 
other destinations at: .  
For the US destination this does indeed look somewhat less attractive 
though.

 Please note DHL operates country-specific sites and offers vary between 
countries; look for "Document & Parcel Shipping".

 HTH,

  Maciej

RE: IDE-SD adapter question

[Maciej W. Rozycki via cctalk]

Eugene,

> Jonas, I am using an SD card, not CF because I need to move files from a 
> laptop to this computer using the SD. Having said that, I suspect 
> everything you said is still true. I don't have access to any linux. But 
> do you think I could make a 300MB partition (for example) on the SD card 
> and use that? I only have windows 7 or 10 machines available to me 
> (other than some PDP machines!)  I don't need very much space. I would 
> like to run windows 95 and two or three other programs.

 It didn't strike me why you needed to use SD rather than CF.

 As my memory has certainly already faded to some extent in this area I 
did a little investigation, and with some reminders I came across I need 
to mention the requirement to make the CHS geometry recorded in the MBR
partition table match one reported by the PC BIOS (as entered in the setup 
program) and the device itself.

 The ATA protocol provides for CHS geometry modification with one of the 
optional commands that the PC BIOS or other software may use for one 
reason or another, but the adapter may not necessarily support it, so one 
used with the PC BIOS of your intended device does need to match one used 
with the firmware.

 To make sure this doesn't get broken somewhere on the way you may want to 
start from scratch and erase the partition table on the SD card.  I can't 
provide you advice other than with Linux as to how to do that, now that 
UEFI is in picture.

 Once that has been done you need to establish the CHS geometry the 
adapter will use with your SD card.  You can use a detection program as I 
noted previously, however a 2GB unit is surely above the 528MB limit, so 
you can guess 1024/16/63 will be right as that is the maximum of the 
intersection of the ATA and PC BIOS CHS geometry limits and the adapter 
ought to handle it if it does the CHS stuff at all.  So use that with your 
intended computer's PC BIOS setup.

 Then boot the machine from a floppy or another device, with the SD and 
the adapter wired, and use whatever tools the OS has to partition the SD.  
Install the MBR as required.  E.g. with DOS this will be `fdisk /mbr', and 
the same command with no arguments to make the partition table.

 If you can use a Linux machine, then I can help setting up the SD card 
directly.

 I have come across: , where 
people report success with hardware as old as 80386, whose PC BIOS surely 
had no idea about LBA, and there haven't been that many ATA-SD adapter 
chip designs made, so chances are yours will work too with sufficient 
care, and the warning as to the use of LBA may have simply come from the 
difficulty to set up SD medium for CHS operation correctly.

 HTH, and good luck!

  Maciej

RE: IDE-SD adapter question

[Maciej W. Rozycki via cctalk]

On Sat, 27 Jun 2020, W2HX via cctech wrote:

> Peter and Maciej. Thank you very much for the input. I don't believe 
> this BIOS supports anything other than CHS. At least I don't see a way 
> to toggle between CHS and LBA. Is this what I should be looking for? An 
> option to enable LBA mode?

 IIRC some old PC BIOSes indeed had an option to switch between CHS and 
LBA, it's been a while.  It might have been on a per-drive basis, at least 
with some implementations; as usually, for bug compatibility or whatever.  
This was all hairy stuff, now that you have reminded me.

 Using Linux did help a lot back then, the system was especially ambitious 
in its early days (it has fallen a bit into routine IMO over the years; 
it's no longer hobbyists trying to make their best and squeeze out as much 
as possible from the hardware), so all that was necessary was to put all 
the boot stuff onto a partition within the first 528MB, even with fake CHS 
parameters in the BIOS setup, and forget about all the PC BIOS limitations 
as the kernel handled all automagically, including geometry discovery and 
switching between CHS and LBA as necessary (IIRC there was an override too 
for the user to pass at kernel invocation in case the firmware of a given 
drive had a bug with one of the modes or whatever).

> I am not opposed to going to CF, but I have no other computers that have 
> a CF port, thus I have no way to move files onto this 486 computer.

 CF to PATA adapters are readily available and can be used to wire CF 
media to any machine talking PATA.  I have one of those adapters that 
actually supports both a master and a slave CF device, so you can plug two 
CF devices at a time, just as with original ATA devices on a flat ribbon 
cable (from StarTech; it may not be available new anymore and I have it at 
a remote location, but I can check the P/N when I'm back at it or perhaps 
track down the original invoice in my e-mail archives if that would really 
help you).

 Of course you can bridge such an adapter to SATA or USB or whatever, just 
as with a genuine ATA device, so you should be able to wire it to a modern 
machine pretty easily.  But actual PATA adapters for PCIe used to be made 
too as I have a couple myself that I bought not so long ago so as not to 
be stuck with vintage hardware for data copying involving a PATA device, 
so tracking down one being sold shouldn't be a big deal yet.

 You might be able to track down an actual hard drive in the CF form 
factor too (branded Microdrive by IBM IIRC, a 1.8" device), though the 
choice was rather limited.  I have one of those from Seagate at 2.5GB, 
extracted from a TomTom sat nav that I upgraded to solid-state CF of a 
larger size several years ago.  I used that dual CF adapter I mentioned 
above to copy data between the two storage devices.  Those true hard 
drives ought to be pretty much compatible with anything, as they're 
ordinary magnetic devices, just smaller:

/dev/hda:

CompactFlash ATA device
Model Number:   ST625211CF  
Serial Number:  [...]
Firmware Revision:  3.04
Standards:
Likely used: 6
Configuration:
Logical max current
cylinders   48454845
heads   16  16
sectors/track   63  63
--
CHS current addressable sectors: 4883760
LBAuser addressable sectors: 4883760
Logical/Physical Sector size:   512 bytes
device size with M = 1024*1024:2384 MBytes
device size with M = 1000*1000:2500 MBytes (2 GB)
cache/buffer size  = 128 KBytes (type=DualPortCache)
Capabilities:
LBA, IORDY(cannot be disabled)
bytes avail on r/w long: 4
Standby timer values: spec'd by Vendor
R/W multiple sector transfer: Max = 16  Current = 16
Advanced power management level: disabled
Recommended acoustic management value: 128, current value: 128
DMA: mdma0 mdma1 *mdma2 udma0 udma1 *udma2 (?)
 Cycle time: min=120ns recommended=120ns
PIO: pio0 pio1 pio2 pio3 pio4 
 Cycle time: no flow control=120ns  IORDY flow control=120ns
Commands/features:
Enabled Supported:
   *SMART feature set
   *Power Management feature set
Write cache
   *Look-ahead
   *WRITE_BUFFER command
   *READ_BUFFER command
   *NOP cmd
   *CFA feature set
Advanced Power Management feature set
   *Mandatory FLUSH_CACHE
   *CFA Power Level 1  (max 330mA)
HW reset results:
CBLID- below Vih
Device num = 0 determined by CSEL
Integrity word not set (found 0x, expected 0x1ca5)

> Is there anyway to add LBA mode to this machine? A new BIOS? A new ISA card? 

 You might be able to chase one of those sophisticated cards that I 
mentioned, which obviously 

Re: IDE-SD adapter question

[Maciej W. Rozycki via cctalk]

On Fri, 26 Jun 2020, W2HX via cctech wrote:

> Thanks for previous help on this project. I am working on an old 486 
> computer and I have replaced a 40 pin IDE hard drive with this SD 
> adapter...
> https://www.amazon.com/gp/product/B07G29TZPS/ref=ppx_yo_dt_b_asin_title_o01_s00?ie=UTF8=1

 There is a worrisome note there about the requirement to use the LBA 
rather than CHS storage device addressing mode with the adapter.  A PC 
BIOS that old may not support LBA.

 IIRC the two modes are told apart by a bit set in one of the ATA control 
registers used to select the sector to perform an operation on.  If that 
bit is silently ignored by the adapter's firmware, then the storage device 
may appear to work, however CHS sector addresses presented by the PC BIOS 
will not correspond to LBA sector addresses interpreted by the firmware.  
Consequently things will undoubtedly break and data corruption will likely 
happen sooner or later, depending on whether the OS installed uses the PC
BIOS interface or has its own driver using LBA.  Also accesses to 
inexistent sectors may be attempted.

 An additional complication is that the PC BIOS CHS API, which predates 
ATA and has been designed with MFM and ESDI disks in mind, has a range 
mismatch with the ATA CHS API.  Consequently the CHS sector range 
accessible via the PC BIOS is limited to the intersection of the two 
ranges.  Once LBA support has become available in PC BIOS implementations 
for ATA storage devices a translation scheme was introduced so that the 
full range of the PC BIOS CHS API could be used by the OS.

> In general it seems to mostly be working. I can see a directory listing 
> of several thousands files located on a 2GB SD card from yesteryear. The 
> SD card was new when I installed it (has been in my possession for 
> years).

 What OS do you use that works with the 2GB SD card correctly?

> However, I do get errors "sector not found" and if I A)bort I get INT 24 
> error.  I am trying to get windows 95 installed and this is certainly 
> preventing that.

 INT 24 is the software interrupt invoked by DOS for I/O error recovery, 
the handler of which asks the user how to proceed.  I gather you're using 
DOS then?

> In the BIOS settings I have the hard drive set as "USER" and these parameters:
> CY:[1024] HD:[16] ST:[63] LZ:[1024] WP:[0]
> These were the parameters in use while I was still using the actual hard 
> drive.

 These are the intersection of the maximum values both the PC BIOS and ATA 
supported, which corresponds to 528MB (or 504MiB); for a 2GB ATA storage 
device that's the best you can do here.

 All but some very early ATA disks actually report their CHS configuration 
via the ATA IDENTIFY DEVICE command.  Unfortunately it took years for PC 
BIOS implementers to discover the existence of that command and add an 
auto-detect feature.  Software exists for various OSes that can retrieve 
and print ATA IDENTIFY DEVICE information in a human parseable format, 
e.g. with my non-LBA disk from 1993 I get:

/dev/hda:

ATA device, with non-removable media
Model Number:   Maxtor 7245 AT  
Serial Number:  [...]
Firmware Revision:  6ADF1E57
Standards:
Likely used: 1
Configuration:
hard sectored
not MFM encoded 
head switch time > 15us
fixed drive
disk xfer rate > 5Mbs, <= 10Mbs
format speed tolerance gap reqd
Logical max current
cylinders   967 967
heads   16  16
sectors/track   31  31
--
bytes/track: 19778  bytes/sector: 638
CHS current addressable sectors: 479632
device size with M = 1024*1024: 234 MBytes
device size with M = 1000*1000: 245 MBytes 
Capabilities:
no IORDY
Buffer type: 0003: dual port, multi-sector with read caching ability
Buffer size: 64.0kB bytes avail on r/w long: 11
Can perform double-word IO
R/W multiple sector transfer: Max = 32  Current = ?
DMA: sdma2
PIO: pio0 pio1 pio2 

(this is output from the `hdparm -I' command on Linux).

> Question 1: Now that I am using an SD card instead of an IDE drive, 
> what, if anything, should I be doing with these BIOS parameters?

 You will need them for the bootloader, which will use PC BIOS calls to 
load the OS, and possibly also the OS itself.  Unless your PC BIOS does 
LBA this generally means you'll have to partition the boot storage device 
and keep the boot partition within the first 528MB of the device.  The 
rest can be used as a second partition, provided that the OS has its own 
ATA driver and does not use the PC BIOS to access the device; otherwise 
it'll remain inaccessible.

> Question 2: The BIOS has an option to format the hard drive. Should I 
> format the SD card using this facility?

 I doubt it.  The operation was meant for magnetic media, to set up tracks 
and 

RE: IDE-SD adapter question

[Maciej W. Rozycki via cctalk]

On Sat, 27 Jun 2020, W2HX via cctech wrote:

> Could it be related to the fact that it is a 2GB SD card and I believe 
> IDE controllers of that day could only address something like 500MB?

 Except for a few sophisticated caching host bus adapters and ATA RAID 
controllers that presented their own software interface an ATA host bus 
adapter was essentially a pass-through device with an address decoder and 
a bunch of tri-state logic buffers.  The IDE controller was (as the name 
suggested) integrated with the ATA device itself.  Therefore all the 
simple ISA host bus adapters for ATA devices supported even the LBA48 mode 
as they did not interpret values passed through the control registers, 
which resided on the ATA device (similarly ATAPI support can work, which 
issues commands in the data stream rather than via the ATA command 
register).

 The limitation came from solely from the PC BIOS interface; once an OS 
has been booted that could drive ATA devices itself you could use the 
full capacity of any ATA device.

  Maciej

Re: Future of cctalk/cctech (comment on address fields) , capturing Discord server traffi

[Maciej W. Rozycki via cctalk]

On Thu, 25 Jun 2020, jim stephens via cctalk wrote:

> I have an observation for when the list migrates.  The current message "From"
> field contains the name of the original sender but with the encoded address of
> the list as the email address
> 
> For example this has
> 
> Al Kossow via cctalk 

 That has been a nuisance in many ways, however regrettably it seems the 
lesser evil in the current world of e-mail infested with DMARC, invented 
with little concern as to its impact on mailing lists.  Sigh...

  Maciej

Re: Future of cctalk/cctech

[Maciej W. Rozycki via cctalk]

On Fri, 19 Jun 2020, Patrick Finnegan via cctalk wrote:

> > Sure, there's always `uuencode' when you do need to post that non-text
> > piece (which I guess will keep the eyes of Luddites away from it too).
> >
> 
> Or an http, https, ftp, or gopher url to somewhere else hosting the image.

 Well, not everyone can afford to host their own site, for various 
reasons, and if hosting externally you have to agree to T's you may not 
necessarily be happy about.

  Maciej

Re: Future of cctalk/cctech

[Maciej W. Rozycki via cctalk]

On Fri, 19 Jun 2020, Peter Corlett via cctalk wrote:

> > It's time to adopt a platform that can handle modern mail. Some may still
> > choose a degraded experience, but everyone is entitled to their own fetish.
> 
> Any old mail client can read "modern mail": MIME is designed to be
> backwards-compatible and the text parts readable on non-MIME clients. One
> quickly learns the ASCII renderings of important non-ASCII characters after
> using such a client for a while. (How do I know this? I still use trn, which
> doesn't understand character sets at all. There are *no* "modern" newsreaders,
> apart from the occasional kitchen-sink monstrosity which does nothing well.)

 I guess depending on how you define "modern".  For instance (AL)PINE does 
handle UTF-8 (your UI might not however, if you run say on a VT220), which 
fulfils my definition of modernity, and it happens to have handled NNTP as 
well, since time immemorial.  I have stopped participating with Usenet due 
to the lack of NNTP servers I could access, but I used to use PINE in this 
manner for years, and it did the right thing there.

 I continue using ALPINE for e-mail and I'm quite happy with the stuff it 
keeps away from me.  An occasional PDF attachment I can deal with.  And I 
can pipe a Git commit being read directly to `git am' with no fuss and no 
need to bother if it has been encoded in any way for transport.

> The "no attachments" rule on many mailing lists is not a Luddite thing, but a
> quality filter. There is a strong inverse correlation between those who feel
> that they can't communicate without images and fancy text formatting, and 
> those
> who have something useful or interesting to say. Less is more, and all that.

 Sure, there's always `uuencode' when you do need to post that non-text 
piece (which I guess will keep the eyes of Luddites away from it too).

  Maciej

Re: Synchronous serial Re: E-Mail Formats RE: Future of cctalk/cctech

[Maciej W. Rozycki via cctalk]

On Thu, 18 Jun 2020, Peter Coghlan via cctalk wrote:

> However, Peter uses PMDF MAIL to post to the list because it has been
> pointed out to him that VMS MAIL doesn't do References: and In-Reply-To:
> headers correctly.  On that note, has anyone heard from Mouse?  I haven't
> seen anything posted by him in a very long time now.

 Yep, last Sat on the VAX/NetBSD mailing list.

  Maciej

Re: Amiga Vendors?

[Maciej W. Rozycki via cctalk]

On Thu, 18 Jun 2020, Peter Corlett via cctalk wrote:

> DB-23 to SCART cables were (and still are) readily-available from anywhere 
> that
> has anything to do with the Amiga. Sometimes they had sawn-down DB-25 plugs
> since DB-23 wasn't exactly a common connector even in the Amiga's heyday.

 Unsurprisingly, given that the shell chosen isn't really DB nor any of 
the remaining D-sub standard DA, DC, DD, DE shell sizes (which may then 
come in various signal, power or RF pin configurations, e.g. the Sun 
DB-13W3, or DEC DA-3W3, or VGA DE-15 connectors).  They could have opted 
for standard DA-26 if they were after connector space saving rather than 
locking customers into an inherently more expensive proprietary solution.

  Maciej

Re: Microsoft open sources GWBASIC

[Maciej W. Rozycki via cctalk]

On Thu, 11 Jun 2020, Maciej W. Rozycki wrote:

>  GCC supports legacy Fortran code, so I have filed PR fortran/95631 to 
> track this bug, at: .  
> Let's see what emerges.

 So the response from GCC Fortran experts is as follows:

"[...] Yes,
old compiler did dumb things, because it was/is difficult to
detect this violation of the Fortran standards.  Note, these
prohibitions are on the programmer.

"F66 8.4.2

"If an actual argument corresponds to a dummy argument that is
defined or redefined in the referenced subprogram, the actual
argument must be a variable name, an array element name, or an
array name.

"F77 15.9.2

"Actual arguments may be constants, symbolic names of constants,
function references, expressions involving operators, and
expressions enclosed in parentheses if and only if the associated
dummy argument is a variable that is not defined during execution
of the referenced external procedure."

 My conclusion has therefore been that this must have been a peculiarity 
of individual compiler implementations, in particular because numerous 
computer systems do not support memory protection and have no way to mark 
a segment read-only, and may otherwise either not support instrumentation 
at all or it can be disabled for performance reasons.  Some implementers 
may have indeed gone to great lengths to support this peculiarity to keep 
software running that has been written for computer systems affected by 
this limitation, but by no means it appears standard in terms of the 
language definition.

 FWIW,

  Maciej

Re: Microsoft open sources GWBASIC

[Maciej W. Rozycki via cctalk]

On Sun, 31 May 2020, Eric Korpela via cctalk wrote:

> C
> C CHANGE THE VALUE OF 4
> C
> 
>   CALL INC(4)
>   WRITE (*, 30) 4
> 30FORMAT ('2+2=',I4)
>   END
> 
>   SUBROUTINE INC(I)
>   I = I + 1
>   END
> 
>  OUTPUT
> 2+2=   5

 Hmm, as a matter of interest I fed this program to current trunk GCC and 
with an x86/Linux system it crashes at the incrementation of the literal, 
because the value has been assigned to a read-only memory segment.  With a 
RV64/Linux system it works as expected as the compiler gives priority to 
data assignment to the small data area over the read-only attribute, but 
I'd call it luck rather than intent.

 GCC supports legacy Fortran code, so I have filed PR fortran/95631 to 
track this bug, at: .  
Let's see what emerges.

 Thanks for sharing this peculiarity with us!

  Maciej

Re: PDP-8/A transformer hum

[Maciej W. Rozycki via cctalk]

On Tue, 9 Jun 2020, Bill Gunshannon via cctalk wrote:

> > For the VXT-2000 with an H7109-B the rated voltage and current values
> > are printed right on the power supply label:
> > 
> > +5.1V, 7.81A
> > +12.1V, 0.62A
> > -12.1V, 0.46A
> > -9V, 0.2A
> > 
> > Fixed width character pinout diagram:
> > 
> >+=+
> >-9V | Yellow | Orange | +12.1V
> >+++
> >??? | White  | Black  | Gnd
> >+++
> > +5.1V | Red| Blue   | -12.1V
> >+++
> > +5.1V | Red| Black  | Gnd
> >+++
> >Gnd | Black  | Black  | Gnd
> >+=+
> > 
> > The mystery is the White wire. The power supply label only lists 4
> > output voltages. The White wire appears to be routed to the Ethernet
> > daughter board. The measured voltage appears that it might be floating
> > slightly negative, somewhere around -1.5V when the Ethernet daughter
> > board is installed and around -5V when it is removed. Maybe it is a
> > high impedance earth ground connection? It appears to be connected to
> > the shield of the Ethernet BNC, which measures around 1M-Ohm to the
> > chassis ground when the power supply is disconnected from the main
> > board, and around 0.75M-Ohm when the power supply is connected.
> > 
> 
> 
> Thank you for that.  Mine has no labels or anything.  It is PC Board
> with Digital, Side 1, Side 2 and a number I don't recognize on it.
> I guess the -9V is the only odd one but you could easily get that
> from a -12V line.  I may get to fix it yet.

 For the unlabeled white wire this must be -9V return, such as say with 
the H7109-AA PSU used with the VAXstation 4000 VLC, the H7819-AA used with 
VAXstation 4000 60/90/etc. and storage expansions or the H7821-00 PSU used 
with several systems, where the -9V supply circuit is isolated and used, I 
believe, for serial line drivers/receivers.  It might be worth checking.

  Maciej

Re: 2.11bsd unix resolver

[Maciej W. Rozycki via cctalk]

On Thu, 21 May 2020, Richard Sheppard via cctalk wrote:

> On Solaris it’s the “hosts” line in the /etc/nsswitch.conf/ file. 

 Having /etc/nsswitch.conf was actually Solaris's invention and Solaris 
itself came from System V rather than BSD.  It was only adopted by the 
freely available *BSD systems much later.

> Perhaps something similar in BSD.

 Ultrix as a sole notable exception had /etc/svc.conf, and anyway with a 
BSD version as early as 2.11 I'd expect the resolver's sequence of queries 
to be hardcoded.

 Perhaps the source of the problem is something as silly as the use of 
+ as line endings in /etc/hosts, causing the entry for 127.0.0.1 
to correspond to `localhost^M' rather than expected `localhost' (a common 
and confusing issue with shebang scripts imported or transmitted over FTP 
in the binary rather than text mode from a foreign system causing an error 
like:

$ ./myscript.sh
./myscript.sh: No such file or directory
$ ls -l ./myscript.sh
-rwxr-xr-x 1 macro macro 251 Jan  1  1970 ./myscript.sh
$ head -1 ./myscript.sh
#!/bin/sh
$ # Hmm...
$ 

)?

 For the record older versions of Linux (up to libc 5), including a.out 
ones in particular, used /etc/host.conf to configure the resolver.

  Maciej

Re: LK201 emulation

[Maciej W. Rozycki via cctalk]

On Sun, 17 May 2020, emanuel stiebler via cctalk wrote:

> Actually, would even like the other way around too, connecting a working
> lk201 to a pc ... ( so the terminal emulation works nicer)

 Well, you just need a serial port adapter + power.  See also: 
.  Linux even 
has a driver that is ready to use, see e.g.: 
.

 Or do you want to drive the PC (e.g. interact with the boot firmware) too 
with that keyboard?

  Maciej

RE: Replacing Power LED on MicroVAX 3100/95 Power Supply

[Maciej W. Rozycki via cctalk]

On Wed, 13 May 2020, Rob Jarratt wrote:

> That's fantastic Maciej! I often buy from Farnell, so there is no issue with
> getting those parts myself. When I have accumulated enough wants to warrant
> an order I will get them.

 You are welcome, I'm glad to be of help!

  Maciej

Re: Replacing Power LED on MicroVAX 3100/95 Power Supply

[Maciej W. Rozycki via cctalk]

On Sun, 10 May 2020, Peter Coghlan via cctalk wrote:

> > I seem to remember people saying it is quite difficult to replace these,
> > mainly because you can't get them out without breaking the holder. Is that
> > right? Has anyone done this successfully and have any tips?
> 
> Is this the green LED in a H7821 PSU? I managed to get one out of the holder
> with a bit of difficulty before I realised I could have left it in place and
> the board can just about get past it when the plug at the far end of the leads
> feeding it is plugged out from the board.

 If the holder is the same as with the H7826 PSU, then it's a generic part 
still manufactured.  I bought whatever was the minimum quantity sold by 
Farnell when I broke one along with the LED a few years ago.  I still have 
a few available and I could post one set once I am back to my UK home 
(which is given the current situation regrettably not going to happen 
anytime soon).  Otherwise you can order it yourself: 
.

> > Are there any recommendations for a replacement? If I remember correctly the
> > LEDs used in those days were not as bright as modern ones and a modern one
> > would end up being much brighter because of the higher voltage maybe?
> 
> Maybe it would be possible to tack blobs of solder onto what's left of the
> leads on the original and use them to attach fine leads, digging out a small
> amount of the LED casing around the leads if necessary?

 I chose an LED matching the original colour, also of the case, as closely 
as possible: 
, but 
still haven't installed it (well, ahem, I need to fix the PSU itself 
first), so I can't comment on the result.  I could post one of those along 
with the holder if needed (subject to the condition noted above).

 An LED will dim with use, so you may not be able to closely match a worn 
one with a brand new part, but I suppose you don't actually need to be 
*that* exact with your equipment, do you?  Otherwise you can always put a 
resistor in series to dim the light produced.

 HTH,

  Maciej

Re: Identifying Machine for DEC Memory

[Maciej W. Rozycki via cctalk]

On Wed, 1 Apr 2020, Antonio Carlini via cctalk wrote:

> I did have a quick hunt on the net for IPBs for any of these systems, but with
> no luck. manx shows a few service manuals but they had the MS4x numbers.

 The look does match MS01-AA though as shown in Figure 5-9 on page 5-16 of 
"DECstation 5000 Model 100 Series Maintenance Guide", EK-PM32G-MG-003 (aka 
pm32gmg3.pdf).  OTOH a single module from an MS01-AA pair is listed as FRU 
57-30735-02 there, so it may not be compatible after all.

 I have several of MS01-AA modules, but all in remote locations, so I 
won't be able to check them anytime soon (given the current situation).

  Maciej

Re: Identifying Machine for DEC Memory

[Maciej W. Rozycki via cctalk]

On Wed, 1 Apr 2020, Liam Proven via cctalk wrote:

> The -12 on the chip part number implies 120ns RAM to me. That is slow
> by modern standards -- before EDO came in, PCs tended to take 70ns,
> 80ns was slow and 60ns was fast. 120ns would be quick enough for a
> 4000/60 or 4000/90, marginal for a 4000/90a and too slow for a VLC or
> 4000/96.

 Also the Mitsubishi 41000 is a 1-Mibit part, so the module is 1MiB (or 
2MiB if double-sided).  So you just need to figure out which DEC systems 
used such SIMMs.  If 2MiB, then DECstation 2100/3100 might be a candidate 
and these would be MS01-AA, also working with DECstation 5000/1xx and 
Personal DECstation 5000/xx systems (and probably some VAX machines too).

 BTW, nice talk at FOSDEM 2020, I was there. :)

  Maciej

RE: H7874 power supply

[Maciej W. Rozycki via cctalk]

On Sun, 29 Mar 2020, Robert Armstrong via cctech wrote:

>   And then there's a giant PCB, almost 11" square, covered with opamps, 74LS
> logic and discrete parts.  There are filter caps, a transformer, and
> switching transistors on this board too so it obviously produces yet another
> power output for something.  Oh, and I think this cabinet has variable speed
> fans, right?  SO there's probably a fan speed controller on here as well.

 There's logic included there for synchronised control of multiple H7874 
PSUs at once in a master-slave configuration via a set of auxiliary 
connectors so as to power up or down all pieces simultaneously in a 
complex machine setup with storage and/or Q-bus expansion boxes.  No 
documentation for the PSU has been chased so far as far as I know.

 Note that also with this PSU there were capacitors used that suffered 
from the issue with the quaternary ammonium salt system used in the 
electrolyte.  All mine had numerous Chemi-Con SXF parts scattered across 
all boards, some leaking.  They are prone to leaks even if unused and have 
to be replaced.  Especially those next to the 5V circuit are hard to get 
to to desolder and replace.  Also Chemi-Con SXE parts present in this PSU 
are reportedly affected although I haven't seen them leak myself.

 This PSU has been my worst nightmare as far as keeping old equipment 
alive has been concerned.  I was able to make just one working PSU out of 
three broken ones by mixing and matching individual pieces with caps 
replaced until I found one set that worked.  I consider replacing the 
large cuboid 6800µF Sprague part as well as I have seen its capacitance 
drop down to like half of its nominal.

  Maciej

Re: Vaxstation 400/90 power supply

[Maciej W. Rozycki via cctalk]

On Wed, 25 Mar 2020, Matt Burke via cctalk wrote:

> > no, no confusion, and thanks for the detailed analysis. Now I have to
> > find my dremel (I just moved) and check the Dallas NVRAM ;-)
> >
> > Cheers & thanks again!
> 
> You can buy replacements for the Dallas DS1287A under a new part number
> - DS12887A.

 They are not exact replacements though as they have an additional address 
line on AD6 which is used to access extra 64 bytes of internal static RAM. 
For correct operation with the DS12887A rather than the DS1287A in the 
4000/90 the line would have to be driven with logical 0 in the address 
phase of the bus cycle.  I don't know if this is guaranteed by the EDAL 
glue logic used to drive the DS1287A (TOY in DEC-speak) chip in the 
4000/90.

 My notes indicate that the 0x2540:0x254000fc 32-bit longword CPU bus 
address range is decoded to the TOY chip in the 4000/90, and the TOY data 
byte is transferred on bits 9:2 of the longword accessed.

 Furthermore the CEAC seems to be selected with 0b001001 in bits 31:26 of 
the CPU bus address, that is spanning the 0x2400:0x27ff address 
range.  Bits 25:22 are then decoded by the CEAC to individual EDAL bus 
chip selects (some devices seem to handle multiple chip selects or, more 
likely, CEAC does incomplete decoding depending on the address subrange).

 This leaves bits 21:8 of the address undefined for the TOY chip, and it 
is unknown if they are actually driven, hardwired or left floating.  It 
will depend on the glue logic involved, though given that the DS1287A has 
a multiplexed AD7:AD0 bus, and in the 4000/90 TOY addresses are presented 
on bus bits 7:2 and data is presented on bus bits 9:2 chances are bits 9:8
and consequently AD7:AD6 are also driven in the address phase.

 There's still question of software accessing the TOY using canonical 
addresses only, i.e. ones in the 0x2540:0x254000fc range rather than 
say 0x25400100:0x254001fc, which likely cause AD6 to be driven with 
logical 1 rather than 0.  Of course software could make use of that extra 
static RAM if accessed deliberately.  As I use all my DEC equipment for OS 
development however I consider it reference hardware and therefore I only 
accept exact replacements if the original part cannot be used anymore.

 Since no new DS1287A (or DS1287, for DECstation 5000 systems) chips are 
available I resorted to reworking old chips to have the original embedded 
coin cell replaced with a socket for a discrete coin cell mounted such as 
to match the original clearance of the chip almost exactly.  This is 
important for DECstation 5000 systems, which have the TOY chip mounted in 
the TURBOchannel slot area with as little as ~0.1" of clearance left with 
respect to option cards.

 I actually bought extra chips from a seller on eBay, just to have spares 
in case something goes wrong in the rework, knowing that they have been 
forged by replacing the original marking with one giving a more recent 
date code, one well past the last manufacture date of genuine chips, to 
pretend they are not as extremely old as they really are.  That is quite 
safe for the rework however, because the way the cell has been embedded 
makes the marking on the original top of the case of the embedded DS1285 
chip clearly readable once the cell has been completely removed.

 In the end one of the batches I got was good, made with the DS1285 chip, 
while the other one had the DS12B885 chip instead, so I had to discard it.  
Now I got yet another batch, but I didn't get to disassembling any of the 
parts yet.

 NB the DS12B885 doesn't exist in any datasheet I could track, however 
there used to be a DS12B887 chip which had a RESET# wiring modification 
that I think couldn't have been made by just adding a quartz crystal and a 
coin cell to the DS12885, so perhaps a dedicated DS12B885 core was made to 
satisfy that application only and never sold in a discrete form.

 FWIW,

  Maciej

Re: Vaxstation 400/90 power supply

[Maciej W. Rozycki via cctalk]

On Mon, 23 Mar 2020, Brent Hilpert via cctalk wrote:

> > I have 4000/90 which behaves funny. It only starts, after switching on
> > twice. The first time, all LEDs stay on, flipping the switch off/on, it
> > boots happily.
[...]
> I've experienced behaviour like this in an Apple-something.
> It related to a dead RTC/boot-ROM battery. I figured it out (years ago) 
> but now forget the exact mechanistics, but it was along the lines of the 
> first power-on leaves enough charge in a capacitor for the subsequent 
> power-on to see the RTC/ROM as at least 'valid', albeit not 'correct', 
> if you get my drift.
> 
> That's just a suggestion/possibility - I'm not acquainted with the 
> 4000/90 specifically.

 A correlation with an expired DS1287A chip seems plausible, though not 
fully verified.

 I have a 4000/90 that seemed dead having been stored alive and left 
unused for a prolonged period.  The symptom were all LEDs steady lit after 
power-up, as if the CPU has failed to execute any instructions after 
coming out of reset.  Multiple consecutive power-ups didn't help.

 The 4000/90 has a couple of potential reasons as to why its CPU would not 
start executing:

- a broken CPU (obviously) or chipset,

- flash ROM corruption (with no write-protection provided regrettably all 
  too easy to happen),

- bitfile ROM corruption (used with the CEAC and SQWF FPGAs in the /90 
  only; replaced with ASICs and the ROM removed in the /90A and the /96),

- power-good signal not asserted by the PSU.

NB the LED latches sit on EDAL (as does the DS1287A), so if the CEAC FPGA 
does not come up they won't budge even if the CPU executes from main flash 
ROM.

 If I were to believe documentation, I'd expect the very first couple of 
instructions executed from the reset vector to poke at the LEDs rather 
than the DS1287A to indicate execution has started, but I haven't actually 
looked at the code there (I should have!).  I didn't therefore consider 
the DS1287A, especially as it was already dead in that machine before it 
was left to sit.

 It appears to make a difference however whether the DS1287A has been only 
discharged enough not to keep the contents across a power down or whether 
it has been indeed deeply discharged (the chip obviously continues to suck 
power from its lithium cell even past the point it cannot hold contents 
from anymore).  I experimented with replacing the chip with a couple of 
spares, but it didn't help.  Frustrated I put the machine aside and left 
it untouched for a couple of months.

 I came back to it once again, disassembled, reassembled, disassembled 
again and verified the tantalum capacitors in-circuit (all measured fine) 
replaced the PSU, replaced the DS1287A a couple of times again, and then 
suddenly with one of the replacement DS1287A chips it started to work.

 I tried the chips that didn't again and oddly the machine continued to 
work, and kept working on many occasions for a couple of years more until 
I last checked it sometime last year.  Hopefully it still does (and I plan 
to replace the DS1287A once expired with one of my reworked chips as shown 
here: ; so 
far I only did the replacement with a couple of DECstation 5000 systems), 
however I cannot verify that now due to the current chaos in Europe making 
travel impossible and keeping me away.

 I need to warn you too that the H7819 PSU the 4000/90 uses also suffers 
from the quaternary ammonium salt system issue with some capacitors used, 
so it's at risk of developing catastrophic leaks (I don't remember offhand 
if the capacitors are safely upside down as in the H7821, and I can't 
easily check right now; I highly suspect it is the case though, so try 
keeping the machine in the right position while in storage).  Furthermore 
much of the contents of this PSU has been treated with hot melt, making 
any diagnosis or repair a real pain.  I would recommend examining the PSU 
just in case anyway.  It might be on the verge of giving the power-good 
signal.

 I realise I may have added confusion rather than helped, but at least 
there may be hints as to the causes for odd behaviour and a hope for full 
recovery.

  Maciej

Re: HPE OpenVMS Hobbyist license program is closing

[Maciej W. Rozycki via cctalk]

On Sat, 21 Mar 2020, Jan-Benedict Glaw wrote:

> >  Not a question for me, but for the record I have used a WTI remote site 
> > manager, essentially a combined power distribution and terminal server 
> > unit, for 5 years now.
> 
> That's this product line, itn's it?
> 
> https://www.wti.com/c-93-cpm-800-2-series-console-server-power-control-combos.aspx

 It is, however 5 years ago the choice was different and much smaller (in 
this category).  They have since switched from Freescale Power to ARM as 
the hardware platform, and presumably still use Linux with a custom app to 
drive it.

 Control CLI access is over SSHv2 over IPv4/IPv6; likewise serial port 
access (both ways).  Per-port and per-plug user accounts can be created.  
There's also control HTTPS and I believe telnet access available, but who 
needs that?  Of course both can be disabled.

> That's neat! I actually never stumbled over this manufacturer, it
> actually looks quite like what is needed.

 As I say I did quite a research at the time.  The usual manufacturers I 
knew of back then didn't have the features I needed.

  Maciej

RE: HPE OpenVMS Hobbyist license program is closing

[Maciej W. Rozycki via cctalk]

On Fri, 20 Mar 2020, Rob Jarratt wrote:

> > Actually, I'm searching (more active than ever) for a proper location to 
> > put all
> > of my hardware to. I already have shelves, controllable power plugs, and 
> > just
> > today an EPROM reader/writer arrived. Though I'm unsure (to use fair
> > language) when there'll be a really up-to-date working Linux port. But maybe
> > at some time, there'll be one!
> 
> Out of interest, what controllable power plugs (sockets?) are you using?

 Not a question for me, but for the record I have used a WTI remote site 
manager, essentially a combined power distribution and terminal server 
unit, for 5 years now.

 The reason I chose that device over alternatives (and with the amount of 
stuff to do with vintage hardware I chose to stay away from a homebrew 
solution so as to reduce distractions) was its ability to automatically 
power-cycle sockets if a device on the network (possibly one powered from 
the socket controlled) is probed dead, so as to reboot a stuck piece of 
communication equipment in an unattended manner.  This has been important 
to me as I cannot afford a travel to my lab whenever a minor disruption 
happens.

 It has dual power inputs too for redundant supply (I found it useful if a 
UPS fails, which I have seen happen many times with expired batteries even 
if mains supply remains live) and can also monitor the current load (at 
individual sockets) and the temperature, and then shut sockets selectively 
down automatically if thresholds are exceeded.

 The serial ports use 8P8C modular sockets, so I had some fun making 
proper 8P8C-MMJ patchcords for these console ports that use an MMJ socket 
rather than a D-sub connector (for those ready-made cables are widely 
available).

 As one I have got has 8/8 sockets/serial ports only I now have a second 
one on the way.

  Maciej

Re: soviet resistor identification help and maybe lamps?

[Maciej W. Rozycki via cctalk]

On Sun, 8 Mar 2020, Curious Marc via cctech wrote:

> On the Russian resistors I saw, the value was what is written on it. If 
> you can’t measure them, maybe there is some conformal coating or 
> corrosion on the leads? You’d need to scratch that off.

 At least in the 1980s they used R, K or M respectively as a decimal point 
and unit designator both at a time.  So say M56 would be 0.56MΩ, 1K5 would 
be 1.5kΩ and 22R would be 22Ω.  On some parts the designation could be 
split between lines.

 FWIW,

  Maciej

Re: HPE OpenVMS Hobbyist license program is closing

[Maciej W. Rozycki via cctalk]

On Tue, 10 Mar 2020, Jan-Benedict Glaw via cctalk wrote:

> > Linux and/or NetBSD/vax would be a good choice, though, to implement the
> > VAX's system calls and execute it's binaries. Though there were more
> > concerted efforts to do this years ago, but I don't know what became of
> > them. Google shows a smattering of efforts littered with broken links. :(
> 
> There was a vax-linux port started by others, and I cared for it for a
> good number of years. My life changed a lot since then, I quite failed
> (and failed hard!) to bring up the needed time to care for Linux, care
> for GCC and Binutils, GNU libc and all those programs silently
> expecting IEEE floating point support.

 I'm still here to help. :)

 I expect to get at least one of my VAXen online RSN (a 4000/60, with 
TURBOchannel).  As in a couple of weeks' time (if only not that damn COVID 
thing!).  It boots our ancient VAX/Linux port with an NFS-root over a PMAD 
interface.  Other machines may follow.

  Maciej

Re: H7821 power supply in MicroVAX 3100, SCSI disk enclosures and others

[Maciej W. Rozycki via cctalk]

On Fri, 31 Jan 2020, Peter Coghlan via cctalk wrote:

> If anyone has anything with H7821 power supplies in them, I suggest checking
> on these capacitors.  If anything with these power supplies is in storage, I
> suggest ensuring it is stored the normal way up as this should limit the
> ability of the goo to escape and spread around the power supply.

 Yep, known issue, discussed here and elsewhere several times previously, 
with these Chemi-Con SXF caps, and also several other lines and reputable 
brands of that era using a quarternary ammonium salt in the electrolyte 
that breaks through the seal with time.  Several DEC PSUs are affected.

 Fortunately the H7821 is the least affected as long as the machine is 
stored in the correct orientation (as you note) as the caps are facing 
down then, meaning the salt does not interact with the seal thanks to 
gravity keeping the two away from each other, and the caps along with the 
PSU remain fully operational.  Other PSUs have caps in other orientation 
meaning they are bound to fail unless the machine one is in is stored in 
an odd orientation, e.g. upside down.

 It's best to replace them all anyway at the earliest convenience.

  Maciej

Re: Fwd: VAX + Spectre

[Maciej W. Rozycki via cctalk]

On Thu, 3 Oct 2019, Maciej W. Rozycki wrote:

> > You need an extremely high resolution timer to detect slight differences in
> > execution time of speculatively-executed threads. The VAX 11/780 certainly 
> > did
> > not do speculative execution, and my guess is that all VAXen did not, 
> > either.
> 
>  The NVAX and NVAX+ implementations include a branch predictor in their 
> microarchitecture[1], so obviously they do execute speculatively.

 For the record: in NVAX prediction does not extend beyond the instruction 
fetch unit (I-box in VAX-speak), so there's actually no speculative 
execution, but only speculative prefetch.

  Maciej

Re: Fwd: VAX + Spectre

[Maciej W. Rozycki via cctalk]

On Tue, 17 Sep 2019, Jon Elson via cctalk wrote:

> > "Spectre" is one of two notorious bugs of modern CPUs involving speculative
> > execution.  I rather doubt that VAX is affected by this but I suspect others
> > here have a lot more knowledge.
> >
> >
> You need an extremely high resolution timer to detect slight differences in
> execution time of speculatively-executed threads. The VAX 11/780 certainly did
> not do speculative execution, and my guess is that all VAXen did not, either.

 The NVAX and NVAX+ implementations include a branch predictor in their 
microarchitecture[1], so obviously they do execute speculatively.

> Also, I don't think the timer was high enough resolution to detect such a
> difference.

 I can't speak of timer availability offhand though.

References:

[1] G. Michael Uhler et al, "The NVAX and NVAX+ High-performance VAX 
Microprocessors", Digital Technical Journal Vol. 4 No. 3 Summer 1992



  Maciej

Re: RS2030 MIPS workstation

[Maciej W. Rozycki via cctalk]

On Tue, 2 Jul 2019, Patrick Mackinlay via cctalk wrote:

> For the MIPS Rx3230 systems, which use an M48T02, the mac address should 
> be in the first 6 bytes of NVRAM. You can read/write the NVRAM through 
> the boot monitor using the “g” (get) and “p” (put) commands. You also 
> need to provide the “-b” argument to specify byte width, and the 
> relevant address. The NVRAM is mapped at 0x1d00-0x1d001fff in the 
> physical address space, but must also set the high bit to access it 
> through kseg0. Each 32-bit word in that range corresponds to a single 
> byte in the NVRAM, so the resulting commands will be something like:
> 
> 
>   *   g -b 0x9d03 (read first byte of NVRAM)
>   *   g -b 0x9d07 (read second byte of NVRAM)
>   *   ...
> 
> Or conversely:
> 
> 
>   *   p -b 0x9d03 0xff (write 0xff to first byte of NVRAM)

 You probably want to use KSEG1 instead to access an MMIO resource, such 
as an NVRAM chip, especially with actual hardware and given that the chip 
is not linearly mapped in the address space in particular, or otherwise 
rubbish will be transferred through unused byte lanes as cache lines are 
read or written.

 With MAME it will of course depend on how accurate it is in reproducing 
the cache, although as a good measure I think correct access addresses 
ought to be always used.

 So:

  *   g -b 0xbd03 (read first byte of NVRAM)
  *   g -b 0xbd07 (read second byte of NVRAM)

and:

  *   p -b 0xbd03 0xff (write 0xff to first byte of NVRAM)

respectively.

  Maciej

RE: More old stuff incoming

[Maciej W. Rozycki via cctalk]

On Wed, 19 Dec 2018, Ali wrote:

> >  I don't know how functional their solutions are and I've never had any
> > of
> > their products nor I have anything to do with them, but I've had this
> > link:  in my bookmarks just in case since
> > 2005.
> > I guess if they have been in that business for so long now, they must
> > have
> > been doing things right.
> 
> I can tell you for a fact that they do NOT support DMA so a non-starter for
> many things.

 What kind of DMA though: ISA bus mastering or the Intel 8237 data mover? 
Or neither?  Either way, quite disappointing -- it all should be pretty 
easy to reproduce with modern circuitry.

 The software side is another matter however -- x86 real-mode OS drivers 
should be easy to run virtualised, but other environments are a tad more 
difficult to emulate.

  Maciej

Re: More old stuff incoming

[Maciej W. Rozycki via cctalk]

On Wed, 19 Dec 2018, Chuck Guzis via cctalk wrote:

> >> Really? Show me one that is 1) in current production, 2) offers the
> >> full ISA bus (not just some decoded address lines and 8 data lines),
> >> 3) plugs into a PCI slot.
> >> Christian
> > 
> > Surprised no one has used something like an ATMega or cheap USB
> > connected ARM to build a USB to ISA adapter with tie in to DOSBox or
> > some other emulator.
> > 
> 
> For what it's worth, I've never seen an ISA to USB or ISA to PCI
> "bridge" implementation that was fully functional--and that includes P4
> and later motherboards using a bridge chip.  I've been round the block
> with a couple of motherboard vendors.

 I don't know how functional their solutions are and I've never had any of 
their products nor I have anything to do with them, but I've had this 
link:  in my bookmarks just in case since 2005.  
I guess if they have been in that business for so long now, they must have 
been doing things right.

 HTH,

  Maciej

Re: Text encoding Babel. Was Re: George Keremedjiev

[Maciej W. Rozycki via cctalk]

On Tue, 4 Dec 2018, Liam Proven wrote:

> >  I don't know if the unreal mode has been retained in the x86 architecture
> > to this day; as I noted above it was not officially supported.  But then
> > some originally undocumented x86 features, such as the second byte of AAD
> > and AAM instructions actually being an immediate argument that could have
> > a value different from 10, have become standardised at one point.
> 
> I know, and was surprised that, v86 mode isn't supported in x86-64.

 In the native long mode, that is.  If you run the CPU 32-bit, then VM86 
works.  I guess AMD didn't want to burden the architecture in case pure 
64-bit parts were made in the future.

> This caused major problems for the developers of DOSEMU.

 And also for expansion-BIOS emulation, especially with graphics adapters 
(which, accompanied by scarce to inexistent hardware documentation, made 
mode switching even trickier in Linux than it already was).  It looks like 
fully-software machine code interpretation like with QEMU is the only way 
remaining for x86-64.

  Maciej

Re: SPARCstation 20 with SCSI2SD

[Maciej W. Rozycki via cctalk]

On Sun, 2 Dec 2018, Jeffrey S. Worley via cctalk wrote:

> The re-work of that Dallas nvram chip is just beautiful.  It makes me
> ashamed of myself.  (I just chopped into the epoxy with a pocket knife,
> soldered two leads, and velcroed the new batteries somewhere inside the
> machine I installed it in.)

 There is very little clearance in DECstation 5000 systems, like .1", as 
per the TURBOchannel specification, between the top of the Dallas chip and 
the bottom of any TURBOchannel option placed right above it (some have 
components underneath, including large ICs), and I think the risk of 
breaking such a non-standard wiring while shuffling option cards is not to 
be ignored either.  Also the design of the system box makes it very 
difficult to choose a suitable location for a distant battery holder that 
would not obstruct anything.

 So I decided to do that properly at the cost of it taking perhaps a 
little longer to rework a single chip.

 NB a CR1220 cell is supposed to last for ~8 years in this application if 
running on battery power all the time, which I think is good enough.  A 
CR2032 cell would last ~50 years, which I think is an overkill, given that 
the seal is expected to fail much earlier, like after 10 years.

 An encapsulated power module could instead be used such as the Renata 
175-0, where space permits, which would indeed last some 50 years, being 
airtight, but I haven't seen any reports of its use in this application (I 
have a couple of those on DEC NVRAM boards and last time I checked they 
still had the power to hold 1MiB SRAM memory contents after 25+ years).

> I salute you sir.

 :)  So far I only made 2 of these, but more are in the pipeline (waiting
for a free weekend).

  Maciej

Re: Text encoding Babel. Was Re: George Keremedjiev

[Maciej W. Rozycki via cctalk]

On Fri, 30 Nov 2018, Fred Cisin via cctalk wrote:

> > Well, ATA drives at that time should have already had the capability to
> > remap bad blocks or whole tracks transparently in the firmware, although
> 
> Not even IDE.
> Seagate ST4096  (ST506/412 MFM)  80MB formatted, which was still considered
> good size by those of us who weren't wealthy.

 Sure!  You did need a bad block list for such a drive though.

> > Of course the ability to remap bad storage areas transparently is not an
> > excuse for the OS not to handle them gracefully, it was not that time yet
> > back then when a hard drive with a bad block or a dozen was considered
> > broken like it usually is nowadays.
> 
> Yes, they still came with list of known bad blocks.  Usually taped to the
> drive.  THIS one wasn't on the manufacturer's list, and neither SpeedStor nor
> SpinRite could find it!
> There were other ways to lock out a block besides filling it with a garbage
> file, but that was easiest.

 IIRC for MS-DOS the canonical way was to mark the containing cluster as 
bad using a special code in the FAT.  Both `format' and `chkdsk' were able 
to do that, as were some third-party tools.  That ensured that disk 
maintenance tools, such as `defrag', didn't reuse the cluster for 
something else as it could happen with a real file assignment of such a 
cluster.

> And, I did try to tell the Microsoft people that the OS "should recover
> gracefully from hardware errors".  In those words.

 I found switching to Linux a reasonable solution to this kind of customer 
service attitude.  There you can fix an issue yourself or if you don't 
feel like, then you can hire someone to do it for you (or often just ask 
kindly, as engineers usually feel responsible for code they have 
committed, including any bugs). :)

> > Did 3.1 support running in the real mode though (as opposed to switching
> > to the real mode for DOS tasks only)?  I honestly do not remember anymore,
> > and ISTR it was removed at one point.  I am sure 3.0 did.
> 
> I believe that it did.  I don't remember WHAT the program didn't like about
> 3.1, or if there were a real reason, not just an arbitrary limit.
> I don't think that the Cordata's refusal to run on 286 was based on a real
> reason.
> 
> But, the Win 3.1 installation program(s) balked at anything without A20 and a
> tiny bit of RAM above 10h I didn't have a problem with having a few
> dedicated machines (an XT with Cordata interface, an AT with Eiconscript card
> for postscript and HP PCL, an AT Win 3.0 for the font editor, a machine for
> disk duplication (no-notch disks), order entry, accounting, and lots of
> machines with lots of different floppy drive types.)  I also tested every
> release of my programs on many variants of the platform (after I discovered
> the hard way that 286 had a longer pre-fetch buffer than 8088!)

 Hmm, interesting.  I never tried any version of MS Windows on a PC/XT 
class machine and the least equipped 80286-based system I've used had at 
least 1MiB of RAM and a chipset clever enough to remap a part of it above 
1MiB.  And then that was made available via HIMEM.SYS.

 What might be unknown to some is that apart from toggling the A20 mask 
gate HIMEM.SYS also switched on the so-called "unreal mode" on processors 
that supported it.  These were at least the 80486 and possibly the 80386 
as well (but my memory has faded about it at this point), and certainly 
not the 80286 as it didn't support segment sizes beyond 64kiB.  This mode 
gave access to the whole 4GiB 32-bit address space to real mode programs, 
by setting data segment limits (sizes) to 4GiB.

 This was possible by programming segment descriptors in the protected 
mode and then switching back to the real mode without resetting the limits 
to the usual 64kiB value beforehand.  This worked because unlike in the 
protected mode segment register writes made in the real mode only updated 
the segment base and not the limit stored in the corresponding descriptor.  
IIRC it was not possible for the code segment to use a 4GiB limit in the 
real mode as it would malfunction (i.e. it would not work as per real mode 
expectations), so it was left at 64kiB.

 According to Intel documentation software was required to reset segment 
sizes to 64kiB before switching back to the real mode, so this was not an 
officially supported mode of operation.  MS Windows may or may not have 
made use of this feature in its real mode of operation; I am not sure, 
although I do believe HIMEM.SYS itself did use it (or otherwise why would 
it set it in the first place?).

 I discovered it by accident in early 1990s while experimenting with some 
assembly programming (possibly by trying to read from beyond the end of a 
segment by using an address size override prefix, a word or a doubleword 
data quantity and an offset of 0x and not seeing a trap or suchlike) 
and could not explain where this phenomenon came from as it contradicted 
the x86 processor manual I 

Re: SPARCstation 20 with SCSI2SD

[Maciej W. Rozycki via cctalk]

On Sat, 1 Dec 2018, alan--- via cctalk wrote:

> I'm not sure what the 'B' in the middle means (silicon rev?), but the DS12885
> has been around for decades.  I use them the JR-IDE project.

 Yes, the DS12885 is a standard part, still in production (with a trailing 
+ marking RoHS compliance).

 According to its datasheet the DS12B887 has an NC pin actually present in 
the position where the DS12885 has the RESET# line, while the remaining NC 
positions are absent due to the respective pins having been bent up (or 
"are missing by design", as the datasheet puts it).  So either a different 
core had to be used with the DS12B887 or the datasheet has an error.

 However RESET# would have to be connected to VCC for normal operation and 
there is no mention of an internal pull-up on RESET# with the DS12885, so 
I take it the DS12B887 had to use a different core and a DS12B885 seems 
like a logical match.

 The placement of RESET# right in the middle between VBAT and GND makes it 
highly unlikely an internal discrete connection has been made in the 
DS12B887 package between RESET# and VCC, as a shortage to the embedded 
lithium cell from that pin if bent up and soldered to would be virtually 
unavoidable.

  Maciej

Re: SPARCstation 20 with SCSI2SD

[Maciej W. Rozycki via cctalk]

On Tue, 27 Nov 2018, systems_glitch via cctalk wrote:

> I probably need to do a writeup on fully potted parts, like the 48T59 and
> DS1287.

 See a photo documentary here:
 for my 
proposal of a DS1287 rework.

 I actually had a nasty surprise trying to rework a DS1287A, with a date 
code indicating a clearly faked marking.  After removing the integrated 
coin cell the marking on the embedded IC revealed showed it wasn't even a 
DS1287A originally as the IC was a DS12B885.  This is a part I haven't 
heard of existing, so I enquired Maxim, but they had no clue about it.  I 
suspect the DS12B885 was the core of the DS12B887 (wired differently from 
both DS12887 and DS12887A), and the DS12B885 has never been marketed as a 
part on its own.

  Maciej

Re: Text encoding Babel. Was Re: George Keremedjiev

[Maciej W. Rozycki via cctalk]

On Fri, 30 Nov 2018, Fred Cisin via cctalk wrote:

> I found the bad spot and put a SECTORS.BAD file there, and then was OK.
> The Microsoft Beta program wanted cheerleaders, and ABSOLUTELY didn't want any
> negative feedback nor bug reports, and insisted that the OS had no
> responsibility to recover from nor survive hardware problems, and that
> therefore it was not their problem.  I told them that they would soon have to
> do a recall (THAT was EXACTLY what happened with DOS 6.2x).  They did not
> invite me to participate in any more Betas.

 Well, ATA drives at that time should have already had the capability to 
remap bad blocks or whole tracks transparently in the firmware, although 
obviously it took some time for the industry to notice that and catch up 
with support for the relevant protocol requests in the software tools.  
It took many years after all for PC BIOS vendors to notice that ATA drives 
generally do report their C/H/S geometry supported (be it real or 
simulated; I only ever came across one early ATA HDD whose C/H/S geometry 
was real, all the rest were ZBR), so there is no need for the user to 
enter it manually for a hard drive to work.

 Of course the ability to remap bad storage areas transparently is not an 
excuse for the OS not to handle them gracefully, it was not that time yet 
back then when a hard drive with a bad block or a dozen was considered 
broken like it usually is nowadays.

> I had a font editor that wouldn't tolerate 3.1, and quite a few XTs (no A20),
> so I continued to keep Win 3.0 on a bunch of machines.

 Did 3.1 support running in the real mode though (as opposed to switching 
to the real mode for DOS tasks only)?  I honestly do not remember anymore, 
and ISTR it was removed at one point.  I am sure 3.0 did.

  Maciej

Re: Text encoding Babel. Was Re: George Keremedjiev

[Maciej W. Rozycki via cctalk]

On Sun, 25 Nov 2018, Liam Proven via cctalk wrote:

> > > For example, right now, I am in my office in Křižíkova. I can't
> > > type that name correctly without Unicode characters, because the ANSI
> > > character set doesn't contain enough letters for Czech.
> >
> > Intriguing.  Is there an old MS-DOS Code Page (or comparable technique)
> > that does encompass the necessary characters?
> 
> Don't know. But I suspect there weren't many PCs here before the
> Velvet Revolution in 1989. Democracy came around the time of Windows
> 3.0 so there may not have been much of a commerical drive.

 Be assured there were enough IBM PC clones running DOS around from 1989 
onwards for this stuff to matter, and hardly anyone switched to MS Windows 
before version 95 (running Windows 3.0 with the ubiquitous HGC-compatible 
graphics adapters was sort of fun anyway, and I am not sure if Windows 3.1 
even supported it; maybe with extra drivers).

 Anyway MS-DOS 5.0 onwards had a complete set of code pages for various 
regions of the world.  For Czechia, Hungary, Lithuania, Poland, and other 
European countries located towards the east and using a language with a 
latin transcription code page 852 was provided.  For France, Germany, 
Spain, Nordic countries, etc. page 850 was provided.  There were other 
pages included as well, beyond the IBM's original page 437, including 
Greek and Cyrillic, but I don't know the details.  It's quite likely 
Wikipedia has them.

 Of course the HGC didn't support text mode character switching, however 
ISA VGA clones started trickling in at one point too.  I still have my ISA
Trident TVGA 8900C adapter from 1993 working in one of my machines, though 
I have since switched to Linux.

 NB my last name is also correctly spelled Różycki rather than Rozycki, 
and the two letters with the diacritics are completely different from and 
have sounds associated that bear no resemblance to the corresponding ones 
without, i.e. these are not merely accents, which we don't have in Polish 
at all (Polish complicates this further in that the sound of `ó' is the 
same as the sound of `u' and the sound of `ż' is the same as the sound of 
`rz' (which is BTW different from where the two letters are written 
separately), however the alternatives are not interchangeable and are 
either invalid or change the meaning of a word, and many native Polish 
speakers get them wrong anyway).

 FWIW,

  Maciej

RE: Astounding Asking Price

[Maciej W. Rozycki via cctalk]

On Wed, 24 Oct 2018, Rob Jarratt via cctalk wrote:

> > Instant alarm bells to me are a seller posting a London address but the 
> > item is
> > 'for pickup only in Budapest, Hungary'
> 
> Yes I noticed that too. Very odd, and £750 to ship to the UK!!

 They just chose to pay taxes in the UK and/or to fall under the UK 
jurisdiction, which is one of the benefits of the single EU market for 
businesses.  It's not uncommon and there are various reasons to do that, 
generally to lower the cost and/or the risk of running a business.  It's 
just like many US companies are registered in the state of Delaware even 
though they really run their business elsewhere.

 If you look through their store, you'll find other items whose price and 
postage are both reasonable, so it just could be an oddball case of 
getting the asking price wrong.  I guess you can always ask them if they 
really mean it.  Also it starts getting tricky to ship individual items 
abroad from/to many places once you get above 20kg (~44lbs), and they say 
it (indirectly) in the description, stating that they'll use your carrier 
of choice.

 FWIW,

  Maciej

Re: WTB: 64K cache SIMM (72-pin)

[Maciej W. Rozycki via cctalk]

On Sat, 1 Sep 2018, Cameron Kaiser via cctalk wrote:

> An excellent question, but it is exactly the same socket as the 72-pin RAM
> SIMMs below it. I even labouriously counted all the pins on the board socket
> this morning just in case I'd missed something, and it's 72. The service
> manual even warns against installing RAM there.
> 
> Is this actually a *non*-standard thing? I know Apple had all kinds of boffo
> L2 cache configurations for the beige Power Macs but Apple's Apple and
> certainly larger than Alpha Micro.

 I'd expect SRAM rather than DRAM on a cache SIMM.  Cache memory is 
supposed to be fast after all.  Otherwise why bother? -- caching only 
complicates things, so there has to be benefit in return.

  Maciej