Kennedy 9800 near L.A. - Shipping help?

2017-09-27 Thread Anders Nelson via cctalk
Hi friends,

Would anyone near Santa Clarita, CA be able to assist in packaging a
Kennedy 9800 tape drive for shipment to NYC? The auction ends tomorrow but
I'm reaching out to the seller to see what his/her flexibility is on the
collection date. Looks like the unit is 50lbs.

--
Anders Nelson

+1 (517) 775-6129

www.erogear.com


Re: Strange grounding problem

2017-09-27 Thread dwight via cctalk
Were does the powerup signal go?

Dwight



From: cctalk  on behalf of Adrian Graham via 
cctalk 
Sent: Wednesday, September 27, 2017 5:23:45 PM
To: General Discussion: On-Topic and Off-Topic Posts
Subject: Strange grounding problem

Hi folks,

This is another Grundy Newbrain problem on a different machine that is probably 
easily explained by someone who understands current flow. This machine has two 
startup circuits that are simply a resistor and 10uF capacitor each, both 
feeding a Hex Schmitt Trigger (CD401068CM). When the caps have charged up 
sufficiently they activate both PWRUP and RESET signals one after the other 
thanks to the 220K and 560K resistors.

Schematic for the circuits is here - 
http://www.binarydinosaurs.co.uk/newbrainPowerupCircuits.png 
 - top circuit is 
PWRUP and the bottom one is RESET that goes straight to the Z80.

Only in this machine it doesn’t unless I have 3 sampling probes and a GND probe 
on my USB-powered logic analyser attached to pins 3-5 of the CD401068CM and the 
GND pin of any nearby chip. Less than 3 sampling probes and it won’t start so 
those probes must be facilitating current flow to GND?

Cheers!

PS Brent, I got the other Newbrain going by replacing the 74LS166 shift 
register, the one that provides the SOVSR signal. All good now!

—
Adrian/Witchy
Binary Dinosaurs - Celebrating Computing History from 1972 onwards



Re: Strange grounding problem

2017-09-27 Thread Jerry Weiss via cctalk
> On Sep 27, 2017, at 8:14 PM, Charles Dickman via cctalk 
>  wrote:
> 
> On Wed, Sep 27, 2017 at 8:23 PM, Adrian Graham via cctalk
>  wrote:
> 
>> Schematic for the circuits is here - 
>> http://www.binarydinosaurs.co.uk/newbrainPowerupCircuits.png 
>>  - top circuit 
>> is PWRUP and the bottom one is RESET that goes straight to the Z80.
>> 
> 
> CD4000 logic can't handle inputs pulled above the power pin or below
> the ground pin without the possibility of malfunctioning or even
> complete failure. Google for "CD4000 parasitic SCR" or "CMOS
> latch-up". When power is cycled rapidly, the caps will still have
> charge which could cause the latch-up. I did some industrial control
> designs with CD4000 and used similar timing circuits, but always
> included diodes to prevent inputs from being driven too high or too
> low. I would have put diodes across both of the resistors.
> 
> Adding your probes may change the currents inside the chip that change
> the latch-up behavior. Of course it also only makes sense if the power
> is cycled quickly for some value of quickly. Others may have an
> explanation, but that was my first thought from looking at the
> schematic.
> 
> -chuck

The capacitors may have become leaky, and start to as resistors in the 100K 
ohms range.

If so, the circuit now contains a voltage divider and and not meet the 
threshold needed for 
the logic gate to switch.  The probes have their own resistive component and 
thus
shift the other side of the divider, which puts the signal back into a 
functional range for
the Schmitt Trigger.

Jerry





Re: DEC manual typeface

2017-09-27 Thread Toby Thain via cctalk
On 2017-09-27 9:33 PM, Charles Dickman via cctalk wrote:
> For those interested in all things DEC, I found a typeface that is
> very close to the typeface used in the old 60's and very early 70's
> manuals. Google for "Function Pro Book font".

If you mean:
https://www.fontspring.com/fonts/fontsite/function-pro
then this is basically a ripoff of Futura.

Can you show me a scan of the manual page, or cite a manual I can look
up or might have?

--Toby

> 
> The only difference I saw was in the upper case I. Sometimes DEC used
> an I that had serifs and sometimes they didn't.  Function Pro's I does
> not have serifs.
> 
> 
> -chuck
> 



DEC manual typeface

2017-09-27 Thread Charles Dickman via cctalk
For those interested in all things DEC, I found a typeface that is
very close to the typeface used in the old 60's and very early 70's
manuals. Google for "Function Pro Book font".

The only difference I saw was in the upper case I. Sometimes DEC used
an I that had serifs and sometimes they didn't.  Function Pro's I does
not have serifs.


-chuck


Re: Strange grounding problem

2017-09-27 Thread Charles Dickman via cctalk
On Wed, Sep 27, 2017 at 8:23 PM, Adrian Graham via cctalk
 wrote:

