Re: Nuke Redmond!

2019-10-07 Thread allison via cctalk
Its been a while but same game and I'm not a player.

I just don't run windows.  I jumped that ship back in 06 when
burned on NT.  Since then its Linux.  If you play in the swamp
of M$ then your run all the risks and costs.  Its just not good
enough to be worth the pain.  Any new machine I might buy must
be bare or come with Linux and in the past Asus did a few that
I still run.  If not I default to ITX/miniITX boards/boxes as
they are easily gotten bare.

It also reminded me of Micro$soft Roads, a few of us likely
remember that one too.

Wait till M$ AI on your car decides some roads do not meet the
terms of service and refuses to go there.

Since schools and Uni's all seem to be M$ based maybe the terms
of service are in effect there.

And tubes... I'm like one of the few here that knows how to design
with them because I did.

Allison


On 10/7/19 10:54 AM, Ethan O'Toole via cctalk wrote:
>> downloaded for free is meaningless to the actual case.  Not saying I
>> agree with the law they got him on as there should be some exceptions
>> but facts are the facts.  Btw. This was the first version of the story
>> I read that mentioned that Microsoft sold replacement restore disks to
>> computer refurbish shops themselves.
> 
> I thought Microsoft would refer you to Dell, and Dell would be the ones
> to sell them.
> 
> Had the discs not looked like the original restore discs then he might
> of gotten away with it? Trademark infringement and all. Fake Louie.
> 
> It's stupid. It really is a mess trying to restore the OS when the hard
> drive dies on machines that ship with recovery partitions and no media.
> 
> I mean, the fact the restore media is on a CD/DVD just says that it's
> for old crusty computers.
> 
> New machines have the license keys baked into the BIOS, the Windows tax
> is built in.
> 
> But the Netflix Bill Gates docuemntary says he is cool so the young
> people trust Microsoft. And of course the beautiful machines Apple was
> making kind of went to hell as they focus on telephones, which are
> declining.
> 
> Pretty much trapped.
> 
>     - Ethan
> 
>> Now if I made a copy of Raiders for someone else or copied it off a
>> free TV transmission and sold DVDs of that, it would be a crime since
>> there still is a way to buy a replacement DVD or watch/DVR it on free
>> TV when it happens to be on.
> 
> But that is different as Windows is protected by a software key, so the
> restore disc is useless without it.
> 
>>
>> Cheers,
>> Corey
>>
>> corey cohen
>> uǝɥoɔ ʎǝɹoɔ
>> Sent from my iPhone
>>
>>> On Oct 7, 2019, at 7:15 AM, John Foust via cctalk
>>>  wrote:
>>>
>>> At 05:51 AM 10/7/2019, Dave Wade via cctalk wrote:
 Must be the USA PC World. In the UK they would have tried to sell
 you an extended warranty as well which is really just an insurance
 policy
 .. but the question is why PC World. Don't US universities have
 student discount stores?
>>>
>>> University student discount stores?  You mean those state-sponsored
>>> computer shops that put all the private computer shops out of business?
>>>
>>> Only 1.2 :-), as for example in a nearby (10K student) university town,
>>> there are no longer any private computer repair shops that a non-student
>>> can go to as far as I can tell, so I'm actually picking up more business
>>> because I'm one town away.
>>>
>>> - John
>>>
>>
> 
> -- 
> : Ethan O'Toole
> 



Re: fix? Repair? or leave alone? http://rcade.camden.rutgers.edu/2020symposium.html

2019-09-27 Thread allison via cctalk
On 9/27/19 2:07 PM, Chuck Guzis via cctalk wrote:
> On 9/27/19 9:22 AM, Brent Hilpert via cctalk wrote:
>> On 2019-Sep-27, at 6:47 AM, Paul Koning via cctalk wrote:
>>> I make it a habit to assume that every email which contains just a
>>> link but no explanation is a scam with a forged sender address.
>>>
>>> Ed, if this is actually from you and actually real, and you want
>>> people to look at it, you need to say what the link is.
>>>
 On Sep 27, 2019, at 3:10 AM, ED SHARPE via cctalk
  wrote:

 http://rcade.camden.rutgers.edu/2020symposium.html
>>
>>
>> "... explored these processes of repair and has focused on their
>> non-linear temporalities."
>>
>> "Repair does not necessarily focus solely on “the reproduction of
>> social and material order,” but also opens up space for the
>> “creative, inventive and innovative work that happens in the process
>> of fixing, across human and non-human bodies."
>>
>> "... offering us a way to historicize and contextualize the work of
>> repair and maintenance. That means avoiding the romanticization of
>> repair while also recognizing “traditions of women's work, domestic
>> and reproductive labor, and all acts of preservation, formal and
>> informal.”"
>>
>>
>> Don't waste your time, unless you're going for some entertainment in
>> watching ridiculous people.
> 
> My reaction also--bunch of word salad devoid of meaningful information
> that reads like someone's attempt at a dissertation.
> 
> --Chuck
> 

This topic has gotten far more words and attention than the poorly
written mental spew that pretends to be intellectual.  If I were
grading their work it would be a D- and a fail is less significant.

The scam is eating your time which is worth something with nothing in
reward.  Lets call it 5 minutes you will never get back.

Allison






Re: phone systems, old and less-old

2019-09-19 Thread allison via cctalk
On 9/19/19 12:56 PM, Kevin Monceaux via cctalk wrote:
> On Wed, Sep 18, 2019 at 09:05:07PM -0700, Chuck Guzis via cctalk wrote:
>  
>> 25 pairs, where
>>
>> White Red Black Yellow Violet for each "bank" and within each bank
>> Blue Orange Green Brown Gray
> 
> From what I've heard and read, where a 25 pair cable is concerned, it's
> slate, not gray.
> 
> 
> 
Grey or slate for outer jacket and the listed colors for wire pairs
or groups of pairs in the cable.

Allison


Re: Vulnerabilities (Was: [Simh] Fwd: VAX + Spectre

2019-09-17 Thread allison via cctalk
On 9/17/19 3:08 PM, Fred Cisin via cctalk wrote:
> On Tue, 17 Sep 2019, Paul Koning via cctalk wrote:
>> I could easily imagine a computer science exam question "Describe in
>> one paragraph the specific design error that enabled the Meltdown
>> attack".
> 
> I used to have some related questions in my microcomputer operating
> systems class.  One student (who later became my best friend and buddy)
> skipped the technical details and said, "The primary design error for
> MacOS and Windoze (sic) is that they placed a lower priority on
> security, than on being able to transparently and without user action,
> add smell-o-vision, dancing kangaroos and yodelling jellyfish."
> 
> (YES, that's where I got that phrase from.)

Fred,
I love it.

My feeling is if you don't stop the mongrel hordes at the door you've
lost. After all wasn't it Vonada that indicated computer are at best
partially tested?

Allison


Re: [Simh] Fwd: VAX + Spectre

2019-09-17 Thread allison via cctalk
On 9/17/19 1:49 PM, Warner Losh via cctalk wrote:
> On Tue, Sep 17, 2019, 6:40 PM Paul Koning via cctalk 
> wrote:
> 
>> Yes, I understand that a number of ISAs are vulnerable.  The original
>> paper by Kocher clearly mentions both x86 and ARM.
>>
>> The reason I forwwarded the question is that I'm not aware enough of all
>> the VAX variants to answer whether there are any VAXen with speculative
>> execution.  If no, then we're done, the answer is easy.  (That was the case
>> when the question was asked for PDP11s.)  But if yes, then it becomes
>> necessary to read the paper carefully to see if any of the prerequisites
>> are implemented in some VAX, and if yes, what the fix might look like.
>>
> 
> Early Vaxen are immune. Latter day ones require careful analysis since they
> have some out of order things. I'm not expert enough to know for sure,
> though, and the latter day stuff is half remembered from marketing material
> for one of the final generations of Vax big iron before Alpha drove that
> away... But I don't think many of these old beasts are still running even
> if my half remembered stuff is right...
> 
> I'm reasonably comfortable assuming that the somewhat-related "Meltdown"
>> vulnerability doesn't show up in VAX, because that issue requires a
>> designer who'd implement page access checking in a way I would not expect a
>> DEC engineer to do.
> 
> 
> I'm agree.
> 
> Warner
> 
> paul
>>
>>> On Sep 17, 2019, at 11:42 AM, Clem Cole  wrote:
>>>
>>> Paul - be careful.  All CPU's post the IBM AGS that used branch
>> prediction are suspect.   Russ Robelen (who was the 360/50 lead, worked on
>> 360/90 and lead AGS) has the speculative executing patent.   I tweaked him
>> when it all came out and said - look at what you did.
>>>
>>> What Russ and team are great ideas and we all have used them since they
>> first published about it.   And the fact is that it took 40 years before
>> someone even proposed that it was an issue and could become security
>> exploit (by some folks in German at a security conference) and it Google 18
>> months to reduce it to practice.
>>> ᐧ
>>>
>>> On Tue, Sep 17, 2019 at 9:55 AM Paul Koning 
>> wrote:
>>> "Spectre" is one of two notorious bugs of modern CPUs involving
>> speculative execution.  I rather doubt that VAX is affected by this but I
>> suspect others here have a lot more knowledge.
>>>
>>>   paul
>>>
 Begin forwarded message:

 From: co...@sdf.org
 Subject: VAX + Spectre
 Date: September 17, 2019 at 5:32:42 AM EDT
 To: port-...@netbsd.org

 So, this is a bug report:
 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86811

 GCC would like to know if VAX needs Spectre-related work.
 Are any of the VAXes ever made capable of speculative execution? the
 first tech for doing it was in 1967, so not entirely far-fetched.
>>>
>>> ___
>>> Simh mailing list
>>> s...@trailing-edge.com
>>> http://mailman.trailing-edge.com/mailman/listinfo/simh
>>
>>

I see this as a question of the number of angels that can dance on the
point of a pin.   But could GCC compile code that has system access to
do nasties is a more complex question.  Then again how does it get
system prives to start with?

First VAX represents more than a dozen different implementations from
the 780 though the many CMOS versions so what might be an issue for one
is likely not for another.  The other half is the OS in use may be
sufficiently able to keep rogue processes confined. Of course there
are the LAVC and bus connected multi-cpu clustered systems.

In the end its mostly meaningless as the only reliable way to take a VAX
down is trip on the power cord, assuming you can get to it.

Allison


Re: RL02s available

2019-08-22 Thread allison via cctalk
On 8/22/19 12:46 PM, William Donzelli via cctalk wrote:
> I have a pair of RL02 drives available, and can bring them to VCFmw in
> about three weeks. Pretty cheap. Untested.
> 
> Contact me off list.
> 
> --
> Will
> 

Where are they now?

Allison


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

2019-08-16 Thread allison via cctalk
On 8/16/19 5:46 PM, Brent Hilpert via cctalk wrote:
> On 2019-Aug-16, at 11:56 AM, systems_glitch via cctalk wrote:
>> On Fri, Aug 16, 2019 at 2:53 PM Paul Koning  wrote:
>>>
 On Aug 16, 2019, at 2:43 PM, systems_glitch via cctalk <

 I'm sure DEC wouldn't have bothered with hard gold plating if their
 connectors were metallurgically incompatible :P The few busted DEC
 connectors I've replaced did indeed have selective gold plating on the
 contact surfaces. Most quality edge connector slots are similarly
 constructed.
>>>
>>> It's been a while and I never looked in depth, but it most definitely is
>>> not true that gold is only compatible with gold.
>>>
>>> From what I remember, the detailed analysis involves an "electrochemical
>>> series", which has metals like sodium at one end, copper closer to the
>>> middle, and gold at or near the other end.  Metals are compatible if their
>>> potential value differs by less than a limit.  The limit depends on the
>>> environment; in an office you can have a larger limit than on a ship where
>>> you have salt spray, or a tire factory with lots of SO2 in the air.
>>>
>>> There are also some twists; I think stainless steel is compatible with
>>> many things thanks to the alloy ("stainless") properties.  In fact, I think
>>> the subject came up in connection with failure analysis of coin cell
>>> battery holders.  The battery cases are stainless steel; the question is
>>> what contacts are acceptable.  Gold is; there may be others but some things
>>> that are used in the market are not good choices.
> 
>> You can look it up in an electronegativity chart for a quick "will these
>> ruin each other" check.
>>
>> I think a lot of this comes from the SIMM era in PCs, where folks were told
>> to only use gold-flash SIMMs in gold sockets, and only tin plated SIMMs in
>> tin plated sockets.
> 
> 
> I've seen pieces of HP high-end lab equipment from thru the 60s that used tin 
> plating on the PCB edge fingers, mating into gold-plated edge connectors on 
> the backplane.
> Never quiet understood it, they (HP) were doing gold-plated edge fingers on 
> other equipment at the same time.
> 
> 

Back in the dark ages when MITS Altair (and dirt) was new

Initial board were tin and not the fancy stuff either,  sockets were
commonly gold. then came the occasional gold.  What was nasty was the
gold over copper not gold/nickel/copper...  Can you say Electromigration
and green plague?  It was the cause of the shake well disorder as in
before powering up, pull the board and wipe the edge connector,
re-insert boards and it would be hopefully stable, maybe.  I had to
retire that machine after about 2 years it was so flakey due to that.
By then the suspect boards were retired and never used again.

Looking back and having it to look at part of the issue was crappy gold
plating (looked good) and also some of the sockets did not have a hard
wipe or high spring tension both of which were likely causative.

I've not see that anywhere else.  Dec connector blocks are hard wipe
and very good at what they do, make a connection.  Even tin plate seems
to be no trouble at all.

Allison



Re: Ill NLS MS-230 ---manual!

2019-08-01 Thread allison via cctalk
On 7/29/19 10:30 PM, Jim Brain via cctalk wrote:
> On 7/29/2019 9:24 PM, allison via cctalk wrote:
>>
>> Since you replaced the batteries did you check the fuse?
> Yep, good.
>> Also the 4066s
> Hmm, all mine are soldered in.  Do you suggest I desolder and check?
>> sometimes get cranky and/or the sockets.
> Only one '00 has a socket.
>>
>> The tough fail would be the CRT. Check the heater pins with a multimeter
>> to see if its open (unplug it as there is a transformer winding across
>> it).
> I'll check.
>> Mine needed one when I got it but they were available then (1977)
>> from NLS. Side effect of the hammer mechanic owner.  Now it would be a
>> hunt though old tube brokers.
> Yep, I know that'd be the main issue, but I am hopeful it's something
> less problematic.
>>
>> Allison
> 
> 



Re: Ill NLS MS-230

2019-07-30 Thread allison via cctalk
On 7/30/19 2:58 PM, Brent Hilpert via cctalk wrote:
> On 2019-Jul-29, at 6:34 PM, Jim Brain via cctalk wrote:
>> I have an ill NLS MS-230 Miniscope.  Is there anyone on list that might be 
>> interested in getting it running for me?  I'm willing pay for the privilege. 
>>  I'd like to see the unit working, but I have no experience with analog 
>> scopes, and I'd rather just entrust it to someone who can see it to success. 
>>  I did replace the batteries and let it charge for quite a while.  The red 
>> LED lights up on the front when on, but no sign of a trace, even when fed a 
>> known good 1kHz wave.  The CRT does not appear to be on.
>>
>> Anyone a fan of these units and might be interested in taking a look?
> 
> 
> It's tempting but I'm across the border and some shipping distance away.
> 
> Looking at the schematic (readily available online), it's fairly 
> straightforward.
> If you're willing to spend a little time on it, you could do the basics and 
> check
> for the power supply voltages as listed on the schematic.
> 
> The power supply is essentially 3 stages:
>   1) line -> charging circuit for the batteries,
>   2) batt -> +5 regulator,
>   3) +5 -> simple switching supply for +/-7V, +80V, +100V, -720V, 0.5V 
> heater, 12V for U11.
> 
> With nothing on the CRT (esp with the intensity turned full up), suspicion 
> may fall around the little switching supply.
> 
> A key point to note with 'scopes like this is the cathode/heater runs at high 
> negative voltage relative to GND, rather than the TV/monitor convention of 
> the anode running at high positive voltage. This is done so the amplifiers to 
> drive the electrostatic deflection plates can be be operated near GND level 
> rather than having to raise them way above GND.
> 
> So according to the schematic the heater (acting as cathode; either pin) 
> should measure -720V relative to GND and there should be 0.6V across the two 
> heater pins.
> U11 should have 12V across pins 14 & 7, but like the heater, it to is 
> floating at -720V below GND.
> 

Read the manual as it has troubleshooting information and test points.
If you follow that it will bring you to the fault very quickly
I've not seen the switching converter fail but there are many parts of
the regulators that can.

Hint do yourself a favor and expand and print the schematic as at least
B if not D size.  it will be easier to follow.

Allison



Re: Ill NLS MS-230

2019-07-30 Thread allison via cctalk
On 7/29/19 10:30 PM, Jim Brain via cctalk wrote:
> On 7/29/2019 9:24 PM, allison via cctalk wrote:
>>
>> Since you replaced the batteries did you check the fuse?
> Yep, good.

THe batteries are charged?  (about 6.6V or more full charge)

>> Also the 4066s
> Hmm, all mine are soldered in.  Do you suggest I desolder and check?
>> sometimes get cranky and/or the sockets.
> Only one '00 has a socket.

Check only socketed devices.  Do not desolder unless you have good
reason to believe the part is bad.

Hint check for 5-6V on the power pins of the ICs.

IF you have the manual, check for all the voltages.

>>
>> The tough fail would be the CRT. Check the heater pins with a multimeter
>> to see if its open (unplug it as there is a transformer winding across
>> it).
> I'll check.



>> Mine needed one when I got it but they were available then (1977)
>> from NLS. Side effect of the hammer mechanic owner.  Now it would be a
>> hunt though old tube brokers.
> Yep, I know that'd be the main issue, but I am hopeful it's something
> less problematic.

The only problem with the CRT is finding a replacement.  THey may be
more common than thought.  Haven't checked in decades.

Allison



Re: Ill NLS MS-230

2019-07-29 Thread allison via cctalk
On 7/29/19 9:34 PM, Jim Brain via cctalk wrote:
> I have an ill NLS MS-230 Miniscope.  Is there anyone on list that might
> be interested in getting it running for me?  I'm willing pay for the
> privilege.  I'd like to see the unit working, but I have no experience
> with analog scopes, and I'd rather just entrust it to someone who can
> see it to success.  I did replace the batteries and let it charge for
> quite a while.  The red LED lights up on the front when on, but no sign
> of a trace, even when fed a known good 1kHz wave.  The CRT does not
> appear to be on.
> 
> Anyone a fan of these units and might be interested in taking a look?
> 
> Jim
> 
Jim,

I have a MS15 miniscope that has been my backup since '77.  Good tool
and I got that one in "not working" condition. I've worked on a few
MS-215s over the years.  Right now I'm up to my eyes with stuff to do
but but if no one answers you, maybe in the late fall (after October).

If you don't have the manual its on BAMA and a few other sites.

Since you replaced the batteries did you check the fuse?  Also the 4066s
sometimes get cranky and/or the sockets.

The tough fail would be the CRT. Check the heater pins with a multimeter
to see if its open (unplug it as there is a transformer winding across
it).  Mine needed one when I got it but they were available then (1977)
from NLS. Side effect of the hammer mechanic owner.  Now it would be a
hunt though old tube brokers.

Allison


Re: Scanning question (Is destruction of old tech docs a moral crime?)

