Re: General Question about UNIBUS backplanes

[william degnan]

Paul,
What terminator card exactly?  As I had written originally, the system was
functional before I added the core planes.  I was thinking that I needed a
terminator now that I have more than just the cpu plus four slot plane, but
I did not have the space for it along with all of the cards I already have
installed.

http://vintagecomputer.net/digital/pdp11-40/card-layout_moved-plane_Pic2.JPG
(I removed the grant cards from the core planes per Tony's suggestion.)


-- 
@ BillDeg:
Web: vintagecomputer.net
Twitter: @billdeg 
Youtube: @billdeg 
Unauthorized Bio 

Re: General Question about UNIBUS backplanes

[Paul Anderson]

An M930 terminator in the far left slot in A/B, where you have the RL11
(M7762). I don't remember if the G7273 is a unibus or q-bus grant card. I
always use the G727 , I think, the little 2 inch by 2 inch or so.

Try front panel funstions with the RL11 out.  You'll probably have to move
it to slot 3.

There is a trick to using a M9301 or m9312  in an 11/40, but I don't
remember it now.  It's been a while since since I've played with an 11/40.

On Sun, May 22, 2016 at 6:07 PM, william degnan 
wrote:

> Paul,
> What terminator card exactly?  As I had written originally, the system was
> functional before I added the core planes.  I was thinking that I needed a
> terminator now that I have more than just the cpu plus four slot plane, but
> I did not have the space for it along with all of the cards I already have
> installed.
>
>
> http://vintagecomputer.net/digital/pdp11-40/card-layout_moved-plane_Pic2.JPG
> (I removed the grant cards from the core planes per Tony's suggestion.)
>
>
> --
> @ BillDeg:
> Web: vintagecomputer.net
> Twitter: @billdeg 
> Youtube: @billdeg 
> Unauthorized Bio 
>

Re: ND-10 software - Re: Harris H800 Computer

[Chuck Guzis]

On 05/22/2016 07:30 PM, Tor Arntsen wrote:

> Chuck, the problem with IMDU is that it's an ms-dos program and 
> Torfinn hasn't yet found a working emulator for his BSD setup. I'm 
> sure there is one. But it's very inconvenient to have to go through 
> MSDOS for this, so Al's suggestion of the imd2raw tool from
> Convergent is very welcome! I have just tested it and it works fine.
> Built on 64-bit Linux. I'll make it easy to batch-process all those
> images. (And it contains a simple documentation of the IMD format, I
> may be blind but I could not find any the last time I went through
> this or I would have written my own tool). (NB: Had to change
> 'convergent' to 'Convergent' in that URL to find it).

IMDU runs fine on DOSEMU; I've tried it on OpenBSD as well as 64 bit
Ubuntu (trusty).  I know that there's also a version for NetBSD, but I
haven't tried it.  Since IMDU is basically a file processor, the I/O
requirements aren't strange.

I still do a lot of DOS work on my Linux boxes.

--Chuck

Re: ND-10 software - Re: Harris H800 Computer

[Tor Arntsen]

On 21 May 2016 at 18:38, Mattis Lind  wrote:

> I have now added some 80 more floppies to download if you would like to
> check.
>
> http://www.datormuseum.se/documentation-software/norsk-data-floppy-disks

Thanks Mattis!
Downloaded. I will go through them soon.

Chuck, the problem with IMDU is that it's an ms-dos program and
Torfinn hasn't yet found a working emulator for his BSD setup. I'm
sure there is one. But it's very inconvenient to have to go through
MSDOS for this, so Al's suggestion of the imd2raw tool from Convergent
is very welcome! I have just tested it and it works fine. Built on
64-bit Linux. I'll make it easy to batch-process all those images.
(And it contains a simple documentation of the IMD format, I may be
blind but I could not find any the last time I went through this or I
would have written my own tool).
(NB: Had to change 'convergent' to 'Convergent' in that URL to find it).

-Tor

Re: strangest systems I've sent email from

[Mouse]

>>>  Why bother?  Won't:
>>> size_t foo = ~0UL;
>>> do (~0ULL for C99)?

>> Only if size_t is no larger than unsigned long int (unsigned long
>> long int for the ULL version).  I don't think that's guaranteed.

> How can you have the type of `size_t' wider than the widest unsigned
> integer type in the respective revision of the language standard?

unsigned long long int isn't necessarily the largest integral type.
Nor do I see anything requiring size_t to be no larger than it.

uintmax_t, on the other hand, would be fine; it _is_ promised to be no
smaller than size_t (or any other unsigned integral type).

size_t foo = ~(uintmax_t)0;

should work fine to set foo to all-bits-set.  (Since size_t is
unsigned, this will set it to be its largest possible value.)

I think uintmax_t is another blemish in the standard, since it makes
certain kinds of innovation impossible.  (For example, the presence of
uintmax_t makes it impossible to extend the compiler to recognize
uintXX_t as "unsigned integer type with at least XX bits" for all XX,
presumably with library support for integers over hardware-supported
sizes.  At least without no longer, strictly, being a C compiler.)

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

Re: General Question about UNIBUS backplanes

[Noel Chiappa]

> From: Bill Degnan

> So I decided to insert two 32K core memory backplanes

32KW, those would be MM11-U backplanes, right?

> My plan is to replace the solid-state RAM card with core, and this will
> free up a slot on the 4-slot backplane for a terminator.

Terminators all only go in the last slot of the last backplane anyway (either
that, or a UNIBUS 'out' cable), so adding extra backplanes shouldn't give you
"a slot .. for a terminator".

Also, Paul's point is a good one: the hex memory cards need so-called 'MUD
slots' (hex), not SPC slots (quad), and only (IIRC) the DD11-C/D have MUD
slots. (Those came in with the 11/04-34, IIRC).

> the serial card seems to have stopped working. It appears that the
> console program is being loaded and runs from the M9312 but nothing is
> appearing on the terminal. I cannot send an "A" to the terminal, the
> most basic test I can think of.

Hmm. You can read/write the console registers from the console, though, it
sounds like? My guess would be that if your serial port is EIA, somehow
you're missing -15V or something on the DD11 in its new location. Study the
-11/35-40 system manual to learn about which 'bricks' supply which voltages
to which system units.

And while you're at it, check that you have the right 'bricks' for the MM11-U.
The -11/35-40 system manual has lots of text on how to support the MM11-U.

> Can you only use the core backplanes for core memory (assume yes), or
> are they capable of holding other types of cards temporarily? 

AFAICR, the MM11-U backplane does _not_ have an SPC slot in it. IIRC, the
16KW MM11-U board set is a quad controller board, and 3 hex boards (core, X-Y
and something else). So two sets (the backplane holds two) would be 8, so one
empty slot - which IIRC is blank. Check the MM11-U manual, it's available.

> I have one slot that needs the npg, it's in place.

??? _Every_ SPC/MUD slot which does not have a DMA device in it _must_ have
the jumper on the backplane (or the _double_ width UNIBUS grant card, whose
number escapes my memory, which contains a NPG jumper). Not sure if that
was the import of what you wrote there.

Noel

Re: Tektronix 4404 servcie manuals needed

[Al Kossow]

On 5/22/16 4:57 PM, Al Kossow wrote:

> If someone has the scsi storage box, dumping the 6502 floppy eprom would be 
> really
> helpful (and maybe taking some pictures of the board).
> 

turns out that one was good. the Adaptec 4000 dump was the bad one

Re: strangest systems I've sent email from

[Chris Hanson]

On May 22, 2016, at 6:09 AM, Mouse  wrote:
> 
> I've often thought about building a C implementation that goes out of
> its way to break assumptions like "integers are two's complement with
> no padding bits" or "floats are IEEE" or "nil pointers are all-bits-0"
> or "all pointers are the same size and representation" or etc.

Just use Symbolics C on a Symbolics or ZetaC on a TI Explorer. (ZetaC was 
recently put in the Public Domain by its author, so you can take a look at how 
it was implemented.) Both of them I believe implemented C89.

There’s also someone writing a C to Common Lisp translator that takes some of 
the same approaches as those compilers:  
Something like that would make it possible to pull C code into a project like 
Mezzano.

(Another approach would be to write an LLVM back-end that generates Common Lisp 
using the same approach as ZetaC, and port clang to it.)

  -- Chris

Re: General Question about UNIBUS backplanes

[william degnan]

On May 22, 2016 1:22 PM, "Mark Darvill"  wrote:
>
> The core memory/CPU backplane is a special case and doesn’t need grant
cards.
>
> If you have linked up to the expansion Unibus then you need to check you
have the NPG jumper in row C, Pins A1 and B1 in each slot. If these do not
have wire wrap then you will either need to wire wrap them or insert a G727
into the backplane slot. Without these the units will hang on attempting to
use a card that requires DMA access.
>
> Hope this helps.
>
> Mark
>

Thanks Mark..yes I have one slot that needs the npg, it's in place.

I have not had a chance to test with grant cards removed hope that does the
trick

Re: General Question about UNIBUS backplanes

[Paul Anderson]

Hi William,

If I follow right, you have gotten some great advice,,but I'm not sure
about a few things.

Is your 4 slot SPC a DD11-A, DD11-B, or DD11-CK/CF?  The standard one used
in most 1140s is the DD11-B, and a lot had DD11-Cs added later. The DD11-B
will not work with the RL11  and probably not with the MOS board.

The last slot of the the Unibus should have a terminator in A/B.

I don't know how well you know the 11/40, but most cpu options require
jumper changes on various cpu boards. These can can weird problems also.
You can take out the options, M7236, 37, 38, 38, and M787, reset the
jumpers, then put them back in when everything else works.

Shortening the bus is also helpful when troubleshooting.

PDP 11/40s are great! Good luck and have fun!

Paul

On Sun, May 22, 2016 at 1:19 PM, william degnan 
wrote:

> On May 22, 2016 1:22 PM, "Mark Darvill"  wrote:
> >
> > The core memory/CPU backplane is a special case and doesn’t need grant
> cards.
> >
> > If you have linked up to the expansion Unibus then you need to check you
> have the NPG jumper in row C, Pins A1 and B1 in each slot. If these do not
> have wire wrap then you will either need to wire wrap them or insert a G727
> into the backplane slot. Without these the units will hang on attempting to
> use a card that requires DMA access.
> >
> > Hope this helps.
> >
> > Mark
> >
>
> Thanks Mark..yes I have one slot that needs the npg, it's in place.
>
> I have not had a chance to test with grant cards removed hope that does the
> trick
>

Re: General Question about UNIBUS backplanes

[Mark Darvill]

The core memory/CPU backplane is a special case and doesn’t need grant cards.

If you have linked up to the expansion Unibus then you need to check you have 
the NPG jumper in row C, Pins A1 and B1 in each slot. If these do not have wire 
wrap then you will either need to wire wrap them or insert a G727 into the 
backplane slot. Without these the units will hang on attempting to use a card 
that requires DMA access.

Hope this helps.

Mark

> On 22 May 2016, at 18:10, tony duell  wrote:
> 
> 
>> Are you saying remove all of the GC cards, just leave the slots blank?
> 
> Yes, from the slots that are designed to take the core memory or its
> controllers (I assume, given you have special backplanes, there are 
> boards with the core planes on, and more boards with the XY drivers
> or the sense/inhibit logic on). 
> 
> Do you have a diagram of where the core boards should go. If so, are
> there slots in the backplane left over. What are those 'extra' 
> slots for?
> 
> -tony

RE: General Question about UNIBUS backplanes

[tony duell]

> Are you saying remove all of the GC cards, just leave the slots blank?

Yes, from the slots that are designed to take the core memory or its
controllers (I assume, given you have special backplanes, there are 
boards with the core planes on, and more boards with the XY drivers
or the sense/inhibit logic on). 

Do you have a diagram of where the core boards should go. If so, are
there slots in the backplane left over. What are those 'extra' 
slots for?

-tony

Re: General Question about UNIBUS backplanes

[william degnan]

On Sun, May 22, 2016 at 1:10 PM, tony duell  wrote:

>
> > Are you saying remove all of the GC cards, just leave the slots blank?
>
> Yes, from the slots that are designed to take the core memory or its
> controllers (I assume, given you have special backplanes, there are
> boards with the core planes on, and more boards with the XY drivers
> or the sense/inhibit logic on).
>
> Do you have a diagram of where the core boards should go. If so, are
> there slots in the backplane left over. What are those 'extra'
> slots for?
>
> -tony
>


I have core memory cards that fill these backplanes from another system.  I
removed the cards, kept them sorted for re-insertion after I get the
backplanes communicating properly.  So, this is just a temporary set up.

I wanted to migrate the core to a different 11/40 because I have the CPU
and power supply tested and working.  By eliminating power and CPU
variables I can troubleshoot just the core cards one at a time.  I have a
few core cards that work so I will be able to work through the unknowns in
this system.The system they came from needs power supply work, etc.
Too many things to try to fix all at once.

Thanks for the help.

-- 
@ BillDeg:
Web: vintagecomputer.net
Twitter: @billdeg 
Youtube: @billdeg 
Unauthorized Bio 

Re: General Question about UNIBUS backplanes

[william degnan]

On Sun, May 22, 2016 at 12:33 PM, tony duell 
wrote:

> Strictly the core backplanes are not Unibus backplanes. They have Unibus In
> and Out connectors, but the slots are wired for the core memory board,
> not Unibus boards (like SPCs -- Small Peripheral Controllers -- which is
> what
> you serial port is).
>
> > Basic Question #1
> > Do I need grant cards in *every* empty slot of the core backplane,
> > including the end slots with the M920's?
>
> No. In fact in most cases it is wrong to put grant continuity cards in
> there.
> However in a lot of cases a special backplane (like your core memory
> one) will have some spare slots (perhaps the core memory doesn't take
> up all 9 slots). And DEC often (but not always) wired those so you could
> put SPCs in there. In which case you will need grant continuity cards in
> those
> slots if you have nothing else in them.
>
>
Tony,
Are you saying remove all of the GC cards, just leave the slots blank?

Here is a photo of what I have now:

http://vintagecomputer.net/digital/pdp11-40/coreplanes_installed.jpg

remove the gc cards from the core planes?  I will read up on this more,
just getting started.

thanks.

Bill

RE: General Question about UNIBUS backplanes

[tony duell]

Strictly the core backplanes are not Unibus backplanes. They have Unibus In
and Out connectors, but the slots are wired for the core memory board,
not Unibus boards (like SPCs -- Small Peripheral Controllers -- which is what
you serial port is).

> Basic Question #1
> Do I need grant cards in *every* empty slot of the core backplane,
> including the end slots with the M920's?

No. In fact in most cases it is wrong to put grant continuity cards in there.
However in a lot of cases a special backplane (like your core memory
one) will have some spare slots (perhaps the core memory doesn't take
up all 9 slots). And DEC often (but not always) wired those so you could
put SPCs in there. In which case you will need grant continuity cards in those
slots if you have nothing else in them.

> Basic Question #2
> Can you only use the core backplanes for core memory (assume yes), or are
> they capable of holding other types of cards temporarily? (yes/no/maybe)

See above. The slots for the core memory and controller cards are special and
can only take those cards. But you might have normal SPC slots on the same
backplane. 

You need to find the 'module utilisation chart' for that core memory backplane.
Be warned that DEC normally drew these looking at the _wire side_ of the 
backplane, not the side where the PCBs go!

-tony

General Question about UNIBUS backplanes

[william degnan]

Background - I have a PDP 11/40 that came to me with a CPU backplane and a
general purpose 4 slot peripheral backplane.  The CPU backplane came to me
connected to the 4 slot via a std 11/40 M981.  In the 4-slot I have I have
a working 64K solid-state RAM card, M7856 serial card, M9312
bootstrap/console card, and an RL02 drive controller.I can access RAM
from the console, run the console program (monitor program) off the M9312
through the serial card.  I can't boot yet off the RL02 and I am thinking
this is due to a termination issue, not sure yet.  I decided I need more
backplane to go any farther.

So I decided to insert two 32K core memory backplanes in between the
original two backplanes that came with the system.  My plan is to replace
the solid-state RAM card with core, and this will free up a slot on the
4-slot backplane for a terminator.  Am I correct in my logic?

I have connected the "new" backplanes using M920's.  Imagine the original
system with a core backplane wedged in the middle.  Power seems fine, DC LO
AC LO fine.

Right now there is nothing in the core backplanes, First I want to verify
that I have them arrayed correctly and that I can still communicate with
the (now) 4th backplane in the back.  I can run "chase the lights" from the
console but the serial card seems to have stopped working.  It appears that
the console program is being loaded and runs from the M9312 but nothing is
appearing on the terminal.  I cannot send an "A" to the terminal, the most
basic test I can think of.

Could be the the M7856 card decided to die on me just now, or something
else is wrong.  Does anyone have a PDP 11 /05/10/35/40 and have
experimented about what you can and can't do with backplanes?

I know that there are a lot of variables here, so I'd like to start with
the basics

Basic Question #1
Do I need grant cards in *every* empty slot of the core backplane,
including the end slots with the M920's?
Basic Question #2
Can you only use the core backplanes for core memory (assume yes), or are
they capable of holding other types of cards temporarily? (yes/no/maybe)

I am researching the system config on my own, but I thought if anyone had
any advice I'd love to hear it, make troubleshooting a little easier.

I have read up on the subject:
http://retrocmp.com/how-tos/setup-a-pdp-11-unibus-backplane
https://trmm.net/PDP-11

I see this is not a simple little thing.  Working to find more GC cards now.

Thanks

b

-- 
@ BillDeg:
Web: vintagecomputer.net
Twitter: @billdeg 
Youtube: @billdeg 
Unauthorized Bio 

Re: strangest systems I've sent email from

[Maciej W. Rozycki]

On Sun, 22 May 2016, Mouse wrote:

>    size_t foo = (size_t)-1;
> >>>size_t foo = -(size_t)1;
> >> size_t foo = (size_t)(-1);
> >  Why bother?  Won't:
> > size_t foo = ~0UL;
> > do (~0ULL for C99)?
> 
> Only if size_t is no larger than unsigned long int (unsigned long long
> int for the ULL version).  I don't think that's guaranteed.

 How can you have the type of `size_t' wider than the widest unsigned 
integer type in the respective revision of the language standard?

  Maciej

Re: strangest systems I've sent email from

[Mouse]

   size_t foo = (size_t)-1;
>>>size_t foo = -(size_t)1;
>> size_t foo = (size_t)(-1);
>  Why bother?  Won't:
>   size_t foo = ~0UL;
> do (~0ULL for C99)?

Only if size_t is no larger than unsigned long int (unsigned long long
int for the ULL version).  I don't think that's guaranteed.

Mouse

Re: strangest systems I've sent email from

[Eric Christopherson]

On Sun, May 22, 2016, Mouse wrote:
> >> Also, PostScript has a lot of language syntax, whereas FORTH has
> >> immediate words that act like language syntax.  (The difference is
> >> that FORTH makes it possible to change those words, thereby changing
> >> the apparent syntax.)
> > What do you mean by that?
> 
> Consider a simple definition
> 
> : foo swap - ;  ( inverted subtraction )
> /foo { exch sub } def  % inverted subtraction
> 
> (The first is FORTH[%], the second PostScript.)  Each of these has some
> "syntax" bits.  In FORTH, :, ;, (, and ).  In PostScript, the leading
> /, {, }, and %.

Interesting. I thought { } were just plain old words, but I'll at least
concede the rest.

> The difference is that in FORTH, you can create new immediate words
> and/or redefine the existing ones; : can do something other than
> beginning the definition of a word, and you can arrange to begin the
> definition of a word with something other than :.  In PostScript, none
> of this is mutable short of hacking on the underlying implementation
> (and if you do that the result isn't PostScript any longer).
> 
> [%] I think.  I don't really know FORTH; does it use - for subtraction?
> 
> /~\ The ASCII   Mouse
> \ / Ribbon Campaign
>  X  Against HTML  mo...@rodents-montreal.org
> / \ Email! 7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B

-- 
Eric Christopherson

Re: HP Draftmaster II 7596A: EPROM dumps needed, urgent :-(

[John Robertson]

On 05/21/2016 10:53 PM, David Collins wrote:

Martin, I might be able to help you as I think we have a 7596A.

Are these EPROMs from the processor PCA?  Are you able to tell me which 'U'
numbers they are in the PC board?

I haven't looked at the plotter itself, but the service manual we have shows
the following part numbers for the processor PCA

07595-18039
07595-18040
07595-18041
07595-18042

So I'm not sure if my manual is old and the plotters at that time had 4
EPROMs and yours is newer and has 2? Or are they on another PCA somewhere?

Let me know.

If the plotter we have is in the main museum facility I can possibly help
you, I will check.

David Collins
Curator
HP Computer Museum.


If your version has four EPROMs and the later (otherwise identical) 
machine only used two then chances are the four earlier EPROMs were 
simply combined into two later ones. For example, if the original EPROMs 
were 2708s then two of those would fit into a single 2716. The 2716 was 
easier to program as well being only a single voltage device.


Combining the images is easy as well. The first 2708 image goes from 
000h to 3FFh and the second would go from 400h to 7FFh, as a 2716 holds 
000h to 7FFh worth of data vs. 000h to 3FFh for the older 2708.


Of course this would also work for 2716s into 2732s, etc. just the data 
boundaries change to reflect the device size.


John :-#)#

-Original Message-
From: cctalk [mailto:cctalk-boun...@classiccmp.org] On Behalf Of Martin
Peters
Sent: Sunday, 22 May 2016 7:21 AM
To: cctalk@classiccmp.org
Subject: HP Draftmaster II 7596A: EPROM dumps needed, urgent :-(

Hello,

the EPROMs are labeled 07595-18045 and 07595-18046.

Can anyone do a dump for me? It's really urgent. Our local hackerspace wants
to get rid of it, if there is no chance to get the Firmware again.

greetings,
Martin





--
John's Jukes Ltd. 2343 Main St., Vancouver, BC, Canada V5T 3C9
Call (604)872-5757 or Fax 872-2010 (Pinballs, Jukes, VideoGames)
 www.flippers.com
"Old pinballers never die, they just flip out"

Re: HP Draftmaster II 7596A: EPROM dumps needed, urgent :-(

[Martin Peters]

Hi David!

David Collins:
> Martin, I might be able to help you as I think we have a 7596A.

Great! :)

> Are these EPROMs from the processor PCA?

I think so.

> Are you able to tell me which 'U'
> numbers they are in the PC board? 

No, not now. The plotter is in the shackspace in Stuttgart and I was not
there for several weeks and now I found an email saying they want to get
rid of it. I already asked for the dumps here one year ago and now it
seems to be really urgent.

> I haven't looked at the plotter itself, but the service manual we have shows
> the following part numbers for the processor PCA 
> 
> 07595-18039
> 07595-18040
> 07595-18041
> 07595-18042

I know. As I was told by the guy who took a look inside one year ago,
these parts do not exist in the revision we own. But I think, they only
put the firmware in two EPROMs at HP in a newer revision of the board.
And if not "only", I think the dumps would be helpful anyway. It would
be great if you could do a dump for me :-)

Many thanks,
Martin
-- 
Martin Peters
mar...@shackspace.de

Re: 'Inside Macintosh' books

[Santo Nucifora]

Related to the early promotional Inside Macintosh phonebook edition, last
week I scanned the documentation for two versions of the MacSupplement
documentation.  I have not seen this posted anywhere else so please feel
free to store these in a central documentation archive.  I got this
documentation plus the Inside Macintosh phonebook edition along with some
of the original diskettes just recently from an early developer.

The February 1985 set appears to be before the Inside Macintosh printing.
The May 1985 set is after. Some of the original diskettes are also posted
here:   http://vintagecomputer.ca/files-area/apple/macintosh/developer/#

If anyone has any earlier editions (was there only one prior to February
1985?) or has/knows where the diskettes may be imaged, I'd love to fill in
the set.  Some of my diskettes may  have been overwritten but they are in
DC42 format so the diskettes can be reproduced.

Hope someone finds this of interest.
Santo

On Wed, May 18, 2016 at 4:45 PM, Toby Thain 
wrote:

> On 2016-05-18 2:02 PM, Ethan Dicks wrote:
>
>> On Wed, May 18, 2016 at 1:39 PM, Chris Hanson
>>  wrote:
>>
>>> For the original “Inside Macintosh,” there was:
>>>
>>> 1. The prerelease looseleaf edition, sent to developers.
>>>
>>
>> I remember leafing through that edition in the summer of 1984 and
>> being horrified at all the Pascal-isms.
>>
>
> I still have a copy. Most pages are dated 1983 iirc.
>
> It's entirely Pascal oriented, indeed. :-)
>
> --Toby
>
>
>
>> -ethan
>>
>>
>

Re: ND-10 software - Re: Harris H800 Computer

[Chuck Guzis]

On 05/22/2016 11:36 AM, Al Kossow wrote:
> 
> 
> On 5/22/16 4:52 AM, Torfinn Ingolfsen wrote:
> 
>> Now I just need to find a tool that converts IMD to raw format and 
>> runs on FreeBSD.
> 
> http://bitsavers.org/bits/convergent/ngen/imd2raw may be adequate.
> There may also be other versions around that people have squashed
> bugs in it.

Dave Dunfield's IMDU /B will work just fine.

--Chuck

Re: ND-10 software - Re: Harris H800 Computer

[Al Kossow]

On 5/22/16 4:52 AM, Torfinn Ingolfsen wrote:

> Now I just need to find a tool that converts IMD to raw format and
> runs on FreeBSD.

http://bitsavers.org/bits/convergent/ngen/imd2raw
may be adequate. There may also be other versions around
that people have squashed bugs in it.

Re: Hamvention

[Jerry Weiss]

Sorry, I didn’t ask on this one.  It looked like a well used/loved machine with 
some wear and customizations to the front panel

Jerry

> On May 22, 2016, at 9:51 AM, Bill Sudbrink  wrote:
> 
> Jerry Weiss wrote:
>> I saw one Altair 8800
> 
> I haven't seen an Altair at a hamfest in this century.
> Out of curiosity, what was the seller asking?
> 
> Bill S.
> 
> 

RE: VGA Error Code from DECpc AXP 150 (Jensen)

[Robert Jarratt]

> -Original Message-
> From: cctalk [mailto:cctalk-boun...@classiccmp.org] On Behalf Of Robert
> Jarratt
> Sent: 22 May 2016 17:02
> To: 'General Discussion: On-Topic and Off-Topic Posts'
> 
> Subject: RE: VGA Error Code from DECpc AXP 150 (Jensen)
> 
> I think I have found the problem, when I took the card out to change its
slot, I
> found there were some corroded pins on one of the chips (looks like
> memory). It looks like battery leakage damage, but the odd thing is that
it is
> nowhere near a battery. Cleaning it up now to see if that will fix it.
> 


Sadly, the cleanup did not work. Moving to another slot, just in case it
made a difference, didn't help :-(

Looks like I may have to replace the card :-(

Regards

Rob

Re: 1's comp

[Chuck Guzis]

On 05/22/2016 06:23 AM, Toby Thain wrote:

> I didn't mean performance - I meant programmer effort to ensure 
> robust/correct code. The Grishman book didn't reassure me, but thanks
> for the additional info.

Well, if you consider it carefully, does zero really have a sign?  So,
the convention of considering 0 to be a positive value is, in a sense,
illogical.  But no, I don't recall that the issue of -0 ever raised much
of a problem in either CP or PP code.

I've long wondered if the abandonment of ones' complement arithmetic on
modern ISAs was more due to the requirement that ones; comp requires an
end-around carry, where two's comp does not.

--Chuck

Re: strangest systems I've sent email from

[Maciej W. Rozycki]

On Sun, 22 May 2016, Guy Dawson wrote:

> >> I'm not even sure
> >
> >>   size_t foo = (size_t)-1;
> >
> >> is legal,
> >
> > In C++, I don't know.  In C, I'm fairly sure it's legal.
> >
> >> or even does what I expect it to do (namely---set foo to the largest
> >> size_t value possible (pre C99).
> >
> > I'm not sure it does that.  If you want that, I think you want
> >
> >size_t foo = -(size_t)1;
> 
> While I think that
> 
> size_t foo = (size_t)(-1);
> 
> is what C would interpret as being meant. What the size of the thing that
> by default, in this implementation, -1 would be stored in.

 Why bother?  Won't:

size_t foo = ~0UL;

do (~0ULL for C99)?  Or is it just an example for the purpose of general 
consideration rather than a solution for a specific problem?

  Maciej

Re: C standards and committees (was Re: strangest systems I've sent email from)

[Maciej W. Rozycki]

On Sun, 22 May 2016, Mouse wrote:

> >>> First off, the C standard mandates that the order of fields in a
> >>> struct cannot be reordered,
> >> Yes.  (I think this is a Bad Thing, but I can see why they did it.)
> > Given that C is a systems implementation language, how would you
> > define HW related data structures where the order of the fields is
> > critical (ie HW defines them).
> 
> I can see three answers.
> 
> 1) Don't use structs for that.  Look at NetBSD's bus-space abstraction
>for one possible way.
> 
> 2) Make any reordering implementation-defined, so that code for
>specific implementations can know how the implementation does it.
> 
> 3) Make reordering optional.  Which way the default should go is
>arguable; since my guess is that most structs are not
>hardware-interface structs, the default should be reordering, with
>some keyword specifying no reordering.

4) While the C language standard may not mandate it itself, a specific 
   system ABI may require a particular bitfield, structure, etc. layout 
   which C compiler implementations for that platform need to adhere to, 
   and then you can rely on that.  Of course that does not solve the 
   problem for code which has to be portable across systems (e.g. option 
   card drivers), but there you usually need to take extra care for 
   differences between systems (e.g. endianness) anyway.

  Maciej

Re: C standards and committees (was Re: strangest systems I've sent email from)

[Guy Sotomayor Jr]

> On May 22, 2016, at 5:40 AM, Mouse  wrote:
> 
 First off, the C standard mandates that the order of fields in a
 struct cannot be reordered,
>>> Yes.  (I think this is a Bad Thing, but I can see why they did it.)
>> Given that C is a systems implementation language, how would you
>> define HW related data structures where the order of the fields is
>> critical (ie HW defines them).
> 
> I can see three answers.
> 
> 1) Don't use structs for that.  Look at NetBSD's bus-space abstraction
>   for one possible way.

I already have to do that for bit fields (ie do mask and shift).  The code
would look *much* cleaner/clearer if I could in fact use bit-fields.

Anything that is implementation defined results in them not being able
to be used.  For example, I have a peripheral that has structures that
define how to communicate to the peripheral.  If structs are “implemenation”
defined, then I can’t use the same structure across the interface because
I can’t guarantee that one side will interpret the structure the same as
the other.

This is *exactly* the issue with bit fields.  I want to use them (because it
makes sense) as part of an interface but I can’t because I can’t know
what the compilers will do on each side.
> 
> 2) Make any reordering implementation-defined, so that code for
>   specific implementations can know how the implementation does it.
> 
> 3) Make reordering optional.  Which way the default should go is
>   arguable; since my guess is that most structs are not
>   hardware-interface structs, the default should be reordering, with
>   some keyword specifying no reordering.


…and that sort of thing will cause all sorts of havoc in terms of breaking
software that currently works.  You’d have to go back and find/change
all of the places where reordering isn’t desired.  *If* it were to happen
I will bet dollars to donuts that the default would be no reordering and
there would be an attribute to allow for it.

…and what exactly is reordering supposed to buy you?

I would argue that for what you’re talking about is not “C” but some
language that may share some syntactic/semantic similarities with
“C” but is a clearly different language.

TTFN - Guy

Re: strangest systems I've sent email from

[Lars Brinkhoff]

Mouse  writes:
> I don't really know FORTH; does it use - for subtraction?

Generally, yes.

RE: VGA Error Code from DECpc AXP 150 (Jensen)

[Robert Jarratt]

I think I have found the problem, when I took the card out to change its
slot, I found there were some corroded pins on one of the chips (looks like
memory). It looks like battery leakage damage, but the odd thing is that it
is nowhere near a battery. Cleaning it up now to see if that will fix it.

Thanks

Rob

RE: Hamvention

[Bill Sudbrink]

Jerry Weiss wrote:
> I saw one Altair 8800

I haven't seen an Altair at a hamfest in this century.
Out of curiosity, what was the seller asking?

Bill S.

Re: strangest systems I've sent email from

[Guy Dawson]

>> I'm not even sure
>
>>   size_t foo = (size_t)-1;
>
>> is legal,
>
> In C++, I don't know.  In C, I'm fairly sure it's legal.
>
>> or even does what I expect it to do (namely---set foo to the largest
>> size_t value possible (pre C99).
>
> I'm not sure it does that.  If you want that, I think you want
>
>size_t foo = -(size_t)1;

While I think that

size_t foo = (size_t)(-1);

is what C would interpret as being meant. What the size of the thing that
by default, in this implementation, -1 would be stored in.



On 22 May 2016 at 14:09, Mouse  wrote:

> > I'd wager that most C code is written *assuming* 2's complement and 0
> > NULL pointers (and byte addressable, but I didn't ask for that 8-).
>
> Well, yes.  I'd go further: I'd wager most C code is written assuming
> everything works just the way the developer's system does; most people
> I interact with don't seem to realize that "try it and see how it
> works" is not a valid way to find out how C (as opposed to "C on this
> particular version of this particular implementation on this particular
> system") works.
>
> >   "[W]rite a VM with minimal bytecode and that uses 1s'
> >   complement and/or sign-magnitude.  Implement a GCC or LLVM
> >   backend for it if either of them has nominal support for that,
> >   or a complete C implementation if not.  [...]
> > Personally, I would *love* to see such a compiler (and would actually
> > use it, just to see how biased existing code is).
>
> I've often thought about building a C implementation that goes out of
> its way to break assumptions like "integers are two's complement with
> no padding bits" or "floats are IEEE" or "nil pointers are all-bits-0"
> or "all pointers are the same size and representation" or etc.
>
> > I'm not even sure
>
> >   size_t foo = (size_t)-1;
>
> > is legal,
>
> In C++, I don't know.  In C, I'm fairly sure it's legal.
>
> > or even does what I expect it to do (namely---set foo to the largest
> > size_t value possible (pre C99).
>
> I'm not sure it does that.  If you want that, I think you want
>
> size_t foo = -(size_t)1;
>
> > To me, I see 2's complement as having "won the war" so to speak.
>
> At present, yes, I agree.  I am not convinced that will not change.
>
> There was a time when "little endian, no alignment restrictions"
> appeared to have won the war (in the form of the VAX and, later, the
> x86).  These days, ARM's star is on the rise and others may follow,
> breaking the "no alignment restrictions" part (and possibly the "little
> endian" part - I forget whether ARM is big- or little-endian).
>
> >   http://blog.regehr.org/archives/[...]
>
> Yeah, I've read some of his writings.
>
> I disagree with him.  I think C needs to fork.  It seems to me there is
> need for two languages: an unsafe one, the "high level assembly
> language" C is regularly called, which is suitable for things such as
> hardware interfacing or malloc() implementation, and a safer one,
> closer to what blog.regehr.org seems to want, for...well, I'm not quite
> sure what he thinks this language would be better for.  Application
> layer stuff, I guess?
>
> /~\ The ASCII Mouse
> \ / Ribbon Campaign
>  X  Against HTMLmo...@rodents-montreal.org
> / \ Email!   7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B
>



-- 
4.4 > 5.4

Re: 1's comp

[Toby Thain]

On 2016-05-22 3:10 AM, Chuck Guzis wrote:

On 05/21/2016 07:34 PM, Toby Thain wrote:


Don't underestimate the headache of handling two zeroes.


At least on the CDC iron, it was never much of a problem.  The primary
way you got -0 as a result (without resorting to boolean operations),
was subtracting -0 from -0.  The ZR/NZ operations worked on either sign.

Note that, on the fullword 60-bit operations, the conditionals were
based on the contents of a single register.  To compare, you had to
subtract or otherwise operate on two operands and branch on the content
of the result.  There were no condition codes--something that made
instruction scheduling much simpler.

The 18-bit index register conditionals (EQ, NE, GT...etc.) didn't
usually see -0 as a problem.

Ones complement did have advantages in bit twiddling--there were some
nifty tricks not possible in two's complement.   Of course the CDC 6000
series was word-addressable--something that seemed eminently practical.

As far as I'm aware, the possibility of two zeroes never impacted the
performance of the CDC 6000 series in the real world.


I didn't mean performance - I meant programmer effort to ensure 
robust/correct code. The Grishman book didn't reassure me, but thanks 
for the additional info.


--Toby




--Chuck

Re: strangest systems I've sent email from

[Mouse]

>> Also, PostScript has a lot of language syntax, whereas FORTH has
>> immediate words that act like language syntax.  (The difference is
>> that FORTH makes it possible to change those words, thereby changing
>> the apparent syntax.)
> What do you mean by that?

Consider a simple definition

: foo swap - ;  ( inverted subtraction )
/foo { exch sub } def  % inverted subtraction

(The first is FORTH[%], the second PostScript.)  Each of these has some
"syntax" bits.  In FORTH, :, ;, (, and ).  In PostScript, the leading
/, {, }, and %.

The difference is that in FORTH, you can create new immediate words
and/or redefine the existing ones; : can do something other than
beginning the definition of a word, and you can arrange to begin the
definition of a word with something other than :.  In PostScript, none
of this is mutable short of hacking on the underlying implementation
(and if you do that the result isn't PostScript any longer).

[%] I think.  I don't really know FORTH; does it use - for subtraction?

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

Re: strangest systems I've sent email from

[Mouse]

> I'd wager that most C code is written *assuming* 2's complement and 0
> NULL pointers (and byte addressable, but I didn't ask for that 8-).

Well, yes.  I'd go further: I'd wager most C code is written assuming
everything works just the way the developer's system does; most people
I interact with don't seem to realize that "try it and see how it
works" is not a valid way to find out how C (as opposed to "C on this
particular version of this particular implementation on this particular
system") works.

>   "[W]rite a VM with minimal bytecode and that uses 1s'
>   complement and/or sign-magnitude.  Implement a GCC or LLVM
>   backend for it if either of them has nominal support for that,
>   or a complete C implementation if not.  [...]
> Personally, I would *love* to see such a compiler (and would actually
> use it, just to see how biased existing code is).

I've often thought about building a C implementation that goes out of
its way to break assumptions like "integers are two's complement with
no padding bits" or "floats are IEEE" or "nil pointers are all-bits-0"
or "all pointers are the same size and representation" or etc.

> I'm not even sure 

>   size_t foo = (size_t)-1;

> is legal,

In C++, I don't know.  In C, I'm fairly sure it's legal.

> or even does what I expect it to do (namely---set foo to the largest
> size_t value possible (pre C99).

I'm not sure it does that.  If you want that, I think you want

size_t foo = -(size_t)1;

> To me, I see 2's complement as having "won the war" so to speak.

At present, yes, I agree.  I am not convinced that will not change.

There was a time when "little endian, no alignment restrictions"
appeared to have won the war (in the form of the VAX and, later, the
x86).  These days, ARM's star is on the rise and others may follow,
breaking the "no alignment restrictions" part (and possibly the "little
endian" part - I forget whether ARM is big- or little-endian).

>   http://blog.regehr.org/archives/[...]

Yeah, I've read some of his writings.

I disagree with him.  I think C needs to fork.  It seems to me there is
need for two languages: an unsafe one, the "high level assembly
language" C is regularly called, which is suitable for things such as
hardware interfacing or malloc() implementation, and a safer one,
closer to what blog.regehr.org seems to want, for...well, I'm not quite
sure what he thinks this language would be better for.  Application
layer stuff, I guess?

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

RE: VGA Error Code from DECpc AXP 150 (Jensen)

[Robert Jarratt]

> -Original Message-
> From: cctalk [mailto:cctalk-boun...@classiccmp.org] On Behalf Of Adrian
> Graham
> Sent: 22 May 2016 12:16
> To: General Discussion: On-Topic and Off-Topic Posts
> 
> Subject: Re: VGA Error Code from DECpc AXP 150 (Jensen)
> 
> On 22/05/2016 11:51, "Robert Jarratt"  wrote:
> 
> >> I can't remember what VGA card was in a Jensen, Compaq Qvision?
> >
> >
> > Yes, that is correct.
> 
> EISA card, yay.
> 
> > Already tried it from the AlphaBIOS and I get the same error. The VGA
> > output varies from all grey, to black and white vertical stripes, to a
> > screen full of "@" symbols.
> 
> Aaaand unless you've got the ECU diskette and a working floppy drive you
> can't just move the card to a different EISA slot. Have you checked all
the
> caps on the motherboard? If slot power is reduced you might get those
> symptoms.
> 

I do have the ECU diskette and I can run the ECU. I had contemplated moving
the card to another slot but didn't think it would make a difference. Will
give that a go. Thanks for the suggestion.

Regards

Rob

Re: ND-10 software - Re: Harris H800 Computer

[Mattis Lind]

söndag 22 maj 2016 skrev Torfinn Ingolfsen :

> On Sat, May 21, 2016 at 6:38 PM, Mattis Lind  > wrote:
> >
> > I have now added some 80 more floppies to download if you would like to
> > check.
> >
> > http://www.datormuseum.se/documentation-software/norsk-data-floppy-disks
>
> Very cool!
> Now I just need to find a tool that converts IMD to raw format and
> runs on FreeBSD.
> IMD / IMDU is a ms-dos program, samdisk exists as a Linux binary, but
> refuses to find a shared library (libbz2.so.1.0:)


Isn't it possible to run dosemu on FreeBSD?  I use imdv in dosemu on Linux.

/Mattis

--
> Regards,
> Torfinn
>

Re: ND-10 software - Re: Harris H800 Computer

[Torfinn Ingolfsen]

On Sat, May 21, 2016 at 6:38 PM, Mattis Lind  wrote:
>
> I have now added some 80 more floppies to download if you would like to
> check.
>
> http://www.datormuseum.se/documentation-software/norsk-data-floppy-disks

Very cool!
Now I just need to find a tool that converts IMD to raw format and
runs on FreeBSD.
IMD / IMDU is a ms-dos program, samdisk exists as a Linux binary, but
refuses to find a shared library (libbz2.so.1.0:)
-- 
Regards,
Torfinn

Re: VGA Error Code from DECpc AXP 150 (Jensen)

[Adrian Graham]

On 22/05/2016 11:51, "Robert Jarratt"  wrote:

>> I can't remember what VGA card was in a Jensen, Compaq Qvision?
> 
> 
> Yes, that is correct.

EISA card, yay.

> Already tried it from the AlphaBIOS and I get the same error. The VGA output
> varies from all grey, to black and white vertical stripes, to a screen full
> of "@" symbols.

Aaaand unless you've got the ECU diskette and a working floppy drive you
can't just move the card to a different EISA slot. Have you checked all the
caps on the motherboard? If slot power is reduced you might get those
symptoms.

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

RE: VGA Error Code from DECpc AXP 150 (Jensen)

[Robert Jarratt]

> -Original Message-
> From: cctalk [mailto:cctalk-boun...@classiccmp.org] On Behalf Of Adrian
> Graham
> Sent: 22 May 2016 09:50
> To: General Discussion: On-Topic and Off-Topic Posts
> 
> Subject: Re: VGA Error Code from DECpc AXP 150 (Jensen)
> 
> On 22/05/2016 08:58, "Robert Jarratt"  wrote:
> 
> > I am hoping to install Windows NT 3.1 on my Jensen. Unfortunately I am
> > getting an error code relating to VGA. The tech docs I have make no
> > mention of this code, anyone know what it means:
> >
> >
> >
> > VGA  ?? 06 0020
> 
> I can't remember what VGA card was in a Jensen, Compaq Qvision?


Yes, that is correct.


> I also
> don't remember running VMS/OSF on a graphics head on one of those so it
> might not be supported. You need to be in AlphaBIOS to install NT anyway,
> so what happens if you
> 
> >>> SET OS_TYPE NT
> >>> ARC
> 
> (this is from rusty memory, YMMV etc, Jensen was also a DEC 2000-300)


Already tried it from the AlphaBIOS and I get the same error. The VGA output
varies from all grey, to black and white vertical stripes, to a screen full
of "@" symbols.

Regards

Rob

Re: VGA Error Code from DECpc AXP 150 (Jensen)

[Adrian Graham]

On 22/05/2016 08:58, "Robert Jarratt"  wrote:

> I am hoping to install Windows NT 3.1 on my Jensen. Unfortunately I am
> getting an error code relating to VGA. The tech docs I have make no mention
> of this code, anyone know what it means:
> 
>  
> 
> VGA  ?? 06 0020

I can't remember what VGA card was in a Jensen, Compaq Qvision? I also don't
remember running VMS/OSF on a graphics head on one of those so it might not
be supported. You need to be in AlphaBIOS to install NT anyway, so what
happens if you

>>> SET OS_TYPE NT
>>> ARC

(this is from rusty memory, YMMV etc, Jensen was also a DEC 2000-300)

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

VGA Error Code from DECpc AXP 150 (Jensen)

[Robert Jarratt]

I am hoping to install Windows NT 3.1 on my Jensen. Unfortunately I am
getting an error code relating to VGA. The tech docs I have make no mention
of this code, anyone know what it means:

 

VGA  ?? 06 0020

 

Regards

 

Rob

Re: Hamvention

[Alex McWhirter]

I picked up one of those power systems, the other was gone before I got to it. 
The only things I can add are an amiga and tons of cisco network gear.
Not a whole lot this year I suppose.


Sent from my T-Mobile 4G LTE Device

 Original message 
From: Brian Marstella  
Date: 5/22/2016  12:09 AM  (GMT-05:00) 
To: "General Discussion: On-Topic and Off-Topic Posts"  
Subject: Re: Hamvention 

After Alex mentioned it, I'd thought about driving up if anyone saw
anything of interest, but sounds like there isn't a great deal to pick from
for older computers. I really can't justify the drive anyway, this year...

Brian KI4GTD

On Sat, May 21, 2016 at 11:48 PM, Jerry Weiss  wrote:

> I saw one Altair 8800 and one TRS-80 III out in the swap fest.  Some more
> recent power (5?) series, but that’s about it.
>
> Jerry WB9MRI
>
>
> > On May 20, 2016, at 1:18 PM, Alex McWhirter 
> wrote:
> >
> >
> >
> >
> > Anyone spot anything list related at hamvention? I'm around trying to
> find anything cool. Particularly sun and ibm stuff.
> >
> > Sent from my T-Mobile 4G LTE Device
>
>

Re: 1's comp

[Chuck Guzis]

On 05/21/2016 07:34 PM, Toby Thain wrote:

> Don't underestimate the headache of handling two zeroes.

At least on the CDC iron, it was never much of a problem.  The primary
way you got -0 as a result (without resorting to boolean operations),
was subtracting -0 from -0.  The ZR/NZ operations worked on either sign.

Note that, on the fullword 60-bit operations, the conditionals were
based on the contents of a single register.  To compare, you had to
subtract or otherwise operate on two operands and branch on the content
of the result.  There were no condition codes--something that made
instruction scheduling much simpler.

The 18-bit index register conditionals (EQ, NE, GT...etc.) didn't
usually see -0 as a problem.

Ones complement did have advantages in bit twiddling--there were some
nifty tricks not possible in two's complement.   Of course the CDC 6000
series was word-addressable--something that seemed eminently practical.

As far as I'm aware, the possibility of two zeroes never impacted the
performance of the CDC 6000 series in the real world.

--Chuck