> Schematic for the circuits is here - 
> http://www.binarydinosaurs.co.uk/newbrainPowerupCircuits.png 
>  - top circuit 
> is PWRUP and the bottom one is RESET that goes straight to the Z80.
>

CD4000 logic can't handle inputs pulled above the power pin or below
the ground pin without the possibility of malfunctioning or even
complete failure. Google for "CD4000 parasitic SCR" or "CMOS
latch-up". When power is cycled rapidly, the caps will still have
charge which could cause the latch-up. I did some industrial control
designs with CD4000 and used similar timing circuits, but always
included diodes to prevent inputs from being driven too high or too
low. I would have put diodes across both of the resistors.

Adding your probes may change the currents inside the chip that change
the latch-up behavior. Of course it also only makes sense if the power
is cycled quickly for some value of quickly. Others may have an
explanation, but that was my first thought from looking at the
schematic.

-chuck


Strange grounding problem

2017-09-27 Thread Adrian Graham via cctalk
Hi folks,

This is another Grundy Newbrain problem on a different machine that is probably 
easily explained by someone who understands current flow. This machine has two 
startup circuits that are simply a resistor and 10uF capacitor each, both 
feeding a Hex Schmitt Trigger (CD401068CM). When the caps have charged up 
sufficiently they activate both PWRUP and RESET signals one after the other 
thanks to the 220K and 560K resistors.

Schematic for the circuits is here - 
http://www.binarydinosaurs.co.uk/newbrainPowerupCircuits.png 
 - top circuit is 
PWRUP and the bottom one is RESET that goes straight to the Z80.

Only in this machine it doesn’t unless I have 3 sampling probes and a GND probe 
on my USB-powered logic analyser attached to pins 3-5 of the CD401068CM and the 
GND pin of any nearby chip. Less than 3 sampling probes and it won’t start so 
those probes must be facilitating current flow to GND?

Cheers!

PS Brent, I got the other Newbrain going by replacing the 74LS166 shift 
register, the one that provides the SOVSR signal. All good now!

—
Adrian/Witchy
Binary Dinosaurs - Celebrating Computing History from 1972 onwards



Re: M8195 SLU died while in use

2017-09-27 Thread Aaron Jackson via cctalk
Hi Noel,

Thanks for the very useful information. I'll do some investigation this
weekend and keep an eye out for a spare SLU. Being in the UK makes it
quite difficult to find these things.

Thanks again,

Aaron.


Noel Chiappa via cctalk writes:

> > From: Aaron Jackson
>
> > a PDP-11/73, M8192 CPU, two M8067 RAM, M7195 ... While playing in ODT,
> > the console completely stopped responding.
> > ...
> > The CPU shows 1000, which I believe is fine, and means it's in ODT. The
> > SLU card has . I've had a Google and I believe this means it can't
> > communicate with the CPU.
> > ...
> > Does anyone have any ideas? It was working and then it wasn't :(
>
> Hmm. Well, it's possible something just died. Dead boards are not un-common,
> I've found, but to have one die while it's being worked with is a bit of bad
> luck... Alas, I can imagine a zillion failures that could produce this symptom
> (from EIA driver chip, down to a bus transceiver chip on the CPU).
>
>
> OK, to start with, those LED values. When you say 1000 on the CPU, there's
> some ambiguity as to which direction you're reading them; so, which LED is
> on? From above the board (component side up), with the contact fingers at the
> bottom, the one on the left, or the one on the right? I'm going to assume the
> one on the right, which does indeed mean the CPU is claiming it's in ODT.
>
> While we're on the CPU, is it set to halt on power-up (power up mode 1) or
> try and start the ROM (power up mode 2)? I always set mine to halt, on the
> grounds that it's easy to start the ROM.
>
> I'm not familiar with the MXV11-B (M7195), and I couldn't turn up a manual
> online, but likely those LEDs are set by software (I can't imagine how one
> would turn on a "can't communicate with the CPU" bit in hardware ... unless
> it's a flop that's set on power-on, and cleared by the first bus cycle to the
> card)...
>
>
> Anyway, there are two approaches to solving this problem. 
>
> So, one option (depending on your budget) is to buy spare boards so you can
> board-swap to localize the problem to one board.
>
> I would recommend getting the spare boards anyway since I would recommend
> always having a spare minimal set of boards (CPU, serial line) etc. Without a
> 'working' machine - at least to the point of running ODT - it's hard to do
> much poking into problems without a lot of pain (i.e. hard work with things
> like a logic analyzer or oscilloscope). Being able to board-swap to at least
> localize the problem to one board is a big help.
>
> So, start with another serial card (QBUS serial cards are pretty easy to find
> on eBay, and not too expensive), and swap out the MXV11-B, and hope the
> serial card you bought works. There are a ton of boards that can do this -
> M7940, M8017, M8028, M8043 (the first 3 single line, the last is a quad, but
> uses the same connector as the MXV11-B, unlike the first 3). (If that option
> is out, I can lend you a known working serial card.)
>
> If it's not the serial card, the next thing to buy is a spare CPU; -11/23's
> are not too expensive, you don't need a /73 to debug hardware issues.
>
>
> The other approach is to debug the hardware. You mention an oscilloscope; do
> you also have a logic analyzer? Some things (e.g. checking that when you type
> a character, the serial interface presents it to the CPU) are going to be hard
> with only an oscilloscope - although I suppose one could program one's
> computer to send a constant stream of characters (probably DEL) to the -11.
>
> I couldn't find a set of MXV11-B prints online - does anyone know of a set?
> Without that, if the problem is in the MXV11-B, finding it's going to be
> painful.
>
> Anyway, you could check on the QBUS to make sure the processor is actually
> cycling, trying to read the console input status register, waiting for the
> 'input character ready' bit to go on. So look at BSYNC and BRPLY, to see if
> they are hopping up and down.
>
>
> Oh, I guess there's a third option: send the CPU and MXV11-B to someone who
> has a working system, so they can board-swap and check them out. (I've done
> this for people...)
>
>
> Bottom line, though: if the fault is in the MXV11-B, unless we can find some
> prints for it, you're probably stuck with buying at least a replacement
> console serial card.
>
>   Noel


