Hi,
I know this has been mentioned before on the list, but I thought people here
would be interested.
I have printed and produced some classic computer wall calendars for 2005.
I've just reduced the price to US$5.99. You can see them and purchase one
online here:
http://www.digicraft.com.au/calendars
I'm sorry if this is seen as spam.
Andy
Brad Parker <brad(a)heeltoe.com> wrote:
> I think the sdsl firmware is really bits put in an fpga.
Hmm, if this is so, the circuit should be pretty simple, as all the digital
stuff would be in the FPGA, so I would just need the FPGA firmware file.
But what's between the FPGA and the copper line?
MS
Vintage Computer Festival <vcf(a)siconic.com> wrote:
> I've got a bunch of AT&T Paradyne modems in case anyone's interested.
Do you have one with a synchronous serial hand-off (NO Ethernet, no bridge
or router functionality) that's compatible with Copper Mountain DSLAMs?
MS
Rules of thumb are just that. They aren't meant to be Science
but Craft; analysis beyond some point(*) is generally worthless.
Hard drives last longer than food, but not much. Reviving for
data recovery is great, but all of the commodity winchester
types are of limited lifespan. If you get 25K hours, consider
yourself skating on thin ice.
PS: If a drive is dead due to stiction, then rotating it sharply
parallel to the platter (I can't believe rotational direction
matters nor that you can know which way they turn w/o opening),
or rapping during power up, or taking the cover off all work
"a lot". On the latter, the once or twice I've done it I
just wiped everything off with a clean rag first, hit reset,
rotate the platter (finger on enter hub, I forget) then xcopy
(it was some DOS box) the data off.
On those old ST225 type drives, sometimes the little brush
(tab) finger thing that grounds the rotating spindle, on the
bottom outside of the drive (under? the PCB?) squeals. Bend it.
(*) I suppose you could use real methodology to determine
exactly what the failure modes really are, and possibly
disk manu's do that. But there's not much value in it
outside disk-drive {manufacture,repair} worlds. Drive
construction techniques come and go, by the time the likes
of us (non-disk-drive-manu-engineers) figure one thing out,
it's changed again.
I recently acquired one of these units and am in the process of searching
for manuals or any info AT ALL on this unit! So far I've figured out how to
call up addresses, store data and program it (havn't really done much since
I can't figure out more then how to play with the registers, the output
hardware is alien to me :/) I'd love to get a copy of the rom as it was
written in the manual, comments and all. Also, if anyone has a manual and
wants it scanned, I'll be more then happy to do that for you! And I'm
especially keen to know how to manipulate the speaker and output LEDs
Hi Heinz,
Thanks for the very useful information.
>Not, it's not a SuperPet. Not even close. Noting shared
>with Commodore's schematics. No memory mapped video,
>no VIAS.
>From what I can tell, it is/was intended to run the same
Waterloo software as the SuperPET (in 6809 mode) - the document
that I have describes the microWAT and SuperPET as separate
hardware (which they obviously are!), but makes very little
distinction once it gets into the software.
>It used a bank switched eprom board (2532's ?) to run boot/
>the monitor and Waterloo Structured interpreted languages
>(Which were themselves written in a weird C-like compiled
> language called WSL= Waterloo Systems Language)
This is probably how the microWAT and SuperPET are "the same"
when the hardware is different ... It appears that WSL is used
to make the same software run on both platforms. From the
document I have:
"SOFTWARE PORTABILITY
When the 6809 was chosed as the microprocessor for the microWAT
and SuperPET, we realized that microcomputers which incorporated
other microprocessors such as the 68000, 8086, 8088 and Z8000
were about to be announced, and some were even available. It
would, therefore, be unwise to prepare extensive software systems
specifically for the 6809. The systems language WSL is ment to
produce code which is portable. By using WSL to write the language
interpreters, the editor, the library the assembler development
system, and in fact the WSL compiler itself, it should be a
relatively easy job to move or "port" the system to other machines
and interface it with their operating systems."
>The most interesting thing in that whole system was that
>Wes Graham (of Watfor fortran compiler fame) had
>written a copyrighted poem (Haiku) that was an unencrypted
>key required to run the software. The designers chose the rarest,
>hardest to program most obscure Harris 3 supply fuse proms to use,
>so it could not be easily copied.
Can you provide more information - at some point I, if I can gather
enough material together, I would like to try and get the thing to
run - do I need to provide this "key"?
Also, can you shed any light on the 1/2 height completely potted
(ie: sealed from tampering) card that I found wrapped up inside
the system? (See previous posting for complete description).
Any other information/resources you can point me at would be
greatly appreciated.
Regards,
Dave
--
dave04a (at) Dave Dunfield
dunfield (dot) Firmware development services & tools: www.dunfield.com
com Collector of vintage computing equipment:
http://www.parse.com/~ddunfield/museum/index.html
/me just got a early Xmas present.
I got what should be a relatively complete Vax 4000-300, console,
cables, and w/ some form of MO jukebox. Might even have a line on a
small pile of tapes for the thing..
I don't know very little about the spec's on the box, as I literally
just got ahold of it.. Looks like its got a fair bit of SCSI, and
Ethernet in it. I'd guess its only got 32Mb of memory as I only saw
one obvious MS670 memory board. (It took that many chips to make 32MB!?)
The only concern I've got is, while its been stored in doors most of its
life, its been outdoors since Monday, and its gotten _COLD_. I think
it'll need a day or two just to warm up.
I see what appears to be at least some documentation up on bitsavers, at
least the phrase KA670 seems to match up what's on the little tag at the
bottom of the unit.
Does anyone have any other suggested hardware documentation site's they
think would be worthwhile to point me at?
Thanks,
/me goes back to poking at the innards. :-)
David
I have the following ISA cards available from a IBM5160:
1 each 1501435 Color graphics
2 each 1503236 async
1 each 256KB memory 6449021XM
$10 for all.
and an unusual find from in a 5150:
Twin CD ROM drives (Hitachi CDR-36006) with ISA interface card
(CD-IP35A) and cables
$20 for all
These are as is, untested, price plus shipping from 99352
thanks Norm
All this talk about the Intel iPDS has peaked my interest, at least for
now. So I have been doing a little investigation on what exactly I have
and here are some of the details.
The iPDS is an 8085-based portable development system. PDS was said to
stand for Personal Development System or Portable Development System.
Intel's manual called it Personal Development System, so that must be it.
The main processor board (and it was one monolithic system board with
cables to the keyboard, crt, and floppy drive. Besides the main cpu
with 64KB of ram, there was a second 8085 that implemented the keyboard
and crt terminal. So the main cpu only talked through an I/O port to
get "console in" and "console out". The main board also had an 8272 (I
think that was the chip) to control the floppy drive.
It had one internal 96-tpi double-sided floppy drive that held about
650K bytes. It used MFM encoding, I guess required by the 8272.
There were three connectors on the back panel for I/O. One was a serial
port. It was a 25-pin D female. It could be jumpered to appear as a
DCE or a DTE. From the factory it was strapped to be a DCE. That was
probably to be consistent with the MDS-800 and port 1 of the Series II.
The 800 required, and the Series II accomodated an external crt terminal
as the "console". Since the iPDS had an integral console (built-in crt
and keyboard) I strapped my serial port to be a DTE so that I could
connect it directly to a modem. In those days, of course, the BBS was
dominate for communications to the world, and a modem was highly
desirable for that.
There was also a 25-pin D female connector to drive a
Centronix-compatible printer. It used the same pinout as the 800 and
the Series II.
Finally there was a 37-pin D female that could connect up an external
floppy drive. Remember, the standard iPDS from Intel had only one
floppy drive built in.
One very cool option was a second cpu board. It has its own 8085 and
64K of ram. It cabled to the main processor board and would use the
integral keyboard, crt, and floppy with the use of a software semaphore
to prevent both processors from accessing a device at the same time.
Another option was a daughter board that accomodated up to four iSBX
boards. When that was installed you could install one or two iSBX-251
bubble memory cards. Those cards were 128K bytes in size and the
operating systems from Intel would support them as logical disk drives.
You could even boot from the internal bubble device. Very advanced for
its time, I'd say.
Intel, of course, wanted users to take advantage of their ISIS-PDS
operating system. It would boot from the bubble or from the floppy
drive. And with ISIS, the file and device locking routines would allow
both cpu's, if you had the optional second processor installed, to boot,
access files, etc, and you could switch between the processors with a
function key. It was truly a multi-processor system, actually two very
logically distinct computers in one. Often I would be editing one file
while compiling, linking, locating, etc, another file, using both cpu's
that way. Remember, of course, the only operating systems for small
computers like that were single-user, single-tasking.
Intel also sold a version of CP/M-80 V2.2 for the iPDS. But due to
licensing issues, and possibly technical issues, CP/M would only boot
>from one of the two processors. It was simply software in the BIOS to
disable the "B" processor. However, a clever workaround was to have
ISIS loaded in a bubble device, boot one processor from that device, and
let the other boot from CP/M on the floppy drive. There were times that
I would document a project that I was working on using Wordstar on a
CP/M-booted processor while developing code on the ISIS-booted processor.
I have a good collection of software for the iPDS, so if anyone who has
a working machine, I would be willing to send out copies of what I
have. I have made Teledisk images of boot floppies that can be
recreated on an IBM-AT compatible on the HD drive. I also have decent
comm software that will transfer files through the serial port to and
>from a PC.
Oh well, I guess you can see how bored I am to spend Christmas Eve
typing this up, but I wanted to get it written down while it was all
fresh in my mind.
Merry Christmas and Happy Holidays to you all!!!
Dave Mabry
