4 Dec
2006
4 Dec
'06
1:07 p.m.
Have y'all had much luck acquiring vintage computer books/info via
library book sales?
--
"The Direct3D Graphics Pipeline" -- DirectX 9 draft available for download
<http://www.xmission.com/~legalize/book/download/index.html>
Legalize Adulthood! <http://blogs.xmission.com/legalize/>
4 Dec
4 Dec
1:19 p.m.
I once bought a set of OS/2 diskettes.
On 12/4/06, Richard <legalize at xmission.com> wrote:
Have y'all had much luck acquiring vintage computer books/info via
library book sales?
--
"The Direct3D Graphics Pipeline" -- DirectX 9 draft available for download
<http://www.xmission.com/~legalize/book/download/index.html>
Legalize Adulthood! <http://blogs.xmission.com/legalize/>
1:23 p.m.
In article <ddc584f50612041319o1f61e7fdwae4cf32a36971811 at mail.gmail.com>,
"9000 VAX" <vax9000 at gmail.com> writes:
I once bought a set of OS/2 diskettes.
Heh heh.
I was wondering if things like copies of Datamation or other now
defunct periodicals might show up in that sort of sale.
--
"The Direct3D Graphics Pipeline" -- DirectX 9 draft available for download
<http://www.xmission.com/~legalize/book/download/index.html>
Legalize Adulthood! <http://blogs.xmission.com/legalize/>
7 Dec
7 Dec
11:04 p.m.
Richard wrote:
I was wondering if things like copies of Datamation or
other now
defunct periodicals might show up in that sort of sale.
Today's fresh arrivals at a Friends of the Library organization to
the north of Sillycon Valley include:
- some Dr. Dobb's Journal from 1994 and 1996
- MSDN Magazine, Nov 2001 ("Windows XP is here")
- Teradata review, Summer 1999
- Software Development, covering the end of 1997 to the beginning of 2002
with gaps
- Java Developer's Journal, a couple from 1999 and one from 2001
- WebSphere Advisor, June 2003
- Bea WebLogic Developer's Journal, four or five across 2001-2004
- JavaPro, some from 2000, some from 2001, one from 2004
- PCPhoto, Oct 2000
- Silicon Valley TechWeek, a couple from May 2000
- Paradox Informant, May 1995 (three copies though)
Blah. I'm sending the lot to the bargain room ($0.10/ea I think).
This is perhaps unfortunately typical. I did look through the whole
box, just in case there was an Altair issue of Poptronics, or some
old 1960s Datamation, but no. (It wasn't likely.)
If you want to get some idea of what's going to be on the main sale
room shelves for Saturday's sale, look at
<http://www.friendspaloaltolib.org/bookshelves.aspx>. Those
pictures were taken on Sunday. I've put some more stuff out since
then.
-Frank McConnell (yeah, I'm the guy who does the computer section,
and I'm there now)
8 Dec
8 Dec
8:58 a.m.
Damn... some good stuff on the bookshelves. The Comer books, the Stevens
books.
Wish I had those here...
Bill
On 12/8/06, Frank McConnell <fmc at reanimators.org> wrote:
Richard wrote:
I was wondering if things like copies of
Datamation or other now
defunct periodicals might show up in that sort of sale.
Today's fresh arrivals at a Friends of the Library organization to
the north of Sillycon Valley include:
- some Dr. Dobb's Journal from 1994 and 1996
- MSDN Magazine, Nov 2001 ("Windows XP is here")
- Teradata review, Summer 1999
- Software Development, covering the end of 1997 to the beginning of 2002
with gaps
- Java Developer's Journal, a couple from 1999 and one from 2001
- WebSphere Advisor, June 2003
- Bea WebLogic Developer's Journal, four or five across 2001-2004
- JavaPro, some from 2000, some from 2001, one from 2004
- PCPhoto, Oct 2000
- Silicon Valley TechWeek, a couple from May 2000
- Paradox Informant, May 1995 (three copies though)
Blah. I'm sending the lot to the bargain room ($0.10/ea I think).
This is perhaps unfortunately typical. I did look through the whole
box, just in case there was an Altair issue of Poptronics, or some
old 1960s Datamation, but no. (It wasn't likely.)
If you want to get some idea of what's going to be on the main sale
room shelves for Saturday's sale, look at
<http://www.friendspaloaltolib.org/bookshelves.aspx>. Those
pictures were taken on Sunday. I've put some more stuff out since
then.
-Frank McConnell (yeah, I'm the guy who does the computer section,
and I'm there now)
4 Dec
4 Dec
2:17 p.m.
Have y'all had much luck acquiring vintage
computer books/info via
library book sales?
I typically pick up a few every year. I've had the best luck at an annual
sale that is held locally to support some sort of Scholarship fund. One of
my best finds there was a copy of "Mick and Brick". Last year was pretty
poor picking for computer books, though several boxes of History books were
purchased for the Library.
The bulk of my vintage computer books have now been donated to the "Conner
Bishop Historical Resource Center" to form the core of the Libraries
Computer History section. I would ask anyone thinking of disposing of
vintage computer documentation to think of us.
http://www.conner-bishop.org
Zane
3:51 p.m.
Have y'all had much luck acquiring vintage computer books/info via
library book sales?
Well, perhaps not specifically computing, but certianly old technical
books...
A friend of mine, for example, got me 8 or so volumes of the 'Radiation
Lab Seires' from a library clearout at the company where he worked...
I bought 'Automatic Digital Computers' for a few pence from a school
library sale. Many years later I realised what I'd actually bought :-)
And I've had god finds at the public library sales -- things like the
ARRL Antenna handbook, several books on Transputers, a programming book
for the Motorola 88K, and so on. I will admit to ignoring content-free
Mac and Windows books, though.
Alas 'good' books have bevome much less common at library sales recently.
Perhaps I've already bought them all...
-tony
5:15 p.m.
On 05/12/06, Zane H. Healy <healyzh at aracnet.com> wrote:
99%, if that low!
I have just got hold of a new copy. If I had known what was in them, I
would have shelled out for them ages ago.
Simon
--
------------------------------------------------------------------------
"Well, an engineer is not concerned with the truth; that is left to
philosophers and theologians: the prime concern of an engineer is
the utility of the final product."
Lectures on the Electrical Properties of Materials, L.Solymar, D.Walsh
D'ya mean
like Knuth for $1 a volume?
What percentage of the list just turned green with envy? 
6:53 p.m.
On 12/5/06, Simon Fryer <fryers at gmail.com> wrote:
On 05/12/06, Zane H. Healy <healyzh at
aracnet.com> wrote:
99%, if that low!
Count me green.
D'ya
mean like Knuth for $1 a volume?
What percentage of the list just turned green with envy? I have just got hold of a new copy. If I had known
what was in them, I
would have shelled out for them ages ago.
I know (in general terms) what's in them, but I haven't been able to
bring myself to shell out the full tick. :-/
-ethan
P.S. - if I ever get it in my head to "invent a new sort", I know a)
to start with Knuth, and b) that I'm almost certainly wrong if I think
I have a clever new way to do it.
7:08 p.m.
On Dec 4, 2006, at 9:53 PM, Ethan Dicks wrote:
They're worth every penny.
I have just
got hold of a new copy. If I had known what was in
them, I
would have shelled out for them ages ago.
I know (in general terms) what's in them, but I haven't been able to
bring myself to shell out the full tick. :-/ P.S. - if I ever get it in my head to "invent a
new sort", I know a)
to start with Knuth, and b) that I'm almost certainly wrong if I think
I have a clever new way to do it.
Huh? Who was it that, a hundred or so years ago, asked the gov't
to shut down the patent office because, surely, everything had
already been invented?
-Dave
--
Dave McGuire
Cape Coral, FL
7:18 p.m.
Huh? Who was it that, a hundred or so years ago,
asked the gov't
to shut down the patent office because, surely, everything had
already been invented?
-Dave
--
Dave McGuire
Cape Coral, FL
That was the guy running the patent office. And everything was invented
which is why most new patents are "insert old patent here" + "on the
net".
Have you seen some of the software and internet patents being given out? If
it was up to me there would be NO software patents at all.
4 Dec
4 Dec
5:30 p.m.
Zane H. Healy wrote:
>D'ya mean like Knuth for $1 a volume?
I payed real $$$ for them. I figured I better buy them
now before the revised edition comes out. His MIX computer
was a classic design -- binary or decmal. His next computer
is what I consider a RISC disaster from what I have seen.
What percentage of the list just turned green with
envy?
Zane
Only if you picked up working hardware for $1.
8:25 p.m.
Zane H. Healy wrote:
I did that at Fullerton, Ca. library sale. I recently got several very
good Architechure
books (Compter style) at Cypress, CA.'s sale last summer, including one
which covered
one of my interests, the Microdata 3200. Also covered was the way that
the 360
firmware (360/50) was modified to run CPS, which I used at UMR in college.
I was amazed to find two things that were so close to my interest at a
random
book sale event.
My favorite was not at a Library book sale, but a Micro Center some
years ago.
They decided to start thinning out books in there book section, which
used to
be quite good, and started by marking all the K&R's down to $5.00 each. And
those were the second edition ones. I bought them all, of course.
BTW, at least here in Orange county they have decimated their once excellent
book section for a huge flashy game display room. I can't blame them,
but they
are such bozos of marketing, I wish they would have kept the books anyway.
I wonder how they survive againt the likes of Fry's and Comp USA (Fry's
anyway). I do have to admire them for being persistant. Just wish they
had not destroyed the book section.
Down here in the Orange county area, the only book store that had had
technical books of any use was Irvine Science and Technical books, but
they closed their storefront and got some totally different domain name and
went internet, as has OpAmp in LA. So now it is all amazon, i guess, with
no useful place to stroll the aisles.
Jim
D'ya mean
like Knuth for $1 a volume?
What percentage of the list just turned green with envy?
Zane
8:30 p.m.
Micro Center isn't great, but I remember it being terrific (when I used to
live in Cambridge) vs. CompUSA where I live now in New Jersey. I wish we
had Micro Center or Frys here!!!
There's a place nearby in Manhattan called Computer Book Works which has a
great selection but it's expensive. That also makes me miss Cambridge --
there was Quantum Books, the MIT Press Bookstore, and the MIT Coop Bookstore
all within one square (errr, triangular) block.
-----Original Message-----
From: jim stephens [mailto:jwstephens at msm.umr.edu]
Sent: Monday, December 04, 2006 11:25 PM
To: General Discussion: On-Topic and Off-Topic Posts
Subject: Re: library book sales
Zane H. Healy wrote:
I did that at Fullerton, Ca. library sale. I recently got several very good
Architechure books (Compter style) at Cypress, CA.'s sale last summer,
including one which covered one of my interests, the Microdata 3200. Also
covered was the way that the 360 firmware (360/50) was modified to run CPS,
which I used at UMR in college.
I was amazed to find two things that were so close to my interest at a
random book sale event.
My favorite was not at a Library book sale, but a Micro Center some years
ago.
They decided to start thinning out books in there book section, which used
to be quite good, and started by marking all the K&R's down to $5.00 each.
And those were the second edition ones. I bought them all, of course.
BTW, at least here in Orange county they have decimated their once excellent
book section for a huge flashy game display room. I can't blame them, but
they are such bozos of marketing, I wish they would have kept the books
anyway.
I wonder how they survive againt the likes of Fry's and Comp USA (Fry's
anyway). I do have to admire them for being persistant. Just wish they had
not destroyed the book section.
Down here in the Orange county area, the only book store that had had
technical books of any use was Irvine Science and Technical books, but they
closed their storefront and got some totally different domain name and went
internet, as has OpAmp in LA. So now it is all amazon, i guess, with no
useful place to stroll the aisles.
Jim
D'ya mean
like Knuth for $1 a volume?
What percentage of the list just turned green with envy?
Zane
5 Dec
5 Dec
12:52 a.m.
Evan,
There is a Micro Center in Villanova here right by Philly.
Greg
-----Original Message-----
From: Evan Koblentz [mailto:evan at snarc.net]
Sent: Monday, December 04, 2006 11:31 PM
To: 'General Discussion: On-Topic and Off-Topic Posts'
Subject: RE: library book sales
Micro Center isn't great, but I remember it being terrific (when I used to
live in Cambridge) vs. CompUSA where I live now in New Jersey. I wish we
had Micro Center or Frys here!!!
There's a place nearby in Manhattan called Computer Book Works which has a
great selection but it's expensive. That also makes me miss Cambridge --
there was Quantum Books, the MIT Press Bookstore, and the MIT Coop Bookstore
all within one square (errr, triangular) block.
-----Original Message-----
From: jim stephens [mailto:jwstephens at msm.umr.edu]
Sent: Monday, December 04, 2006 11:25 PM
To: General Discussion: On-Topic and Off-Topic Posts
Subject: Re: library book sales
Zane H. Healy wrote:
I did that at Fullerton, Ca. library sale. I recently got several very good
Architechure books (Compter style) at Cypress, CA.'s sale last summer,
including one which covered one of my interests, the Microdata 3200. Also
covered was the way that the 360 firmware (360/50) was modified to run CPS,
which I used at UMR in college.
I was amazed to find two things that were so close to my interest at a
random book sale event.
My favorite was not at a Library book sale, but a Micro Center some years
ago.
They decided to start thinning out books in there book section, which used
to be quite good, and started by marking all the K&R's down to $5.00 each.
And those were the second edition ones. I bought them all, of course.
BTW, at least here in Orange county they have decimated their once excellent
book section for a huge flashy game display room. I can't blame them, but
they are such bozos of marketing, I wish they would have kept the books
anyway.
I wonder how they survive againt the likes of Fry's and Comp USA (Fry's
anyway). I do have to admire them for being persistant. Just wish they had
not destroyed the book section.
Down here in the Orange county area, the only book store that had had
technical books of any use was Irvine Science and Technical books, but they
closed their storefront and got some totally different domain name and went
internet, as has OpAmp in LA. So now it is all amazon, i guess, with no
useful place to stroll the aisles.
Jim
D'ya mean
like Knuth for $1 a volume?
What percentage of the list just turned green with envy?
Zane
4 Dec
4 Dec
10:15 p.m.
At 8:25 PM -0800 12/4/06, jim stephens wrote:
My favorite was not at a Library book sale, but a Micro
Center some years ago.
They decided to start thinning out books in there book section, which used to
be quite good, and started by marking all the K&R's down to $5.00 each. And
those were the second edition ones. I bought them all, of course.
I vaguely remember the Micro Center in the Washington DC area around
'93, though I was only able to get there once, maybe twice in the
three years I was stationed there. I picked up OS/2 2.0, a couple
books, and a CD-ROM of questionable information (some good classic
computer info on it though). The strange thing is among all the
computer books and magazines, I also found a RPG magazine.
Down here in the Orange county area, the only book
store that had had
technical books of any use was Irvine Science and Technical books, but
they closed their storefront and got some totally different domain name and
went internet, as has OpAmp in LA. So now it is all amazon, i guess, with
no useful place to stroll the aisles.
Sounds like I'm lucky to live in the land of Powells Books, though I
have to avoid going to the main store, or the Technical bookstore out
of fear for my wallet.
Zane
--
| Zane H. Healy | UNIX Systems Administrator |
| healyzh at aracnet.com (primary) | OpenVMS Enthusiast |
| MONK::HEALYZH (DECnet) | Classic Computer Collector |
+----------------------------------+----------------------------+
| Empire of the Petal Throne and Traveller Role Playing, |
| PDP-10 Emulation and Zane's Computer Museum. |
| http://www.aracnet.com/~healyzh/ |
5 Dec
5 Dec
1:06 p.m.
D'ya mean like Knuth for $1 a volume?
What percentage of the list just turned green with envy? 
6 Dec
6 Dec
12:17 a.m.
On Tue, 2006-12-05 at 21:06 +0000, Tony Duell wrote:
Knuth's 'The Art of Computer Programming'
is, IMHO, well
worth reading (and I say that even though I am not a programmer). Yes, I
have the first version of it, the 3 volumes that were published. And I've
even read most of them.
I still think finding what appears to be a first edition of 'Automatic
Digital Computers' for 30p beats it...
A first edition? Without a doubt. At 30 quid it beats it -- beats
it like it owed it money. Even ignoring the topic, it's an incredibly
rare book. A most excellent score, Tony!
Peace,
Warren E. Wolfe
wizard at voyager.net
2:22 a.m.
New subject: Machine Independent Storage Idea...
Hello, Fellow Cyber-Archaeologists,
I have an idea... (everybody duck)
One of the more common problems in the field of classic computers is
that of loading operating systems, programs, and data onto an old
machine. Could we not come up with a standard means of information
interchange? I would suggest the USB memory sticks one sees everywhere
now. I just bought a few of them at about four dollars each -- and each
one stores a gigabyte of information.
I was thinking... could we not develop, say, an S-100, an S-50, an
Apple II circuit board that accepts these sticks? An RL02 equivalent
controller that reads memory sticks, and pretends they are drives?
Information could be stored on any modern machine, loaded onto a memory
stick in a jiffy, and used to load up a copy of vital data for any
information-starved machine. Each area of specialty would only need one
card (or device) developed, along with a set of files and programs
necessary (or just mildly useful) for booting up and running the target
machine. As a bonus, one Gig of RAM memory would be a powerful drive on
many older machines, and would speed the system up immensely. I'm
currently spiffing up a couple of CP/M machines, and after all this
time, the diskettes spinning up to read a few K at a time is almost
physically painful.
For me, the joy comes in USING the older machines, rather than the
process of fixing them up. YMMV. But, I sure would enjoy having a
gigabyte of fast storage available -- it could include a bootable CP/M
image, and the entire SIG/M Public Domain library, and still have most
of the disk free. Equivalencies could be made for many other machines.
Does anyone have an interest in setting up some common scheme for the
hardware design, and data storage so that cards and interfaces could use
some common circuitry, with a separate hardware equivalent of a BIOS
(implementation dependent area) that would be different for different
machine applications?
Comments, anyone? Has this been done? Would people see it as an
abomination or boon? Who would be interested in (and capable of)
producing a USB interface card for "their" computers?
Peace,
Warren E. Wolfe
wizard at voyager.net
2:46 a.m.
New subject: Machine Independent Storage Idea...
Hey All,
On 06/12/06, Warren Wolfe <wizard at voyager.net> wrote:
I have an idea... (everybody duck)
[Using USB memory sticks as universal drives for old machines]
[Interfaces for each class or type of machine]
[Software on the stick]
Comments, anyone? Has this been done? Would
people see it as an
abomination or boon? Who would be interested in (and capable of)
producing a USB interface card for "their" computers?
I was thinking of doing the same sort of thing but using compact flash
cards and building some electronics as the interface for the QIC tape
interface. Thinking about it is about as far as I got. From what I
understand, the electronics and software for interfacing Compact Flash
is a little easier than USB.
My initial need for something like this, again comes back to the
problems with aged QIC tapes. I have quite a few and I don't expect to
get more than a read off them. Therefore I am looking for one good
read into a ADC, a little signal processing, then a way to emulate the
tape drive to get the OS onto the machines in question. For what it is
worth, the tapes are DomainOS and assorted utilities.
I look at it as, well, I would really like to use the original tapes
and drives, but I also want to preserve the information on the tapes
for n rereads in the future. I am therefore going to acknowldge that I
am not going to undertake the OS load using all original hardware.
However I am going to undertake it using as much of the original
hardware as I can, substituting new hardware where I think there is a
high probability something will go wrong.
I can see the strange irony in this project is the micro controller
that runs the interface is likely to have more CPU power and memory
than the host machine!
Simon
--
------------------------------------------------------------------------
"Well, an engineer is not concerned with the truth; that is left to
philosophers and theologians: the prime concern of an engineer is
the utility of the final product."
Lectures on the Electrical Properties of Materials, L.Solymar, D.Walsh
6:05 a.m.
New subject: Machine Independent Storage Idea...
Simon Fryer wrote:
Hmm, I'd much prefer that to USB; USB is a comms mechanism not a storage
system - using CF cards means that a bridge to all sorts of common interfaces
is possible (and in the case of things like USB and IDE such bridges exist
already).
Question: do CF cards support 8 bit transfers though, and are they guaranteed
to do so? IDE interfaces have been homebrewed to a lot of vintage machines,
but quite often they only support drives that'll do 8 bit data transfers.
Remember that the most common gadget found on old machines though is the
floppy drive - and that generally-speaking they're *reasonably* standardised
at the electrical interface. Typically that's the only device which is
bootable, and for which controlling software exists within whatever passes for
an OS on the machine, too. Maybe the sensible thing to do is make a gadget
which looks like a floppy drive to a vintage system but which holds data on
more modern storage (USB stick, CF card etc.) or allows for a comms link to a
modern machine.
I can't help feeling that requiring the building of a proprietary card for
every different system and the writing of drivers for it on that system is a
heck of a lot of work!
Comments,
anyone? Has this been done? Would people see it as an
abomination or boon? Who would be interested in (and capable of)
producing a USB interface card for "their" computers?
I was thinking of doing the same sort of thing but using compact flash
cards and building some electronics as the interface for the QIC tape
interface. Thinking about it is about as far as I got. From what
I
understand, the electronics and software for interfacing Compact Flash
is a little easier than USB.
It's IDE on a smaller pin pitch I think. Certainly there's no smarts to the
IDE-CF convertor that I have here - CF socket, power socket, IDE socket, a
capacitor, and a jumper for master/slave. That's it.
And like SCSI, interfacing to IDE is mainly a software issue - the hardware
tends to be a few buffers and little more.
cheers
Jules
--
there's a carp in the tub
there's a carp in the tub
so nobody's taken a bath
7:04 a.m.
New subject: Machine Independent Storage Idea...
I don't know how much times a flash memory can be written. It might be OK to
make a bootable device from it.
My concern is about how to make replacement RL02, RD53 or similar. Flash
memory might not be good for this purpose.
vax, 9000
7:26 a.m.
New subject: Machine Independent Storage Idea...
From: "9000 VAX" <vax9000 at gmail.com>
I don't know how much times a flash memory can be
written. It might be OK
to
make a bootable device from it.
My concern is about how to make replacement RL02, RD53 or similar. Flash
memory might not be good for this purpose.
It is true that the flash have a finite number of write cycles. (If we
believe the manufacturers, the number of writes allowed is improving.)
However, even so, I'd think the reliability would compare favorably
with the old media. One suggestion was to mimic a floppy disk drive,
(to cut down on the number of controllers that have to be implemented),
and I'd think that the flash would easily have a similar lifetime to
floppy media :-).
Part of the point was to be able to copy the data onto newer equipment,
which would also largely obviate the problem of finite media lifetime.
(If your flash is getting tired, just copy it onto a new one.)
Secretly, I believe that USB sticks will be out of fashion (unobtanium)
before their reliability for this purpose becomes much of an issue.
Meanwhile, CF or USB sticks would be a great transition for getting
the information off the existing aging media.
I can envision a floppy-to-CF gizmo attached to a CF-to-USB gizmo
attached to a USB-to-<future interface> gizmo, etc. as needed.
Vince
7:40 a.m.
New subject: Machine Independent Storage Idea...
9000 VAX wrote:
I don't know how much times a flash memory can be
written. It might be
OK to
make a bootable device from it.
My concern is about how to make replacement RL02, RD53 or similar. Flash
memory might not be good for this purpose.
vax, 9000
Static RAM and a nicad?
Gordon
7 Dec
7 Dec
4:08 a.m.
New subject: Machine Independent Storage Idea...
Gordon JC Pearce wrote:
9000 VAX wrote:
If the interface is CF, which is just IDE, then I suppose it's possible to
just hook an IDE hard disk up instead. Maybe :-)
(I've often wondered if I can do this with my digital camera, and the camera
will automagically know how much storage it has - but I presume that because
the camera uses a FAT filesystem it'll get upset around the 500MB mark and
probably not recognise anything beyond that)
cheers
Jules
--
there's a carp in the tub
there's a carp in the tub
so nobody's taken a bath
I don't know how much times a flash memory
can be written. It might be
OK to
make a bootable device from it.
My concern is about how to make replacement RL02, RD53 or similar. Flash
memory might not be good for this purpose.
vax, 9000
Static RAM and a nicad? 
7:16 a.m.
New subject: Machine Independent Storage Idea...
On Thursday 07 December 2006 07:08, Jules Richardson wrote:
(I've often wondered if I can do this with my
digital camera, and the
camera will automagically know how much storage it has - but I presume
that because the camera uses a FAT filesystem it'll get upset around
the 500MB mark and probably not recognise anything beyond that)
FAT16 works fine up to 2GB, and you can buy 4GB and larger flash memory
for cameras... It's possible that your camera will do FAT32 just fine,
and work with larger than 2GB filesystems.
500MB had to do with a cylinder/head/sector number limitation when you
combined the maximums you could do with IDE and the limits imposed by
BIOS calls.
Pat
--
Purdue University ITAP/RCAC --- http://www.rcac.purdue.edu/
The Computer Refuge --- http://computer-refuge.org
8:05 a.m.
New subject: Machine Independent Storage Idea...
Patrick Finnegan wrote:
On Thursday 07 December 2006 07:08, Jules Richardson
wrote:
Interesting. The camera's manual (it's a Canon G5 so what, three or four years
old?) doesn't list anything past 256MB - but then it's quite possible that
256MB was the biggest (and 'Canon approved') card around at the time.
I tend to find that if I'm taking shots of things like PCBs that it takes a
while to get the tripod and backdrop set up 'just right', so anything that
doesn't require me to disturb the camera (such as swapping CF cards) is a plus.
Other than that it's not a problem anyway, so it was more a case of idle
speculation as to whether it would work :-)
cheers
Jules
--
there's a carp in the tub
there's a carp in the tub
so nobody's taken a bath
(I've often wondered if I can do this with my
digital camera, and the
camera will automagically know how much storage it has - but I presume
that because the camera uses a FAT filesystem it'll get upset around
the 500MB mark and probably not recognise anything beyond that)
FAT16 works fine up to 2GB, and you can buy 4GB and larger flash memory
for cameras... It's possible that your camera will do FAT32 just fine,
and work with larger than 2GB filesystems.
11:17 a.m.
New subject: Machine Independent Storage Idea...
Patrick Finnegan wrote:
On Thursday 07 December 2006 07:08, Jules Richardson
wrote:
Right now I am trying to build OS/8 ( for the SBC6120 PDP/8 clone )
and I have a whole 2 meg of file space per platter -- up to 8 platters
for the drive. I am quite sure 500 meg will work fine for most classic
computer systems.
(I've often wondered if I can do this with my
digital camera, and the
camera will automagically know how much storage it has - but I presume
that because the camera uses a FAT filesystem it'll get upset around
the 500MB mark and probably not recognise anything beyond that)
FAT16 works fine up to 2GB, and you can buy 4GB and larger flash memory
for cameras... It's possible that your camera will do FAT32 just fine,
and work with larger than 2GB filesystems.
500MB had to do with a cylinder/head/sector number limitation when you
combined the maximums you could do with IDE and the limits imposed by
BIOS calls. Pat
11:56 a.m.
New subject: Machine Independent Storage Idea...
On Thu, 2006-12-07 at 06:08 -0600, Jules Richardson wrote:
If the interface is CF, which is just IDE, then I
suppose it's possible to
just hook an IDE hard disk up instead. Maybe :-)
(I've often wondered if I can do this with my digital camera, and the camera
will automagically know how much storage it has - but I presume that because
the camera uses a FAT filesystem it'll get upset around the 500MB mark and
probably not recognise anything beyond that)
I personally use a 1 GB Compact Flash card in my Nikon 990, and it
sees the whole Gig. Any point of confusion not related to specific
devices must be 'north' of that point, and probably past that of the 4GB
cards I have seen advertised. Due to binary math, 16 GB could well be a
cut-off point. Apparently, some cards HAVE large (1Gb or greater) hard
disks on them, also, so they may be even more expandable that that. (Of
course, how a hard drive fits on a CF card form factor boggles MY mind,
at least...)
Oh, and thanks to EVERYONE who has commented on this topic. It's
not really surprising that this subject generated some interest, but the
depth and range of the discussion has been most gratifying and
interesting. Thanks, again, to all involved!
Peace,
Warren E. Wolfe
wizard at voyager.net
3:12 p.m.
New subject: Machine Independent Storage Idea...
Oh, and thanks to EVERYONE who has commented on
this topic. It's
not really surprising that this subject generated some interest, but the
depth and range of the discussion has been most gratifying and
interesting. Thanks, again, to all involved!
Warren, beyond the "commercial" aspects of the device, this is something
I see very necessary for the preservation of old computers. My world
(unfortunately) revolves around MSX, TRS-80, Apple and like. If I find hard
to have good 5 1/4 disks, I can imagine people talking about DEC, VAX and
like. DC-600 and DC-2000(?) tapes seems to last forever, but your milegage
may vary. I think the construction of a kind of universal device for floppy
emulation is the next step into old gear preservation.
Greetz from Brazil
Alexandre Souza
www.tabajara-labs.com.br
10:09 a.m.
New subject: Machine Independent Storage Idea...
On 6 Dec 2006 at 15:40, Gordon JC Pearce wrote:
Static RAM and a nicad?
How about MRAM?
http://www.eetechbrief.com/browse_archived_events.php?cat_id=6 35
nsec. and unlimited writes.
Cheers,
Chuck
1:06 a.m.
New subject: Machine Independent Storage Idea...
I don't know how much times a flash memory can be
written. It might be OK
to
make a bootable device from it.
My concern is about how to make replacement RL02, RD53 or similar. Flash
memory might not be good for this purpose.
Something from 100.000 to 1.000.000 writes. Maybe battery-backed SRAM or
the newer FRAM battery-less chips fits the bill.
Greetings from Brazil
Alexandre Souza
www.tabajara-labs.com.br
8:11 a.m.
New subject: Machine Independent Storage Idea...
I haven't been following this thread too closely... but if it's going to be
a machine independent storage device, why is there talk about it being a
replacement for a floppy drive? Most of the machines in my collection didn't
have floppy drives available. There was also talk of holding the flux
transitions in a memory buffer. Is that possible on a machine with only
say... 8K of core when you consider the additional software that must be
present in the machine to interface?
I would think the best interface to a host is serial (from a common
denominator standpoint), and then provide different software on each host to
make it appear as a drive of the chosen type.
In other words, let the same device that can act as an RL02 on an DEC 11/20
also act as a 7900A on an HP 2100. I'd sure be willing to attempt finding
time to write the HP specific end :)
Jay West
8:28 a.m.
New subject: Machine Independent Storage Idea...
On Thu, 2006-12-07 at 10:11 -0600, Jay West wrote:
I would think the best interface to a host is serial
(from a common
denominator standpoint), and then provide different software on each host to
make it appear as a drive of the chosen type.
Wouldn't it make more sense to design SCSI cards for the different
machines which emulated the various relevant native disk/tape
interfaces? It would allow you to hook up any ol' removable media, or
just design a SCSI removable flash drive or something...
-Tore
8:52 a.m.
New subject: Machine Independent Storage Idea...
On 7 Dec 2006 at 10:11, Jay West wrote:
I haven't been following this thread too
closely... but if it's going to
be a machine independent storage device, why is there talk about it being
a replacement for a floppy drive? Most of the machines in my collection
didn't have floppy drives available. There was also talk of holding the
flux transitions in a memory buffer. Is that possible on a machine with
only say... 8K of core when you consider the additional software that must
be present in the machine to interface?
I was the one who was talking about a floppy replacement, only
because the topic dovetailed nicely with something I'm currently
"back of envelope-ing".
Said floppy replacement would (within limits) not give a whit what
the host machine was or its level of intelligence. It would simply
be a plug-in replacement for a standard floppy and have all the
smarts needed for that purpose self-contained.
All of the other solutions that I'm reading about on this thread
appear to be less-than-transparent replacements for existing devices
in that they require some kind of software on the host system. The
floppy drive replacement would not--you'd merely plug it in as a
replacement floppy.
If you're looking for a serial-interface (RS232/422/485) FC board,
I've already posted a link to a commerical one that retails for under
$70 and supports up to 4GB cards.
Cheers,
Chuck
10:24 a.m.
New subject: Machine Independent Storage Idea...
Chuck Guzis wrote:
On 7 Dec 2006 at 10:11, Jay West wrote:
Chuck:
It sounds like what you are looking for would be a microcontroller, some
Flash memory (or possibly a CF/SD/MMC/whatever slot), with a couple of
common floppy drive connectors (card-edge [5 1/4], card-edge [8"], and
the modern pin-style [for 3 1/2"]). The device could be "dumb" in the
first stages and just use, say, 2 megabytes of Flash. A more advanced
version would have a small display and the aforementioned memory slot,
and give you a choice of disk images stored. The "uber" advanced
version might even understand some of the standard disk-image formats,
so you could take (as an example) a CP/M or Apple ][ disk image directly
I haven't been following this thread too
closely... but if it's going to
be a machine independent storage device, why is there talk about it being
a replacement for a floppy drive? Most of the machines in my collection
didn't have floppy drives available. There was also talk of holding the
flux transitions in a memory buffer. Is that possible on a machine with
only say... 8K of core when you consider the additional software that must
be present in the machine to interface?
I was the one who was talking about a floppy replacement, only
because the topic dovetailed nicely with something I'm currently
"back of envelope-ing".
Said floppy replacement would (within limits) not give a whit what
the host machine was or its level of intelligence. It would simply
be a plug-in replacement for a standard floppy and have all the
smarts needed for that purpose self-contained. from the Internet, drop it on a CF card, and plug it in
to the computer
in question and boot from it. Heck, while we're at it, add a
mp3
decoder chip, so we can put cassette images on it. *chuckle*
The microcontroller would interpret drive step instructions and return
data from the track being read. It could also probably be designed to
turn it around: connect up a standard floppy drive of your liking, stick
a disk in, and it would make a disk image.
I don't know enough about how floppy interfaces work, but I know enough
about microcontrollers to see this as being a "not too difficult"
project from the hardware side. Coding it might be difficult, getting
all the timings right.. but it certainly does not strike me as "impossible".
11:49 a.m.
New subject: Machine Independent Storage Idea...
C. Sullivan wrote:
Chuck:
It sounds like what you are looking for would be a microcontroller, some
Flash memory (or possibly a CF/SD/MMC/whatever slot), with a couple of
common floppy drive connectors (card-edge [5 1/4], card-edge [8"], and
the modern pin-style [for 3 1/2"]).
Basing it around the size of a stock 3.5" floppy drive, with the same mounting
points, might be nice. Card slot / LCD / whatever at the front, stock power
and pin connector at the back. Convenient mounting for systems with 3.5"
drives, or with 5.25" via a bracket (I bet lots of us have one of those
brackets tidied away).
8" is left as a bit more of an engineering exercise for the reader :-)
so you could take (as an example) a CP/M or Apple ][
disk image directly
from the Internet, drop it on a CF card, and plug it in to the computer
in question and boot from it. Heck, while we're at it, add a mp3
decoder chip, so we can put cassette images on it. *chuckle*
Bah, give it a wireless card and it can get its own darn images from the
Internet! ;-)
To be honest, I'd like it if the device did have a direct-link capability to
the outside world (whether it be RS232, USB, Ethernet, parallel, SCSI, or
whatever). But I'm not *that* bothered if it doesn't; it's not that difficult
to sneakernet a CF card back and forth between the device and a modern system
(except that I blew my card reader up a couple of months back :)
IMHO: I think that having the device aware of sector, let alone filesystem,
structure is a mistake though - it just adds complexity, increases firmware
size, and can never hope to support all the systems out there anyway. Better
to make the device good at its primary job - emulating a standard floppy drive
- and leave support for more complex things to tools that can exist on a more
modern machine as and when people feel like writing them.
I don't know enough about how floppy interfaces
work, but I know enough
about microcontrollers to see this as being a "not too difficult"
project from the hardware side. Coding it might be difficult, getting
all the timings right.. but it certainly does not strike me as
"impossible".
Timings shouldn't be too tricky I would have thought. Once you know the data
rate and RPM then you know how often to sample the data stream (on floppy
write) or output the current bit (on floppy read). There aren't many more
parameters; you'd have to simulate step rate and motor on/off delays but
that's about it (sensible defaults would probably work in a lot of cases as
they can be a lot faster than a real drive - making them slow enough so as not
to cause problems is likely the issue)
If I knew anything about PIC design* I'd get to doing some messing around with
it right now... :-)
* assuming that a PIC is fast enough; it'll have to read/write to the floppy
interface side at several times the floppy data transfer rate, so several MHz
- then there are program overheads on top of that... (you could almost do a
DMA approach to/from buffer memory actually and have the CPU relatively slow...)
cheers
Jules
--
there's a carp in the tub
there's a carp in the tub
so nobody's taken a bath
12:55 p.m.
New subject: Machine Independent Storage Idea...
Jules Richardson wrote:
My view was that the "1.0" version would have USB or similar.
C. Sullivan wrote:
That was kind-of my thinking. I would build it in a full-height 5 1/4"
form factor as well, only because the extra space would be nice and it
would be easier to have both (all three?) connector formats in the
larger frame.
Chuck:
It sounds like what you are looking for would be a microcontroller,
some Flash memory (or possibly a CF/SD/MMC/whatever slot), with a
couple of common floppy drive connectors (card-edge [5 1/4],
card-edge [8"], and the modern pin-style [for 3 1/2"]).
Basing it around the size of a stock 3.5" floppy drive, with the same
mounting points, might be nice. 8" is left as a bit more of an engineering
exercise for the reader :-)
For my money, 8" compatibility would be VERY nice, especially for CP/M
and other obsolete machines of similar vintage (TRS-80 Model II comes to
mind). It is my understanding that there isn't much difference between
5 1/4" and 8" electrically, so it might be a moot point.
so you could take (as an example) a CP/M or Apple
][ disk image
directly from the Internet, drop it on a CF card, and plug it in to
the computer in question and boot from it. Heck, while we're at it,
add a mp3 decoder chip, so we can put cassette images on it. *chuckle*
Bah, give it a wireless card and it can get its own darn images from
the Internet! ;-)
To be honest, I'd like it if the device did have a direct-link
capability to the outside world (whether it be RS232, USB, Ethernet,
parallel, SCSI, or whatever). But I'm not *that* bothered if it
doesn't; it's not that difficult to sneakernet a CF card back and
forth between the device and a modern system (except that I blew my
card reader up a couple of months back :)
IMHO: I think that having the device aware of sector, let alone
filesystem, structure is a mistake though - it just adds complexity,
increases firmware size, and can never hope to support all the systems
out there anyway. Better to make the device good at its primary job -
emulating a standard floppy drive - and leave support for more complex
things to tools that can exist on a more modern machine as and when
people feel like writing them.
Understood. My intention was to make it work well as a drop-in drive
replacement, and add the other stuff as 'enhanced' features for a 2.0
(or later) device.
If I knew anything about PIC design* I'd get to doing some messing
around with it right now... :-)
A fast PIC could do it. I was leaning more towards something a little
more sophisticated (not that a PIC can't be), if for no other reason to
support the creeping features I pointed out above. Also, the floppy
timings on GCR formats can get a bit weird. FM/MFM should be fairly
easy. Hard-sector formats might even be easier, or harder. Again, I
don't know enough about the signals to really know.
I do a lot of microcontroller crap. I'm in the middle of a move right
now (from Portland, OR to Billings, MT), so I don't have a way of
testing any theories right now.. but would definately be interested in
pursuing this as a project early in the new year once I'm settled here.
Anybody interested in starting up a mailing list specifically to start
napkin-drawing this thing? I have a listserv...
1:45 p.m.
New subject: Machine Independent Storage Idea...
C. Sullivan wrote:
Oh, absolutely. I merely meant that building a suitable mounting bracket would
be done on a per-case basis (were there ever companies officially selling
5.25" to 8" drive brackets? I've never come across such a thing)
Maybe; but it's not vital to operation as the intention would be for the
primary storage to be something like a CF card or a USB stick. Although that
is interesting; the primary store is a USB stick then it's presumably easy to
code the firmware so that the device can be plugged in via a cable to a system
running suitable host software as an alternative (providing the device holds
sufficient local memory to buffer a track and USB data transfer to the host is
fast enough to not upset whatever the floppy emulator's plugged in to).
Of course I suspect that most of us on here (and in the context of vintage
hardware in general) are more comfortable with something like RS232...
Personally if I were building it I'd put an expansion bus connector on the
board and forget about any kind of host interface for the the initial release;
people can add daughtercards (and updated firmware) for their favourite comms
interface at a later date...
Complete agreement. Keep it simple for an initial release; just keep it in
mind what direction it *might* take in future, I suppose. Key for an initial
release would be getting it to act like a floppy drive *reliably* and working
with some form of local storage (personally I like CF, but then I do tend to
be a bit anti-USB :-)
That's interesting; personally I hadn't thought about GCR at all really. The
sort of thing I have stuck in my head right now has three small boards to it:
1) A 'core' board containing CPU, a bit of addressing logic, some local
memory (whether a whole track buffer or not I don't know), LCD / switch logic,
ROM, and a header for future expansion.
2) A 'local storage interface' board, such as one holding a Compact Flash
connector and any control logic (I'd hope that most work could be done in
software)
3) An 'emulation' board containing the floppy side of things - connector,
buffers, and simple control logic (again I'd hope software could do the
necessary line twiddling.
The interface between the boards would just be an expansion bus; essentially
just CPU lines and a bit of selection logic. The key is that such an approach
allows someone to make the floppy-side 'emulation' board totally different in
future (along with a firmware change) to support some completely different
floppy electrical specification, or even make it look to a vintage machine
like some totally different low-speed data device.
Similarly, the 'local storage' side of things could be swapped for something
else; but the core elements of the device would be that it does have some form
of local storage (even if a remote host is connected via some other comms
interface), some form of interface board to a vintage system, and that the
'core' board stays the same (with the exception of firmware changes).
But, I'm not a hardware designer, so all of that is probably wrong. :-)
8" is
left as a bit more of an engineering exercise for the reader :-)
For my money, 8" compatibility would be VERY nice It is my understanding that there isn't much
difference between
5 1/4" and 8" electrically, so it might be a moot point.
Certainly it seems that driving a 8" drive using an 5.25" disk controller
isn't too difficult in a lot of cases. I don't know if the reverse is true
though, i.e. how easy it is to make the interface found on a typical 5.25"
drive work with a system that's expecting 8" disks.
To be honest,
I'd like it if the device did have a direct-link
capability to the outside world (whether it be RS232, USB, Ethernet,
parallel, SCSI, or whatever). But I'm not *that* bothered if it
doesn't; it's not that difficult to sneakernet a CF card back and
forth between the device and a modern system (except that I blew my
card reader up a couple of months back :)
My view was that the "1.0" version would have USB or similar. ...
Understood. My intention was to make it work well as a drop-in drive
replacement, and add the other stuff as 'enhanced' features for a 2.0
(or later) device. If I knew
anything about PIC design* I'd get to doing some messing
around with it right now... :-)
A fast PIC could do it. I was leaning more towards something a little
more sophisticated (not that a PIC can't be), if for no other reason to
support the creeping features I pointed out above. Also, the floppy
timings on GCR formats can get a bit weird. FM/MFM should be fairly
easy. Hard-sector formats might even be easier, or harder.
Again, I
don't know enough about the signals to really know.
I suspect it's easy enough (but I don't know for sure). It can't be *that*
complex, but whether it needs a change in hardware, I don't know. But see
above - worst-case it's just a different emulation board.
I do a lot of microcontroller crap. I'm in the
middle of a move right
now (from Portland, OR to Billings, MT), so I don't have a way of
testing any theories right now.. but would definately be interested in
pursuing this as a project early in the new year once I'm settled here.
Anybody interested in starting up a mailing list specifically to start
napkin-drawing this thing? I have a listserv...
I just said that in a private email to Chuck a few hours ago, too :) I'm all
for it - personally what I wouldn't want to see happening is people wanting
millions of features from day one, though (that's what kills a lot of
theoretical discussions on here! :)
But a simple device that looks like an SA400/SA800 type floppy drive and uses
some form of 'portable' local storage, and has some reasonable expansion
options / future-proofing - yeah, I think that's probably doable. It's not
exactly Warren's dream of a 'portable to every system' type device, but
it's a
still a darn useful thing to have and I suspect would solve a lot of problems
for a lot of people (particularly longer-term).
Plus it should be reasonably trivial to provide 'floppy to simulator' copying
in the future without a physical vintage machine, which means that for not
much effort we get the ability to archive possibly-damaged disks from vintage
systems onto modern media. (I think Chuck was seeing that as a feature of the
simulator, whereas I was seeing it more as a simple box of tricks which sat
between the simulator and a physical drive to handle the necessary signalling)
cheers
Jules
(all 'theorised out' today! :)
8 Dec
8 Dec
6:06 a.m.
New subject: Machine Independent Storage Idea...
On Thursday 07 December 2006 16:45, you wrote:
Maybe; but it's not vital to operation as the intention would be for the
primary storage to be something like a CF card or a USB stick. Although
that is interesting; the primary store is a USB stick then it's presumably
easy to code the firmware so that the device can be plugged in via a cable
to a system running suitable host software as an alternative (providing the
device holds sufficient local memory to buffer a track and USB data
transfer to the host is fast enough to not upset whatever the floppy
emulator's plugged in to).
Of course I suspect that most of us on here (and in the context of vintage
hardware in general) are more comfortable with something like RS232...
Personally if I were building it I'd put an expansion bus connector on the
board and forget about any kind of host interface for the the initial
release; people can add daughtercards (and updated firmware) for their
favourite comms interface at a later date...
Complete agreement. Keep it simple for an initial release; just keep it in
mind what direction it *might* take in future, I suppose. Key for an
initial release would be getting it to act like a floppy drive *reliably*
and working with some form of local storage (personally I like CF, but then
I do tend to be a bit anti-USB :-)
That's interesting; personally I hadn't thought about GCR at all really.
The sort of thing I have stuck in my head right now has three small boards
to it:
1) A 'core' board containing CPU, a bit of addressing logic, some local
memory (whether a whole track buffer or not I don't know), LCD / switch
logic, ROM, and a header for future expansion.
2) A 'local storage interface' board, such as one holding a Compact
Flash connector and any control logic (I'd hope that most work could be
done in software)
3) An 'emulation' board containing the floppy side of things -
connector, buffers, and simple control logic (again I'd hope software could
do the necessary line twiddling.
The interface between the boards would just be an expansion bus;
essentially just CPU lines and a bit of selection logic. The key is that
such an approach allows someone to make the floppy-side 'emulation' board
totally different in future (along with a firmware change) to support some
completely different floppy electrical specification, or even make it look
to a vintage machine like some totally different low-speed data device.
Similarly, the 'local storage' side of things could be swapped for
something else; but the core elements of the device would be that it does
have some form of local storage (even if a remote host is connected via
some other comms interface), some form of interface board to a vintage
system, and that the 'core' board stays the same (with the exception of
firmware changes).
But, I'm not a hardware designer, so all of that is probably wrong. :-)
C. Sullivan wrote:
Oh, absolutely. I merely meant that building a suitable mounting bracket
would be done on a per-case basis (were there ever companies officially
selling 5.25" to 8" drive brackets? I've never come across such a thing)
I have a pair of teac fd55gfr (5.25 DSDD) drives running on a Monolithic
systems Z80 multibus board. I built a small board to handle the connector
difference. I used an AVR to generate the missing motor on signal.
It looks at the drive select signals and asserts motor on if any drive is
selected. It deasserts motor on after 15 seconds of no drive selected.
So i guess the short answer is it's not hard. I did it.
None of this is an issue for a storage dongle... It doesn't have a motor ;-)
8"
is left as a bit more of an engineering exercise for the reader :-)
For my money, 8" compatibility would be VERY nice It is my understanding that there isn't much
difference between
5 1/4" and 8" electrically, so it might be a moot point.
Certainly it seems that driving a 8" drive using an 5.25" disk controller
isn't too difficult in a lot of cases. I don't know if the reverse is true
though, i.e. how easy it is to make the interface found on a typical 5.25"
drive work with a system that's expecting 8" disks. To be
honest, I'd like it if the device did have a direct-link
capability to the outside world (whether it be RS232, USB, Ethernet,
parallel, SCSI, or whatever). But I'm not *that* bothered if it
doesn't; it's not that difficult to sneakernet a CF card back and
forth between the device and a modern system (except that I blew my
card reader up a couple of months back :)
My view was that the "1.0" version would have USB or similar. ...
Understood. My intention was to make it work well as a drop-in drive
replacement, and add the other stuff as 'enhanced' features for a 2.0
(or later) device. If I knew
anything about PIC design* I'd get to doing some messing
around with it right now... :-)
A fast PIC could do it. I was leaning more towards something a little
more sophisticated (not that a PIC can't be), if for no other reason to
support the creeping features I pointed out above. Also, the floppy
timings on GCR formats can get a bit weird. FM/MFM should be fairly
easy. Hard-sector formats might even be easier, or
harder. Again, I
don't know enough about the signals to really know.
I suspect it's easy enough (but I don't know for sure). It can't be *that*
complex, but whether it needs a change in hardware, I don't know. But see
above - worst-case it's just a different emulation board.
I do a lot of microcontroller crap. I'm in
the middle of a move right
now (from Portland, OR to Billings, MT), so I don't have a way of
testing any theories right now.. but would definately be interested in
pursuing this as a project early in the new year once I'm settled here.
Anybody interested in starting up a mailing list specifically to start
napkin-drawing this thing? I have a listserv...
I just said that in a private email to Chuck a few hours ago, too :) I'm
all for it - personally what I wouldn't want to see happening is people
wanting millions of features from day one, though (that's what kills a lot
of theoretical discussions on here! :)
But a simple device that looks like an SA400/SA800 type floppy drive and
uses some form of 'portable' local storage, and has some reasonable
expansion options / future-proofing - yeah, I think that's probably
doable. It's not exactly Warren's dream of a 'portable to every system'
type device, but it's a still a darn useful thing to have and I suspect
would solve a lot of problems for a lot of people (particularly
longer-term).
Plus it should be reasonably trivial to provide 'floppy to simulator'
copying in the future without a physical vintage machine, which means that
for not much effort we get the ability to archive possibly-damaged disks
from vintage systems onto modern media. (I think Chuck was seeing that as a
feature of the simulator, whereas I was seeing it more as a simple box of
tricks which sat between the simulator and a physical drive to handle the
necessary signalling)
cheers
Jules
(all 'theorised out' today! :)
9:04 a.m.
New subject: Machine Independent Storage Idea...
On 8 Dec 2006 at 9:06, joseph c lang wrote:
I have a pair of teac fd55gfr (5.25 DSDD) drives
running on a Monolithic
systems Z80 multibus board. I built a small board to handle the connector
difference. I used an AVR to generate the missing motor on signal.
It looks at the drive select signals and asserts motor on if any drive is
selected. It deasserts motor on after 15 seconds of no drive selected.
I guess I AM showing my age. My first impulse would have been to use
a 555--and the same for synthesizing a READY* signal if the drive
had no jumper to provide one.
Although using an AVR or PIC is also a great idea--just never thought
of using an MCU for such a simple job. Geezer's disease, I guess.
Cheers,
Chuck
So i guess the short answer is it's not hard. I did it.
None of this is an issue for a storage dongle... It doesn't have a motor ;-)
>
> >> To be honest, I'd like it if the device did have a direct-link
> >> capability to the outside world (whether it be RS232, USB, Ethernet,
> >> parallel, SCSI, or whatever). But I'm not *that* bothered if it
> >> doesn't; it's not that difficult to sneakernet a CF card back and
> >> forth between the device and a modern system (except that I blew my
> >> card reader up a couple of months back :)
> >
> > My view was that the "1.0" version would have USB or similar.
>
> Maybe; but it's not vital to operation as the intention would be for the
> primary storage to be something like a CF card or a USB stick. Although
> that is interesting; the primary store is a USB stick then it's presumably
> easy to code the firmware so that the device can be plugged in via a cable
> to a system running suitable host software as an alternative (providing the
> device holds sufficient local memory to buffer a track and USB data
> transfer to the host is fast enough to not upset whatever the floppy
> emulator's plugged in to).
>
> Of course I suspect that most of us on here (and in the context of vintage
> hardware in general) are more comfortable with something like RS232...
>
> Personally if I were building it I'd put an expansion bus connector on the
> board and forget about any kind of host interface for the the initial
> release; people can add daughtercards (and updated firmware) for their
> favourite comms interface at a later date...
>
> >>...
> >
> > Understood. My intention was to make it work well as a drop-in drive
> > replacement, and add the other stuff as 'enhanced' features for a 2.0
> > (or later) device.
>
> Complete agreement. Keep it simple for an initial release; just keep it in
> mind what direction it *might* take in future, I suppose. Key for an
> initial release would be getting it to act like a floppy drive *reliably*
> and working with some form of local storage (personally I like CF, but then
> I do tend to be a bit anti-USB :-)
>
> >> If I knew anything about PIC design* I'd get to doing some messing
> >> around with it right now... :-)
> >
> > A fast PIC could do it. I was leaning more towards something a little
> > more sophisticated (not that a PIC can't be), if for no other reason to
> > support the creeping features I pointed out above. Also, the floppy
> > timings on GCR formats can get a bit weird. FM/MFM should be fairly
> > easy.
>
> That's interesting; personally I hadn't thought about GCR at all really.
> The sort of thing I have stuck in my head right now has three small boards
> to it:
>
> 1) A 'core' board containing CPU, a bit of addressing logic, some local
> memory (whether a whole track buffer or not I don't know), LCD / switch
> logic, ROM, and a header for future expansion.
> 2) A 'local storage interface' board, such as one holding a Compact
> Flash connector and any control logic (I'd hope that most work could be
> done in software)
> 3) An 'emulation' board containing the floppy side of things -
> connector, buffers, and simple control logic (again I'd hope software could
> do the necessary line twiddling.
>
> The interface between the boards would just be an expansion bus;
> essentially just CPU lines and a bit of selection logic. The key is that
> such an approach allows someone to make the floppy-side 'emulation' board
> totally different in future (along with a firmware change) to support some
> completely different floppy electrical specification, or even make it look
> to a vintage machine like some totally different low-speed data device.
>
> Similarly, the 'local storage' side of things could be swapped for
> something else; but the core elements of the device would be that it does
> have some form of local storage (even if a remote host is connected via
> some other comms interface), some form of interface board to a vintage
> system, and that the 'core' board stays the same (with the exception of
> firmware changes).
>
> But, I'm not a hardware designer, so all of that is probably wrong. :-)
>
> > Hard-sector formats might even be easier, or harder. Again, I
> > don't know enough about the signals to really know.
>
> I suspect it's easy enough (but I don't know for sure). It can't be
*that*
> complex, but whether it needs a change in hardware, I don't know. But see
> above - worst-case it's just a different emulation board.
>
> > I do a lot of microcontroller crap. I'm in the middle of a move right
> > now (from Portland, OR to Billings, MT), so I don't have a way of
> > testing any theories right now.. but would definately be interested in
> > pursuing this as a project early in the new year once I'm settled here.
> > Anybody interested in starting up a mailing list specifically to start
> > napkin-drawing this thing? I have a listserv...
>
> I just said that in a private email to Chuck a few hours ago, too :) I'm
> all for it - personally what I wouldn't want to see happening is people
> wanting millions of features from day one, though (that's what kills a lot
> of theoretical discussions on here! :)
>
> But a simple device that looks like an SA400/SA800 type floppy drive and
> uses some form of 'portable' local storage, and has some reasonable
> expansion options / future-proofing - yeah, I think that's probably
> doable. It's not exactly Warren's dream of a 'portable to every
system'
> type device, but it's a still a darn useful thing to have and I suspect
> would solve a lot of problems for a lot of people (particularly
> longer-term).
>
> Plus it should be reasonably trivial to provide 'floppy to simulator'
> copying in the future without a physical vintage machine, which means that
> for not much effort we get the ability to archive possibly-damaged disks
> from vintage systems onto modern media. (I think Chuck was seeing that as a
> feature of the simulator, whereas I was seeing it more as a simple box of
> tricks which sat between the simulator and a physical drive to handle the
> necessary signalling)
>
> cheers
>
> Jules
> (all 'theorised out' today! :)
9 Dec
9 Dec
6:02 a.m.
New subject: Machine Independent Storage Idea...
On Friday 08 December 2006 12:04, you wrote:
On 8 Dec 2006 at 9:06, joseph c lang wrote:
Actually My first draft was a 555. By the time all the requirements were met,
the component count had gotten out of hand. 7420,555,7438,handfull
of descretes... a single 20 pin package a crystal and a transistor didn't
seem like overkill.
And it would handle the creeping feature bloat My projects suffer from ;^)
joe
I have a pair of teac fd55gfr (5.25 DSDD) drives
running on a Monolithic
systems Z80 multibus board. I built a small board to handle the connector
difference. I used an AVR to generate the missing motor on signal.
It looks at the drive select signals and asserts motor on if any drive is
selected. It deasserts motor on after 15 seconds of no drive selected.
I guess I AM showing my age. My first impulse would have been to use
a 555--and the same for synthesizing a READY* signal if the drive
had no jumper to provide one.
Although using an AVR or PIC is also a great idea--just never thought
of using an MCU for such a simple job. Geezer's disease, I guess.
Cheers,
Chuck
8:45 a.m.
New subject: Machine Independent Storage Idea...
On 9 Dec 2006 at 9:02, joseph c lang wrote:
Actually My first draft was a 555. By the time all the
requirements were met,
the component count had gotten out of hand. 7420,555,7438,handfull
of descretes... a single 20 pin package a crystal and a transistor didn't
seem like overkill.
And it would handle the creeping feature bloat My projects suffer from ;^)
I happened to mention this to a customer yesterday who sells
computerized scales and the like. His comment was that a PIC was
very competitive with a 555, when one considered the external
discrete component count and glue--although he admitted that a number
of his products still use lots of 555s.
Cheers,
Chuck
3:42 p.m.
New subject: Machine Independent Storage Idea...
On Dec 9, 2006, at 11:45 AM, Chuck Guzis wrote:
I can see that being the case when you need multiple related pulse
trains or something like that...but to replace a single 555, I find
this very difficult to believe. I've designed both into commercial
products in the last few years...Sure, PICs are super cheap, but 555s
in thousand-unit quantities cost less than a dime. As for the
discrete components...Assuming you're running the PIC in internal
oscillator mode (which saves you a crystal and two capacitors), you
need a pullup resistor to MCLR, while a typical 555 oscillator
circuit needs one or two resistors and a capacitor...so a capacitor
and possible additional resistor. Add in the step of having to
program the PIC (and maintain the codebase, documentation, etc)...no
way.
It seems to me that many of these types of attitudes stem from the
"if it's old, it's bad, and if it's not new, it's old" mentality
that
has been adopted by the obedient mass of consumers.
-Dave
--
Dave McGuire
Cape Coral, FL
Actually My
first draft was a 555. By the time all the
requirements were met,
the component count had gotten out of hand. 7420,555,7438,handfull
of descretes... a single 20 pin package a crystal and a transistor
didn't
seem like overkill.
And it would handle the creeping feature bloat My projects suffer
from ;^)
I happened to mention this to a customer yesterday who sells
computerized scales and the like. His comment was that a PIC was
very competitive with a 555, when one considered the external
discrete component count and glue--although he admitted that a number
of his products still use lots of 555s.
4:03 p.m.
New subject: Machine Independent Storage Idea...
On 9 Dec 2006 at 18:42, Dave McGuire wrote:
It seems to me that many of these types of
attitudes stem from the
"if it's old, it's bad, and if it's not new, it's old"
mentality that
has been adopted by the obedient mass of consumers.
My reaction upon getting my first NE555 was "Isn't that just the most
clever thing you've ever seen?--and in an 8 pin DIP, too!"
You probably won't see many LS121/123/221s in modern circuits, but
the lowly 555 still marches on.
Cheers,
Chuck
10 Dec
10 Dec
1:21 a.m.
New subject: Machine Independent Storage Idea...
Chuck Guzis wrote:
On 9 Dec 2006 at 18:42, Dave McGuire wrote:
Similar to my first thoughts on playing with an NE555. My second
thought on using it was "where the fsck is all this hash on the supply
line coming from?!"
Gordon
It seems to me that many of these types of
attitudes stem from the
"if it's old, it's bad, and if it's not new, it's old"
mentality that
has been adopted by the obedient mass of consumers.
My reaction upon getting my first NE555 was "Isn't that just the most
clever thing you've ever seen?--and in an 8 pin DIP, too!"
2:23 p.m.
New subject: Machine Independent Storage Idea...
The easiest way to make a floppy drive replacement, in my opnion, is to make
an ISA card and to rely on a DOS program. You get everything this way. You
can even get a PC104 board and embed your PC into the floppy drive case, and
attach whatever media you come in mind with it.
vax, 9000, who gets along well with X86, PC and DOS
2:26 p.m.
New subject: Machine Independent Storage Idea...
In article <160501c71a55$73c485f0$f0fea8c0 at alpha>,
"Alexandre Souza" <alexandre-listas at e-secure.com.br> writes:
Chalk me on that! But would this kind of chat be
offtopic for this list?
I don't think it would be off topic, but everyone likes to complain
about something.
--
"The Direct3D Graphics Pipeline" -- DirectX 9 draft available for download
<http://www.xmission.com/~legalize/book/download/index.html>
Legalize Adulthood! <http://blogs.xmission.com/legalize/>
8 Dec
8 Dec
12:55 p.m.
New subject: Machine Independent Storage Idea...
It was written...
> Anybody interested in starting up a mailing list
specifically to start
> napkin-drawing this thing? I have a listserv...
As do I ;) I wouldn't
think it's necessary though... see below...
Chalk me on that! But would this kind of chat be
offtopic for this
list?
This has been discussed before. This type of conversation is most definitely
on-topic.
Jay West
12:57 p.m.
New subject: Machine Independent Storage Idea...
However this winds up being done.... I'd love it if there was an RS232
serial interface on it with some type of procotol that was documented. I'd
LOVE to write a little driver on the HP 2100 that let me write files to it
which could then be moved back and forth to a PC...
Jay
1:47 p.m.
New subject: Machine Independent Storage Idea...
On Fri, 2006-12-08 at 14:57 -0600, Jay West wrote:
However this winds up being done.... I'd love it
if there was an RS232
serial interface on it with some type of procotol that was documented. I'd
LOVE to write a little driver on the HP 2100 that let me write files to it
which could then be moved back and forth to a PC...
Well, if I can (at best) combine or (at worst) conflate two ongoing
topics... Why not just write an XModem driver for the HP 2100, and
connect to a PC as a BBS? Come to think of it, there are probably
XModem (or derivatives or competitors) protocol drivers for it
already...
On an unrelated topic, did you ever hear of Steve Schmidt? I used
to work with HP 21MX machines. He, in order to make a very useful
department computer at Michigan Technical University, wrote CP/M into
microcode on the 21MX. It was full multi-user, and he implemented Z-80
instructions in microcode, too. Oh, yes, the CP/M call was a single
micro-coded instruction. They used various CP/M commercial software on
it, and were quite pleased.
Peace,
Warren E. Wolfe
wizard at voyager.net
10 Dec
10 Dec
6:45 p.m.
New subject: Machine Independent Storage Idea...
However this winds up being done.... I'd love it
if there was an RS232
serial interface on it with some type of procotol that was documented. I'd
LOVE to write a little driver on the HP 2100 that let me write files to it
which could then be moved back and forth to a PC...
Jay, it can be done (forgot how to spell 'definitely'). But..."why"?
Compactflash is fast/big enough, to use a serial cable I'd have to create a
way to write on the CF (and it can be done faster thru a CF card writter) or
to have SRAM on board. Maybe I can use RS232/USB, who knows? I'm here to
please you all :oD
7 Dec
7 Dec
3:42 p.m.
New subject: Machine Independent Storage Idea...
BTW, anyone got the SA-400 and FD-400 techinical manuals? I'm googgling
it but nothing useful found...
Thanks
Alexandre Souza
www.tabajara-labs.com.br
2:59 p.m.
New subject: Machine Independent Storage Idea...
On 7 Dec 2006 at 20:42, Alexandre Souza wrote:
BTW, anyone got the SA-400 and FD-400 techinical manuals? I'm googgling
it but nothing useful found...
Is this what you're looking for?
http://www.bitsavers.org/pdf/shugart/54102-2_SA400_OEM_Sep78.pdf
Cheers,
Chuck
3:09 p.m.
New subject: Machine Independent Storage Idea...
> I don't know enough about how floppy
interfaces work, but I know enough
> about microcontrollers to see this as being a "not too difficult" project
> from the hardware side. Coding it might be difficult, getting all the
> timings right.. but it certainly does not strike me as "impossible".
Jules, seems that it is easy enough. I already started to do some
experiments. In my proposition of the three-layers, the first and second
layers are almost done. I just need to dig deeper into the floppy innards.
Shuggart interface specialists around? :o)
For me it HAS to emulate the physical drive, and not the OS/formatting
of the target. If you have a bit more work to emulate the physical drive,
you'll have a universal device. What about a group digging into that?
If I knew anything about PIC design* I'd get to
doing some messing around
with it right now... :-)
www.mcselec.com - download BASCOM-AVR and get some Atmega32 or
Atmega128, you'll have a great surprise of how easy is to use that.
* assuming that a PIC is fast enough; it'll have
to read/write to the
floppy interface side at several times the floppy data transfer rate, so
several MHz - then there are program overheads on top of that... (you
could almost do a DMA approach to/from buffer memory actually and have the
CPU relatively slow...)
AFAIK, the "mechanicals" of the drive can be separated into two points:
- Mechanical control and sensing: track up/down, motor on/off, select
head 0/1, index hole, disk change, density select
- Logical encoding of MFM data: get raw sector data, output MFM-encoded
data
The first is a breeze. The second I have no experience but seems easy
enough by what I saw on wikipedia. I have a "digital alignment disk" for 3
1/2 720K floppies. Since the data on this disk is know (and have no
sector/track encoding, just raw data), I'll try to read and understand that.
If someone is willing to help, contact me privately. I'm using AVR
microcontrollers and the Bascom compiler. I'm looking for the shuggart
manual of the disk interface (ST-406?).
Greetz from Brazil
Alexandre Souza
9:02 a.m.
New subject: Machine Independent Storage Idea...
Jay West wrote:
I haven't been following this thread too
closely... but if it's going to
be a machine independent storage device, why is there talk about it
being a replacement for a floppy drive?
I think some of us (myself included) sort of hijacked the thread (sorry Warren!).
Personally I don't think that true independence (i.e. a device for any
machine) is possible, partly because as you say some systems lack the
necessary abilities, and mainly because it's so much work (heck, how many
different systems have been built over the years? How many different interface
boards would have to be made and software written to access them?)
Targetting a specific storage medium - such as the floppy, whose days are
numbered - does seem like a worthwhile project, though. Even there there are a
lot of access methods to rotating removeable magnetic media, so picking the
most common (such as SA400/800 drives) seems a sensible starting point.
There was also talk of
holding the flux transitions in a memory buffer.
Only within the context of the on-board memory for a device which emulated a
floppy drive, I think. Such a device doesn't make any assumptions about the
system's hardware other than needing to know the data transfer rate across the
floppy interface.
In other words, let the same device that can act as an
RL02 on an DEC
11/20 also act as a 7900A on an HP 2100. I'd sure be willing to attempt
finding time to write the HP specific end :)
Great, so that's one tiny corner of the HP world covered, then ;-)
Seriously, I really think it's waaay too much work (and in fact probably
impossible; there must be plenty of systems out there for which sufficient
technical documentation to build an interface and write the software no longer
exists)
However, emulating the common devices used as primary storage on vintage
machines I think is a little more achievable; there are way less possible
types than there are possible systems. It'd still be a daunting task to try
and do everything - hence my feeling we should pick something common like the
floppy drive (with the most common interface) for starters.
cheers
Jules
6:24 p.m.
New subject: Machine Independent Storage Idea...
On Thu, 2006-12-07 at 10:11 -0600, Jay West wrote:
I would think the best interface to a host is serial
(from a common
denominator standpoint), and then provide different software on each host to
make it appear as a drive of the chosen type.
Yes... with storage of USB stick or CF card, or whatever. (Those
were my two choices.) I have found the discussion of the possibilities
and approaches to be most intriguing. To tell the truth, I had not
thought at all about recording the flux from diskettes...
Anyway, diskettes are going the way of the dodo. I have several
older machines, and spent a good part of the last two days trying,
unsuccessfully, to find 5-1/4 inch diskettes for sale. They simply are
not carried any more. And, I live in the heart of a truly major retail
center -- I've been in EVERY major computer and electronics store, and
many of the minor ones in the last 48 hours.
That adds a certain urgency to the project. Diskettes have a
limited lifespan, and, without replacement media, it is not possible to
format new disks and move information off aging media to preserve it.
In other words, let the same device that can act as an
RL02 on an DEC 11/20
also act as a 7900A on an HP 2100. I'd sure be willing to attempt finding
time to write the HP specific end :)
Yeah, THAT was the idea...
Peace,
Warren E. Wolfe
wizard at voyager.net
6 Dec
6 Dec
7:47 a.m.
New subject: Most simple interface for modern Storage (Was: Machine Independent Storage Idea)
No longer actve following the list I stumbled across this discussion...
Am 6 Dec 2006 8:05 meinte Jules Richardson:
> Thinking about it is about as far as I got. From
what I
> understand, the electronics and software for interfacing Compact Flash
> is a little easier than USB.
It's IDE on a smaller pin pitch I think. Certainly
there's no smarts to the
IDE-CF convertor that I have here - CF socket, power socket, IDE socket, a
capacitor, and a jumper for master/slave. That's it.
And like SCSI, interfacing to IDE is mainly a software
issue - the hardware
tends to be a few buffers and little more.
As if using CF in memory Mode not even that. Still, you need
(beside MS-DOS file system et al) to have enough free interface
lines and beeing able to folow a protocoll with multiple control
lines. If you realy look for a simple and easy modern readable
media to interface for most computers, I would recommend MMC (and
compatible SD-Card) media. As most basic interface they support
SPI, a 4 wire serial bus that can operate at any speed from zero
to 20 MHz with almost no need for additional hardware.
A year ago I did even an implementation using the Apple ][ game
port. No need to say that the transferrate was rather slow, still
on par with floppy speed :)
Gruss
H.
--
VCF Europa 8.0 am 28/29.April 2007 in Muenchen
http://www.vcfe.org/
7 Dec
7 Dec
1:05 a.m.
New subject: Machine Independent Storage Idea...
Question: do CF cards support 8 bit transfers though,
and are they
guaranteed to do so? IDE interfaces have been homebrewed to a lot of
vintage machines, but quite often they only support drives that'll do 8
bit data transfers.
Yep, they do.
It's IDE on a smaller pin pitch I think. Certainly
there's no smarts to
the IDE-CF convertor that I have here - CF socket, power socket, IDE
socket, a capacitor, and a jumper for master/slave. That's it.
Yes, you are sure
And like SCSI, interfacing to IDE is mainly a software
issue - the
hardware tends to be a few buffers and little more.
This is "not so easy" as you may think. But my three-layers-approach
seems to fit nicely here.
Anyone has the protocol of a QIC-80 drive? I'd like to take a peek on
that.
BTW, remember: This does not need to be a CF card, it can even be some
cheap SRAM memory and a serial or ethernet connection... :o)
Greetz from Brazil
Alexandre Souza
www.tabajara-labs.com.br
6 Dec
6 Dec
8:15 a.m.
New subject: Machine Independent Storage Idea...
On 6 Dec 2006 at 10:46, Simon Fryer wrote:
I was thinking of doing the same sort of thing but
using compact flash
cards and building some electronics as the interface for the QIC tape
interface. Thinking about it is about as far as I got. From what I
understand, the electronics and software for interfacing Compact Flash
is a little easier than USB.
I've been toying with the idea of using a CF to provide emulation for
floppy drives. More complicated, as the thing has to look like a
floppy. Rather than record separated data, I'm inclined to record
flux transitions on the CF, so a disk would require something on the
order of 128KBytes per track (for a 300 RPM 500KHz drive). i.e.,
the drive would be data-encoding independent. Since one can get 4GB
CF cards, this shouldn't be a problem . Managing multiple images
from a single CF card will require some careful
thought. Simulating
multiple drives with a single unit is another possibility.
There are still whole segments of the industrial market where
floppies represent the only available interface for older equipment.
For the interested, here's a RS232/485-to-CF card development board.
Note that it's pretty simple, using a PIC for most functions.
http://www.futurlec.com/CompBoard_Technical.shtml
I've been using the same outfit's USB-to-parallell I/O module and
find that it's easy to use (and plugs into a 32-pin DIP socket).
Cheers,
Chuck
9:21 a.m.
New subject: Machine Independent Storage Idea...
Chuck Guzis wrote:
On 6 Dec 2006 at 10:46, Simon Fryer wrote:
I've been toying with the idea of using a CF to provide emulation for
floppy drives. More complicated, as the thing has to look like a
floppy. Rather than record separated data, I'm inclined to record
flux transitions on the CF, so a disk would require something on the
order of 128KBytes per track (for a 300 RPM 500KHz drive). i.e.,
the drive would be data-encoding independent. Since one can get 4GB
CF cards, this shouldn't be a problem .
Yep, gut-feeling is that it'd be useful (see other post, assuming it made it -
been having some email troubles today).
I was a bit concerned about the write speed of CF (remember the discussion
about a 'universal floppy disk reader' gadget a short while ago), but I think
it works out as being fast enough for recording flux transitions at suitable
oversampling.
I suppose you need a fair bit of on-board CPU power to process the data (given
that it has to do serial-parallel conversion between drive interface and card).
Managing multiple images
from a single CF card will require some careful thought.
Darn interesting idea, though :) That implies some intelligence controlling
the gadget 'remotely' though, or at the mickey-mouse end of the scale, a
rotary switch on top of the device to say which image to select. Perhaps a
version 2 thing?
Simulating multiple drives with a single unit is
another possibility.
Hmm, that 'feels' messy, somehow. Not sure why - but I think I'd prefer one
gadget per drive...
cheers
Jules
--
there's a carp in the tub
there's a carp in the tub
so nobody's taken a bath
9:38 a.m.
New subject: Machine Independent Storage Idea...
On 6 Dec 2006 at 11:21, Jules Richardson wrote:
Darn interesting idea, though :) That implies some
intelligence controlling
the gadget 'remotely' though, or at the mickey-mouse end of the scale, a
rotary switch on top of the device to say which image to select. Perhaps a
version 2 thing?
Ideally, a couple of pushbuttons and a small LCD display, I'd think.
Floppy changing is a manual effort in the real world; no reason to do
it differently in the simulated world.
Hmm, that 'feels' messy, somehow. Not sure why
- but I think I'd prefer one
gadget per drive...
Yeah, it occurred to me that you'd get into the situation of "My A:
drive is on one CF card, but my B: drive is on another. What do I
do?" (2 CF slots, maybe?)
Per-track access time from the CF shouldn't be much of an issue. One
can always delay the index pulse until the data is ready (recall that
at 300 RPM, an index pulse occurs every 200 msec.).
Cheers,
Chuck
10:35 a.m.
New subject: Machine Independent Storage Idea...
Chuck Guzis wrote:
It just feels like it might get complex at that point - and costly. I suppose
you can put a header (or even just pads for one) on the main board for a cable
going to a second card, but not worry about the expense of adding a second
slot right now; sort of make it an optional extra. If CF is just IDE then it
should presumably be dead easy to support one or two cards on the same bus
anyway without additional logic.
Same deal on the floppy interface side - make it possible to hook it up as two
drives if someone wants to buy the extra cabling and relevant interface logic,
but don't actually provide that in the initial design (heck, don't even worry
about the firmware for it at this stage).
Later on it can then be done if people need it without a change of core design
or PCBs (just new firmware and additional hardware), but you're not worried
about every possible scenario from day 1.
On 6 Dec 2006 at 11:21, Jules Richardson wrote:
True. A link to a modern machine might be nice for transfer, though (to save
on swapping cards around). But I remember the lengthy discussions about what
the 'best' interface is in the past :-)
I was thinking that some sort of switch is a bit clunky - but with your
addition of the LCD the device would be able to display more information about
which file was selected (rather than having to rely on the user knowing that
the thing in 'slot' #0 was disk xyz etc.)
Darn interesting idea, though :) That implies
some intelligence controlling
the gadget 'remotely' though, or at the mickey-mouse end of the scale, a
rotary switch on top of the device to say which image to select. Perhaps a
version 2 thing?
Ideally, a couple of pushbuttons and a small LCD display, I'd think.
Floppy changing is a manual effort in the real world; no reason to do
it differently in the simulated world. Hmm, that
'feels' messy, somehow. Not sure why - but I think I'd prefer one
gadget per drive...
Yeah, it occurred to me that you'd get into the situation of "My A:
drive is on one CF card, but my B: drive is on another. What do I
do?" (2 CF slots, maybe?) Per-track access time from the CF shouldn't be
much of an issue. One
can always delay the index pulse until the data is ready (recall that
at 300 RPM, an index pulse occurs every 200 msec.).
True, but then wouldn't you have to buffer the entire written (computer to
device) and oversampled track of data in memory somewhere rather than spitting
it straight out to the CF card (via suitable serial ==> parallel conversion of
course)?
If there's a guarantee that the CF write speed is fast enough, then it should
make the device simpler as hopefully something like a PIC micro has enough
on-board RAM without worrying about external memory at all. Keeps costs down
too if you're not mucking around with things like SIMM sockets.
I think when I did some quick calculations a while back that CF write speed
should be good enough - but it was close on marginal CF cards (it seems like
write speed can vary a lot between manufacturers) when handling floppy drives
with high data rates (and assuming a reasonable level of oversampling).
Read speed (device to computer) shouldn't be an issue, I think.
For something like a 500Mbps/300rpm drive and 8x oversampling, I don't think
there'd be a problem at all, assuming that a disk surface can be stored on the
card as a raw linear sequence of blocks (worrying about handling of fragmented
files or encoding lots of metadata might screw things up).
It'd be a fun project, at any rate...
cheers
Jules
--
there's a carp in the tub
there's a carp in the tub
so nobody's taken a bath
11:38 a.m.
New subject: Machine Independent Storage Idea...
On 6 Dec 2006 at 12:35, Jules Richardson wrote:
True, but then wouldn't you have to buffer the
entire written (computer to
device) and oversampled track of data in memory somewhere rather than spitting
it straight out to the CF card (via suitable serial ==> parallel conversion of
course)?
Oh, absolutely. I was thinking of a RAM track buffer and a counter
that spit out an index pulse every time the counter reset to zero.
It would be simple to also have a second counter to emit sector
pulses to simulate hard disks. Other than the buffer itself, I think
most of the logic (counters, serializer/deserializer, memory
arbitration, etc. could be implemented in a modest CPLD. I suppose
one could mitigate CF write latency with some double-buffering.
Cheers,
Chuck
11:19 a.m.
New subject: Machine Independent Storage Idea...
Rumor has it that Chuck Guzis may have mentioned these words:
To me, the whole point of "big storage" is to increase the number of
floppies available without increasing the cost.... if you have one gizmo
per drive, the cost increase for multiple dries goes up linearly. With the
emulated solution, you could (easily) have hundreds of floppies, without
the hundredfold increase in cost.
$100 for my CoCo IDE interface and $20 for the 256Meg might sound like a
lot until one figures I get 256 RSDOS floppies *and* a 170Meg NitrOS9 hard
drive all in one (very) small package. That's $0.50 per virtual floppy
drive & a relatively large NitrOS9 HD kicked in for good measure... ;-)
Anywho, that's just me, and I like me that way. (At least that's what the
voices say... ;-) )
Laterz,
Roger "Merch" Merchberger
--
Roger "Merch" Merchberger | Anarchy doesn't scale well. -- Me
zmerch at 30below.com. |
SysAdmin, Iceberg Computers
On 6 Dec 2006 at 11:21, Jules Richardson wrote:
RGBDos for the CoCo makes it quite a bit easier - it patches the onboard
RSDOS to allow up to 256 emulated floppies - there's a command that allows
some real floppies in the mix as well (say, drives 0 and 1 are real, then
2-255 are emulated on the CF card).
The logic associated with onboard buttons (and a display) adds a layer of
complexity to the device that would have to be thoroughly debugged...
sometimes software can be easier. ;-)
Darn interesting idea, though :) That implies
some intelligence
controlling
the gadget 'remotely' though, or at the
mickey-mouse end of the scale, a
rotary switch on top of the device to say which image to select. Perhaps a
version 2 thing?
Ideally, a couple of pushbuttons and a small LCD display, I'd think.
Floppy changing is a manual effort in the real world; no reason to do
it differently in the simulated world. Hmm, that
'feels' messy, somehow. Not sure why - but I think I'd prefer
one
> gadget per drive...
11:42 a.m.
New subject: Machine Independent Storage Idea...
On 6 Dec 2006 at 14:19, Roger Merchberger wrote:
RGBDos for the CoCo makes it quite a bit easier - it
patches the onboard
RSDOS to allow up to 256 emulated floppies - there's a command that allows
some real floppies in the mix as well (say, drives 0 and 1 are real, then
2-255 are emulated on the CF card).
That's nice if'n you know what platform you're aiming at. But a
general-purpose floppy emulator probably doesn't have that luxury. I
mean, what would you do for say, a Ioline fabric cutter or
Meistergram embroidery machine? (That's where you'll find a lot of
floppies still in use).
Cheers,
Chuck
12:23 p.m.
New subject: Machine Independent Storage Idea...
Rumor has it that Chuck Guzis may have mentioned these words:
On 6 Dec 2006 at 14:19, Roger Merchberger wrote:
Ah, OK. Now I get yer drift...
With all this talk of "multiple floppies means multiple gizmos" I was
internally translating that to "microcomputer systems" as I'd not really
seen many specialty machines that took multiple floppies like that... ;-)
You're looking for something that plugs straight into the floppy cable to
do it's "dirty work." If that's the case, *if* (yea, big if) the device
supports multiple drives on the same cable, one could monitor the
DriveSelect lines and automagically support multiple floppies from a single
device... [[ "swapping" floppies would still need some form of external
interface, methinks... ]]
Don't mind me - I lost my village long ago. ;-)
Laterz,
Roger "Merch" Merchberger
--
Roger "Merch" Merchberger | A new truth in advertising slogan
SysAdmin, Iceberg Computers | for MicroSoft: "We're not the oxy...
zmerch at 30below.com | ...in oxymoron!"
RGBDos for the CoCo makes it quite a bit easier -
it patches the onboard
RSDOS to allow up to 256 emulated floppies - there's a command that allows
some real floppies in the mix as well (say, drives 0 and 1 are real, then
2-255 are emulated on the CF card).
That's nice if'n you know what platform you're aiming at. But a
general-purpose floppy emulator probably doesn't have that luxury. I
mean, what would you do for say, a Ioline fabric cutter or
Meistergram embroidery machine? (That's where you'll find a lot of
floppies still in use).
12:42 p.m.
New subject: Machine Independent Storage Idea...
On 6 Dec 2006 at 15:23, Roger Merchberger wrote:
With all this talk of "multiple floppies means
multiple gizmos" I was
internally translating that to "microcomputer systems" as I'd not really
seen many specialty machines that took multiple floppies like that... ;-)
There are still boatloads of old CNC machinery out there in
productive use. Consider that the purchase price was often in 6
figures and that there's basically nothing wrong with the part that's
attached to the iron casting (i.e., the business end of the tool).
Tool vendors are most likely to encourage you to purchase a whole new
machine than upgrade parts of it.
You're looking for something that plugs straight
into the floppy cable to
do it's "dirty work." If that's the case, *if* (yea, big if) the device
supports multiple drives on the same cable, one could monitor the
DriveSelect lines and automagically support multiple floppies from a single
device... [[ "swapping" floppies would still need some form of external
interface, methinks... ]]
That's what I was thinking of, all right.
Cheers,
Chuck
2:24 p.m.
New subject: Machine Independent Storage Idea...
On 12/6/06, Chuck Guzis <cclist at sydex.com> wrote:
On 6 Dec 2006 at 10:46, Simon Fryer wrote:
A good start:
http://www.thesvd.com/SVD/
-- John.
I was thinking of doing the same sort of thing
but using compact flash
cards and building some electronics as the interface for the QIC tape
interface. Thinking about it is about as far as I got. From what I
understand, the electronics and software for interfacing Compact Flash
is a little easier than USB.
I've been toying with the idea of using a CF to provide emulation for
floppy drives. More complicated, as the thing has to look like a
3:35 p.m.
New subject: Machine Independent Storage Idea...
On 6 Dec 2006 at 14:24, John R. wrote:
A good start:
http://www.thesvd.com/SVD/
Thanks for the link!
An interesting idea. If my mind isn't playing tricks on me, there
also was a similar commercial device for the PeeCee sometime during
the 80's. Freakishly expensive, even for then.
The SVD widget appears to store decoded data (256KB SRAM), which
means it has to know something about the system it's working with. I
haven't looked at the firmware listing yet, so I'm fuzzy on details.
Is it better to store undecoded data streams (like a Catweasel) or
the decoded data? My inclination is to deal with raw track data
without attempting to interpret it. Requires quite a bit more memory
to store data, but has fewer limitations.
Cheers,
Chuck
4:15 p.m.
New subject: Machine Independent Storage Idea...
Chuck Guzis wrote:
Is it better to store undecoded data streams (like a
Catweasel) or
the decoded data? My inclination is to deal with raw track data
without attempting to interpret it. Requires quite a bit more memory
to store data, but has fewer limitations.
Certainly on the gadget I'd prefer to store raw, undecoded data - as you say,
encoding the data requires knowledge about the actual disk data being stored
(and potentially screws up various copy-protection schemes in the process).
Personally I'd see any data stored within the gadget as purely transient; the
'real' archival copy would be held somewhere on properly backed up storage and
I'd expect tools to exist there to either compress / decompress the 'raw'
copies, or to have some intelligence and allow conversion between decoded form
(suitable for analysing, manipulating, using with emulators etc.) and the raw
format used on the 'floppy emulator'.
Of course conversion requires knowledge of the data at a higher level - but
that's OK as a user can just install the relevant conversion tools on their
modern system according to what hardware they have (rather than the floppy
emulator having to have knowledge of every vintage floppy / filesystem format
on the planet)
cheers
Jules
--
there's a carp in the tub
there's a carp in the tub
so nobody's taken a bath
5:22 p.m.
New subject: Machine Independent Storage Idea...
On 12/6/06, Chuck Guzis <cclist at sydex.com> wrote:
On 6 Dec 2006 at 14:24, John R. wrote:
Yeah I guess one way is the "embedded systems" approach and the other
is a desktop approach. For archival purpose I think your idea is
better. For daily use (the SVD is a "peripheral" that travels between
machines) I think the decoded data is probably better.
On the desktop I expect you still wouldn't store the raw data, but
pipe to a filter that decodes it and store that.
-- John.
A good start:
http://www.thesvd.com/SVD/
Thanks for the link!
An interesting idea. If my mind isn't playing tricks on me, there
also was a similar commercial device for the PeeCee sometime during
the 80's. Freakishly expensive, even for then.
The SVD widget appears to store decoded data (256KB SRAM), which
means it has to know something about the system it's working with. I
haven't looked at the firmware listing yet, so I'm fuzzy on details.
Is it better to store undecoded data streams (like a Catweasel) or
the decoded data? My inclination is to deal with raw track data
without attempting to interpret it. Requires quite a bit more memory
to store data, but has fewer limitations.
5:36 p.m.
New subject: Machine Independent Storage Idea...
Is it better
to store undecoded data streams (like a Catweasel) or
the decoded data? My inclination is to deal with raw track data
without attempting to interpret it. Requires quite a bit more memory
to store data, but has fewer limitations.
Yeah I guess one way is the "embedded systems" approach and the other
is a desktop approach. For archival purpose I think your idea is
better. For daily use (the SVD is a "peripheral" that travels between
machines) I think the decoded data is probably better.
7 Dec
7 Dec
4:02 a.m.
New subject: Machine Independent Storage Idea...
Fred Cisin wrote:
Ah, we've been here before.
Several times :-)
Is it better to store undecoded data streams (like a
Catweasel) or
the decoded data? My inclination is to deal with raw track data
without attempting to interpret it. Requires quite a bit more memory
to store data, but has fewer limitations.
Yeah I guess one way is the
"embedded systems" approach and the other
is a desktop approach. For archival purpose I think your idea is
better. For daily use (the SVD is a "peripheral" that travels between
machines) I think the decoded data is probably better. For a "universal disk storage" device or
format, you need to have the
capability of three different levels
1) files
2) sectors
3) flux transition
+ software to convert both ways between all three
The latter point's the important bit, I suppose. If you merely want a
replacement for failing floppy disks, then surely flux transition storage /
playback is sufficient?
I'd imagine that such data probably compresses reasonably well (say for
archival purposes), too.
But (as you say) to actually *do* anything more constructive with the data at
the sector level (such as convert to other disk image formats) you need to be
able to decode the flux transitions based on knowledge of what low-level
encoding scheme was used for a particular image.
Similarly at the file level (such as viewing / copying files to other
filesystems) you need tools that can both decode the flux transitions based on
encoding scheme, and decode the filesystem based upon whatever system the
image is for.
Personally I'd be inclined to go for a device that just handles raw flux
transitions at the moment and worry about manipulation tools further down the
line; the priority right now is likely for something that can replace floppy
disks on vintage hardware, not for some bells and whistles tool that comes
with a big software suite for data manipulation.
Having said that, as a test does anyone have the tools available to record a
disk image at the flux transition level with suitable oversampling? It'd be
interesting to see how difficult it is in software to engineer that back to
sector-level data (filesystem-level we know isn't a problem!).
#3, flux transition ideally calls for the device to
have an SA800/SA400
interface, and would not require any additional software on the machine.
My gut feeling is that's the sensible way to start, with other interface types
being supported further down the line. Just keep in mind when designing the
hardware and firmware that an SA800/400 interface isn't the only type that we
may want to support in the future.
Of course if there are people with non-SA800/400 drives on board and with
suitable technical knowledge then there's nothing to stop them being supported
from day 1 - but I suspect that most people will be
more familiar with the
SAxxx drives.
Since conversion between USB interface and memory
cards is readily
available, either would do. But, howzbout RS232 and/or "centronics"
parallel?
I do think that a comms mechanism between device and more modern machine would
be nice, purely to save swapping 'local storage' (CF, USB stick, whatever)
around so much. However, I wouldn't think it vital for an initial release (or
any kind of proof of concept).
Note that I am hoping that a CF card (or USB stick) has fast enough data
transfer rates so that the gadget doesn't actually *need* a big pile of local
memory - it can just operate to/from the card/stick direct. In other words,
the card/stick isn't just a means of getting data to the device - it *is* the
device's local working storage too.
That's perhaps not in keeping with what others are thinking - but personally
I'd prefer the lower complexity / cost / parts count / development time if it
can be shown that there's no actual need for local memory (other than the
obvious few bytes of operating RAM - which with something like a PIC is quite
possibly all on-board anyway)
cheers
Jules
13 Dec
13 Dec
2:13 a.m.
New subject: Machine Independent Storage Idea...
Haven't been following this list for some time, but the few times I do look
at archived listings I find gems like these. Thanks for the link Chuck as
futurlec is the first place that I've found that carries a PCI digital I/O
card for only $40! (A lot easier option than my building one in my (almost
non-existent) spare time).
To put in my $0.02 worth about the machine independant storage idea, I'm
partial to using IDE disks as the medium as these are directly readable by
PC's via an external IDE firewire to PC interface and could also be used as
a disk drive on the old machine. I started the design of a parallel port
to IDE interface for the PDP-11 a few years ago but this was shelved when
my girlfriend told me that either the PDP-11/23 MINC system in my living
room went or she went. Still have the PDP-11 system, but she doesn't know
where I've stashed it.
Parallel port type interfaces are available on most old machines and if one
used a USB flash drive, one would have to do serial to parallel data
conversion as part of the interface, so why not go with a parallel data
interface the whole way? Flashdrives are smaller, but most of my PC's
don't have USB interfaces and I can quickly add an IDE disk drive to my old
systems for copying data. Another option is to use a serial port for
transfers and this is how I used to load software on my diskless PDP-11
systems. Can't get much simpler than that.
On 6 Dec 2006 at 10:46, Simon Fryer wrote:
I was thinking of doing the same sort of thing
but using compact flash
cards and building some electronics as the interface for the QIC tape
interface. Thinking about it is about as far as I got. From what I
understand, the electronics and software for interfacing Compact Flash
is a little easier than USB.
I've been toying with the idea of using a CF to provide emulation for
floppy drives. More complicated, as the thing has to look like a
floppy. Rather than record separated data, I'm inclined to record
flux transitions on the CF, so a disk would require something on the
order of 128KBytes per track (for a 300 RPM 500KHz drive). i.e.,
the drive would be data-encoding independent. Since one can get 4GB
CF cards, this shouldn't be a problem . Managing multiple images
from a single CF card will require some careful thought. Simulating
multiple drives with a single unit is another possibility.
There are still whole segments of the industrial market where
floppies represent the only available interface for older equipment.
For the interested, here's a RS232/485-to-CF card development board.
Note that it's pretty simple, using a PIC for most functions.
http://www.futurlec.com/CompBoard_Technical.shtml
I've been using the same outfit's USB-to-parallell I/O module and
find that it's easy to use (and plugs into a 32-pin DIP socket).
Cheers,
Chuck
6 Dec
6 Dec
12:36 p.m.
New subject: Machine Independent Storage Idea...
On 12/6/06, Warren Wolfe <wizard at voyager.net> wrote:
Hello, Fellow Cyber-Archaeologists,
I have an idea... (everybody duck)
One of the more common problems in the field of classic computers is
that of loading operating systems, programs, and data onto an old
machine. Could we not come up with a standard means of information
interchange? I would suggest the USB memory sticks one sees everywhere
now. I just bought a few of them at about four dollars each -- and each
one stores a gigabyte of information.
You need to add a USB host controller. This solves a more general
problem of getting access to modern USB devices. Flash drives,
keyboards, joysticks, mice, serial adapters, parallel adapters, even
VGA adapters.
The good news is, that this has already been done... see
http://microusb.org
If you poke around, they do have Forth code for accessing a USB flash key drive.
-- John.
7 Dec
7 Dec
1 a.m.
New subject: Machine Independent Storage Idea...
Comments, anyone? Has this been done? Would
people see it as an
abomination or boon? Who would be interested in (and capable of)
producing a USB interface card for "their" computers?
Well, there are common USB master chips you can find for less than $10.
Something like you are thinking can be made in three "layers" for easy
modification for each machine
- Layer one: Interacts with the USB pen drive.
- Layer two: intelligence between the USB pen drive (master controller)
and the LOGIC part of the media controller for the old puter
- Layer three: digital/analog circuits needed to interface the original
'puter media
I'll give an example:
- L1: Philips USB Master chip, controlled thru SPI
- L2: Atmel Atmega32 or Atmega 128 doing the bridge between the USB
Master and the computer itself
- L3: TTL/ECL/CMOS/etc interfacing to the microcomputer
Why three layers? Because in the level one, I can use compactflash, MMC,
SD, Memory stick or ferrite cores (:oD) as the medium. The Level two can be
reprogrammed at will, and level three can be a simple "cartridge" that can
be changed to make it usable for any old computer. And all modules can be
independently developed.
With proper help and a nice qty done, all this can be less than $50 to
build, and a fun to develop.
Comments, suggestions, rocks and apple (ueba!) pies!?
Alexandre Souza
www.tabajara-labs.com.br
15 Dec
15 Dec
12:06 p.m.
New subject: Machine Independent Storage Idea...
And thusly were the wise words spake by Warren Wolfe
Information could be stored on any modern machine, loaded onto a memory
stick in a jiffy, and used to load up a copy of vital data for any
In only 1/60th of a second?! That is pretty darn fast... 8-)
Cheers,
Bryan
6 Dec
6 Dec
3:57 p.m.
I still think
finding what appears to be a first edition of 'Automatic
Digital Computers' for 30p beats it...
A first edition? Without a doubt. At 30 quid it beats it -- beats
4 Dec
4 Dec
4:40 p.m.
for the Motorola 88K, and so on. I will admit to
ignoring content-free
Mac and Windows books, though.
Alas 'good' books have bevome much less common at library sales recently.
Perhaps I've already bought them all...
-tony
No, the lack of "good" books is because they are all now those
"content-free
Mac, Windows, and *UNIX* books" with very few exceptions. Thanks to the
popularity of Linux you really need to add Unix to the "content-free"
catagory. Though most O'Reilly books are still worth picking up, recently
I've gotten a lot of good use out of a couple previous version Web related
O'Reilly books I picked up earlier in the year at a Library sale (I just
happened to have taken a day of vacation and we ran into that sale on
accident).
Zane
10:07 p.m.
On Mon, 4 Dec 2006, Zane H. Healy wrote:
No, the lack of "good" books is because they
are all now those
"content-free Mac, Windows, and *UNIX* books" with very few exceptions.
Thanks to the popularity of Linux you really need to add Unix to the
"content-free" catagory. Though most O'Reilly books are still worth
picking up, recently I've gotten a lot of good use out of a couple
previous version Web related O'Reilly books I picked up earlier in the
year at a Library sale (I just happened to have taken a day of vacation
and we ran into that sale on accident).
I often look for O'Reilly books while at the booksales. Wiley and Addison
Wesley are also good to look for. I have a few local 'secret' sources for
O'Reilly and other books which I won't divulge, mainly because they will
sell me the overstock/remainder books for $1-3/each, so once or twice a
year, I get to load up a shopping cart with good books :)
-Toth
10:55 p.m.
----- Original Message -----
From: "Tothwolf" <tothwolf at concentric.net>
To: "General Discussion: On-Topic and Off-Topic Posts"
<cctalk at classiccmp.org>
Sent: Tuesday, December 05, 2006 1:07 AM
Subject: Re: library book sales
On Mon, 4 Dec 2006, Zane H. Healy wrote:
Do you see many older engineering books from the 1930's? I always found
those interesting. Haven't been to a library booksale for ages, they usually
just sell books donated to them don't they or do they sell things from their
shelves?
I collect military history books as well as older computer ones, just don't
have much space for more books at the moment.
No, the lack of "good" books is because
they are all now those
"content-free Mac, Windows, and *UNIX* books" with very few exceptions.
Thanks to the popularity of Linux you really need to add Unix to the
"content-free" catagory. Though most O'Reilly books are still worth
picking up, recently I've gotten a lot of good use out of a couple
previous version Web related O'Reilly books I picked up earlier in the
year at a Library sale (I just happened to have taken a day of vacation
and we ran into that sale on accident).
I often look for O'Reilly books while at the booksales. Wiley and Addison
Wesley are also good to look for. I have a few local 'secret' sources for
O'Reilly and other books which I won't divulge, mainly because they will
sell me the overstock/remainder books for $1-3/each, so once or twice a
year, I get to load up a shopping cart with good books :)
-Toth
5 Dec
5 Dec
9:24 a.m.
In article <011901c7183a$5a32d8c0$0b01a8c0 at game>,
"Teo Zenios" <teoz at neo.rr.com> writes:
Do you see many older engineering books from the
1930's? I always found
those interesting. Haven't been to a library booksale for ages, they usually
just sell books donated to them don't they or do they sell things from their
shelves?
Each library is probably different but at the UofU library, its both.
--
"The Direct3D Graphics Pipeline" -- DirectX 9 draft available for download
<http://www.xmission.com/~legalize/book/download/index.html>
Legalize Adulthood! <http://blogs.xmission.com/legalize/>
10:01 a.m.
Every year, our local library has a fundraiser ( "Friends of the
Library Sale") at the fundraiser. They sell not library stock, but
donated books by the truckload. I've picked up many an old software
manual or text that way. They also have a "software" section, but
I've never been too interested in that.
The selection of LP's on the other hand, has been great.
Cheers,
Chuck
1:04 p.m.
for the Motorola 88K, and so on. I will admit to
ignoring content-free
Mac and Windows books, though.
Alas 'good' books have bevome much less common at library sales recently.
Perhaps I've already bought them all...
-tony
No, the lack of "good" books is because they are all now those
"content-free
Mac, Windows, and *UNIX* books" with very few exceptions. Thanks to the popularity of Linux you really need to add Unix to the
"content-free"
catagory. Though most O'Reilly books are still worth picking up, recently
I would agree.
-tony
11:06 p.m.
Richard wrote:
Have y'all had much luck acquiring vintage
computer books/info via
library book sales?
Sometimes. There's an annual book sale here, with books from a number
of academic and public libraries collected together. I picked up a copy
of 101 BASIC Computer Games for 1.00UKP once, some Best of Creative
Computing, several books on programming languages, a few books on
microprocessors, computer architecture, and bit-slice design, some data
books, books by Marvin Minsky and others, and a couple of DEC handbooks,
amongst many others. Of course, it takes patience to sift through the
outdated Windows manuals, alternative "science", and all the other stuff
these sales have.
--
Pete Peter Turnbull
Network Manager
University of York
6583
days inactive
6594
days old
95 comments
35 participants
participants (35)
-
alexandre-listas＠e-secure.com.br -
ard＠p850ug1.demon.co.uk -
bfranchuk＠jetnet.ab.ca -
borisg＠unixg.ubc.ca -
bpope＠wordstock.com -
cclist＠sydex.com -
cisin＠xenosoft.com -
ethan.dicks＠gmail.com -
evan＠snarc.net -
feedle＠feedle.net -
fmc＠reanimators.org -
fryers＠gmail.com -
gmanuel＠gmconsulting.net -
gordon＠gjcp.net -
Hans.Franke＠siemens.com -
healyzh＠aracnet.com -
jclang＠notms.net -
jhoger＠gmail.com -
julesrichardsonuk＠yahoo.co.uk -
jwest＠classiccmp.org -
jwstephens＠msm.umr.edu -
legalize＠xmission.com -
mcguire＠neurotica.com -
pat＠computer-refuge.org -
pechter＠gmail.com -
pete＠dunnington.plus.com -
shoppa_classiccmp＠trailing-edge.com -
spc＠conman.org -
teoz＠neo.rr.com -
toresbe＠ifi.uio.no -
tothwolf＠concentric.net -
vax9000＠gmail.com -
vrs＠msn.com -
wizard＠voyager.net -
zmerch-cctalk＠30below.com