-- 
Aaron Jackson
PhD Student, Computer Vision Laboratory, Uni of Nottingham
http://aaronsplace.co.uk


RE: Joe Rigdon

2017-09-27 Thread Jay West via cctalk

I keep his pages online as he had a pretty huge amount of info and pictures.

On more than one occasion over the years I have tried to locate him, and posted 
on the list about it. There have been no positive responses

J




Joe Rigdon

2017-09-27 Thread Michael Thompson via cctalk
I see that Joe Rigdon's old WWW pages are still on
http://www.classiccmp.org/hp/joespage.htm, but the email address doesn't
work.

The RICM is interested in the ECRM Omnibus boards that he had.
Anyone have current contact information?

-- 
Michael Thompson


Re: formatting MFM drives on a IBM PC

2017-09-27 Thread allison via cctalk



On 9/27/17 10:59 AM, Ethan via cctalk wrote:
IIRC, the first time I had problems with the low level format was 
with one

of the early IDE controllers and a 230MB Maxtor. Crapped out the entire
firmware, was never able to get it to admit who it was again. Seemed to
work okay with earlier MFM/RLL 40 MB and 80 MB Conner drives (I 
think, it's

been a while).


AFAIK a lot of IDE drives store part of the firmware on the spinning 
disk in a special section of the disk. Not sure if those early models 
used that trick to cut costs or not?




Not so for MFM.  All and IDE drive is in essence is a MFM with a WD1003 
controller as IDE is the buss

level view of the 1003 (or the later 1005 RLL encoded version).

The idea of IDE, as my understanding, is the controller that existed 
as an ISA card was moved onto the actual drive, and then what became 
the controller was mostly just extending the ISA bus over to the drive.



Correct.
My first hard drive was a SCSI-1 ?Fuji? on a Seagate 8-bit ISA card. 
Families Tandy 1000sx. I remember in the end playing with low level 
formatting tools and interleves, then the drive dying at the same 
time. I correlated the two together then, but looking back I think the 
issue was drive motor/bearings/stuck rotation of platters.


My first drive was a ST506 on S100 using the Teltek controller (CP/M) I 
was an early adopter and
5MB felt like a a lot of space when floppies were maybe 720K (2side 
double density 80track) back
in 1980.  After that it included over time St506, st412(RD50), RD51(also 
sold as MFM for PCs 31mb) then SA225(RD31), sa250 (RD32), Quantum D540 
(RD52) and a long list of others including most of the drives to 150mb.  
Those larger than 30mb woere used in my QBUS PDP11's and MicroVAX 
systems.  Least that was
true up to about 93ish when I started using PCs (XT class running 
dos/WIN3.11).


DEC for MFM RDxx disks had different formats depending on system those 
being Rainbow, PRO, QBUS(RQDX1,2 or RQDX3) which was PDP11 and MicroVAX( 
MV2000 and QBUS).  That's for Low level format.  FOr High level
format for the different file systems were handled by the OS.  While 
they were sometimes called format it was really writing a bland initial 
filesstem on formatted media.


IDE disks format usually meant high level only.  SCSI could be either 
depnding on the specific controller and media.


PCs forced the issue with multiple controlled not all the same  For 
example the ST225 could be formatted

with WD1003(plain MFM) or WD1005 (RLL encoded).  There were many versions.

In the CP/M s100 days you had teltek, Konan and many others all 
different.  Media must be formatted for the controller and there was 
code supplied for that. Those were the bus installed controller as 
Xyebc, WD, Adaptec also had host controllers as well as SASI/SCSI 
interfaced versions to drive MFM drives.


The whole of that is 5.25 disks and the later 3.5inch IDE class 
devices.  Other formats were well, different.