2019-07-22 Thread allison via cctalk
On 07/22/2019 10:55 AM, Guy Dunphy via cctalk wrote:
> At 10:41 AM 21/07/2019 -0600, you wrote:
> On Sun, Jul 21, 2019, 4:16 AM Joseph S. Barrera III via cctalk 
>  wrote:
>> I'd suggest that in 2019 when bits are cheap and high-quality scanners
>> nearly as cheap, "crappy quality digital image" is a bit of a straw man.
>> Yes, I've seen plenty of barely-readable or practically unreadable scans,
>> but they were made years or decades ago.
> 
> There are still plenty of bad scans being done today, for various reasons.
> The technology of producing a final digital copy continues to improve and has 
> a way to go yet.
> *This* is why I strongly oppose destroying rare docs to scan them, now. 
> Better to wait
> till non-destructive scanning methods become available.
> 
> 
>> What dpi qualifies as not "crappy"? 300dpi? 400? 600?
> 
> Points:
> 1. Both the DPI and bits/pixel affect the visual result. Having shaded pixels 
> on curved edges
>   makes the eye see a smooth curve, where the same resolution in two-tone 
> (B) would look jagged.
>   Achieving an optimal balance of resolution and shading levels for various 
> types of content and
>   fineness of detail, vs file size, is a bit of an art. 
>   But ultimately it's a simple test: look at the paper original, and your 
> final result on screen
>   (at 1:1 final scale.) Does the quality look the same?
>   Is your copy how the original publisher would have wanted the doc to appear?
>   People only auto-producing PDFs rarely catch on to this, because PDF ONLY 
> encodes as one of:
>   two-tone B (fax mode), or JPG (or JPEG2000 rarely) or the excreable JBIG2 
> (Never use this!)
>   Experiment with PNG encoding, via a tool like Irfanview, which allows 
> flexibly setting PNG
>   bits/pixel, raw, indexed color or gray scale. PNG is a lossless encoding, 
> and so the only
>   resolution loss is by your choice while rescaling in post-processing.
> 
> 2. The resolution you scan at, and the final presentation resolution, won't 
> be the same.
>   Especially when the pages include elements like screened color or B 
> images. To deal with
>   these properly you MUST scan at a resolution several times higher than the 
> screen dot pitch. 
>   Otherwise there will be moire patterns (beats) between the scan sampling 
> and the screening dots.
>   Then you post-process to eliminate the screening, and end up with a truly 
> tonal image at the
>   resolution the eye would perceive when viewing the original screened image.
>   This avoids any moire patterning, realizes the original publisher's visual 
> intent, and enables
>   minimizing the final file data size.
>   B text should be encoded with at least 16 gray levels available to edge 
> shading. ie 4 bits/pixel.
>   B tonal images need at least 256 level gray scale, or the eye sees 
> quantization of shades (aka
>   posterization.)
>   Colour images need either 24 bit/px, ie 8 bits each for RGB, or if there 
> are a limited number
>   of flat colours an indexed color scheme may work. 256 colors or less, ie an 
> 8 bit index per pixel.
>   Typical utilities will generate the color table automatically (which can 
> sometimes ba a pain.)
>   PDF does not allow any of these kind of user choices.
> 
> 3. The final page images, don't have a 'dots per inch' dimension. They have 
> only total number of
>   pixels in H & V. When doing final page image down-scaling and choice of 
> encoding, you have to
>   make an aesthetic decision on final pixel dimensions.
>   If your original page was A4 (8.5" wide) and you scanned at 600 DPI, that's 
> 5100 pixels wide.
>   But you'll likely find that the final copy can be scaled to around 1000 to 
> 1200 pixels wide,
>   with 4 bits/px (if B text), for an on-screen page image indistinguishable 
> from the original.
> 
> 4. All post processing should be done in 24 bit RGB, at the full scan 
> resolution. Keep staged backups.
>NEVER use any indexed color scheme when scaling, rotating, etc. The result 
> is unavoidably bad.
>The final two steps should be: rescale to desided X-Y pixel size, THEN 
> down-code to final
>color system and file encoding.  There's a discussion of this in 
> http://everist.org/temp/On_scanning.htm
> 
> In general, 'acceptable' resolution VERY MUCH depends on the content. 
> 
>> I just scanned my Rainbow 100 User's Manual at 300, 600 and 1200dpi using 
>> the scansnap default settings. You see a jump between 300 and 600, but 
>> little difference going on up to 1200 for this material. I posted the 300dpi 
>> results and even they are acceptable. Some of the diagrams look heavier than 
>> the 600dpi version and at high zoom you see pixelated letters, where the 600 
>> doesn't. The 1200 is hard to see any big difference and takes 4x as long to 
>> scan. I think I'll be scanning the remaining rainbow docs at 600dpi. The 
>> file is 22MB vs 12MB, so that's worth it. The 1200dpi version was almost 
>> 70MB which is starting to get a bit large for a 60 sheet 

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

2019-06-24 Thread allison via cctalk
On 06/24/2019 04:38 PM, Noel Chiappa via cctalk wrote:
> MX11
> Memory Extension Option

If it is not KT-11 then its not memory address extension.

MX-11 and variants are memory boards or systems.

BEst I can do it never appears in my Qbus world so it may be
a board/module level reference to the KT1-11B Memory address
extension (CPU option).

Allison


Re: Wanting to get my first classic computer

2019-06-19 Thread allison via cctalk
On 06/19/2019 10:31 AM, Noel Chiappa via cctalk wrote:
> > From: Ray Jewhurst
> 
> > I would really like to get my own classic computer but I don't know
> > where to begin.
> 
> Two questions you need to sort out in your mind, to decide, are i) do you
> want something with a bit-mapped video screen, or are you happy with ASCII
> serial line only, and ii) what are you prepared to do for mass storage.
> 
> E.g. if you really want video, you're probably looking at something like a
> VAXStation or so; if ASCII will do you, a QBUS PDP-11 might be a good
> start, as with patience eBay can yield a cheap chassis, CPU etc (although
> in the last year or so the really cheap stuff seems to have dried up,
> alas).
> 
>   Noel
> 

Ray,

I'd take that a level deeper.

And old machine is like an old car.  Parts will be needed,
they will come from various places including scrounging, parts
may be unobtainium (long gone) or those available are expensive.
You will have to do most of the work as most will not touch it.

I liken having old systems and keeping them going to be like
having an exotic pet that would do better in a zoo and isn't
warm and cuddly and might even bite!

The likelihood of finding something is high, however it may require
work to get it up and running.  The work maybe electronic repair,
finding and replacing disk drives, or finding software on suitable
media.  There is also potential for replacing board or repairing
them.  If you lucky enough to acquire a working system, the task of
keeping working is also there (spare cards, media to back up the disks
to and so on).

For VAXStation and the like disk drives are getting old and replacement
is not unlikely. Qbus PDP-11 come in a large array of flavors and you
need complete documents for what you may have and is likely not DEC
standard configuration so you need all the supplemental documents
for the alterations.  At the same time finding media to load a copy
of the OS is also something to consider.

Besides OS specific knowledge you will require hardware specific
knowledge lest you run in merry circles for a s simple issue.
This means obtaining the needed manuals and reading them, thanks
to many the information is on line.

In short real hardware comes with real issues to solve and often
the interfaces and media are not at all modern PC like.  I'd add
anything you know about PCs is unlikely to be helpful at best and
can lead one down an unproductive path as PCs and most older non-PC
machines tend to not be similar (other than being a computer).

Allison



Re: M7264 Troubleshooting

2019-06-09 Thread allison via cctalk
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: M7264 Troubleshooting

2019-06-08 Thread allison via cctalk
On 06/08/2019 07:08 PM, Noel Chiappa via cctalk wrote:
> A follow-up to close out something:
> 
> > OK, now a picture of the bus with no console card:
> 
> > http://ana-3.lcs.mit.edu/~jnc/tech/pdp11/jpg/BSYN-BDAL_NoMem.jpg
> [Note: image re-named, to correctly say what it's showing]
> 
> > It's a bit hard to interpret what's going on here .. The long assertion
> > of BSYNC is undoubtly the CPU trying to get the console CSR to respond,
> > and eventually timing out.  Not sure what the short assertion following
> > it is - without looking at the ucode for the ODT, there's no way to know
> > what the CPU's doing.
> 
> > Even harder to understand is what the BDAL line is doing. It looks like
> > it's un-asserted (0, i.e. +3V) on the falling (electrically - rising,
> > logically) edge of BSYN (which would be incorrect - see above). And then
> > it hops around while BSYNC is asserted, which makes no sense at all to
> > me.
> 
> So this makes a little more sense now.
> 
> This is actually showing a NXM cycle to main memory (apparently to address 0),
> hence the '0' on BDAL10. (The second assertion of BSYNC must be somehow
> associated with the NXM.) Apparently it doesn't even try to talk to the
> console card unless the memory is there OK; if it can't see the memory, it
> must just reset and try again.
> 
> Here:
> 
> > http://ana-3.lcs.mit.edu/~jnc/tech/pdp11/jpg/BSYN-BDAL_NoCon.jpg
> 
> is a system with memory, but without a console. A very similar picture, but
> here BDAL10 _is_ '1', as expected.
> 
> 
> So the original picture did in fact indicate what the problem was - had I
> known enough to know how to interpret it! Schaeffer's Law strikes again!
> 
> Although I still don't understand why the LSI-11 wants to see main memory on
> the bus, in order for ODT to run. ODT doesn't use memory at all; ODT on the
> KDF11 CPUs will run without any memory.

ODT for the two systems are very different.  The LSI-11 ODT is microcode
in the base CPU MICOM set and very low level. Also the 11/2 cpu (dual
width is a bit differnt), KDF-11 the ODT is part of the higher level
code.  The larger cards (11/23 and 23+) boot to resident (ep)rom.

Also consider the difference between the restart/run between the two.
If memory serves The KDF11 requires enough ram to have a few of the key
addresses in low memory operational.

There is a lot going on with the LSI-11 as it also initializes internal
and external RAM. At the time memory nearly always dynamic and require
refresh cycles before it is "on line".

The manuals detail it well.


Allison

>   Noel
> 



Re: M7264 Troubleshooting

2019-06-08 Thread allison via cctalk
On 06/08/2019 12:07 PM, Mister PDP via cctalk wrote:
> On Fri, Jun 7, 2019 at 7:35 PM Noel Chiappa  wrote:
> 
>> PS: Might be useful to check that the DLV11-J works; having a stock of
>> known-good
>> boards you can swap in is such a tool for QBUS debugging.
> 
> 
> Tried that one out too, and it works. In fact, unlike my M8017, it will
> actually respond to my inputs on my terminal. I'm pretty sure I may just
> have the card configured incorrectly, but I'm not going to worry about that
> for now. Right now I am working on getting a TU58 emulator set up. You
> wouldn't happen to know where  I could find detailed instructions
> (Address/Vector, Bootstrap, etc..) on how to do this would you?
> 

LSI-11 (or PDP-11) Microcomputer handbook there were many versions
over the years earlier maybe more useful to LSI-11 users.

First you really want the DLV11J as you need the ports.
Configure it with the standard address for DD(TU58) and its vector.
There is a list in the various Qbus LSI/PDP11 manuals.

Note to boot anything from TU58 you will need a boot program
and unless you add a MRV11 (eprom card) that means hand entry
via ODT.  See
http://retrocmp.com/tools/tu58fs/265-tu58fs-pdp-11-boot-loader-operation
for details.

Also you will want not less that 16Kbytes of memory more its very
desirable the upper limits is about 28K words as the upper 4K words
is reserved mostly for boot (ep)roms and device addresses.

Most common easily loaded OS is RT-11 V3 though 5.4.

The most common devices:
RX01 floppy
LP11 Parallel printer, this can also be a port on the DLV11 for
a serial printer.
And of course the console  VT52 or VT100 were the time frame for
LSI-11 but any of the later VT2xx,3xx and later terminals work well.
LSI-11 Boot, terminator card (there are variants depending on the
bootable devices.

ONE LAST REMINDER:  LSI-11 was first of its kind and while Qbus did
become a standard it did not remain completely in the original
format.  There is Q16, Q18, and Q22 and that specified both level
of change and the address bus width.  Not all cards work right in
LSI-11 level bus with LSI-11 cpu and some of the older cards
common to LSI-11 do not in the newer buses with 11/23 or later
cpus.  Some of the backplanes did specific incompatible things
with the CD portion of the connector chain and in some cases
had a EF connector (HEX width).  Use care, read up, and have fun.


Allison



Re: Modems and external dialers.

2019-06-05 Thread allison via cctalk
On 06/05/2019 12:01 PM, Electronics Plus via cctalk wrote:
> 
> 
> -Original Message-
> From: cctalk [mailto:cctalk-boun...@classiccmp.org] On Behalf Of Grant Taylor 
> via cctalk
> Sent: Wednesday, June 05, 2019 10:42 AM
> To: cctalk@classiccmp.org
> Subject: Re: Modems and external dialers.
> 
> On 6/4/19 8:30 PM, allison via cctalk wrote:
>> Keep in mins the hardware for auto dial required some for of micro and 
>> that was a post 1974 thing for the most part.
> 
> Why did it require a micro?  Could the host not perform the function 
> that the micro would do?
> 
>> A few before that had a lot of TTL state machine to do that. 
>> They obviously weren't cheap.

Simple answer was at that time micros were not yet invented.  Actually
they were but not economical when a 8080 board or 6502 board required a
large handful of parts.  Before that? Whats an 8080?


> Why did that state machine need to be implemented in electronics?

It was a way to have rudimentary smarts that was not quite a cpu.

> Why couldn't that state machine be implemented in software on the host 
> using the modem & auto-dialer?
>

IT was the auto dialer!  OR it used manual dialer.


>> The dialer was often not at all as it was the human that dialed the phone.
> 
> ~chuckle~
> 
>> I know of none that did both functions that required a second serial port.
> 
> Okay.
> 
> Reading the links that Ethan provided, it sounds like some auto-dialers 
> did use a second port, but it was not a second (recommended) standard 
> 232 port.  Instead it was an RS-232 and RS-366.
> 
> Aside:  RS-366 sounds odd.  A combination of serial signaling and 
> parallel signaling on the same port.  But not the same as a traditional 
> parallel printer port.
>

Those likely existed but it was for system that did a lot of dialing out.

>> My first modem was a box about 12x8x2.5 inches and it was an all analog 
>> modem good for 110/300 baud and it required connection to the phone line 
>> (pre-modular connector) and you dialed the various (and relatively scarce) 
>> BBSs and when you heard the tone hit the switch that put the modem on 
>> the phone line and you would see the carrier and data lamps do their 
>> thing. That was 1978ish.
> 
> Aside:  I assume that you're talking about before the small 6-position 2 
> or 4 conductor plugs.  Or are you referring to the older than that 
> not-quite-square 4 pin plug?  Or was the modem actually hard wired in 
> with no plug / jack at all?

For a lot of years the older hardware TELCO had ws still in place.
I still have a 500 series deskset and it works well!  So at that time
I connected using whatever ways needed, sometimes I upgraded to makes it
easier next time.

Modular is the RJ stuff newer and still in use, the older was the
larger clunky 4 pin plug.  My house still has a few.


>> A modem that could dial was maybe 1983-5 or so at affordable prices 
>> (under 300$) for 300 baud.
> 
> *nod*
> 
> I have this mental picture, which I think is based on something I've 
> seen at some point in the past, that was a device that attached / 
> actuated / ??? a traditional rotary dial phone.  As in it had a finger 
> that interfaced with the dial and something that could rotate it to dial 
> the digit in question, rewind (term?), and dial the next digit in question.
> 

Wild idea but never saw that one.  I have the advantage of spanning
computing from late 60s to now.  The intersting case was 1970, PDP10
with PDP8I the 8I did all the communications between the 10 (blkio)
and the modem bank which was dial in only.  Over 300 users on the BOCES
LIRICS computer network and 98% of them were ASR33 with 110baud
acoustic coupled modem.  the last 2% were ASR35 and Hazeltine 1000 and
2000 terminals in the center (local 1200baud!).

So I remember pre-carterphone to 56K modems, then DSL and now fiber.
My memory of carterphone was a interconnect for radios (Amateur radio)
and how we then just did it being very careful with transformer
isolation.  By 1970 I was working in the land mobile industry with
remote base radios connected with RTL (Radio Tie Lines) which were just
a pair of rented wires (owned by TPC aka telco) between the business to
the hill where the radios were.  They had to pass DC and every so often
some bright eyes would add load coils and effectively short out the
line.  That would cause a day of troubleshooting as it was never the
TPCs fault.  At least according to them.

Allison


Re: Modems and external dialers.

2019-06-04 Thread allison via cctalk
On 06/04/2019 09:45 PM, Grant Taylor via cctalk wrote:
> Does anyone have any experience working with modems that didn't include
> internal / auto dialers?
>

Yes,
Novation cat, Hays, and a few others.  Dial the phone and put it in the
cradle or flip a switch.  Most of the 110/300boaud bel 101 and bell103
modems were "manual".

Keep in mins the hardware for auto dial required some for of micro and
that was a post 1974 thing for the most part.  A few before that had a
lot of TTL state machine to do that.  They obviously weren't cheap.

> They came up in a conversation in a newsgroup and I realized that I know
> of them, but know virtually nothing about them.
> 
> I think they were separate devices, which probably means that they
> likely had separate serial ports to talk to each of them.  Did they
> support some sort of pass through?  Or did they really require two
> serial ports on the host?

The dialer was often not at all as it was the human that dialed the phone.

I know of none that did both functions that required a second serial port.

For example the DEC ealy modems required the user to dial the phone and
pushing a button would connect it.  THe DEC modem had a protocal was
different from the later ATDT (Hays modems).

My first dial up was 1969, Bell 103 external to the TTY.  Later versions
had rotary dial or touch tone and the modem in the TTY stand.

My first modem was a box about 12x8x2.5 inches and it was an all analog
modem good for 110/300 baud and it required connection to the phone line
(pre-modular connector) and you dialed the various (and relatively
scarce) BBSs and when you heard the tone hit the switch that put the
modem on the phone line and you would see the carrier and data lamps
do their thing. That was 1978ish.

A modem that could dial was maybe 1983-5 or so at affordable prices
(under 300$) for 300 baud.

Allison



Re: 11/93 Rebuild - SCSI HD now boots RT11

2019-05-31 Thread allison via cctalk
On 05/31/2019 03:27 PM, Rod Smallwood via cctalk wrote:
> 
> On 31/05/2019 19:40, allison via cctalk wrote:
>> On 05/31/2019 02:04 PM, Rod Smallwood via cctalk wrote:
>>> Hi
>>>
>>>  Well I now have a bootable SCSI drive on my 11/93. Its not RSTS/E
>>> (yet) but it is RT 11 and reliable.
>>>
>>> Its a bit baseline but it runs.
>>>
>>> So next up was to see if we could get the RQDX3 to co-exist with the
>>> SCSI controller.
>>>
>>> I switched the base address to 160336 and it does not stop the SCSI
>>> drive booting as DU0.
>>>
>>> Had the RQDX3 been on the normal base address I think you would get the
>>> HD as DU0 and the two halves of an RX50 as the next two drives.
>>>
>>> But what happens to the RX50's when you move the RQDX3 to 160336 ?
>>>
>>> Rod
>>>
>>>
>>>
>> Under RT-11 you have to do a SET CSR and sometimes Vector when you move
>> a device off the default.  Its how I could have two DD (tu58) on teo
>> serial ports.  Same for RX02, RL02, with RQDX3 (with RD52 and RX33)
>> where the RQDX was set to a nonstandard address.
>>
>> As I remember the CMD controller is nominally the same as RQDX3 for the
>> same address. so likely RQDX at the secondary address (see the manual)
>> will be treated well if not use the set utility.  It  only comes to mind
>> as I had two RQDX3s in one machine to make RD52 to RD52 copies at one
>> point.  Also my BA123 uVAX-II has both CMD SCSI controller (Rz56 x2) and
>> RQDX3 for RD52 wher the RD52 was the swap and page disk (QD540s are fast
>> but only 31mb) and by having independent channels helped with system
>> performance.
>>
>> RSTS/E the conventions for non standard device addresses are different
>> but there is a mechanism for addressing that.  I've not used that.
>>
>> Any of the PDP11 unix again there is a way but the process varies with
>> version and is unknown to me.  I tried once to get V^ to talk to more
>> than RL02.
>>
>> In the end first make sure you using the suggested secondary controller
>> address.  Then use the OS dependent tools for installing additional
>> drives.
>>
>> Allison
> 
> Hi
>    OK lets see if I can understand whats going on.
> 
> 1. The CQD sits at the normal 17772150 base address
> 2. RQDX3 is at the alternate 17760334 base address.

OK good address and non interfering.

> 3. The map function in the 11/93 monitor sees both
> 4. The SCSI drive boots RT11 with the RQDX3 in place.
OK that means the RQDX is not causing issues but likely the
OS does not see it as the DU/DUX driver is not configured to
see that address and the 11/93 map function does not communicate
with the OS.  So unless the OS is told that RQDX3 is additional
334Q address its not even going to bother with it or by it.

> 5. So if I connect an RX50 through the cable splitter as normal then
> what device(s) is(are) the RX50

No idea, until you set the du1 (the other is du0 I memory hasn't
croaked) its a non sequitur.

So at the prompt >set du1 CSR=17760334<  or something along those
lines (syntax) will connect the controller to the OS.  At this
point since I've not done it in a decade you may need to init
the device and media, copy stuff to it then set the boot device.

> Rod

Beats me!  Never got a 11/93.  Latest Qbus-11 I have is a J11 -11/73
the smaller dual width card (no PMI).  Never seen the map function.

However having said that, the CPU may know what disks are there but
once the boot operating gets to the disk resident boot then the OS
has to be up to it meaning all the initial setups in place or if the
device was bootable a script (or manual entry) that loads and set up
everything.  That much is certain for RT-11.  For example I run RT11XM
from VM: [memory disk], however first you have to init VM: and put stuff
there and set it up so you can boot it.  So happens I do that from DD
(tu58 tape) but I've done it from RX02, RL02, and DU.

For RSTS and others the game is different but you first muct boot from a
device already know to the copy of the OS on a device that the system
knows how to boot from.

One thing that is consistent is that the boot for any device is often
the same in that it calls for the device to access the bootable track
and sector or base LBA, the MSCP devices [cmd or RQDXn] have their own
thing where the controller knows the place for a given media it can use.
In that case the system boot in rom is a message to "give me the boot
block at xx ram address" and transfers to that.

Allison


Re: 11/93 Rebuild - SCSI HD now boots RT11

2019-05-31 Thread allison via cctalk
On 05/31/2019 02:04 PM, Rod Smallwood via cctalk wrote:
> Hi
> 
>     Well I now have a bootable SCSI drive on my 11/93. Its not RSTS/E
> (yet) but it is RT 11 and reliable.
> 
> Its a bit baseline but it runs.
> 
> So next up was to see if we could get the RQDX3 to co-exist with the
> SCSI controller.
> 
> I switched the base address to 160336 and it does not stop the SCSI
> drive booting as DU0.
> 
> Had the RQDX3 been on the normal base address I think you would get the
> HD as DU0 and the two halves of an RX50 as the next two drives.
> 
> But what happens to the RX50's when you move the RQDX3 to 160336 ?
> 
> Rod
> 
> 
> 
Under RT-11 you have to do a SET CSR and sometimes Vector when you move
a device off the default.  Its how I could have two DD (tu58) on teo
serial ports.  Same for RX02, RL02, with RQDX3 (with RD52 and RX33)
where the RQDX was set to a nonstandard address.

As I remember the CMD controller is nominally the same as RQDX3 for the
same address. so likely RQDX at the secondary address (see the manual)
will be treated well if not use the set utility.  It  only comes to mind
as I had two RQDX3s in one machine to make RD52 to RD52 copies at one
point.  Also my BA123 uVAX-II has both CMD SCSI controller (Rz56 x2) and
RQDX3 for RD52 wher the RD52 was the swap and page disk (QD540s are fast
but only 31mb) and by having independent channels helped with system
performance.

RSTS/E the conventions for non standard device addresses are different
but there is a mechanism for addressing that.  I've not used that.

Any of the PDP11 unix again there is a way but the process varies with
version and is unknown to me.  I tried once to get V^ to talk to more
than RL02.

In the end first make sure you using the suggested secondary controller
address.  Then use the OS dependent tools for installing additional drives.

Allison


Re: M7264 Troubleshooting

2019-05-29 Thread allison via cctalk
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: Possible PUTR bug?

2019-05-11 Thread allison via cctalk
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: How were 32-bit minis built in the 70s/80?

2019-05-11 Thread allison via cctalk
On 05/11/2019 09:30 PM, ben via cctalk wrote:
> On 5/11/2019 6:28 PM, allison via cctalk wrote:
> 
>> Not all were 74181 based, Thats an early 1972 part and but 1975 it was
>> already getting old though useful as it evolved to 74S and 74F series.
>> The 82s100 and 105 series were out there and even by 1980 the AMD 2900C
>> series was getting long in the tooth. Mask programable gate arrays were
>> in the 1000 and up gate level by 1980 and growing by doubles every 6
>> months to a year. Don't got get programmables like PAL/GAL logic.
>> There was a lot of designs and even inside DEC you might see several
>> approaches depending on what machine and the specific date.  For example
>> the 780, 750 and 730 used very different technology.  I will not go into
>> those that also went the ECL {10K, 100K, 1M families] route.
> 
> 74181 is FAST, but I disagree with the way most computer architecture is

TTl in general is slow a ALU based on 181 is hitting the wall at 5mhz
with 12 or 32 but carry lookahead.


> designed. You have a fast micro code cycle, that is out of sync with
> main memory, that tries to emulate a Harvard? Memory model.
> It looks fast only on paper or demo programs sadly.
> The few schematics I have seen (PDP 8/11) have 74H logic hidden
> inside so you can't say they are pure TTL logic.

Yes, they are mostly TTL and the typical 8efm use MSI ttl such as
7481, a bunch of them.

I'm likely one of the few that took a 8E and ran semiconductor ram then
pushed the clock up to the breaking point and you get to about 4x and
you start getting timing errors and critical path delays that mess with
the logic.  However at 4X you doing a lot and decently fast but you
needs a faster generation of logic.

> 
>  A cpu instruction has 4 parts in general
>  a) getting the instruction and literal data from memory
>  b) calculating the the effective address
>  c) fetching the data from memory  c) ouputing data
>  d) using the data d) saving to memory.
> 
Many of those things can be done in parallel.

