On Monday, December 08, 2014 8:12 PM Fred Cisin [mailto:cisin at xenosoft.com]
<snip>
>In MS-DOS/PC-DOS 2.00 and above, FDISK reported hard disk capacity in
honest binary Megabytes of 1,048,576
I looked for but could not find a screenshot of very early PCDOS FDISKs, the
later ones I've found all include the statement 1 MB = 1,048,576 bytes so by
that time Microsoft and IBM were indeed "honest" unlike Apple. FWIW, The
MS-DOS Encyclopedia (c) 1988 which covers thru DOS 3.3 shows the "Display
Partition Data" option as giving capacity in the number of cylinders, not a
particularly useful measurement but not misleading. FORMAT and CHKDSK all
report in decimal digits without commas. Would like to see a screenshot for
an early FDISK Option 1 using binary prefixes before I concede that
Microsoft/IBM DOS used but did not disclose binary prefixes before Apple
<snip>
>WHAT missing 490 KB??!?
>I recall Seagate referring to the ST225 as "20 Megabyte" (~1985?) Unlike
some other manufacturers, they rounded DOWN, not UP, AND they did not use
excessive "significant digits".
>(That also gave them a lot more slack than their less scrupulous
competitors to cover bad sectors) ((In apthecary measures, there are THREE
Scruples in every DRAM!))
The published Seagate specification for ST225 that I have states the
formatted capacity = 21.4 MB comprising exactly 41,820 x 512 byte sectors =
21.411.840 bytes = 21.4 MB
BTW the reason I picked the ST225 as an example rather than the ST412 is
that Seagate specified the formatted ST412 with 32 x 256 byte sectors per
track giving precisely 10.0 MB (10.027008 MB). IBM in the PC chose to go
to 17 x 512 Bytes sectors per track thereby increasing the formatted
capacity to 10.7 MB or 10.4 MiB. So a Seagate ST412 used with any of the
several IBM PC compatible controllers actually had a dram more than Seagate
specified, but in both cases more than 10.0; confusing perhaps but no basis
for complaining. But they soon changed to 512 byte sectors and that dram
went away. I really don't think Seagate was any more scrupulous than its
competition in specifying its drives, as near as I can tell they rounded
off, but even if they rounded down it was in the third or higher digit so we
are talking about a relatively small number when compared to the confusion
caused by binary prefixes.
Tom
Hey,
I'm looking for a Sun-1 keyboard (between myself and another local
collector we have 3 Sun-1's but only 2 Sun-1 keyboards).
Does anyone happen to know anyone who might have and extra one they'd be
willing to sell?
Thanks.
Earl
This is a long shot, and an oddball request, but we're all hoarders
here, right?
I'm looking for "PC Connection" catalogs from 1989 through 1992. If
you have any, please drop me a line. I'd be happy to pay a few bucks
for each one, plus mailing costs of course.
-Seth
> Date: Sun, 7 Dec 2014 19:26:23 -0500
> From: Matt Patoray <mspproductions at gmail.com>>
> To: "cctalk at classiccmp.org" <cctalk at classiccmp.org>
> Subject: Recaping a Macintosh Portable
> Message-ID: <A1A9E821-368F-422D-AAE8-B0BF138AFF7F at gmail.com>
> Content-Type: text/plain; charset=us-ascii
>
> Hello all,
>
> I have a Mac portable that refuses to even attempt to boot.
>
> I get random junk on the screen that is different on every power up, no drive activity and no sound.
>
> I am thinking the onboard surface mount electrolytics are due for replacement.
>
> I was able to read the values off of most of the caps but I was not able to read the follow caps. C4, C5, C15 and C24.
>
> Does anyone know what value those caps are?
>
> Thanks,
>
> Matt
>
> Sent from my iPhone
I believe that those four caps are all G4 1 50v - there is a close-up picture of C15 and C24 (on right) here: http://regmedia.co.uk/2010/11/08/port_unknown_large.jpg
> From: Johnny Billquist
> If the MMU is off, you can consider the PAR registers as just plain ram.
Ooooh, very clever! Wouldn't work on a /40, of course, but on a /23 with
22-bit addressing, they are full width! Thanks for the tip!
Noel
I'm a bit late into the fray for this subject but '5 pins' does ring a bell. A 'link adapter port' which '... provides an interface to the outside world ... to allow the user to control an external network of Transputers ... has 5 lines (and a ground/grounds). The 5 lines are
NotReset
NotAnalyse
NotError
LinkIn
LinkOut
Doug.
> I'm trying to fix a broken MSV11-L card (M8059-KF). The symptom is that
> it always reads back with the 020 bit set, but otherwise appears to be
> fine.
> ...
> two octal 3-state-output latches (E57 and E64, an 'LS373 and an 'S373
> respectively).
> ...
> the two octal latches are both TI Malaysia parts (date code 8231)
> ...
> it's the data latch that's bad.
So, I seem to have discovered a plague! I had another failed QBUS memory card,
an MSV11-D this time (M8044-DB). It has the exact identical symptom, except
with a different bit - 02000 this time, instead of 020.
So, since the designs are very similar, I thought 'maybe another bad S373'.
Well, they aren't quite as similar as it thought, but the culprit is indeed
apparently ... a bad S373! (Although I have to caveat that; I suppose it
could be the bus transceiver it's connected to.. but the output is always
high, which make it seem like the the driver in the 'S373 has failed.)
Anyway, this time it's a National Semiconductor part, and from a very
different date code (7947). What is it with S373's? Is this just pure chance,
that two from different makers, quite a while apart in time, were the
culprit? Or is there some issue with S373's? (I note that MSV11-D's are
apparently notorious for failing; perhaps because they use S373's a lot?)
I do have another MSV11-D with a similar fault (the 01 bit this time); once I
get it fault-isolated, I'll report if it, too, is caused by an S373 failure.
It may take a while to get it fault-isolated, though - so far, I've been
writing two- or three- instruction loops which have the picked bit set in all
the words of the program! (Because I'm too lazy to write a longer program that
sets up the memory mapping so the program can run out of 'good' memory, only
poking the 'bad' memory to test it... :-) Also, it's kind of an fun
challenge... :-)
Noel
>On Saturday, December 06, 2014 8:21 PM Chuck Guzis wrote
>On 12/06/2014 06:55 PM, Noel Chiappa wrote:
>> From: Jerome H. Fine
>> I would point out that one reason that memory may have stayed with 2 **
>> 30 is that memory is usually produced and sold in multiples of 2 ** 30
>> these days
>>
>> Main memory has pretty much _always_ been sold in blocks that were
>> exact powers of two, for obvious reasons (at least, powers of two of
>> the word size of the machine in question)...
>Let's see; IBM 1620--basic memory size=20,000 digits, increments of
>20,000 digits up to 60,000. IBM 705, 7080,...
>What is curious is the marketing numbers used for the memory size. 65K,
131K, etc. I believe IBM was guilty of this in their S/360 marketing
literature.
>The numbers sound bigger.
>--Chuck
Welcome to the debate over who is responsible for the confusion in the use
of binary versus decimal prefixes; it has been going on at Wikipedia since
2001, see:
https://en.wikipedia.org/wiki/Binary_prefix and
https://en.wikipedia.org/wiki/Timeline_of_binary_prefixes
Actually I think IBM was fairly rigorous in using decimal prefixes, K
meaning 1,000, with annotation K=1024 when appropriate as in the Amdahl
article on S/360 architecture. I doubt if it had anything to do with
appearance. More importantly I am pretty sure that into the 1980s (perhaps
later) in its product literature, product specs and operating system
utilities IBM used decimal digits with no prefixes at all.
IMO the mess really started with Apple's Macintosh which reported memory and
disk capacity using K in a binary sense without any qualification. I can't
prove a negative, but I think no OS prior to the Mac OS used any prefixes at
all; they simply displayed or printed a decimal number to however many
digits necessary, sometimes without commas. It will be interesting to see
what this group recalls
If u think about it, mixing decimal digits with binary prefixes makes little
sense and probably has caused all sorts of problems and confusions such as
the infamous 1.44 MB FD. I've always wondered why the programmer at Apple
didn't use decimal prefixes and avoid all this nonsense. After all there
isn't a lot of difference in coding between a binary shift followed by a
decimal conversion as Apple did it and a decimal conversion followed by a
decimal shift.
Tom
It's Holiday Music Week on RetroBattlestations, where people submit videos of their old computers playing music! Play some music with your PDP on an AM radio, enter your favorite scores into Music Construction Set, or fire up a Christmas demo! You can choose any holiday music from the traditional or the not so traditional, but, in order to be eligible though, you have to submit a song that hasn't already been submitted.
There's prizes of vinyl stickers and reddit gold, but like most every challenge on RetroBattlestations, it's more about showing off your computers and that they still work. You can get more details here:
http://redd.it/2ogx2n
And for anyone that hasn't seen it before, here's a mashup of most of last year's entries playing Linus & Lucy.
http://youtu.be/aZOJQwVgRi4
--
Follow me on twitter: @FozzTexx
Check out my blog: http://insentricity.com
> From: Jerome H. Fine
> I would point out that one reason that memory may have stayed with 2 **
> 30 is that memory is usually produced and sold in multiples of 2 ** 30
> these days
Main memory has pretty much _always_ been sold in blocks that were exact
powers of two, for obvious reasons (at least, powers of two of the word size
of the machine in question)...
(Although occasionally, back when, one used to see things that were 1.5 times
a power of two, e.g. on a 16-bit machine, 12KB, 96KB, etc - physical and cost
constraints tended to produce those. I don't recall the last time I saw
something that wasn't a power of two - probably those 96KB jobs.)
With disk drives, on the other hand, one can get all sorts of arbitrary sizes,
produced by the number of cylinders, numbers of heads, etc, etc.
Noel