Allison


Re: formatting MFM drives on a IBM PC

2017-09-27 Thread allison via cctalk



On 9/27/17 12:04 PM, Liam Proven via cctalk wrote:

On 26 September 2017 at 21:33, Phil Blundell via cctalk
 wrote:

Low-level formatting (which, at the time, was just called "formatting")
used to be quite a routine operation on ST-506 MFM and RLL hard disks.
They usually came completely blank from the factory and you had to
format them according to whatever sector layout and interleave your
particular controller wanted before they were usable.  Once the drive
was formatted you then had to run a separate process to lay out an
actual filesystem.

All true, although by the time I entered the industry in 1988 or so,
it was normal for drives to ship low-level formatted, at least.

I remember that Netware came with a special tool called COMPSURF to do
a "comprehensive surface analysis".

There's still a passing mention of this here:
https://support.novell.com/subscriptions/readmes/114.html


Everyone forgets Norton Utilities...


Re: ICL 1501 terminal available in Sweden.

2017-09-27 Thread Stefan Skoglund via cctalk
ons 2017-09-27 klockan 19:54 +0200 skrev Mattis Lind via cctalk: 
> 2017-09-27 17:33 GMT+02:00 Stefan Skoglund via cctalk  >:
> 
> > ons 2017-09-27 klockan 16:03 +0200 skrev Mattis Lind via cctalk:
> > > >> In a closed Facebook group in Sweden there is someone that want to
> > sell a
> > > >>> number of ICL1501 terminals.
> > > >>>
> > > >>>
> > > >> There doesn't seem to be any information about ICL terminals at the
> > > >> Terminals wiki http://terminals-wiki.org/
> > > >>
> > > >> But some information is found
> > > >> http://computermuseum.informatik.uni-stuttgart.de/dev_en/
> > > >> icl1501/icl1501.html
> > > >>
> > > >> looks like these are a bit more than terminals
> > > >>
> > > >>
> > > > Indeed, the 1501s are real computers, built by a firm called "Cogar".
> > At
> > > > the end of our page about the ICL1501 is a link to the technical
> > > > information: schematics and programmers manual.
> > > >
> > >
> > > Apparently the terminals this guy is selling was connected to a Diablo 30
> > > type drive. He just uploaded a couple of pictures of the drive as well.
> > >
> > > Quite an interesting little system.
> >
> > Pictures (or did he only post inside the FB:group) ?
> >
> 
> https://scontent-arn2-1.xx.fbcdn.net/v/t1.0-9/22007786_10156051698148570_5172629553901310482_n.jpg?oh=702928bcc49671c32995f82c6dbb5066=5A4CAB74
> 
> https://scontent-arn2-1.xx.fbcdn.net/v/t1.0-9/21766522_10156051700663570_6972929011325858586_n.jpg?oh=b10c6c1d3f324f18cd627e359f10ef18=5A43AE91
> 
> I think the pictures  should be visible outside Facebook. Otherwise I have
> to put them on some other hosting service.
> 
> Looks like the drive is in decent condition.
> 
> /Mattis

They are OK.



Re: formatting MFM drives on a IBM PC

2017-09-27 Thread Chuck Guzis via cctalk
I'm suffering from TL;DR disease this morning, so I didn't have the
inclination to follow all of the links cited in the discussion, so my
apology is presented in advance.

However, there *was* another way to handle large drives in earlier DOS
before 4.0.  It was far from satisfactory, because it broke a lot of
utilities.

The basic scheme was to insert a "layer" in-between the PC Int 13H
services and DOS and block I/O transactions up into larger virtual
sectors.There was nothing sacred about a hard drive sector being 512
bytes; indeed, the PC98 versions of MS-DOS use 1024 byte sectors on
their floppies.

So, for example, if you were limited by 16-bit relative sector addresses
to 33MB (calling 1MB = 1,000,000 bytes), you could block 2 512-byte
physical sectors up into a single "virtual" sector of 1024 bytes and
extend the reach of DOS to 65 MB.  Make it larger, say, 2048 bytes and
you get 134MB.

As I said, this came at a cost of memory (you need buffers for these
bigger sectors) and a lot of utilities that assumed a 512 byte sector,
but as a desperate dodge, it worked surprisingly well.  There was also a
slight performance penalty, as most MFM hard drives there used 17
sectors per track--or 25 if they were RLL, so there was the awkward
problem of a write possibly crossing a cylinder boundary.

--Chuck


Re: formatting MFM drives on a IBM PC

2017-09-27 Thread Fred Cisin via cctalk

On Wed, 27 Sep 2017, Liam Proven wrote:

... as usual, lots of high-quality info. Can't disagree with any of it.


thanks.  many errors, due to inadequately refreshed dynamic wet-ware RAM
Chuck will probably notice most of them.


There were several additional programs, that were sometimes needed, such as
if you wanted to have a partition larger than 32MB on DOS 3.30 or earlier
(MS-DOS 3.31 was first to accept larger partitions).

Until this bit!
Vanilla PC-DOS and MS-DOS didn't get past 3.3, TTBOMK.


My turn to nit-pick.

There never was ANY version 3.3 !
And certainly no three point three!
You mean version 3 point THIRTY!  (3.30)

Internally, starting with 2.00, the major version was stored as an 
integer, and the minor version was a two digit decimal number.
INT21h Fn30h (place 30h in AH and INT21h) returned the major version in 
AL, and the minor version in AH.

3.30 gave an AX of 1E03 ("three point thirty")
3.31 gave an AX of 1F03 ("three point thirty-one")
2.10 gave an AX of 0A02 ("two point ten")
2.11 gave an AX of 0B02 ("two point eleven")
"three point three" would be AX of 0303, and would be 3.03

A program to replicate the functionality of the VER command in a
program was an assignment that I used to give my Assembly Languuge 
class.

In C, formatting would be
printf("$d.%02d",_AL,_AH);
to avoid 4.01 coming out as 4.1
My nitpick might only be important if you have 6.01 and 6.10, etc.



The first DOS I saw that could handle >32MB partitions was Compaq DOS
3.31 -- they tweaked it slightly.


How about ZENITH?
I thought that I had seen other 3.31s, but I never used them, so I'm not 
sure.
Were the tweaks done BY Compaq, or by Compaq and Microsoft, in preparation 
for support in later versions of DOS?
3.31 was only available as OEM versions of MS-DOS.  There was no PC-DOS 
3.31.  Some OEMs had enhancements.


2.11 (0B02) was another version that was ONLY OEMs, often with some very 
strange changes/enhancements, such as support for odd drives such as 3.5" 
(not supported mainstream until 3.20 (1403)), MODE for switching between 
internal/external video and 8 or 16 line internal displays (Gavilan 2.11), 
etc.
BTW, Gavilan started (NCC 1983) with 3.0" drive, then single sided 3.5" 
(SA300), and about the time that Gavilan destroyed itself (1985), they had 
double sided 3.5" (SA350).  Gavilan 3.5" double sided disk formats were 
different from PC-DOS 3.5" formats until Gavilan 2.11K (unofficially 
released after Gavilan was GONE.)  In converting a Gavilan to 720K, to 
get a clean look, transfer the bezel from a Gavilan SA300 to a stock SA350.
Gavilan was one of MANY early laptops, a full year later than Grid 
Compass, but Gavilan appears likely to have been the first to use the term 
"laptop".



PC-DOS 4.00 (0004) was "buggy".  "The new DOS is so buggy that Norton 
Utilities won't work!"  How many of those "bugs" were simply CHANGES that 
Norton fUtilities and the like were not prepared for?

PC-DOS 4.01 was supposedly "fixed" (think in a veterinary context?).
I had a copy of PC-DOS 4.01 that returned 0004!  "ALL bugs fixed?"

Prior to 5.00 (0005), MS-DOS was "only for sale with a computer, or as 
upgrade to such".  In THEORY, it was not available for retail sale, but 
there was a GIANT grey market, with no difficulty at all finding and 
buying copies.  There was NO apparent effort by Microsoft to rein in the 
gray market.


5.00 was the first version with a RETAIL channel.  It was ten years after 
IBM and Microsoft signed - their contract obviously permitted Microsoft 
selling to OEMs, but was there a clause in their contract that 
forbade RETAIL sales [for ten years]?


