The collected works of jodys

jodys
From Denver, CO
Who joined Feb. 6, 2007, 1:33 a.m.
Wrote on the subject of Nekoware-current at Sept. 9, 2008, 10:58 p.m...
I've uploaded the following updated packages to /incoming

neko_atk-1.23.5.tardist, neko_cairo-1.6.4.tardist, neko_curl-7.19.0.tardist,
neko_glib-2.18.0.tardist, neko_gtk+-2.14.1.tardist, neko_libpixman-0.11.10.tardist,
neko_pango-1.20.5.tardist

This is the first time I've compiled packages for nekoware, so, please, let me know what I missed ;)

Common things appear to be working, e.g. gimp, but I would appreciate any assistance in testing to make sure this hasn't broken other packages.
:Octane2: :Indy: :O2: :O2: :O3x0: :Indigo2IMP:
jodys
From Denver, CO
Who joined Feb. 6, 2007, 1:33 a.m.
Wrote on the subject of Nekoware-current at Sept. 10, 2008, 8:35 p.m...
I've been testing and reviewing the packages I uploaded and already found some major errors in packaging (jumped the gun, I guess.) I am working on getting everything corrected and will upload those new versions shortly.
:Octane2: :Indy: :O2: :O2: :O3x0: :Indigo2IMP:
jodys avatar
jodys
Member
Who joined Feb. 6, 2007, 2:33 a.m.
and authored 69 notes
Wrote on the subject of Prefix-portage from Gentoo on IRIX at May 20, 2009, 12:52 p.m...
Thanks for all the work on this!

I am, however, having troubles finishing the installation as shown. I am on a Origin 300 running 6.5.30 and MIPSPro 7.4.4m

When I attempt to do the first emerges I get

Code:
-bash-3.2$ USE="-*" emerge --oneshot -v --keep-going sed wget bash baselayout-prefix lzma-utils m4 flex bison coreutils findutils tar grep patch gawk make

These are the packages that would be merged, in order:

Calculating dependencies... done!

!!! All ebuilds that could satisfy "dev-lang/perl" have been masked.
!!! One of the following masked packages is required to complete your request:
- dev-lang/perl-5.8.8-r6 (masked by: package.mask)
/opt/gentoo/usr/portage/profiles/package.mask:
# Torsten Veller <tove@gentoo.org> (28 Jan 2009)
# Masked for testing (#249629)
# https://bugs.gentoo.org/show_bug.cgi?id=79685#c14

- dev-lang/perl-5.8.8-r5 (masked by: missing keyword, invalid: SLOT is undefined)

For more information, see the MASKED PACKAGES section in the emerge
man page or refer to the Gentoo Handbook.
(dependency required by "sys-apps/help2man-1.36.4" [ebuild])
(dependency required by "sys-devel/libtool-2.2.6a" [ebuild])
(dependency required by "dev-libs/popt-1.13" [ebuild])
(dependency required by "net-misc/rsync-3.0.5" [ebuild])
(dependency required by "sys-apps/portage-2.2.00.13621" [ebuild])
(dependency required by "sys-apps/baselayout-prefix-1.12.5-r6" [ebuild])
(dependency required by "baselayout-prefix" [argument])

-bash-3.2$


I could overcome the "missing keyword" mask with the package.keywords file, but I can't seem to get around the "invalid SLOT" mask.

Here is the emerge --info, if it would be any help
Code:
-bash-3.2$ emerge --info
Portage 2.2.00.13621-prefix (prefix/irix/6.5/mips, gcc-3.4.6, unavailable, 6.5 IP35)
=================================================================
System uname: IRIX-6.5-IP35-mips-32bit
Timestamp of tree: Tue, 12 May 2009 22:01:37 +0000
app-shells/bash:     4.0_p17-r1
ACCEPT_KEYWORDS="mips-irix ppc-macos sparc-solaris x86-freebsd x86-solaris ~mips-irix ~ppc-macos ~sparc-solaris ~x86-freebsd ~x86-solaris"
CBUILD="mips-sgi-irix6.5"
CFLAGS="-c99 -O2 -n32 -mips4 -r14000 -float_const -use_readonly_const -TARG:isa=mips4:platform=ip30:processor=r14000 -TENV:zeroinit_in_bss=ON -OPT:fast_io=ON:Olimit=8192:reorg_common=ON:swp=ON -LNO:auto_dist=ON:fusion_peeling_limit=8:gather_scatter=2 -diag_error 1035 -woff 1174,1183,1185,1552,3968,3970"
CHOST="mips-sgi-irix6.5"
CONFIG_PROTECT="/etc"
CONFIG_PROTECT_MASK="/etc/env.d /etc/gconf"
CPPFLAGS=" -I/opt/gentoo/usr/include"
CXXFLAGS="-J2 -O2 -n32 -mips4 -r14000 -float_const -use_readonly_const -TARG:isa=mips4:platform=ip30:processor=r14000 -TENV:zeroinit_in_bss=ON -OPT:fast_io=ON:Olimit=8192:reorg_common=ON:swp=ON -LNO:auto_dist=ON:fusion_peeling_limit=8:gather_scatter=2 -diag_error 1035 -FE:eliminate_duplicate_inline_copies:template_in_elf_section -woff 1174,1183,1185,1552,3968,3970 "
DISTDIR="/opt/gentoo/usr/portage/distfiles"
EPREFIX="/opt/gentoo"
FEATURES="collision-protect distlocks fixpackages nostrip parallel-fetch preserve-libs protect-owned sfperms strict test unmerge-orphans userfetch userpriv"
GENTOO_MIRRORS="http://distfiles.gentoo.org http://distro.ibiblio.org/pub/linux/distributions/gentoo"
LDFLAGS="-Wl,-s,-x,-n32,-mips4,-rdata_shared,-allow_jump_at_eop,-rpath,/opt/gentoo/usr/lib:/opt/gentoo/lib -L/opt/gentoo/usr/lib -L/opt/gentoo/lib"
LINGUAS="en en_GB"
PKGDIR="/opt/gentoo/usr/portage/packages"
PORTAGE_CONFIGROOT="/opt/gentoo/"
PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --stats --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages"
PORTAGE_TMPDIR="/opt/gentoo/var/tmp"
PORTDIR="/opt/gentoo/usr/portage"
PORTDIR_OVERLAY="/opt/gentoo/usr/local/portage"
SYNC="rsync://rsync.prefix.freens.org/gentoo-portage-prefix"
USE="X acl ao bash-completion berkdb bzip2 cleartype cracklib crypt cscope dbus esd expat fam gdbm gnutls gtk hal iconv ipv6 ithreads jpeg jpeg2k libnotify lzo midi mips-irix mmap ncurses nls ogg opengl openmp pcre perl png prefix python readline slang spell sqlite sqlite3 ssl svg tcl test threads tiff unicode urandom vim-pager vim-syntax xft xinerama xprint xv zlib" ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat linear meter mmap_emul mulaw multi null plug rate route share shm softvol" APACHE2_MODULES="actions alias auth_basic authn_alias authn_anon authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache dav dav_fs dav_lock deflate dir disk_cache env expires ext_filter file_cache filter headers include info log_config logio mem_cache mime mime_magic negotiation rewrite setenvif speling status unique_id userdir usertrack vhost_alias" ELIBC="IRIX" INPUT_DEVICES="keyboard mouse" KERNEL="IRIX" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LINGUAS="en en_GB" USERLAND="GNU"
Unset:  CTARGET, EMERGE_DEFAULT_OPTS, FFLAGS, INSTALL_MASK, LANG, LC_ALL, MAKEOPTS, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS

-bash-3.2$


Any help would be appreciated.

_________________
:0300: :Octane2: :Indy: :0300: <-> :0300:
jodys avatar
jodys
Member
Who joined Feb. 6, 2007, 2:33 a.m.
and authored 69 notes
Wrote on the subject of Prefix-portage from Gentoo on IRIX at May 20, 2009, 11:22 p.m...
I spent some more time one this, it looks like the bash that was bootstrapped did not have these patches (that you wrote) applied http://forums.nekochan.net/viewtopic.php?f=15&t=7547&start=15 and was causing a bunch of problems. Pointing the bootstrap scripts at the /usr/nekoware/bin/bash instead of the bootstrap one seems to have fixed the problem, temporarily. I'm not sure that that is the right answer, but I'd really like to get portage up and running.

_________________
:0300: :Octane2: :Indy: :0300: <-> :0300:
jodys avatar
jodys
Member
Who joined Feb. 6, 2007, 2:33 a.m.
and authored 69 notes
Wrote on the subject of Prefix-portage from Gentoo on IRIX at May 22, 2009, 1:13 p.m...
Thanks again! I'm rather excited about getting portage up and running. I've been learning a lot about portage trying to work around these problems, but I still haven't finished the bootstrap yet.

stuart wrote:
bash-3.2 and bash-4.0 should both work on IRIX, so long as they are not compiled above '-O1' (at which points MIPSpro optimisations break it quite badly). This should all be dealt with by the ebuild, though.

What might be happening here is that a recent 'portage' update changed the ebuild semantics from requiring 'EAPI="prefix"' to breaking with a similar error if that directive is present.


It looks like the bootstrap-prefix.sh builds bash with -O2, causing the problem.

stuart wrote:
If this is the cause of the problem, then either re-syncing portage (from the already-installed binaries) with 'emerge --sync' and/or re-installing the latest portage if the necessary dependencies are present ('USE="-*" FEATURES="-test" emerge --oneshot -v portage') should fix the problem.


I can't run emerge --sync as I'm still midway through bootstrapping portage. To do a sync, I need rsync, but rsync depends on baselayout-prefix which is giving me circular dependency problems.

