-------------Original Message:
Date: Wed, 31 Mar 2010 22:27:26 -0700
From: "Chuck Guzis" <cclist at sydex.com>
Subject: Re: Reading ancient paper digital media (was Re: Hamurabi
Focal source)
<snip>
>Watching the thing read at 1200 cards per minute is pretty impressive.
<snip>
--Chuck
------------Reply:
Watching one *jam* at 1200 cards per minute is even more impressive,
especially if the sensors are dirty or misadjusted (and *especially* if you
have to recreate the damaged cards manually)...
mike
I rescued this thing from a computer store in the area a couple years
ago, and I think it's time to pass it on. From what I was told and what
I can tell, this is a CDC 9-track SCSI tape drive that was removed from
it's original rack/chassis. At the time, this computer store used it to
do some data recovery on some 1980 census tapes from Chicago, and they
had rigged this to a more modern SCSI based PC to do so. So I don't
know what condition it is currently in, and no idea if it works still,
but it did before it was stashed away into storage from what I understand.
If you want it, I can ship it at your expense or more than happy to pass
it along any other means possible, it is located in the Chicagoland area.
Temporarily posted pictures at:
http://www.merry-xmas.net/9track/
Mike
Noticed eBay auction /#/380220354709 - some collection of HSJ50 bits and
what look suspiciously like some CI ports. Does an HSJ even have the
capability to support CI? I never really dealt with HSCs back in the
day, or the intelligent storage controllers from the BA35x era.
Anyway if it does support a CI interface, I thought it might be a
cheaper way for somebody with a larger VAX to get closer-to-modern
storage and much lower electric bills than using SDI or HSC options.
Doesn't do me much good for my 11/730, so go for it.
No connection to the seller, and no comment regarding the asking price...
Share and enjoy!
--Steve.
Hello,
I'm repairing my A1010 Amiga external floppy drive - the actual drive
works (tested by plugging it into the internal A500 floppy connector),
so the fault should be on the latch board inside; there are two chips,
a 74LS74 D Flip-Flop and one chip (also 14 pin) with number M53238P
preceded by the Mitsubishi logo. Given the required function, and
connections on the adapter board, I am 99% sure that it's a 74LS38
Quad NAND open-collector equivalent - but googling doesn't turn up a
datasheet, just a gazillion chinese parts vendors. Can someone just
confirm this in a cross-reference? Or a A1010 schematic? Or their own
drive?
Thanks,
Joe.
PS. Symptom is that the drive clicks but never spins. I've already
taken out the chips and replaced them - this time in sockets. So if
I'm wrong it's a simple matter of undoing the 20-odd screws yet again
(Verdammte Post mit deren entstoerregelungen von damals...) and
replacing the chip. I just want to double-check before plugging it
into the A500 again tonight.
--
Joachim Thiemann :: http://www.tsp.ece.mcgill.ca/~jthiem
Martin Goldberg <wgungfu at gmail.com> wrote:
> Someone from the IGDA-Preservation group is in the process of
> transferring old DEC game code printouts in to text files, and was
> wondering if any one from the list knew if there was a PDP5 emulator
> (as a bunch of this is PDP5 in origin)?
>
> He may also require assistance in checking some of the assembly, as
> the printouts and copies are not always clear enough to read
> accurately.
>
> Any help would be appreciated, and I'll pass the info on.
Depending on the code, it might be runnable on a PDP8.
The main differences between the PDP5 and PDP8, as far as I can
remember, is that the PDP5 keeps the PC at address 0, and stores the old
PC at address 1 when an interrupt happens, while the PDP8 have the PC as
a separate CPU registers, and stores the old PC at address 0 when an
interrupt occurs.
And some (combinations of) OPR instructions don't work on the PDP5. But
that should not be a problem if you just take the program to a PDP8.
So, unless the program in question needs interrupts, or play directly
with the PC, I believe it might run on a PDP8.
Johnny
Philipp Hachtmann <hachti at hachti.de> wrote:
> Hi folks,
>
> it's probably a laughable idea but... Is it possible to read LINCtapes with a TU56 and a TD8E
> DECTape controller? I could imagine that it's possible due to the simple design of the TD8E
> controller - most work is done in software...
Nothing laughable about it.
As far as I know, it should work just fine.
> I just stumbled across a few of those tapes with unknown content. I first thought that I got a
> DECTape which was wound to the wrong side. I just tried it out. The DECTape system seemed to
> recognize just something on the tape - as it "rewound" the tape just up to the "beginning". And
> then it was not able to read something, of course.
> Oh, it would be fine if LINCtape reading on TD8E was possible - and readily implemented...
>
> Best wishes,
>
> Philipp
>
>
> P.S.: I probably won't be able to give those tapes away without cleaning them... So offers to look
> at them for me are quite useless :-(
> If I do not find means to read the tapes, I'll degauss them. Or simply reformat them. Or both for a
> clean tape start. Most of it seems to be working data. And some obscure software I don't know (yet).
When you need to understand is that you can't use any "normal" software
to read them, and that include any device drivers.
The tapes are written in the other direction. And that's something the
device driver is involved in.
As far as I know, you can actually use any DECtape controller to
read/write the tapes, not just the TD8E. But the same problem applies to
all of them. You need a special device driver.
But apart from that, it should be pretty straight forward. You basically
do eveything the same way you would do with DECtapes, except you set the
transport direction inverted to what a DECtape would do for all operations.
DECtape and LINCtape are clever in the way they identify blocks though,
so that the block markers can be detected the same no matter which way
the transport is moving, which is why you seem to recognize the tapes
somehow.
(The tape markers were designed so that the fluxes would become the same
no matter which direction you read them.)
One last thing. It *might* be that you'll have to do some bitfiddling
after reading the tapes. A DECtape (and LINCtape) records only three
bits at a time. When reading forward, you read 4 rows to get all 12
bits. And of course, they get stuffed in a certain order. Reading in
reverse means you get groups of 3 bits possibly shuffled around, as well
as being inverted. Depending on the LINCtape format, and how the TD8E
reacts, things might end up just right, or might require the bit
fiddling. You'll have to experiment...
Johnny
Hi folks,
it's probably a laughable idea but... Is it possible to read LINCtapes with a TU56 and a TD8E
DECTape controller? I could imagine that it's possible due to the simple design of the TD8E
controller - most work is done in software...
I just stumbled across a few of those tapes with unknown content. I first thought that I got a
DECTape which was wound to the wrong side. I just tried it out. The DECTape system seemed to
recognize just something on the tape - as it "rewound" the tape just up to the "beginning". And
then it was not able to read something, of course.
Oh, it would be fine if LINCtape reading on TD8E was possible - and readily implemented...
Best wishes,
Philipp
P.S.: I probably won't be able to give those tapes away without cleaning them... So offers to look
at them for me are quite useless :-(
If I do not find means to read the tapes, I'll degauss them. Or simply reformat them. Or both for a
clean tape start. Most of it seems to be working data. And some obscure software I don't know (yet).
--
http://www.hachti.de
-----------------Original Message:
Date: Mon, 05 Apr 2010 16:28:58 -0700
From: Brent Hilpert <hilpert at cs.ubc.ca>
Subject: PET 4032 keyboard scanning problem / was Re: Anyone have an
image of a Japanese PET chrgen ROM 901447-12?
Speaking of early Commodore PETs, I have here a 4032 on which some of the keys
do not work. Some time ago I took a brief look at it and, as I recall,
concluded the problem was not the keyboard but rather something was messed up
with the scanning, something like not all columns/rows being scanned. I think
it was a 6821 or 6822 or some such doing the I/O, but the diagnosis was perhaps
more suggestive of something like a PROM bit failure causing the firmware
program to foreshorten the scan sequence.
Anyone have knowledge of a known failure mode of this sort with these machines?
--------------------Reply:
The most common problem is just oxidation and/or wear of the rubber 'contacts'
and the PCB grid; if you're lucky a good cleaning will clear it up, in case of bad
wear of the conductive pads you may have to recoat them with conductive paint
ot glue little pads of aluminum foil or aluminized mylar on to them.
Electronically they are a normal scanned matrix, driven by a 6520 PIA (UB12?)
and a muliplexer; if there is a problem there then it would most likely be with all
the keys in a certain row or column. I suppose it's possible, but I'd be very
surprised if it were a bad ROM.
Check the schematic and you should be able to jumper across the appropriate
keyboard lines to test all the rows and columns.
http://www.zimmers.net/anonftp/pub/cbm/schematics/computers/pet/8032/803202…
Someone from the IGDA-Preservation group is in the process of
transferring old DEC game code printouts in to text files, and was
wondering if any one from the list knew if there was a PDP5 emulator
(as a bunch of this is PDP5 in origin)?
He may also require assistance in checking some of the assembly, as
the printouts and copies are not always clear enough to read
accurately.
Any help would be appreciated, and I'll pass the info on.
Thanks!
Marty
As it is getting close to the date for the Dayton Hamvention, is anyone
on the list going to be at Dayton? My plan is to be there with two
selling spots (one to park in) and see what kind of "stuff" I can get
rid of. If we have a few people there, it might be fun to have a
Saturday night dinner at one of the local restaurants.