BTW, "PC-DOS" was "descriptive" ("Personal Computer Disk Operating 
System"), and was NOT a trademark.  I personally confirmed that in the 
stacks of the Patent nadTrademark Office in Virginia in 1987.

At least until after DRI brought "Concurrent PC-DOS" to market.
IBM was not amused.
http://online.wsj.com/public/resources/documents/googleglassuspto.pdf
"MS-DOS", however WAS trademarked.


SETVER (starting with 5.00) was even more fun.
Prior to that, one of the early assignments that I gave my Assembly 
Language class was to modify EXE2BIN (our copy which came with PC-DOS 
2.00 and the IBM release of MASM 1.0, was locked to DOS 2.00) to be DOS 
version tolerant.




That employer only sold IBM and Compaq kit, and being that the UK was
poorer back then, mostly I only saw those and other cheaper clone PCs.
We didn't get to see some of the other States-side premium ranges, or
*I* didn't, until later, in the early-to-mid 1990s. So other vendors
may have had larger-disk-partition hacks, too. I recall reading of
some -- Wikipedia claims Commodore, Leading Edge, AST, NEC, AT,
Tandy, Sperry & Unisys all fiddled with FAT formats.


There was another, even more bizarre way to handle large drives, even 
larger than 512MB!
In DOS 3.10 (0A03), they introduced the [undocumented?] "network 
redirector".  Remember MSCDEX?
3.10 had the 32MB limit. 

Re: ICL 1501 terminal available in Sweden.

2017-09-27 Thread Mattis Lind via cctalk
2017-09-27 17:33 GMT+02:00 Stefan Skoglund via cctalk :

> ons 2017-09-27 klockan 16:03 +0200 skrev Mattis Lind via cctalk:
> > >> In a closed Facebook group in Sweden there is someone that want to
> sell a
> > >>> number of ICL1501 terminals.
> > >>>
> > >>>
> > >> There doesn't seem to be any information about ICL terminals at the
> > >> Terminals wiki http://terminals-wiki.org/
> > >>
> > >> But some information is found
> > >> http://computermuseum.informatik.uni-stuttgart.de/dev_en/
> > >> icl1501/icl1501.html
> > >>
> > >> looks like these are a bit more than terminals
> > >>
> > >>
> > > Indeed, the 1501s are real computers, built by a firm called "Cogar".
> At
> > > the end of our page about the ICL1501 is a link to the technical
> > > information: schematics and programmers manual.
> > >
> >
> > Apparently the terminals this guy is selling was connected to a Diablo 30
> > type drive. He just uploaded a couple of pictures of the drive as well.
> >
> > Quite an interesting little system.
>
> Pictures (or did he only post inside the FB:group) ?
>

https://scontent-arn2-1.xx.fbcdn.net/v/t1.0-9/22007786_10156051698148570_5172629553901310482_n.jpg?oh=702928bcc49671c32995f82c6dbb5066=5A4CAB74

https://scontent-arn2-1.xx.fbcdn.net/v/t1.0-9/21766522_10156051700663570_6972929011325858586_n.jpg?oh=b10c6c1d3f324f18cd627e359f10ef18=5A43AE91

I think the pictures  should be visible outside Facebook. Otherwise I have
to put them on some other hosting service.

Looks like the drive is in decent condition.

/Mattis


Re: formatting MFM drives on a IBM PC

2017-09-27 Thread Liam Proven via cctalk
On 26 September 2017 at 21:33, Phil Blundell via cctalk
 wrote:
>
> Low-level formatting (which, at the time, was just called "formatting")
> used to be quite a routine operation on ST-506 MFM and RLL hard disks.
> They usually came completely blank from the factory and you had to
> format them according to whatever sector layout and interleave your
> particular controller wanted before they were usable.  Once the drive
> was formatted you then had to run a separate process to lay out an
> actual filesystem.

All true, although by the time I entered the industry in 1988 or so,
it was normal for drives to ship low-level formatted, at least.

I remember that Netware came with a special tool called COMPSURF to do
a "comprehensive surface analysis".

There's still a passing mention of this here:
https://support.novell.com/subscriptions/readmes/114.html

-- 
Liam Proven • Profile: https://about.me/liamproven
Email: lpro...@cix.co.uk • Google Mail/Talk/Plus: lpro...@gmail.com
Twitter/Facebook/Flickr: lproven • Skype/LinkedIn/AIM/Yahoo: liamproven
UK: +44 7939-087884 • ČR/WhatsApp/Telegram/Signal: +420 702 829 053


Re: formatting MFM drives on a IBM PC

2017-09-27 Thread Liam Proven via cctalk
On 26 September 2017 at 20:53, Fred Cisin via cctalk
 wrote:

... as usual, lots of high-quality info. Can't disagree with any of it.

> There were several additional programs, that were sometimes needed, such as
> if you wanted to have a partition larger than 32MB on DOS 3.30 or earlier
> (MS-DOS 3.31 was first to accept larger partitions).

Until this bit!

Vanilla PC-DOS and MS-DOS didn't get past 3.3, TTBOMK.

The first DOS I saw that could handle >32MB partitions was Compaq DOS
3.31 -- they tweaked it slightly.

It didn't help me inasmuch as at the time, the main use for such
"huge" disks was in fileservers -- and my company used 3Com 3+Share, a
weird MS-DOS based fileserver with internal multitasking.

It was _very_ picky about what additional DOS utilities it would work with.

For larger hard disks, the only supported tool was something from
Golden Bow Systems, later known for their Vopt disk-defragger.

I tried with Compaq DOS 3.31 -- it died messily, as I recall.

I also tried a special memory managed for 80286 PS/2s which could turn
the 384 kB of XMS into EMS, which 3+Share could use for a disk cache.

Yeah, that crashed a customer's live fileserver, corrupting thousands
of files. And I did it, so I had to restore all the files they'd
edited, one by one, from backups. On floppy diskette. And for the
hundred-odd they'd edited since the last backup, undelete them, one by
one.

Days of work. It was the only disciplinary measure I got, as it was
unpaid for the client and immensely tedious (and humiliating) for me.

One customer had a Model 80 (a 386) machine with a 330MB hard disk,
but  wouldn't spring for Golden Bow's disk manager. It had drives C:,
D:, E:, F:, G:, H:, I:, J:, K: and L:.

Muggins here had to arrange a pattern of disk shares to try and
usefully employ all that space. I did manual hashing of user's home
directories for  some of it.

So, anyway, yes, circa 1989, DOS supported disk partition sizes were a
subject of intense professional interest for me, and really,
seriously, the only 3.x era MS-DOS family OS I ever saw with >32MB
support was Compaq's.

It ran fine on any machine. I used it on several. I may still have a
copy somewhere.

That employer only sold IBM and Compaq kit, and being that the UK was
poorer back then, mostly I only saw those and other cheaper clone PCs.
We didn't get to see some of the other States-side premium ranges, or
*I* didn't, until later, in the early-to-mid 1990s. So other vendors
may have had larger-disk-partition hacks, too. I recall reading of
some -- Wikipedia claims Commodore, Leading Edge, AST, NEC, AT,
Tandy, Sperry & Unisys all fiddled with FAT formats.


Golden Bow's _didn't_ work with MS-DOS 4 and later, which had built-in
support for larger partitions. Compaq DOS did -- I think MS, or rather
IBM, picked up Compaq's schema and used it. Later it was named FAT16B
or BigDOS.

https://en.wikipedia.org/wiki/File_Allocation_Table#Logical_sectored_FAT


> And, you needed an overlay, such as ONTRACK, to use a drive larger than
> 504MB.
> Also, if you had a drive whose geometry was too incompatible with your
> computer - not all CMOS/SETUPs had a user-defined drive parameters option.

Oh my yes -- that was a whole 'nother world of pain.

Even in the late 1990s, I was occasionally dealing with this. I
incrementally expanded a friend's cheapo Dell Pentium-133 PC for him.
64 MB RAM, IDT WinChip CPU upgrade, bigger hard disk.

The original drive was a 120MB or so. The BIOS couldn't handle drives
over 512MB. (No Logical Block Addressing.) So I installed OnTrack Disk
Manager, moved his Win95B install to the new drive, converted it to
FAT32 with PartitionMagic, hooked up his old drive as a slave, made it
drive D:, and secured it in place with duct tape and cable ties.

Years later he handed it on to his dad. Later, his dad asked a friend
to look at the machine for him. Word was passed back to dad, to my
mate, and to me:

"Blimey. Whoever your son's mate was who upgraded this PC for him, he
did an amazing job. I've never seen such an old PC tricked out as much
as this, and it's great workmanship."

I remain inordinately pleased by that, some 20y later...

-- 
Liam Proven • Profile: https://about.me/liamproven
Email: lpro...@cix.co.uk • Google Mail/Talk/Plus: lpro...@gmail.com
Twitter/Facebook/Flickr: lproven • Skype/LinkedIn/AIM/Yahoo: liamproven
UK: +44 7939-087884 • ČR/WhatsApp/Telegram/Signal: +420 702 829 053


Re: formatting MFM drives on a IBM PC

2017-09-27 Thread Guy Sotomayor Jr via cctalk

> On Sep 26, 2017, at 10:20 PM, Chuck Guzis via cctalk  
> wrote:
> 
> On 09/26/2017 09:53 PM, Mike Stein via cctalk wrote:
> 
>> Ah yes, the interesting 11MB IMI 7710. Cromemco also used them in their 
>> Z-2H; I still have one somewhere, not a bad drive when it worked ;-)  
> 
> The really crazy thing is that we were taking our hardware over to
> Viking Labs to do temperature, humidity and shake table testing, along
> with hipot.   We were pretty proud that things kept working even after
> the CRT neck fractured.