stuart wrote:
(Or, alternatively, the overlay packages I included may now be out of date - try re-downloading http://files.irix-tools.homeunix.net/irix/IRIX-MIPSpro-wrapper.tar.bz2 , which I have just updated, or run 'PORTDIR_OVERLAY="" emerge --oneshot -v =perl-5.8.8-r5' and please let me know if either works)

[/quote]

I went ahead and started again from scratch following your instructions. I downloaded your overlays and bootstrap-prefix.sh fresh. Here are the results

1. Bash built by the bootstrap-prefix.sh is built -O2, so I had to manually link in nekoware bash
2. trying to do the initial emerge reveals a circular dependency in baselayout-prefix.

Code:
-bash-3.2$ USE="-*" emerge --oneshot -v --keep-going sed wget bash baselayout-prefix lzma-utils m4 flex bison coreutils findutils tar grep patch gawk make

These are the packages that would be merged, in order:

Calculating dependencies... done!


[nomerge      ] sys-apps/baselayout-prefix-1.12.5-r6  USE="-prefix-chaining"
[nomerge      ]  sys-apps/portage-2.2.00.13621  USE="-build -doc -epydoc -prefix-chaining (-selinux)" LINGUAS="-pl"
[nomerge      ]   dev-lang/python-2.6.2  USE="-berkdb -build -doc -examples -gdbm (-ipv6) -ncurses -readline -sqlite -ssl -threads -tk -ucs2 -wininst -xml"
[ebuild  N    ]    app-admin/eselect-python-20080925
[ebuild  N    ]     app-admin/eselect-1.0.12  USE="-bash-completion -doc"
[ebuild  N    ]      sys-apps/file-5.03  USE="-python"
[ebuild  N    ]       dev-lang/python-2.6.2  USE="-berkdb -build -doc -examples -gdbm (-ipv6) -ncurses -readline -sqlite -ssl -threads -tk -ucs2 -wininst -xml"

* Error: circular dependencies:

('ebuild', '/', 'app-admin/eselect-python-20080925', 'merge') depends on
('ebuild', '/', 'app-admin/eselect-1.0.12', 'merge') (runtime)
('ebuild', '/', 'sys-apps/file-5.03', 'merge') depends on
('ebuild', '/', 'dev-lang/python-2.6.2', 'merge') (buildtime)
('ebuild', '/', 'app-admin/eselect-1.0.12', 'merge') depends on
('ebuild', '/', 'sys-apps/file-5.03', 'merge') (runtime)
('ebuild', '/', 'dev-lang/python-2.6.2', 'merge') depends on
('ebuild', '/', 'app-admin/eselect-python-20080925', 'merge') (buildtime)

* Note that circular dependencies can often be avoided by temporarily
* disabling USE flags that trigger optional dependencies.
-bash-3.2$

_________________
:0300: :Octane2: :Indy: :0300: <-> :0300:
jodys avatar
jodys
Who joined Feb. 6, 2007, 1:33 a.m.
and authored 72 notes
Wrote on the subject of Lyon Lamb IVAS Animation Controller? at July 11, 2013, 7:23 a.m...
Not my auction or anything, but I saw an interesting GIO32 card on eBay and I'm curious if anyone knows what it is.

http://www.ebay.com/itm/Animation-Contr ... 1161744021

I'm trying to piece together what Lyon Lamb did and what this card interfaces with.

I believe that the MINIVAS, IVAS, ProVAS are all systems to allow single frame recording on to VTRs. When animators were animating by hand, they needed a quick way to view results. Lyon Lamb developed a system to use a video camera, one of their cameras, and a VTR. The animator would set of a single frame, tell the VAS unit to record a single frame and then the VAS would tell the VTR to record a single frame. Apparently there is some sort of non-standard frame coding as well.

"At Siggraph '86 in Dallas, Texas; Lyon Lamb Video Animation Systems, Inc. introduced tbe MINIVAS, a new animation controller product specifically designed for the PC graphics and animation market. The new MINIVAS animation controller interfaces directly to PC systems for automated single frame recording, frame grabbing, and VTR control, using either Lyon Lamb's proprietary Vertical Interval Frame Code or standard EBU time code. Frame numbers or EBU time code are displayed
on the MINIVAS front panel for the convenience of tbe computer graphics animator. Assuring field accurate recording,
editing, searching and frame-grabbing, the Lyon Lamb MINIVAS interfaces to Image Technology February 1987."

Another reference to the MINIVAS, http://www.iavsc.org/repository/avs5/so ... Anima.html

As to the IVAS, I find a reference in a patent which implies that the GIO32 card combines some control stuff with a frame grabber, then the image would/could be manipulated by Photoshop, then output

In the alternative "video camera" embodiment, the "TI-24A" is connected to the image processor by a coaxial-to-RS232 coupling, and in particular, to an external port of a "frame grabber" of a personal computer 26. This image processor utilizes an "INDIGO ELAN" model computer (available from Silicon Graphics, Inc. of Mountain View, Calif.), which is advantageous because of the computer's R4000 microprocessor and its advanced graphics capabilities. The "INDIGO ELAN" is configured with a "IVAS" frame grabber (also available from Lyon Lamb of Burbank, Calif.) that affords the computer 26 alternative access to the frame grabber, which simultaneously receives and processes the video signal from the video camera.
....
In the alternative "video camera" embodiment, the "IVAS" device is integrated into the "INDIGO ELAN" computer as a computer add-on board that has an external port, for allowing the frame grabber to directly communicate to devices which are peripheral to the computer. Thus, the video signal generated by the video camera may be directly fed into the frame grabber via this port, while the computer 26 simultaneously accesses and manipulates the video data as it is stored in the frame grabber's RAM.

--

Anyone have any experience with this stuff or know more?

_________________
:0300: :Octane2: :Indy:
jodys
From Denver, CO
Who joined Feb. 6, 2007, 1:33 a.m.
Wrote on the subject of What do you use your SGI for? at Sept. 17, 2013, 1:12 p.m...
I have a maxed out Indy (R5000/180, 256M) that I've been using pretty regularly. The main applications I use are LaTeX, Maple, MIPSpro C, and git. Thankfully, the TexLive crew still support Irix so I can use LaTeX and my treasured copy of Maple 7 to support all my work getting a bachelor's degree in mathematics. My only frustration these days is that recent versions of EMACS are getting pretty unusable on it. So, I work in NEdit, but I miss AucTeX.

Even though I have faster Irix machines, the Indy is small and quiet. The Indy has a further advantage; it is fast enough to be usable for my purposes, but slow enough that I can't run anything even approaching a modern browser. I simply can't waste time on the web :D
:Octane2: :Indy: :O2: :O2: :O3x0: :Indigo2IMP:
jodys
From Denver, CO
Who joined Feb. 6, 2007, 1:33 a.m.
Wrote on the subject of What do you use your SGI for? at Sept. 25, 2013, 7:15 a.m...
vishnu wrote:
jodys wrote: The Indy has a further advantage; it is fast enough to be usable for my purposes, but slow enough that I can't run anything even approaching a modern browser. I simply can't waste time on the web :D

What's an Indy? An Indigo without the "go." ;)


Then again, I can't put a R5K in an Indigo which means the Indigo doesn't run mips4, limiting the nekoware I can run. Thus, perhaps the Indigo should be a Indican't ;)
:Octane2: :Indy: :O2: :O2: :O3x0: :Indigo2IMP:
jodys
From Denver, CO
Who joined Feb. 6, 2007, 1:33 a.m.
Wrote on the subject of Show Off Your Home Office Setup & SGI Collection... at Nov. 2, 2013, 3:08 p.m...
Image
:Octane2: :Indy: :O2: :O2: :O3x0: :Indigo2IMP:
jodys avatar
jodys
Donor
From Denver, CO
Who joined Feb. 6, 2007, 1:33 a.m.
Wrote on the subject of Cheap composite tbc recommendation for O2 capture at July 5, 2014, 12:48 p.m...
rooprob wrote:
O2 CPU board contains two CPUs. One is whatever model system R5000 etc. the other is a R3000 derived SIMD which delivers real time image and media functions. It's only presented through the digital media libraries and AFAIK there's no official support to hand code it in MIPS assembler to make it do arbitrary things. What you have in Irix is all you get, see /var/arch/vicetre/.


Actually the VICE is three seperate things: a DMA engine, the bitstream processor which is a a weirdo 16 bit custom MIPS CPU that is designed for Huffman coding/decoding, and the aforementioned R3K which is paired with a SIMD vector coprocessor, AKA the MSP. The MSP can execute a scalar and a vector instruction simultaneously, so really the VICE ought to be thought of as three additional CPUs. openGL, the imaging libraries, and the digital media libraries execute code on the VICE through a library, libvice, in Irix. I have yet to locate any headers for libvice, though. Fun fact: Irix ships with microcode for the VICE for MPEG2 encoding and decoding, but there is no support in the rest of Irix. MPEG2 was one of the major design goals for the VICE, but somehow all we get is MJPEG. Maybe the chip didn't perform as well as desired. I don't know.
:Octane2: :Indy: :O2: :O2: :O3x0: :Indigo2IMP:
jodys avatar
jodys
Donor
From Denver, CO
Who joined Feb. 6, 2007, 1:33 a.m.
Wrote on the subject of Cheap composite tbc recommendation for O2 capture at July 5, 2014, 8:09 p.m...
robespierre wrote: the Crime chip (CRM) is like the "northbridge" of the O2. it accepts requests from the CPU and the other I/O chips and buffers them to the memory. It also contains the OpenGL accelerator component, unimaginatively called the "Rendering Engine", which is like the Indy's XL graphics (no geometry engine).
the VICE chip sits on the same bus as the CPU (SysAD bus), which limits its usefulness somewhat, since they both share the same path to main memory. Furthermore, they are not cache-coherent with one another.


I wouldn't class the O2 graphics as just another XL. Clearly it doesn't have a fully accelerated 3D pipeline, but there are compelling differences from the XL. MRE being able to do color space conversions is one of them. The VICE is available to perform some pretty substantial imaging calculations is another. I think that really the O2 is a memory controller with some coprocessors, just look at the diagram in the technical report. This is great when you are using VICE or fully utilizing the rendering engine, but not so great when you want maximum CPU speed. Hence the well documented underperformance of the R10/12k in the O2.

The VICE and the CPU are not cache coherent but I don't think that is really necessary for their purposes. If your MSP is processing GBs of data sequentially do you really want to keep a cache coherent?

I think what limits the VICE is not a shared bus but the sheer complexity of making it work. A driver and library would already handle loading ucode and allocating buffers, but you'd be writing two different bits of assembly, both of which need to be less than 4k and both of which are different dialects of MIPS. Furthermore, each chip has loads of quirks and probably bugs.
:Octane2: :Indy: :O2: :O2: :O3x0: :Indigo2IMP:
jodys
From Denver, CO
Who joined Feb. 6, 2007, 1:33 a.m.
Wrote on the subject of Ars on reality of using old 'puters & SGI accelerator idea? at Oct. 3, 2014, 6:39 p.m...
sgifanatic wrote:
sgifanatic wrote: There have been all sorts of custom add-on boards designed for the Apple II, Commodore, Amiga and Atari communities. Stuff that lets these machines access SD card storage, provides proc acceleration, etc. I wonder about a little browser offload card add-on for our SGIs... it could also provide USB ports, storage, wireless & security services (firewall)... I'm thinking a dual NIC BananaPi connecting directly to the SGI NIC, providing DHCP services, a modern browser via XDMCP and firewall services. Second NIC on Banana goes to uplink. This also adds USB ports to SGIs (exported auto via NFS to host) and wireless. A nice 3-d printed case to match the design sensibilities of *pick your favorite SGI*, and voila!


Thoughts on the above viz web browser acceleration?


For the browser part: running to a Fuel/Octane via gigabit would probably be pretty workable. I do recall having some issues with missing X extensions, but perhaps that could be resolved. The real hack would be, say, a GIO card for Indigo/Indy/Indigo2. Something like the SunPCI card?
:Octane2: :Indy: :O2: :O2: :O3x0: :Indigo2IMP:
jodys
From Denver, CO
Who joined Feb. 6, 2007, 1:33 a.m.
Wrote on the subject of Indigo2 R4400 250Mhz HighImpact + TRAM at Nov. 21, 2014, 7:36 a.m...

Code: Select all

# hinv -vm
CPU: MIPS R4400 Processor Chip Revision: 6.0
FPU: MIPS R4000 Floating Point Coprocessor Revision: 0.0
1 250 MHZ IP22 Processor
Main memory size: 128 Mbytes
Secondary unified instruction/data cache size: 2 Mbytes on Processor 0
Instruction cache size: 16 Kbytes
Data cache size: 16 Kbytes
Integral SCSI controller 0: Version WD33C93B, revision D
Disk drive: unit 1 on SCSI controller 0
CDROM: unit 3 on SCSI controller 0
Integral SCSI controller 1: Version WD33C93B, revision D
On-board serial ports: 2
On-board bi-directional parallel port
Graphics board: High Impact/TRAM option card
Integral Ethernet: ec0, version 1
Iris Audio Processor: version A2 revision 1.1.0
EISA bus: adapter 0


Code: Select all

# /usr/gfx/gfxinfo -vv
Graphics board 0 is "IMPACT" graphics.
Managed (":0.0") 1280x1024
Product ID 0x0, 1 GE, 1 RE, 4 TRAMs
MGRAS revision 3, RA revision 5
HQ rev A, GE11 rev B, RE4 rev A, PP1 rev A,
VC3 rev A, CMAP rev EMC rev C
unknown, assuming 19" monitor (id 0xf)

Input Sync: Voltage - Video Level; Source - Internal; Genlocked - False
Channel 0:
Origin = (0,0)
Video Output: 1280 pixels, 1024 lines, 60.00Hz (1280x1024_60)
Video Format Flags:  (none)
Sync Disabled
Using Gamma Map 0
Monitor Type:  unknown

Code: Select all

# uname -aR
IRIX GreenMachine 6.5 6.5.3m 01221552 IP22


And the original OEM 4GB drive.

Code: Select all

# scsicontrol -i /dev/scsi/sc0d1l0
/dev/scsi/sc0d1l0:  Disk          SGI     QUANTUM XP34550SLXY4
ANSI vers 2, ISO ver: 0, ECMA ver: 0; supports:  synch linkedcmds cmdqueing
Device is  ready


It is not that I needed another SGI, but this machine had been on craigslist for a couple of weeks. Despairing for its fate, I bought it. I'm glad I did. It is very clean and well cared for--the owner had bought it brand new in 1996--and it came with with all the original boxes and accesories. Not the highest spec Indigo2, but enough for me. After saving the original OEM drive with its install of 6.5.3, I think I may just install 6.2, since it came with a license for a MipsPro that will will run on 6.2. It came with a delightfully large box of CDs, including the groovy "Adventures of Ratmandu and Whitewolf" binder filled with Developer Toolbox CD's.

Right before I left with the machine, I pulled out some crisp $20's to pay for the machine.

He gave me a sour look and said "That's not enough, it'll be about $40,000" and then we both smiled. Ahh, depreciation...
:Octane2: :Indy: :O2: :O2: :O3x0: :Indigo2IMP:
jodys
From Denver, CO
Who joined Feb. 6, 2007, 1:33 a.m.
Wrote on the subject of Indigo2 R4400 250Mhz HighImpact + TRAM at Nov. 21, 2014, 1:47 p.m...
The pictures do belie certain cosmetic imperfections and dust. However, it is great condition. The PO said he was in about $40,000 with software, too.

Thanks for the info re MIPSpro licenses. I have another machine licensed with 6.5 and 7.4, so I thought it might be nice to have a 6.2 machine.
:Octane2: :Indy: :O2: :O2: :O3x0: :Indigo2IMP:
jodys
From Denver, CO
Who joined Feb. 6, 2007, 1:33 a.m.
Wrote on the subject of Indigo2 R4400 250Mhz HighImpact + TRAM at Nov. 21, 2014, 1:58 p.m...
foetz wrote: oh yeah, indigo2 with an r4400/250 is neat. it's one of the most compatible systems. if you switch the impact with a pre-mgras card you can run everything from irix4 up to 6.5.22.

and yes, running 6.5.x on this makes little sense since any older version will be a boost in comparison. with 5.3 this one will fly and you can even run coff :D


Since I'd like to do some development on this machine, what is the last version of the SGI compilers to run on 5.3? I've got quite a few discs to look through. I assume that 5.3 is not compatible with Impact, right?
:Octane2: :Indy: :O2: :O2: :O3x0: :Indigo2IMP:
jodys avatar
jodys
Donor
From Denver, CO
Who joined Feb. 6, 2007, 1:33 a.m.
Wrote on the subject of WTB: Indy corona presenter card with cable. at June 22, 2015, 6:05 p.m...
IIRC, the Presenter board in the Indy doesn't connect to the GIO32 bus (maybe power only), rather it connects to special connectors on the XL card. I seem to recall that XZ cards needed a different adapter card.
:Octane2: :Indy: :O2: :O2: :O3x0: :Indigo2IMP:
jodys avatar
jodys
Donor
From Denver, CO
Who joined Feb. 6, 2007, 1:33 a.m.
Wrote on the subject of O2 Vice MPEG2 discovery at Oct. 4, 2015, 12:07 p.m...
The O2 has the vice engine. This was an architecture designed just before things like the Pentium got MMX and MIPS got MDMX. Instead of extra instructions on the main CPU, VICE is actually three completely seperate execution units that talk via a mapped region in main memory (not a big deal on the O2's UMA architecture). The three units are the MSP, BSP and a DMA engine. I'll talk more about the specifics of this architecture in future posts (time permitting). Additionally, two hardware versions of the VICE were released, DX and TRE with TRE being the most recent version.

This unit is used by two parts of Irix: the ImageVision library for accelerating 2D image operations and by dmedia for accelerating various image compression tasks. Specifically

Code: Select all

SGI versions 1, 2 and 3 (supported compression formats: uncompressed,
MVC1, MVC2, JPEG, RLE8, RLE24, RLE32)

Microsoft AVI (Audio Video Interleaved)

MPEG1 (ISO 11172) - read, play, and append only

Raw DV/DVCPro DIF files - read, play, and export only

Notably missing is MPEG2. Everything I've read on the net supports this, as well, the O2 can't do realtime MPEG-2 (please, correct me if I'm wrong about this assumption.) However, I was able to locate some internal documentation for the VICE engine and references to MPEG-2 decoding is littered through the documentation. MPEG2 decoding was definitely one of the design goals.

Furthermore, I find some compelling evidence of the ability to decode MPEG2 in 6.5.30m. Because the MSP and BSP are seperate executing units, Irix must keep object files around to run on those units.

The ImageVision MSP/BSP objects are found in

Code: Select all

/usr/gfx/ucode/CRM/vasm/

The dmedia objects are found in

Code: Select all

/var/arch/vicetre/
...
mpeg1dec.bex
mpeg1dec.mex
mpeg2dec.bex
mpeg2dec.mex
mpeg2dec_fld.bex
mpeg2dec_fld.mex
...

So... at the bottom of the dmedia stack there is some solid evidence that Irix supports mpeg2 decoding, because there is code to run on the Vice.

But does the rest of Irix know how to decode mpeg2? I cobbled some C together from the dmedia manpages and examples to introspect the dmedia image converters (the image compression section of dmedia) to see what converters it knows about.

Code: Select all

...
Contents of Parameter/Value List for IC 34:
DM_IMAGE_COMPRESSION=MPEG-2 Video
DM_IC_REVISION=0(int)
DM_IC_VERSION=1(int)
DM_IC_SPEED=NONREALTIME
DM_IC_CODE_DIRECTION=DECODE
DM_IC_ENGINE=The mpeg2 decoder
DM_IC_ID=mpg2
Contents of Parameter/Value List for IC 35:
DM_IMAGE_COMPRESSION=MPEG-2 Video
DM_IC_REVISION=0(int)
DM_IC_VERSION=0(int)
DM_IC_SPEED=REALTIME
DM_IC_CODE_DIRECTION=DECODE
DM_IC_ENGINE=Vice
DM_IC_ID=dvc
...
Contents of Parameter/Value List for IC 37:
DM_IMAGE_COMPRESSION=MPEG-2 Video
DM_IC_REVISION=0(int)
DM_IC_VERSION=2(int)
DM_IC_SPEED=REALTIME
DM_IC_CODE_DIRECTION=DECODE
DM_IC_ENGINE=Vice
DM_IC_ID=mpeg
...

The output is bit conflicting (why is the dvc decoder listed with a "MPEG-2 Video"). I compiled this with the debug version of dmedia (export LD_LIBRARY_PATH=/usr/lib/debug) without any problems. But, the way I read the output is that, at least at the image compression level, there is support for hardware (DM_IC_SPEED=REALTIME) and software (DM_IC_SPEED=NONREALTIME) mpeg2 decoding. Now support for the compression scheme is only part (albeit a major one) of displaying mpeg2 on the screen. The next step is to learn more about dmMovie which supports the various container formats. Is there support for a mpeg2 container there?

I've attached a copy of the source of the tool to list the available imageconverters. If anyone else wants to run this on their O2, I'd be interested to see if there is any difference in versions of Irix (did 6.3 have dmedia?) I've become a bit obsessed by the VICE and I hope to keep updating this thread with more that I discover, especially about mpeg2.
:Octane2: :Indy: :O2: :O2: :O3x0: :Indigo2IMP:
jodys avatar
jodys
Donor
From Denver, CO
Who joined Feb. 6, 2007, 1:33 a.m.
Wrote on the subject of O2 Vice MPEG2 discovery at Oct. 17, 2015, 9:33 a.m...
Thanks for the encouragement! It feels a bit weird spending all this time thinking about something that is, basically, unimportant in the grand scheme of things; the architecture was a dead end, Irix is long expired, and who cares about MPEG2 these days? Well, apparently, I do. It isn't some wish to go back, but, by golly, just because the rest of the world decided to be finished with this stuff doesn't mean I have to be finished with it!

I was a bit concerned about 'MPEG-2 Video' being listed for every vice related engine. Perhaps I was pulling the value from the string stored behind the dmedia library when it wasn't valid (e.g. left over from the previous image decoder)?

Reversing the order

Code: Select all

for(i=n;i>=0;i--){
status = dmICGetDescription(i, params);
PrintParams(params, i);
}

Sure enough, something weird going on.

Code: Select all

Contents of Parameter/Value List for IC 37:
DM_IC_REVISION=0(int)
DM_IC_VERSION=2(int)
DM_IC_CODE_DIRECTION=DECODE
DM_IC_SPEED=REALTIME
DM_IC_ENGINE=Vice
DM_IC_ID=mpeg

This certainly looks like a mpeg1 decoder, which we know works. Bad news? I dunno, there is still a lot of evidence pointing to a mpeg2 vice decoder. Even though the imageconverter library doesn't expose it, we still have those bits of code for the MSP and BSP on the vice. However, am I misinterpreting the names of those code files?

Experiment: run a mpeg1 file and see what .mex and .bex files it loads.

First, I wanted a minimal player that used dmedia (I don't think any of the legacy media stuff supports vice?). I found a simple example in /usr/share/src/dmedia/movie/miscGL/simplemoveGL. Second, I need a working mpeg1 movie file. This was in /usr/demos/O2/Birth_of_O2/data/product_manager/System_components/avModule.mpg. Third, I need a way to watch what system calls (specifically open calls) are made when I run the movie player with the mpeg1 file. par(1) does this easily enough.

Code: Select all

par -n open ./simplemovieGL /usr/demos/O2/Birth_of_O2/data/product_manager/System_components/avModule.mpg
...(some rld stuff)
6mS                 : open("/usr/lib32/libmovieplay.so", O_RDONLY, 05) = 3
7mS                 : open("/usr/lib32/libmoviefile.so", O_RDONLY, 05) = 3
7mS                 : open("/usr/lib32/libdmedia.so", O_RDONLY, 05) = 3
8mS                 : open("/usr/lib32/libX11.so.1", O_RDONLY, 05) = 3
9mS                 : open("/usr/lib32/libGL.so", O_RDONLY, 05) = 3
10mS                 : open("/usr/lib32/libm.so", O_RDONLY, 05) = 3
11mS                 : open("/usr/lib32/libcl.so", O_RDONLY, 05) = 3
11mS                 : open("/usr/lib32/libmutex.so", O_RDONLY, 05) = 3
12mS                 : open("/usr/lib32/libGLcore.so", O_RDONLY, 05) = 3
13mS                 : open("/usr/lib32/libXsgivc.so", O_RDONLY, 05) = 3
15mS                 : open("/usr/lib32/libXext.so", O_RDONLY, 05) = 3
16mS                 : open("/usr/lib32/libvice.so", O_RDONLY, 05) = 3

I believe that the vice is exposed to the kernel via an entry in /dev that can be controlled via a variety of ioctls and libvice.so wraps that up in a nice api.

Code: Select all

42mS                 : open("/dev/zero", O_RDWR, 01757312210) = 3
...(a bunch of X and openGL calls)
50mS                 : open("/usr/lib32/dmedia/imageconverters/libmpeg1video.so", O_RDONLY, 05) = 4
66mS                 : open("/usr/lib32/dmedia/imageconverters/", O_RDONLY|O_NONBLOCK, 01505656520) = 4
68mS                 : open("/usr/lib32/dmedia/imageconverters/libmpeg2.so", O_RDONLY, 05) = 4
70mS                 : open("/usr/lib32/dmedia/imageconverters/vicedv.so", O_RDONLY, 05) = 4
73mS                 : open("/usr/lib32/dmedia/imageconverters/vicempeg.so", O_RDONLY, 05) = 4
75mS                 : open("/usr/lib32/dmedia/imageconverters/vicers.so", O_RDONLY, 05) = 4
76mS                 : open("/usr/lib32/dmedia/imageconverters/vicejpeg.so", O_RDONLY, 05) = 4
79mS                 : open("/dev/vicedms", O_RDWR, 0570) = 4

I think here libvice.so is starting to control the vice

Code: Select all


80mS                 : open("/dev/dms", O_RDWR, 070) = 5
81mS                 : open("/dev/dms", O_RDWR, 070) = 6
83mS                 : open("/dev/dms", O_RDWR, 0130) = 7
89mS                 : open("/dev/dms", O_RDWR, 03) = 8
89mS                 : open("/dev/dms", O_RDWR, 0130) = 9
173mS                 : open("/dev/dms", O_RDWR, 03) = 10
195mS                 : open("/dev/vicedms", O_RDWR, 0570) = 4
196mS                 : open("/dev/dms", O_RDWR, 070) = 5
197mS                 : open("/dev/dms", O_RDWR, 070) = 6
199mS                 : open("/dev/dms", O_RDWR, 0130) = 7
204mS                 : open("/dev/dms", O_RDWR, 03) = 8
205mS                 : open("/dev/dms", O_RDWR, 0130) = 9
266mS                 : open("/dev/dms", O_RDWR, 03) = 10
...(a bunch of X and openGL calls
592mS                 : open("/var/arch/vicetre/mpeg1dec.mex", O_RDONLY, 017777605604) = 27
593mS                 : open("/var/arch/vicetre/mpeg1dec.bex", O_RDONLY, 010000) = 27

With the /dev/vicedms already open (from above) the library loads up the mpeg1dec.mex and mpeg1dec.bex files to the MSP and BSP, respectively. Thus, running an mpeg1 file uses the mpeg1dec.mex and mpeg1dec.bex files. So what? Well there are still

Code: Select all

mpeg2dec.bex
mpeg2dec.mex
mpeg2dec_fld.bex
mpeg2dec_fld.mex

in /var/archer/vicetre/. Who uses those files?

Code: Select all

$ strings /usr/lib32/dmedia/imageconverters/vicempeg.so | grep mpeg2
mpeg2dec.mex
mpeg2dec.bex
mpeg2dec_fld.mex
mpeg2dec_fld.bex


The very same vicempeg.so that runs mpeg1. Then why does vicempeg.so tell the dmIC library that it can do mpeg1 but not mpeg2?

A mystery.

The next question that emerges in my mind; what is going on in vicempeg.so? Finding the addresses of the mpeg1dec.mex and mpeg1dec.bex strings in vicempeg.so could provide enough info to run dbx(1) or cvd(1) along with test_ic.c and see if I can't see how the dmIC introspection interacts with vicempeg.so. I'm mildly encouraged since there does exist a /usr/lib/dmedia/debug/vicempeg.so. Perhaps, it has not been stripped of symbols and use the function names to understand where I am in the code. If it is stripped I think that it might be possible to at least follow the pattern for mpeg1 and see if I can find a branch that skips mpeg2. Maybe a decompiler will help here?
:Octane2: :Indy: :O2: :O2: :O3x0: :Indigo2IMP:
jodys avatar
jodys
Donor
From Denver, CO
Who joined Feb. 6, 2007, 1:33 a.m.
Wrote on the subject of O2 Vice MPEG2 discovery at Nov. 4, 2015, 6:27 a.m...
Looking at the docs for dbx I think I can set a break when entering a system call. From there I think I can at least isolate where in vicempeg.so those files are loaded. I thought a useful first thing to try would be to at least build a call tree for mpeg1 which I think is doable with dbx and the symbols in vicempeg.so.

A question related to compiling with debug ('-g') turned on. How do you know if a given binary was compiled with '-g'?
:Octane2: :Indy: :O2: :O2: :O3x0: :Indigo2IMP:
jodys avatar
jodys
Donor
From Denver, CO
Who joined Feb. 6, 2007, 1:33 a.m.
Wrote on the subject of I'm going fiber at Jan. 30, 2016, 5:45 p.m...
I used FDDI for awhile, since I couldn't afford fast ethernet for my Indy. For awhile I used a SparcStation to route between it's fast ethernet and FDDI. Then I bought a 3Com CoreBuilder 3500 which had fast ethernet (fiber and copper), gigabit fiber, and FDDI. That was a pretty neat convergence. I think to start using FDDI again (my house is being remodeled and I've put a lot of fiber in the wall), but, at this point, it is more expense and trouble than it is worth. I do miss all the strands of orange draped all over the place.
:Octane2: :Indy: :O2: :O2: :O3x0: :Indigo2IMP:
jodys avatar
jodys
Donor
From Denver, CO
Who joined Feb. 6, 2007, 1:33 a.m.
Wrote on the subject of I'm going fiber at Jan. 31, 2016, 8:27 a.m...
ivelegacy wrote: FDDI double ring ? 200Mbit/s ?
I think I would be a good idea for a backbone between two servers located in different buildings / rooms


IIRC, the double ring was just a redundancy thing. You could lose one fiber and things would stay up.
:Octane2: :Indy: :O2: :O2: :O3x0: :Indigo2IMP:
jodys avatar
jodys
Donor
From Denver, CO
Who joined Feb. 6, 2007, 1:33 a.m.
Wrote on the subject of I'm going fiber at Jan. 31, 2016, 8:44 a.m...
I pulled a fair amount of OM4 cabling before we finished in the house (I'm trying to be ready for when 10Gb and higher gets cheap). I'm looking around it appears that OM4 _should_ be backward compatible with FDDI.

OM4 Specifications
• Effective Modal Bandwidth (EMB) >/= 4700 MHz-km – Allows 2 methods for verification– DMD Masks or EMBc
• OFL Bandwidth at 850nm >/= 3500 MHz-km
– Ensures performance with sources that launch more power into
outer modes
• OFL Bandwidth at 1300nm >/= 500 MHz-km
– Ensures backward compatibility with OM1, OM2, OM3 fibers for applications such as FDDI, 100BASE-FX, 1000BASE-LX, etc.


However, I have none of the equipment anymore. The Indy adapter card and my old bridge/router are long gone...
:Octane2: :Indy: :O2: :O2: :O3x0: :Indigo2IMP:
jodys avatar
jodys
Donor
From Denver, CO
Who joined Feb. 6, 2007, 1:33 a.m.
Wrote on the subject of Getting a Phobos P1000 Gbit NIC to work in O2... at Feb. 6, 2016, 4:54 p.m...
I'm scouring the internet for a copy of the manual and the drivers for the P1000. I can't seem to find these anywhere. Any chance someone still has copies?
:Octane2: :Indy: :O2: :O2: :O3x0: :Indigo2IMP:
jodys avatar
jodys
Donor
From Denver, CO
Who joined Feb. 6, 2007, 1:33 a.m.
Wrote on the subject of Getting a Phobos P1000 Gbit NIC to work in O2... at Feb. 7, 2016, 6:56 a.m...
I have one and was wanting to experiment on it myself. Any help getting the drivers would be much appreciated!
:Octane2: :Indy: :O2: :O2: :O3x0: :Indigo2IMP:
jodys avatar
jodys
Donor
From Denver, CO
Who joined Feb. 6, 2007, 1:33 a.m.
Wrote on the subject of O2 Vice MPEG2 discovery at Feb. 7, 2016, 9:17 a.m...
It looks like tracing the execution won't be easy

Code: Select all

jodys@mirkwood debug$ pwd
/usr/lib/dmedia/imageconverters/debug
jodys@mirkwood debug$ dwarfdump vicempeg.so
No DWARF information present in vicempeg.so
jodys@mirkwood debug$

but it won't be hard

Code: Select all

jodys@mirkwood debug$ file vicempeg.so
vicempeg.so:    ELF 32-bit MSB mips-2 dynamic lib MIPS - version 1
jodys@mirkwood debug$
:Octane2: :Indy: :O2: :O2: :O3x0: :Indigo2IMP:
jodys avatar
jodys
Donor
From Denver, CO
Who joined Feb. 6, 2007, 1:33 a.m.
Wrote on the subject of O2 Vice MPEG2 discovery at Feb. 7, 2016, 2:02 p.m...
elfdump returns nothing, but reading its manpage led me to stdump(1). Looks like there is some amount of information here because I'm guessing MIPS2 implies that it was not compiled with n32.

Aside, in a unrelated message from Apr 1995 (probably pretty close to beginning of development on the o2)

Code: Select all

The symbol table formats are rather weird: we don't use DWARF for the
32-bit platforms yet - the format is called "mdebug", and is described in
/usr/include/syms.h
/usr/include/symconst.h
--

Silicon Graphics Inc.                   Phone:  +1-415-390-2072
URL:    http://reality.sgi.com/employees/shankar


that explains the lack of dwarf info.

Anyways, it looks like neither vicempeg.so or debug/vicempeg.so are compiled with any extra debug information. The most interesting revealed from stdump(1)

Code: Select all

Local Symbols:
from file dmic_interface.c  compiled -g0  Print aux if present
0. ( 0)(   0) dmic_interface.c File       Text       symref 40
1. ( 1)(133894176) dmICInitDso Proc       Text       [15] endref 3, int
2. ( 1)( 356) dmICInitDso End        Text       symref 1
3. ( 1)(133894532) Open       StaticProc Text       [17] endref 5, int
4. ( 1)( 236) Open       End        Text       symref 3
5. ( 1)(133894768) Close      StaticProc Text       [19] endref 7, int
6. ( 1)( 116) Close      End        Text       symref 5
7. ( 1)(133894884) GetDescription StaticProc Text       [21] endref 9, int
8. ( 1)( 300) GetDescription End        Text       symref 7
9. ( 1)(133895184) SetSrcPoolParams StaticProc Text       [23] endref 11, int
10. ( 1)(  60) SetSrcPoolParams End        Text       symref 9
11. ( 1)(133895244) SetDstPoolParams StaticProc Text       [25] endref 13, int
12. ( 1)(  60) SetDstPoolParams End        Text       symref 11
13. ( 1)(133895304) SetDstPool StaticProc Text       [27] endref 15, int
14. ( 1)(  80) SetDstPool End        Text       symref 13
15. ( 1)(133895384) GetDstFD   StaticProc Text       [29] endref 17, int
16. ( 1)(   8) GetDstFD   End        Text       symref 15
17. ( 1)(133895392) GetSrcFilled StaticProc Text       [31] endref 19, int
18. ( 1)(  76) GetSrcFilled End        Text       symref 17
19. ( 1)(133895468) GetDstFilled StaticProc Text       [33] endref 21, int
20. ( 1)(  76) GetDstFilled End        Text       symref 19
21. ( 1)(133895544) VerifySrcParams StaticProc Text       [35] endref 23, int
22. ( 1)( 184) VerifySrcParams End        Text       symref 21
23. ( 1)(133895728) VerifyDstParams StaticProc Text       [37] endref 25, int
24. ( 1)( 132) VerifyDstParams End        Text       symref 23
25. ( 1)(133895860) VerifyConvParams StaticProc Text       [39] endref 27, int
26. ( 1)(  12) VerifyConvParams End        Text       symref 25
27. ( 1)(133895872) GetDefSrcParams StaticProc Text       [41] endref 29, int
28. ( 1)( 128) GetDefSrcParams End        Text       symref 27
29. ( 1)(133896000) GetDefDstParams StaticProc Text       [43] endref 31, int
30. ( 1)( 128) GetDefDstParams End        Text       symref 29
31. ( 1)(133896128) GetDefConvParams StaticProc Text       [45] endref 33, int
32. ( 1)(  12) GetDefConvParams End        Text       symref 31
33. ( 1)(133896140) Send       StaticProc Text       [47] endref 35, int
34. ( 1)(2016) Send       End        Text       symref 33
35. ( 1)(133898156) Recv       StaticProc Text       [49] endref 37, int
36. ( 1)( 156) Recv       End        Text       symref 35
37. ( 1)(133898312) VerifySrcDstConv StaticProc Text       [51] endref 39, int
38. ( 1)( 184) VerifySrcDstConv End        Text       symref 37
39. ( 0)(   0) dmic_interface.c End        Text       symref 0


I'm thinking I can use the machine level instructions in dbx to start seeing what is happening. Again, part of the goal is to simply start seeing some of the call stack at various places in the code. I'm hoping to get at least some perspective with just the external symbols.
:Octane2: :Indy: :O2: :O2: :O3x0: :Indigo2IMP:
jodys avatar
jodys
Donor
From Denver, CO
Who joined Feb. 6, 2007, 1:33 a.m.
Wrote on the subject of Getting a Phobos P1000 Gbit NIC to work in O2... at Feb. 7, 2016, 3:34 p.m...
I was able to locate drivers and manual. I'm providing a copy at gopher://firien.helluin.org:70/1/sgi/software/
:Octane2: :Indy: :O2: :O2: :O3x0: :Indigo2IMP:
jodys avatar
jodys
Donor
From Denver, CO
Who joined Feb. 6, 2007, 1:33 a.m.
Wrote on the subject of Getting a Phobos P1000 Gbit NIC to work in O2... at Feb. 8, 2016, 1:45 p.m...
I was hoping to do some more experiments on the o2 to confirm. It seems like there is about 70MB/s of memory bandwidth available. I wonder what is causing the poor performance...
:Octane2: :Indy: :O2: :O2: :O3x0: :Indigo2IMP:
jodys avatar
jodys
Donor
From Denver, CO
Who joined Feb. 6, 2007, 1:33 a.m.
Wrote on the subject of SmartDec with MIPS / SGI support. at Feb. 8, 2016, 1:51 p.m...
I'm not familiar with smartdec. Does this compile on Irix or do I need a Linux machine? Either way I'm stoked to give this a try.
:Octane2: :Indy: :O2: :O2: :O3x0: :Indigo2IMP:
jodys avatar
jodys
Donor
From Denver, CO
Who joined Feb. 6, 2007, 1:33 a.m.
Wrote on the subject of Archiving CDROM images at Feb. 8, 2016, 2 p.m...
I've got a ginormous box of SGI CDROMs. Last time I used the CDROM on my O2 I had some strange errors. These CDs are getting on in the years. I'm thinking it is time to start tackling making archives.

Is anyone else keeping a big archive? How are you organising it? Any special software you are using? Do you keep md5 sums? Do you keep images or dist? Are there better tools for long-term storage? Pictures of the CDs and/or booklets and covers?
:Octane2: :Indy: :O2: :O2: :O3x0: :Indigo2IMP:
jodys avatar
jodys
Donor
From Denver, CO
Who joined Feb. 6, 2007, 1:33 a.m.
Wrote on the subject of Archiving CDROM images at Feb. 9, 2016, 12:01 p.m...
Thanks for the reminder about the .IM files. I just wrote a little python script to image (dd if=/dev/sr0 of=IMAGE_NAME) these from a linux box, loopback mount the image, then rename stuff according to the .IM file (or user input). FYI, the .IM file seems to have been introduced around or after 5.3. Many of my earlier CDs lack this so I have to name them manually. I'm still thinking about imaging the booklets and/or CD covers. I think it would be pretty quick work with a copy stand and some lights.
:Octane2: :Indy: :O2: :O2: :O3x0: :Indigo2IMP: