12 Nov
2007
12 Nov
'07
1:07 p.m.
Subject: Re: Tarbell is making me insane
From: Grant Stockly <grant at stockly.com>
Date: Mon, 12 Nov 2007 00:43:21 -0900
To: "General Discussion: On-Topic and Off-Topic Posts" <cctalk at
classiccmp.org>
Allison, thanks a lot for the detailed response! A lot of that info
can be used to help other people too!
I've written this e-mail from the "bottom up", so some things may
seem out of order in the time line.
I think that I'm to the point where I've narrowed the problem down to
inside the tarbell card, but I don't think the problem is the
1771. Any further hints are well appreciated. : )
I've seen bad 1771s out of the box (WD was not allways a qualaity house)
but I've never seeen one fail in service excluding overvoltage or reverse
polairty.
One little nasty. The 1771 has a basic ability to do data seperation.
I havent' looked at a tarbel board in a very long time but I do hope
that they didn't do the TRS80 save a buck trick and try to use that
internal seperator, it does NOT work. It has zero jitter tolerence.
I think we're getting closer!
Just making sure.
>I can't speak for the exact combination
of the Tarbell, but the
>system has been running all day long with:
>-16k static card
>-8k static card
>-4k static card
The disks are 24k CP/M 1.4, the 4k is for the monitor. Forgot to say
that... Included on my source disk (which is read by the flaky
tarbell) is a BIOS for 48k CP/M, but I have never had it going long
enough to patch, movcpm, or whatever it is that has to be done to get
the new CP/M onto the disk... Ok you have 28k
ram. Is the image sized and booting in that?
If the image is sized for say 32 or 48K it will crash, likely
as a bounce back to rom monitor.
See previous response for a description. When it runs, it
runs. When it doesn't...it doesn't : ( I spent all day long writing my own tarbell driver /
monitor program
that would select, reset, seek, read, write, etc. When I tried the
read monitor command for the first time I didn't get an error. I
tried booting CP/M and it worked... Then I swapped to the more
troublesome tarbell card to get errors (I know, stupid) The problem
appears to be within the tarbell card. I can reliably get my tarbell
monitor to report this:
Reading A Sector
ERROR: Record Not Found!
"
Data is comming from the disk, however it's not readable. Possible
reasons:
NOISE, ground the drive, insure it has good power that the
system case and it's grounds are common. Also common
error is long drive cables (stay short for now) and cables
(and drives) that get near CRTs.
Jitter:
EXTERNAL: This can come from noise as above. Also drive
mechanical issues.
Internal: 1771 requires a data seperator to recover clock and
nice(cleaned up some) read data. The common circuits
are oneshots and PLLs. Tarbel used oneshots. Generally
they work well enough if set right.
LOGIC: problem with read/wait hardware not working or possible
data path corruption.
When I swap to the "better" tarbell, the basic sector read command
passes. (BTW, the reliably bad one above did boot CP/M once and gave
me a few good sectors!!! And I've swapped the 1771 between boards
and the bad stays bad and good stays good!) Basically I use the
monitor to clean the memory, load my program, and then I flip the
reset switch on the Altair. The Altair runs my program which starts
at 0000 and then jumps back into the rom monitor. Here is the
tarbell being good:
your shotgunning. I've seen this for 30+ years. Doesn't work, swap
out the big hairy chip as they must be flaky or why else put it in a
socket? Rare if ever is that the case.
FYI: certain brands of sockets of the side wipe style tend to fatigue
with insertion/removeal and some do it over time leading to failures
where the chips are 100% good but nothing works and may be flakey
if wiggled or moved.
"
MON85 Version 1.1
Copyright 1979-2006 Dave Dunfield
All rights reserved.
DD or HD with tarbel??????
F0000 3000 00
L
Reading A Sector
MON85 Version 1.1
Copyright 1979-2006 Dave Dunfield
All rights reserved.
m2000
2000 1E 0A 31 00 01 21 00 45 16 33
0E 02 06 04 79 CD ..1..!.E.3....y.
2010 2A 00 15 CA 00 5A 06 00 0C 79 FE 13 DA 0F 00 3E *....Z...y.....>
2020 53 D3 F8 DB FC 0E 01 C3 0C 00 D3 FA CD 41 00 3E S............A.>
2030 88 B0 D3 F8 DB FC B7 F2 41 00 DB FB 77 23 C3 34 ........A...w#.4
2040 00 DB F8 E6 9D C8 1D C2 02 00 32 80 00 2F D3 FF ..........2../..
2050 C3 50 00 00 5A 80 04 19 00 02 00 45 80 04 15 01 .P..Z......E....
2060 01 80 51 00 00 00 00 00 00 00 00 00 00 00 00 00 ..Q.............
2070 00 00 00 00 00 00 00 00 00 00 00 00 00 C3 00 00 ................
"
I have to pull the card out to enable the boot rom...guess what, it
boots...but at the moment it is only reading "real" DD media. The HD
media with the tape "works" but BDOS complains about "bad
sectors". This HD disk on another day works just fine. I ran one of the programs:
"A>disktest
TARBELL MINI-FLOPPY DIAGNOSTIC OF 8-1-80
STANDARD VERSION 1.8
40 TRACKS 18 SECTORS
SELECT DRIVE. (A/B/C/D) a
HOW MANY RETRYS? (0-9) 4
SELECT STEP RATE. (S=40MS,M=20MS,F=12MS) m
FULL TRACK SEEK? (Y/N) y
TO START TEST TYPE RETURN.
0 READ ERRORS DETECTED.
REPEAT TEST? (Y/N)
"
Maybe that gives you a clue as to what I'm working with.
And if I try my HD disks it does this: (to every sector on every track)
"
READ RECORD NOT FOUND ERROR.
TRACK 0 SECTOR 1
READ RECORD NOT FOUND ERROR.
TRACK 0 SECTOR 2
READ RECORD NOT FOUND ERROR.
TRACK 0 SECTOR 3
"
Last weekend that was my boot disk and I had several basic programs
compiled with basic-e on it.
HD media is incompatable in every way with older drives and lower
data rates.
Drives used for HD media are 96tpi and track pasing ansd width are
different, incompatability is oftenn the case or at best it gets by.
Don't have Tarbell schematics handy to check.
Does the read loop test a status bit or hang/wait on read?
If it's hang wait on read is that also tied to interrupt??
If it's read a status bit two things:
CPU MUST complete the read a byte loop in 32us (64 for mini floppy)
and CPU speed makes this in some cases difficult.
can you supply the sector read code? ( should be fairly short)
Is the boot
image set up for MITS 2SIO and does it set it up?
I have a session captured from "once upon a time" when it booted
(which is more random than anything I can think of)
"TARBELL 24K CPM V1.4 OF 7-20-79
2SIO MINIFLOPPY VERSION.
HOW MANY DISKS? 2
A>dir
A: CPM COM
A: SYSGEN COM
A: DDT COM
A: COPY COM
A: PIP COM
A: ASM COM
A: STAT COM
A: ED COM
A: FORMAT COM
A: DISKTEST COM
A: DUMPDSK COM
A: BASIC COM
A: RUN COM
A>
" I assume thse
are in high memory and not below the address the image will
try to boot to. CP/M wants from 0000h to system size as configured.
My bytesaver is at C000 and 4k of sram for the monitor is at
E000. There is 24k of contigous memory at 0000.
Doesnt assure the FDC is set right for the drive
and media.
Also doesnt assure the media is SD or even bootable.
Further is the media is not using a 2sio as the IO the system could
boot and crash or appear to.
The drive, tarbell, and boot disks were mailed to me from a fellow
enthusiast. He made all of the modifications, made the disks,
etc. He has tested the setup in an IMSAI (kind of) with my (kit)
CPU, a SSM 8080, and a ZPU at 2MHz. To add to that, I have myself booted off the setup,
formatted disks,
made copies, ran the basic compilier, ran asm, etc. But something
(and I think its IN??? the tarbell card does not like me, Alaska, my
Altiar... I don't know! : (
Could be an interaction of both.
A quote:
"My Imsai has a standard front panel with a factory suggested mod. to
do a power-on halt at zero. It has two 16K Industrial Microsystems
static ram boards, a SIO2 serial board and a SSM 8080 CPU. The prom
on the Tarbell is turned off to let the front panel operate properly
at power on. The Tarbell is then booted by using a MITS eprom board
and the 1702A eprom you burned for me. The power supply is a
Industrial Microsystems switching supply which powers both the drives
and the backplane
But you don't have "that". You sorta have something like that.
Following is the different configurations I have used
in the test
unit to boot the Tarbell;
1. With a Z80 Cromemco ZPU set at 2Mhz, power-on jump set to
zero and no front panel. The Tarbell boots at power-on and will do a
cold boot every time you push the reset button.
2. With a ZPU and Imsai front panel the Tarbell
boots
only when the run switch is pushed.
3. With the Altair CPU and no front panel the Tarbell will not
boot at power on or after a reset!
No suprize, the MITS CPU has no POJ, nada. It must be reset, load address
and then run.
4. With the Altair CPU and the Imsai front panel
the Tarbell
will boot after you push reset and then push the run switch.
Says the MITS FP is causing some pain.
After the Tarbell boards boot I have never had a problem or dropout
in CP/M with any CPU- front panel configuration. The static ram
boards use low power chips and run cool.
thats good but getting there is an issue.
Remember my Altair CPU board uses a 8224 in the
oscillator circuit
and I replaced the 8T97 with 74LS367's.
"
The 8t97s worked fine for me. It has 8224? your mod or 8800B?
This is some info on the mod:
"The modification we have on our Tarbell boards was designed for the
5.25 Tandon TM-100 single sided. single density 48tpi drive which was
one of the first 5.25 drives produced. It might be that some of the
new 3.5 drives just won't work with the setup we are using."
The only media that should go in that drive is the brown SD/DD floppies.
If the media was written on a 96tpi drive the noise and jitter _will_
be higher due to track width differences. IF the FDC oneshots are
not quite on that makes a huge differnence.
The hub clamps sometimes off center the media and still media will
sometimes drag the motor speed down. Watch for that.
Could even be a
simple bad IDC crimp on the cable.
I have tried a few FDC cables. Maybe I should make a new one.
Time for bed. : (
Grant
Don't know if it helps
Allison
13 Nov
13 Nov
12:25 a.m.
Wow, a lot to go over here... Rich, if you have any problems with
your drive I might be able to help you after this exercise! : )
At least we both have a ZPU and both have one with the 2MHz
switch. So that eliminates the CPU card one shots from the
reliability question. Right?
FP?
Data is comming from the disk, however it's not
readable. Possible
reasons:
NOISE, ground the drive, insure it has good power that the
system case and it's grounds are common. Also common
error is long drive cables (stay short for now) and cables
(and drives) that get near CRTs.
I'm hooking the 3.5" drive power cable directly to the output of the
7805 on the tarbell, which is getting its power from an 8v switching
power supply. The power is nice and steady at 4.95v. The only thing
I haven't done is made sure the case is grounded. Some drives had
jumpers for that, but mine doesn't. So it could be either way.
Internal: 1771 requires a data seperator to
recover clock and
nice(cleaned up some) read data. The common circuits
are oneshots and PLLs. Tarbel used oneshots. Generally
they work well enough if set right.
The tarbell card I have doesn't have any one shots for data
separation. The read data line goes into a L74 (Dual D Edge
Triggered Flip Flop), then goes into a LS175 (Quad D Type Flip Flop
with Direct Clear). There are two LS161 (Synchronous 4 Bit Binary
Counter) that are hooked up to parts of the LS175. There are is a
XOR gate and two NAND gates. I'm not sure what is going on at the
moment, does it seem like that pile of parts could be implementing a
PLL? I would think a PLL would be more complex than that. I'll at
least make sure all of the edges match up (Read data vs separated
clock and data)
I hope I find something obvious. I should at least see a difference
between the two tarbell cards (reliably bad vs somewhat bad). I have
a 4FDC Cromemco? It uses a 1771. I might be able to use the tarbell
driver to boot off of that. Is anything known about that card as far
as being better or worse?
LOGIC: problem with read/wait hardware not working
or possible
data path corruption.
The two 3.5" drives and the 5.25" drive I have don't do anything with
the ready/disk change line at all. BUT, I know the Sony 3.5" drive
doesn't generate index pulses until the drive speeds up (I think that
is what its doing).
With a TEAC 235HF drive it takes 694.053ms for the drive to generate
sector pulses AFTER the drive was given a "Motor Enable"
signal. Even though the head was NOT at track 00, the drive didn't
signal that status until 491.221ms after given a "Motor Enable". So
the drive seemed to spin the motor up, tell the controller it was not
at 0, and then start issuing index pulses.
That is probably how the 3.5" disk is getting away without a ready
line. The older drives probably generated index pulses regardless of
if the drive is ready or not. These newer drives with more brains
must not make index pulses unless they are ready.
your shotgunning. I've seen this for 30+ years.
Doesn't work, swap
out the big hairy chip as they must be flaky or why else put it in a
socket? Rare if ever is that the case.
On my second kenbak build I had a problem. First I tested all of the
ICs (digital only) but didn't find any problems so I started swapping
them all. About 3 hours after testing it started working, but then
stopped. I found a cold solder joint. Pushing around and bending
the boad "fixed" it. : ) So I fixed the joint and reinstalled all
of the old chips. : )
The main reason I swapped the 1771 was because I think I read
somewhere that its a very static sensitive part and of all of them
the most likely to go out...
FYI: certain brands of sockets of the side wipe style
tend to fatigue
with insertion/removeal and some do it over time leading to failures
where the chips are 100% good but nothing works and may be flakey
if wiggled or moved.
I will replace the sockets with machine pin sockets.
DD or HD with tarbel??????
The tarbell is treating the 3.5" disk drive as that TM100 tandon SSSD
drive. The data rate recorded to the drive is 8.07us per bit. I'm
getting 123916 bits a second, which doesn't seem to match anything I
remember...
HD media is incompatable in every way with older drives
and lower
data rates.
My drive is a new from sony. I've made formatted and written to HD
disks with the HD hole covered. This same drive reading the same
disks does not always read. I don't know if its the tarbell's fault or not.
Does the read loop test a status bit or hang/wait on
read?
The silly tarbell issues a "IN" to a "wait" port and the tarbell
keeps it in a wait state until the 1771 is good and ready. Kind of
makes debugging hard if the tarbell doesn't decide to stop waiting. ; )
can you supply the sector read code? ( should be
fairly short)
The datasheet for the 1771 says "Upon receipt of the Read command,
the head is loaded, the BUSY status bit set, and when an ID field is
encountered that has the correct track number, correct sector number,
and correct CRC, the data field is presnted to the computer."
Is that the sector read code you are talking about? One of those
first bytes? The data sheet says that the 1771 is capable of reading
the entire track as one big sector. Maybe I should try to make a
routine to do that. I don't know of any other way to get that code
since it isn't part of a normal read.
The drive,
tarbell, and boot disks were mailed to me from a fellow
enthusiast. He made all of the modifications, made the disks,
etc. He has tested the setup in an IMSAI (kind of) with my (kit)
CPU, a SSM 8080, and a ZPU at 2MHz.
Kind of and exactly are differnt things. 4. With
the Altair CPU and the Imsai front panel the Tarbell
will boot after you push reset and then push the run switch.
Says the MITS FP is causing some pain. The 8t97s worked fine for me. It has 8224? your mod
or 8800B?
That was part of a quote from him. Its not my board. I do have pictures at:
http://www.stockly.com/forums/showthread.php?t=325
Its a regular Rev 0 card with some modifications. The biggest
modification is the lack of one shots. It uses an 8224. I imagine
he got this info from a vintage place somewhere because his work
looks very well planned out. Or maybe he just planned it out good!
The only media that should go in that drive is the
brown SD/DD floppies.
If the media was written on a 96tpi drive the noise and jitter _will_
be higher due to track width differences. IF the FDC oneshots are
not quite on that makes a huge differnence.
I've read that HD (1.44MB 3.5") disks with tape over the HD hole
aren't exactly a DD disk. Something about the track width being
narrower because of the smaller head in an HD drive? BUT, the DD
(720k 3.5") disks were formatted to 40 tracks 18 sectors, 128 bytes a
sector using an HD drive. So the DD disks wouldn't have a wide track
width to begin with. Are there really physical media differences
between DD and HD that would keep a HD disk from being used as a DD
disk when in a HD drive? The HD drive should be able to read the
narrow track written on what it thinks is a DD disk, right? Is the
magnetic material of an HD disk significantly different?
Most of the information I've read about mixing media is in reference
to DD disks being written in an HD drive and then becoming unreliable
in a DD drive. I've also heard about people who add holes to disks
to make a DD disk an HD disk, which probably works for them better
than my tarbell works for me... : )
Thanks!
Grant
7:23 p.m.
Wow, a lot to go over here... Rich, if you have any problems with
your drive I might be able to help you after this exercise! : )
If that's a plain 7805, it'll only sypply 1A. And I could well believe an
S100 board of logic (including a 1771) _and _ a floppy drive could take
more than that. You might be having little power glitches caused by the
spindle motor, or when you step the head, that will really mess things up.
I would use a seprarate supply for the drive.
As regards grounds, it's ovbiously essential that the 0V line of the
drive and controller (and the rest of the S100 system) are all linked
together. But I've never hand any problems with not bonding the drive
chassis to ground, I suspect that unless you live in an eelctrically
noisy environment, you won't either.
Data is comming from the disk, however it's
not readable. Possible
reasons:
NOISE, ground the drive, insure it has good power that the
system case and it's grounds are common. Also common
error is long drive cables (stay short for now) and cables
(and drives) that get near CRTs.
I'm hooking the 3.5" drive power cable directly to the output of the
7805 on the tarbell, which is getting its power from an 8v switching
power supply. The power is nice and steady at 4.95v. The only thing
I haven't done is made sure the case is grounded. Some drives had
jumpers for that, but mine doesn't. So it could be either way. HD media is
incompatable in every way with older drives and lower
data rates.
My drive is a new from sony. I've made formatted and written to HD
disks with the HD hole covered. This same drive reading the same
disks does not always read. I don't know if its the tarbell's fault or not.
I've read that HD (1.44MB 3.5") disks with
tape over the HD hole
aren't exactly a DD disk. Something about the track width being
Coirrect. The coercivity of the HD media is a little higher. Not as bad
as the difference between 5.25" DD and HD disks, but it can still 'bite'
you sometimes.
narrower because of the smaller head in an HD drive?
BUT, the DD
(720k 3.5") disks were formatted to 40 tracks 18 sectors, 128 bytes a
sector using an HD drive. So the DD disks wouldn't have a wide track
width to begin with. Are there really physical media differences
When used ona PC, both 3.5" formats (720K and 1.44M) have 80 cylinders, 2
heads. The track spacing is the same (135 tpi). If you're only using 40
cylinders, my guess is that you're using the outer 40 cylinders of the
80-cylinder format, still at 135 tpi. This shouldn't be a problem.
-tony
7:04 p.m.
I've seen bad 1771s out of the box (WD was not
allways a qualaity house)
but I've never seeen one fail in service excluding overvoltage or reverse
polairty.
I have, or at least I think I have. A friend had an RML380Z machine with
disk problems, and after a bit of troubleshooting, we traced it to the
1771 chip. I had _one_ spare at the time which I gave him, AFAIK the
machine is still running 10 years on.
Now obvioulsly I can't be sure there wasn't a spike on one of the PSU
rails that killed the old chip, but that was the only chip in the machine
to fail, and the 380Z PSU is a pretty simple thing full of 3-terminal
regulators, not known for playing up.
I've certainly had 1793s fail in my TRS-80 Model 3. One time it
intermittantly didn't prrduce DRQs, so the data register was not loaded
with the next byte by the software. The result was bytes being repeated
in a secotr. Ouch!.A text file might contain 'Hellllllllllllllo World'
for example.
One little nasty. The 1771 has a basic ability to do
data seperation.
I havent' looked at a tarbel board in a very long time but I do hope
that they didn't do the TRS80 save a buck trick and try to use that
internal seperator, it does NOT work. It has zero jitter tolerence.
Strange. I used an unmodified TRS-80 Model 1 EI for years and never had
any problems with the disk side of things. And that used the internal
data separateor of the 1771 IIRC.
-tony
11:07 p.m.
One little nasty. The 1771 has a basic ability to do
data seperation.
Well, it purports to.
The quality of the internal data separation sometimes leaves a bit to be
desired. Percom sold an astonishing number of add-on data separator
sandwich boards to TRS80 owners.
Then they switched to selling a sandwich board that added a 179x for
double density, while still retaining the 1771, for the oddball DAMs that
it could provide (needed for TRS80)
15 Nov
15 Nov
4:23 a.m.
On Tuesday 13 November 2007 18:07, Fred Cisin wrote:
What was oddball about DRAM (Is that what you meant?) for those machines?
--
Member of the toughest, meanest, deadliest, most unrelenting -- and
ablest -- form of life in this section of space, ?a critter that can
be killed but can't be tamed. ?--Robert A. Heinlein, "The Puppet Masters"
-
Information is more dangerous than cannon to a society ruled by lies. --James
M Dakin
One little
nasty. The 1771 has a basic ability to do data seperation.
Well, it purports to.
The quality of the internal data separation sometimes leaves a bit to be
desired. Percom sold an astonishing number of add-on data separator
sandwich boards to TRS80 owners.
Then they switched to selling a sandwich board that added a 179x for
double density, while still retaining the 1771, for the oddball DAMs that
it could provide (needed for TRS80)
4:44 a.m.
New subject: Tarbell helped make me insane
Then they
switched to selling a sandwich board that added a 179x for
double density, while still retaining the 1771, for the oddball DAMs that
it could provide (needed for TRS80)
What was oddball about DRAM (Is that what you meant?)
for those machines?
Well, I'm sure that there ARE some oddball DRAMs, but that ISN'T what I
meant.
DAM is Data Address Mark.
Oversimplifying just enough to offend the experts, . . .
it is a slightly "out of spec" byte (such as missing a clock pulse) that
can be used to provide an out-of-band signal to the disk controller,
to mark the start of a block of data.
The 1771 could provide a bunch of different ones.
The 179x could provide some, but not all of the ones that the 1771 could
handle.
Unfortunately, Model I TRS-DOS (1771) used some that the 179x could not
create. Therefore, there wasn't any practical way to create a disk
using a 179x that UNMODIFIED Model I TRS-DOS could handle.
There are unconfirmed stories that the reason that TRS-DOS used "oddball"
ones was due to a misprint on a spec sheet.
--
Grumpy Ol' Fred cisin at xenosoft.com
5:18 a.m.
New subject: Tarbell helped make me insane
On Wednesday 14 November 2007 23:44, Fred Cisin wrote:
Ok. I'm glad I asked. :-)
> Then they
switched to selling a sandwich board that added a 179x for
> double density, while still retaining the 1771, for the oddball DAMs
> that it could provide (needed for TRS80)
On Wed, 14 Nov 2007, Roy J. Tellason wrote:
What was oddball about DRAM (Is that what you
meant?) for those machines?
Well, I'm sure that there ARE some oddball DRAMs, but that ISN'T what I
meant.
DAM is Data Address Mark. Oversimplifying just enough to offend the experts, . .
.
it is a slightly "out of spec" byte (such as missing a clock pulse) that
can be used to provide an out-of-band signal to the disk controller,
to mark the start of a block of data.
The 1771 could provide a bunch of different ones.
The 179x could provide some, but not all of the ones that the 1771 could
handle.
This is interesting, I had no idea about those differences between those two
parts.
Unfortunately, Model I TRS-DOS (1771) used some that
the 179x could not
create. Therefore, there wasn't any practical way to create a disk
using a 179x that UNMODIFIED Model I TRS-DOS could handle.
Makes sense.
There are unconfirmed stories that the reason that
TRS-DOS used "oddball"
ones was due to a misprint on a spec sheet.
Heaven only knows, at this point.
I don't recall having those 17xx parts in the datasheets yet, I guess I'll
have to dig some up and add them in there. I also remember one that I think
I ran into in some of the Osborne stuff -- MB8877 sounds about right -- that
seemed to be equivalent to one of those. And there was some common data
separator part I used to run into all the time, too -- 9316 sound at all
familiar? I forget if that's it or not but at one point in time I found
myself with three different machines and all three of them had the same FDC
and data separator chips in them.
--
Member of the toughest, meanest, deadliest, most unrelenting -- and
ablest -- form of life in this section of space, ?a critter that can
be killed but can't be tamed. ?--Robert A. Heinlein, "The Puppet Masters"
-
Information is more dangerous than cannon to a society ruled by lies. --James
M Dakin
4:45 a.m.
On 14 Nov 2007 at 23:23, Roy J. Tellason wrote:
What was oddball about DRAM (Is that what you meant?)
for those machines?
No, he means DAM - Data Address Mark. It's a combination of data and
clock bits that marks the start of the data portion of a sector.
Normally this would not be encountered elsewhere. For example, the
"normal" DAM for FM disks is FB with a C7 clock. But the 1771 could
write DAMs with values from F8 to FB. IIRC (I'd have to go back to
my notes to make sure), the TRS-80 marked directory sectors with a
DAM of FA. Now, a DAM of FA is no problem with the 179x FDC, except
that the 1771 returned a two-bit status giving record type, but the
1791 collapses this to one bit. So the 1791 can't tell the
difference between an FA and FB DAM, so the 1771 is needed for those
old TRS-DOS diskettes that use the FA=directory sector scheme.
A case where a programmer being "clever" came back to bite the
vendor.
Cheers,
Chuck
9:04 p.m.
Then they
switched to selling a sandwich board that added a 179x for
double density, while still retaining the 1771, for the oddball DAMs th=
at
it could provide (needed for TRS80)
What was oddball about DRAM (Is that what you meant?) for those machines?
13 Nov
13 Nov
11:16 p.m.
One little
nasty. The 1771 has a basic ability to do data seperation.
I havent' looked at a tarbel board in a very long time but I do hope
that they didn't do the TRS80 save a buck trick and try to use that
internal seperator, it does NOT work. It has zero jitter tolerence.
Strange. I used an unmodified TRS-80 Model 1 EI for years and never had
any problems with the disk side of things. And that used the internal
data separateor of the 1771 IIRC.
11:47 p.m.
On 13 Nov 2007 at 14:16, Grant Stockly wrote:
If that is the case, why would the Tarbell have so
many extra
chips? Also, at the time the tarbell was manufactured, would they
have even known that there was an issue with the 1771's data separation?
WD made no bones about it. In the app notes for the 1771, they say:
"In order to maintain an error rate better than 10**8, and(sic)
external data seperator (sic) is recommended."
Yes, they spell it "seperator" throughout the application notes (this
was before spelling checkers appeared on Red Hill Road, I suppose).
The app notes has several customer-supplied circuits for data
"seperators".
In point of fact, the Shugart SA-801 has an on-board one-shot data
separator for FM and you'd be crazy to use it.
Cheers,
Chuck
6262
days inactive
6265
days old
11 comments
6 participants
participants (6)
-
ajp166＠bellatlantic.net -
ard＠p850ug1.demon.co.uk -
cclist＠sydex.com -
cisin＠xenosoft.com -
grant＠stockly.com -
rtellason＠verizon.net