That reminds me of one of the “chamber” tests that was being run on an XT.
The XT was in the chamber running diagnostics while the chamber was doing
temperature and humidity cycling.  The lab techs left it running over a long 
weekend.  Over the weekend there was a power failure (not infrequent in
southern Florida) and the chamber when it rebooted ran it’s default program
which was to raise the temperature to 70C and remain there for 24 hours.

The sight that greeted us when we came into the lab was funny.  The monitor 
(I think it was monochrome) melted (I should say the plastic did) and the floppy
disk in the drive was rippled.  However, we rebooted the XT (after removing the
floppy from the drive) and it worked (including the monitor).

TTFN - Guy

Re: ICL 1501 terminal available in Sweden.

2017-09-27 Thread Stefan Skoglund via cctalk
ons 2017-09-27 klockan 16:03 +0200 skrev Mattis Lind via cctalk: 
> >> In a closed Facebook group in Sweden there is someone that want to sell a
> >>> number of ICL1501 terminals.
> >>>
> >>>
> >> There doesn't seem to be any information about ICL terminals at the
> >> Terminals wiki http://terminals-wiki.org/
> >>
> >> But some information is found
> >> http://computermuseum.informatik.uni-stuttgart.de/dev_en/
> >> icl1501/icl1501.html
> >>
> >> looks like these are a bit more than terminals
> >>
> >>
> > Indeed, the 1501s are real computers, built by a firm called "Cogar". At
> > the end of our page about the ICL1501 is a link to the technical
> > information: schematics and programmers manual.
> >
> 
> Apparently the terminals this guy is selling was connected to a Diablo 30
> type drive. He just uploaded a couple of pictures of the drive as well.
> 
> Quite an interesting little system.

