Re: Stuffing boards with pulled QFP chips

[allison via cctech]

On 03/31/2017 06:32 AM, David Griffith via cctalk wrote:
>>
>> I'm down to the last few P112 boards for sale and am pondering
>> another run of them because demand is steady.  One of the biggest
>> challenges for the last run was getting the QFP-packaged 100-pin
>> chips[1] in a state such that the pick-and-place robot wouldn't throw
>> a fit about slight differences in lead position.  The stuffing house
>> insisted that I send them new chips.  Pulls, though they looked
>> perfectly okay to me, were not acceptable.  Does anyone here know
>> anything about pick-and-place robots using pulled 100-pin QFPs,
>> particularly a stuffing house that can work with such chips and not
>> screw up?
>>
>> [1] The now-obsolete super-io chips
>>
>>
>
Is this something that an experienced hand can manually do?

Of all the CP/M platforms its one of the few I haven't done.  But
it keeps popping after I've long figured its long gone.

I'm not afraid of SMT as I proto using 0603 and 0402 parts
at uhf/microwave freehand.

Baving delt with layouts for BGA and large pinout devices usually getting
fiducial marks on the board so it can locate and position without
optical works.
One time the board designer messed up and we had to use existing fixed
points
for that.  PITA but it worked. After that I got into the board layout
bit and DFM.


Allison

Re: Stuffing boards with pulled QFP chips

[allison via cctech]

On 03/31/2017 02:00 PM, Paul Koning wrote:
>> On Mar 31, 2017, at 1:51 PM, allison via cctech <cctech@classiccmp.org> 
>> wrote:
>>
>> On 03/31/2017 06:32 AM, David Griffith via cctalk wrote:
>>>> I'm down to the last few P112 boards for sale and am pondering
>>>> another run of them because demand is steady.  One of the biggest
>>>> challenges for the last run was getting the QFP-packaged 100-pin
>>>> chips[1] in a state such that the pick-and-place robot wouldn't throw
>>>> a fit about slight differences in lead position.  The stuffing house
>>>> insisted that I send them new chips.  Pulls, though they looked
>>>> perfectly okay to me, were not acceptable.  Does anyone here know
>>>> anything about pick-and-place robots using pulled 100-pin QFPs,
>>>> particularly a stuffing house that can work with such chips and not
>>>> screw up?
>>>>
>>>> [1] The now-obsolete super-io chips
>>>>
>>>>
>> Is this something that an experienced hand can manually do?
> Yes, definitely.  100 lead PQFP is perfectly doable if the lead pitch is not 
> insanely small.  It takes a good fine tip soldering iron (mine is a Weller 
> with a PTS tip), fine solder (preferably real, i.e., 63/37 non-PC solder).  
> Liquid flux is a big help, as is a magnifier and bright light or modest 
> magnification microscope.
>
> If you have to do a couple of dozen boards this gets very tedious, but for 
> 5-ish it isn't a big deal.
>
>   paul
>
So happens I'm fully equipped on all counts.  Including the PTS tip. 
However my preference
for years has been the PTA7K (WTCP60) which is 1/4" wide!  Gets a few
pins done at a time... ;)

I've not gone over to the Rohs side, most of the solders are not fun to
work with though a
few have very active fluxes and solder aluminium well.   So its Kester
44 in 10 and
20 mil (inch mil) diameters.

I've done more than a few AD537 and similar Blackfin CPUs with their 288
BGA package that's
a challenge to pull and replace.

Allison

Re: Aquired PDP 11/23

[allison via cctech]

On 03/12/2017 04:56 PM, Systems Glitch via cctech wrote:
>> Are dectape II tapes expensive?
> TU58? They're hard to come by, but the good news is you can *emulate* them 
> with a PC and a serial port (or USB adapter). That's how I run XXDP on most 
> of my systems, and pretty much all of the systems I check out for people. 
> You've got a DLV11-J in there so you've already got SLU0 in place (or can 
> strap it up for it). AK6DN has a bunch of useful TU58 images premade, with 
> listings of what XXDP utilities are on them.
What makes them hard to come by is that they must be preformatted for
the TU58, as far as I know
only DEC had hardware to do that.  The Drive as it stands cannot do that,

It is not capable of higher storage capacity as a result (hardware
limit, programming and no formatting).
> It's also possible to boot other OSes on TU58, like RT-11. There's even a 
> patched RT-11 driver to fudge the capacity on TU58s so you can use the 
> emulator(s) to store a much larger volume of data. Helps to set SLU0 for a 
> higher speed than 9600 if you plan on doing that :)
I run RT-11XM using TU58 a real one.  Boot times to load the RT-11XM:
driver and copy the tape and boot
to XM: virtual disk that takes about 5 minutes.  That's with the files
optimally placed on the tape
(in order of need) to limit the number of rewinds.

The VAX750 used TU58 to load microcode and diagnostics. Any os that can
fit on the 256K per tape
times two tapes would likely be bootable if it can do the serial
protocal used for the booter and the OS.

A PC emulation (or Rpi) can do this a bit faster (just over a minute for
a boot can copy to VM:) but you are
limited to the max baud rate (38K) of the serial port use by the DD
driver. 

There was at least one company that used a floppy drive (360K 5.25 or
720K for two sided) with a TU58 emulation
that was somewhat faster than tape due to faster seeks to a block.

Allison

> Thanks,
> Jonathan
>

Re: Ciarcia Micromint

[allison via cctech]

On 07/02/2017 06:54 PM, Fred Cisin via cctech wrote:
> On Sun, 2 Jul 2017, John Wilson wrote:
>> That sounds like the MPX16?  I thought the SB180 was a Z180 thing.
>
> You're right.
>
> Sorry
> thinking about the wrong one.
Yes for sure, as I have both SB180 and BCC180 both are Z180 based.
He also had a 8052 (with basic in rom) and the MPX16.


Allison

Re: PDP-8/a cleaning

[allison via cctech]

On 04/25/2017 03:45 AM, ben via cctech wrote:
> On 4/24/2017 1:19 PM, Pontus Pihlgren via cctech wrote:
>> Hi
>>
>> My PDP-8/A is up for restoration. More specifically and 8A100 according
>> to it's ID plate. It is in overall "ok" shape but oh so dusty.
>>
>> I'd like to give it a good cleaning so I'm tearing it down. And I'm
>> looking for suggestion to cleaning the backplane and regulator board.
>>
Dishwasher.   Its what I do.

>> I'm considering putting the Omnibus part under warm water and perhaps a
>> bit of mild detergent. Should I get distilled water or will tap do? The
>> water here is not very "hard"
>>
Tap will do since you will rinse with alcohol.

>> The regulator backplane has a relay and a button which will never dry
>> out if I soak it...
>>
>> Thanks in advance,
>> Pontus.
>>
>>
> I would go for distilled water, tap water could have chlorine it it.

The amount of chlorine (or its analog) is not a enough to be a factor.
If you can drink it and its not pool water.

Allison

> Ben.
>

Re: PDP-8/a cleaning

[allison via cctech]

On 4/25/17 6:06 AM, Pete Turnbull via cctech wrote:

On 25/04/2017 10:08, jim stephens via cctalk wrote:


On 4/25/2017 1:39 AM, Pete Turnbull via cctalk wrote:


"Little residue" would be more accurate, and some of that residue
will be water (look up "azeotrope") - plus you need a lot of
alcohol for something the size of a PDP-8 backplane.  Blow dry,
even after an alcohol rinse.


I should perhaps have mentioned that the idea is to flush the remaining
water or alcohol out by blowing, not evaporate it like your hairdresser
would :-)  And you ought to use dry air, ideally - most compressors 
have water in their air.



In the process of cleaning optics indeed you need air and other
means to do that, you are right.  But in this case I'm suggesting
the alcohol as a way to displace water out of internal parts. The
spotting or such is not much to worry about in the cleaning job on a
computer part.


Except those spotty residues are usually hygroscopic, which can lead to
corrosion later.


But in optics the process is much longer and elaborate, but still
needs the ventilation to be sure you don't have a problem with
fumes.


Sure.  Outside of electronics, my experience is in a chemistry lab 
needing clean dry glassware.  The process would go something like this:


- preliminary clean with whatever is best, often water and a little
  detergent/surfactant, then drain most off
- rinse with distilled water
- rinse with ethanol to flush out remaining water, then drain
- rinse with acetone to remove the alcohol/water residue
- air dry

Considering your also trying to remove possible hazardous material and 
leave a noncontaminating

surface its overkill to the max for a backplane.


In photography, on the other hand, the final rinse would just be water 
- tap water if not too hard - with a tiny amount of a wetting agent 
(eg detergent) in it.



Again you are striving to neutralize the chemistry used.

For a backplane or some PCBs I'd compromise, but closer to the 
photographic example than the chem lab.  In fact I've done that with 
my PDP-8s, rinsing the backplanes then blowing out most of the residue.


Considering a fan(s) has been blowing dust and who knows what else at it 
for years
cleaning is good and any residue is nothing compared to the crud that 
was formerly there.


In the pre-freon days the standard cleaner (when they did!) was a 
modified dish washer.
The usual mod was reshape the racks to hold the boards and lower the 
heater temperature
used for drying.  A week rarely went by that someone had open it mid 
cycle to see if

it was done.


We had a booboo in assembly that required cleaning and we no longer
had freon cleaner we wanted to use in that quantity, so we went with
the water / alcohol process.  A switch had defective sticky seals on
it and they had all gotten waterlogged.  Vendor claimed they would
survive water process wash and they were wrong.  Paid us quite a bit
in credit for messing up a couple hundred boards before we caught
the problem.


Ouch!


Plastics and elastic materials require more care for compatibility.
Water is usually the safest but, none can remain.

Allison

Re: TV Typewriter project nearing completion

[allison via cctech]

On 06/26/2017 11:29 AM, Brad H via cctech wrote:
> Thanks Nick!
>
> I had thought about selling PCBs or creating a kit, but I lack the skill to 
> draft it in PCB CAD software.  The boards I made come from scans of the plans 
> (on swtpc.com), and I really had to tweak those to get them to work.  And 
> even then, while I was able to correct for size I missed de-skewing them, so 
> the molex connectors for the bus between boards do not line up perfectly, 
> making connecting boards a bit of a trick.  I hadn't realized just how badly 
> scanning could distort artwork until I got my hands on an original copy of 
> the Radio Electronics construction guide for the Mark-8.  Comparing the 
> artwork in it to the scanned copies online showed just how bad the scanner 
> mangled things.  
>
> Unfortunately I missed a perfect opportunity to acquire an original 
> construction guide when an actual vintage TVT came up on ebay.  The auction 
> was for the TVT and the seller threw in the guide he'd bought.  I lost that 
> auction to Grant Stockly.  As it turns out, he plans to diassemble that TVT, 
> scan the boards and make kits available.  I was disappointed that he was 
> going to dismantle an original piece (he does intend to reassemble it), but 
> am glad some quality kits will come as a result.  We had been negotiating to 
> send my original Mark-8 boards for a scan, since they are unbuilt, but I have 
> been leery about shipping them off to the US ever since they were almost lost 
> in transit to me.
>
> If folks are interested I could make my 'corrected' (photoshopped) artwork 
> available somewhere.  Maybe someone could fix it further.  I may even fix it. 
>  Last week I acquired some actual vintage 1973 PCB stock, and now have an 
> opportunity to go the last mile on authenticity and actually rebuild the TVT 
> with correct PCBs.  That'd make it almost indistinguishable from an original. 
>  But.. it'd also be a ton of (re)work.. 
>
> Brad
>
>
> -Original Message-
> From: cctalk [mailto:cctalk-boun...@classiccmp.org] On Behalf Of Nick Allen 
> via cctalk
> Sent: Sunday, June 25, 2017 12:54 PM
> To: cct...@classiccmp.org
> Subject: Re: TV Typewriter project nearing completion
>
> wow impressive work Brad!  Thanks for blogging about it, it's fun to watch 
> you progress.  Ever consider selling some of the PCB boards, and coming up 
> with a BOM list, so we can recreate some too?
>
>
> ---
> This email has been checked for viruses by AVG.
> http://www.avg.com
>
>

