22 Sep
2015
22 Sep
'15
12:50 p.m.
Pretty futile to restore until I have manuals and a load tape if
needed in front of me. The previous owner said it powered up and did not
blow smoke so that is a good thing... but even still that was many
many years ago.
Unlike you Jay that has a 'mountain' of DG stuff in front of you to
*wicker basket something together from... all I have is this one lonely
rack!
I have no familiarity with DG op/sys at all.... never ran one ..
I did had an orig NOVA ( lo s/n no other suffix after it... about
the first year I was in the computer business sold it to someone... I
did try to track it back but they guy has scrapped it... as I
found out 30 years later.
BUT! I figure DG sould have some sort of representation here... and
if it attracts MORE DG so be it!Least case it needs a terminal to
display with it and ... yes... A POSTER!
This month's 'make computer work ' project is HP-3000 related.
In a message dated 9/22/2015 12:04:36 P.M. US Mountain Standard Time,
jwest at classiccmp.org writes:
Ed wrote...
----
Our Eclipse is not as grand as some photos ,,, and the tape drive is
a
small side by side reel unit that fits in the single rack here is a
photo of ours....
http://www.smecc.org/data_general.htm
----
There's nothing non-grand about that. Nice non-blinken Eclipse with 6125
tape drive, and some type of disk unit in the bottom. Nice.
And...
----
had it for years need manuals etc and maybe some sales lit.
or
scans of advertising material to display with it... but yea... it
cries out to have a terminal with it!
----
No, it cries out to be restored and run rather than just sitting under a
poster. But that's just me.
J
22 Sep
22 Sep
3:25 p.m.
Ed wrote...
----
Pretty futile to restore until I have manuals and a load tape if
needed in front of me.
----
Not futile at all. Taking it apart, cleaning it up, replacing anything
obviously bad, checking out the power supply.... all things you can likely
do without a manual. You could go a little further than that just by asking
a few questions here; folks are glad to help! Think of all the great stuff
you'd learn along the way!! You'd find manuals and tapes at some point I'm
sure!
----
Unlike you Jay that has a 'mountain' of DG stuff in front of you to
*wicker basket something together from... all I have is this one lonely
rack!
----
Not sure what you're driving at there, but when I'm done... all I will have
is one lonely rack :) Nothing wrong with that!
Not to mention, there's the "classiccmp law of attraction". Basically if
you
get just part of a machine, the rest will suddenly start appearing :)
----
BUT! I figure DG sould have some sort of representation here... and
if it attracts MORE DG so be it!Least case it needs a terminal to
display with it and ... yes... A POSTER!
----
Awesome. What minicomputer systems do you have on public display besides the
DG? I'm glad to see more DG representation of course :)
----
This month's 'make computer work ' project is HP-3000 related.
----
I'm a bit of an HP fan ;) What's cooking 3K-related?
J
7 p.m.
New subject: Thoughts on manual database design?
So, I am looking to convert my old Access database I have used for many
years to a MySQL database, with the expectation that I will eventually
publish it on a web page for public lookup.
Below is my first cut at a database design for it. I'd be happy for
comments and suggestions, to the list or directly. Note, however, that
I don't expect to do this to the same level of complexity and
completeness that one might if they were the library of congress, a
major university library, etc. So, some suggestions to generalize may
be quietly ignored, even if they would in principle, be the "right
thing" according to some criteria or other.
This would be used for manuals, per se, print sets, etc. Quite possibly
for books as well.
What follows amounts to a data dictionary:
Table MANUAL:
This is the primary table of manuals. Many of the fields will be
available for string and/or pull down search, as appropriate.
Machine_MFG: VARCHAR(32)
The manufacturer of the machine(s) to which the manual applies
Part of unique key.
Pull down search.
Manual_Number: VARCHAR(40)
The manual number, including version strings, etc.
In some cases, this may be an SBN or ISBN.
Part of unique key
String search.
Artifact_ID: CHAR(16) [format/type still under consideration]
The local identifier for the manual/artifact.
Part of unique key.
Will be generated if none is entered during creation/update.
(Required because I may have more than one copy of a given manual).
Publisher: VARCHAR(32)
The publisher of the manual. (Typically will be the same as the
Machine MFG - but not necessarily always)
May not be NULL.
Type: VARCHAR(16)
Manual, Drawing (== printset, schematic, etc.), Book, ...
Pull down search.
Original: BOOLEAN
True if an original manual. False if a copy ("Xerox").
Missing: BOOLEAN
True if the manual is missing (i.e., is not where it is supposed to
be, and the actual location is not known).
Title: VARCHAR(255)
The title of the manual, including any subtitles.
Suggest "; " to separate multiple titles/subtitles
May not be NULL
String search.
Incomplete: CHAR(1)
Indicates if the manual is not a complete copy.
NULL indicates the copy is complete.
Year: DATE
The year the manual was published / printed / copyrighted.
May be NULL, signifying the date is unknown / not entered.
Location: VARCHAR(20)
The general location of the manual in my inventory
May be NULL, signifying the manual is not in my inventory.
Cabinet: CHAR(2)
The ID of the cabinet or box in which the manual is stored, if any.
May be NULL, even if the manual is in my inventory.
May not be NULL if Drawer is not NULL.
Drawer: CHAR(2)
The ID of the drawer of the cabinet in which the manual is stored,
if any. May be NULL.
Inventory_Date: DATE
The date that the manual was last inventoried.
Filename: VARCHAR(255)
The name of the file which is an image of the manual in my local
file storage.
OnlineLocation: VARCHAR(255)
URL of the manual located online (e.g., the bitsavers URL)
May be NULL. This does NOT mean that the manual is not online.
Of course, this field can become out of date.
OnlineVersion: CHAR(1)
= means that the online manual is the same version as this one
means that there is no equal version online, but there
is a
later version
< means there is no equal or later version online, but there is an
earlier version.
OnlineMD5: CHAR(32)
MD5 hash of online manual - used to check for moved manuals. ;)
TABLE MachineManual
This table cross references manuals to the machine(s) to which they
apply. This list will NOT be guaranteed to be complete. During inquiry
and update, this will be a list of machines with a separator character
in between which will not be allowed in Machine_MFG. During an update,
the entire list will be replaced with the first one being flagged as the
primary machine.
MachineMFG: (See above). Part of the unique key for this table.
Manual_Number: (See above) Part of the unique key for this table.
Machine: VARCHAR(16)
One of the machine(s) to which this manual applies.
Part of the unique key for this table.
Primary_Machine: BOOLEAN
When true, indicates that this machine should be listed first
in the list of applicable machines. For a peripheral, this will
typically be the machine for which the peripheral was originally
designed.
So a list of machines for an RX01 manual might be:
PDP-11, RX01, RX01, VAX-11
TABLE Machines
A lookup table of valid machines. Only column is Machine (See above).
Naturally this table will change over time - I anticipate that an update
where the updater (me) keys in an "invalid" one will be greeted with
some kind of confirmation panel.
TABLE Manufacturers
A lookup table of valid manufacturers. Only column is Machine_MFG
(See above). Naturally this table will change over time - I anticipate
that an update where the updater (me) keys in an "invalid" one will be
greeted with some kind of confirmation panel.
Table Types
A lookup table of valid Types. Only column is Type (See above)
TABLE: LastGeneratedArtifact
The last generated artifact ID - used to assign new artifact numbers
when one is not manually entered. Algorithm TBD. One column:
Artifact_ID (See above)
TABLE: Locations
A table of valid locations (e.g. Basement, Garage, STORAGE, Unknown, etc.)
Used for convenience during data entry.
(Once this one is done and running (at least locally), the next one is
probably media (tapes, floppies, etc.) which is not too bad, and then
machines, cards and parts, which is more complicated for lots of reasons).
After those are done (hopefully by the end of the year - I am retired
and this will be my primary focus for a while) comes the design for a
database for SMS cards and for the IBM 1410 use of SMS cards.
JRJ
8:12 p.m.
New subject: Thoughts on manual database design?
My recommendation would be to ensure compatibility with the MARC database format. Even if
you don't include all the fields, the fields you do have should be compatible. If you
look you should find Open Source projects that are MARC compatible. It's been several
years since I looked into this, and then I was populating a MARC database from a massive
Excel spreadsheet.
Zane
On Sep 22, 2015, at 7:00 PM, Jay Jaeger <cube1 at charter.net> wrote:
So, I am looking to convert my old Access database I
have used for many
years to a MySQL database, with the expectation that I will eventually
publish it on a web page for public lookup.
Below is my first cut at a database design for it. I'd be happy for
comments and suggestions, to the list or directly. Note, however, that
I don't expect to do this to the same level of complexity and
completeness that one might if they were the library of congress, a
major university library, etc. So, some suggestions to generalize may
be quietly ignored, even if they would in principle, be the "right
thing" according to some criteria or other.
This would be used for manuals, per se, print sets, etc. Quite possibly
for books as well.
What follows amounts to a data dictionary:
Table MANUAL:
This is the primary table of manuals. Many of the fields will be
available for string and/or pull down search, as appropriate.
Machine_MFG: VARCHAR(32)
The manufacturer of the machine(s) to which the manual applies
Part of unique key.
Pull down search.
Manual_Number: VARCHAR(40)
The manual number, including version strings, etc.
In some cases, this may be an SBN or ISBN.
Part of unique key
String search.
Artifact_ID: CHAR(16) [format/type still under consideration]
The local identifier for the manual/artifact.
Part of unique key.
Will be generated if none is entered during creation/update.
(Required because I may have more than one copy of a given manual).
Publisher: VARCHAR(32)
The publisher of the manual. (Typically will be the same as the
Machine MFG - but not necessarily always)
May not be NULL.
Type: VARCHAR(16)
Manual, Drawing (== printset, schematic, etc.), Book, ...
Pull down search.
Original: BOOLEAN
True if an original manual. False if a copy ("Xerox").
Missing: BOOLEAN
True if the manual is missing (i.e., is not where it is supposed to
be, and the actual location is not known).
Title: VARCHAR(255)
The title of the manual, including any subtitles.
Suggest "; " to separate multiple titles/subtitles
May not be NULL
String search.
Incomplete: CHAR(1)
Indicates if the manual is not a complete copy.
NULL indicates the copy is complete.
Year: DATE
The year the manual was published / printed / copyrighted.
May be NULL, signifying the date is unknown / not entered.
Location: VARCHAR(20)
The general location of the manual in my inventory
May be NULL, signifying the manual is not in my inventory.
Cabinet: CHAR(2)
The ID of the cabinet or box in which the manual is stored, if any.
May be NULL, even if the manual is in my inventory.
May not be NULL if Drawer is not NULL.
Drawer: CHAR(2)
The ID of the drawer of the cabinet in which the manual is stored,
if any. May be NULL.
Inventory_Date: DATE
The date that the manual was last inventoried.
Filename: VARCHAR(255)
The name of the file which is an image of the manual in my local
file storage.
OnlineLocation: VARCHAR(255)
URL of the manual located online (e.g., the bitsavers URL)
May be NULL. This does NOT mean that the manual is not online.
Of course, this field can become out of date.
OnlineVersion: CHAR(1)
= means that the online manual is the same version as this one
means that there is no equal version online, but
there is a
later version
< means there is no equal or later version online, but there is an
earlier version.
OnlineMD5: CHAR(32)
MD5 hash of online manual - used to check for moved manuals. ;)
TABLE MachineManual
This table cross references manuals to the machine(s) to which they
apply. This list will NOT be guaranteed to be complete. During inquiry
and update, this will be a list of machines with a separator character
in between which will not be allowed in Machine_MFG. During an update,
the entire list will be replaced with the first one being flagged as the
primary machine.
MachineMFG: (See above). Part of the unique key for this table.
Manual_Number: (See above) Part of the unique key for this table.
Machine: VARCHAR(16)
One of the machine(s) to which this manual applies.
Part of the unique key for this table.
Primary_Machine: BOOLEAN
When true, indicates that this machine should be listed first
in the list of applicable machines. For a peripheral, this will
typically be the machine for which the peripheral was originally
designed.
So a list of machines for an RX01 manual might be:
PDP-11, RX01, RX01, VAX-11
TABLE Machines
A lookup table of valid machines. Only column is Machine (See above).
Naturally this table will change over time - I anticipate that an update
where the updater (me) keys in an "invalid" one will be greeted with
some kind of confirmation panel.
TABLE Manufacturers
A lookup table of valid manufacturers. Only column is Machine_MFG
(See above). Naturally this table will change over time - I anticipate
that an update where the updater (me) keys in an "invalid" one will be
greeted with some kind of confirmation panel.
Table Types
A lookup table of valid Types. Only column is Type (See above)
TABLE: LastGeneratedArtifact
The last generated artifact ID - used to assign new artifact numbers
when one is not manually entered. Algorithm TBD. One column:
Artifact_ID (See above)
TABLE: Locations
A table of valid locations (e.g. Basement, Garage, STORAGE, Unknown, etc.)
Used for convenience during data entry.
(Once this one is done and running (at least locally), the next one is
probably media (tapes, floppies, etc.) which is not too bad, and then
machines, cards and parts, which is more complicated for lots of reasons).
After those are done (hopefully by the end of the year - I am retired
and this will be my primary focus for a while) comes the design for a
database for SMS cards and for the IBM 1410 use of SMS cards.
JRJ
9:43 p.m.
New subject: Thoughts on manual database design?
On 9/22/2015 10:12 PM, Zane Healy wrote:
My recommendation would be to ensure compatibility
with the MARC database format. Even if you don't include all the fields, the fields
you do have should be compatible. If you look you should find Open Source projects that
are MARC compatible. It's been several years since I looked into this, and then I was
populating a MARC database from a massive Excel spreadsheet.
Zane
I checked quite a bit of it out, including:
http://www.loc.gov/marc/bibliographic/
http://www.loc.gov/marc/umb/um01to06.html
https://en.wikipedia.org/wiki/MARC_standards
https://en.wikipedia.org/wiki/MARC_standards#MARC_21
http://www.loc.gov/standards/marcxml/xml/spy/spy.html
MARC does not seem at all applicable to my goals - MARC is not at all a
"database" format. Instead it is a (very complicated and cumbersome)
format standard for binary or (in the case of MARCXML) XML transmission
(interchange) of a very small portion of the sort of information I would
have in my database (like, the publisher and title). The standard is
for records that have been folded into a single binary or XML
representation of the metadata about a publication. Furthermore, and
most importantly, the standard doesn't really address the
characteristics of individual fields at all (aside from encoding special
characters, which I would not want to do at all). Finally, MARC and
MarcXML are *way* more baroque and complicated than I would ever want to
deal with (see my original statement).
Trying to apply MARC to my situation would seem to be akin to taking a
Cessna private plane to a major airline hanger for maintenance. Yeah,
it could be done: a great cost and expense, with the possibility that
due to mismatch in experience, potentially fatal mistakes might be made.
The info on the Library of Congress "authority records" for identifying
publishers / manufacturers was interesting. But, really, the important
thing that points to is to have those sorts of fields be constrained to
defined values so that a consistent set is used (instead of just free
form text), which I had already planned to do.
So, almost no value for mountains of work.
The value of MARC would be if someone wanted to take all of my documents
at some point and send them to a real library to include in its catalog.
Then one might transform the rows of my database into MarcXML. Not
something I care to do or worry about.
(BTW, My memory of that acronym is "Machine Assisted Resource
Coordinator", a small-sized Unix work-alike developed by Ed Ziemba (RIP)
using Leor Zolman's BDS C compiler).
JRJ
26 Sep
26 Sep
10:30 p.m.
New subject: MARC (was Re: Thoughts on manual database design?)
On Tue, Sep 22, 2015, Jay Jaeger wrote:
(BTW, My memory of that acronym is "Machine
Assisted Resource
Coordinator", a small-sized Unix work-alike developed by Ed Ziemba (RIP)
using Leor Zolman's BDS C compiler).
I'm having trouble finding much about this system; most of it is on your
web page and the Wikipedia page for BDS C, which appears to borrow quite
a bit from your page. Was MARC an OS itself, or a Unix-like layer on
CP/M? Is it available to download and play with?
--
Eric Christopherson
11 p.m.
New subject: MARC (was Re: Thoughts on manual database design?)
Not sure if it's relevant:
https://en.m.wikipedia.org/wiki/WordMARC
My brother was one of the few engineers on this product, in Palo Alto. The software ran on
dozens of different machines and architectures, using the most portable language of the
day: Fortran 77. I believe MARC was the umbrella name/company for a number of different
products.
He got me a summer job there - I had to print out the sources and then make copies for
everyone. We also wired the offices with rs-232 runs to the PRIME lurking in the basement.
Formative years...
Sent from my teeny little terminal.
On Sep 26, 2015, at 10:30 PM, Eric Christopherson
<echristopherson at gmail.com> wrote:
On Tue, Sep 22, 2015, Jay Jaeger wrote:
(BTW, My memory of that acronym is "Machine Assisted Resource
Coordinator", a small-sized Unix work-alike developed by Ed Ziemba (RIP)
using Leor Zolman's BDS C compiler).
I'm having trouble finding much about this system; most of it is on your
web page and the Wikipedia page for BDS C, which appears to borrow quite
a bit from your page. Was MARC an OS itself, or a Unix-like layer on
CP/M? Is it available to download and play with?
--
Eric Christopherson
27 Sep
27 Sep
5:48 a.m.
New subject: MARC (was Re: Thoughts on manual database design?)
Not related at all, to my knowledge.
Sent from my iPad
On Sep 27, 2015, at 01:00, Steve Algernon
<salgernon at me.com> wrote:
Not sure if it's relevant:
https://en.m.wikipedia.org/wiki/WordMARC
My brother was one of the few engineers on this product, in Palo Alto. The software ran
on dozens of different machines and architectures, using the most portable language of the
day: Fortran 77. I believe MARC was the umbrella name/company for a number of different
products.
He got me a summer job there - I had to print out the sources and then make copies for
everyone. We also wired the offices with rs-232 runs to the PRIME lurking in the basement.
Formative years...
Sent from my teeny little terminal.
>> On Sep 26, 2015, at 10:30 PM, Eric Christopherson <echristopherson at
gmail.com> wrote:
>>
>> On Tue, Sep 22, 2015, Jay Jaeger wrote:
>> (BTW, My memory of that acronym is "Machine Assisted Resource
>> Coordinator", a small-sized Unix work-alike developed by Ed Ziemba (RIP)
>> using Leor Zolman's BDS C compiler).
>
> I'm having trouble finding much about this system; most of it is on your
> web page and the Wikipedia page for BDS C, which appears to borrow quite
> a bit from your page. Was MARC an OS itself, or a Unix-like layer on
> CP/M? Is it available to download and play with?
>
> --
> Eric Christopherson
11:05 a.m.
New subject: MARC (was Re: Thoughts on manual database design?)
On Sat, 26 Sep 2015, Steve Algernon wrote:
Not sure if it's relevant:
https://en.m.wikipedia.org/wiki/WordMARC
My brother was one of the few engineers on this product, in Palo Alto.
The software ran on dozens of different machines and architectures,
using the most portable language of the day: Fortran 77. I believe MARC
was the umbrella name/company for a number of different products.
OCLC and Library Of Congress are sure going to be surprised that their
MAchine-Readable-Cataloging system is the umbrella name/company for a
number of unrelated products! Was Z39.50 similarly commercialized?
MARC can be very efficient or very bloated. For example, if you allocate
arrays for all fields, then a record can be up to 250K (think 8" SSSD).
But, with even half-assed dynamic allocation to use the space needed,
rather than the maximum that it could be, a very crude MARC record editor
can be done on an Atari Portfolio.
9:37 a.m.
New subject: MARC (was Re: Thoughts on manual database design?)
On 9/27/2015 12:30 AM, Eric Christopherson wrote:
On Tue, Sep 22, 2015, Jay Jaeger wrote:
I'm not surprised, as it was never available as a product. I originally
inquired about it after an article about it in the BDS C User's Group
newsletter, and talked with Ed Ziemba, and he agreed to send me a copy
to play with / test. I tested a few versions before Ed Ziemba's
passing, and did some work on programs like icheck/ncheck/dcheck.
It was an operating system, not a layer on top of CP/M, although it did
use the CP/M BIOS calling conventions for the I/O layer. And, until you
got your own BIOS integrated into your copy of MARC, it could boot by
starting up a CP/M program on top of your existing BIOS, which was
termed a "parasitic boot".
I had a version of "ed" running on it, but the code was "tainted" as
I
had access to a version done in PL/M that itself had ties to the
original Unix version, and had access to the Unix version code myself. I
also had a version of "make" than ran on it, that was not tainted.
(There is one article out there that supposes that MARC was doomed to
failure because the 8080 machine address was too small. That is an
erroneous speculation from my perspective - given that programs like BDS
C, "ed" and "make" could run on it is pretty strong evidence to the
contrary).
Here is an article about the accident that pretty well sums things up:
https://books.google.com/books?id=pD0EAAAAMBAJ&pg=PT14&lpg=PT14&…
(Sorry about the fragmented URL).
As the above InfoWorld article mentions, Lauren Weinstein did work on
MARC after Ed's passing, but owing to legal difficulties (and perhaps
technical ones, too, I suppose), it never made it to market. I
corresponded with Lauren back in the 80's as well as more recently when
I contemplated providing a copy to Al Kossow and the CHM. Lauren
advised me against doing so because of the aforementioned legal
difficulties. Lauren and Leor Zolman would know much more about all of
this than I did/do, as I never saw the source code.
I do not believe that the copy I had had the CP/M emulation component
that allowed CP/M programs to run on it that is mentioned in the article
above - I "just" had the Unix style system calls.
JRJ
(BTW, My memory of that acronym is "Machine
Assisted Resource
Coordinator", a small-sized Unix work-alike developed by Ed Ziemba (RIP)
using Leor Zolman's BDS C compiler).
I'm having trouble finding much about this system; most of it is on your
web page and the Wikipedia page for BDS C, which appears to borrow quite
a bit from your page. Was MARC an OS itself, or a Unix-like layer on
CP/M? Is it available to download and play with?
5:30 p.m.
New subject: MARC (was Re: Thoughts on manual database design?)
On Sun, Sep 27, 2015, Jay Jaeger wrote:
On 9/27/2015 12:30 AM, Eric Christopherson wrote:
Did it have multitasking?
--
Eric Christopherson
On Tue, Sep 22, 2015, Jay Jaeger wrote:
I'm not surprised, as it was never available as a product. I originally
inquired about it after an article about it in the BDS C User's Group
newsletter, and talked with Ed Ziemba, and he agreed to send me a copy
to play with / test. I tested a few versions before Ed Ziemba's
passing, and did some work on programs like icheck/ncheck/dcheck.
It was an operating system, not a layer on top of CP/M, although it did
use the CP/M BIOS calling conventions for the I/O layer. And, until you
got your own BIOS integrated into your copy of MARC, it could boot by
starting up a CP/M program on top of your existing BIOS, which was
termed a "parasitic boot". (BTW, My memory of that acronym is "Machine
Assisted Resource
Coordinator", a small-sized Unix work-alike developed by Ed Ziemba (RIP)
using Leor Zolman's BDS C compiler).
I'm having trouble finding much about this system; most of it is on your
web page and the Wikipedia page for BDS C, which appears to borrow quite
a bit from your page. Was MARC an OS itself, or a Unix-like layer on
CP/M? Is it available to download and play with?
9:44 p.m.
New subject: MARC (was Re: Thoughts on manual database design?)
On 9/27/2015 7:30 PM, Eric Christopherson wrote:
On Sun, Sep 27, 2015, Jay Jaeger wrote:
No, not that I recall. That would have taken additional hardware for a
timer interrupt, at the least, and my Altair never had that. I recall
pipes being done as files, ala Mini-Unix.
JRJ
On 9/27/2015 12:30 AM, Eric Christopherson
wrote:
Did it have multitasking?
On Tue, Sep 22, 2015, Jay Jaeger wrote:
I'm not surprised, as it was never available as a product. I originally
inquired about it after an article about it in the BDS C User's Group
newsletter, and talked with Ed Ziemba, and he agreed to send me a copy
to play with / test. I tested a few versions before Ed Ziemba's
passing, and did some work on programs like icheck/ncheck/dcheck.
It was an operating system, not a layer on top of CP/M, although it did
use the CP/M BIOS calling conventions for the I/O layer. And, until you
got your own BIOS integrated into your copy of MARC, it could boot by
starting up a CP/M program on top of your existing BIOS, which was
termed a "parasitic boot". (BTW, My memory of that acronym is "Machine
Assisted Resource
Coordinator", a small-sized Unix work-alike developed by Ed Ziemba (RIP)
using Leor Zolman's BDS C compiler).
I'm having trouble finding much about this system; most of it is on your
web page and the Wikipedia page for BDS C, which appears to borrow quite
a bit from your page. Was MARC an OS itself, or a Unix-like layer on
CP/M? Is it available to download and play with?
22 Sep
22 Sep
11:38 p.m.
New subject: Thoughts on manual database design?
Instead of cooking up another completely custom inventory management schema, you might
consider adhering to Dublin Core for some more modern
schema conventions:
https://en.wikipedia.org/wiki/Dublin_Core
For the dbms engine I would use MariaDB over MySql (but with some of the MySQL tool chain)
as I prefer code to remain outside the clutches of Oracle:
https://mariadb.org
It's a drop-in replacement, runs nicely and the HeidiSQL management client is very
useable.
Also, why are you restricting your field lengths so much? This is the 21st century, you
can afford to be a bit more generous on those VARCHARs :)
Final thing, are you going for a completely normalised database? (ok, I haven't
analysed your schema to any great extent)
Steve.
---------------------------- Original Message ----------------------------
Subject: Thoughts on manual database design?
From: "Jay Jaeger" <cube1 at charter.net>
Date: Wed, September 23, 2015 12:00 pm
To: cctalk at classiccmp.org
--------------------------------------------------------------------------
So, I am looking to convert my old Access database I
have used for many
years to a MySQL database, with the expectation that I will eventually
publish it on a web page for public lookup.
Below is my first cut at a database design for it. I'd be happy for
comments and suggestions, to the list or directly. Note, however, that
I don't expect to do this to the same level of complexity and
completeness that one might if they were the library of congress, a
major university library, etc. So, some suggestions to generalize may
be quietly ignored, even if they would in principle, be the "right
thing" according to some criteria or other.
This would be used for manuals, per se, print sets, etc. Quite possibly
for books as well.
What follows amounts to a data dictionary:
Table MANUAL:
This is the primary table of manuals. Many of the fields will be
available for string and/or pull down search, as appropriate.
Machine_MFG: VARCHAR(32)
The manufacturer of the machine(s) to which the manual applies
Part of unique key.
Pull down search.
Manual_Number: VARCHAR(40)
The manual number, including version strings, etc.
In some cases, this may be an SBN or ISBN.
Part of unique key
String search.
Artifact_ID: CHAR(16) [format/type still under consideration]
The local identifier for the manual/artifact.
Part of unique key.
Will be generated if none is entered during creation/update.
(Required because I may have more than one copy of a given manual).
Publisher: VARCHAR(32)
The publisher of the manual. (Typically will be the same as the
Machine MFG - but not necessarily always)
May not be NULL.
Type: VARCHAR(16)
Manual, Drawing (== printset, schematic, etc.), Book, ...
Pull down search.
Original: BOOLEAN
True if an original manual. False if a copy ("Xerox").
Missing: BOOLEAN
True if the manual is missing (i.e., is not where it is supposed to
be, and the actual location is not known).
Title: VARCHAR(255)
The title of the manual, including any subtitles.
Suggest "; " to separate multiple titles/subtitles
May not be NULL
String search.
Incomplete: CHAR(1)
Indicates if the manual is not a complete copy.
NULL indicates the copy is complete.
Year: DATE
The year the manual was published / printed / copyrighted.
May be NULL, signifying the date is unknown / not entered.
Location: VARCHAR(20)
The general location of the manual in my inventory
May be NULL, signifying the manual is not in my inventory.
Cabinet: CHAR(2)
The ID of the cabinet or box in which the manual is stored, if any.
May be NULL, even if the manual is in my inventory.
May not be NULL if Drawer is not NULL.
Drawer: CHAR(2)
The ID of the drawer of the cabinet in which the manual is stored,
if any. May be NULL.
Inventory_Date: DATE
The date that the manual was last inventoried.
Filename: VARCHAR(255)
The name of the file which is an image of the manual in my local
file storage.
OnlineLocation: VARCHAR(255)
URL of the manual located online (e.g., the bitsavers URL)
May be NULL. This does NOT mean that the manual is not online.
Of course, this field can become out of date.
OnlineVersion: CHAR(1)
= means that the online manual is the same version as this one
means that there is no equal version online, but
there is a
later version
< means there is no equal or later version online, but there is an
earlier version.
OnlineMD5: CHAR(32)
MD5 hash of online manual - used to check for moved manuals. ;)
TABLE MachineManual
This table cross references manuals to the machine(s) to which they
apply. This list will NOT be guaranteed to be complete. During inquiry
and update, this will be a list of machines with a separator character
in between which will not be allowed in Machine_MFG. During an update,
the entire list will be replaced with the first one being flagged as the
primary machine.
MachineMFG: (See above). Part of the unique key for this table.
Manual_Number: (See above) Part of the unique key for this table.
Machine: VARCHAR(16)
One of the machine(s) to which this manual applies.
Part of the unique key for this table.
Primary_Machine: BOOLEAN
When true, indicates that this machine should be listed first
in the list of applicable machines. For a peripheral, this will
typically be the machine for which the peripheral was originally
designed.
So a list of machines for an RX01 manual might be:
PDP-11, RX01, RX01, VAX-11
TABLE Machines
A lookup table of valid machines. Only column is Machine (See above).
Naturally this table will change over time - I anticipate that an update
where the updater (me) keys in an "invalid" one will be greeted with
some kind of confirmation panel.
TABLE Manufacturers
A lookup table of valid manufacturers. Only column is Machine_MFG
(See above). Naturally this table will change over time - I anticipate
that an update where the updater (me) keys in an "invalid" one will be
greeted with some kind of confirmation panel.
Table Types
A lookup table of valid Types. Only column is Type (See above)
TABLE: LastGeneratedArtifact
The last generated artifact ID - used to assign new artifact numbers
when one is not manually entered. Algorithm TBD. One column:
Artifact_ID (See above)
TABLE: Locations
A table of valid locations (e.g. Basement, Garage, STORAGE, Unknown, etc.)
Used for convenience during data entry.
(Once this one is done and running (at least locally), the next one is
probably media (tapes, floppies, etc.) which is not too bad, and then
machines, cards and parts, which is more complicated for lots of reasons).
After those are done (hopefully by the end of the year - I am retired
and this will be my primary focus for a while) comes the design for a
database for SMS cards and for the IBM 1410 use of SMS cards.
JRJ
23 Sep
23 Sep
12:41 a.m.
New subject: Thoughts on manual database design?
BIKESHED ALERT! BIKESHED ALERT!!
On 23-09-15 08:38, steven at malikoff.com wrote:
Instead of cooking up another completely custom
inventory management schema, you might consider adhering to Dublin Core for some more
modern
schema conventions:
https://en.wikipedia.org/wiki/Dublin_Core
For the dbms engine I would use MariaDB over MySql (but with some of the MySQL tool
chain) as I prefer code to remain outside the clutches of Oracle:
https://mariadb.org
It's a drop-in replacement, runs nicely and the HeidiSQL management client is very
useable.
Also, why are you restricting your field lengths so much? This is the 21st century, you
can afford to be a bit more generous on those VARCHARs :)
Final thing, are you going for a completely normalised database? (ok, I haven't
analysed your schema to any great extent)
Steve.
---------------------------- Original Message ----------------------------
Subject: Thoughts on manual database design?
From: "Jay Jaeger" <cube1 at charter.net>
Date: Wed, September 23, 2015 12:00 pm
To: cctalk at classiccmp.org
--------------------------------------------------------------------------
--
Met vriendelijke Groet,
Simon Claessen
drukknop.nl
So, I am looking to convert my old Access
database I have used for many
years to a MySQL database, with the expectation that I will eventually
publish it on a web page for public lookup.
Below is my first cut at a database design for it. I'd be happy for
comments and suggestions, to the list or directly. Note, however, that
I don't expect to do this to the same level of complexity and
completeness that one might if they were the library of congress, a
major university library, etc. So, some suggestions to generalize may
be quietly ignored, even if they would in principle, be the "right
thing" according to some criteria or other.
This would be used for manuals, per se, print sets, etc. Quite possibly
for books as well.
What follows amounts to a data dictionary:
Table MANUAL:
This is the primary table of manuals. Many of the fields will be
available for string and/or pull down search, as appropriate.
Machine_MFG: VARCHAR(32)
The manufacturer of the machine(s) to which the manual applies
Part of unique key.
Pull down search.
Manual_Number: VARCHAR(40)
The manual number, including version strings, etc.
In some cases, this may be an SBN or ISBN.
Part of unique key
String search.
Artifact_ID: CHAR(16) [format/type still under consideration]
The local identifier for the manual/artifact.
Part of unique key.
Will be generated if none is entered during creation/update.
(Required because I may have more than one copy of a given manual).
Publisher: VARCHAR(32)
The publisher of the manual. (Typically will be the same as the
Machine MFG - but not necessarily always)
May not be NULL.
Type: VARCHAR(16)
Manual, Drawing (== printset, schematic, etc.), Book, ...
Pull down search.
Original: BOOLEAN
True if an original manual. False if a copy ("Xerox").
Missing: BOOLEAN
True if the manual is missing (i.e., is not where it is supposed to
be, and the actual location is not known).
Title: VARCHAR(255)
The title of the manual, including any subtitles.
Suggest "; " to separate multiple titles/subtitles
May not be NULL
String search.
Incomplete: CHAR(1)
Indicates if the manual is not a complete copy.
NULL indicates the copy is complete.
Year: DATE
The year the manual was published / printed / copyrighted.
May be NULL, signifying the date is unknown / not entered.
Location: VARCHAR(20)
The general location of the manual in my inventory
May be NULL, signifying the manual is not in my inventory.
Cabinet: CHAR(2)
The ID of the cabinet or box in which the manual is stored, if any.
May be NULL, even if the manual is in my inventory.
May not be NULL if Drawer is not NULL.
Drawer: CHAR(2)
The ID of the drawer of the cabinet in which the manual is stored,
if any. May be NULL.
Inventory_Date: DATE
The date that the manual was last inventoried.
Filename: VARCHAR(255)
The name of the file which is an image of the manual in my local
file storage.
OnlineLocation: VARCHAR(255)
URL of the manual located online (e.g., the bitsavers URL)
May be NULL. This does NOT mean that the manual is not online.
Of course, this field can become out of date.
OnlineVersion: CHAR(1)
= means that the online manual is the same version as this one
means that there is no equal version online, but
there is a
later version
< means there is no equal or later version online, but there is an
earlier version.
OnlineMD5: CHAR(32)
MD5 hash of online manual - used to check for moved manuals. ;)
TABLE MachineManual
This table cross references manuals to the machine(s) to which they
apply. This list will NOT be guaranteed to be complete. During inquiry
and update, this will be a list of machines with a separator character
in between which will not be allowed in Machine_MFG. During an update,
the entire list will be replaced with the first one being flagged as the
primary machine.
MachineMFG: (See above). Part of the unique key for this table.
Manual_Number: (See above) Part of the unique key for this table.
Machine: VARCHAR(16)
One of the machine(s) to which this manual applies.
Part of the unique key for this table.
Primary_Machine: BOOLEAN
When true, indicates that this machine should be listed first
in the list of applicable machines. For a peripheral, this will
typically be the machine for which the peripheral was originally
designed.
So a list of machines for an RX01 manual might be:
PDP-11, RX01, RX01, VAX-11
TABLE Machines
A lookup table of valid machines. Only column is Machine (See above).
Naturally this table will change over time - I anticipate that an update
where the updater (me) keys in an "invalid" one will be greeted with
some kind of confirmation panel.
TABLE Manufacturers
A lookup table of valid manufacturers. Only column is Machine_MFG
(See above). Naturally this table will change over time - I anticipate
that an update where the updater (me) keys in an "invalid" one will be
greeted with some kind of confirmation panel.
Table Types
A lookup table of valid Types. Only column is Type (See above)
TABLE: LastGeneratedArtifact
The last generated artifact ID - used to assign new artifact numbers
when one is not manually entered. Algorithm TBD. One column:
Artifact_ID (See above)
TABLE: Locations
A table of valid locations (e.g. Basement, Garage, STORAGE, Unknown, etc.)
Used for convenience during data entry.
(Once this one is done and running (at least locally), the next one is
probably media (tapes, floppies, etc.) which is not too bad, and then
machines, cards and parts, which is more complicated for lots of reasons).
After those are done (hopefully by the end of the year - I am retired
and this will be my primary focus for a while) comes the design for a
database for SMS cards and for the IBM 1410 use of SMS cards.
JRJ
7:17 a.m.
New subject: Thoughts on manual database design?
On 9/23/2015 1:38 AM, steven at malikoff.com wrote:
Instead of cooking up another completely custom
inventory management schema, you might consider adhering to Dublin Core for some more
modern
schema conventions:
https://en.wikipedia.org/wiki/Dublin_Core
Slightly more useful than MARC, but really it comes down to just a field
naming issue.
Relatively few of my fields are present there:
Title, Publisher, Creator (what I called Machine_MFG), Date (though
their definition is really really vague), identifier (my Manual_Number),
Their type would just be "Text" or "StillImage" for all of my stuff -
not sufficiently specific for my uses.
Subject is only *roughly* equivalent to my Machine table, and would not
do the job I need done with it.
I don't plan on a lengthy description. No way I am going to enter that
much data.
For the dbms engine I would use MariaDB over MySql (but with some of the MySQL tool
chain) as I prefer code to remain outside the clutches of Oracle:
https://mariadb.org
It's a drop-in replacement, runs nicely and the HeidiSQL management client is very
useable.
I certainly understand that point of view. However, that really isn't
an issue for me, and MySQL is presumably better supported by hosting
outfits.
Also, why are you restricting your field lengths so
much? This is the 21st century, you can afford to be a bit more generous on those VARCHARs
:)
Probably. On the other hand, really easy to make them longer, too,
should that prove necessary - this isn't a 100 million row table. And
the fields are already longer, in most cases, than I would want to
actually display and longer than the fields I currently have - which
have already been lengthened as needed.
Final thing, are you going for a completely normalised
database? (ok, I haven't analysed your schema to any great extent)
THANKS FOR ASKING THAT QUESTION. Well I thought I had done a decent job
of practical normalization, but clearly missed some things that I
noticed as a result of your question.
First, I certainly should pull out the File and Online fields into a
separate table because as is they could result in
redundancy/inconsistency between multiple copies in my inventory.
Pulling them into a separate table will remove the redundancy, and also
allow for the eventual possibility of multiple online sources for a
given manual.
TABLE File
Fields: Machine_MFG(K), Manual_Number(K), OnlineLocation(K)*,
OnlineVersion*, OnlineMD5*.
(Filename goes away - it is just an instance of "OnlineLocation")
(*) - removed from original Manual table.
Theoretically, I should separate the copies into a separate copy table,
keyed by artifact ID, but it wouldn't really buy me much, as I almost
always store multiple copies of a manual in the same place. Still it
probably would be the way to go:
TABLE Artifact
Fields: ArtifactID(K), Location*, Cabinet*, Drawer*, InventoryDate*,
Missing*, Original*, Incomplete*, Publisher*, Date*
I think I will add a field "Marked" - Boolean - true if an artifact
has been marked with its ArtifactID.
I *might* also yank Publisher and Date into this table. Have to
think about that, but with the possibility of multiple printings,
the Date almost certainly belongs here. I suppose one could argue
the same for Publisher. AH YES! HP and Apollo - different
publishers for the exact same manual.
So, yes, these need to move too.
So now, table Manual just has the following:
Machine_MFG(K), Manual_Number(K), Title, Type
And I need a relationship table to bind the two together:
TABLE ManaulArtifacts
ArtifactID(K), Machine_MFG, Manual_Number
Steve.
---------------------------- Original Message ----------------------------
Subject: Thoughts on manual database design?
From: "Jay Jaeger" <cube1 at charter.net>
Date: Wed, September 23, 2015 12:00 pm
To: cctalk at classiccmp.org
--------------------------------------------------------------------------
So, I am looking to convert my old Access
database I have used for many
years to a MySQL database, with the expectation that I will eventually
publish it on a web page for public lookup.
Below is my first cut at a database design for it. I'd be happy for
comments and suggestions, to the list or directly. Note, however, that
I don't expect to do this to the same level of complexity and
completeness that one might if they were the library of congress, a
major university library, etc. So, some suggestions to generalize may
be quietly ignored, even if they would in principle, be the "right
thing" according to some criteria or other.
This would be used for manuals, per se, print sets, etc. Quite possibly
for books as well.
What follows amounts to a data dictionary:
Table MANUAL:
This is the primary table of manuals. Many of the fields will be
available for string and/or pull down search, as appropriate.
Machine_MFG: VARCHAR(32)
The manufacturer of the machine(s) to which the manual applies
Part of unique key.
Pull down search.
Manual_Number: VARCHAR(40)
The manual number, including version strings, etc.
In some cases, this may be an SBN or ISBN.
Part of unique key
String search.
Artifact_ID: CHAR(16) [format/type still under consideration]
The local identifier for the manual/artifact.
Part of unique key.
Will be generated if none is entered during creation/update.
(Required because I may have more than one copy of a given manual).
Publisher: VARCHAR(32)
The publisher of the manual. (Typically will be the same as the
Machine MFG - but not necessarily always)
May not be NULL.
Type: VARCHAR(16)
Manual, Drawing (== printset, schematic, etc.), Book, ...
Pull down search.
Original: BOOLEAN
True if an original manual. False if a copy ("Xerox").
Missing: BOOLEAN
True if the manual is missing (i.e., is not where it is supposed to
be, and the actual location is not known).
Title: VARCHAR(255)
The title of the manual, including any subtitles.
Suggest "; " to separate multiple titles/subtitles
May not be NULL
String search.
Incomplete: CHAR(1)
Indicates if the manual is not a complete copy.
NULL indicates the copy is complete.
Year: DATE
The year the manual was published / printed / copyrighted.
May be NULL, signifying the date is unknown / not entered.
Location: VARCHAR(20)
The general location of the manual in my inventory
May be NULL, signifying the manual is not in my inventory.
Cabinet: CHAR(2)
The ID of the cabinet or box in which the manual is stored, if any.
May be NULL, even if the manual is in my inventory.
May not be NULL if Drawer is not NULL.
Drawer: CHAR(2)
The ID of the drawer of the cabinet in which the manual is stored,
if any. May be NULL.
Inventory_Date: DATE
The date that the manual was last inventoried.
Filename: VARCHAR(255)
The name of the file which is an image of the manual in my local
file storage.
OnlineLocation: VARCHAR(255)
URL of the manual located online (e.g., the bitsavers URL)
May be NULL. This does NOT mean that the manual is not online.
Of course, this field can become out of date.
OnlineVersion: CHAR(1)
= means that the online manual is the same version as this one
means that there is no equal version online, but
there is a
later version
< means there is no equal or later version online, but there is an
earlier version.
OnlineMD5: CHAR(32)
MD5 hash of online manual - used to check for moved manuals. ;)
TABLE MachineManual
This table cross references manuals to the machine(s) to which they
apply. This list will NOT be guaranteed to be complete. During inquiry
and update, this will be a list of machines with a separator character
in between which will not be allowed in Machine_MFG. During an update,
the entire list will be replaced with the first one being flagged as the
primary machine.
MachineMFG: (See above). Part of the unique key for this table.
Manual_Number: (See above) Part of the unique key for this table.
Machine: VARCHAR(16)
One of the machine(s) to which this manual applies.
Part of the unique key for this table.
Primary_Machine: BOOLEAN
When true, indicates that this machine should be listed first
in the list of applicable machines. For a peripheral, this will
typically be the machine for which the peripheral was originally
designed.
So a list of machines for an RX01 manual might be:
PDP-11, RX01, RX01, VAX-11
TABLE Machines
A lookup table of valid machines. Only column is Machine (See above).
Naturally this table will change over time - I anticipate that an update
where the updater (me) keys in an "invalid" one will be greeted with
some kind of confirmation panel.
TABLE Manufacturers
A lookup table of valid manufacturers. Only column is Machine_MFG
(See above). Naturally this table will change over time - I anticipate
that an update where the updater (me) keys in an "invalid" one will be
greeted with some kind of confirmation panel.
Table Types
A lookup table of valid Types. Only column is Type (See above)
TABLE: LastGeneratedArtifact
The last generated artifact ID - used to assign new artifact numbers
when one is not manually entered. Algorithm TBD. One column:
Artifact_ID (See above)
TABLE: Locations
A table of valid locations (e.g. Basement, Garage, STORAGE, Unknown, etc.)
Used for convenience during data entry.
(Once this one is done and running (at least locally), the next one is
probably media (tapes, floppies, etc.) which is not too bad, and then
machines, cards and parts, which is more complicated for lots of reasons).
After those are done (hopefully by the end of the year - I am retired
and this will be my primary focus for a while) comes the design for a
database for SMS cards and for the IBM 1410 use of SMS cards.
JRJ
1:52 p.m.
New subject: Thoughts on manual database design?
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
6:18 p.m.
New subject: Thoughts on manual database design?
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
24 Sep
24 Sep
12:13 p.m.
New subject: Thoughts on manual database design?
On 9/23/2015 8:18 PM, steven at malikoff.com wrote:
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)
)
Because my artifact ID's are not always just numbers. In some cases
they may already be marked on an artifact (though typically not for
manuals - but this is just the first of a set of such projects, and they
*are* marked on many of my computer boards).
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.
No, I don't need made up primary keys. The other tables have the keys
they need to guarantee uniqueness - in some cases the PK is made of up
two or more columns. I seriously dislike the current fad of inventing
such keys when they are not needed.
Those you mention and a few more FK constraints are there. Some of the
tables, like Location and Manual_Type also exist to populate pull down
lists without having to read through larger tables to populate them
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.
As I mentioned in another response, I truly dislike SQLite, based on my
experience with it on my Garmin GPS.
JRJ
23 Sep
23 Sep
7:05 p.m.
New subject: Anyone recognize this bus/form factor?
68xx system, unusual (in my experience) 40-pin
single row header bus.
Anyone recognize it?
https://lh3.googleusercontent.com/-jRSv5KbuziQ/VgNYaQ5j1gI/AAAAAAAAAXY/A5k2…
8:43 p.m.
New subject: 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/A5k2…
--
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.'
8:53 p.m.
New subject: Anyone recognize this bus/form factor?
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:
--
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.'
68xx system, unusual (in my experience) 40-pin
single row header bus.
Anyone recognize it?
https://lh3.googleusercontent.com/-jRSv5KbuziQ/VgNYaQ5j1gI/AAAAAAAAAXY/A5k2…
10:23 p.m.
New subject: Anyone recognize this bus/form factor?
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:
--
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.'
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:
https://lh3.googleusercontent.com/-jRSv5KbuziQ/VgNYaQ5j1gI/AAAAAAAAAXY/A5k2…
68xx system, unusual (in my experience) 40-pin
single row header bus.
Anyone recognize it?
24 Sep
24 Sep
7:06 a.m.
New subject: Anyone recognize this bus/form factor?
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…
----- 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/A5k2…
--
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.' 
8:23 a.m.
New subject: Anyone recognize this bus/form factor?
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…
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
12:05 p.m.
New subject: Anyone recognize this bus/form factor?
On Thu, Sep 24, 2015 at 8:06 AM, Mike Stein <mhs.stein at gmail.com> wrote:
Wonder why that type of connector wasn't used more
often for a bus instead
of presumably more expensive edge connectors;
Lower cost is why that style of connector was chosen by SWTPC for the
SS-50 bus, and by Ohio Scientific for their bus, though the board in
your photo clearly doesn't match either of those.
I think I do have some (CDC?)
boards that are the opposite, i.e. pins plugging into sockets on the
backplane.
Interesting. With that style of connector, it's relatively easy for
the male pins to get damages, and not so much for the sockets. The
"backwards" approach has the advantage of protecting the backplane
pins better, since those are harder to replace.
3373
days inactive
3379
days old
24 comments
15 participants
participants (15)
-
billdegnan＠gmail.com -
chrise＠pobox.com -
cisin＠xenosoft.com -
COURYHOUSE＠aol.com -
cube1＠charter.net -
echristopherson＠gmail.com -
healyzh＠aracnet.com -
jwest＠classiccmp.org -
mhs.stein＠gmail.com -
salgernon＠me.com -
simski＠dds.nl -
spacewar＠gmail.com -
steven＠malikoff.com -
tdk.knight＠gmail.com -
tmfdmike＠gmail.com