cctalk Digest, Vol 15, Issue 24
mark at markesystems.com
mark at markesystems.com
Thu Sep 24 16:37:29 CDT 2015
>> I don't know what you're looking at for the front end of this project,
>> but have you considered SQLite for the database engine back end? If
>
>No, I would not consider it. I have experience with it on my Garmin GPS
>unit. I really dislike it.
Wow - I'm quite surprised at that. It is in *everything*: Android, iOS,
FireFox, Chrome, - the list goes far on. Personally, I've never used it on
an embedded platform, although I'm certainly keeping it in my back pocket
for the time when I need an embedded database. What problems have you
experienced?
I have used it on PC platforms, and have been quite impressed with how
robust the database structure is. It's all contained in one file, and it's
an in-process library, not a server. This makes it not-as-good for
massively multi-user stuff, but *much* easier to administer; no daemons to
manage, and just one database file (like Access, but better).
I use it for industrial automation applications, and have tested it a lot to
see if I could corrupt the database. Basically, unless I deliberately
mangled the container file, I couldn't get it to fail non-gracefully, even
by turning of the power while writing the file. (This was not a full,
rigorous failure study, but I've got a lot of them out there now, and
although I get plenty of support calls a screwed-up database is never the
root cause.)
Just my experience...
~~
Mark Moulding
------------------------------
Message: 21
Date: Wed, 23 Sep 2015 17:09:42 -0500
From: Jay Jaeger <cube1 at charter.net>
To: cctalk at classiccmp.org
Subject: Re: Structured Fortran - was Re: Self modifying code, lambda
calculus
Message-ID: <56032326.30504 at charter.net>
Content-Type: text/plain; charset=utf-8
On 9/23/2015 4:27 PM, ben wrote:
> On 9/23/2015 2:39 AM, ANDY HOLT wrote:
>>> From: "Chuck Guzis" <cclist at sydex.com>
>>
>> ?
>>> After all, languages are supposed to expose features
>>> of the underlying machine to the programmer.
>>
>> Many believe that the purpose of languages is to HIDE (abstract) the
>> underlying
>> machine.
>
> The 60's idea that MACROS could do that seems to have faded away.
> Ben.
>
>
Yes, STAGE2 and friends pretty well faded out when LR grammars and
parsers and parser generators became more widely understood and used.
JRJ
------------------------------
Message: 22
Date: Thu, 24 Sep 2015 00:15:10 +0100
From: Antonio Carlini <a.carlini at ntlworld.com>
To: General Discussion: On-Topic and Off-Topic Posts
<cctalk at classiccmp.org>
Subject: Re: Backups [was Re: Is tape dead?]
Message-ID: <5603327E.3080107 at ntlworld.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
On 21/09/15 14:15, Noel Chiappa wrote:
> > From: tony duell
>
> > In some cases it should be possible to write a machine code program
> > that executes on 2 processors with wildly different instruciton
> sets.
>
> I have this bit set that I was told (or something, the memory is _very_
> vague) that early versions of the KL-10 had this hack; the root block on
> the
> disk was the boot block both the PDP-10 and the PDP-11 front end machine,
> and
> the first instruction or two was very cleverly construced and sent the two
> machines different ways. Alas, I looked in the front-end PDP-11 code (in
> the
> KLDCP; directory) and saw no signs of this, so maybe it was an urban
> legend?
>
>
I can't find a definitive reference right now, but I *think* that the
ODS-1 disk format
was first used on the PDP-11 and then later used in early versions of
VMS. I *think*
that it was arranged such that a PDP-11 booting and a VMS system booting
could
be done from the same disk by arranging for each to interpret the boot
block in
a way that each was happy with.
Antonio
arcarlini at iee.org
------------------------------
Message: 23
Date: Wed, 23 Sep 2015 16:24:53 -0700
From: Chuck Guzis <cclist at sydex.com>
To: "General Discussion: On-Topic and Off-Topic Posts"
<cctalk at classiccmp.org>
Subject: Re: Structured Fortran - was Re: Self modifying code, lambda
calculus
Message-ID: <560334C5.40102 at sydex.com>
Content-Type: text/plain; charset=utf-8; format=flowed
On 09/23/2015 02:27 PM, ben wrote:
> The 60's idea that MACROS could do that seems to have faded away.
> Ben.
It depends. One very handy method is to devise a machine architecture,
complete with registers and opcodes, and write the application code in
macros, creating instruction words--and then run them using a small
emulator for the devised machine.
After operation can be validated, re-code the macro bodies to generate
native machine code instead of emulated fictitious machine instructions.
A way to get certain tasks done very quickly.
The C macro facility barely qualifies as such. PL/I had a wonderful
preprocessor; some assemblers were similarly versatile. For example,
I've used an assembler that boasted support of arrays of structures of
user-defined data types. Now that was a macro facility.
--Chuck
------------------------------
Message: 24
Date: Wed, 23 Sep 2015 18:29:37 -0500
From: Jay Jaeger <cube1 at charter.net>
To: cctalk at classiccmp.org
Subject: Re: Structured Fortran - was Re: Self modifying code, lambda
calculus
Message-ID: <560335E1.4070607 at charter.net>
Content-Type: text/plain; charset=utf-8
On 9/23/2015 6:24 PM, Chuck Guzis wrote:
> On 09/23/2015 02:27 PM, ben wrote:
>
>> The 60's idea that MACROS could do that seems to have faded away.
>> Ben.
>
> It depends. One very handy method is to devise a machine architecture,
> complete with registers and opcodes, and write the application code in
> macros, creating instruction words--and then run them using a small
> emulator for the devised machine.
>
> After operation can be validated, re-code the macro bodies to generate
> native machine code instead of emulated fictitious machine instructions.
>
> A way to get certain tasks done very quickly.
>
Shades of SIL for SNOBOL and also STAGE2.
JRJ
------------------------------
Message: 25
Date: Thu, 24 Sep 2015 00:38:34 +0100
From: Antonio Carlini <a.carlini at ntlworld.com>
To: General Discussion: On-Topic and Off-Topic Posts
<cctalk at classiccmp.org>
Subject: Re: Backups [was Re: Is tape dead?]
Message-ID: <560337FA.70404 at ntlworld.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
On 21/09/15 01:55, Jerome H. Fine wrote:
>
> I used the above example when I created a CD which had files to be used
> with RT-11 in addition to being a normal CD under Windows. I found that
> for a normal CD under Windows, sectors 0 to 15 (hard disk blocks 0 to 63)
> on the CD were empty. I don't know if that area is reserved for boot
> code
> under Windows when the CD is bootable, but my goal did not require the
> CD to be bootable under Windows.
I did something very similar (or rather, used someone else's code to do
something
very similar) with ODS-2 under OpenVMS and ISO9660 (which is what Windows
uses for CD media iirc).
As you say, ISO9660 leaves the first 16 (or thereabouts) 2048 byte
blocks undefined.
ODS-2, on the other hand, uses them. So the code builds an ISO9660 CD
and then
overlays the ODS-2 structure on top. It finds the ISO9660 directory
structures and
arranges for them to live in BADBLK.SYS so VMS is happy enough when
mounting the
media. All the ODS-2 structures get packed into the beginning of the
image so anything
looking at the ISO9660 side sees nothing untoward. This only works well
for filetypes
that have no special structure under ODS-2: basically CR-LF text files
and binary
formats (such as PDF). I still have a CD that I built this way many
moons ago.
I remember reading a message in one of the EASYnet NOTES conferences
(inside DEC) which more or less said that ISO9660 leaving those initial
blocks
free wasn't a coincidence and that DEC's representative (Andy Goldstein
perhaps)
had pushed for that.
Antonio
arcarlini at iee.org
------------------------------
Message: 26
Date: Wed, 23 Sep 2015 16:57:22 -0700
From: Chuck Guzis <cclist at sydex.com>
To: "General Discussion: On-Topic and Off-Topic Posts"
<cctalk at classiccmp.org>
Subject: Re: Structured Fortran - was Re: Self modifying code, lambda
calculus
Message-ID: <56033C62.9040804 at sydex.com>
Content-Type: text/plain; charset=utf-8; format=flowed
On 09/23/2015 04:29 PM, Jay Jaeger wrote:
> Shades of SIL for SNOBOL and also STAGE2.
The first time I did this was for translating COBOL to a special-purpose
dialect. Not a simple lexical task--it was a full-blown two-pass affair.
The initial test versions of the thing were very, very slow. Once the
native-code version was rolled out, it was very, very fast. Development
time was pretty fast.
--Chuck
------------------------------
Message: 27
Date: Thu, 24 Sep 2015 02:36:13 +0200
From: Johnny Billquist <bqt at update.uu.se>
To: cctalk at classiccmp.org
Subject: Re: Backups [was Re: Is tape dead?]
Message-ID: <5603457D.2070703 at update.uu.se>
Content-Type: text/plain; charset=utf-8; format=flowed
On 2015-09-24 01:15, Antonio Carlini wrote:
> On 21/09/15 14:15, Noel Chiappa wrote:
>> > From: tony duell
>>
>> > In some cases it should be possible to write a machine code
>> program
>> > that executes on 2 processors with wildly different instruciton
>> sets.
>>
>> I have this bit set that I was told (or something, the memory is _very_
>> vague) that early versions of the KL-10 had this hack; the root block
>> on the
>> disk was the boot block both the PDP-10 and the PDP-11 front end
>> machine, and
>> the first instruction or two was very cleverly construced and sent the
>> two
>> machines different ways. Alas, I looked in the front-end PDP-11 code
>> (in the
>> KLDCP; directory) and saw no signs of this, so maybe it was an urban
>> legend?
>>
>>
>
> I can't find a definitive reference right now, but I *think* that the
> ODS-1 disk format
> was first used on the PDP-11 and then later used in early versions of
> VMS. I *think*
> that it was arranged such that a PDP-11 booting and a VMS system booting
> could
> be done from the same disk by arranging for each to interpret the boot
> block in
> a way that each was happy with.
I think that is incorrect, since early VMS didn't havea boot block. The
VAX-11/780 was always booted from the PDP-11, and it started with VMB.
VMB was gotten from the FE, and VMB in turn understood the file system.
It wasn't until the VAX-11/750 that DEC did a VAX that used boot blocks.
And then, of course, the boot block is just the first block(s) on the
disk. Don't matter what file system you might have...
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt at softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
------------------------------
Message: 28
Date: Wed, 23 Sep 2015 17:52:23 -0700
From: Josh Dersch <derschjo at gmail.com>
To: "General Discussion: On-Topic and Off-Topic Posts"
<cctalk at classiccmp.org>
Subject: Re: DDS SETASI SC44 info?
Message-ID: <56034947.1090007 at gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
FYI, I've thrown up a couple of (cell phone) photos of the SC44 boards here:
http://yahozna.dyndns.org/scratch/sc44/
I'll have the machine home in a few days and I'll be able to take better
pictures then...
- Josh
On 9/23/15 2:40 PM, Josh Dersch wrote:
> Hi all --
>
> I just added a PDP-11/44 to my collection and it appears to have some
> manner of cache upgrade; it's made by Digital Data Systems (DDS) and
> consists of two cards, one hex-height labeled "SC44 SETASI" (in the
> place of the normal 11/44 cache board) and a second quad-height
> labeled "1051" at the end of the first backplane. The two are
> connected via a ribbon cable.
>
> I know DDS made some seriously nice upgrades for the 11/70 but I can't
> find anything on this board set at all. I'm assuming it's just a
> souped-up cache but it'd be nice to know more (and docs would be
> excellent of course).
>
> Thanks,
> Josh
------------------------------
Message: 29
Date: Wed, 23 Sep 2015 20:54:53 -0400
From: Paul Koning <paulkoning at comcast.net>
To: "General Discussion: On-Topic and Off-Topic Posts"
<cctalk at classiccmp.org>
Subject: Re: Structured Fortran - was Re: Self modifying code, lambda
calculus
Message-ID: <5209997D-E793-43B2-BC93-502F921078E3 at comcast.net>
Content-Type: text/plain; charset=us-ascii
> On Sep 23, 2015, at 7:24 PM, Chuck Guzis <cclist at sydex.com> wrote:
>
> ...
> The C macro facility barely qualifies as such. PL/I had a wonderful
> preprocessor;
That depends on the compiler. I remember the PL/C compiler (from Cornell,
running on IBM 370s). In graduate school, we were forced to use it because
the instructor was also the main author of that compiler. It was used in a
compiler construction class, with heavy use of macros.
That seemed fine except for one fatal flaw in the macro engine design. PL/I
has the notion of "source margins" -- source code is only processed between
colums 2 and 72 (by default; those limits are settable). The fatal flaw was
that the PL/C macro processor sat before the source margin machinery, so it
had to obey the source margins in doing macro expansion.
Unfortunately, it couldn't do that. A typical result of attempting to use a
complex macro was a compiler crash. To cure it, you'd add or remove spaces
from the macro call and/or the macro definition -- at which point you'd get
a crash or compiler infinite loop at some other macro call.
After a few weeks of that, we convinced the instructor to drop this bogus
piece of software and switch to a real compiler -- Pascal on the PDP-10.
paul
------------------------------
Message: 30
Date: Wed, 23 Sep 2015 18:06:23 -0700
From: Zane Healy <healyzh at aracnet.com>
To: "General Discussion: On-Topic and Off-Topic Posts"
<cctalk at classiccmp.org>
Subject: Re: Honeywell/Bull DPS-6 deskside info?
Message-ID: <032919E9-8EAB-4E9E-9E73-7CB2DD29A25C at aracnet.com>
Content-Type: text/plain; charset=us-ascii
Sam Ismail used to have a DPS-6, if not more than one, but I don't think he
was ever able to do anything with it. Does it have GCOS-6 installed?
I worked on DPS-8's and GCOS-8 a lifetime ago. I did a little with GCOS-6,
mainly assisting with moving operations from DPS-6 Mini's over to HP 9000
workstations running DPS-6 emulators.
I never had any GCOS-6 doc's and my GCOS-8 doc's were sent North a couple
years ago.
Zane
On Sep 23, 2015, at 2:44 PM, Josh Dersch <derschjo at gmail.com> wrote:
> Along with the 11/44 I also picked up a Honeywell/Bull DPS-6 deskside
> workstation; I can't seem to dig up much information specific to this
> model
> (a badge on the rear labels it as "Model/Index No. B01732"). I can take
> some detailed pictures later this week after I've had time to clean it up
> (it's very, very dirty), but it looks very similar to the DPS-6 unit
> pictured on this site:
> http://www.feb-patrimoine.com/projet/gcos6/gcos6.htm
>
> Anyone have any docs on this thing? Or fun anecdotes to share? What have
> I gotten myself into with this thing?
>
> Thanks,
> Josh
------------------------------
Message: 31
Date: Wed, 23 Sep 2015 21:24:04 -0400
From: COURYHOUSE at aol.com
To: cctalk at classiccmp.org
Subject: Re: Honeywell/Bull DPS-6 deskside info?
Message-ID: <384aea.543ed142.4334aab4 at aol.com>
Content-Type: text/plain; charset="US-ASCII"
there was a nightmare!
In a message dated 9/23/2015 6:20:18 P.M. US Mountain Standard Time,
healyzh at aracnet.com writes:
Sam Ismail used to have a DPS-6, if not more than one
------------------------------
Message: 32
Date: Wed, 23 Sep 2015 18:27:03 -0700
From: Josh Dersch <derschjo at gmail.com>
To: "General Discussion: On-Topic and Off-Topic Posts"
<cctalk at classiccmp.org>
Subject: ISO: FP11-F (M7093) for PDP-11/44
Message-ID: <56035167.3030403 at gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
The 11/44 I acquired recently has a complete CPU set but no FP11-F board
(M7093). I'd like to be able to run 2.11BSD (or other UNIX) on this
machine, so having floating point hardware is pretty essential -- anyone
have one going spare for sale/trade?
Thanks as always,
Josh
------------------------------
Message: 33
Date: Wed, 23 Sep 2015 20:29:34 -0500
From: Paul Anderson <useddec at gmail.com>
To: "General Discussion: On-Topic and Off-Topic Posts"
<cctalk at classiccmp.org>
Subject: Re: ISO: FP11-F (M7093) for PDP-11/44
Message-ID:
<CACwhfuMWaZe_O=_rmZdOXJ3ufJiSpsvUKfQq86WeuvQ50H9wrg at mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
I've got some here. Let me find it later tonight or tomorrow and I'll
contact you off list.
Paul
On Wed, Sep 23, 2015 at 8:27 PM, Josh Dersch <derschjo at gmail.com> wrote:
> The 11/44 I acquired recently has a complete CPU set but no FP11-F board
> (M7093). I'd like to be able to run 2.11BSD (or other UNIX) on this
> machine, so having floating point hardware is pretty essential -- anyone
> have one going spare for sale/trade?
>
> Thanks as always,
> Josh
>
>
------------------------------
Message: 34
Date: Wed, 23 Sep 2015 21:48:59 -0400
From: Todd Goodman <tsg at bonedaddy.net>
To: "General Discussion: On-Topic and Off-Topic Posts"
<cctalk at classiccmp.org>
Subject: Re: The desk has arrived - WAS: Somewhat OT: Freighting Items
Message-ID: <20150924014858.GZ30683 at ns1.bonedaddy.net>
Content-Type: text/plain; charset=us-ascii
* Ali <cctalk at fahimi.net> [150921 17:24]:
> Well,
>
> In case anyone is still interested the desk arrived on Friday. The seller
> did a very good job of packing it and it arrived in tact. Thanks to
> everyone
> for their input, tips, and bits of wisdom. BTW: If anyone is interested
> you
> can check out some quick pictures here:
>
> http://megacube.classiccmp.org/Synergetix/Synergetix.html
>
> The web page is very rudimentary and will be expanded. Once I get it
> cleaned
> up it will house an IBM 5150 A, a 5151, a 5152-002 and a Cipher 5120.
>
> -Ali
Nice! Glad it arrived OK and was packed well by the seller!
Todd
------------------------------
Message: 35
Date: Wed, 23 Sep 2015 22:05:00 -0400
From: "Mike Stein" <mhs.stein at gmail.com>
To: "General Discussion: On-Topic and Off-Topic Posts"
<cctalk at classiccmp.org>
Subject: Anyone recognize this bus/form factor?
Message-ID: <D3E2DA8EFD034FC0B7CCD646F6CEE07B at 310e2>
Content-Type: text/plain; format=flowed; charset="utf-8";
reply-type=original
68xx system, unusual (in my experience) 40-pin
single row header bus.
Anyone recognize it?
https://lh3.googleusercontent.com/-jRSv5KbuziQ/VgNYaQ5j1gI/AAAAAAAAAXY/A5k2n04KROo/s720-Ic42/Mystery68xx.JPG
------------------------------
Message: 36
Date: Wed, 23 Sep 2015 19:42:42 -0700
From: steve shumaker <shumaker at att.net>
To: General Discussion: On-Topic and Off-Topic Posts
<cctalk at classiccmp.org>
Subject: Re: Honeywell/Bull DPS-6 deskside info?
Message-ID: <56036322.4010901 at att.net>
Content-Type: text/plain; charset=UTF-8; format=flowed
On 9/23/2015 2:44 PM, Josh Dersch wrote:
> Along with the 11/44 I also picked up a Honeywell/Bull DPS-6 deskside
> workstation; I can't seem to dig up much information specific to this
> model
> (a badge on the rear labels it as "Model/Index No. B01732"). I can take
> some detailed pictures later this week after I've had time to clean it up
> (it's very, very dirty), but it looks very similar to the DPS-6 unit
> pictured on this site:
> http://www.feb-patrimoine.com/projet/gcos6/gcos6.htm
>
> Anyone have any docs on this thing? Or fun anecdotes to share? What have
> I gotten myself into with this thing?
>
> Thanks,
> Josh
>
>
browse here and elsewhere for WWMMCCS history and beginnings of
GCOS/DPS-6/Honeywell 6000
https://en.wikipedia.org/wiki/Worldwide_Military_Command_and_Control_System
One legend that gets trotted out whenever you speak of WWMMCCS is the
cookie monster that was on terminals in the Pentagon installation of
WWMMCCS. As the legend goes, at random intervals, the console would go
blank, operators would loose control and a message would display
something to the effect "cookie monster hungry - feed me". Supposedly
once you typed in one of several cookie names, the routine would release
the system back to the operator. I personally know a retired AF IT
manager who worked WWMMCCS and swears its a true story...
Suspect you will find very little material other than what Al has - it
wasn't a particularly common installed setup.
Steve
------------------------------
Message: 37
Date: Wed, 23 Sep 2015 20:00:46 -0700
From: Zane Healy <healyzh at aracnet.com>
To: "General Discussion: On-Topic and Off-Topic Posts"
<cctalk at classiccmp.org>
Subject: Re: Honeywell/Bull DPS-6 deskside info?
Message-ID: <7F9F16AF-2C5D-477C-9EA9-700E1D517C34 at aracnet.com>
Content-Type: text/plain; charset=us-ascii
On Sep 23, 2015, at 7:42 PM, steve shumaker <shumaker at att.net> wrote:
> On 9/23/2015 2:44 PM, Josh Dersch wrote:
>> Along with the 11/44 I also picked up a Honeywell/Bull DPS-6 deskside
>> workstation; I can't seem to dig up much information specific to this
>> model
>> (a badge on the rear labels it as "Model/Index No. B01732"). I can take
>> some detailed pictures later this week after I've had time to clean it up
>> (it's very, very dirty), but it looks very similar to the DPS-6 unit
>> pictured on this site:
>> http://www.feb-patrimoine.com/projet/gcos6/gcos6.htm
>>
>> Anyone have any docs on this thing? Or fun anecdotes to share? What
>> have
>> I gotten myself into with this thing?
>>
>> Thanks,
>> Josh
>>
>>
> browse here and elsewhere for WWMMCCS history and beginnings of
> GCOS/DPS-6/Honeywell 6000
>
> https://en.wikipedia.org/wiki/Worldwide_Military_Command_and_Control_System
>
>
> One legend that gets trotted out whenever you speak of WWMMCCS is the
> cookie monster that was on terminals in the Pentagon installation of
> WWMMCCS. As the legend goes, at random intervals, the console would go
> blank, operators would loose control and a message would display something
> to the effect "cookie monster hungry - feed me". Supposedly once you
> typed in one of several cookie names, the routine would release the system
> back to the operator. I personally know a retired AF IT manager who
> worked WWMMCCS and swears its a true story...
>
> Suspect you will find very little material other than what Al has - it
> wasn't a particularly common installed setup.
>
> Steve
>
DPS-8's, not 6's, and I for one don't believe that legend.
Zane
------------------------------
Message: 38
Date: Wed, 23 Sep 2015 20:03:47 -0700
From: Charles Anthony <charles.unix.pro at gmail.com>
To: "General Discussion: On-Topic and Off-Topic Posts"
<cctalk at classiccmp.org>
Subject: Re: Honeywell/Bull DPS-6 deskside info?
Message-ID:
<CANV78LRbu0e8K4-BPtacmdFdN6v--Nf9qdeNWu7vRtmpcngaLQ at mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
On Wed, Sep 23, 2015 at 8:00 PM, Zane Healy <healyzh at aracnet.com> wrote:
>
> On Sep 23, 2015, at 7:42 PM, steve shumaker <shumaker at att.net> wrote:
>
> > One legend that gets trotted out whenever you speak of WWMMCCS is the
> cookie monster that was on terminals in the Pentagon installation of
> WWMMCCS. As the legend goes, at random intervals, the console would go
> blank, operators would loose control and a message would display something
> to the effect "cookie monster hungry - feed me". Supposedly once you
> typed in one of several cookie names, the routine would release the system
> back to the operator. I personally know a retired AF IT manager who
> worked WWMMCCS and swears its a true story...
> >
> > Suspect you will find very little material other than what Al has - it
> wasn't a particularly common installed setup.
> >
> > Steve
> >
>
> DPS-8's, not 6's, and I for one don't believe that legend.
>
>
I don't know about the legend, but the cookie program originated on the
DPS-8: http://www.multicians.org/cookie.html
-- Charles
------------------------------
Message: 39
Date: Wed, 23 Sep 2015 20:04:36 -0700
From: Chuck Guzis <cclist at sydex.com>
To: "General Discussion: On-Topic and Off-Topic Posts"
<cctalk at classiccmp.org>
Subject: Re: Structured Fortran - was Re: Self modifying code, lambda
calculus
Message-ID: <56036844.8040006 at sydex.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
On 09/23/2015 05:54 PM, Paul Koning wrote:
>
>> On Sep 23, 2015, at 7:24 PM, Chuck Guzis <cclist at sydex.com> wrote:
>>
>> ...
>> The C macro facility barely qualifies as such. PL/I had a wonderful
>> preprocessor;
>
> That depends on the compiler.
Well, IBM did have a real PL/I compiler (after all, they invented the
stuff)--and later, there was an ANSI PL/I.
--Chuck
------------------------------
Message: 40
Date: Thu, 24 Sep 2015 15:43:37 +1200
From: Mike Ross <tmfdmike at gmail.com>
To: "General Discussion: On-Topic and Off-Topic Posts"
<cctalk at classiccmp.org>
Subject: Re: Anyone recognize this bus/form factor?
Message-ID:
<CAPhLQbMwe7CEQ8NY+G=DQ40mT9UV+4g406S=93jDVEXLS+xWOg at mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
That's odd.
I can't say for sure but... it has the feel of something that might
have belonged in a terminal or keyboard... character generator or
something... stab in the dark really.
Mike
On Thu, Sep 24, 2015 at 2:05 PM, Mike Stein <mhs.stein at gmail.com> wrote:
> 68xx system, unusual (in my experience) 40-pin
> single row header bus.
>
> Anyone recognize it?
>
> https://lh3.googleusercontent.com/-jRSv5KbuziQ/VgNYaQ5j1gI/AAAAAAAAAXY/A5k2n04KROo/s720-Ic42/Mystery68xx.JPG
>
--
http://www.corestore.org
'No greater love hath a man than he lay down his life for his brother.
Not for millions, not for glory, not for fame.
For one person, in the dark, where no one will ever know or see.'
------------------------------
Message: 41
Date: Wed, 23 Sep 2015 22:53:43 -0500
From: Adrian Stoness <tdk.knight at gmail.com>
To: "General Discussion: On-Topic and Off-Topic Posts"
<cctalk at classiccmp.org>
Subject: Re: Anyone recognize this bus/form factor?
Message-ID:
<CAA3rs22vN79V_-NnipY=nL0AQZiu7pJH-1k+=vs-4q3ZTC2Zqw at mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
heathkit?
On Wed, Sep 23, 2015 at 10:43 PM, Mike Ross <tmfdmike at gmail.com> wrote:
> That's odd.
>
> I can't say for sure but... it has the feel of something that might
> have belonged in a terminal or keyboard... character generator or
> something... stab in the dark really.
>
> Mike
>
> On Thu, Sep 24, 2015 at 2:05 PM, Mike Stein <mhs.stein at gmail.com> wrote:
> > 68xx system, unusual (in my experience) 40-pin
> > single row header bus.
> >
> > Anyone recognize it?
> >
> >
> https://lh3.googleusercontent.com/-jRSv5KbuziQ/VgNYaQ5j1gI/AAAAAAAAAXY/A5k2n04KROo/s720-Ic42/Mystery68xx.JPG
> >
>
>
>
> --
>
> http://www.corestore.org
> 'No greater love hath a man than he lay down his life for his brother.
> Not for millions, not for glory, not for fame.
> For one person, in the dark, where no one will ever know or see.'
>
------------------------------
Message: 42
Date: Wed, 23 Sep 2015 23:22:59 -0600
From: Eric Smith <spacewar at gmail.com>
To: "General Discussion: On-Topic and Off-Topic Posts"
<cctalk at classiccmp.org>
Subject: Re: Structured Fortran - was Re: Self modifying code, lambda
calculus
Message-ID:
<CAFrGgTQ8=KQ5+DWXqj_SstbnH3Pj6xRFSd-BHe4yFd=gghOUag at mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
On Wed, Sep 23, 2015 at 8:30 AM, Jay Jaeger <cube1 at charter.net> wrote:
> An int just has to be able to store numbers of a certain magnitude.
> Same with long. You do have to be able to convert between longs (and
> possibly ints) and addresses (*). So, you make an int 5 digits (which
> matches the natural length of addresses) and longs something like 10
> digits. You don't have to simulate anything, near as I can tell. Then
> the length of an int is 5 and a long is 10 (instead of the more typical
> 2 and 4).
And the length of a char? It's required that all types other than
bitfields be fully represented as multiple chars, not e.g. an int
being two and a half chars, and a char has to cover at least the range
0..255, or -128..127, and it has to have a range based on a power of
two.
ISO/IEC 9899:1999(E) ?3.6 ?1 - a byte has to hold any member of the
basic character set
ISO/IEC 9899:1999(E) ?3.7.1 ?1 - a character is a C bit representation
that fits in a byte
ISO/IEC 9899:1999(E) ?5.2.4.2.1 ?1 - the size of a char is CHAR_BIT
bits, which is at least 8
ISO/IEC 9899:1999(E) ?6.2.6.1 ?2-4 - everything other than bitfields
consists of bytes
ISO/IEC 9899:1999(E) ?6.2.6.1 ?5 - Some data types other than char may
have machine representations that can't use all of the possible bit
patterns of the storage allocated; those representations are called
"trap representations". The char (and unsigned char) types can't have
trap representations.
ISO/IEC 9899:199(E) ?6.2.6.2 ?1 - unsigned integer types must have a
range of 0 to (2^n)-1, for some natural number n.
ISO/IEC 9899:199(E) ?6.2.6.2 ?2 - signed integer types must have a
range of -(2^n) to (2^n)-1 or -((2^n)-1) to (2^n)-1.
On a decimal machine, if you use three digits for a char, you have to
arrange that all your other types are multiples of three digits, with
each three-digit group only using valid char representations, because
accessing a char/byte out of a larger integer type is not allowed to
be a trap representation, because chars can't have a trap
representation.
If an unsigned char is three digits with values from 0..255, an
unsigned int can't be five digits. It has to be six digits, and the
only valid representations for it would have values of 0..65535. It
can't have any valid values in the range of 65536..999999.
------------------------------
Message: 43
Date: Thu, 24 Sep 2015 01:23:11 -0400
From: william degnan <billdegnan at gmail.com>
To: "General Discussion: On-Topic and Off-Topic Posts"
<cctalk at classiccmp.org>
Subject: Re: Anyone recognize this bus/form factor?
Message-ID:
<CABGJBuegdj6gxxuh=pfqmUkvKgvuPO-O67x-JkeMkgqJKeqpYw at mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
Looks like an add on or daughter board.
Bill Degnan
twitter: billdeg
vintagecomputer.net
On Sep 23, 2015 11:53 PM, "Adrian Stoness" <tdk.knight at gmail.com> wrote:
> heathkit?
>
> On Wed, Sep 23, 2015 at 10:43 PM, Mike Ross <tmfdmike at gmail.com> wrote:
>
> > That's odd.
> >
> > I can't say for sure but... it has the feel of something that might
> > have belonged in a terminal or keyboard... character generator or
> > something... stab in the dark really.
> >
> > Mike
> >
> > On Thu, Sep 24, 2015 at 2:05 PM, Mike Stein <mhs.stein at gmail.com> wrote:
> > > 68xx system, unusual (in my experience) 40-pin
> > > single row header bus.
> > >
> > > Anyone recognize it?
> > >
> > >
> >
> https://lh3.googleusercontent.com/-jRSv5KbuziQ/VgNYaQ5j1gI/AAAAAAAAAXY/A5k2n04KROo/s720-Ic42/Mystery68xx.JPG
> > >
> >
> >
> >
> > --
> >
> > http://www.corestore.org
> > 'No greater love hath a man than he lay down his life for his brother.
> > Not for millions, not for glory, not for fame.
> > For one person, in the dark, where no one will ever know or see.'
> >
>
------------------------------
Message: 44
Date: Wed, 23 Sep 2015 17:52:39 -0400
From: Sean Caron <scaron at umich.edu>
To: "General Discussion: On-Topic and Off-Topic Posts"
<cctalk at classiccmp.org>, Sean Caron <scaron at umich.edu>
Subject: Re: DDS SETASI SC44 info?
Message-ID:
<CAA43vkUFNLHRw1sbw_0hrqJpHdq0xyUcTJC_s+W5YS+=b11nGQ at mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
Any easy way to post pics of the top side of both boards? I can't
definitively ID them but we should be able to make a good guess as to
what's actually on there looking at all the major ICs...
Did you just buy this? :O
http://vintagetech.com/sales/Big%20Iron/PDP%2011-44/Information
Best,
Sean
On Wed, Sep 23, 2015 at 5:40 PM, Josh Dersch <derschjo at gmail.com> wrote:
> Hi all --
>
> I just added a PDP-11/44 to my collection and it appears to have some
> manner of cache upgrade; it's made by Digital Data Systems (DDS) and
> consists of two cards, one hex-height labeled "SC44 SETASI" (in the place
> of the normal 11/44 cache board) and a second quad-height labeled "1051"
> at
> the end of the first backplane. The two are connected via a ribbon cable.
>
> I know DDS made some seriously nice upgrades for the 11/70 but I can't
> find
> anything on this board set at all. I'm assuming it's just a souped-up
> cache but it'd be nice to know more (and docs would be excellent of
> course).
>
> Thanks,
> Josh
>
------------------------------
Message: 45
Date: Wed, 23 Sep 2015 17:56:07 -0400
From: Sean Caron <scaron at umich.edu>
To: "General Discussion: On-Topic and Off-Topic Posts"
<cctalk at classiccmp.org>, Sean Caron <scaron at umich.edu>
Subject: Re: Honeywell/Bull DPS-6 deskside info?
Message-ID:
<CAA43vkWd1NHC3=t6xtVOb8fg7dc1qxOO2ySh_=h1zr21-eRVnw at mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
Ah, so these are the vintagetech.com machines! Please take lots of pics of
the DPS-8 inside and out; I've never really seen the innards of a Honeywell
machine before and I'm kind of curious what their "style" looks like.
Best,
Sean
On Wed, Sep 23, 2015 at 5:47 PM, Dave G4UGM <dave.g4ugm at gmail.com> wrote:
> Many years ago we used them as Data Entry machines, but I have no
> documents and have forgotten everything I knew.
>
> > -----Original Message-----
> > From: cctalk [mailto:cctalk-bounces at classiccmp.org] On Behalf Of Josh
> > Dersch
> > Sent: 23 September 2015 22:45
> > To: General Discussion: On-Topic and Off-Topic Posts
> > <cctalk at classiccmp.org>
> > Subject: Honeywell/Bull DPS-6 deskside info?
> >
> > Along with the 11/44 I also picked up a Honeywell/Bull DPS-6 deskside
> > workstation; I can't seem to dig up much information specific to this
> model (a
> > badge on the rear labels it as "Model/Index No. B01732"). I can take
> some
> > detailed pictures later this week after I've had time to clean it up
> (it's very,
> > very dirty), but it looks very similar to the DPS-6 unit pictured on
> this site:
> > http://www.feb-patrimoine.com/projet/gcos6/gcos6.htm
> >
> > Anyone have any docs on this thing? Or fun anecdotes to share? What
> have
> > I gotten myself into with this thing?
> >
> > Thanks,
> > Josh
>
>
------------------------------
Message: 46
Date: Thu, 24 Sep 2015 11:18:03 +1000
From: steven at malikoff.com
To: "General Discussion: On-Topic Posts" <cctech at classiccmp.org>
Subject: Re: Thoughts on manual database design?
Message-ID:
<38f04b0e735cffb635b13834dcaee682.squirrel at webmail04.register.com>
Content-Type: text/plain;charset=utf-8
Not sure why you have VARCHARs for primary keys, why not use the
conventional auto-increment int so you can dispense with
the LastGeneratedArtifactID table.
CREATE TABLE Manual_Artifact
(
ArtifactID INT(11) NOT NULL AUTO_INCREMENT,
. . . other fields . . .
CONSTRAINT ArtifactID_pk PRIMARY KEY (ArtifactID)
)
You'll also need similar type primary keys on your other tables, and also
set up the foreign key constraints for your db integrity if you really want
to go
that far for this project. Some of those tables could be coalesced to
simplify the thing - as per the inane comment from the guy in Holland (or
wherever)
for instance the Location and Manual_Type tables.
Another thing, although MySQL is fine but for this I think SQLite might be a
better choice of db. Its access methods are all in-process ie. no external
dbms service to bother with, just a library to link in and the physical
database is a disk file (.s3db extension). It has a much 'lighter' db
footprint.
Steve.
---------------------------- Original Message ----------------------------
Subject: Re: Thoughts on manual database design?
From: "Jay Jaeger" <cube1 at charter.net>
Date: Thu, September 24, 2015 6:52 am
To: cctech at classiccmp.org
--------------------------------------------------------------------------
> If anyone cares a draft data model is visible at:
>
> http://webpages.charter.net/thecomputercollection/misc/manualmodel.pdf
>
> (It may change as I work on the design).
>
> Biggest change from earlier discussions: I found no reason not to merge
> the manuals/artifacts relationship table into the artifact table, and I
> reduced the primary key columns down to only those absolutely necessary
> to guarantee uniqueness.
>
> JRJ
>
>
------------------------------
Message: 47
Date: Thu, 24 Sep 2015 08:39:17 +0200
From: Pontus Pihlgren <pontus at Update.UU.SE>
To: "General Discussion: On-Topic and Off-Topic Posts"
<cctalk at classiccmp.org>
Subject: Re: DDS SETASI SC44 info?
Message-ID: <20150924063916.GA32087 at Update.UU.SE>
Content-Type: text/plain; charset=us-ascii
archive.org almost has some info:
http://web.archive.org/web/19990908232518/http://www.setasi.com/DECPP.html
It's a "Super Cache". Perhaps you could track down someone from Setasi?
See the mention here:
ftp://ftp.dbit.com/pub/pdp11/faq/faq.pages/vendors.html
/P
On Wed, Sep 23, 2015 at 02:40:14PM -0700, Josh Dersch wrote:
> Hi all --
>
> I just added a PDP-11/44 to my collection and it appears to have some
> manner of cache upgrade; it's made by Digital Data Systems (DDS) and
> consists of two cards, one hex-height labeled "SC44 SETASI" (in the place
> of the normal 11/44 cache board) and a second quad-height labeled "1051"
> at
> the end of the first backplane. The two are connected via a ribbon cable.
>
> I know DDS made some seriously nice upgrades for the 11/70 but I can't
> find
> anything on this board set at all. I'm assuming it's just a souped-up
> cache but it'd be nice to know more (and docs would be excellent of
> course).
>
> Thanks,
> Josh
------------------------------
Message: 48
Date: Thu, 24 Sep 2015 00:02:56 -0700
From: Josh Dersch <derschjo at gmail.com>
To: "General Discussion: On-Topic and Off-Topic Posts"
<cctalk at classiccmp.org>
Subject: Re: DDS SETASI SC44 info?
Message-ID: <5603A020.1060000 at gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
On 9/23/15 2:52 PM, Sean Caron wrote:
> Any easy way to post pics of the top side of both boards? I can't
> definitively ID them but we should be able to make a good guess as to
> what's actually on there looking at all the major ICs...
Yeah, I took some pictures this afternoon (a bit blurry -- it was dark
and all I had was my cell phone, I'll try to get better pics tomorrow):
http://yahozna.dyndns.org/scratch/sc44/
>
> Did you just buy this? :O
>
> http://vintagetech.com/sales/Big%20Iron/PDP%2011-44/Information
Yep :).
- Josh
>
> Best,
>
> Sean
>
>
> On Wed, Sep 23, 2015 at 5:40 PM, Josh Dersch <derschjo at gmail.com> wrote:
>
>> Hi all --
>>
>> I just added a PDP-11/44 to my collection and it appears to have some
>> manner of cache upgrade; it's made by Digital Data Systems (DDS) and
>> consists of two cards, one hex-height labeled "SC44 SETASI" (in the place
>> of the normal 11/44 cache board) and a second quad-height labeled "1051"
>> at
>> the end of the first backplane. The two are connected via a ribbon
>> cable.
>>
>> I know DDS made some seriously nice upgrades for the 11/70 but I can't
>> find
>> anything on this board set at all. I'm assuming it's just a souped-up
>> cache but it'd be nice to know more (and docs would be excellent of
>> course).
>>
>> Thanks,
>> Josh
>>
------------------------------
Message: 49
Date: Thu, 24 Sep 2015 01:04:59 -0600
From: ben <bfranchuk at jetnet.ab.ca>
To: cctalk at classiccmp.org
Subject: Re: Structured Fortran - was Re: Self modifying code, lambda
calculus
Message-ID: <5603A09B.3050706 at jetnet.ab.ca>
Content-Type: text/plain; charset=utf-8; format=flowed
On 9/23/2015 11:22 PM, Eric Smith wrote:
> ISO/IEC 9899:1999(E) ?3.6 ?1 - a byte has to hold any member of the
> basic character set
> ISO/IEC 9899:1999(E) ?3.7.1 ?1 - a character is a C bit representation
> that fits in a byte
> ISO/IEC 9899:1999(E) ?5.2.4.2.1 ?1 - the size of a char is CHAR_BIT
> bits, which is at least 8
> ISO/IEC 9899:1999(E) ?6.2.6.1 ?2-4 - everything other than bitfields
> consists of bytes
Bla Bla Bla ...
What happened to seven bit ASCII?
I think the major change in C from the OTHER programing languages
is BYTE addressing. Even Pascal from what I have seen packs characters
in words of some kind. That is main dividing line in how memory
can be accessed. char *ptr++ vs array(foo-1)
0-99 can hold a trimmed character set and 10 digits per int.
5 chars per word sounds right on decimal machine.
Logic operations would be on the digit rather the binary
level. This may not be standard C but I has the early
PDP 11 C feel if they I developed UNIX on decimal machine.
Ben.
------------------------------
Message: 50
Date: Thu, 24 Sep 2015 00:10:32 -0700
From: Josh Dersch <derschjo at gmail.com>
To: "General Discussion: On-Topic and Off-Topic Posts"
<cctalk at classiccmp.org>
Subject: Re: Honeywell/Bull DPS-6 deskside info?
Message-ID: <5603A1E8.3060903 at gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
On 9/23/15 2:56 PM, Sean Caron wrote:
> Ah, so these are the vintagetech.com machines! Please take lots of pics of
> the DPS-8 inside and out; I've never really seen the innards of a
> Honeywell
> machine before and I'm kind of curious what their "style" looks like.
>
> Best,
>
> Sean
Will do. I took the boards out to inspect them tonight (they had
rattled about a bit during shipment) and everything seems ok. I'll have
time to take some pictures this weekend. Unfortunately, somewhere along
the line someone disconnected nearly all the ribbon cables running to
the boards and I've got no idea what goes where (only a couple are
cohesively labeled.) This thing is going to be a project.
- Josh
------------------------------
Message: 51
Date: Thu, 24 Sep 2015 03:53:58 -0400
From: COURYHOUSE at aol.com
To: cctalk at classiccmp.org
Subject: Re: Honeywell/Bull DPS-6 deskside info?
Message-ID: <a1cb0.44c5458a.43350616 at aol.com>
Content-Type: text/plain; charset="US-ASCII"
is it a dps 6 or 8?
In a message dated 9/24/2015 12:10:41 A.M. US Mountain Standard Time,
derschjo at gmail.com writes:
On 9/23/15 2:56 PM, Sean Caron wrote:
> Ah, so these are the vintagetech.com machines! Please take lots of pics
of
> the DPS-8 inside and out; I've never really seen the innards of a
Honeywell
> machine before and I'm kind of curious what their "style" looks like.
>
> Best,
>
> Sean
Will do. I took the boards out to inspect them tonight (they had
rattled about a bit during shipment) and everything seems ok. I'll have
time to take some pictures this weekend. Unfortunately, somewhere along
the line someone disconnected nearly all the ribbon cables running to
the boards and I've got no idea what goes where (only a couple are
cohesively labeled.) This thing is going to be a project.
- Josh
------------------------------
Message: 52
Date: Thu, 24 Sep 2015 10:20:02 +0100
From: "Dave G4UGM" <dave.g4ugm at gmail.com>
To: "'General Discussion: On-Topic and Off-Topic Posts'"
<cctalk at classiccmp.org>
Subject: RE: Honeywell/Bull DPS-6 deskside info?
Message-ID: <084601d0f6aa$3209f150$961dd3f0$@gmail.com>
Content-Type: text/plain; charset="utf-8"
The DPS6 is a very different animal to the GE600 -> GE6000 > Level 66 =>
DPS300 which were as far as I know all TTL or LSI TTL....
... The CPU was built on wire wrap boards which were around 14" or 16"
square (say 35cm) and which slotted into a backplane.
.. the machines had an extensive test suite which the CE ran weekly. This
could vary the voltages to the logic chips....
.. when a faulty board was found they were usually repaired on-site, there
was a board tester shipped with each system to identify chip level faults.
.. this contrasts with the earlier H3200 we had which was fixed by board
level repair..
The CPU and Memory were in separate cabinets, much like the 360/67 but
Honeywell kept the same layout when moving from core (I think the
GE6000/H6000 were core) on to D-Ram in the L66.
The CPU number and I think the RAM start addresses were all configured on
switchs, so it was possible to split a Dual CPU machine into two singles for
testing.
The peripherals came from MPI a joint venture with CDC
https://en.wikipedia.org/wiki/Control_Data_Corporation#Magnetic_Peripherals_Inc.
There are more ramblings, (not from me) here:-
http://www.feb-patrimoine.com/english/gecos_to_gcos8_part_2.htm
The GCOS-3 Control Cards and Abort Codes Pocket Guide DD04 Rev.0 is sat on
my desk in the scanning queue...
Dave
> -----Original Message-----
> From: cctalk [mailto:cctalk-bounces at classiccmp.org] On Behalf Of Josh
> Dersch
> Sent: 24 September 2015 08:11
> To: General Discussion: On-Topic and Off-Topic Posts
> <cctalk at classiccmp.org>
> Subject: Re: Honeywell/Bull DPS-6 deskside info?
>
> On 9/23/15 2:56 PM, Sean Caron wrote:
> > Ah, so these are the vintagetech.com machines! Please take lots of
> > pics of the DPS-8 inside and out; I've never really seen the innards
> > of a Honeywell machine before and I'm kind of curious what their "style"
> looks like.
> >
> > Best,
> >
> > Sean
>
> Will do. I took the boards out to inspect them tonight (they had rattled
> about
> a bit during shipment) and everything seems ok. I'll have time to take
> some
> pictures this weekend. Unfortunately, somewhere along the line someone
> disconnected nearly all the ribbon cables running to the boards and I've
> got
> no idea what goes where (only a couple are cohesively labeled.) This
> thing is
> going to be a project.
>
> - Josh
>
------------------------------
Message: 53
Date: Thu, 24 Sep 2015 11:41:35 +0200
From: Pontus Pihlgren <pontus at Update.UU.SE>
To: cctalk at classiccmp.org
Subject: Regarding Manuals
Message-ID: <20150924094135.GB32087 at Update.UU.SE>
Content-Type: text/plain; charset=us-ascii
Hi
I have more manuals than I really have room for. Lots and lots of VMS
binders and softcover books. And now my employer is throwing out box
upon box of SUN, Ultrix, tru64 and various literature.
I'm trying to save what I think is useful and/or worth preserving. But
It's damn hard to decide and damn hard to motivate filling up every inch
of precious space.
At the moment I thinking about just looking the other way and throw what
is not directly useful to me.
What is a collector/hoarder to do? Anyone who wants to turn up with a
truck and fill with dead trees?
Regards,
Pontus.
------------------------------
Message: 54
Date: Thu, 24 Sep 2015 19:44:23 +1000
From: Nigel Williams <nw at retrocomputingtasmania.com>
To: cctalk <cctalk at classiccmp.org>
Subject: Re: Regarding Manuals
Message-ID:
<F0214D71-4B97-4CF9-9A8A-CD39406E25FE at retrocomputingtasmania.com>
Content-Type: text/plain; charset=us-ascii
> On 24 Sep 2015, at 7:41 pm, Pontus Pihlgren <pontus at Update.UU.SE> wrote:
> ...And now my employer is throwing out box
> upon box of SUN, Ultrix, tru64 and various literature.
Is it practical/possible to make a list of what is available and to
crowd-source out to the cctalk community to check whether copies exist
online or due for scanning? that might cut down the volume worth keeping.
------------------------------
Message: 55
Date: Thu, 24 Sep 2015 11:51:54 +0200
From: Pontus Pihlgren <pontus at Update.UU.SE>
To: "General Discussion: On-Topic and Off-Topic Posts"
<cctalk at classiccmp.org>
Subject: Re: Regarding Manuals
Message-ID: <20150924095154.GA9183 at Update.UU.SE>
Content-Type: text/plain; charset=us-ascii
On Thu, Sep 24, 2015 at 07:44:23PM +1000, Nigel Williams wrote:
>
> > On 24 Sep 2015, at 7:41 pm, Pontus Pihlgren <pontus at Update.UU.SE> wrote:
> > ...And now my employer is throwing out box
> > upon box of SUN, Ultrix, tru64 and various literature.
>
> Is it practical/possible to make a list of what is available and to
> crowd-source out to the cctalk community to check whether copies exist
> online or due for scanning? that might cut down the volume worth
> keeping.
It would be a lot of work. For the VMS stuff I have started indexing. I
suppose I should run the list through manx at least. Having an automatic
tool for that is tempting to make.
/P
------------------------------
Message: 56
Date: Thu, 24 Sep 2015 12:16:06 +0200
From: "Mazzini Alessandro" <mazzinia at tin.it>
To: "'General Discussion: On-Topic and Off-Topic Posts'"
<cctalk at classiccmp.org>
Subject: R: Regarding Manuals
Message-ID: <006001d0f6b2$06a4f570$13eee050$@tin.it>
Content-Type: text/plain; charset="iso-8859-1"
Crying at the prospect of the waste :( (from someone that had the chance of
saving just a set of X-Open manuals)
-----Messaggio originale-----
Da: cctalk [mailto:cctalk-bounces at classiccmp.org] Per conto di Pontus
Pihlgren
Inviato: gioved? 24 settembre 2015 11:42
A: cctalk at classiccmp.org
Oggetto: Regarding Manuals
Hi
I have more manuals than I really have room for. Lots and lots of VMS
binders and softcover books. And now my employer is throwing out box upon
box of SUN, Ultrix, tru64 and various literature.
I'm trying to save what I think is useful and/or worth preserving. But It's
damn hard to decide and damn hard to motivate filling up every inch of
precious space.
At the moment I thinking about just looking the other way and throw what is
not directly useful to me.
What is a collector/hoarder to do? Anyone who wants to turn up with a
truck and fill with dead trees?
Regards,
Pontus.
------------------------------
Message: 57
Date: Thu, 24 Sep 2015 07:10:15 -0400 (EDT)
From: Mouse <mouse at Rodents-Montreal.ORG>
To: cctalk at classiccmp.org
Subject: Re: C out of its comfort zone - Re: Structured Fortran - was
Re: Self modifying code
Message-ID: <201509241110.HAA04206 at Stone.Rodents-Montreal.ORG>
Content-Type: text/plain; charset="iso-8859-1"
> Well, there are plenty of word-but-not-byte/character addressable
> machines out there, which makes life interesting for the likes of C.
C is able to support them just fine, though a whole lot of C code isn't
(beacuse it assumes things like "all pointers are the same size", or
even more specifically, "all pointers are just memory addresses").
Such machines typically just have void * and char * occupying more
space than pointers to word-and-larger types.
> One thing that I've wondered about is "does the current HLL-du-juor
> dictate processor architecture?"--and not the reverse.
Dictate, probably not quite. Influence, certainly.
> Does anyone consider a machine that doesn't implement any sort of
> hardware stack, for example, a marketplace contender?
I don't, for the simple reason that I don't know of any that aren't, by
today's standards, ludicrously slow.
If a hypothetical machine were to be released that didn't have stack
support of some sort in hardware (even if just autodecrement and
autoincrement addressing modes - for example, the Super-H)? I'd want
to know what it had that made its maker think it worth making despite
that.
However, I have trouble imagining a machine on which it is difficult to
implement a stack. Even the machines of old which "didn't have stacks"
generally had (what we would today call) addressing modes that made it
possible to implement them without too much pain. (What they usually
didn't have was an easy way to get procedure call return addresses onto
the stack, like one I remember hearing of whose call instruction stored
the return address just before the beginning of the called procedure.
While I don't know any such machines well enough to be sure, I would
imagine a return stack could be maintained there by slightly
complicating the procedurecall and return sequences - in this crowd,
I'm sure I'll be corrected if I'm wrong! :-)
/~\ The ASCII Mouse
\ / Ribbon Campaign
X Against HTML mouse at rodents-montreal.org
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
------------------------------
Message: 58
Date: Thu, 24 Sep 2015 05:35:54 -0700
From: Al Kossow <aek at bitsavers.org>
To: cctalk at classiccmp.org
Subject: Re: Regarding Manuals
Message-ID: <5603EE2A.8020308 at bitsavers.org>
Content-Type: text/plain; charset=windows-1252; format=flowed
On 9/24/15 2:41 AM, Pontus Pihlgren wrote:
> Hi
>
> I have more manuals than I really have room for. Lots and lots of VMS
> binders and softcover books. And now my employer is throwing out box
> upon box of SUN, Ultrix, tru64 and various literature.
>
I'd like to get a set of SunOS 1.x manuals to fill out what I just
uploaded to bitsavers, and any manuals for SunOS layered products that
I haven't already uploaded. Hoping they still had manuals that old.
------------------------------
Message: 59
Date: Thu, 24 Sep 2015 14:53:15 +0200
From: Pontus Pihlgren <pontus at Update.UU.SE>
To: "General Discussion: On-Topic and Off-Topic Posts"
<cctalk at classiccmp.org>
Subject: Re: Regarding Manuals
Message-ID: <20150924125315.GC9183 at Update.UU.SE>
Content-Type: text/plain; charset=us-ascii
On Thu, Sep 24, 2015 at 05:35:54AM -0700, Al Kossow wrote:
> On 9/24/15 2:41 AM, Pontus Pihlgren wrote:
> >Hi
> >
> >I have more manuals than I really have room for. Lots and lots of VMS
> >binders and softcover books. And now my employer is throwing out box
> >upon box of SUN, Ultrix, tru64 and various literature.
> >
>
> I'd like to get a set of SunOS 1.x manuals to fill out what I just
> uploaded to bitsavers, and any manuals for SunOS layered products
> that
> I haven't already uploaded. Hoping they still had manuals that old.
>
I think the oldest I have seen from Sun is from 1987 or 88. Is that old
enough?
/P
------------------------------
Message: 60
Date: Thu, 24 Sep 2015 09:16:20 -0400
From: Toby Thain <toby at telegraphics.com.au>
To: General Discussion: On-Topic and Off-Topic Posts
<cctalk at classiccmp.org>
Subject: Re: Structured Fortran - was Re: Self modifying code, lambda
calculus
Message-ID: <5603F7A4.60808 at telegraphics.com.au>
Content-Type: text/plain; charset=utf-8; format=flowed
On 2015-09-24 3:04 AM, ben wrote:
> On 9/23/2015 11:22 PM, Eric Smith wrote:
>
>> ISO/IEC 9899:1999(E) ?3.6 ?1 - a byte has to hold any member of the
>> basic character set
>> ISO/IEC 9899:1999(E) ?3.7.1 ?1 - a character is a C bit representation
>> that fits in a byte
>> ISO/IEC 9899:1999(E) ?5.2.4.2.1 ?1 - the size of a char is CHAR_BIT
>> bits, which is at least 8
>> ISO/IEC 9899:1999(E) ?6.2.6.1 ?2-4 - everything other than bitfields
>> consists of bytes
>
> Bla Bla Bla ...
> What happened to seven bit ASCII?
> I think the major change in C from the OTHER programing languages
> is BYTE addressing. Even Pascal from what I have seen packs characters
> in words of some kind. That is main dividing line in how memory
> can be accessed. char *ptr++ vs array(foo-1)
Depends on the Pascal. Apple chose (Object) Pascal as its principal
systems and applications programming language for at least a decade
(Lisa, 68K Mac, etc), and its memory addressing capabilities, in
particular byte arrays, were equivalent to C's. Many other Pascals had
similar extensions (I seem to recall Turbo Pascal did).
--Toby
>
> 0-99 can hold a trimmed character set and 10 digits per int.
> 5 chars per word sounds right on decimal machine.
> Logic operations would be on the digit rather the binary
> level. This may not be standard C but I has the early
> PDP 11 C feel if they I developed UNIX on decimal machine.
>
> Ben.
>
>
>
>
>
>
------------------------------
Message: 61
Date: Thu, 24 Sep 2015 10:06:51 -0400
From: "Mike Stein" <mhs.stein at gmail.com>
To: "General Discussion: On-Topic and Off-Topic Posts"
<cctalk at classiccmp.org>
Subject: Re: Anyone recognize this bus/form factor?
Message-ID: <D3A61F3A56BA41069507A1E2A18B491F at 310e2>
Content-Type: text/plain; format=flowed; charset="UTF-8";
reply-type=original
Found a few more boards; I guess the displays,
optocouplers and surge suppressors suggest an
industrial system of some sort, perhaps custom or
limited production.
Wonder why that type of connector wasn't used more
often for a bus instead of presumably more
expensive edge connectors; I think I do have some
(CDC?) boards that are the opposite, i.e. pins
plugging into sockets on the backplane.
https://picasaweb.google.com/115794482077177620188/Mystery68xxCards?authkey=Gv1sRgCKq4r5zr3fjGiwE
----- Original Message -----
From: "Mike Ross" <tmfdmike at gmail.com>
To: "General Discussion: On-Topic and Off-Topic
Posts" <cctalk at classiccmp.org>
Sent: Wednesday, September 23, 2015 11:43 PM
Subject: Re: Anyone recognize this bus/form
factor?
> That's odd.
>
> I can't say for sure but... it has the feel of
> something that might
> have belonged in a terminal or keyboard...
> character generator or
> something... stab in the dark really.
>
> Mike
>
> On Thu, Sep 24, 2015 at 2:05 PM, Mike Stein
> <mhs.stein at gmail.com> wrote:
>> 68xx system, unusual (in my experience) 40-pin
>> single row header bus.
>>
>> Anyone recognize it?
>>
>> https://lh3.googleusercontent.com/-jRSv5KbuziQ/VgNYaQ5j1gI/AAAAAAAAAXY/A5k2n04KROo/s720-Ic42/Mystery68xx.JPG
>>
>
>
>
> --
>
> http://www.corestore.org
> 'No greater love hath a man than he lay down his
> life for his brother.
> Not for millions, not for glory, not for fame.
> For one person, in the dark, where no one will
> ever know or see.'
------------------------------
Message: 62
Date: Thu, 24 Sep 2015 10:00:47 -0500
From: Jay Jaeger <cube1 at charter.net>
To: cctalk at classiccmp.org
Subject: Re: Structured Fortran - was Re: Self modifying code, lambda
calculus
Message-ID: <5604101F.2090207 at charter.net>
Content-Type: text/plain; charset=utf-8
On 9/24/2015 12:22 AM, Eric Smith wrote:
> On Wed, Sep 23, 2015 at 8:30 AM, Jay Jaeger <cube1 at charter.net> wrote:
>> An int just has to be able to store numbers of a certain magnitude.
>> Same with long. You do have to be able to convert between longs (and
>> possibly ints) and addresses (*). So, you make an int 5 digits (which
>> matches the natural length of addresses) and longs something like 10
>> digits. You don't have to simulate anything, near as I can tell. Then
>> the length of an int is 5 and a long is 10 (instead of the more typical
>> 2 and 4).
>
> And the length of a char? It's required that all types other than
> bitfields be fully represented as multiple chars, not e.g. an int
> being two and a half chars, and a char has to cover at least the range
> 0..255, or -128..127, and it has to have a range based on a power of
> two.
>
> ISO/IEC 9899:1999(E) ?3.6 ?1 - a byte has to hold any member of the
> basic character set
> ISO/IEC 9899:1999(E) ?3.7.1 ?1 - a character is a C bit representation
> that fits in a byte
> ISO/IEC 9899:1999(E) ?5.2.4.2.1 ?1 - the size of a char is CHAR_BIT
> bits, which is at least 8
> ISO/IEC 9899:1999(E) ?6.2.6.1 ?2-4 - everything other than bitfields
> consists of bytes
>
> ISO/IEC 9899:1999(E) ?6.2.6.1 ?5 - Some data types other than char may
> have machine representations that can't use all of the possible bit
> patterns of the storage allocated; those representations are called
> "trap representations". The char (and unsigned char) types can't have
> trap representations.
>
> ISO/IEC 9899:199(E) ?6.2.6.2 ?1 - unsigned integer types must have a
> range of 0 to (2^n)-1, for some natural number n.
> ISO/IEC 9899:199(E) ?6.2.6.2 ?2 - signed integer types must have a
> range of -(2^n) to (2^n)-1 or -((2^n)-1) to (2^n)-1.
>
> On a decimal machine, if you use three digits for a char, you have to
> arrange that all your other types are multiples of three digits, with
> each three-digit group only using valid char representations, because
> accessing a char/byte out of a larger integer type is not allowed to
> be a trap representation, because chars can't have a trap
> representation.
I don't *have* to do any such thing.
>
> If an unsigned char is three digits with values from 0..255, an
> unsigned int can't be five digits. It has to be six digits, and the
> only valid representations for it would have values of 0..65535. It
> can't have any valid values in the range of 65536..999999.
>
It does not *have* to be six digits.
You seem to be supposing that I said one could/would implement ANSI/ISO
C on a 1410 in native code (as opposed to some kind of binary
threaded-code simulator that has been suggested). I did not. I said C,
and by that I meant something presumably contemporary with the machine
in its last years. I would not suggest that one would implement
ANSI/ISO C on such a machine, any more than I would expect to implement
current versions of FORTRAN on such a machine. Heck, there wasn't even
a FORTRAN IV for the 1410.
I would expect a char to be 6 or 7 bits on a 1410 - one storage
character, rather than 8 (one could conceivably use the word-mark for a
char bit to get 7 bits, and it would make some sense to do so, but if
abused (say, by accessing an int as char [5]) could result in a wordmark
in the middle of an int, which it would be good to avoid if at all
possible to avoid having to move integer types to an intermediate
storage location using record marks to terminate the move rather than
wordmarks).
An int would be 5 characters long.
If one goes back to the definition of C in "The C Programming Language",
then one sees a less restrictive specification the the contemporary
ANSI/ISO specification. The restrictions of ANSI/ISO C came later
because of things that folks tended to assume and do in their C programs
because of the hardware it typically ran on, i.e., that chars were
capable of holding 8 bit binary numbers.
"Objects declared as characters (char) are large enough to store any
member of the implementation's character set, and if a genuine character
from that character set is stored in a character variable, its *value*
is *equivalent* to the integer code for that character. Other values
may be stored into character variables, but the implementation is
machine-dependent." (asterisk emphasis added).
"Equivalent" is extremely important here, as it frees one from the
notion of it having to be the exact same bit representation. It means
that if you cast from char to int (access it as a value), or pass a char
as a formal parameter, the int gets the value of the character as a set
of bits, and vice versa. It does NOT require that the int be the
*identical* bits as the char.
Common practice is, of course, to use chars to store small, but still
useful, integer values, in this case, -32 to +31 (6 bits) or -64 to +63
(7 bits)). Would this break some programs that assume a char can hold
values from -127 to 127? Of course. Would those programs be "fixable"
to the extent that they were not dependent upon machine I/O hardware and
the like? Yes, they should be.
""Plain" integers have the natural size suggested by the host machine
architecture".
Thus one would end up with a C char type which is only slightly
different from FORTRAN CHARACTER variables, but which can still store
small integer values in the spirit of C.
Enough already.
JRJ
------------------------------
Message: 63
Date: Thu, 24 Sep 2015 10:11:16 -0500
From: Jay Jaeger <cube1 at charter.net>
To: cctalk at classiccmp.org
Subject: Re: Structured Fortran - was Re: Self modifying code, lambda
calculus
Message-ID: <56041294.1060803 at charter.net>
Content-Type: text/plain; charset=utf-8
On 9/24/2015 2:04 AM, ben wrote:
> On 9/23/2015 11:22 PM, Eric Smith wrote:
>
>
> 0-99 can hold a trimmed character set and 10 digits per int.
> 5 chars per word sounds right on decimal machine.
> Logic operations would be on the digit rather the binary
> level.
On a 1410 (or 1401) 0-63 can hold the entire character set using
char/int conversion instead of storing chars as their native bits, and
then we have 5 digits per int as the native integer size (size of an
address).
0-127 would be required to hold a character with a work mark bit, which
I think one would probably want to make available at a character level,
but try and avoid having them set inside of ints.
Also, on a 1410 or a 1401 with the right optional features, bitwise
operations (bitwise &^|) could still be carried out on a binary level
without undue difficulty.
As you say, logic operations (&&, ||) would presumably use int 0 and 1 -
but could still be carried out on a binary level.
>This may not be standard C but I has the early
> PDP 11 C feel if they I developed UNIX on decimal machine.
>
> Ben.
>
Precisely.
JRJ
------------------------------
Message: 64
Date: Thu, 24 Sep 2015 10:23:55 -0500
From: Chris Elmquist <chrise at pobox.com>
To: "General Discussion: On-Topic and Off-Topic Posts"
<cctalk at classiccmp.org>
Subject: Re: Anyone recognize this bus/form factor?
Message-ID: <20150924152355.GQ4403 at n0jcf.net>
Content-Type: text/plain; charset=us-ascii
On Thursday (09/24/2015 at 10:06AM -0400), Mike Stein wrote:
> Found a few more boards; I guess the displays, optocouplers and surge
> suppressors suggest an industrial system of some sort, perhaps custom or
> limited production.
>
> Wonder why that type of connector wasn't used more often for a bus instead
> of presumably more expensive edge connectors; I think I do have some
> (CDC?)
> boards that are the opposite, i.e. pins plugging into sockets on the
> backplane.
>
> https://picasaweb.google.com/115794482077177620188/Mystery68xxCards?authkey=Gv1sRgCKq4r5zr3fjGiwE
Those are the same connectors used on the Heathkit H8 and H89 backplanes
but those are definitely not cards that plug into the backplane of either
of those machines.
Chris
--
Chris Elmquist
------------------------------
Message: 65
Date: Thu, 24 Sep 2015 09:06:25 -0700 (PDT)
From: Fred Cisin <cisin at xenosoft.com>
To: "General Discussion: On-Topic and Off-Topic Posts"
<cctalk at classiccmp.org>
Subject: Re: Structured Fortran - was Re: Self modifying code, lambda
calculus
Message-ID: <Pine.LNX.4.64.1509240856460.309 at shell.lmi.net>
Content-Type: TEXT/PLAIN; charset=UTF-8; format=flowed
On Wed, 23 Sep 2015, Eric Smith wrote:
> And the length of a char? It's required that all types other than
> bitfields be fully represented as multiple chars, not e.g. an int
> being two and a half chars, and a char has to cover at least the range
> 0..255, or -128..127, and it has to have a range based on a power of
> two.
> ISO/IEC 9899:1999(E) ?3.6 ?1 . . .
> ISO/IEC 9899:1999(E) ?3.7.1 ?1 . . .
> ISO/IEC 9899:1999(E) ?5.2.4.2.1 ?1 . . .
> ISO/IEC 9899:1999(E) ?6.2.6.1 ?2-4 - everything other than bitfields
> consists of bytes
> ISO/IEC 9899:1999(E) ?6.2.6.1 ?5 - Some data types other than char may
> ISO/IEC 9899:199(E) ?6.2.6.2 ?1 - unsigned integer types must have a
> ISO/IEC 9899:199(E) ?6.2.6.2 ?2 - signed integer types must have a
> On a decimal machine, if you use three digits for a char, you have to
> arrange that all your other types are multiples of three digits, with
> each three-digit group only using valid char representations, because
> accessing a char/byte out of a larger integer type is not allowed to
> be a trap representation, because chars can't have a trap
> representation.
> If an unsigned char is three digits with values from 0..255, an
> unsigned int can't be five digits. It has to be six digits, and the
> only valid representations for it would have values of 0..65535. It
> can't have any valid values in the range of 65536..999999.
The original "challenge" just said "C".
THAT is all ANSI C.
K&R C did not have those limitations. If you wanted to build a C with a 7
bit short, a 13 bit int, and a 19 bit long, it was OK.
Only limits were that the sizeof an int couldn't be smaller than the size
of a short, sizeof a long couldn't be less than that of an int, etc.
I am not claiming that I could create a C compiler for 1401/1410, but
these restrictions only preclude ANSI C.
Note: I am also not saying that doing so would be a good idea.
------------------------------
Message: 66
Date: Thu, 24 Sep 2015 09:08:44 -0700 (PDT)
From: Fred Cisin <cisin at xenosoft.com>
To: "General Discussion: On-Topic and Off-Topic Posts"
<cctalk at classiccmp.org>
Subject: Re: Honeywell/Bull DPS-6 deskside info?
Message-ID: <Pine.LNX.4.64.1509240907080.309 at shell.lmi.net>
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
On Thu, 24 Sep 2015, COURYHOUSE at aol.com wrote:
> is it a dps 6 or 8?
I am actually sincerely sorry that you are having another migraine that
causes you to press the spacebar.
But, I do have to point out that it makes you sound like William Shatner.
------------------------------
Message: 67
Date: Thu, 24 Sep 2015 12:55:41 -0400
From: COURYHOUSE at aol.com
To: cctalk at classiccmp.org
Subject: Re: Honeywell/Bull DPS-6 deskside info?
Message-ID: <aaf55.450df234.4335850b at aol.com>
Content-Type: text/plain; charset="US-ASCII"
pretty funny!
maybe I should be fortunate enough to have his salary also!?
#ed
In a message dated 9/24/2015 9:08:48 A.M. US Mountain Standard Time,
cisin at xenosoft.com writes:
On Thu, 24 Sep 2015, COURYHOUSE at aol.com wrote:
> is it a dps 6 or 8?
I am actually sincerely sorry that you are having another migraine that
causes you to press the spacebar.
But, I do have to point out that it makes you sound like William Shatner.
End of cctalk Digest, Vol 15, Issue 24
**************************************
More information about the cctech
mailing list