I'll have to pull out the one I built in '75 as my first Altair non TTY
terminal. 
Bet it still works and has the 64 char mod.  The only issue was
stability of the
position adjustments.   One shots for timing... still not a fan.

Allison

Re: Kryoflux or Catweasle

[allison via cctech]

On 05/24/2017 02:19 PM, ben via cctech wrote:
> On 5/24/2017 12:30 AM, Chuck Guzis via cctalk wrote:
>> On 05/23/2017 05:31 PM, Andrew Harvey via cctalk wrote:
>>> I don't think Indivudual Computers make the catweasle any more. They
>>> never
>>> released a 64bit Windows driver for it.
>>
>> In point of advancing technology, one can purchase a STM32F4 development
>> board with USB, UART, microSD, battery-backed RTC and oodles of timers
>> and I/Os as well as a TFT interface for less than $12 shipped.  Almost
>> all I/Os are 5V tolerant--and can be configured as open-drain if
>> desired.  192KB of fast SRAM and a CPU running at about 168MHz.
>> Perfectly capable of doing sampling of floppy output.
>>
>> Why would anyone want a Catweasel at this stage?  Technology has moved
>> past that.
>>
>> --Chuck
>
> But who wants to write the software?
> I am building a 1977 ttl style computer because now I have spare time.
> Finding vintage or similar devices is being a challenge as well fighting
> modern OS to have even a C compiler and a TEXT editor.
> Technology is not better, just cheaper.
>
> I plan to use a low of LOW POWER 22V10's and undefined ALU logic
> since I have several designs I want to play with. NOW is your last
> chance to buy small quantities of things like 2901's and small TTL RAM's
> and floppy disks.
>
I have a load of all of those...  2901Cs the faster ones. The 2901 tends
to force
the flavor of the hardware and instructions toward microcoded machine.

If your doing your own design an interesting flavor is a TTA, Transport
Trigged Architecture
sometimes called a OIS (one instruction machine).  For that the machine
has one instruction
I did a Move machine and the whole word is source, destination and
options like jump if zero.
Tends to be very unique, can be fast and fairly simple since the
instruction cycle is fetch, do,
and repeat.  That can also be used as a microcode engine for a more
conventional machine.

When you build its hand to not dream.
 
Allison




> Ben.
>
>
>
>

Re: Extracting files off “unknown” 8 inch disks. Any thoughts…

[allison via cctech]

On 05/04/2017 07:39 PM, Terry Stewart via cctech wrote:
>> And yet, if there were an RX02 somewhere on this VAX, I don't believe
> you'd be able to read them at all... RX02 seeming more likely with a VAX.
>
> Interestingly PUTR, does seem to accommodate this, and the kind of system I
> have set up (i.e. 1.2 MB 5.25 inch in CMOS even though it's an 8 inch
> drive).  From the readme file...
>
> "SET x: type
>
>
> Sets the drive type for one of the four possible PC floppy
> drives A:-D: (note that actual PCs rarely have more than one or
> two floppy drives).  The type must be RX01, RX02, RX03, RX50,
> RX33, RX24, RX23, or RX26.  The default value for each drive is
> whatever was stored in CMOS memory by the ROM BIOS setup
> utility.
Yes but RX02 uses FM headers and FM2 sectors.  NO FDC CHIP CAN READ THAT.
None of the 765 family or WDC 179x and cousins can.

It was unique to DEC though Intel did similar but not the same on the
MDS800 dual density drives their difference was the whole media
was one recording format either single or double density.

You need a PDP11 with RX02 (or DSD880) or a catsweasel.

I know this as I have the former. 

Allison

> This command may be useful when the drive types stored in CMOS
> RAM are incorrect for some reason.  It's also helpful when an 8"
> drive, or a real DEC RX50 drive, has been attached to the PC
> using a D Bit "FDADAP" adapter, or something equivalent.  There
> is no standard for representing these drive types in CMOS RAM.
> Using real RX50 drives (or other 300 RPM quad-density drives
> such as the Tandon TM100-3 and TM100-4) is different from RX33s
> (which is what PUTR calls regular PC 1.2 MB drives) because the
> motor speed is slower, so the FDC chip must be programmed for a
> lower data rate to match."
>
>  I didn't spend too much time on PUTR as it seemed to be more for the older
> DEC OSs rather than Vax VMS.  VMS wasn't mentioned as an option in PUTR
> which is why I spent more time experimenting with ODS2, which was VAX
> specific.  And...as I said, PUTR tries to figure out what DEC OS (if any)
> is on the disk and failed to find one.
>
> Maybe I should play around with the switches in PUTR more before I give up
> though
>
> Terry

Re: The origin of the phrases ATA and IDE [WAS:RE: formatting MFM drives on a IBM PC]

[allison via cctech]

On 10/2/17 9:40 AM, william degnan wrote:



ATA-IDE and SCSI (OK SASI) are about the same age but had
different adoption and growth rates.

Earliest SASI/SCSI was AmproLB+ and Visual 1050 with adaptor.  I
have both with hard disks.
FYI the Z80 powered AMPROLB+ was 1984 introduction.


The Commodore D9060/D9090 pre-dates these and was a SASI derivative, 
right?  Not that it matters which was first, but just wanted to 
mention the CBM hard drive too. I have worked with the Visual and CBM 
drives, but never seen the AMPRO.



Hi Bill,

I used those as I knew the dates well having them since new.

Ampro was a basic 64K Z80 system with mini (5.25) or micro(3.5) inch 
floppy interface and if purchased the 5380 parallel/SCSI/SASI adaptor 
chip.  With it you could use the varios boards (Adaptec or Xybec) and 
the Shugart 20mb SASI drive with the existing software supplied.  I 
modded the BIOS to adapt it for a Fujitsu 45mb 3.5" SCSI drive a few 
years later. and it would work with most current generation SCSI-1 
drives save for partitioning and initializing.


The visual was actually older and used TTL to create SASI (scsi look 
alike) bus and the same adaptors

and drives to complete the hard disk side like the Ampro.

I still feel the SCSI bus was inspired by IEE488 (GPIB).

In the systems world my first SCSI on VAX was microVAX ba123 (uVAXIIgpx) 
with CMD controller
and a RD54(MFM 150mb) on an Adaptec Controller and later replaced with 3 
RZ56s (drive with SCSI internal).


Memries of the first SASI/SCSI was 33 years ago for Me, and VAX SCSI was 
1995 as that's when I got

the CMD controller.

Allison

Bill

Re: The origin of the phrases ATA and IDE [WAS:RE: formatting MFM drives on a IBM PC]

[allison via cctech]

On 10/2/17 8:22 AM, Jules Richardson via cctech wrote:

On 10/02/2017 01:46 AM, Alan Perry via cctech wrote:
There was a call to form the CAM (Common Access Method) Committee of 
X3T9.2

(SCSI-2) on 30 Sept 1988 and they first met on 19 Oct 1988. The primary
goal was to come up with a SCSI subset to facilitate it support in 
multiple

OSs and BIOS on PCs. At the first meeting, two items mentioned in the
minutes seem relevant. 1. Jim McGrath of Quantum was interested in
embedding SCSI in the drive without a physical SCSI bus and described
problems with reference to the PC/AT.


Does anyone know why IDE/ATA even came about? I mean, why SCSI wasn't 
used? It would have been an established standard by then, the drive 
complexity seems comparable to IDE/ATA (i.e. intelligent commands over 
a parallel bus), and SCSI controllers can be extremely simple - just a 
handful of LS logic ICs - unless you want to add loads of command 
queuing and such (again, comparable to IDE)


Roughly the same at the complexity level but SCSI was more costly as it 
was a defined bus
and did not include the actual device level hardware which SCSI disks 
needed same as IDE.
The ya but was to get SCSI to go faster it needed a complex chip in the 
computer (anyone

remember the NCR 5380 and its kin...) that was costly and PITA to program.

So in effect the IDE was a minimal interface that would interface to the 
computer bus
with no more than buffering.  SCSI required translation from PC buses to 
SCSI BUS and then
from SCSI to IDE(essentially the same electronics with SCSI bus 
interface).  IDE was always a
register interface where SCSI was a protocol that needed a smarter 
target.  Early SCSI disks
were MFM drives with Adaptec or Xybec host boards (SCSI to MFM, local 
cpu was Z80 on the adaptor).


ATA-IDE and SCSI (OK SASI) are about the same age but had different 
adoption and growth rates.


Earliest SASI/SCSI was AmproLB+ and Visual 1050 with adaptor.  I have 
both with hard disks.

FYI the Z80 powered AMPROLB+ was 1984 introduction.
Did it simply come down to pressure from vendors, wanting to 
distinguish between expensive workstation-class drives and something 
cheaper which could be associated with the lowly PC?


It was price...  ATA-IDE was cheaper and PC industry was working hard to 
push the price down.

SCSI always remained more costly.

Allison

cheers

Jules

Re: The origin of the phrases ATA and IDE [WAS:RE: formatting MFM drives on a IBM PC]

[allison via cctech]

On 10/2/17 10:13 AM, Jules Richardson via cctech wrote:

On 10/02/2017 08:29 AM, allison via cctech wrote:



On 10/2/17 8:22 AM, Jules Richardson via cctech wrote:

On 10/02/2017 01:46 AM, Alan Perry via cctech wrote:
There was a call to form the CAM (Common Access Method) Committee 
of X3T9.2
(SCSI-2) on 30 Sept 1988 and they first met on 19 Oct 1988. The 
primary
goal was to come up with a SCSI subset to facilitate it support in 
multiple

OSs and BIOS on PCs. At the first meeting, two items mentioned in the
minutes seem relevant. 1. Jim McGrath of Quantum was interested in
embedding SCSI in the drive without a physical SCSI bus and described
problems with reference to the PC/AT.


So in effect the IDE was a minimal interface that would interface to the
computer bus
with no more than buffering.


True, I suppose the command structure was more complex with SCSI. It's 
a shame though, it would have been nice if SCSI had been the PC 
standard, what with the large number of devices available, more 
flexibility, and performance potential.


It was/is widely used in PCs.  It put Adaptec on the map.  Servers and 
high end systems

commonly used it especially for early shadow and RAID systems.


Early SCSI disks
were MFM drives with Adaptec or Xybec host boards (SCSI to MFM, local 
cpu

was Z80 on the adaptor).


Xebec... but yeah, and I forgot that they used a Z80 (I was thinking 
it was some Intel 80xx thing). 

Later versions of bridge boards had the 8088 or 80188 16bitter.