Whoever RMW cycles on memory even with very fast memory will slow the
system as you have cycles that cannot be interrupted mostly in the
slow memory.

> It is very hard to speed up this cycle because this has
> sync to extenal memory. Memory is the bottleneck
> is the true speed limit in any sytem. Add in virtual
> memory and in multitasking and graphics
> no wonder the PDP 8 at with TTL gives better response
> time.

Memory is often the bottleneck then IO especially block IO.

The response time of PDP8 was mostly due to a simple OS and nothing to
get in the way.

The name for that is system overhead and PDP-8 had little and what it
did have was written in assembler for speed and compact code as it was
also space constrained.

Allison, have the shirt.

> Ben.
> PS: this message was delayed for about a minute as
> background program froze the sytem.
> 



Re: How were 32-bit minis built in the 70s/80?

2019-05-11 Thread allison via cctalk
On 05/11/2019 07:14 PM, Warren Toomey via cctalk wrote:
> I'm building my own 8-bit CPU from TTL chips, and this caused me to think:
> how were 32-bit minis built in the late 70s and early 80s? In particular,
> how was the ALU built? I know about the 74181 4-bit ALU, and I know (from
> reading A Soul of a New Machine) that PALs were also used.
> 
> Did companies get custom chips fabricated, or was it all off-the-shelf chips
> with a few PALs sprinkled in?
> 
> Thanks, Warren
> 

Lets see the VAX 11/780 hit the street in 78 and DG followed with theirs
soon after and of course the IBM 360 was 32bit so the number can be
fairly large.  Soul of a new machine was more romantic but it was of
early VAX era and the Eclipse was the result.

Reading the following woould be better as it compared and contrasts DEC
hardware and instill an idea of ISA design and then its hardware
implementation.  Its a good read and free!

http://www.bitsavers.org/pdf/dec/_Books/BellComputerEngineering.pdf

Building now is more based on what you have or can get not what was used
then as most were pushing for speed vs price and the available parts
were never fast enough and cost too much.

Not all were 74181 based, Thats an early 1972 part and but 1975 it was
already getting old though useful as it evolved to 74S and 74F series.
The 82s100 and 105 series were out there and even by 1980 the AMD 2900C
series was getting long in the tooth. Mask programable gate arrays were
in the 1000 and up gate level by 1980 and growing by doubles every 6
months to a year. Don't got get programmables like PAL/GAL logic.
There was a lot of designs and even inside DEC you might see several
approaches depending on what machine and the specific date.  For example
the 780, 750 and 730 used very different technology.  I will not go into
those that also went the ECL {10K, 100K, 1M families] route.

Your question has to be based on a specific date window and narrow at
that as keep in mind by 1978 16bit CPUs on silicon were a fact
(Ti9900, SBP9900, F11, T11, Nova, 8086).





Re: RT-11 doesn't recognize my 3.5" floppy