Pictures (or did he only post inside the FB:group) ?



Re: formatting MFM drives on a IBM PC

2017-09-27 Thread Ethan via cctalk

IIRC, the first time I had problems with the low level format was with one
of the early IDE controllers and a 230MB Maxtor. Crapped out the entire
firmware, was never able to get it to admit who it was again. Seemed to
work okay with earlier MFM/RLL 40 MB and 80 MB Conner drives (I think, it's
been a while).


AFAIK a lot of IDE drives store part of the firmware on the spinning disk 
in a special section of the disk. Not sure if those early models used that 
trick to cut costs or not?


The idea of IDE, as my understanding, is the controller that existed as an 
ISA card was moved onto the actual drive, and then what became the 
controller was mostly just extending the ISA bus over to the drive.


My first hard drive was a SCSI-1 ?Fuji? on a Seagate 8-bit ISA card. 
Families Tandy 1000sx. I remember in the end playing with low level 
formatting tools and interleves, then the drive dying at the same time. I 
correlated the two together then, but looking back I think the issue was 
drive motor/bearings/stuck rotation of platters.





Re: formatting MFM drives on a IBM PC

2017-09-27 Thread Paul Koning via cctalk

> On Sep 27, 2017, at 7:55 AM, Bill Gunshannon via cctalk 
>  wrote:
> 
> ...
> I have never had to do that.  The only boxes I ever LLF disks for
> were PDP-11's and VAX.  And then, only once, on initial install.

DEC was all over the map as far as disk formatting goes.  Some packs were 
delivered blank and had to be formatted first (RK05 for example).  Some were 
delivered formatted and there wasn't any format operation (RL01, RP04).  And 
then there were the fixed head devices (RC11, RF11, or more accurately RS64 and 
RS11 drives) which were delivered formatted, but might have to be reformatted 
in the field by specialized field service devices for certain repairs.  I've 
seen it done on an RF11 that had a head crash, in 1975 in college.

Stranger still are the Pro hard drives, which can be formatted but the tools 
are deeply buried; I remember seeing RT11 code that can do it but I don't 
remember if other operating systems include the capability.

What VAX drives had a format capability?  The PDP-11 ones I can think of 
weren't supported on VAX.

paul



RE: formatting MFM drives on a IBM PC

2017-09-27 Thread Bill Gunshannon via cctalk


From: cctalk [cctalk-boun...@classiccmp.org] on behalf of Fred Cisin via cctalk 
[cctalk@classiccmp.org]
Sent: Tuesday, September 26, 2017 7:53 PM
To: Ali; General Discussion: On-Topic and Off-Topic Posts
Subject: Re: formatting MFM drives on a IBM PC

> > I remember at least one manufacturer >recommending it for their
> > drive(s) if they were ever tilted through 90 degrees - >presumably
> > there were tiny effects on the head positioning and so not >doing a
> > LLF would result in problems.

On Tue, 26 Sep 2017, Ali via cctalk wrote:
> This was pretty common wisdom back in the day. Not quote sure how wise
> it was but it was generally recommended in the magazines of the time. I
> remember reading an article about it in PC Magazine.

There were some interesting discussions of that when companies, such as
Compaq, first started to put hard drives in portables!



I have never had to do that.  The only boxes I ever LLF disks for
were PDP-11's and VAX.  And then, only once, on initial install.

bill



Re: formatting MFM drives on a IBM PC

2017-09-27 Thread Christian Corti via cctalk

On Tue, 26 Sep 2017, emanuel stiebler wrote:

So, what is the best(?) or easiest piece of software,
to format the drives, check for bad blocks, etc.?


I like the "CMS Fixed Disk Diagnostics" very much, the file is FDIAG.COM
It can be found here:
ftp://computermuseum.informatik.uni-stuttgart.de/utils/FDIAG.COM

Christian


Re: ICL 1501 terminal available in Sweden.

2017-09-27 Thread Mattis Lind via cctalk
>> In a closed Facebook group in Sweden there is someone that want to sell a
>>> number of ICL1501 terminals.
>>>
>>>
>> There doesn't seem to be any information about ICL terminals at the
>> Terminals wiki http://terminals-wiki.org/
>>
>> But some information is found
>> http://computermuseum.informatik.uni-stuttgart.de/dev_en/
>> icl1501/icl1501.html
>>
>> looks like these are a bit more than terminals
>>
>>
> Indeed, the 1501s are real computers, built by a firm called "Cogar". At
> the end of our page about the ICL1501 is a link to the technical
> information: schematics and programmers manual.
>

Apparently the terminals this guy is selling was connected to a Diablo 30
type drive. He just uploaded a couple of pictures of the drive as well.

Quite an interesting little system.


>
>
>
>