I don't know if Xebec actually made a SCSI one, I think they may all 
have been SASI (at least the ones that I've used). I remember there 
was a little schematic in the back of the manual for a suitable 
controller.


Some were SASI and later firmware was SCSI...  Only difference as I had 
both.


Adaptec, Emulex and OMTI all made similar bridge boards... and there 
were probably others, too.



Yes, them too.

Oddly the first VAX to use SCSI or SCSI like was uVAX-2000 as the extra 
box with TK50 Tape

used that.

Allison

cheers

Jules

Re: Xerox 820

[allison via cctech]

On 11/21/2017 10:51 AM, Bill Gunshannon via cctech wrote:
> Any interest in a Xerox 820 board that never had it's construction completed?
>
> It's amazing the stuff I find digging through my boxes of junk.
>
> bill
Bill,

I'm likely one of the few around that can populate it with period parts.
Very tempting to add yet another project to my list.

Allison

Re: Xerox 820

[allison via cctech]

On 11/22/2017 08:51 PM, william degnan via cctech wrote:
> On Nov 22, 2017 8:17 PM, "Pete Lancashire via cctech" <cctech@classiccmp.org>
> wrote:
>> Wow that brings back some memories. There was about 10 of us who got
>> together and I can't remember how or who got 10 of them. I think mine is
>> still in storage somewhere.
>>
>>
>>
>> On Wed, Nov 22, 2017 at 4:54 PM, allison via cctech <cctech@classiccmp.org
>>
>> wrote:
>>
>>> On 11/21/2017 10:51 AM, Bill Gunshannon via cctech wrote:
>>>> Any interest in a Xerox 820 board that never had it's construction
>>> completed?
>>>> It's amazing the stuff I find digging through my boxes of junk.
>>>>
>>>> bill
>>> Bill,
>>>
>>> I'm likely one of the few around that can populate it with period parts.
>>> Very tempting to add yet another project to my list.
>>>
>>> Allison
>>>
>>>
> I have an 820-II but I also have a lot of 820  1/4 un software diskettes
> (but no 5 1/4" drive.  I can image and upload my disks if you'd like.  I
> have about 50 or so disks, various software.
>
> My 820-11 was new-old -stock when I got it whatever years ago, still have
> the orig boxes and all.  Takes 8in disks, has a working hard drive.  I
> think I have dBase and that kind of thing.

Everyone note Bill wrote the original post. 

For me an 820 would be another nice CP/M system addition.  From S100
based through
AmproLB+ and with disks ranging from  8", 5.25, and  3.5".  Once I got
the boot disk going
supporting software is easy as several of the CP/M systems Have hard
disks (AmproLB+, S100 box,
SB180, Visual1050) and I have my Walnut Creek CD.  HOwever ther eis also
Gaby's site and
a few others on line.

Allison

> Bill Degnan
> twitter: billdeg
> vintagecomputer.net

Re: Drive capacity names (Was: WTB: HP-85 16k RAM Module and HPIB Floppy Drive

[allison via cctech]

On 11/16/2017 03:30 PM, Geoffrey Reed via cctech wrote:
>
> On 11/15/17, 9:44 AM, "cctalk on behalf of Fred Cisin via cctalk"
>  wrote:
>> Can you name another 20 exceptions?   (Chuck and Tony probably can)
>>
>>
>> --
>> Grumpy Ol' Fred  ci...@xenosoft.com
>
>  ³Floptical² disks 720 rpm 1.6 Mb/s transfer 1250 TPI and 25MB unformatted
> capacity
>
>  LS-120 and LS-240 (which sadly I can¹t remember the specs of :(
>
>
>

Also the Syquest 270mb IDE/parallel port cartridge disk.  I have one
that works
and over a dozen carts.  Its still in use in a ITX box using the IDE
interface.  After
two decades of use it seems solid.

Allison

Re: Any difference between VAX Q-bus and PDP-11 Q-bus cards?

[allison via cctech]

On 12/06/2017 09:55 PM, Jon Elson via cctech wrote:
> On 12/03/2017 10:28 AM, Aaron Jackson via cctech wrote:
>> I'm looking after a VAX 4000 for a friend, which has a SCSI Q-bus card
>> (M5976). If the card did not have the large metal face, would it work in
>> a Q-bus PDP-11? We are not going to potentially ruin a card by trying
>> this, but I am interested to know if this is the case.
>>
>>
> As long as the PDP supports the 22-bit Q-bus, it should work
> perfectly.  The metal plate can be removed.
>
> Jon
Aaron,

Save the plate though as they are scarce...

MicroVAX used Q22.  The thing to be wary of is the Q-bus spec allows for
slots ABCD (wide)
and also ABAB if its ABAB its easy and no big issues unless  They
can also be ABABAB
(hex wide QBUS CORE).

Whats that mean... AB is the address, data and control bussed connectors
and CD are usually
parallel bussed but may have odd voltages or order to the signals for
some of the wide cards that
(usually RL and Memory) need them.  Its not unusual for a bus to be
mixed  like BA123 (uVAXII)
where the first 3 or 4 slots are ABCD and the remaining are ABAB.

IF the board requires ABCD such as the two board set RLV11 its important
as the two board talk
between them selves on the CD portion of the bus.

Also many of the uVAX and some later PDP-11 (J11based) the CD bus was
wired differently
for memory.

In most cases the ABCD portion of the uVAX backplanes are only a few
slots and then it reverts
to ABAB.

FYI if your in the ABAB area make sure you keep the bus grants and
interrupt grants continuous.

I know of this as I have PDP-11 and uVAX systems from LSI-11 though
uVAXII/GPX.  They are all Q
but there are more differences than Q16/Q18/Q22 due to the mechanical
variations.

Qbus board can be used in any system if they match the bus width (Q22
usually for uVAX) and
you pay attention to where you put them.  This includes a lot of the
PDP-11 Qbus cards. 

Allison

Epson PX-8 specifically TF-10 problem...

[allison via cctech]

I have several Epson PX-8s and i used them.. They work well with the
various wedges I have.

I also Have a PF-10 which is the portable 3.5" 40 track two side floppy.

The problem is it randomly does not turn the media unless I give it a
push to get it turning.

Things checked:
* Batteries, NEW fully charge (Both).
* internal Power supplies, current voltage and bridged with external
   supplies does not help.
* media checked for binding, it does not.

 When it turns it reads and writes correctly and at the correct speed.
 It may do so without help for many tries then will stop required a
manual push.

At first glance I though there were motor bearing issues but have verified
this is not so.   If I force motor on and restrain it I has good torque
and no
dead spots.  All signals in the motor control look good on the scope.

Any thoughts?


Allison

Re: Which Dec Emulation is the MOST useful and Versatile?

[allison via cctech]

On Oct 24, 2017, at 1:44 AM, Kip Koon via cctalk  wrote:

Hi DEC Enthusiast's,

If I were to have to decide on just one model DEC PDP system to run in a DEC
Emulator, which one would be the most useful, versatile and has the most
software available for it?

I have only ever used a real PDP-8/e system way back in high school so I'm
not up to par on any other model of DEC PDP system and I only know BASIC on
the PDP-8/e so not much there either.

I hear a lot about the PDP-11.  I found out that there were 16 major PDP
models at one time so I'm not too sure which one to pick.

I built Oscar Vermeulen's PiDP-8/I which I'm waiting on 1 part for.  Other
than that project which is in a holding pattern at the moment, I have no
other PDP anything running in any form.



The problem is how your asking.

First question is there is not one PDP system  and more than there is 
one FORD.

So you have to narrow the question to your interests such as 12, 16, 18, 32,
 or 36 bit systems as DEC made many very different systems.

Of those the PDP-8 series, 12 bit are interesting.
PDP11 the 16bit line
or for the unusual 18 bit PDP-7 or 36 bit PDP10.
There is even emulation for PDP-1 (18bit).

When you ask what is more versatile are you asking about the emulator or
the emulated end system?

For most the PDP-8 as its one system where the hardware and software is 
fairly

understandable to the lowest levels.

For the PDP-11 the variety of hardware and system configurations are 
nearly exceeded
by operating system and user software.  Its also the definitive Unix 
machine to some.

Its is one of my favorites either 11/73 as hardware or 11/70 as a sim.

As to SIMs  SIMH is by far the most widely known and versatile, with it 
and software

you can emulate most anything even something from your imagination.

E-11 Aka Ersatz-11 is a very good PDP-11 emulator.

There are no shortage of other simulators.  I'm sure everyone has their 
favorites.


Me I'm into the actual hardware so I have PDP-8F, an assortment of 
PDP11s from
the initial LSI-11 though the 11/73 hardware.  That and a boat load of 
MicroVAX
systems.  I limit my DEC systems to that scope for space mostly. THe 
rest of the

hardware in the collection is CP/M based (S100, Kaypro, Ampro...).

So pick a DEC system that has interest and simulate it or all if you 
have time.


Allison

Re: micro pdp11/83 power supply

[allison via cctech]

On 05/13/2018 01:51 AM, Waldemar Brodkorb via cctech wrote:
> Hi,
>
> I started to revive an old Micro PDP11/83 I have for over 12 years
> now. It is fully assembled and last time I tried to start the
> machine it some kind of started.
> My biggest issue at the moment is the power supply.
>
> After the machine is running for a while, let's say 10 minutes and
> then when I poweroff, the power supply starts producing a lot of
> dense smoke. The smell is very penetrant.
>
> What can I do with the power supply? Do I need to exchange it
> completely or just parts of it?
>
> At the moment I removed it from the case like described here:
> http://www.bitsavers.org/pdf/dec/pdp11/microPDP11/EK-MIC11-TM-002_MicroPDP11_Systems_Technical_Manual_Sep85.pdf
>
> Thanks in advance for any starting hints,
>  Waldemar
Make sure the cause is not the cable from the PS to the Back plane. 
Inspect the plugs for burnt
for signs of over heating.

There were two versions of the cable on had all the wires unequal length
to make the bend pretty,
the preferred one has all the wires equal size.

Allison

Re: Modifying microcode

[allison via cctech]

On 06/01/2018 02:46 PM, Antonio Carlini via cctech wrote:
> On 01/06/18 18:40, Eric Smith via cctalk wrote:
>> On Fri, Jun 1, 2018 at 11:08 AM, Robert Armstrong  wrote:
>>
 Eric Smith  wrote:
 The control stores of the 11/785, 8600, and 8650 were entirely WCS.

 All other VAXen had (relatively) large ROM control store and tiny
 WCS or
 patch store.
>>>    You forgot the 11/730 and 725.  The KA730 used 2901 bit slicers
>>> and the
>>> control store was entirely in RAM.  After power on it was a paperweight
>>> until the 8085 CFE loaded the microcode.
>>
>> Thanks for the correction! I've never used those models.
>>
>
> In the Digital Technical Journal #2 (the one that describes the
> development of the MicroVAX II)
>
> they say that they used the VAX-11/730 as a testbed
>
> the 78032 chip. The VAX-11/730 was chosen because it was "an entirely
> 'soft' machine".
>
>
> (The VAX-11/725 is essentially the same hardware but in different
> packaging).
>
>
> Antonio
>
>
It was my understanding from using the 730 that there was limited
(really limited) microcode
enough to load the WCS as the tu58 was a serial device (standard tu58)
and the 730 had to
unpack and stuff the WCS.  You need little to do that but far from even
PDP11 instruction set.
The Microcode was loaded was the "what made it a VAX stuff".

Allison

Re: Looking for North star software

[allison via cctech]

On 07/03/2018 01:58 PM, Fred Cisin via cctech wrote:
> On Tue, 3 Jul 2018, Stephen Pereira via cctech wrote:
>> I believe that Mike Douglas has a utility program that you can get
>> into a Northstar Horizon, and then it can receive a .DSK image sent
>> from the terminal and it will write the disk for you in the Horizon.
>> It’s called PCtoFlop and I think he has it in his archive here:
>> http://deramp.com/downloads/north_star/
>> 
>> Good luck!
>
> You "get it into a NorthStar", by already booting the NorthStar to
> CP/M, and using PIP.
>
> It looks like an excellent way to handle more images, including
> N*-DOS, AFTER you have CP/M working.
>
NO matter what first you have to boot the horizon and if you lack
prepared media its a hard stop.
Mike Douglass solved it by putting an Eprom on the ZPB-A as there is a
spot for a 2708 1K part.
He made up a header to use more common signal voltage parts like
2716/2732 and so on.
With a machine language monitor that allows loading bytes to memory the
process is then easy.

Me I cheated and used a spare 64K memory board that used 2kx8 parts and
put an eprom (2716) in
the F000H space.  Change the CPU boot address jumpers from E800/E900 to
F000h and now
you can talk to it via serial port.

The PCput and PCget are handy and no so big to hand insert.

Allison

Re: Looking for North star software

[allison via cctech]

On 07/02/2018 06:27 PM, Fred Cisin via cctech wrote:
> On Mon, 2 Jul 2018, dwight via cctalk wrote:
>> I have a machine that I'm just now bringing up. I have some boot
>> software but it is TSS/A that is the accounting multi-user package.
>> I'd really like the TSS/B floppies instead. I'd settle for images.
>
> Sounds like fun!
>
> What model Northstar?

There are three basic systems:
Horizon Single density
Horizon Double density same as single save for newer controller.
Advanatage, not s100!

>
> Once you get some images, have you worked out a way to get the images
> onto hard-sector disks?
>
If you can get code into the box NS dos can write disks from memory
images.  The based NS* horizon
roms are minimal and only boot a disk.  The easy path is if everything
works get a copy of NS* DOS
and boot it.  Then IO via serial gets easy.

> AFTER you boot the machine, with some minimal programs, you can
> transfer data into the machine through serial port.
Once NS*Dos or CP/M is there yes.  Until then the box is pretty useless.

Plan B is get or make a Eprom board with a monitor utility into the
h or FXXXh ram block (max 4K).

Plan B' get a cpu card with rom on it. 

NOTE: pins 20 and 70 are grounded so any card that uses those pins will
likely have to be modded.
(those are memory protect and unprotect for that era, IEEE 696
reassigned them).


Allison

Re: Microvax II 'primer'?

[allison via cctech]

On 1/22/18 2:18 PM, Douglas Taylor via cctech wrote:
I can't believe you 'just carry it into the house' all by yourself, 
unless you are professional athlete.
I also have a MicroVax II in the BA123 world box and it has wheels for 
a reason!  The damn thing weighs 130 lbs!

I took it to the VCF East last year, never do that again.  Too heavy.

Huge difference between BA23 and ba123 as the BA123 is about twice the 
size and internal board space.

I have both.  I can't lift a BA23 anymore, old back.


When I got mine, it had only 3MB of memory and I found that I couldn't 
install VMS 5.5-2 or 7.3 with that amount of memory.  I put in an 8 MB 
board and 11 MB total was fine.



Sounds about right.

You should make your own cable to connect the console to a PC or 
terminal.  Its that odd.  I found the PC connection to be helpful 
because you can log what you are doing.


Yes, remove the NiCad battery.


Its easily replaced.


The box I got had 3 RD53 disks in it and none worked.  I am using a 
Viking SCSI controller and a SCSI2SD drive to boot the system.


RD53s had a problem with the head sticking against the stops.  I repair 
them, yes I open them

unstick it then remove the offending the rubber parts.

A Viking or CMD SCSI controller makes using larger and more modern disks 
easy.  A disk of 500 MB

will run a lot of users and VMS will not use much of it.

I left the RX50 drives in and reconfigured the RQDX2 to address them. 
They come in handy for getting the VMS hobbyist licenses in.

The TK50 never worked.


It can be very handy.


I put a DELQA in for networking, never tried a DEQNA.

If the DEQNA works use it Support is there through V5.4 and the driver  
is there for later but

unsupported (don't call FS!).   Delqa tens to be more reliable.

I consider it an important machine in computing history.  It allowed 
scientific researchers, like myself, to get off of remote mainframes 
that billed at fantastic rates and compute in a more relaxed environment.

BTW there is one in the Air & Space Museum in Washington DC.

I have two MicroVAXIIs on in BA23, the other as a BA123 (uVAXII/GPX).  
Also a few uVAX2000,
and a slew of uVAX3100s.   A 3100 can be handy as both a VAX and a boot 
host for the MicroVAXII.
I run the whole bunch in the winter for a few days each year (12 
systems) as a LAVC

(local area connected) VAX Cluster.  Much fun and about 1400watts of heat.

Allison


On 1/21/2018 2:25 PM, Jules Richardson via cctech wrote:


So, I picked up (and I did just carry it into the house, and now I 
hurt) a Microvax II from another list member yesterday. Cosmetically 
it's a disaster (BA123 has a cracked top panel, broken wheels, 
missing front door, missing right-rear panel) but internally it 
appears to be complete; board wise we have:


  M7606 - CPU
  M7608 - 4MB ram
  M9047 - grant continuity
  M7504 - DEQNA ethernet
  M3104 - DHV11 8-port serial
  M7555 - RQDX3 disk controller
  M7546 - TX50 controller

... it's got a TK50 and hard drive (no idea of capacity).

Operational status is a complete unknown, and I have absolutely zero 
knowledge about these systems - so my question at this stage is what 
background reading I need to be doing in terms of pre-powerup* 
checks, actually hooking a console, if there's a suggested minimal 
config I can use to diag the CPU, and then (assuming it gets to that 
point) how to actually use the thing (I'm assuming it was running VMS 
rather than Ultrix, but I don't know for sure). I'm wondering there 
aren't any handy tutorials out there, alongside whatever DEC docs are 
recommended.


* e.g. for most machines I'd be thinking in terms of pulling all 
boards/drives, hooking up a dummy load to whatever PSU rails required 
it, and then at least running the PSU up in isolation first, but I 
don't know to what extent this machine requires some logic in place 
for the PSU to even run.


cheers

Jules

Re: Maxtor full-height 5.25" drives of death

[allison via cctech]

On 02/22/2018 07:45 AM, Ulrich Tagge via cctech wrote:
> /Here is my list. 6x RD54 (Maxtor XT2190) >2x OK, 2x Media Error, 1x
> Actuator Issue, 1x Head issue 3x RD53 (Micropolis 1325) >2x Actuator
> issue, 1x actuator issue followed by spinning issue (speed sensor?)
1325s with head stuck will normally spin down.  If the head does not
position there is no servo
so the motor control shuts the show down.  The fix is pop the cover and
remove the offending goo that
was the bead bumper stop.

Allison

> 4x Seagate ST251 >4x OK 3x Seagete ST225 >3x OK 3x IBM Type 068 >3x
> Dead On the 3.5" side I have also many dead drives (<1GB capacity).
> Mostly sticky actuators and dead tantalum caps, but by now nothing I
> was not able to repair. Many Greetings Ulrich /
>>>
>>> A tangential question out of curiosity: who here has 5.25" MFM
>>> drives they're extremely surprised are still working, and which
>>> model(s)?
>>> ...
>>>
>>> - John
>
>

Re: how good is the data reliability with CD ROM and DVD RAM?

[allison via cctech]

On 07/23/2018 09:21 AM, Devin Monnens via cctech wrote:
>> I have a lot of backup here stored in CDs, and I have recently bought
>> an SCSI DVDRAM unit to create new backups in caddies DVD-RAMs (of
>> 4.2Gbyte each)
>
> what is your experience?
>
>
>  I recently disposed of a couple hundred DVD and CD backups I'd made. As
> mentioned in a previous comment, it's simply too impractical to store
> terabytes of information in 4.7GB segments, plus they take up a LOT of
> space. HDDs aren't the most reliable, but this is what I use now for that
> reason. I make sure to keep the previous backup in case something happens.
> I'll only use optical backups now with the most important data.
>
> Backblaze has some interesting stats regarding HDD reliability (they are a
> data center using thousands of drives running constantly):
> https://www.backblaze.com/blog/hard-drive-stats-for-q1-2018/
>
> As noted previously, beyond storage conditions, disc longevity depends on
> the types of dyes used in the discs. Gold is supposed to be best. Early on,
> they experimented with a wide variety of dye types, and the silver dyes
> were least reliable, oxidizing in only about 10 years.
>
> The thing is, no media format is going to last forever. The only really
> reliable way of keeping data around is multiple backups and data migration.
> Basically, for your really important stuff, you'll want a couple of
> backups, stored in different geographical locations (one local, one on
> cloud works, too). You'll want to periodically refresh the backups by
> migrating the data onto fresh media.
>
> In the preservation business, the ideal is to refresh after the cost of
> storage media is 1/2 of the initial investment. So, if you paid $1 a GB for
> the initial storage media, you'll want to migrate once the new format is
> $0.50 a GB, and then again when it is $0.25 and so on. This way, the total
> cost is double what you initially invested.
>
> Of course, while the cost per GB might drop steadily, the total amount on a
> particular media format will increase as well, such that the $150 HDD you
> bought 5 years ago will have twice the storage for...$150. Definitely open
> to other suggestions.

I remember the first video disks that after 10 years would develop
sparklies
(video noise from errors).

I rarely use optical disks of any for though I still have CDR as a small
but
locally handy media.  There are many others over the years.  I generally
keep a few formats as working copies.  Any media for that gets refreshed
as needed and master copies are abundant as a backup.  Its rare they all
fail
at the same time, least I've never seen that.

For example for the CP/M systems 8", 5,25, and 3.5" floppies, refreshed
every so often.
The exception is the hard sector 5.25 stuff.  The pdp11 has RX01/2 and RX33
Both PDP11 and uVAX I have a large number of RD52 (Quantum D540s 31mb)
I use as cold swap backup storage media.  They are very good as the
media is
plated nickel-cobalt not the usual brown rust.  With more than two
decades of
doing that none have thrown an error or failed.  Of the larger RZ56s are
basically
used the same way save for SCSI class.

For the PC, I use older PC with big disks.  They are air-gapped
backups.  There are
several with all the same stuff in case one fails.  The routine is to
install and run
a new data drive for a while then copy the smaller to it and archive the
smaller.
Over the last few years I've resorted to using  large disks in a USB
case (so called
backup drives) where the case is open-able and I swap drive into them as
archive
copies with a write, verify, remove, and store cycle.  Big drives 300GB
to 1TB are
dirt cheap and I use them like flash sticks. 

 I also use USB flash as they seem solid though somewhat small if you
don't re-write
a lot.   I have a few that are a mere 128K byte that are over a decade
old and still
going.  However I am wary of widows systems as they tend to write a lot
of crap
on them besides the actual file.  Linux is kinder to them.

Allison

Re: VAX 11/785 "Superstar" Backplanes

[allison via cctech]

On 09/05/2018 01:53 AM, Paul Birkel via cctech wrote:
> On the 'bay: 183405165416 and 183405165414  "Scrap / Gold Recovery"
>
>  
>
> Six total.  One wonders what the scrappers did with the rest, and where they
> came from given that the location is Goffstown, New Hampshire.
>
>  
>
> paul
>
There were not many 785s,  The largest population were in the mill and
ZK (Nashua NH faciltiy)
So I'd expect most of them are Ex-dec.

Allison

Re: Microvax II 'primer'?

[allison via cctech]

On 01/23/2018 07:58 PM, Jules Richardson via cctech wrote:
> On 01/22/2018 02:05 PM, allison via cctech wrote:
>>
>>
>> On 1/22/18 2:18 PM, Douglas Taylor via cctech wrote:
>>> I can't believe you 'just carry it into the house' all by yourself,
>>> unless you are professional athlete.
>>> I also have a MicroVax II in the BA123 world box and it has wheels
>>> for a
>>> reason!  The damn thing weighs 130 lbs!
>>> I took it to the VCF East last year, never do that again.  Too heavy.
>>>
>> Huge difference between BA23 and ba123 as the BA123 is about twice
>> the size
>> and internal board space.
>
> Mine's the BA123, the bigger one. It's heavy! I lifted it out of the
> van myself and put it onto one of the kids' old sleds so that I could
> drag it through the snow to the door it needed to go through, then
> picked it up again and took it up the few steps that were necessary.
> Did I mention that it was heavy?
>
> I did take the side panels off, which helped a lot - I could lift it
> (just) then with one hand around the top edge and the other on the
> metal bar at the bottom by the power inlet. I certainly wouldn't want
> to carry one far.
>
Your younger than I.  I moved min in the summer so the wheels were good
end ough anda 2WD Toyota pickup (1999) is low
so it was slide it up and in.  Using a a winch didn't hurt either.


>>> Yes, remove the NiCad battery.
>>>
>> Its easily replaced.
>
> Does leaving it out entirely cause any issues (at least during a
> testing phase)?
>
> If it's actually holding a charge at present (I seriously doubt it,
> but it doesn't appear to have leaked) is there any benefit to leaving
> it in initially - i.e. is it responsible for retaining any settings
> (e.g. disk parameters) that it would be useful for me to write down -
> assuming the system proves to be operational - before replacing it?
>
If its working and not leaking go for it.  Its easy to replace when you
need to.

>> RD53s had a problem with the head sticking against the stops.  I repair
>> them, yes I open them
>> unstick it then remove the offending the rubber parts.
>
> That's useful to know - I'm certainly not against doing that myself if
> it proves necessary (assuming that's the drive I have)
>
My favorite line for all this is Kaplagh~!  Go for it and get the docs
they can really help! 

Allison


> cheers
>
> Jules
>

Re: NEC TK-80A Ref Manual Wanted

[allison via cctech]

On 03/06/2018 12:09 PM, Bill Degnan via cctech wrote:
> Looking for a reference manual to the NEC TK-80A trainer.  Rev A.
>
> This one:
> http://bugbookmuseum.blogspot.com/2015/12/computer-tk-80-single-board-8080.html
>
> Thanks
>
> Bill

So happens I have one of the TK80A and the manual.  Unfortunately
scanning the 100+ pages would be painful
an an old USB flatbed.

I also have one of the few auxiliary boards that had additional ram
sockets and power supply.

No its not for sale.

Allison

Re: 8085 Dissasembly?

[allison via cctech]

On 04/16/2018 03:01 PM, W2HX via cctech wrote:
> Hi friends. I have a 1990's vintage commercial radio system that uses an 
> 80C85A CPU. I am looking to hopefully modify the firmware to make some small 
> changes in its behavior.  The firmware is contained in two EPROMS.
>
>
> Can anyone recommend a decent disassembler to use with this? Preferably 
> something that ran in windows 10 or windows 7? A dos box would be fine too.
I've used DASMx freeware. 
My primary for that work is resource/Zsource but that runs on my CP/M
box where my EPROM reader/writer is.

Google 8085 disassembler.  Try several to see what works for you. 
Generally those that interact with the
user are best as you can sorta guide them around text sections and allow
you to assign descriptive labels to
sections (subroutines).

You may even need a 8085 simulator to test sections of code.

> Also, I looked through the dumped contents of the EPROM. In the past I have 
> seen EPROM ascii dumps where most is unintelligible to the naked eye but 
> typically text messages give to the users during interaction with the program 
> are human readable. In this case, the ASCII dump shows only other HEX data.  
> I believe I read that there is a HEX format and that I might need to convert 
> from HEX to BIN before disassembling. Of course, an ideal tool would do both 
> if anyone knows such a thing.
>
You may depending on what the tool expects.  Usually hex dumps obscure
the text.  Its not common for
8085 programmers to compress text.   That assumes the text is not a
bitmap for a LCD or LED then all
bets are off as to what you may see.

> I am not familiar with 8085 stuff but any insight would be appreciated.
>
I am.   You will need to understand the 8085, its environment (the stuff
it controls) and
what the memory layout(both rom and ram)  and IO layout.  Learn the 8085
instruction set.
FYI the 8080/8085 user manual is on line so find it and get it will be a
big help.

As they say, you will be working very close to the raw metal.

One worry is that the code could have been written in C or PL/M (or PLI)
and that may obscure the code further.

> Lastly, I wonder if there might be some kind of checksum check to prevent 
> tampering. Is there a common way this is handled in 8085 world? Or is it 
> entirely programmer dependent?

The 8085 does not have hardware checksum.  Its a programmer thing as in
who wrote the code and if there were
requirements by management or client to have checks (may include other
self tests and manufacturing
diagnostics as well).  However, its possible to do that in the code as
part of the startup self check (or BITE if mil). 
That only means you have to either negate that code (after finding it)
or you can find where the checksum is
and write a new one.   In cases where I've seen it it was early in the
startup and was there to verify
the Eproms were not broken than a worry about tampering.

Doing this is not trivial and you are in full forensic sleuth mode.


Hope that helps.

Allison/KB1GMX

Re: Teac Mt-2st/20D-12-u

[allison via cctech]

On 10/07/2018 01:48 PM, Craig Ruff via cctech wrote:
> I used to have a SCSI interface version of that drive type, I made backups of 
> my Mac Plus (I think it was) hard drive.  Since I don't have it currently, I 
> believe I gave it to a friend along with the rest of my Mac Plus peripherals. 
>  I don't recall the capacity of my specific drive, but it used a "data 
> cassette", which had a notch in the tape case to prevent use of regular 
> cassette tapes.
The version I have is not SCSI.

The part number looks up in the manual  as 90ips, Ferrite head and D/CAS
as the interface.

I've never had any Mac hardware before the Macbook, or VME.

Allison

Re: Datasheet for a NEC Chip in DEC Professional 350

[allison via cctech]

On 11/04/2018 08:10 AM, Rob Jarratt via cctech wrote:
>> -Original Message-
>> From: Tony Duell [mailto:ard.p850...@gmail.com]
>> Sent: 04 November 2018 12:42
>> To: r...@jarratt.me.uk; Jarratt RMA ; General
>> Discussion: On-Topic and Off-Topic Posts 
>> Subject: Re: Datasheet for a NEC Chip in DEC Professional 350
>>
>> On Sun, Nov 4, 2018 at 12:37 PM Rob Jarratt via cctalk
>>  wrote:
>>> I have posted previously about a DEC Pro 350 I am trying to get
>>> working again. At the moment it seems to be constantly resetting the CPU.
>>>
>>>
>>>
>>> I have traced one possible path for the cause of this back to a NEC
>>> chip for which I cannot find a datasheet. It is a 40-pin DIP it is
>>> marked "NEC Japan
>>> 8239K6 D7201C". All I have been able to find is more modern USB host
>>> controllers.
>> Almost certainly a uPD7201 multi-protocol (asynchronous and synchronous)
>> serial chip. I have an NEC data book with it in if all else fails but a 
>> google
>> search for 'uPD7201 datasheet' (no quotes) found sites with the data sheet
>> to download as a .pdf file.
>>
>> Quite why that should reset the machine is beyond me
> I have been trying to find what is driving this path in the logic and this 
> chip was the only one I for which I couldn't identify the pins, but it seems 
> that from this datasheet 
> (https://datasheet4u.com/datasheet-pdf-file/1098405/NEC/UPD7201/1) they are 
> all inputs and not outputs. So I need to look again for an output pin that is 
> driving this signal.
>
> Thanks
>
> Rob 
>
Rob, you need to have the drawing for the PRO-350, and read it.  Reset
on the F11 chipset is generally part of
Pwr-OK  and if reset is bouncing likely power is NOT ok. 

FYI the 7201 is MPSC a dual multiprotocol serial chip not unlike the
Z80-SIO.  Likely the system wide reset
is coming from the power OK generation as you seeing hardware reset into
the MPSC.

Hint: the pro350 is basically an 11/23 in a different form factor.

Allison

Re: BPK-72 or Bubble Memory Dummy Module + Seed Module

[allison via cctech]

On 10/09/2018 02:42 PM, dwight via cctech wrote:
> CHM has these in their collection. Where are you located at? They don't look 
> really complicated. I'd think one could make one if they had a schematic.
>
> Dwight
>
>
> 
> From: cctalk  on behalf of Josh via cctalk 
> 
> Sent: Monday, October 8, 2018 9:42:22 AM
> To: General Discussion: On-Topic and Off-Topic Posts
> Subject: WTB: BPK-72 or Bubble Memory Dummy Module + Seed Module
>
> Currently working on restoring some bubble memories and I'm looking for
> some modules originally included in Intel's BPK-72 development kit,
> specifically the Dummy Load module and the Seed module.
>
> http://archive.computerhistory.org/resources/still-image/Intel/intel.dummy_seed_modules.102652232.lg.jpg
>
> These are used for testing a bubble memory system as well as repairing
> bubble modules which have had some sort of failure which requires manually
> re-seeding them.
>
> I have all the parts I need to work with the modules, I'm just missing
> these parts. The manual shows the schematics, component values, and layouts
> of both of these modules, so I can fabricate them myself if need be, but
> wanted to see if anyone had them handy first.
>
> Thank you again!
>
> Josh
The seed module is simple.  The SM system with its driver, formatter,
and controller is a whole other thing.
I have two BPK-72s and they are interesting but 128Kb is not very big.

Allison

Re: Core memory emulator using non volatile ram.

[allison via cctech]

On 12/15/2018 01:01 PM, Guy Sotomayor Jr via cctech wrote:
> FRAM or MRAM.  I make extensive use of them in my projects.
>
> Everspin has a few (all SMT and 3.3v).  As I recall they run ~$20/ea for 4Mb 
> (512K x 8 or 256K x 16).
>
> TTFN - Guy
>
>> On Dec 15, 2018, at 1:22 AM, Rod G8DGR via cctalk  
>> wrote:
>>
>> I have an idea to produce an MM-8  clone using RAM that acts like core when 
>> turned off.
>> Can anybody suggest a chip that will do this?
>>
>> Rod Smallwood
>>
>>
My call on this is that cmos static ram 4Bit wide does the job well I
have 32K of it in my PDP-8 to
get past possible failure of hard to find and get core.  A Panasonic
BR-1 lithium cell has enough
capacity at the measured drain for about 6-7 years and the Dallas power
management chip
makes it a non hack.  Flash, EEprom and Magnetic FRAM and MRAM) types
have many unacceptable
properties for a random access read write memory.  It makes no
difference to the PDP8(ILEFMA)
that read is not destructive as it will write back as needed anyway.

There is a design on the 'net for using CMOS ram in a straight forward
buildable array for Omnibus
with battery back up that is fine.  Don;t get wraped around the axle
about RMW as any sufficiently
fast ram can do that without wearout.  And compared to core it doesn't
take much speed.

EEprom and Flash work fine for read mostly disks or disk simulators.

Allison

Re: Core memory emulator using non volatile ram.

[allison via cctech]

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

The cycle life is a limiting factor for things like swapping drums/disks
but for something that's
read mostly its ok.

Core is RAM, and not serial anyway.

Allison

Re: Core memory emulator using non volatile ram.

[allison via cctech]

On 12/15/2018 09:32 PM, Charles Anthony via cctech wrote:
> On Sat, Dec 15, 2018 at 6:15 PM Rod G8DGR via cctalk 
> wrote:
>
>> All very interesting.. 1201 alarm while I deal will all of the information
>> Rod
>>
>>
> 1202 coming up...
>
> I don't know specifically about the various memory types being bandied
> about, but I do know that the destructive read behavior of core memory my
> be required for some architectures; "load and clear" type instructions rely
> on the suppressing the write-after-read cycle to make the instruction
> atomic, allowing the implementation of data locking instructions. For some
> architectures,  it may be that any replacement memory would have to support
> the suppression signal to work correctly.
>
> -- Charles

That's all fairy land speculation and guessing.  The person that started
this is working with
a PDP-8E so the above does not apply.  the 8E and later had both DEC
made ram and third
parties did when 2102 were cheap enough about 78ish.    Later it was
battery backed up
cmos.  For system with disk a rom based booter was enough as who cares
if the ram held
valid stuff.  As to realism, the cost of a core was high enough then if
it broke or worse now
if it breaks its out of sight.  Breakage back then was costly, not its
possibly unobtainium.

The for the most part with the covers on the only thing noted was binary
blisters from the
switches and the incessant loud fans.   In the mean time the user was
interacting with a
TTY with its notable noises and if needing service a sometimes bad
attitude.  The fact that
CORE does a R-Rewrite or RMW cycle is both unseen without a scope and
had no impact while
running a file though PAL-III in all caps.

In the end, current generation CMOS ram is the easy out, battery is
small, cost is small,  and
produces much less of the heat that is killer to systems.   The only
reason to do that is core
cost big if you can find it for your machine.  I can cost more if you
want to run an OS that
needs a fair amount of it.  AC as well as it can help heat the room and
also power as in
makes the meter spin.

So much lathering and speculation about what and how.  When the point is
totally missed.

Allison

Re: Core memory emulator using non volatile ram.

[allison via cctech]

On 12/16/2018 10:07 PM, ben via cctech wrote:
> On 12/16/2018 8:00 PM, allison via cctech wrote:
>
>> In the end, current generation CMOS ram is the easy out, battery is
>> small, cost is small,  and
>> produces much less of the heat that is killer to systems.   The only
>> reason to do that is core
>> cost big if you can find it for your machine.  I can cost more if you
>> want to run an OS that
>> needs a fair amount of it.  AC as well as it can help heat the room and
>> also power as in
>> makes the meter spin.
>>
>> So much lathering and speculation about what and how.  When the point is
>> totally missed.
>>
>> Allison
>>
>
> What programs or operating sytems require non volatile core?
> Did DEC have any BOOTSTRAP programs in prom for the 8?
> A small prom and regular slow mos memory may be the solution.
> Ben.
>
None.

Non volitility was handy if you wanted to power down go home and restart
where you were
the next day but at the OS level that was never a consideration.

CMOS is MOS!  Current generation parts are cheap and easy to use.  Its
not a speed issue as
core was so slow, PDP-8 the fastest core was 1.5uS and even current cmos
(5101) was under 1uS.
No advanatage for slow memory as everything from 1978 on was likely much
faster than an 8e
needed anyway. 

The easy way if obvious use cmos as its cheap and common as house
flies.  Leave out the
small lithium cell. 

The problem is PROM cards for PDP-8 omnibus was not common at at then
then time cheap
and used parts likely to be unobtainium now.  The machines that had it
used an abbreviated
front panel  maybe 12 sense switches for the OSR instruction and a
boot/start switch.  Not many
made and FS contract required the full panel to do checkout and fix.  So
cost wise the boot card
was not common.  Call it an artifact of systems then.

The loader for most stuff was small anyway, toggle it in, usually rim or
bin loaders.  Run the reader
and that loaded whatever.

Typical small non disk systems were CPU, TTY and maybe a high speed
reader.  Next level added TU56
or maybe RX01 floppy, from there a DF32 disk and maybe a RK05 or two. 

The user interacted with them the box ala the CPU was a small part of
that interaction/experience.


Allison

Re: Origin of 'Straight 8' name

[allison via cctech]

On 12/21/2018 01:10 PM, Al Kossow via cctech wrote:
>
> On 12/21/18 10:03 AM, Al Kossow via cctalk wrote:
>
>> "Straight-8" seems to be a fairly modern name coming from collectors
>>
>> I never heard it called that before then.
> Anyone feel like doing a alt.sys.pdp-8 search for it by date?
>
> I don't feel like going down the rathole of trying to find a way to
> search Usenet by date right now.
>
>
Not I, that is a deep hole to dredge.  I do know it was a clear way to
differentiate the various
family of 8 machines and it was on alt.sys.pdp-8 I'd seen it way back
like mid 80s.
It may have been old by then.  I used to peek there as my first PDP-8e
was in hand
around late 1983.

And the automotive reference was not it.  It was the straight as in not
later lettered
versions.  Best similar use is:  Whiskey straight, water on the side.

One of the DEC history things about the era was often engineering went
may different
directions at the same time  making for a plethora of systems that were
or mostly
PDP-8ish like the PDP-12 that was PDP-8 and LINK.  RICM has a really
pretty one.


Allison

Re: N8vem and z80sbc

[allison via cctech]

On 12/03/2018 03:34 PM, trtech thetrtech.com via cctech wrote:
> Looking for software especially rom code for both of these SBC boards.
Does google or other search engine work where you are...

First hit was:   http://obsolescence.wixsite.com/obsolescence/the-n8vem-sbc

Allison

Re: music dec tapes? (paper)

[allison via cctech]

On 01/03/2019 11:15 PM, Kyle Owen wrote:
> On Thu, Jan 3, 2019, 17:48 allison   wrote:
>
>> I don't think this album has been forgotten; I have a copy, and I
>> know others with copies, too. It seems as though "Unplayed by
>> Human Hands" (both versions) are less well-known. I would like to
>> work on getting the original software archived, assuming it's
>> still out there, as it ran on a Straight-8.
>>
> ITs also on line.
>
>
> The recordings, or the software? If you're referring to the latter,
> please send a link! I know someone has a GitHub repository, but it's
> missing any and all PDP-8 files. 
>
> Kyle
>
Recording as in record album on Vinyl. 

Re: music dec tapes? (paper)

[allison via cctech]

On 01/03/2019 05:22 PM, Kyle Owen wrote:
> On Thu, Jan 3, 2019 at 3:29 PM allison via cctech
> mailto:cctech@classiccmp.org>> wrote:
>
> Those were likely with a PDP12 or LAB-8 with DAC board.  The code
> actually is a roughly
> digital version of tones in 10 or 12 bit form by writing sequential
> words (waveforms) to
> the DAC.  
>
>
> Do you have any information on the AA01-A DAC that was used with the
> PDP-12?

No but RICM as a PDP12or two.  Worth contacting them and all.  They
might like a copy of the
tapes if they don't already have them.

> I see in the PDP-12 System Reference Manual that it is capable of
> supporting three channels, 12 bits each. It gives an example of one
> instruction, 6551, which loads the first DAC. Is it safe to assume
> that 6552 and 6554 are the other instructions to load the other two DACs?
>
Unknown.

> I see the AA50-A in the 1972 PDP-8 Small Computer Handbook has
> sequential instructions for updating the DAC channels (up to 8).
>
> AA05-A/AA07 use a more complex address/data method to address more
> total channels, but that is listed in the Laboratory Computer Handbook
> as an option on the Negibus.
>
>
Never played with 8s in any form other than omnibus.

> Of course everyone here forgets the First Philadelphia Computer Music
> Festival on vinyl from '78
> with samples of computer played music.  I run my copy on occasion just
> to remember being there.
>
>
> I don't think this album has been forgotten; I have a copy, and I know
> others with copies, too. It seems as though "Unplayed by Human Hands"
> (both versions) are less well-known. I would like to work on getting
> the original software archived, assuming it's still out there, as it
> ran on a Straight-8.
>
ITs also on line.

Allison

Re: music dec tapes? (paper)

[allison via cctech]

On 01/03/2019 09:03 AM, Bill Degnan via cctech wrote:
> I have tapes with labels
>
> 8-152a 8 Music Coding Program Symbolic #1
> 8-152   8 Music Coding Program Symbolic #2
> 8-152   Teddy Bear's Picnic Symbolic
> 8-152a Penny Lane Symbolic
> 8-152 Joy to the World Symbolic
> 8-152 Your Mother Should Know Symbolic
>
> 8-152a Penny Lane 0037-7720, 0170=
>  0171=, 0172=7750,
>  0173=6020 Binary
>
> 8-152  When I'm 64
> 0037=720, 0170=7776
> 0172-7750
>
> 8-162   MUSIC FOR THE PDP-8
>  Load Tunes: 440
>  Play Tunes: 400
>
> "Start 8 Music"  (hand-written, no printed label)
>
> On Tue, Jan 1, 2019 at 9:03 PM Kyle Owen via cctalk 
> wrote:
>
>> On Tue, Jan 1, 2019, 15:18 Adrian Stoness via cctalk <
>> cct...@classiccmp.org
>> wrote:
>>
>>> anyone seen these music tapes before i grabed  this trays for the oddnes
>> of
>>> the content of these tapes? also apears to have the software to play
>> them?
>>>
>>>
>> https://www.ebay.ca/itm/Lot-of-15-digital-decus-Paper-Tapes-w-Case/273628629483?ssPageName=STRK%3AMEBIDX%3AIT&_trksid=p2060353.m2749.l2649
>>>
>>>
>> https://www.ebay.ca/itm/Lot-of-8-digital-decus-Paper-Tapes-w-Case/273628539210?ssPageName=STRK%3AMEBIDX%3AIT&_trksid=p2060353.m2749.l2649
>>> would this be some weird synthy type thing?
>>> control points for the sound boaerd used for automation on some fancy
>> desk?
>>> or somthing els?
>>>
>> Vince has a listing for some version of DECUS 8-152 on his website (
>>
>> http://svn.so-much-stuff.com/svn/trunk/pdp8/src/decus/8-152/decus-8-152-lst.pdf
>> ).
>> I have reverse engineered it enough to have his version play a few songs.
>> However, it seems like there's a difference between the music tapes I have
>> and the listing he has.
>>
>> I don't know what hardware was required of this software, but I suspect it
>> to be a DAC responding on address 055. This seems to match with an AA01
>> option.
>>
>> Did you end up buying these tapes? I have digitized the music tapes I
>> bought from the seller and will post them soon. It would be excellent if
>> the buyer of this lot would do the same.
>>
>> Musically,
>>
>> Kyle
>>

Those were likely with a PDP12 or LAB-8 with DAC board.  The code
actually is a roughly
digital version of tones in 10 or 12 bit form by writing sequential
words (waveforms) to
the DAC.  Before that it was done setting link and clearing link bit
with a timing routine.

There was a version of that also for MINC-11 and I've see variant back
when that used multiple
DAC cards for stereo or multiple voices.

It was also a thing for the S100 8080/z80 set (using a DAC) and many
other systems
(Kim-1, Apple, Cosmac, Commodore).

Of course everyone here forgets the First Philadelphia Computer Music
Festival on vinyl from '78
with samples of computer played music.  I run my copy on occasion just
to remember being there.

Allison

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

[allison via cctech]

> On Wed, Jan 30, 2019 at 9:49 PM Bill Degnan via cctech <
> cctech@classiccmp.org> wrote:
>
>> Random question
>> would you prefer having, if you had to pick only one, the original PDP
>> 11/70 or the newer "blue cabinets" PDP 11/70, assuming both were complete
>> configurations with racks of storage etc as they would have been sold, more
>> or less.
>>
>> Assume space and power are not issues, consider just the machine itself.
>>
>> Bill
>>
At first i treated this as troll bait.  Then thought about it some.

First despite caveats I don't have space so the likelihood is nil.
Also its outside what I do collect, that crates conflicts for space,
power and documents.

The reasons I could give for one or another are multidimensional.

Esthetic, the early 11/70 was of an era and that had a look.  The later
one as well.

Historical significance,  thats limited to the general model the biggest
fastest 11
made but having say serial number 001 or whatever was first off the line
for sale is
as significant as the last one off the line or both.  Also any along the
way that had
a instruction set or major hardware difference of some historical note. 
An example
of that would be an 11/74 as those were truly rare (maybe 4 assembled).

Operational, as in running it. definitely a late model near last built
as it would
have all the ECOs, be the least old, and should run well

Opportunity to save a machine that might be scrapped.  In itself thats
important
and it would be model independent.

Being a Qbus 11 collector there are still critters I might gather. 

Allison

Re: Thinking about PDP11 PC05 Emulation

[allison via cctech]

On 03/11/2019 02:11 PM, Jay Jaeger via cctech wrote:
> I have several PDP-11's in my collection (among other things), and not
> enough PC05 tape readers (or enough room) to go around.  But most if not
> all of my machines have M7810 PC11 interfaces, and I have one I could
> move from machine to machine as needed.  Moving a PC05 around would be a
> lot more work, and not every rack has room.  ;)
>
> So, I took a look at what it might take to interface with an M7810 (or,
> down the road, a PDP-8/L or PDP-12.  It looks like the emulator would
> have to accept as input just 3 lines (Initialize  L, IOP2(1)/Select,
> IOP4(1)/Read) [It would not need the redundant Initialize H, IOP1(1),
> Qualify or Skip], and would have to drive 11 lines into the pullups on
> the M7810 (8 Data lines, IO Bus INT L/Reader Done L, Outtape/Error and
> RDR RUN L/RDR Busy L).
>
> So, a total of 14 interface lines. (The 8 or 12 would take a few more
> lines).
>
> The pullups average about 470 ohms (1 is 1K, 1 is 220, the rest are
> 470), so at 5V the output has to sink a bit over 10ma, and all total
> 120ma.
>
> An Arduino Uno with an Ethernet shield would have 20 minus 5 lines
> available, in theory, but if one wants serial I/O as well for debugging,
> that sucks up 2 more lines - so only 13 available.  And sinking 120ma
> would be a bit much though I could likely sprinkle inputs among the
> outputs to make it work so as to stay within the recommended sink
> limits, and at least initially have it never run out of tape, and tie
> Error down.
>
> http://playground.arduino.cc/Main/ArduinoPinCurrentLimitations
>
> So, I am thinking about an Arduino Mega, as it has more output groupings
> to sprinkle the sink current around, and 5V interface capability, and
> more pins to eventually support my PDP-8/L and PDP-12.
>
> (I could do it with a PIC - did that for a Documation card reader to PC
> interface, but I am really tired of fighting Microchip's IDE.)
>
> BUT - it also occurs to me someone may have already done something like
> this?  Any leads / ideas?
>
> JRJ
The Uno or Nano is more than adequate.

To do the data you need 8 bits but you can bit bang them out using two
lines on a nano to
a 74ls164.  The rest you use transistors (open collector) to do high
current (though 5V,
1K pullup is only 5ma) and I'd do that to make the IO more rugged and
ESD proof.  That
covers the strobes and control lines.  Just using two lines to get the 8
data lines via a 164
frees enogh pins for there to be surplus IO lines.

Then I can load the Uno (or nano) via USB or Serial  or use 4lines to
interface a
uSD loaded with tapes ( MCLK, MSI, MSO). 

With 32K of program space the RIM and BIN load can be part of the
standard code base.

Then a library and software tool to load up the uSD or SD as usb to
SD/uSD socket adapters
are common.  It would be great to be able to get a file with all the
common tapes on it.
for loading into a 8 via a loader device.

I've not done this for PDP-8 or 11 but I can easily envision it.  The
Arduinos are
often fast enough if not faster than the host so speed is not an issue.

Allison

Re: M7264 Troubleshooting

[allison via cctech]

On 05/29/2019 07:17 AM, Noel Chiappa via cctech wrote:
> > From: Josh Dersch
> 
> > how is the backplane in the H11 currently configured? (i.e. what boards
> > are in what slots?)  Could the issue here be something as simple as a
> > break in the qbus due to a misplaced board?
> 
> He did mention that he had the console card in the slot next to the CPU, which
> I think is what you're referring to - but it shouldn't matter for ODT, which
> doesn't use interrupts, only programmed I/O.
> 
> A QBUS system will work fine without continuity of grant (interrupt, DMA)
> lines to boards which only respond to DATI/DATO (memory, non-interrupt I/O,
> etc). Just for grins, I took my -11/03, and plugged the console card in a
> bunch of slots down, leaving several empty slots between it and the CPU, and
> it worked 'fine': ODT was fine, and it would run "BR ." programs fine, too.
> 
> So unless there's actually a break in one of the 'broadcast' bus lines (e.g.
> BDALxx, etc) on that backplane, between the CPU slot, and the slot the console
> card is in, or something like that...
> 
> I suppose it would be worth while checking BDALn, BSYNC and BDIN _on the
> console card_ (I'm not sure where he was looking at them, before) just to
> rule out the broken bus line possibility.
> 
> 
> One thing that's bugging me, though; he said "BDAL3-13 .. are all active and
> jump around in some manner". But for the ODT microcode loop trying to read the
> console CSR, i.e. 0177560, BDAL7 (0200) and BDAL3 (010) should be 0, i.e.
> un-asserted.
> 
> So why are they jumping around too? Is this somehow related to the odd 
> behaviour
> I was seeing on my machine with no console card, where the BDAL line was 
> behaving
> in a way I couldn't understand?
> 

BDAL, Bus Data and Address lines.  During the nominal cycle the address,
then strobe, then data (from ot to an addresses device or memory) and
controls asserted for the cycle type (ReadWord, Read ByteHigh,
ReadbyteLOW, WriteWORD and so on.  There are also transfers on the
same lines for interrupt vector and priority.

All that makes the BDAL lines busy...

Generally the LSI-11 is a bit stranger as it also does bus level
memory refresh for dynamic ram card that do not refresh themselves.
The contemporary memory cards did not self refresh and used the early
4K or 16K 16pin devices.  Memory used for 11/23 (f11) and later
by then self refresh on the local card level was the norm and cut
bus traffic load.

Many of the functions were replicated as part of the T-11 CPU.

> I'm going to look into that more, to try and understand what I'm seeing there,
> but it won't be today, which is 'crane day'!

Big tree!

Allison


> 
>Noel
> 

Re: M7264 Troubleshooting

[allison via cctech]

On 06/08/2019 10:37 PM, Noel Chiappa via cctech wrote:
> > From: Allison
> 
> > ODT for the two systems are very different. .. KDF-11 the ODT is part
> > of the higher level code. The larger cards (11/23 and 23+) boot to
> > resident (ep)rom.
> 
> Ah, no. (Well, the KDF11 CPU's can boot to EPROM, which in the -11/23+ can be
> on the CPU card; the -11/23 is a dual card and has no functionality on the CPU
> card except the CPU.)

Yes that is what the para quoted above implies.  The resence of Eprom
and serial are unique to the F11 based and later J11 quad width cards.

All of the Qbus processor cards could boot to Eprom (TEV11) just like
the Unibus 11s.

And yes the KDF11 cpu does rely on higher level code inside the
microcode its how that code was structured [and made to fit].


Also there are three cards for the KDF11, one dual width, and two
quad width.  The 11/23 early did not boot all devices and had
different eproms (board level difference) than the later 11/23+
hence the + [and different part designations in the Mseries]
designation.  Back then FS noted that when requesting replacement
boards and history requires it.

> 
> The ODT in the KDF11's (and KDJ11's) is, just like in the LSI-11's,
> microcode, not macro-code. From the 1982 'microcomputers and memories'
> handbook, pg. 161 (in Chapter 7, "Octal Debugging Technique (Microcode
> ODT)"):

Save for the CPU and microcode are entirely different.  ODT as a
function is defined to do certain things how its done is vaguely
similar at best.  While implemented in ucode how its done and
depnendancies are very unique to the each (again cp1600 and F11)

>   "The console emulator Octal Debugging Technique (ODT)is a portion of
>   the processor microcode ... The console ODT implemented on the LSI-11/23,
>   PDP-11/23 and PDP-11/23-PLUS is identical."

Yes and unlike many here I have CPUs of all three form factors
operational.  However ODT on the dual width CPU does require a
serial card as there is no way to talk to it without.  That is an
important difference especially if jumpered for ODT.  Actually my
"11" series Qbus collection includes all of the CPUs from the LSI11
though J11 based. And the bus versions are greater from the LSI11
early (and H11) though the later ones with PMI some specific to
devices like the RL11 controller board set.

However LSI-11/23 whatever that is, typo? So I will say the CP1600
processor of LSI-11 and the F11 (KDF-11)processor have major differences
in how ODT works internally and on the bus and the code that does that
are very different.  To the user with a terminal its not very visible
but to the service person (or someone assembling a system) it makes a
difference.

ODT had a specification and if you reffered to it that inside DEC it
was not clear if it was microcode only that what the user/field service
saw behaved in a very specific way.  When applied to a specific
processor it had deeper meaning.  Some of that was factory test
related.  That Specification was an evolved thing as LSI-11 (cp1600)
lead to additions and minor changes that were important to Field
service and manufacturing.

> and on pg. 154:
> 
>   "Unlike the LSI-11 and LSI-11/2, the LSI-11/23 does not enter console
>   ODT upon occurrence of a double bus error"

Glad to see someone reads the books.  There are other differences on
power up and run states.  Like the ram and console dependencies

But all the M7264 posts were boiled down to the problem of not
reading and understanding that ODT for that version of the CPU
had dependencies.  As well as the evolution of Qbus family of PDP11
CPUs and their low level and bus level idiosyncrasies.

Most never refer to the LSI-11/23 that way to mean KDF-11 CPU its was
a documentation error that propagated in educational services and lead
to errors.  LSI-11 (CP1600) was the first generation Qbus and later was
F11 or J11 (or the T11).  The difference was not always small as there
were subtle instruction set differences and diagnostic impacts.  That
always had me during my yeas at DEC going which one are you talking
about, as every thing had at least three names (never minding numbers)
and one was usually ambiguous or a nonspecific family name.

> From which I think is quite clear that the KDF11's have microcode ODT.

It's not a question only the implications of how they did it.  That
they did it using using ucode is too road a generalization and misses
implementation details.

Its those details that get you when assembling systems and forgetting
to include functions that are required if not used.  That goes back to
how DEC supported their systems when computers no longer had front
panels.  It was a field service requirement so they were not trying
to wake a brick with nothing.


Allison

>   Noel
> 

Re: Possible PUTR bug?

[allison via cctech]

My Solution is easier, least for me.

I have a few Z80 CP/M machines with 765A in it and if it can't read it
its likely due to being hard sectored or M2FM.  I has 3.6, 5.25 and 8"
and  the 5.25 are Teac FD55gfh which are dual speed and can do all
modes. With my own software and utilities it does whatever even RX180,
RX50, RX33, and RX22/23 formats from the DEC pool.

The PC machine for when that stuff is needed is a DELL pizza box that
has 32mb of ram and 486dx/66 (ISA/ISA16) and can run dos though NT4 as
needed as I have a buttload of ST3660As as media for them (have two as a
spare).  That machine uses a combo IO controller for the FDC seems to do
what I ask of it.  Also an old Compag with similar features and PII and
32MB and also does Ethernet but the disk controller is a newer ISA16
using a combo chip and most of the combo chips after late 90s-ish seem
to have an even shorter VFO sync window (flash blindess).

I neither expect nor desire modern machine with anything past NT4 to
behave well with old disks.  Though Mini-ITX boards all seem to support
everything and anything and have all the legacy ports.  They all run
linux and if needed a partition (60mb of disk is trivial) for MSdos
6.22 or freedos.

Oh, unless its under threat the OS is linux, freedos, or if required XP
Though the latter is usually under VMware or Virtualbox on Linux..  I
just got tired of all the winders hassles and requirements for insane
hardware needs every few years.  Most stuff runs fine under dosemu or wine.

As to RT11, I have run mostly V5.0x and as needed if a device required
it a later driver borrowed from V5.04 or later.  It just seems to work
with out much pain.

As to running a RX50 on a PC...  That drive was a neat thing but its
mostly the interface is incompatible with most standard floppies and
a FD55A/B or any of the 48tpi 40 track drives will read and write the
media.  I make a point of only using it on PDP-11 as transfer media,
its low density so its marginal for much.  Keep in mine that drive
select is used to select the A or B drive of a RX50 there is no side.
They had a terrible track record for reliability.  I can put Two RX33
[teac fd55gfh] in the same space and store more.  Some to think of it
most Late PC 5.25 and 3.5 inch drives are incompatable with old standard
[TM100 and that era] as many do not have a 1 of 4 drive select jumper
and use the funky PC only twist cable.

I neatly sidestep all of the cruft and hacks needed for super wizbang
winXP and later machines.  I figure if I'm going to play with old
hardware I need to retain the old hardware to maintain them.  So I
retained the best of the best old PCs as they bulk of them are crap.
I buy new hardware that is not neutered.  Mini/Micro-ITX board with
atom or celeron CPUs (really all that's needed) are cheap and easily
built up into linux boxes or if you must any of the older 32 bit
winders incantations.


Allison



]On 05/11/2019 11:22 AM, Douglas Taylor via cctech wrote:
> I understand your frustration, because all I really wanted to do was
> read/write RX33 and RX50 5-1/4" floppies to move data in and out of my
> microPDP11.  Once, I wanted to write an RX23 3-1/2" floppy with OpenVMS
> PAK files that could be read on an DEC Alpha.
> 
> Finding a PC that supports the 5-1/4" floppy drive is difficult, the
> BIOS or FDC chips only support 3-1/2" floppies in many late model PC's. 
> It appeared only a few of the older PC's that supported the 5-1/4"
> drives could actually change the spindle speed so you could read/write
> RX50 format.
> 
> I dedicated a DELL XPS 233H to this task, 32MB memory, Pentium II cpu. 
> Boots from 3GB hard disk, DOS and Win 3.1 (if you so need it).  I also
> have an IDE to CF card adapter standing by when the hard disk dies. 
> Love to have something with a smaller form factor, but it gets the job
> done.
> 
> Doug
> 
> 
> On 5/11/2019 10:35 AM, Charles via cctalk wrote:
>> Just an update... I spent an entire long afternoon wrestling with that
>> old PC, trying to find some combination of HDD jumpers and BIOS
>> settings that would allow the XP hard drive to boot with another drive
>> attached (either on the slave connector or the secondary channel with
>> the CD-ROM removed). No dice.
>>
>> So I had the bright idea to use Minitool's Partition Wizard, and
>> shrink my Windows partition so there'd be room for a  newDOS partition.
>> But it won't even run (probably because I have only 64 MB RAM on that
>> box). Grrr. It's unbelievably slow anyhow, so more SDRAM on order,
>> which is really cheap these days.
>> I'd get a newer PC for the workbench, but need to keep the old
>> motherboard because there are a couple of devices (including a PB-10
>> PROM programmer) which are ISA slots.
>>
>> So, this has become a Windows/PC (ugh) project instead of just being
>> able to play with my PDP-11...
>>
> 

Re: Greetings

[allison via cctech]

On 04/28/2019 09:28 PM, Grant Taylor via cctech wrote:
> On 4/28/19 6:27 PM, Ray Jewhurst wrote:
>> I already have a Hobbyist License.  I am just interested in
>> experimenting with different OSes and different versions of OSes.
>
> ACK
>
> I don't know what VAX hardware VMS 1.5 supported, what VAX hardware
> that Simh supports, or what the overlap is between the two.
>
> There's a reasonable chance that someone will chime in with experience.
>
>
>
You are limited to what the VAX-11/780 system had for peripherals and
typically under 8MB ram (it maxed at 16mb).

Re: Greetings

[allison via cctech]

On 04/29/2019 11:37 AM, Jon Elson wrote:
> On 04/29/2019 06:47 AM, allison via cctech wrote:
>> On 04/28/2019 09:28 PM, Grant Taylor via cctech wrote:
>>> On 4/28/19 6:27 PM, Ray Jewhurst wrote:
>>>> I already have a Hobbyist License.  I am just interested in
>>>> experimenting with different OSes and different versions of OSes.
>>> ACK
>>>
>>> I don't know what VAX hardware VMS 1.5 supported, what VAX hardware
>>> that Simh supports, or what the overlap is between the two.
>>>
>>> There's a reasonable chance that someone will chime in with experience.
>>>
>>>
>>>
>> You are limited to what the VAX-11/780 system had for peripherals and
>> typically under 8MB ram (it maxed at 16mb).
> Well, for command-line computing (well, this IS the classic computing
> list) you can do a lot.
> Our first 11/780 had half a megabyte of memory.  Friday afternoon one
> memory board went bad, and I pulled it out.  A user group ran a
> gigantic batch job of mechanical analysis over the weekend on 256 K! 
> I was amazed, I really thought it would thrash itself to death on that.
>
> I ran a microVAX-II at home on one meg for years.

The typical environment during the DEC years '83-93 was a 780 with a
4-12mb and dozens of users or more.
In 83 that meant 3.2 or later and much of the time was V3.8 or 3.9 till
maybe 86ish then V4 and soon after V5.
The years 83 and 84 I fondly remember V3.6 and later mostly 3.8 and
often the best available machine was
a PDP-11 [PRINCE] and [VIDEO] as the terminals and printers machines
were running RSTS and phase II DECnet.
Others of memory were MILRAT, REX, and ROYALT and later (1989) my own
work box VIDSYS (uVAXII BA123].

If memory serves V4 was the last that ran in 1meg, V5 pushed that higher
as a 4 meg system was more
common then.  However the Qbus uVAX has a RD54[system] and RD52[swap] on
separate MSCP controllers
for performance as thats where they bottlenecked when heavy swapping.

All my uVAXen have run from V4.4 [MicroVaxII/GPX] or later and my
nominal version is 5.4.  Though I have a
RZ56 with V7.2 on it.   All are physical hardware in the Qbus BA123
realm and M3100 series. 

>
> But, I never experienced VMS before about version 3.4, I think.  I'd
> really hate to run any VMS that didn't have loadable device drivers. 
> Doing the brute force sysgens was so RSX-11 ish.
> I think VMS 1.5 still had a bunch of utilities running in PDP-11
> emulation.
>
> Jon
>
Running anything before V3 is painful as it was a build.  Also V1 was
tied the 780 and that did PDP11 emulation
mode for a lot of stuff.  VMS changed a lot from 4.2 to 4.6, long file
names are one that comes to mind as well as
phase III and IV DECnet.

That was a long time ago.

Allsion

Re: Quantum 2080 and 540 service manuals

[allison via cctech]

On 11/16/19 12:48 AM, Chuck Guzis via cctech wrote:
> On 11/15/19 2:21 PM, dwight via cctalk wrote:
>> Heads getting stuck on the ramp?
>> Maybe it has warn a groove in the plastic. It could be the bearings on the 
>> head assembly as well.
>> Dwight
> 
> Dunno--I only fire the thing up about once every 5 years or so...
> 
> --Chuck
> 

Mine are in the once a year for the lest frequently used and a few at
least once a week.

I find them bullet proof.

Allison

several items for sale and a note.

[allison via cctech]

Note:  we have some entity scraping the list(how is not determined).
If I post I find that I get spam for about a week after until I post
again.  Most of the SPAM is scamware.  It maybe someone with a virus
on their system or a account that is for a bogus user.  Take from that
what you may.


Now stuff for sale:
The rules are, none for free, make a reasonable offer.  PICKUP only
eastern MA in a reasonable amount of time.  I WILL NOT PACK OR SHIP,
too heavy, damage too likely.  Make offers offline, anything no
interest will be disposed of.


First item:
  Vt180, complete sans wart box, operating, and with second set of RX180
  drives.  I will not break this up. I have some disks for it as well.
  Terminal box is 8 or better and not too yellow.

Second item:
  California Computer Systems (CCS) S100, with z80 CPU, 64K ram,
  Multi-serial IO Floppy disk controller and manuals.

  System is operational save for no disk drives as I am keeping
  the set I have.  However I have two half height loose drives
  of unknown status.

Future offers when I'm done with them include:
  Two PDP11 (11/23 series in BA-11 series boxes)
  Northstar Horizon S100 MDS-A controller, Z80, memory,
  with at least 1 floppy and working.


Allison

Re: several items for sale and a note.

[allison via cctech]

I can't it's in the way.  Space and all are the reasons.

You can get the pin out for both ends from the manuals and the prints.
If you get it wrong things just don't work but no breakage.

On 11/22/19 3:42 PM, Henk Gooijen wrote:
>  
> 
>  
> 
> *Van: *allison via cctech <mailto:cctech@classiccmp.org>
> *Verzonden: *vrijdag 22 november 2019 20:01
> *Aan: *cctech@classiccmp.org <mailto:cctech@classiccmp.org>
> *Onderwerp: *several items for sale and a note.
> 
>  
> 
> Now stuff for sale:
> The rules are, none for free, make a reasonable offer.  PICKUP only
> eastern MA in a reasonable amount of time.  I WILL NOT PACK OR SHIP,
> too heavy, damage too likely.  Make offers offline, anything no
> interest will be disposed of.
> 
> First item:
>   Vt180, complete sans wart box, operating, and with second set of RX180
>   drives.  I will not break this up. I have some disks for it as well.
>   Terminal box is 8 or better and not too yellow.
> 
> Allison
> 
>  
> 
>  
> 
> I hope the buyer (or maybe you Allison?) will take the time to beep
> 
> the floppy disk drive interface cable.
> 
> The floppy drive side has a DB-25 connector, the VT180 side has a
> 
> DC-37 connector. Not much to find about it on the internet,
> 
> See www.pdp-11.nl/vt180/vt180-info.html
> <http://www.pdp-11.nl/vt180/vt180-info.html>    I would love to get
> confirmation that the home-made cable is correct …
> when I'm done with them
>  
> 
> Thanks,
> 
> Henk
> 
>  
>