11 Jun
2024
11 Jun
'24
12:06 p.m.
Good evening, while I'm still waiting on the full uploads to progress (it's like
there's a rule any >100MB upload to archive.org for me has to fail like 5 times
before it'll finally go...) I decided to scrape out the UNIX RTR manual from a recent
trove of 5ESS materials I received and tossed it up in a separate upload:
https://archive.org/details/5ess-switch-unix-rtr-operating-system-reference…
This time around I've got Issue 10 from December 2001. The last issue of this
particular manual I found on another 5ESS disc is Issue 7 from 1998 which I shared
previously
(https://ia601200.us.archive.org/view_archive.php?archive=%2F12%2Fitems%2F5e…)
The manual is in "DynaText" format on the CD in question, unlike Issue 7 which
was already a PDF on its respective CD. I used print-to-PDF to generate the above linked
copy. Given that the CD itself is from 2007, this may point to UNIX RTR having no
significant user-visible changes from 2001 to 2007 that would've necessitated manual
revisions.
In any case, I intend to upload bin/cue images of all 7 of the CDs I've received
which span from 1999 to 2007, and mostly concern the 5ESS-2000 switch from the
administrative and maintenance points of view. Once I get archive.org to choke these
files down I also intend to go back around to the discs I've already archived and
reupload them as proper bin/cue rips. I was in a hurry the last time around and simply
zipped the contents from the discs, but aside from just being good archive practice, I
think bin/cue is necessary for the other discs as they seem to have control information in
the disc header that is required by the interactive documentation viewers therein.
All that to say, the first pass will result in bin/cues which aren't easily readable
through archive.org's interface, but I intend to also swing back around on these new
discs and provide zips of the contents as well to ensure the archives are both correct
(bin/cue) and easily navigable (zip).
As always, if you have any such documentation or leads on where any may be awaiting
archival, I'm happy to take on the work!
- Matt G.
11 Jun
11 Jun
12:59 p.m.
On Mon, Jun 10, 2024 at 11:06 PM segaloco via TUHS <tuhs(a)tuhs.org> wrote:
Good evening, while I'm still waiting on the full uploads to progress (it's
like there's a rule any >100MB upload to archive.org for me has to fail like 5
times before it'll finally go...) I decided to scrape out the UNIX RTR manual from a
recent trove of 5ESS materials I received and tossed it up in a separate upload:
https://archive.org/details/5ess-switch-unix-rtr-operating-system-reference…
This time around I've got Issue 10 from December 2001. The last issue of this
particular manual I found on another 5ESS disc is Issue 7 from 1998 which I shared
previously
(https://ia601200.us.archive.org/view_archive.php?archive=%2F12%2Fitems%2F5e…)
The manual is in "DynaText" format on the CD in question, unlike Issue 7 which
was already a PDF on its respective CD. I used print-to-PDF to generate the above linked
copy. Given that the CD itself is from 2007, this may point to UNIX RTR having no
significant user-visible changes from 2001 to 2007 that would've necessitated manual
revisions.
In any case, I intend to upload bin/cue images of all 7 of the CDs I've received
which span from 1999 to 2007, and mostly concern the 5ESS-2000 switch from the
administrative and maintenance points of view. Once I get archive.org to choke these
files down I also intend to go back around to the discs I've already archived and
reupload them as proper bin/cue rips. I was in a hurry the last time around and simply
zipped the contents from the discs, but aside from just being good archive practice, I
think bin/cue is necessary for the other discs as they seem to have control information in
the disc header that is required by the interactive documentation viewers therein.
I have some of these CDs already and can compare notes with you:
DK5E-CD from 2004, OA&M from 2008.
I think you can just copy the SGML files to a HDD once you have
DynaText installed, so whatever is funky about the CDs is not terribly
important for use aside from the fidelity of your archival. Some of
my CDs also use something called Eloquent Presenter which seems like a
HyperCard style program. All the docs that aren't SGML are PDF,
including most of the schematics, plenty which look like scans of
originals.
All that to say, the first pass will result in
bin/cues which aren't easily readable through archive.org's interface, but I
intend to also swing back around on these new discs and provide zips of the contents as
well to ensure the archives are both correct (bin/cue) and easily navigable (zip).
As always, if you have any such documentation or leads on where any may be awaiting
archival, I'm happy to take on the work!
FWIW I have a fully working 5ESS that I turned off last week (actually
a 7 R/E - 3B21D, CM3 (Global Message Server), 20k lines a mix of POTS,
ISDN, PRI trunks) and it is coming home with me at the end of the
month. Small matters of loading, unloading, AC PDU and getting a
sizable DC power plant and unbounded wiring are in my future. Why? I
dunno but full send. I need to have a think on how to be public with
all this going forward, I do want to share the system and the goal is
historical preservation and learning with interested parties.
- Matt G.
12 Jun
12 Jun
7:37 a.m.
On Tue, Jun 11, 2024 at 2:06 AM segaloco via TUHS <tuhs(a)tuhs.org> wrote:
In any case, I intend to upload bin/cue images of all
7 of the CDs I've received which span from 1999 to 2007, and mostly concern the
5ESS-2000 switch from the administrative and maintenance points of view. Once I get
archive.org to choke these files down I also intend to go back around to the discs
I've already archived and reupload them as proper bin/cue rips. I was in a hurry the
last time around and simply zipped the contents from the discs, but aside from just being
good archive practice, I think bin/cue is necessary for the other discs as they seem to
have control information in the disc header that is required by the interactive
documentation viewers therein.
Bin/cue is a PITA. You've checked that a simple raw image isn't
adequate? Perhaps the viewer was just checking the volume label?
Jim
9:34 a.m.
On Tuesday, June 11th, 2024 at 6:37 PM, Jim Carpenter <jim(a)deitygraveyard.com>
wrote:
On Tue, Jun 11, 2024 at 2:06 AM segaloco via TUHS
tuhs(a)tuhs.org wrote:
What would you suggest? My main point of reference is years and years of being in the
console video game scene, bin/cue is the most accessible of the high fidelity formats
I've seen for things, compared with say cdi and mdf/mds. Does a plain old iso
suffice for all relevant data from the media? Frankly I've never done dumps on a
UNIXy computer with an optical drive, only Windows boxen, so can't say I'm hip
to the sort of disc image you get doing a dd from an optical /dev entry, maybe I just need
to get a UNIX of some kind on my old beater game machine with an optical drive to do these
dumps going forward.
Either way, open to suggestions on what format is the ideal combination of capturing
everything that matters from optical media while not using too onerous or closed up of an
image format. This is not an area I'm "with the times on", I just went
straight to what was customary for myself over a decade ago when I was last diligently
interacting with optical media preservation.
- Matt G.
In any case, I intend to upload bin/cue images of
all 7 of the CDs I've received which span from 1999 to 2007, and mostly concern the
5ESS-2000 switch from the administrative and maintenance points of view. Once I get
archive.org to choke these files down I also intend to go back around to the discs
I've already archived and reupload them as proper bin/cue rips. I was in a hurry the
last time around and simply zipped the contents from the discs, but aside from just being
good archive practice, I think bin/cue is necessary for the other discs as they seem to
have control information in the disc header that is required by the interactive
documentation viewers therein.
Bin/cue is a PITA. You've checked that a simple raw image isn't
adequate? Perhaps the viewer was just checking the volume label?
Jim 
11:43 a.m.
On Tue, Jun 11, 2024 at 9:41 PM segaloco via TUHS <tuhs(a)tuhs.org> wrote:
What would you suggest? My main point of reference is years and years of being in the
console video game scene, bin/cue is the most accessible of the high fidelity formats
I've seen for things, compared with say cdi and mdf/mds. Does a plain old iso
suffice for all relevant data from the media? Frankly I've never done dumps on a
UNIXy computer with an optical drive, only Windows boxen, so can't say I'm hip
to the sort of disc image you get doing a dd from an optical /dev entry, maybe I just need
to get a UNIX of some kind on my old beater game machine with an optical drive to do these
dumps going forward.
The vast majority of non-game software was distributed on discs that
were formatted with a single data track and no special formatting.
These can be safely imaged in flat (ISO) format. The main reason to
use the lower-level formats is for discs with disc-based copy
protection or multiple tracks (usually one data track and multiple
audio tracks), both of which are very uncommon for non-game software.
BeOS install CDs are the one exception I can think of; these have an
ISO-format boot track followed by one or two BFS-format system tracks
(separate system tracks are used for x86 and PPC), although even these
aren't actually dependent on multiple tracks and can be run from a CD
with just the system track if a boot floppy is used.
Most dumping programs should be able to show you how the discs are
formatted; if they only have a single track each, ISO format should be
sufficient.
1:01 p.m.
On 12/06/24 17:43, Andrew Warkentin wrote:
On Tue, Jun 11, 2024 at 9:41 PM segaloco via TUHS
<tuhs(a)tuhs.org> wrote:
FWIW, I've successfully dd'ed cds and cd-roms into iso files and burnt
copies. I've never made use of the bin/cue setup, and wouldn't know how
to work it.
Wesley Parish
What would you suggest? My main point of
reference is years and years of being in the console video game scene, bin/cue is the most
accessible of the high fidelity formats I've seen for things, compared with say cdi
and mdf/mds. Does a plain old iso suffice for all relevant data from the media? Frankly
I've never done dumps on a UNIXy computer with an optical drive, only Windows boxen,
so can't say I'm hip to the sort of disc image you get doing a dd from an
optical /dev entry, maybe I just need to get a UNIX of some kind on my old beater game
machine with an optical drive to do these dumps going forward.
The vast majority of non-game software was distributed on discs that
were formatted with a single data track and no special formatting.
These can be safely imaged in flat (ISO) format. The main reason to
use the lower-level formats is for discs with disc-based copy
protection or multiple tracks (usually one data track and multiple
audio tracks), both of which are very uncommon for non-game software.
BeOS install CDs are the one exception I can think of; these have an
ISO-format boot track followed by one or two BFS-format system tracks
(separate system tracks are used for x86 and PPC), although even these
aren't actually dependent on multiple tracks and can be run from a CD
with just the system track if a boot floppy is used.
Most dumping programs should be able to show you how the discs are
formatted; if they only have a single track each, ISO format should be
sufficient.
2:12 p.m.
Hi Andrew,
Most dumping programs should be able to show you how
the discs are
formatted; if they only have a single track each, ISO format should be
sufficient.
Presumably, it's fairly simple to look at the text-file cue-sheet, if
bin/cue had been used, to see an ISO would have been good enough?
https://en.wikipedia.org/wiki/Cue_sheet_(computing)#Cue_sheet_syntax
And then perhaps there's a command to extract the ISO from the bin/cue
files.
--
Cheers, Ralph.
2:41 p.m.
On Wed, Jun 12, 2024 at 09:12:04AM +0100, Ralph Corderoy wrote:
And then perhaps there's a command to extract the
ISO from the bin/cue
files.
'bchunk' is one that does exactly that.
Also 'fuseiso' allows mouting a BIN/CUE file/image as a regular filesystem to
read the files if you just want to use them as-is.
Bye, Arno.
10:30 p.m.
On Wednesday, June 12th, 2024 at 1:41 AM, Arno Griffioen via TUHS <tuhs(a)tuhs.org>
wrote:
On Wed, Jun 12, 2024 at 09:12:04AM +0100, Ralph
Corderoy wrote:
bchunk is likewise my tool of choice for that sort of thing. I think what I'll go
with is the bin/cue for completeness but also a zip of the contents composited together.
Someone who specifically needs the disc image data can probably figure out bchunk and then
an archive will be present in a form navigable through archive.org's interface with
the composite pieces from each collection (i.e. a merge of the discs for a multi-disc
set). That should hopefully satisfy various needs.
- Matt G.
And then perhaps there's a command to
extract the ISO from the bin/cue
files.
'bchunk' is one that does exactly that.
Also 'fuseiso' allows mouting a BIN/CUE file/image as a regular filesystem to
read the files if you just want to use them as-is.
Bye, Arno.
193
days inactive
194
days old
8 comments
7 participants
participants (7)
-
Andrew Warkentin -
Arno Griffioen -
Jim Carpenter -
Kevin Bowling -
Ralph Corderoy -
segaloco -
Wesley Parish