2019-05-07 Thread allison via cctalk
On 05/07/2019 11:15 AM, Douglas Taylor via cctalk wrote:
> Very interesting , now that you got it to work, what can you use it for?
> Will it be an exchange media with PUTR?
>
> Doug
>
> On 5/6/2019 6:20 PM, Charles via cctalk wrote:
>> I have installed an RQDX3 and the M9058 distribution board in my
>> 11/23+. Since I don't have a 5.25" drive yet, I hooked up a 3.5" HD
>> (1.44 MB) drive from an old PC.
>> After a struggle (which I documented on VCFED's DEC forum), I managed
>> to get all the jumpers and cables set correctly, and now my XXDP
>> diagnostics (ZRQA?? ... ZRQF??) recognize the drive as an RX33 (DU0:,
>> logical drive 0 since no hard disks are attached). It passes all the
>> tests, and I can INIT, DIR, and copy files to it using the limited OS
>> with the XXDP suite. The LED on the RQDX3 blinks once when the drive
>> is accessed. So far so good.
>>
Did you actually test the drive by formatting, reading and writing?

>> But, when I boot the system (with RT-11SJ V5.01), it can't see the
>> drive at all. Attempts to access it result in the command hanging
>> indefinitely, the drive does not select, and the RQDX3 lamp flashes
>> rapidly. SHOW DEV:DU does say that the handler is installed for the
>> correct 172150, 154 location. However, SHOW DEV:DUn where n=[0..3]
>> displays two blank lines then back to the dot prompt.
>>
>> Is my version of RT-11 just too old to recognize an RX-33? If so,
>> what do I need to fix this? Presumably a later DU.SYS?
>> Thanks for any help. Most of my experience is with PDP-8's so this is
>> slow going...
>> -Charles
>>
>

RT11V5 works for me using RQDX3 and the distribution board in the BA23
box assembled as a MicroPDP-11 with RX33
and RD52 (Quantum 31mb).  Never thought much about it other than to make
sure the RX33 was jumpers were correct
and making a dummy panel for the smaller than RX50 drive.

The 11/73 system has the RQDX3 and the signal distribution board (m8058)
out of BA123 to hook up
RD52, RX33, RX23 and never had issues due to addressing devices under RT11.

Is it possible you have a interrupt grant gap between the various boards
and the RQDX?  That would cause a hang.

If you successful it makes using PUTR easier though RX50 works for that
too just smaller.

Allison


Re: Excessive amount of time in interrupt stack mode

2019-04-30 Thread allison via cctalk
On 04/30/2019 02:02 PM, John Klos via cctalk wrote:
>> The system is mostly idle, RAM is mostly free (there's 32mb),
>> there is almost no paging, but the CPU is spending upwards of 70% of the
>> time in the interrupt stack mode.
>
> If I had to guess, I'd say the most likely culprit is ethernet. Try
> disconnecting ethernet, perhaps the AUI, too, and see if it's any
> different.
>
> John
Last time I'd seen that another system on the network was jabbering... 
it had a bad DEQNA.

Allison


Re: Greetings

2019-04-29 Thread allison via cctalk
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: Greetings

2019-04-29 Thread allison via cctalk
On 04/29/2019 09:41 AM, Paul Koning wrote:
>
>> On Apr 29, 2019, at 7: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).
> Does it support MSCP?  If not, RP06 would certainly serve for your disks.
>
>   paul
>
I believe its pre MSCP.  V1.5 is pre 1981 if memory serves.  MSCP I
think was introduced
Qbus systems in the 80s just prior to the MicroVAX.

VAX-11/78-- was introduced in '78 and the next generation was around
1980 with the
730 and 750 for the small systems and the 782 and 785 for the larger ones.


Re: Greetings

2019-04-29 Thread allison via cctalk
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: What do to with an Internet-connected PDP-11?

2019-04-29 Thread allison via cctalk
On 04/29/2019 03:20 AM, ben via cctalk wrote:
> On 4/28/2019 11:34 PM, Cameron Kaiser via cctalk wrote:
>>> Maybe it would be possible to get a text only browser running?
>>
>> I think Gopher would be a better fit, personally. That's easy to write,
>> parse and display.
>>
> That might be true, but what sites still provide that service.
> A web novel app might work. 5K of REAL text, 5Meg of ads,pop ups and
> java script. :(
> Ben.
>
>
>
With a PDP-11/23 and full boat ram (18bit) you can run more than RT-11
and something like V6 unix or maybe
RSX might be a better choice for anything networking.  An OS that
supports swapping and maybe virtual memory
would help even at the expense of speed.  Networking does require some
level of multitasking as well so RT-11/FB
is likely more useful than vanilla RT.

Allison


Re: Televideo 925 character rom dump

2019-04-24 Thread allison via cctalk
On 04/24/2019 08:47 PM, Al Kossow via cctalk wrote:
>
> On 4/24/19 5:46 PM, allison via cctalk wrote:
>
>> The 8049 is readable just like the 8048 save for 2k device.  I worked
>> for NEC back then and had access to intel parts too.
> is that true for "HC" parts or just NMOS?
>
>
All!  The HC were different lower power process thats all.  if it were
8051 thats different.

My samples include NMOS, NMOSII, and HCMOS.  and the NEC parts through CMOS


Allison


Re: Televideo 925 character rom dump

2019-04-24 Thread allison via cctalk
On 04/24/2019 07:55 PM, Guy Dunphy via cctalk wrote:
> At 08:14 AM 24/04/2019 -0700, you wrote:
>>
>> On 4/24/19 5:39 AM, Guy Dunphy wrote:
>>
>>> The keyboard controller is an 8049. Firmware not readable.
>> 8049s aren't protected. they are 2k versions of the 8048
>> and can be read as 8749s
> I did try reading it as an 8749. By 'not readable' I meant it read as all FF.
> Using a Topmax device programmer; a fairly good brand.
> Interestingly when I selected Intel 8749 it actually hung on reading. 
> Repeatably. Never seen that happen before.
> Selecting NEC 8749, it read, but got all FFs. 
> Considering there's something odd going on, I was quite relieved to verify 
> the chip still works afterwards.
> I hadn't gone as far as getting out the databooks and checking whether 8049 
> should be readable.
> I thought they are, but the absense of '8049' type in the chip programmer 
> seemed to suggest otherwise. Unless they
> were 'induced' to leave it out to hinder copying?
> Shall look into it further.
>
> Guy
>
The 8049 is readable just like the 8048 save for 2k device.  I worked
for NEC back then and had access to intel parts too.
If you can't read it its your programmers fault, FYI the set up is
nearly the same as 8749 but the voltage for the read
function is lower.  Here is except of page 2-19 of the intel MCS48
family manual july 78...

"The processor is placed in the READ mode by applying a high voltage
(+25V for the
8748, +12V for the 8048/8049) to the EA pin and +5V to the TO (8748
only) input pin.
RESET must be at OV when voltage is applied to EA. The address of the
location
to be read is then applied to the same lines (TTL levels) of BUS and
Port 2 which output
the address during single step (see below), The address is latched by a
"0" to "1"
transition on RESET and a high level on RESET causes the contents of the
program
memory location addressed to appear on the eight lines of BUS."

It is possible that the devices is being used with external rom/eprom
the test for that is pin7 EA, if EA is high then program access
is external.  it was very common to use any 8048/49 in place of 8035/39
in a system and often cheaper due to misprogrammed
parts that can still be used with external rom.

FYI there are no "protection bits".

Allison



Re: PDP-11/83 w/FPU?

2019-04-18 Thread allison via cctalk
On 04/18/2019 04:19 PM, Noel Chiappa via cctalk wrote:
> > From: Allison
>
> > Experience is that an 11/23 or 23+ will run V6 as mine does.
>
> What changes did you make to get it to run? (I assume the stock binary
> wouldn't run.)
>
>   Noel

The hardest part was was getting it on a RL02 from the PUPs library.
The binary was stock for that device, its only been maybe 15 or more years.

V6 was low enough in requirements that a valid mass storage was the big
thing.
Choices were RK05, RL01/02, and maybe RX01(way too small).

Allison


Re: PDP-11/83 w/FPU?

2019-04-18 Thread allison via cctalk
On 04/18/2019 10:56 AM, Noel Chiappa via cctalk wrote:
> > From: W2HX
>
> > i have a few CPUs available to me, a 11/23+, an 11/73 and I also have
> > available to me an 11/83
> > I would like to try to run as many different OS's as may interest me,
> > including some unixes as possible (bsd...etc).
>
> Early Unixes in general will run on those machines - but not straight off the
> tape (since they didn't exist then, and have quirks which aren't supported).
>
> I've brought up V6 on a /23 (which must have the KTF11-A MMU chip); here:
>
>   http://gunkies.org/wiki/Running_UNIX_V6_on_an_-11/23
>
> are instructions on exactly what (minor) changes need to be made for it to
> run.
>
> The /73 and /83 should be subsets of that, although you'll want to start with
> m45.s, because those machines support the split-I-D MMU of the -11/45. (A /23
> Unix binary would boot/run on them, if you don't feel like doing a special one
> for them.) I haven't yet tried V6 on them; if you want me to, and do a
> writeup, let me know. The /73 and /83 have LTC registers, so on those you
> won't need the LTC hack.
>
> Also, you may know this already, but if not, note that the /83 is a PMI:
>
>   http://gunkies.org/wiki/Private_Memory_Interconnect
>
> machine, and _MUST_ be plugged into a Q/CD backplane _only_; plugging into
> a standard Q/Q backplane will _damage_ it.
>
>
> > would I see any improvement in performance with the FPU compared to
> > without it? Or does the application running need to be something like
> > fortran to see any perceivable difference?
>
> As someone noted, the /73 and /83 implement thefloating point instructions in
> microcode, so the code can't tell if the optional FPJ11 FP hardware
> accelerator is plugged in or not. In general, only on applications (the
> language is not relevant) which are heavy users of FP would you see any
> difference.
>
> On the /23, with no KEF11-A FPU chip plugged in, there are no floating point
> instructions at all, so any application which tries to use them will blow out
> (although under V6 there's an emulator); see here:
>
>   http://gunkies.org/wiki/Setting_up_UNIX_-_Sixth_Edition
>
> and search for 'floating point' to see discussion of it).
>
>
> > From: Ethan Dicks
>
> > v5, v6, and v7 UNIX shouldn't require any sort of math hardware.
>
> Don't know v5/v7 in detail, but AFAIK that's accurate. V6 can _support_
> FP hardware on machines which have it, and is otherwised prepared to
> emulate those instructions (see above).
>
> > From: Paul Koning
>
> > I think that was typically called "EAE" (extended arithmetic element),
> > a Unibus peripheral that implemented integer mul/div ... It only
> > applies to 11/20 and 11/05 since all the other machines have the
> > relevant instructions built into the CPU.
>
> Also the -11/04 and -11/03 were both missing the EIS; the former could use
> the EAE, for the latter the optional KEV11-A or KEV11-B microcode chips both
> provide it.
>
> > From: Josh Dersch
>
> > The EAE was also an option on the 11/40.
>
> Technically, on any UNIBUS machine; on the /40, the EIS (added instructions,
> not the device model of the EAE) was available via an optional board in
> the CPU.
>
>   Noel
All,


Experience is that an 11/23 or 23+ will run V6 as mine does.  REason it
does is V6 does not require I support

The usual issue is not FPU for Unix as questioned but if there is a need
for I spaces.  The 11/23 (f11 chipset)
does not support that but the J11 (11/73 and 11/83) do support that.  I
have a 11/73 so I could run BSD and a few
others commonly found that require I support.

There may be other versions that place less of a burden on requiring I
However I've not encountered a need for FPU connected to OS.  Also
the assumption for many unix is MMU support but not all DEC OS have
that requirement.

Allison



Re: Adding floppy drives to my PDP-11?

2019-04-13 Thread allison via cctalk
On 04/13/2019 06:07 PM, Charles via cctalk wrote:
> I have a PDP-11/23+ with two RL02's in a corporate cabinet but no
> floppy drives. Also an RXV21 (M8029) card.
>
> My PDP-8/A has RX01 drives, and I was hoping just to run the cable
> over to the -11 when I wanted to use floppies on it.
> But after some searching, it appears that the RXV21 will only work
> with an RX02 drive...
>
> Just wondering what my options are for hooking up any kind of floppy
> drives.
> I could sell the RXV21 and buy/trade for an RXV11 (M7946) instead, to
> use with the RX01 in the other rack.
> Or look for an RX02 that won't break the bank - but that won't fit in
> the corporate cabinet. I do have another cabinet but it's got other
> rack-mount gear in it at the moment.
> What about smaller drives (RX50? RX33?)... can those be interfaced to
> the 11/23+ Qbus?
> Other thoughts?
> thanks
> Charles
>
>
RX50, RX33, RX23 aall work with the RQDX2,3 controllers The boards and
cables are fairly easy to find as they were
used in microPDP11 and Qbus Microvax.  Depending on the CPU they will be
bootable (11/23+ I believe works).
IF you lucky and can fine a quantum D540 or St225 you can have a hard
disk as well.  I have 11/23+ and 11/73
configured using that (rqdx2 in one and Rqdx3 in the other) and the
breakout board.

Many people skip over the MSCP controller for MFM hard disks as the hard
drives are scarce, but floppies
a Teac FG55GFR is the hot item as would be a RX50 or 1.44 3.5" floppy or
all three as it can interface not
less than two floppy drives.


Allison


Re: The story of... PDP-1

2019-04-02 Thread allison via cctalk
On 04/01/2019 08:34 PM, Paul Koning via cctalk wrote:
> Nice.  The bit about the PDP-1 at the skydiving world championship (in 
> Orange, MA) is still a well known item in the history of skydiving.
>
>   paul
Orange MA airport is still an active skydiving site.

I used to fly there regularly for cheap fuel for the 150 and the mid
summer hit and miss engine show.

For me all of this and the mixx is anything but history as it was where
I worked for 10 years
and around the area long after.

Allison

>> On Apr 1, 2019, at 5:23 PM, Liam Proven via cctalk  
>> wrote:
>>
>> DEC archival docs tell the story of the genesis of the PDP-1:
>>
>> https://gordonbell.azurewebsites.net/digital/timeline/pdp-1story.htm
>>
>> -- 
>> Liam Proven - Profile: https://about.me/liamproven
>> Email: lpro...@cix.co.uk - Google Mail/Hangouts/Plus: lpro...@gmail.com
>> Twitter/Facebook/Flickr: lproven - Skype/LinkedIn: liamproven
>> UK: +44 7939-087884 - ČR (+ WhatsApp/Telegram/Signal): +420 702 829 053



Re: Refillable spray can

2019-03-24 Thread allison via cctalk
On 03/24/2019 02:39 PM, Chuck Guzis via cctalk wrote:
> On 3/24/19 11:32 AM, Chuck Guzis via cctalk wrote:
>
>> So this?
>>
>> https://www.amazon.com/EWK-Aluminum-Pneumatic-Refillable-Compressed/dp/B00JKED4MS
>>
>> Just be sure to use a dryer on your compressor output.  Compressed air
>> can hold a lot of moisture.
> I'll also add that at 90 PSI, this won't hold much air for long--in the
> reviews, that's the major complaint.   Better is a small "pony tank"
> that can be charged and transported.
>
> --Chuck
>
 To spray paint well a drier and regulator as best pressures are down
around 20 to maybe 40psi.
With lower pressure the need for additional tank and all not required. 

I do a lot of work with an airbrush as its small volume and you can do
fine detail work very well.
Airbrushes also need lower volume of air so lower pressures require the
regulator.

Allison


Re: Thinking about PDP11 PC05 Emulation

2019-03-11 Thread allison via cctalk
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: Pioneers of computing

2019-03-11 Thread allison via cctalk
On 03/11/2019 04:49 AM, Brent Hilpert via cctalk wrote:
> On 2019-Mar-10, at 3:59 PM, Will Cooke via cctalk wrote:
>>> On 3/10/2019 3:18 PM, Murray McCullough via cctalk wrote:
 Back in 1965 Jack Kilby, Jerry Merryman and James Van Tassel at texas
 Instruments created an integrated circuit designed to replace the
 calulator. Historians, though not all, credit this development as the
 beginning of the electronic-computing revolution that was truly underway by
 the mid-70s. Vintage/classic computing our hobby goes back that far as us
 baby-boomers can attest to.
> . . .
>> Here is a little bit of info on it:
>> http://www.vintagecalculators.com/html/ti_cal-tech1.html
>
> On 2019-Mar-10, at 10:48 PM, ben via cctalk wrote:
>> On 3/10/2019 7:30 PM, Guy Dunphy via cctalk wrote:
>>
 Here is a little bit of info on it:
 http://www.vintagecalculators.com/html/ti_cal-tech1.html
>>> That's fascinating, thanks. I'd never heard of it.
>>> The Intel 4004 came out in 1971.   https://en.wikipedia.org/wiki/Intel_4004
>>> I'd understood that was the first chip that could be considered a 
>>> 'processor' (though it required some support chips to do anything.)
>>> The TI Cal-Tech design was begun in 1965 and they had a working calculator 
>>> in 1967. I wonder if the chips in that had any kind of code programmability?
>> Looking at the vintage calculator page, I would give the "FAR EAST" my vote 
>> for the first processor type chips. Everything was in-house development you 
>> can say they all came out at the same time. Look at TTL
>> pre 1970 4 gate logic, after 1970 74181 alu 7416x 4 bit counters 7489 16x4 
>> RAM. About 1973 Tristate logic and 32x8 , 256x4 PROMS.
>
> If you read the link provided by Will, the Cal-tech was four ICs, not one.
> It was a forward-thinking lab R project which you would expect to be ahead 
> of the IC technology on the market.
>
> It would be several more years, ca. 1971 before the complete logic for a 
> calculator was stuffed onto one chip and available on the market,
> so coincident in time with the 4004.
> There was the TMS-0100 series from TI , single-chip calculators, 1971.
>   https://en.wikichip.org/wiki/ti/tms0100
>
> TI and others did produce some calculator chip-sets (calc on several 
> dedicated LSI chips) for the market prior to the single-chip implementations.
>
> No, the first 'processor-type' chips didn't come out of the 'far east'.
> The Japanese were producing calculators with hard-wired / random logic / 
> dedicated state-machine architectures in the late 60s.
> With the advent of LSI, they came to the Americans to get chips designed, 
> resulting in one case in the 4004.
>
> See also the TMS1795 (1971) and TMS1000 (1974).
> Rockwell was another of the big players.
>
First I prefix thing with how many of you were over the age of 8 or 10
at the time of the introduction of the calculator?

OK, I was well over that by then.  I started in Jr high with a slipstick
(slide rule) as an early techno geek
so I got to see the industry develop and yes the desk sized computers
were easily early on but the
key thing is pocket calculator just like the Pocket transistor radio. 
Each were of similar level of
change. radios weren't a new idea but mass produced and cheap  pocket
sized was.  So the pocket
calculator was big and when the cost got under 50$ then everyone wanted
it.  I was an early adopter
of the Ti 8 digit 4 banger (-+/*) (TMS103) and took that to college in
the very early 70s.  After that I'd
seen and gotten to use the famous HP65 (then about 650$).  It was a very
different market and use
for the pocket calc than the desktop calc.  The biggest part of the
desktop was printing, the
transactional record of what was done.

The key is we (users and market) went from slide rules in about 69-70 to
calculators in 71-72 and
they were everywhere by 74 and prices dropping very fast.

As to microcomputers and calculators I see them on the parallel path as
they both required the same
technologies to be present to be able to make wither but one was market
driven and the other was
technology driven.  The calculator is however become a dead end in that
it never advanced beyond
a point then it was a computer.  Its utility however is every cell phone
has one.

The CADC Central air data computer was the fly by wire for the F14 and
was a multi-chip system
and programmable, making it the first LSI micro.  The question of single
chip is moot as it was the
later 70s with TMS1000, F8, and 8048 that would put all of the computer
functions on one chip.
The 8080/6502/6800/and friends were all multichip to realize even a
simple functioning system.

Oddly science fiction had computers but calculators were not part of
their forecast..  I know of
only one example that had pocket/portable calculator.

Allison



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

2019-01-31 Thread allison via cctalk


> On Wed, Jan 30, 2019 at 9:49 PM Bill Degnan via cctech <
> cct...@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: PDP-11 ID page, a few images needed

2019-01-24 Thread allison via cctalk
On 01/24/2019 10:38 AM, Ethan Dicks wrote:
> On Wed, Jan 23, 2019 at 8:41 PM Allison Parent via cctalk
>  wrote:
>> On Jan 23, 2019, at 8:43 PM, Paul Koning via cctalk  
>> wrote:
>>> On Jan 23, 2019, at 5:37 PM, Noel Chiappa via cctalk 
>>>  wrote:
>>>
>>> http://ana-3.lcs.mit.edu/~jnc/tech/pdp11/PDP-11_Models.html
>>>
>> A variant of the LSI-11 is the H-11 sold by Heathkit.  Is that actually the 
>> same board?  Either way it would be worth mentioning
> I have an H11 and it has a real DEC CPU board.  The backplane is
> Heath, with industry-standard (not DEC's zig-zag) backplane edge
> connectors, and Heath parallel and serial cards, but the CPU card is
> 100% DEC.
>
>> The heath h11 and the lsi11 are
>> The same right down to the handle.   The prime difference
>> Is the heath backplane is smaller number of slots and user assembled along 
>> with the case and power supply.  The memory, io, and disk system
>> was all heath and could be used in dec backplanes and DEC cards in heath.  
>> The heath disk was RX01 comparable and could format media.
> Right.  The H-27 disk system definitely worked with RX01 media and
> could format blank media.  I have an H-27 that came with my H-11 but
> the former owner (my boss at the time) never used the H-27 and I never
> got it working to boot from it.  My boss did a massive case mod to
> extend the width of the box several inches and made a simple 2-slot
> CD-interconnect (two Heath backplane connectors and some wire) so he
> could fit in an RLV11.  That's how I used it at work, and when the
> company closed and he gave me the old box, I undid the mod (it was
> functional but not strong and definitely not pretty) and so now I
> can't use the RLV11 in there any more (yes I have an RLV12 now).  The
> point here being, we didn't use the H-27 and I never got it working to
> boot from it.  All I ever had for this box was real DEC RT-11 (v5.4).
> I never got the original HT-11 disks, so if the H-27 needs a special
> RT-11 driver, that's likely where I'm getting stuck.
The H27 is media compatible with RX01 but the boot and driver for it is
unique.
RT11 then likely V4 with heath driver and was supplied as a special version
from heath (HT11). UCSD pascal with a H27 driver was also available.  Also
TinyC interpreter as a language for HT11.  Back then that was about it for
the H11.

Common H27 issue was the hub clamp plastic would get brittle and die.
That clamp is likely extinct.

Its the one item I do not have is the H27.  I have ram, single serial
cards (DL copies),
and a parallel card that was used with the punch reader.  Most people
found the
H11 power supply rather flaky and usually moved to a BA11 as both upgrade
and mechanical improvement.  Most that had the H11 moved to more mainstream
DEC hardware and OS.

All my systems use RX11, RX21, or RQDX2/3 with M7555 breakout board
for floppies and MFM disks (RD52 Quantum), one has tu58,  and one system
has RLV21, RQDX3, RX21-RX02, RLV21-RL02.

Allison




Re: PDP-11 Memory

2019-01-12 Thread allison via cctalk
On 01/12/2019 05:03 PM, Bill Gunshannon via cctalk wrote:
> On 1/12/19 4:30 PM, allison via cctalk wrote:
>> On 01/12/2019 04:14 PM, Bill Gunshannon via cctalk wrote:
>>> On 1/12/19 2:25 PM, allison via cctalk wrote:
>>>> On 01/12/2019 12:29 PM, Pete Turnbull via cctalk wrote:
>>>>> On 12/01/2019 01:24, Zane Healy via cctalk wrote:
>>>>>
>>>>>> I’m pretty sure you could get the /23+, /53, /73, /83, and /93 in
>>>>>> either a BA23 or a BA123.  I have an actual badged BA23 pedestal for
>>>>>> my /23+.
>>>>> I'm fairly certain all microPDP-11/23+ systems were only sold in BA23
>>>>> boxes, and I think microPDP-11/73 and the later, cheaper, cut-down
>>>>> 11/53 were as well.  But almost all the 11/83 systems I've ever seen
>>>>> were in BA123 boxes, though they did sell some in BA23 pedestals -
>>>>> I've got one.
>>>>>
>>>> Pete,
>>>>
>>>> Your right the 11/23+ showed up on a lot of boxes but not the BA123
>>>> though it would fit.
>>> My 11/23+ is in a box labeled PDP-11/23PLUS on the front with
>>> three toggle switches.  :-)  It has a 9276-A backplane labeled
>>> OPTION 11/23B. It is a 9 slot, Q22 A-B-C-D .  That's the home
>>> for my next system which will (hopefully) have 2 meg of memory,
>>> a DEQNA and an Andromeda Card for a small hard disk and 8" floppy.
>> BA11 box with one of the usual two common backplanes or standard BA23.
>>
>> Problem with DEQNA is what OS?  RT11 does nothing with it.  RSX-11
>> I don't have a recent enough version so its often unused/
> My only problem is I have 3 DEQNA and 1 DELQA.  I thought I read
> somewhere recently that the DEQNA was the better of the two.
DELQA replace the DEQNA as often they didn't work, high failure rate in
service.
There was also a DAta corruption bug that also turned up so DELQA was the
replacement.

> As for software, what about the Kent TCPIP package?  Will that
> not work with the DEQNA?  I thought the two Ethernet controllers
> for QBUS were functionally the same.
Roughly as the DEQNA carried a mop boot loader but it didn't use it for
RT-11.  RT does nto that I know of through 5.4 support the Ni device
for any internal use, an application can but you get to write code and
create a Decnet endpoint.

I know of now IP stacks for PDP11, they may exist but not in my vocabulary.
I can't see why not though but then you likely need UNIX and what version?

I know V6 doesn't and I have that on RL02.
> And, while we are at it, if I type BOOT XH does it look for a
> MOP Server?
For RSX it may work as RSX later versions supported networking.

>>> I also plan on another small 11/23 with 128KW of memory and an
>>> 18 bit backplane so I can use the RX02 emulator.  And, probably
>>> an Andromeda in there, too
>>>
>>>
>>> To bring my part of this discussion to an end, I now have a BA23
>>> MicroPDP box with an 11/73 CPU, 4 meg of memory, DHV11 for eight
>>> serial lines (probably only use one to talk to a TU58 emulator
>>> but the DHV11 was just sitting there looking lonely) a DEQNA
>>> and a CMD SCSI Controller set for 6 disks and one tape.  Only
>>> thing it lacks at this point is software.
>> The TU58 like a responsive IO a DLV11J is a better choice for console and DD
>> and works best if first card after the memory (early in the interrupt
>> grant chain).
> My 11/73 only has a console, thus the need for the DHV11 but really
> only one port. (Although I may try putting multiple serial ports in
> all the boxes and doing some "networking" over them.  :-)
Right the 11/23 and later quad 11/73 have console the dual width without
pulling out
the rack to look did not.

>> The simulators are faster than tu58 so it makes for fewer retries.
>> I use DHV11 for terminal and modem lines (slower stuff).
>>> On to my next project.
>>>
>>> Thanks for all the help.  I had forgotten just how much fun
>>> real computers were compared to PC's and MAC's.
>> Yes they are.  Their performance without all the gui gunk is often a
>> suprize to many that have not worked with them.

I've had people running stuff on a 486/dx33 with 8mb (win3.11 as DOS 5.22)
and RT11 on PDP11/23 with 512kbyte  and totally blew their minds.  The 11
ran a lot of stuff that the PC could and was faster.  Then they got to
see it as
a multiuser system with RSTS, push them over with a feather.   The
multitasking and multiuser aspect shows it off.  Side effect of time and
maturity of OS and Instruction set with good hardware.

The Storage systems were better and MMU made swappi

Re: PDP-11 Memory

2019-01-12 Thread allison via cctalk
On 01/12/2019 04:14 PM, Bill Gunshannon via cctalk wrote:
> On 1/12/19 2:25 PM, allison via cctalk wrote:
>> On 01/12/2019 12:29 PM, Pete Turnbull via cctalk wrote:
>>> On 12/01/2019 01:24, Zane Healy via cctalk wrote:
>>>
>>>> I’m pretty sure you could get the /23+, /53, /73, /83, and /93 in
>>>> either a BA23 or a BA123.  I have an actual badged BA23 pedestal for
>>>> my /23+.
>>> I'm fairly certain all microPDP-11/23+ systems were only sold in BA23
>>> boxes, and I think microPDP-11/73 and the later, cheaper, cut-down
>>> 11/53 were as well.  But almost all the 11/83 systems I've ever seen
>>> were in BA123 boxes, though they did sell some in BA23 pedestals -
>>> I've got one.
>>>
>> Pete,
>>
>> Your right the 11/23+ showed up on a lot of boxes but not the BA123
>> though it would fit.  
> My 11/23+ is in a box labeled PDP-11/23PLUS on the front with
> three toggle switches.  :-)  It has a 9276-A backplane labeled
> OPTION 11/23B. It is a 9 slot, Q22 A-B-C-D .  That's the home
> for my next system which will (hopefully) have 2 meg of memory,
> a DEQNA and an Andromeda Card for a small hard disk and 8" floppy.
BA11 box with one of the usual two common backplanes or standard BA23.

Problem with DEQNA is what OS?  RT11 does nothing with it.  RSX-11
I don't have a recent enough version so its often unused/

> I also plan on another small 11/23 with 128KW of memory and an
> 18 bit backplane so I can use the RX02 emulator.  And, probably
> an Andromeda in there, too
>
>
> To bring my part of this discussion to an end, I now have a BA23
> MicroPDP box with an 11/73 CPU, 4 meg of memory, DHV11 for eight
> serial lines (probably only use one to talk to a TU58 emulator
> but the DHV11 was just sitting there looking lonely) a DEQNA
> and a CMD SCSI Controller set for 6 disks and one tape.  Only
> thing it lacks at this point is software.
The TU58 like a responsive IO a DLV11J is a better choice for console and DD
and works best if first card after the memory (early in the interrupt
grant chain).
The simulators are faster than tu58 so it makes for fewer retries.
I use DHV11 for terminal and modem lines (slower stuff).
> On to my next project.
>
> Thanks for all the help.  I had forgotten just how much fun
> real computers were compared to PC's and MAC's.
Yes they are.  Their performance without all the gui gunk is often a
suprize
to many that have not worked with them.

Allison
> bill



Re: PDP-11 Memory

2019-01-12 Thread allison via cctalk
On 01/12/2019 12:29 PM, Pete Turnbull via cctalk wrote:
> On 12/01/2019 01:24, Zane Healy via cctalk wrote:
>
>> I’m pretty sure you could get the /23+, /53, /73, /83, and /93 in
>> either a BA23 or a BA123.  I have an actual badged BA23 pedestal for
>> my /23+.
>
> I'm fairly certain all microPDP-11/23+ systems were only sold in BA23
> boxes, and I think microPDP-11/73 and the later, cheaper, cut-down
> 11/53 were as well.  But almost all the 11/83 systems I've ever seen
> were in BA123 boxes, though they did sell some in BA23 pedestals -
> I've got one.
>
Pete,

Your right the 11/23+ showed up on a lot of boxes but not the BA123
though it would fit.  The  BA23 as the micropdp11 or 11/53..  names and
models were a large jumble.  The J11 based CPU were showing up int BA123
as the later ones had PMI and a natural for the 123 as anyone
using J11 likely wanted storage, memory and space for it.  

Not not all of the dual width 11/73s were slow chips only that the were
run at 15mhz.  No advantage for faster as Qbus transactions
are slower for memory so the PMI versions were faster by default.

My BA23 (micropdp11was upgraded to microVAXII by me before DEC left me
and the machine next to it under the desk was VIDSYS: a
MicrovaxII GPX They both came home with me on last day.   The BA23 was
put back to the micropdp11 config and VIDSYS: remains though
with larger disks.  I also have a rack based system (11/73 CPU) and
multiple BA11 series mostly 11/23(various flavors) based but have the
11/2 board and LSI-11.   Even An H11 backplane with LSI-11 and Heath ram
and IO.

While there were many sold systems and a larger number of supported
systems Qbus PDP-11 was more mix and match than most any
and the early Qbus microVAX series did that for a while. 


Allison


Re: PDP-11 Memory

2019-01-12 Thread allison via cctalk
On 01/12/2019 12:36 PM, Bill Gunshannon via cctalk wrote:
> On 1/12/19 12:24 PM, Pete Turnbull via cctalk wrote:
>> On 11/01/2019 23:58, Ethan Dicks via cctalk wrote:
>>> On Fri, Jan 11, 2019 at 3:51 PM Bill Gunshannon via cctalk
>>>  wrote:
 Mine are all BA23.  Wasn't the BA123 for the MicroVAX?
>>> As sold, most likely.  I don't think DEC ever configured any MicroPDP
>>> systems in a BA123 but no reason it doesn't work.
>> Absolutely not so - there were very many microPDP-11/83 systems sold in 
>> BA123 cabinets, in fact probably more in BA123 than in BA23.  The 
>> MicroPDP-11 System Maintenance Manual features the BA123 heavily 
>> throughout, as do other microPDP-11 manuals.
>>
> None of my MicroPDP-11 manuals show anything but the BA23. Most
> show the install as being in a deskside pedestal.  But even the
> one that shows rack mount installation is only BA23.
>
> bill
And my older manuals don't show anything other than BA11, later manuals
are useful for that reason.

Allison




Re: PDP-11 Memory

2019-01-11 Thread allison via cctalk
On 01/11/2019 02:55 PM, Bill Gunshannon via cctalk wrote:
> On 1/11/19 2:25 PM, Allison Parent via cctalk wrote:
>> Most Probable cause is interrupt grant is broken.  For most microspheres 
>> backplanes the first three slots are different than remaining.
> Yes, that's true.  But the problem doesn't occur until the 5th slot.
> And a quick look at the C-D edges of the board shows that the BUS
> Grant lines are jumpered. So the 2 A-B slots should pass the grants
> just fine. I saw  no mention about these not working in A-B/A-B
> backplanes.  The only mention the docs make at all is that the
> only lines used on C-D slots is power.
>
> bill
>
That is generally true... however there were more than a few odd backplanes
including a few that were wired for Core and some design to suit a
different
memory and incompatible (smoke releasing!).  Others are unique as the RL11
two board set require a CD backplane slot pair (will not work if ABAB).

You need to look at the backplane and find out what one it is.

I have a few boxes I got without a backplane at all and as a result they
have
what I find was most useful and very non standard.

The CSR complaint is because if you talk to the board and don't get a
int vector
or can't set a working one (floating)  the CSR is broke.  This is a
behavior that
is much different from unibus.  It also happens if an expected CSR is
non standard
for nominal drivers.  An example is my 11/73 as it has 2 RQDX3 so one
has to be
at a new and unusual CSR same for the second DLV11J serial.  Some memory
(parity or ECC) also have CSRs and if they interupt and the drive is not
there
I've heard havoc ensues (of all my memory on hand none have that).

Irs a side effect of the Q bus starting in the 70s (LSI-11) and
continuing with
some evolution though the 90s (11/83 and 11/9x).

Allison



Re: PDP-11 Memory

2019-01-11 Thread allison via cctalk
On 01/11/2019 02:32 PM, Noel Chiappa via cctalk wrote:
> > From: Allison Parent
>
> > Most Probable cause is interrupt grant is broken.
>
> The only -11 that complains if the grant chain is broken that I know of is
> the /34 (maybe the /04 too). I certainly have a QBUS chassis right next to my
> workstation here that i) has a bunch of empty slots, and ii) works fine, as
> long as there are no empty slots between the CPU and the devices.
I'm far from a newby to Qbus 11s as I stated with LSI-11 nearly 4
decades ago
and I ahve all Qbus models of note from LSI-11(quad), 11/2 (dual) ,
11/23(dual)
11/23(quad), 11/23B(quad), 11/73(dual) in various BA11VA,  BA-11s, BA11N,
BA23, BA123, and also microVAXII in BA23 and BA123.  Which covers about
eight different Qbus backplane variations not including the Heath H11 and a
engineering one off (8 slot dual width with bigger supply sorta like
taller a
BA11VA 4 slot.  Small advantage to being a Millrat.   I forgo most
non-Qbus 11s
to specialize.

All of my 11s are Qbus and yes they complain if the interrupt grant
chain is broken.
Missing CSR is the usual complaint.

Typical micorpdp-11 Qbus is:

First three slots after CPU the CD slots are open use, or be used or
memory private bus.
ABCD CPU
ABCD  where CD is memory wired not bus
ABCD
ABCD  up to this slot memory does not have to grant interrupts on the
right (CD)side of quad cards
ABAB  All cards dual or quad must have int grant jumper of the board or
grant card.
ABAB
ABAB
ABAB

> Also, IIRC he said it works with 3 cards plugged in, but not 4; how can
> plugging a card _in_ cause grant problems?
See the above...  Qbus is can or cannot be uniform for quad or dual
width cards.
For most only bus slots that are AB bussed are data/address.  But they
can be
serpentine for quad wide systems and most quad wide board have interrupt
grant jumpers on the board or are just hardwired that way.

Qbus is not Unibus.  You can build a Qbus system of all dual width
cards, some
Qbus system memory uses PMI. 

For example I have an 11/23b+ in a quad width BA11-N but the backplane is
nonstandard ,18 slots of Q22 ABAB (serpentine wired).  It has  a quad
width 11/23B
and 8 MSV11 256KB dual width Q22 memory. RQDX3 dual width, RXV21 RX02,
DRV11J and a M7555 (also found in MicroVAXII in BA123 boxes, takes the
50pin
wide RQDX breaks it out for multiple RX33 floppy and RD32 drives).

There are many Qbus  backplanes  and several different configurations for
DUAL/QUAD mixes of cards.  The Microvax Qbus backplanes also fit in that
realm such as BA123 with J11 cpus installed and PMI ram.  Also many of the
Qbus can be Q16(not many), Q18(fairly common) and Q22(only late and
MicroVax) address bus width.

The microcomputers handbook is a start and the modules manuals.
Typically you need a 1980 version and a later 80s versions.  Also the
LSI-11 Systems Service Manual Volumes 1 and 2.  Generally the more
docs you have for Qbus 11 systems and the MicroVAX kin the less pain
you will have configuring them especially for non standard configurations
or systems with mix and match boards.


Allison




Re: Bogus "account hacked" message

2019-01-08 Thread allison via cctalk
On 01/08/2019 04:29 PM, Grant Taylor via cctalk wrote:
> On 01/08/2019 02:09 PM, allison via cctalk wrote:
>> Its actually funny.  The password given is three yahoo (groups) hacks
>> ago (about 10 years) but the email address used was a public one way
>> reflector (arrl.net).
>
> So you are (or were) a licensed ham.  73 to you.  :-)

Still am.  Hence the reflector as myc...@arrl.net.  But the reply if
there is one will be from
a different address.  Anyone with a functional brain can look that up.

>
>> So all and all its a crude phishing attempt.  I write down old
>> passwords to keep from reuse and I use long mixed ones.  So I know it
>> was from that and meaningless.
>
> Hopefully you keep that list in a way that's not cleartext on your
> computer.
>
Cleartext on paper in my handwriting... ok, that may mean loosely encrypted.

Generally anything useful is walled off or encrypted.  I also maintain
an air gapped
archive.  Hardware is cheap and disk cheaper.  Someone hacks this
machine with
ransomware, I wipe and reboot as a 64gb disk is not big and not the
motherlode.

Better is the stuff on the VAX under VMS user account...  I put it on
the net on occasion and
the fun begins as the script kiddies try to log in.  Mind you need both
an account name and
a password longer than 15 chars.  Standard lockout after three fails is
15 minutes.  No Apache
and other webby stuff plus Decnet over IP messes with them.    Once I
put up an VMS account
with the directiories all write-locked  with virus copies (maybe a few
megabytes of oldies) in it
and a guest password it was funny to watch the access and then nothing
from that IP.

> I too have lists of old passwords in my password vault.
>
>> The source is useless as the address is a bogus hack as well.
>
> I'm still curious.  Mainly because I run my own mail server and wonder
> if the messages would have been stopped by my filtering.
>
Like I said the reflector is public and they used the right call, easy
to look up and verify.

>> Same claims of rude and crude caught off the camera save for the
>> systems use never had one or are blocked/disconnected(laptops) and at
>> best a stupid threat. I run linux on multiple flavors/platforms so
>> typical M$ hacks don't fly either.
>
> Scare tactics.
>
Or hilarity!  As a women it was funnier to read.  Like, really!?!

>> I was tempted to buy the smallest bitcoin possible maybe 0.1 cent (1
>> milliDollar) for laughs and send that as they deserve the very least
>> for a dumb hack.
>
> I would avoid doing anything good to the miscreants.
A millibuck is a pFFT (raspberry noise) to someone demanding kilo bucks.
I have mostly contempt for them.  Been at it longer too.
>
>> Ignore the phoolz and if the password matches current change it.
>
> Yep.

The usual is that that password accessed as many as a dozen or more
sites and accounts.
If one is hacked then which one of the many if even remembered.

>> consider changing them periodically.
>
> I thought there had been some research and reports, particularly from
> NIST (?) about a year ago where /forced/ periodic password changes
> were actually a bad thing.
>
>
Yes, many when forced to do that on 30 or 90 day rotations use poor
passwords (weak) or worse write
them down and tape them under the keyboard.   The interval can be random
and long or anytime a hack
has been reported somewhere even if not the known systems.   I worked
one place where "123" was a
low level password for a decade and still every Monday I'd get called
"did the password change?"
because they forgot it.  If used from outside it got you mostly nothing
and access to very slowest
machines if you made it through the firewall (discrete hardware).


Allison




Re: Bogus "account hacked" message

2019-01-08 Thread allison via cctalk
On 01/08/2019 03:41 PM, Grant Taylor via cctalk wrote:
> On 01/08/2019 01:25 PM, John Rollins via cctalk wrote:
>> That they found an address used only for a certain mailing list makes
>> it more interesting. Doing a quick Google search it looks like the
>> list archives can be searched through, and while the addresses appear
>> to be slightly obfuscated using “at” instead of “@“, it’s feasible
>> that the address was picked up by a random email address scraping of
>> web data.
>
> I've wondered if some unscrupulous person has subscribed to the list
> so that they can receive a steady stream of email addresses that they
> can potentially send spam / phishing emails to.
>
> I don't remember ever getting one of these types of messages.  So I
> can't comment about them with anything other than 2nd (or more) hand
> knowledge.  Though I run fairly tight anti-spam / anti-virus
> configuration on my server.
>
> I would actually be interested in seeing full messages source,
> including headers, for some of the messages.  (If anyone is willing
> and interested in sharing.)
>


I to have received that phishing attempt many times.

Its actually funny.  The password given is three yahoo (groups) hacks
ago (about 10 years) but the email address
used was a public one way reflector (arrl.net).  So all and all its a
crude phishing attempt.  I write down old
passwords to keep from reuse and I use long mixed ones.  So I know it
was from that and meaningless.

The source is useless as the address is a bogus hack as well.

Same claims of rude and crude caught off the camera save for the systems
use never had one or are
blocked/disconnected(laptops) and at best a stupid threat. I run linux
on multiple flavors/platforms so
typical M$ hacks don't fly either.

I was tempted to buy the smallest bitcoin possible maybe 0.1 cent (1
milliDollar) for laughs
and send that as they deserve the very least for a dumb hack.

Ignore the phoolz and if the password matches current change it consider
changing
them periodically.

A=




Re: so far off topic - capatob - saratov2 computer Russsian pdp8?

2019-01-07 Thread allison via cctalk
On 01/07/2019 07:25 PM, ben via cctalk wrote:
> On 1/7/2019 8:20 AM, allison via cctalk wrote:
> snip...
>> made though more likely 74F, AS, or LS variant and of course CMOS 74ACT
>> (and cmos friends) as I just bought a bunch.  Dip is getting harder to
>> get but
>> the various SMT packages are easy.  Prices for 10 or more of a part are
>> cheap to cheaper from primary suppliers.  The second tier suppliers are
>> often several times that.
>
> I got ebay... The bottom of the heap.
>
>> I figure most of what I did back then is years before many here were
>> born.
>>
>> However I have enough NOS TTL 74LS, 74AS, 74F series to build several
>> machines.
>
> I have been playing around with a early 70's TTL computer design
> and 74LS181's are too slow by 30 ns. Using a BLACK BOX model for core
> memory, I can get a 1.2us memory cycle using a 4.912 MHz raw clock
> but I need a few 74Hxx's in there. Proms are 256x4 60 ns and 32x8 50 ns.
>
> Do you have your 74Hxx spares? Eastern Europe still  has a few on ebay
> with reasonable shipping for 100% American Russian parts.
>
No use for 74H parts though I have a bunch.

the 74LS are slow  you are paying for lower power with speed.  tHe 74181
and 74S181 were far faster.

Proms are small and slow, last time I used them was for the address
decode used on the Northstar* MDS-A controller.

I built the last big machine with ram back 1980 and was in the 1us
instruction
cycle time for single cycle instructions without pipelines.  Core was never
considered.  Trick is throw hardware at it.  Adding adders to the address
calculation rather than reuse the ALU saves a lot of time and wires.   Not
like it was for manufacture or anything like that.  More of an exercise.

I still want to make a stretched 8, PDP8 ISA with 16 bits and faster.
No good reason save for it wold be fun.
>> I'm still building, current project is a very compact Z80 CP/M system
>> using CF
>> for disk. Mine uses all Zilog CMOS for very low power.  Its a variant of
>> the
>> Grant Searle Z80 with memory management added to utilize all of the
>> 124k ram and eeprom.  If you want go look there.
>
> What do you use all that memory for?
>
CP/M the allocation block store for each drive and deblocking buffers
for performance
can be large plus its easy to hide part of the Bios in banked ram. 
Background processes
are easier when you have lots of ram for that.  Most of the larger aps
like C compilers
and such run better with more than 48K, 56k is easy, and 60k is doable
with the
right memory map.

For EEprom its more than boot, the system is in EEprom (about 8K) and
with 32K
or more things like romdisks and utilities are easily parked there.

I've been building nonstandard CP/M systems since 79.  In all cases he
aps think
it is standard CP/M but the bios and such have been tuned even CP/M Bdos
it self.
Though I often use ZRdos or ZSdos as they are very good.  Not much you
cant do
to it.

Allison
>>
>
> The Chinese elves have been busy, My 5V 15 amp $20 power supply arrived
> in the mail today. I have power to spare for my BUS and blinking lights.
>
So long as you load it at least 10% it will be good.

> Ben.
>
>



Re: so far off topic - capatob - saratov2 computer Russsian pdp8?

2019-01-07 Thread allison via cctalk
On 01/07/2019 09:51 AM, Peter Corlett via cctalk wrote:
> On Sun, Jan 06, 2019 at 02:54:08PM -0700, ben via cctalk wrote:
>> On 1/6/2019 12:24 PM, allison via cctalk wrote:
>>> The small beauty of being there...   FYI back then (1972) a 7400 was about
>>> 25 cents and 7483 adder was maybe $1.25.  Least that's what I paid.
>> Checks my favorite supplier.
>> $1.25 for 7400 and $4.00 for a 7483.
>> It has gone up in price.
> Thanks to inflation, $0.25 in 1972 is worth $1.51 now. Likewise, $1.25 has
> inflated to $7.54. So they're cheaper in real terms than they used to be.
>
> However, it's still not entirely comparable, as I suspect nobody's making
> 74-series chips any more so you're buying NOS. A modern equivalent would be a
> microcontroller, which start at well under a dollar.
>
First I wasn't guessing back.  I was building and buying back then. So
that was what I
actually paid in 1972,  I've been at it since RTL hit the streets.   The
74 series still
made though more likely 74F, AS, or LS variant and of course CMOS 74ACT
(and cmos friends) as I just bought a bunch.  Dip is getting harder to
get but
the various SMT packages are easy.  Prices for 10 or more of a part are
cheap to cheaper from primary suppliers.  The second tier suppliers are
often several times that.

I figure most of what I did back then is years before many here were born.

However I have enough NOS TTL 74LS, 74AS, 74F series to build several
machines. 

I'm still building, current project is a very compact Z80 CP/M system
using CF
for disk. Mine uses all Zilog CMOS for very low power.  Its a variant of
the
Grant Searle Z80 with memory management added to utilize all of the
124k ram and eeprom.  If you want go look there.

Allison





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

2019-01-06 Thread allison via cctalk
On 01/06/2019 01:54 PM, William Donzelli via cctalk wrote:
>> And then the PDP-11 put the nail in that coffin (and in 1980, there were more
>> PDP-11's, world-wide, than any other kind of computer).
> I bet the guys at Zilog might have something to talk to you about.
>
> --
> Will
And Intel!  8008 and 8080 was a byte machine as was 8085, z80,  8088,
6800, 6502, and a long list to follow.

The PDP-11 was unique that it was 8/16 bit in that memory (and by
default IO) supported both byte and word
reads and write.   Instructions were 16bit but data was byte word.  

There were more  Z80 based machines (TRS-80 alone exceeded 250,000) than
PDP-11.
History guys, we are about history!

Allison




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

2019-01-06 Thread allison via cctalk
On 01/06/2019 02:08 PM, Grant Taylor via cctalk wrote:
> On 1/6/19 11:25 AM, Guy Sotomayor Jr via cctalk wrote:
>> I think it’s also telling that the IETF uses the term octet in all of
>> the specifications to refer to 8-bit sized data.  As “byte” (from
>> older machines) could be anything and is thus somewhat ambiguous.
>>
>> It *may* have been the IBM 360 that started the trend of Byte ==
>> 8-bits as the 360’s memory (in IBM’s terms) was byte addressable and
>> the instructions for accessing them were “byte” instructions (as
>> opposed to half-word and word instructions).
>
Yes it was.

Machines around them and in that time frame (mainframe) were 12, 18, 36,
60 bit words.

The big break was mid 1970s with micros first 8008, 8080, 6800 and
bigger machines
like PDP11 (did byte word reads and writes) and TI990.

The emergence of VAX and other 32bit machines made 8bit common as
terminal IO was
starting to standardize.

> Thank you for the clarification.
>
> My take away is that before some nebulous point in time (circa IBM's
> 360) a "byte" could be a number of different bits, depending on the
> computer being discussed.  Conversely, after said nebulous point in
> time a byte was standardized on 8-bits.
>
> Is that fair and accurate enough?  -  I'm wanting to validate the
> patch before I apply it to my mental model of things.  ;- 

There is no hard before and after as systems like DEC10 and other
persisted for a while.  Also part of it was IO codes for the
EBDIC, Flexowriter, ASr33 (8level vs Baudot), and CRT terminals emerging
with mostly IBM or ANSI.

I am somewhat DEC and personal computer (pre IBM PC) centric on this as
they were he machines I got to see
and work with that were not in rooms with glass and white coated
specialists.

Allison





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

2019-01-06 Thread allison via cctalk
On 01/06/2019 01:19 PM, Noel Chiappa via cctalk wrote:
> > From: Grant Taylor
>
> > Is "byte" the correct term for 6-bits?  I thought a "byte" had always 
> > been 8-bits.
>
> I don't claim wide familiary with architectural jargon from the early days,
> but the PDP-10 at least (I don't know about other prominent 36-bit machines
> such as the IBM 7094/etc, and the GE 635/645) supported 'bytes' of any size,
> with 'byte pointers' used in a couple of instructions which could extract and
> deposit 'bytes' from a word; the pointers specified the starting bit, and the
> width of the 'byte'. These were used for both SIXBIT (an early character
> encoding), and ASCII (7-bit bytes, 5 per word, with one bit left over).
As far as what other systems supported especially the 7094 and GE, that
is already out
of context as the focus was a Russian PDP-8 clone.  Any other machines
are then thread
contamination or worse.

In the early days a byte was the smallest recognized group of bits for
that system
and in some case its 9 bits, 6bits as they were even divisible segments
of the machine
word.  This feature was the bane of programmers as everyone had a
different idea
of what it was and it was poison to portability.

For PDP-8 and friends it was 6 bits and was basically a halfword, also
used as stated for
6bit subset of ASCII (uppercase, TTY codes).  Most of the 8 series had
the bit mapped
instructions (DEC called the microcoded) for doing BSW, byte swap,  swap
the
lower half of the ACC with the upper half.  Very handy for doing
character IO.

> > I would have blindly substituted "word" in place of "byte" except for
> > the fact that you subsequently say "12-bit words". I don't know if
> > "words" is parallel on purpose, as in representing a quantity of two
> > 6-bit word.
>
> I think 'word' was usually used to describe the instruction size (although
> some machines also supported 'half-word' instructions), and also the
> machine's 'ordinary' length - e.g. for the accumulator(s), the quantum of
> data transfer to/from memory, etc. Not necessarily memory addresses, mind -
> on the PDP-10, those were 18 bits (i.e. half-word) - although the smallest
> thing _named_ by a memory addresses was usually a word.
>
>   Noel
The PDP-8 and 12bit relations the instruction word and basic
architecture was 12bit word.
There were no instructions that were a half word in length or other
fragmentations.  The
machine was fairly simple and all the speculated concepts were well
outside the design
of the PDP-5/8 family.   For all of those the instruction fetch, memory
reads and write
were always words of 12bits.   I'd expect a Russian PDP-8 clone to be
the same.   After
all DEC did widely gave out the data books with nearly everything but
schematics.  The
value of copying is software is also copied.  It happened here with the
DCC-112 a
PDP-8e functional clone.

While its possible to use half word ram with reconstruction the hardware
cost is high
(registers to store the pieces) and it would take more to do that than
whole 12bit words.
Any time you look at old machine especially pre-IC registers were costly
and only done
as necessity dictated as a single bit flipflop was likely 4 transistors
(plus diodes and other
components) or more to implement never minding gating. 

Minor history and thread relative drift... 
The only reason people didn't build their own PDP-8 in the early 70s was
CORE.  It was
the one part a early personal computer (meaning personally owned then) 
was difficulty
to duplicate and expensive outright buy.  Trying to make "random" core
planes that
were available work was very difficult due to lack of data, critical
timing, and the
often minimal bench (and costly) test equipment.   The minimum gear for
seeing
the timing was a Tek-516 and that was $1169(1969$).   Semiconductor ram was
either a few bits (4x4) or 1101 (three voltage 256x1) at about 8$ in
1972 dollars.  That
made the parts for a 256x12 a weeks pay at that time (pre-8008) and a
4Kx12 with parts
was nearly that of a new truck (2100$)!.   Compared the basic logic of
the 8e (only
three boards of SSI TTL) core/ram was the show stopper.  About 7 years
later a 8K8
S100 ram was about  (early 1979) 100$, by 1980 64kx8 was 100$.   Moore's
law was
being felt.

The small beauty of being there...   FYI back then (1972) a 7400 was
about 25 cents
and 7483 adder was maybe $1.25.  Least that's what I paid.

Allison



Re: music dec tapes? (paper)

2019-01-04 Thread allison via cctalk
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)

2019-01-03 Thread allison via cctalk
On 01/03/2019 05:22 PM, Kyle Owen wrote:
> On Thu, Jan 3, 2019 at 3:29 PM allison via cctech
> mailto:cct...@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)

2019-01-03 Thread allison via cctalk
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 <
>> cctalk@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: Origin of 'Straight 8' name

2018-12-21 Thread allison via cctalk
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: Origin of 'Straight 8' name

2018-12-21 Thread allison via cctalk
On 12/21/2018 10:10 AM, Noel Chiappa via cctalk wrote:
> Does anyone know where the 'Straight 8' name for the first PDP-8 model came
> from? Obviously, it's probably a play on the car engine configuration name,
> but how did the connection get made? Thanks - I hope!
>
> Noel
>
ssrsly?

It was the first PDP-8 no model letter like S, L, I, E, F, M, or A.  It
was also the direct decedent of the
PDP-5 (1963 and transistors) which was the first 12bit machine and
largely compatible with later
family of 8 machines.  The PDP-8 series started in 1965 and grew from there.

When looking at the history LINK and LINK-8, PDP12, and later LAB-8 are
also related and interleaved
as laboratory machines.

Simple answer, it was DECs first blockbuster machine that was
manufactured in high volume and was
very low cost in terms of the day.

The transistor to IC change...  The 8I:
Also commenting on ICs the 1970 Omnibus 8 (PDP-E)  was the largely MSI
IC based machine (M series).
The 8I/8L was the first TTL machine prior to that the systems were
transistor.    The march to higher density
ICs was well underway. 

FYI my first contact was the DEC PDP8I fall of 1969  as part of the
BOCES LIRICS timeshare system
(NY, LI, Sufflok county schools). The following year (fall 1970) it was
integrated into and part of the larger
DEC System 10 timeshare system running TOPS-10.

None of this is secret or difficult to find.  Doug Jones has a great
archive.   http://homepage.divms.uiowa.edu/~jones/pdp8/


Allison


Re: Which DEC machine made use of th pre Flip-Chip board?

2018-12-21 Thread allison via cctalk
On 12/21/2018 09:33 AM, Noel Chiappa via cctalk wrote:
> > through (I think) the PDP-7; at least, this PDP-7 internals image
> > .. seems to show System Modules at the top, and FLIP CHIPs at the
> > bottom.
>
> After groveling through the 'PDP-7 Maintainence Manual' (F-77A), this seems to
> be accurate. In "Module Identification" (pg. 6-5), it refers to both types; 
> the
> example on the next page uses a 4303, a 4000-Series System Module.
>
> What's interesting is the physical layout; all System Modules at the top of
> that image, and FLIP CHIPs at the bottom. No doubt this is partially for
> mechanical reasons (the two used different backplanes), but I wonder about the
> division into sub-systems; were the two types interspersed among each other in
> individual sub-systems (rewquiring running wires from the top to the bottom),
> or were sub-systems exclusively one or the other (so that the top of the bay
> is one sub-system, and the bottom another)?
>
> No doubt I could answer this by studying the prints, but time is short; 
> perhaps
> someone who worked on the one at the LCM and already knows the answer can
> enlighten us!
>
> Noel
IC as in digital logic  were in production in the early 60s and RTL/DTL
the  oldest I was playing with as a kid by '66
and TTL started to appear well before 1970.  The stuff of the day was
2input Nand, Nor, 4 bit counters, and
similar SSI logic.

We forget the AGC Apollo guidance computer used a dual 3input NOR RTL
dating to 1960.  This was already
old by 1970.  People were building frequency counters with RTL
(uL914/923, MC789 and friends as
"hobbyist chips" it by then.  Least I was able to buy uL9xx, MC7XX,
MC10K,  in the late 60s for under a
dollar a package.

The transition from transistors to ICs was fast.  Cost and space were
drivers and generally speed as well.
The industry needed faster and more reliable and interconnects needed to
be fewer.  At the same time ICs
went from 1960 dual 3input nor to MSI (7483 quad full adder and 74181
ALU) in about 10 years.  The computer
industry were the early consumers.

Allison


Re: flashx20 - Floppy and screen for the Epson HX-20

2018-12-17 Thread allison via cctalk
On 12/16/2018 11:39 PM, Will Cooke via cctalk wrote:
>
>
>
>
>
> On December 16, 2018 at 11:14 PM allison via cctalk  
> wrote:
>>> On Sun, 16 Dec 2018, Norbert Kehrer via cctalk wrote:
>>>> I have not tested it, but I suppose, that also the PX-8 and PX-4 used
>>>> the protocol,
>>>> because the protocol specification defines the following device numbers:
>>>> - HX-20: 0x20 (probably also used for the HC-20)
>>>> - PX-8:  0x22
>>>> - PX-4:  0x23
>>>
>>>
>> PX-8!
>>
> A subject dear to me.  I still have the px-8 I bought new (borrowed the money 
> from my sister) as a young man in 1984.  Alas, I could never afford the PF-10 
> disk drive.
>  
>
>>> However, the PX-8 3.5" had 40 cylinders, with 67.5 tpi, instead of the
>>> common 80 cylinder 135 tpi of other 3.5" disks.
>>> Those 40 cylinder 3.5" drives are quite rare.
> Somewhere in my searches I recall reading that the 3 1/2" drives used the 
> same format as the 5 1/4" ones.  Maybe 40 tracks of 16 256 byte sectors.  
> Oddly, I believe that 2 tracks are "reserved for CP/M" even though it is in 
> ROM and not stored on disk. 
>
>
>> ceramic magnet lost its stuff over time.  When I have time the next
>> project will be a Atmega2650 running
>> a CF to via serial interface.  The drive table can be patched for a
>> larger (up to 8mb) drive.
> I've been planning something very similar for a while, but using an Arduino 
> (ATMega 328) or bare AVR chip and probably a smaller/simpler flash chip.  I 
> din't know about the drive table.  That's interesting.  Would a new ROM have 
> to be burned with the new table?  Do you have an links to the info?

The system in the base PX-8 has a system area for user patches. the
drive table is part of the BIOS and
there are provisions for intercepting the calls to there and patching in
changes or extensions.  Its
detailed in the manuals.


>>> With appropriate format handling software on the PC, it should be
>>> possible for a PC connected using your system to work with actual
>>> Epson diskettes, and emulate the Epson external drives.
>>>
>> There are several software packages on the net to do the fake of the
>> disk via serial and manuals of the system to
>> explain the format.  Likely that software could do the earlier HX20 (and
>> friends) with minor tweaks.
> Here is one I am familiar with that runs on Linux.  Only does drives, AFAIK, 
> no display.
> https://fjkraan.home.xs4all.nl/comp/px4/vfloppy/
Thats true, but the IO on the PX-8 allows for redirection to the serial
port for console and even keyboard.
I've many times used it with my VT320 to save my poor eyes.

> And if anyone is interested here are some more links:
> http://oldcomputer.info/8bit/hx20/index.htm#links
> Navigating through some of those links takes you to the protocol:
> https://fjkraan.home.xs4all.nl/comp/hx20/epsp.html
> Note at the bottom of the page it says the PX-8 and CP/M only use four of the 
> functions.
> This link has lots of HX-20 info.  
> http://electrickery.xs4all.nl/comp/hx20/doc/index.html
> The tms files near the bottom (ch 10-11?) describe the protocol and how it 
> functions in detail.
>
> Will
>
 Indeed.  its all there.


Re: flashx20 - Floppy and screen for the Epson HX-20

2018-12-17 Thread allison via cctalk
On 12/16/2018 11:56 PM, Fred Cisin via cctalk wrote:
>> On December 16, 2018 at 11:14 PM allison via cctalk
>>  wrote:
>>>
>>>> On Sun, 16 Dec 2018, Norbert Kehrer via cctalk wrote:
>>>>> I have not tested it, but I suppose, that also the PX-8 and PX-4 used
>>>>> the protocol,
>>>>> because the protocol specification defines the following device
>>>>> numbers:
>>>>> - HX-20: 0x20 (probably also used for the HC-20)
>>>>> - PX-8:  0x22
>>>>> - PX-4:  0x23
>>>>
>>>>
>>>>
>>> PX-8!
>>>
>> A subject dear to me.  I still have the px-8 I bought new (borrowed
>> the money from my sister) as a young man in 1984.  Alas, I could
>> never afford the PF-10 disk drive.
>>
I've had one for many decades and 2 more for well, now its two decades.
Handy little critter and they do see use.
>>
>>>> However, the PX-8 3.5" had 40 cylinders, with 67.5 tpi, instead of the
>>>> common 80 cylinder 135 tpi of other 3.5" disks.
>>>> Those 40 cylinder 3.5" drives are quite rare.
>
> On Sun, 16 Dec 2018, Will Cooke via cctalk wrote:
>> Somewhere in my searches I recall reading that the 3 1/2" drives used
>> the same format as the 5 1/4" ones.  Maybe 40 tracks of 16 256 byte
>> sectors.  Oddly, I believe that 2 tracks are "reserved for CP/M" even
>> though it is in ROM and not stored on disk.
>
> It was not uncommon for CP/M disks to have "reserved" or "system"
> tracks, even when the particular disk was not a bootable "system" disk.
>
Standard SSSD 8" that is the case the fist two tracks are for "system"
and the system is loaded from those.
Most other do a variation depending on format and space.  CP/M ( the
modules CCP, BDOS, BIOS) fits in about 8k
so that defines the size of system tracks. 

CP/M revolves around logical sectors of 128 bytes so anything larger
2556/512/1k requires
blocking and deblocking in the bios.

> I don't remember for sure, and don't have convenient access to my
> materials, but 16 256 byte physical sectors makes sense.
>
Yes, it would be enough.  Save for the PX8 has CP/M loaded into ROM so
the system tracks are largely wasted.
I believe there is some drive and system level configuration information
there but we are talking less than
a sector or two.

> The drive manual
> http://electrickery.xs4all.nl/comp/px8/doc/PF-10Manual.pdf
> SAYS 9 512 byte sectors, but that seems likely to be in error from a
> cut and paste boilerplate from a different machine, because the more
> specific information is all for "64 sectors", which means CP/M RECORDS
> or "logical sectors" of 128 bytes each.  THAT would be consistent with
> either 8 512 byte PHYSICAL sectors, or 16 256 byte PHYSICAL sectors.
>
It seems that way as it matches the PF-20 5.25" drive.  However the
format on the drive also seems consistent at 9x512.
Its not uncommon to use the whole system track or two even if it has
"excess" space. Often the first sector contains the full
disk book rather than a minimal 1 sector boot.  There is a lot of
latitude and mostly why copy format programs such as yours
existed due to same drive and media and many many different formats.


I've gotten away from rotating media on a few of my CP/M systems and
they go to the edge of what CP/M permits
as in EPROM loaded, ROMdisks, RAMdisks and CF.


Allison


Re: Core memory emulator using non volatile ram.

2018-12-16 Thread allison via cctalk
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.

2018-12-16 Thread allison via cctalk
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.

2018-12-16 Thread allison via cctalk
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: flashx20 - Floppy and screen for the Epson HX-20

2018-12-16 Thread allison via cctalk
On 12/16/2018 10:59 PM, Fred Cisin via cctalk wrote:
> On Sun, 16 Dec 2018, Norbert Kehrer via cctalk wrote:
>> I have not tested it, but I suppose, that also the PX-8 and PX-4 used
>> the protocol,
>> because the protocol specification defines the following device numbers:
>> - HX-20: 0x20 (probably also used for the HC-20)
>> - PX-8:  0x22
>> - PX-4:  0x23
>
>
>
PX-8!

> The Epson Geneva PX-8 had an external 3.5" floppy available, and CP/M!
CP/M was in rom so your disk was a paltry 24k(bare PX8), 60K(multiwedge)
or 120K (Ramdisk wedge)
and of course both a 5.25 or 3.5 floppy.  The 3.5" drive could run on
internal battery.

> However, the PX-8 3.5" had 40 cylinders, with 67.5 tpi, instead of the
> common 80 cylinder 135 tpi of other 3.5" disks.
> Those 40 cylinder 3.5" drives are quite rare.
> I don't know about the track width; for reading, a PC can simply look
> at every other track.  And formatting a virgin disk and writing to it
> should work.  But, there is a definite possibility that RE-writing a
> PX-8 disk would result in one that the PX-8 couldn't handle (EXACTLY
> the same problem as RE-writing a 40 track 5.25" disk with an 80 track
> 5.25" drive)
>
Many of the drives have dead spots and need a manual push to start.  I
have two like that.  I suspect the
ceramic magnet lost its stuff over time.  When I have time the next
project will be a Atmega2650 running
a CF to via serial interface.  The drive table can be patched for a
larger (up to 8mb) drive.
>
> With appropriate format handling software on the PC, it should be
> possible for a PC connected using your system to work with actual
> Epson diskettes, and emulate the Epson external drives.
>
There are several software packages on the net to do the fake of the
disk via serial and manuals of the system to
explain the format.  Likely that software could do the earlier HX20 (and
friends) with minor tweaks.

Allison



Re: Core memory emulator using non volatile ram.

2018-12-16 Thread allison via cctalk
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: PET peve thing... Editors

2018-12-13 Thread allison via cctalk
On 12/13/2018 12:05 AM, Sean Conner via cctalk wrote:
> It was thus said that the Great allison via cctalk once stated:
>> On 12/12/2018 03:04 PM, Sean Conner via cctalk wrote:
>>> It was thus said that the Great allison via cctalk once stated:
>>>> The whole thing comes from a project for myself... 
>>>> I wanted a very basic screen based editor written in 8080/8085/z80 asm
>>>> and compact
>>>> (as in under 4K).  I figured first lets inquire of the Internet to see
>>>> if I need to and code exists...
>>>   I remember typing in TED.ASM from one of the PC magazines in the late 
>>> 80s. 
>>> Yes, it's for MS-DOS, but:
>>>
>>> 1) The 8086 is somewhat, kind of, source compatible with the
>>> 8080/Z80 (if you squint hard enough)
>> Your not serious?  Z80 or 8080 to 8086 is not too bad but the other way
>> is plain nuts.
>   I learned assembly on the 6809, then the 8086 (technically the 8088). I've
> always heard that it was designed to make porting code from the 8080/Z80
> easy.  But I never really learned the assembly for the 8080/Z80.  I only
> mentioned it because I think (if I recall) TED.COM was limited to editing
> around 60K or so (one segment's worth of memory).
The 6809 is one of the few I pay attention to as it was remarkably close
to the PDP-11.

The 8088/86 is that it was designed as a 8085 with a bag on the side. 
The register
correspondence from 8080/8085 to 8088 is good and lofting code usually
works if
you watch for odd errors like AH, is that the value A hex, or
Accumulator high.  Z80
however in base is 8080/8085 but had a second set of identical registers
and 8088
has nothing like that.  So unless one keep the Z80 code to the 8080
register model
it does not translate well.   In the reverse direction the 8088 has
register (segment)
and a few other that would have to be sorted out by hand.

The size limit of 60K is not a problem as what I want is aimed at files
in the 7-32K range.
>   But I can see it won't fit your needs.
If it wasn't a handful to get ported to z80 it might have made a start.

I found EDIT and EDITM both are based on EDIT CPMSIG vol 16 where edit M
is more cleaned up
and handles some things better.  Both are very small under 2.8K.  So
that makes for a platform
to add to by wiring in a set of recurrent edit macros that repeat and
update the screen.

Allison



Re: PET peve thing... Editors

2018-12-12 Thread allison via cctalk
On 12/12/2018 03:04 PM, Sean Conner via cctalk wrote:
> It was thus said that the Great allison via cctalk once stated:
>> The whole thing comes from a project for myself... 
>> I wanted a very basic screen based editor written in 8080/8085/z80 asm
>> and compact
>> (as in under 4K).  I figured first lets inquire of the Internet to see
>> if I need to and code exists...
>   I remember typing in TED.ASM from one of the PC magazines in the late 80s. 
> Yes, it's for MS-DOS, but:
>
>   1) The 8086 is somewhat, kind of, source compatible with the
>   8080/Z80 (if you squint hard enough)
Your not serious?  Z80 or 8080 to 8086 is not too bad but the other way
is plain nuts.

>   2) It was 3K when assembled into TED.COM
Its not nice code either.  It assumes a memory mapped video, as in the
usual
PC video.   Kaypro is a pretty close example of that but this will not
be used
on a kaypro.

The executable did run ok in .dosemu.
>   3) Was full screen.  And quite basic.  
>
>   I'm not sure how hard it would be to translate it to 8080/Z80.
Pretty nasty as Z80 does not know of segments, DOS IO, or can be assumed
to have a memory mapped video.  For S100 that would be a PT VDM-1,or one
of the similar flavors.   If it were my usual S100/Kaypro/AMproLB+ or
any of
the CP/M machines I have its VEDIT.

But this machine is maybe 1/3rd the size of a S100 card. All IO is
serial initially.

Allison


Re: PET peve thing... Editors

2018-12-12 Thread allison via cctalk
On 12/12/2018 03:08 PM, Sean Conner via cctalk wrote:
> It was thus said that the Great allison via cctalk once stated:
>> The whole thing comes from a project for myself... 
>> I wanted a very basic screen based editor written in 8080/8085/z80 asm
>> and compact
>> (as in under 4K).  I figured first lets inquire of the Internet to see
>> if I need to and code exists...
>   There is this page:
>
>   http://www.texteditors.org/cgi-bin/wiki.pl?CPMEditorFamily
Its been bookmarked for years.  Lot of stuff there many dead links and
some only lead to
executables.  Many just repeats of the Walnutcreek CP/M CDrom and i've
had that for well over
20 years.

The real hunt was good links, source or source that could uncrunched,
unLBR, UnLZH, Unhuffed, unarced or
unarked.

Most however lead to a compredded vversion of a executable only and
exceeds the size of edit and
the one from DRdobbs is large. regardless of the C compiler used.
>   That might have what you want.
Finally found the source for Edit.  Not a favorite as its line but i can
build in a simple flavor
of VTECO with it  Its from SIGM vol16.   My usual editor for CP/M is
VEDIT and has been since
late '79.  In between that KED on RT-11 and TPU on VAX/VMS it wasn't
till the mid 386 era that
I had to use a PC for anything and it was VEDIT there too till winders
then Notepad+

Why not Vedit, 11K.

Linux is generally gedit with language selections added even 8080/z80 asm.

>   -spc (On the basis that CP/M ran on the 8080/Z80 CPU ... )
Sheesh it originated there and was ported to 68K and Z8K.  When One says
CP/M they are
Its safe to assume 8080/8085/z80/z180/280/NSC800 or other z80 core.


Allison


Re: P112 redesigned for Z280? terminal

2018-12-12 Thread allison via cctalk
>> That is the easy part, where is the 99 cent dumb terminal to go with it?
>> Ben.
>

Ben,

look at Grant Searle's display system, not the Z80 CP/M but his three
chip display system.
Take two Atmel Atmega328Ps and a 74ls166  monitor and P2 keyboard required.
That yields a 24line x 80char display that is a subset of Vt100/Ansii.
Its not 99cents but
at list prices under 7$ Monitor and keyboard not included.

Or you can use an arduino with a 40char by 4 line LCD.


Allison


Re: PET peve thing... Editors

2018-12-12 Thread allison via cctalk
On 12/12/2018 02:49 PM, emanuel stiebler via cctalk wrote:
> On 2018-12-12 14:41, allison via cctalk wrote:
>> The whole thing comes from a project for myself... 
>> I wanted a very basic screen based editor written in 8080/8085/z80 asm
>> and compact
>> (as in under 4K).  I figured first lets inquire of the Internet to see
>> if I need to and code exists...
> Probably something like the
> "TEA an 8080/8085 Co-Resident Editor/Assembler"
>
> Have the book in the shelf, I think I used it once,
> and IIRC, the Source was once on the internet ...
I also have the book.
TEA is both an assembler (not needed) and line oriented editor like ED
(gag).  There are many others just
like it others like it including EDASM (trs80), PT ALS-8, MITS
Programming package 1 (and II), a similar package
for IMSAI as well as Dave Dunfields ALPS.  None are screen oriented and
all add the weight of an assembler.

If I wanted ED I have it as its native and supplied with CP/M.  Best I
can tell over the last 4 decades most
people like me suffered it to get the system up and bought something a
bit less painful.  And deleted ED.
What would be worse?  Typing in TEA from the book, stripping the
assembler and making it CP/M friendly.
Since that seems rather high effort its easier to take SCS-1, ALPS, or
ALS-8 as at least I have source on
line.

The project will be a z80 system and the boot device is a 32K EEProm
with system and a very small
disk image so every K of code I can save/avoid  is a program to fit in
the available 24K.  Wit a little magic
DDT, ASM, and an editor has to fit.  That's bridge code mostly as the
next level is a large device (IDE/CF/SD).

Seems simple but, not.

Allison







PET peve thing... Editors

2018-12-12 Thread allison via cctalk
The whole thing comes from a project for myself... 
I wanted a very basic screen based editor written in 8080/8085/z80 asm
and compact
(as in under 4K).  I figured first lets inquire of the Internet to see
if I need to and code exists...

Well google is a rats bottom as now matter how you write it it either
thinks your talking about

 assemblers, no i'm not.
 emulators, srsly?
 PC based editor, still not close
 HTML editors, aw come on now!
 ALS or any of the line editor (aka ED), yuck and I have that already...
 
They must have existed how'ed all that CP/M code get written before
Vedit or other programmers editors?
So now I'm going to have to write my own as the "world search tools" are
willfully dumb and stupid.



Allison


Re: P112 redesigned for Z280?

2018-12-12 Thread allison via cctalk
On 12/12/2018 07:58 AM, David Griffith via cctalk wrote:
>
> My reply is at the bottom.
> Please put your reply there too.
> On Tue, 4 Dec 2018, ben via cctalk wrote:
>> On 12/4/2018 1:17 PM, Tony Nicholson via cctalk wrote:
>>> Hello David
>>>
>>> I saw your posting on the cctalk mailing list regarding RSX180.
>>>
>>> It is Hector Peraza that's been tinkering with this.  He intends
>>> making the
>>> full source-code available via SourceForge or GitHub but is still
>>> working
>>> on preliminary web pages and documenting etc.  No doubt he will
>>> provide you
>>> with more details.
>>>
>>> I've been tinkering with a Z280 system designed by Bill Shen (the
>>> Z280RC on
>>> the RetroBrew web site at
>>> https://www.retrobrewcomputers.org/doku.php?id=builderpages:plasmo:z280rc
>>> )
>>> and have contacted Hector about porting it to the Z280.
>>
>> That is the easy part, where is the 99 cent dumb terminal to go with it?
>> Ben.
>
> That's got me thinking... Suppose I redesign the P112 board to take a
> Z280 CPU.  Would you guys go for it?  I'd like to come up with a way
> to use a socketed CPU or put a surface-mounted chip on a carrier board
> to allow greater versatility with playing with different Zilog chips.
>

I'd be interested in a Z280 system.  I have a few of the jlead (socketed
format) chips of very late revision
I've built around.   The design work I used was started by Tim Olmstead.
   The RSX system would likely
run very well as Z280 offers larger memory, I space,  supervisor/use,
and MMU so a real protected
space OS is possible. 

Allison




Re: Another p112 Query

2018-12-06 Thread allison via cctalk
On 12/06/2018 10:37 AM, David Griffith via cctalk wrote:
> On December 6, 2018 6:42:44 AM PST, Bill Gunshannon via cctalk 
>  wrote:
>> While we are talking about the P122   :-)
>>
>>
>> Has anyone tried and/or had luck using an 8" floppy drive
>>
>> on the P112?
>>
>>
>> bill
> I haven't tried it myself, but a few of my customers have reported success 
> doing so.
The answer is Yes, if you really understand what your asking.

I've not used the P112 but I have used the combo part in it for FDC
interface and it does/can work with 8", 5.25", 3.5"
drive so long as you get the wiring right as they all differ especially
the 8".   It does do CP/M 8" SSSD format
which was the primary interest (RX01 was secondary and does that too).

The second half of that is the driver for the device as it can do it but
it does have to be programmed.

The combo chip is basically a 765/8272 with 9229 for clock and FDC
interface inside and is not unlike the
37C65/37C765 and remote relations.  Basically it can do any fairly
standard soft sector thing  assuming
its not one of the odd 1771/1773 formats or based on some unique
controller (intel 2D M2FM and RX02). 
The chip used was from the PC world and most people that had issues with
PCs and 8" disks were
trying to work with existing PC FDC drivers limitations.

Allison



Re: [rescue] Sun2/120 SunOS 3.2 suntools movie (was: advise on Sun2 disk install)

2018-12-06 Thread allison via cctalk
On 12/06/2018 07:28 AM, Liam Proven via cctech wrote:
> On Thu, 6 Dec 2018 at 12:44, Tony Duell  wrote:
>> I don't think anyone is questioning that it's a workstation, and that it was
>> made by Sun.
>>
>> I think the problem is over 'first' and that a Sun-2 is not going to be the
>> 'first' model.
> Ah! Excellent point. I have to admit, I was totally unfamiliar with
> the very early Sun products. I was happy with my little ZX Spectrum
> back then, and being about 14, wasn't paying much attention to the
> world of academic Unix usage. :-)
>
> Looking up the SUN-1, I see that it lacked a graphics adapter, and was
> a text-only machine. I didn't know that. That alone means that it's
> not really what I think of when I think of a Sun workstation: no
> windowing system means that for me it's not really a workstation.
>
> But as a single-user Unix machine, yes, it unquestionably qualifies,
> and I need to redefine my terms and my thinking a little...
>
>
During my days at DEC in the later 80s the definition of workstation was
1MIPS processing power,
1M pixels, Desktop or desk side (fairly compact).  Graphics and
processing power were high
and lots of ram and sufficient local disk as well.  Most of the machines
were RISC based,
Sun (sparc), MIPS, or ARM powered.

Allsion





Re: P112 runs RSX-11

2018-12-05 Thread allison via cctalk
On 12/05/2018 05:00 PM, Torfinn Ingolfsen via cctalk wrote:
> There is a "contact" link on this page:
> http://p112.sourceforge.net/index.php?rsx180
> Maybe it works.
> On Tue, Dec 4, 2018 at 6:48 PM Al Kossow via cctalk
>  wrote:
>>
>>
>> On 12/4/18 7:51 AM, Dennis Boone via cctalk wrote:
>>>  > That's all I could find, too.  If anyone knows where the source might
>>>  > be or stumbles on it, I would definitely be interested as well.
>>>
>>> I think that's Hector Peraza's site.  His email address is listed; you
>>> could try writing to him.
>>>
>>> De
>>>
>> Subject: Re: Interested in a Z280 SBC
>> Posted by
>> hperaza
>>  on Thu, 12 Oct 2017 12:44:09 GMT
>> View Forum Message
>>  <>
>> Reply to Message
>> lowen wrote on Wed, 11 October 2017 06:44While I personally would like to 
>> see a bit more
>> coordination of efforts especially in the area of the C compiler, assembler, 
>> and emulator, I know of
>> several efforts by several people already underway.  I am very interested in 
>> the emulation side of
>> things, and even going as far as a VHDL or verilog core that could be used 
>> in an FPGA.  With the
>> annoying bugs fixed, of course!
>> Some of the bugs could even be emulated (if they are not of erratic nature, 
>> of course). That could
>> be useful in case someone wants to test a program on the FPGA version that 
>> is intended to work
>> on the real iron as well. The "compatibility" mode could be controlled by a 
>> bit in an additional CPU
>> control register.
>> Which brings up another question: is there any updated list somewhere of the 
>> known Z280 bugs?
>> So far the information available is rather fragmented and incomplete.
>> Quote:To all who are involved in doing a compiler, assembler, or emulator: I 
>> know you've probably
>> posted before, but I would like to get a list together of all of these 
>> efforts and see what
>> coordination might be possible.
>> OK, here is my list:
>>  native Z280 (macro)-assembler, preferably M80 or SLR compatible (currently 
>> working on that)
>> debugger (e.g. like DDTZ, but using the single-step capabilities of the 
>> chip) get UZI280 working
>> (haven't even looked at it yet) and add more utilities, etc. same for Fuzix 
>> port of MP/M better hard
>> disk support (e.g. via FDISK utility like the one for the P112, with 
>> automatic recognition of
>> partitions in CP/M and UZI so one will not have to change the BIOS every 
>> time partitions change)
>> better ROM setup? again taking the P112 as an example (i.e. adding disk 
>> timing parameters to
>> the NV RAM, if possible add a simple embedded debugger?) a Verilog or VHDL 
>> Z280 core,
>> perhaps taking T80 as the base. And if I really get the time, would like to 
>> make something like this,
>> so it could be plugged directly into the CPU280 CPU socket. and like Lamar I 
>> also have my own,
>> other niche project - a port of a multitasking, RSX-11M-like OS I wrote many 
>> years ago for the Z80
>> (now ported to the Z180). The PDP-11 always was my favorite machine, and the 
>> Z280 has many
>> PDP-ish features, including a similar MMU, so for me is an interesting hobby 
>> project.
>>
>>
>
I'd love to see source and to my eyes its the first really new OS on z80
family hardware
since the few from near the '80s.

I don't happen to have a P112 but versions for other hardware has me
interested.

I have S100 (Compupro, North*star, AmproLB+, SB180, BCC180, kaypros, and
more
than a few others.  Maybe I should crank a system using real late
version Z280s .

RSX (RT-11 and others) on PDP-11 is why I have a bunch of Qbus 11s as
they are
fairly small and friendly. 

Allison




Re: P112 runs RSX-11

2018-12-04 Thread allison via cctalk
On 12/04/2018 04:26 AM, David Griffith via cctalk wrote:
>
> I don't know who did it, but here's a video of a P112 running RSX:
> https://www.youtube.com/watch?v=5s6IOCCk3Uw
>
> If the creator of this thing is reading, I'd very much like to get my
> hands on RSX-180 and put it up on the P112 page at Sourceforge,
> Gitlab, et al.
>
>

I did find this here: https://en.everybodywiki.com/RSX-180

Allison


Re: N8vem and z80sbc

2018-12-03 Thread allison via cctalk
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: NVRAM resuscitation (Was Re: SPARCstation 20 with SCSI2SD)

2018-11-27 Thread allison via cctalk
On 11/27/2018 03:34 PM, Jeffrey S. Worley via cctalk wrote:
> When I bought that Sparcstation 4/330 at Computer Parts Barn, the 48T02
> was one of the problems with it.  The chip looks like a piggieback rom
> encapsulated in epoxy.
>
> I was not reinventing the wheel at the time, I think, because it was
> the year 2000 or so, but I looked for a replacement and found them hard
> to come by.  So, knowing the battery was most likely the fault, I went
> about fixing that bit.
>
> The battery accounts for the high profile.  You do not have to cut the
> entire doggone batter off, the terminals are at one side, iirc, the
> right-hand side if the notch is to your left.  It is high on the epoxy,
> so all you need do is cut down an eighth of an inch in that region,
> just shave that top edge until you expose the battery terminals.  I
> forget how I determined the polarity of them, perhaps I plugged it into
> the board after and tested the terminals for power, but all you do once
> you've exposed the terminals is solder a power and a ground wire to
> them and attach a 3volt battery.  I used a pack with two AA's, in a
> case so they are user-replaceable.  They are probably STILL keeping
> time in that machine, wherever DHS took it and my MEGA ST4 and DG
> MV4000/dc...  That's another story.
>
> So refurbishing these chips is a cakewalk, takes 15 minutes (the second
> time 'round), and will work til' doomsday.
>
> Best regards,
>
> Jeff
>
I take a very simple approach:


All the ones I've ever purchased were bad out of the box (NOS parts), so
much for china but they can be repaired too.

After removing it from the board...

I use a small magnet to locate the battery.  I use a sharp wood chisel
about .25 wide and carve the plastic down
to the battery then get under one edge.   Once metal is visible I clear
the plastic and pop it out.  The wires then
are easy to locate and I mount using Hot-melt glue a new holder for the
very common 2032.    Never had to
replace one of those and a few are pushing more than 12years.  The whole
mess takes less than a few minutes
to do where access the board and getting it off the board are the bigger
part of it.  Since I have a few NOS
(but dead) parts plus pulls from old CPU cards I rarely worry if the
existing one gets damaged as I have spares.
To me its not a big deal.

Allison



Re: TU58 tape formatter (was Re: rebuilding DC100A cartridges?)

2018-11-14 Thread allison via cctalk
On 11/14/2018 10:53 AM, Ethan Dicks via cctalk wrote:
> On Sat, Nov 24, 2012 at 4:08 AM Eric Smith  wrote:
>> I spent some time reverse-engineering the firmware.  There is only one
>> undocumented opcode, decimal 10, and I haven't yet figured out what it
>> does, but it definitely doesn't format a tape.
> I looked at the firmware disassemblies.  Opcode 10 appears to only
> point to code (vs NOP) on one version of the firmware
>
> https://gitlab.com/NF6X_Retrocomputing/tu58firmware/blob/master/disassembly/23-089e2.asm
>
> op_undoc_10:
> ldhl,l07e4
> calls06a
> lda,018h
> ld(r2003),a
> jpop_nop
>
> (I think the jump to op_nop is just there to handle regular opcode
> processing cleanup)
>
> I have TU58 drives in VAXen (11/750, 11/730, 11/725), a VT103, and one
> standalone unit that I pulled from an 11/725 that we bought to strip
> for parts to keep our 11/730 running.  I really haven't explored the
> differences in the firmware since mostly, I've used them as intended,
> for loading SA Backup, Microcode patches, and, of course, as Console
> Media to boot the 730 and 725.
>
> -ethan
Mine I use to boot a 11/23.  The code, I have both is functionally the
same for PDP11 use.
There are also two version of the TU58 board, one is serial IO (used for
most everything)
and a parallel version used in the PDT110 (I have one).  The parallel
one uses the same
bits and all to match the UART so the same code.  The parallel IO
hardware fakes the
uart framing error error (attention signal).  Very clever as the 8085
code is the same.

Both samples of disassembled code do not relate bits and ports in the
actual drive if they
did then it would be clearer what the code was doing.  The biggest thing
is it reads or
writes a 128byte section of a 512 byte block to tape without doing IO to
the host from
local ram as the CPU is fully consumed doing that. 

The actual TU58 system is 2K of Eprom,  8155 (256 bytes of ram and 8255
style of port
IO plus a timer), serial port and 8085.  So the core hardware outside of
the read amps
is pretty trivial.  It takes all of the available IO and most of the
interrupt pins plus SID/SOD
pins to implement it.  Its very IO intense for controlling the tape and
reading/writing it.

Best use for the code is extract the parts that do IO to the host (MRSP)
and make a dual
256Kbyte ram (or eprom if IPL for VAX) to replace the physical tape.

For 11/23 use I run a 512K ram board an it boots RT-11 XM copies it to
XD(ram disk)
and then boots it.  Takes about 7 minutes to boot but once there its
fairly fast save for
file IO to tape as seeks are very slow.  The version of a solid state
TU58 I have is not
much faster as the serial rate is the same but seeks are much faster.


Allison


Re: TU58 tape formatter (was Re: rebuilding DC100A cartridges?)

2018-11-13 Thread allison via cctalk
On 11/13/2018 03:46 PM, Ethan Dicks via cctalk wrote:
> On Sat, Nov 24, 2012 at 4:08 AM Eric Smith  wrote:
>>> It is remotely possible that there's an undocumented "format" command
>>> in the protocol.  However, I've heard multiple people claim that
>>> special firmware was required.
>> I spent some time reverse-engineering the firmware.  There is only one
>> undocumented opcode, decimal 10, and I haven't yet figured out what it
>> does, but it definitely doesn't format a tape.
> Is Opcode #10 the "Enter MRSP Mode" or is that something else?
>
> -ethan
Same here,

I asked while I was at DEC and the designer said need a special rig to
do that and the important
things was EOT and BOToptical sensors and the code with the basic
patterns.  The TU58 does not
have an EOT or BOT sensor as it detects end marks on the tape.

I think using disassembled code and adding the sensors its possible to
put down the marks needed.
Never explored it fully to prove that.  It was easier to make a
RAM-based TU58 work alike and at
least one company did a floppy based TU58 work alike.

Allison



Re: Datasheet for a NEC Chip in DEC Professional 350

2018-11-05 Thread allison via cctalk
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: 70's computers

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

My first stab was 74181 ALU based and was trying to do z80 faster than
4mhz... no hope there and
feature creep made it not z80.  I worked a little monitor to make it
useful but it gave me the core
understanding of CPU and how they work.   It was fun developing and
deciding I could change an
instruction to make coding easier.

I also did a simple machine based on a simplification of the basic
microcontroller of the RX01.
It had two instructions Jump CC and DO   It was more than enough to
be a Harvard machine
programmed at the microcode level.

I did those to bridge the college simple logic and sequential circuits
and their jump to programing
a computer with the bit in the middle missing.

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

As to chip based the list is [6100, 6120, 9900, 8080, 8085, 8086, z80,
1802, SC/MP, SC/MPII-8073,
6800, 6809, 6502, T-11] as they say long.   Some I still use namely
8039,  8085, z80, and 1802 and on
occasion the 6100 (cmos pdp8).  with older CPUs and newer memory the
resulting machines are
interesting and often fast for their type.  Things like large megabyte
Flash makes cp/m without physical
disk remarkably fast (large flash as disk) and simple.

I still run several CP/M machines (S100 and single board plus Kaypro
4/84++) and the PDP11 is mostly running
RT11 but on occasion I load up V6 Unix RL02 pack.  The vaxs are a small
(10way LAVC) mostly running
VMS5.4H.

> So, I managed to clone a Nat. Semi 32016 system and got it running,
> but it was amazingly slow.
> I suspect that my kluged memory interface was not fully optimal, but
> even the original that I copied was pretty slow.  Then, I spent BIG
> BUCKS to buy a uVAX-II CPU board from a broker, and was finally in HOG
> HEAVEN!  It was certainly fast, almost the speed of the VAX-780's I
> used at work, and ALL MINE!
>
I have the luxury of being there and leading edge for Altair by time 79
rolled around I was PDP11
and would later work in DEC engineering.  By the late 80s I had a nice
PDP11/23 of my own and
not long after a collection of VAX systems that I have to this day.  To
this day VMS is the OS in my
mind though Unix V6, V7(PDP11) and Ultrix(VAX) are around fro the DEC
hardware and Linux on
the desktop.

My idea of doing stuff is a Rpi-3B running a copy of linux on batteries
as a full boat laptop machine.
The Rpi may not be lightning in a bottle but its posting this email!  
What to I do for fun 8039,
PIC or Atmega328P for embedded projects.  One of these days a laptop
runnin

Re: 70's computers

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

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

There are very few CPUs that had serial insides. 

Allison


Re: 70's computers

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

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

Likely make a fortune off my stockpile of 2901s. 

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

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

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



Re: 70's computers

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

The 1802 is claimed to be serial.

Allison


Re: 70's computers

2018-10-24 Thread allison via cctalk
On 10/24/2018 09:19 AM, Paul Koning via cctalk wrote:
>
>> On Oct 23, 2018, at 7:08 PM, Noel Chiappa via cctalk  
>> wrote:
>>
>> ...
>> There was a recent discussion about code density (I forget whether here, or
>> on TUHS), and someone mentioned this paper:
>>
>>  http://web.eece.maine.edu/~vweaver/papers/iccd09/iccd09_density.pdf
>>
>> which shows that for a combo of benchmarks, the PDP-11 had the densest code
>> out of all the ones they looked at. (They didn't look at the PDP-8, but I
>> suspect that since it's a single-address design, it's almost ceertainly not
>> as dense.)
>>
>> The PDP-11 dates back to the days of core (it went through several 
>> generations
>> before DRAM arrived - e.g. the -11/70 originally shipped with core), and 
>> given
>> core prices, minimizing code size was pretty important - hence the results
>> above.
> What's interesting is that the paper uses compiled code.  The gcc back end 
> for pdp11 is still a work in progress and clearly doesn't deliver best 
> possible code, certainly not back then.
>
>   paul
>
I found that paper to be a not so interesting and more or less
pointless.  For many applications its what's on the
chip and rarely does it focus on architecture.  Engineers need to do
things or produce things that work
and  most of the time it comes down to whats available and price.  With
embedded machines the IO
capability and resident memory are likely deciding factors more so than
if its Harvard or Von, RISC
or CISC.   The other is the tool chain costs in, acquisition cost,  time
to learn, and apply.

Allison



Re: 70's computers

2018-10-24 Thread allison via cctalk
On 10/23/2018 05:32 PM, Gordon Henderson via cctalk wrote:
> On Tue, 23 Oct 2018, ben via cctalk wrote:
>
>> The PDP 11 is nice machine, but I am looking  for simpler designs
>> where 16K words is a valid memory size for a OS and small single user
>> software.
>
> Try the Modular One with an OS written in BCPL.
>
> https://www.cs.ox.ac.uk/files/3230/PRG08.pdf
>
> Although that paper suggest 32K of core.
>
> -Gordon

Why not the Data General Nova,  16bits and fairly simple.

Allison


Re: Selling keyboards without the terminal

2018-10-19 Thread allison via cctalk
On 10/19/2018 01:23 PM, Chuck Guzis via cctalk wrote:
> On 10/19/18 9:55 AM, ED SHARPE via cctalk wrote:
>> well i  have  some  clicky  keyboards and   yea  love the   feedback  clak  
>> when I type  but the   usual off the rack  frys    usb  thing is  
>> problematic 
> I've got a bunch of Model Ms scattered around here.  I remember when
> Surplus Software in Portland was selling the new surplus ones for
> something like $15 each.
>
> Personally, having learned to touch-type on a manual typewriter, I
> prefer the clickety sound.  IBM Wheelwriter typewriters used to drive me
> nuts due to the out-of-sync sound of the type hammer and the keypress.
>
> Those who learned to touch-type in the post-Selectric era probably don't
> have the problem.
>
> So, at least I have an excuse.  The model Ms work fine for me--I use one
> of the PCPlay-based USB keyboard+mouse adapters.  But then, I'm not a
> gamer...
>
> --Chuck
>
>
Me I had M keyboards in the day, thought they sucked!  Vt100 and VT220
early version
were my measure.  None of them made me type better!

For the last decade plus I've used the aluminum large and small USB
keyboard from Apple
on the various Linux boxes.  My only gripe is they are not double shot
keys so the letters
wear off after about  5-6 years.   Why did I buy it?  Reliable, coffee
resistant,  the only
thing that counts.

As to keyboard fetish fans... Seriously?   If I'd do anything I want
that brass and wood steampunk
piece of art like used in Werehouse 13,  least then I feel I got
something unusual and attractive.

Allison


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

2018-10-10 Thread allison via cctalk
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: Anyone know where uPD2167 SRAMs appeared?

2018-10-10 Thread allison via cctalk
On 10/09/2018 08:54 PM, Josh Dersch via cctalk wrote:
> On Tue, Oct 9, 2018 at 5:14 PM Ethan Dicks via cctalk 
> wrote:
>
>> Hi, All,
>>
>> I asked a version of this question earlier this year.  I have not been
>> able to find any vintage machines that used these 16Kx1 55ns SRAMs.
>> Anyone recognize them?  Lots of them for sale on eBay.  Probably few
>> buyers.  One would want to know which systems used them, thus my
>> question.
The uPD2167(16Kx1) and 2147 (4kx4) rams appeared in 1981, I was at NEC then.
They were offered as 65/55/45ns and for the time that was faster than
most static and dynamic parts.

>> They probably would have been excellent in a DEC MOS memory board but
>> I have no evidence they were used thusly.  Contemporary DRAMs were
>> cheap and 64Kx1 so that's what was in consumer gear.
>>
>> Anyone?  Fast SRAM?  Anywhere?
>>
> The Three Rivers PERQ used 48 of them for microcode store in the 16K CPU,
> and on the Z80-based IO Processor.  (I suspect the IO Processor didn't need
> RAMs quite that fast, but 3RCC probably had a lot of them on hand due to
> their use in the main CPU...)
>
> - Josh

Popular use was memory planes for high speed graphics and cache for some
minis.
At that time and for a good while there were no micros that pushed the
speed needs
that hard even 12mhz 8086 in the mid 80s.
>> There's little point in wiring 8 of them up into a byte vs using a
>> 62256 except for speed.  55ns is faster than any 8MHz machine really
>> needs (100ns-150ns was typical for those depending on bus
>> architecture).  I could see these being cache RAM for a minicomputer
>> vs primary RAM.
>>
>> -ethan
>>

I used them for a fast cull of 10mhz Z80 without wait states.  While an
8mhz z80 machine has
limited need when you add buffering and propagation delays you do need
to be under 100ns
for margin.  At 10mhz you have to be under 85ns.

Also back then the largest byte wide was 2116/6116 (2kx8) and they were
fast at maybe 200ns.
The 62256 was later and early parts were barely 150ns.  Now finding
parts that slow is a challenge.
The need for external cache for 386 and 486 based machines drove it way
down such that 15-25ns
static CMOS (mid to late 1990s) became easy to find.

Allison


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

2018-10-07 Thread allison via cctalk
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


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

2018-10-07 Thread allison via cctalk
Group,

I have one of these TEAC Phillips tape drives.  I have a manual:

Is tape (media) available for it?

What was it typically used in?

How much storage was it?

I was digging for some paerts and found it in my collection.  I know of
no system
I have that used it but someone must have done a "Here, maybe you can
use it!".

Allison



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

2018-09-21 Thread allison via cctalk
On 09/21/2018 12:19 PM, Eric Smith via cctalk wrote:
> On Fri, Sep 21, 2018 at 6:04 AM, Bill Gunshannon via cctalk <
> cctalk@classiccmp.org> wrote:
>
>> Or just throw it in the garbage.
>
> That's way too good for these 

Re: Unknown US manufacturer - try again

2018-09-12 Thread allison via cctalk
On 09/12/2018 06:03 PM, jim stephens via cctalk wrote:
>
>
> On 9/12/2018 10:59 AM, Peter Van Peborgh via cctalk wrote:
>> Guys,
>>
>> See these photos:
>>
>> https://scontent.flhr2-2.fna.fbcdn.net/v/t1.0-9/35682272_10216634445119982_2
>>
>> 53889771863015424_n.jpg?_nc_cat=0=74459af2e9232dd433046b2a9d43dedd=5BC
>>
>> F55A0
>>
>> and
>>
>> https://scontent.flhr2-2.fna.fbcdn.net/v/t1.0-9/36244235_10216691120256825_4
>>
>> 287682979926376448_n.jpg?_nc_cat=0=e8ab72feb9eb1cf311c7ef0546318e44=5C
>>
>> 1358C6
>>
> Found in a 1965 manufacturer's volume on Bitsavers.  Used Kelly
> Leavitt's reference.  looks like they
> had some products up thru 1974,  but dropped this most likely.
>
> This system of products would have been competitive with the DEC Flip
> Chip concept of the early 60s,
> and there were a lot of players.  (see others in the 1965
> manufacturers reference).
>
> This shows reference info, category, and page it was located in the
> PDF / document.
>
> http://www.bitsavers.org/pdf/computersAndAutomation/196506.pdf
>
>
>
> Roster of Organizations:
>
> Control Logic, Inc., 3 Strathmore Rd., Natick, Mass
>   01762 / 617-655-1170 / *C 65
>    Welded digital circuit modules; data and con-
>    trol systems; digital training systems / S 70
>    / E 1961
> page 15 (of document and pdf
>
> C11. CIRCUITS, LOGICAL (FOR DIGITAL COMPUTERS)
>
> Control Logic, Inc., 3 Strathmore
>   Rd., Natick, Mass. 01762 /
>   digital circuit cards and
>   welded modules / DESCR: welded
>   encapsulated digital circuit
>   modules, open circuit and
>   module cards. Germanium and
>   silicon circuits, DC to 50 MC
>   / - / $5.50 per flipflop to
>   $90 per flipflop / Cll
>
> page 30
>
> C24. COMPUTERS, DIGITAL
>   see C24A
>
> page 32
>
> C24A. COMPUTERS, SPECIAL PURPOSE
>
> Control Logic, Inc., 3 Strathmore
>   Rd., Natick, Mass. 01762 /
>   digital systems / DESCR: special
>   purpose digital data handling,
>   measurement and control systems
>   /-/-/ C24A
>
> page 33
>
> C26. COMPUTER COMPONENTS
>    see C24A
>
> page 33
>
> C30. CONSULTING SERVICES (see also
>  "Survey of Consulting Services")
>    see C24A
>
> page 34
>
> C31. CONTROLS
>    see C24A
>
> page 35
>
> C33. CONTROLS, SIGNALLING
>    see C24A
>
>   page 35
>
> C34. CONTROLS, SORTING AND COUNTING
>    see C24A
>
> page 35
>
> C39. CONVERTERS, INFORMATION
>    see C24A
>
> page 36
>
> C53. COUNTERS
>    see C24A
>
> page 36
>
> El. EDUCATION
>    see C24A
>
> page 38
>
> G2. GENERATORS, FUNCTION, ELECTRONIC
>    see C24A
>
> page 39
>
> P2. PANELS, JACK
>     see C24A
>
> page 40
>
> Rll. REGISTERS, SHIFT
>
> Control Logic, Inc. --see Cll
>   and C24A
>
> page 43
>
>
>
> COMPUTERS and AUTOMATION for JUNE, 1965 

Small world,

Built a 8008 system for a company I was with back in early 74 using
their board set
and backplane. 

Allison





Re: VT100's

2018-09-06 Thread allison via cctalk
On 09/06/2018 12:54 PM, Al Kossow via cctalk wrote:
>
> On 9/6/18 9:48 AM, Paul Koning via cctalk wrote:
>> VT50 seems like it was someone's mistake -- 12 lines, what were they 
>> thinking?
>
Mostly about screen memory which back then was small and not cheap.


Allison


Re: VAX 11/785 "Superstar" Backplanes

2018-09-05 Thread allison via cctalk
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: CESI VM8128 PDP8-A 128 K MOS?

2018-08-24 Thread allison via cctalk
On 08/24/2018 07:06 AM, Rod G8DGR via cctalk wrote:
> M8417 MSC8DJ PDP8A 128K MOS 
>
> Clone of this
>
>
>
> Sent from Mail for Windows 10
>
> From: Paul Anderson via cctalk
> Sent: 24 August 2018 10:12
> To: General Discussion: On-Topic and Off-Topic Posts; cct...@vax-11.org
> Subject: CESI VM8128 PDP8-A 128 K MOS?
>
> I have an idea what this might be, but I can't find anything to confirm it
> on line. Can anyone shine some light on it?
>
> Thanks, Paul
>
its a 128 memory card If memory is right hex width for PDP-8A... The
last of the omnibus 8s.
That machine had extended the MMU used in earlier PDP-8 from 3 EMA lines
to 5.
Only fits the 8A chassis.

Allison


  1   2   3   >