are you the site administrator or something??? An
offer to buy or trade would not have been ruled out.
The COBOL compiler I mentioned was bought dopey
person, with manuals, for 5 bucks. I mentioned the
Borland Museum because I like passing on a hot tip
once in a while, ummm like yourself (who isnt aware of
e donkey?). But I dont feel the need to issue
ultimatums.
--- cctech-bounces at classiccmp.org
<holger.veit at ais.fraunhofer.de> wrote:
> Chris M wrote:
>
> >I may have posted this request...plea...on cctech
some
> >time ago. I've been looking for an early Microsoft
> >Fortran compiler for eons. Vanilla DOS version
would
> >be fine, but for something exotic like the Tandy
2000
> >or Zenith Z-100 would be exquisite. I was fortunate
to
> >obtain, oo, MS-COBOL recently, and to my amazement
I
> >managed to WinImage the disks. Version 2.0 or
> >something.
> > If any of you weren't aware, the earliest versions
of
> >Turbo Pascal and Turbo C are available for download
on
> >the Borland Museum.
> >
> >__________________________________________________
> >Do You Yahoo!?
> >Tired of spam? Yahoo! Mail has the best spam
protection around
> >http://mail.yahoo.com
> >
> >
> Hi, I guess with anonymous "Chris M" with a
throw-away yahoo address not
> many people have many
> trust in handing out copies of software to you. This
software is
> admittedly obsolete by far, but
> is still copyrighted by Microsoft. What Borland does
with their obsolete
> software is their personal
> preference, and is not transferable to other
companies.
>
> Personal suggestion: look into emule/edonkey P2P
networks for a key [Dos
> Application], and don't tell
> anyone what you might see, and never ask here again.
>
> Holger
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
I need to clear out some space. I have Apple ][ super serial and I/O
controller cards (with cables). I also have a Duodisk floppy drive and
a Disk II floppy drive and a WICO command control joystick.
$5 each + shipping, untested.
Thanks! Norm
All:
After a few weeks of tinkering with my 8800b I think I've finally
got it working satisfactorily (except for some bad RAM which was the subject
of a prior email).
I've got an EPROM programmed with the Turnkey Monitor, EPROM
programming software for the SSM P1B board, and the driver software for the
SSM V1B video board. Except for the RAM, everything works. The only thing I
have to track down is why the video is displaying only black-on-white.
Otherwise, I have to replace two switches on the front panel with flat-blade
ones.
Now I have to improve on the monitor so I can load something useful
into memory :-)
Rich
Rich Cini
Collector of classic computers
Build Master for the Altair32 Emulation Project
Web site: http://highgate.comm.sfu.ca/~rcini/classiccmp/
/************************************************************/
>
>Subject: Re: FDC Gap Length?
> From: Dave Dunfield <dave04a at dunfield.com>
> Date: Sun, 17 Jul 2005 11:10:39 -0400
> To: "General Discussion: On-Topic and Off-Topic Posts" <cctalk at classiccmp.org>
>
>Hi Jules,
>
>>On Sun, 2005-07-17 at 07:28 -0400, Dave Dunfield wrote:
>>> If no calculation is possible, can anyone point me at a more complete table of
>>> suggested GPLs? The NEC table has some large holes, for example 9x512 and 10x512
>>> are missing.
>>
>>In case it's useful, I've got the following in the Torch Manta SCSI-
>>floppy controller documentation (amongst others):
>>
>>512 byte sectors (5.25" or 3.5" media):
>>
>> FM recording, 4 sectors/track, gap3 size is 175 bytes of FFh.
>> FM recording, 5 sectors/track, gap3 size is 31 bytes of FFh.
>> MFM recording, 9 sectors/track, gap3 size is 66 bytes of 4Eh.
>>
>>1024 byte sectors (5.25" or 3.5" media):
>>
>> FM recording, 2 sectors/track, gap3 size is 255 bytes of FFh.
>> MFM recording, 4 sectors/track, gap3 size is 255 bytes of 4Eh.
>> MFM recording, 5 sectors/track, gap3 size is 66 bytes of 4Eh.
>>
>>512 byte sectors (8" media):
>>
>> FM recording, 7 sectors/track, gap3 size is 149 bytes of FFh.
>> FM recording, 8 sectors/track, gap3 size is 62 bytes of FFh.
>> MFM recording, 14 sectors/track, gap3 size is 120 bytes of 4Eh.
>> MFM recording, 15 sectors/track, gap3 size is 73 bytes of 4Eh.
>> MFM recording, 16 sectors/track, gap3 size is 33 bytes of 4Eh.
>>
>>1024 byte sectors (8" media):
>>
>> FM recording, 3 sectors/track, gap3 size is 255 bytes of FFh.
>> FM recording, 4 sectors/track, gap3 size is 157 bytes of FFh.
>> MFM recording, 7 sectors/track, gap3 size is 255 bytes of 4Eh.
>> MFM recording, 8 sectors/track, gap3 size is 128 bytes of 4Eh.
>>
>>
>>can't remember what controller IC the board uses now though - I'm
>>reasonably sure it's not a 765.
>
>Thanks - I'm not sure this helps me, as the numbers given are different
>than the NEC table. Here's what I have:
The numbers you program into the 765 are not in bytes. Those are counter
values (usually a up counter) so that putting in 255 means 1, the however
the count values are prescaled such that in some cases putting in 254 does
not yeild 2 of something but 4 or even 8 [(0-n) * base]. Example are HLT
(head load time) and HUT (head unload time) and even they are affected by
what the 8/4 mhz clock supplied. Byte counts like the gaps are similar.
So a gap length if FBh might really be 4*16 gap bytes. One note: those
counters have different prescale values for FM then MFM. Hope this helps
and I'm really testing 25 year old memory from my NEC apps engineeing
days.
>Clearly the 200/255 are the maximum values. I have tried working the numbers
>without these entries, and still cannot come up with a calculation.
>
>As you can see the gap sizes differ quite a bit from the ones that you have
>documented - with the 765, this is only one of several gaps, and the controller
>does not provide complete access to the raw format like a 179x controller
>would.
No it does not in the fullest sense. The WD and NEC designs are programtically
as different as night and day. The level of internal automation is higher for
the NEC but doing that takes control from the programmer. NEC used to have
a part (upD371) that was like the 1771 in that it required a fair amount
of processer attention at the per byte level to affect transfers especially
formatting. Where the 765 family all the programmer supplies for formatting
is the initial command and then the sector header info (CHRN) on a per sector
IO. The result is smaller format buffer at the expense of limited format
options. IE:the general layout of a track is allways the same save for gaps and
sector lengths.
>I assume the gap sizes need to decrease for formats which have an extra
>sector (or two) over the NEC table, however I do not know by how much ...
>Any additional table entries, or information on how to calculate this would
>be much appreciated.
Correct and the information provided may help in deciding what those counters
corospond to.
>>The Manta docs only talk about gaps 1-4, however I know some of my Acorn
>>docs reference a gap5 which sits between the gap4 at the end of the last
>>sector on the track and the index marker - I have no idea what that's
>>supposed to do as it's listed as being 0 bytes long in the Acorn
>>examples!
>
>Normally the last gap is filled from the end of the last sector until
>the physical index mark occurs. The 765 appears to do this automatically
>as part of the "Format Track" command. For a controller like the 179x,
>you need to keep providing filler bytes until the physical end of track.
There are two cases of gap 4, gap 4A(index mark) and gap 4B(EOT to index).
I've seen gap 4b refered to as gap 5. In the nominal IBM gap 4A is index
gap and 4B is the end of track filler gap.
FYI: gap 4 it not optional on 765 and excluded in 7265. Functionally
its use is been abused and sometimes not included (1771/1791 it's optional).
Yes for the fill to EOT. The INDEX signal is important to the 765 for
start of track, end of track and read fail.
Allison
> As you can see the gap sizes differ quite a bit from the ones that you
> have documented - with the 765, this is only one of several gaps, and
> the controller does not provide complete access to the raw format like
> a 179x controller would.
Yes, the 179x controllers have the Read Track and Write Track command.
I can remember that from the time I wrote my own "DOS" for the 6800-based
machine with a homebrew floppy controller based on the 1793 IIRC (1981).
You put *all* data in RAM (sector data, gap data, ID mark, sync fields
and what more, and then issue the Write Track command. That's how I got
my 5.25" floppies formatted. Make sure that you have slack (extra gap
bytes at the end ot the "track" in RAM, because depending on rotation
fluctuations the last gap is not a constant number of bytes.
> I assume the gap sizes need to decrease for formats which have an extra
> sector (or two) over the NEC table, however I do not know by how much
> ... Any additional table entries, or information on how to calculate
> his would be much appreciated.
If you do not have the 179x data sheet, aks me. Only then I will go up
to the attick and start searching for it. Otherwise, I will not go there
because, believe me, it *hot* there, afetr two weeks of more than 25"C!
> Normally the last gap is filled from the end of the last sector until
> the physical index mark occurs. The 765 appears to do this automatically
> as part of the "Format Track" command. For a controller like the 179x,
> you need to keep providing filler bytes until the physical end of
> track.
Correct :~)
I found out the hard way, after I "upgraded" the software from single
to double density ... I used polling software to see when DRQ is asserted
and then write the data byte. With double density, the max time allowed
before a data byte *must* be written, is too short for whatever clever
constructed polling loop (in assembler of course).
So I "improved" the hardware to generate an interrupt on DRQ and I could
format floppies in double density. But after some time when I tried to
format a floppy the whole system hung.
I got more interrupts than anticipated, and that was because of the
extra bytes wanted by the FDC. It works sometimes, but that is just
because of the tolerances of the rotation speed.
Now in the year 2005, I am probably going to desing a floppy controller
interface for the Core and I/O Board set, but that's an other story :~)
greetz,
- Henk, PA8PDP.
Hi Jules,
>On Sun, 2005-07-17 at 07:28 -0400, Dave Dunfield wrote:
>> If no calculation is possible, can anyone point me at a more complete table of
>> suggested GPLs? The NEC table has some large holes, for example 9x512 and 10x512
>> are missing.
>
>In case it's useful, I've got the following in the Torch Manta SCSI-
>floppy controller documentation (amongst others):
>
>512 byte sectors (5.25" or 3.5" media):
>
> FM recording, 4 sectors/track, gap3 size is 175 bytes of FFh.
> FM recording, 5 sectors/track, gap3 size is 31 bytes of FFh.
> MFM recording, 9 sectors/track, gap3 size is 66 bytes of 4Eh.
>
>1024 byte sectors (5.25" or 3.5" media):
>
> FM recording, 2 sectors/track, gap3 size is 255 bytes of FFh.
> MFM recording, 4 sectors/track, gap3 size is 255 bytes of 4Eh.
> MFM recording, 5 sectors/track, gap3 size is 66 bytes of 4Eh.
>
>512 byte sectors (8" media):
>
> FM recording, 7 sectors/track, gap3 size is 149 bytes of FFh.
> FM recording, 8 sectors/track, gap3 size is 62 bytes of FFh.
> MFM recording, 14 sectors/track, gap3 size is 120 bytes of 4Eh.
> MFM recording, 15 sectors/track, gap3 size is 73 bytes of 4Eh.
> MFM recording, 16 sectors/track, gap3 size is 33 bytes of 4Eh.
>
>1024 byte sectors (8" media):
>
> FM recording, 3 sectors/track, gap3 size is 255 bytes of FFh.
> FM recording, 4 sectors/track, gap3 size is 157 bytes of FFh.
> MFM recording, 7 sectors/track, gap3 size is 255 bytes of 4Eh.
> MFM recording, 8 sectors/track, gap3 size is 128 bytes of 4Eh.
>
>
>can't remember what controller IC the board uses now though - I'm
>reasonably sure it's not a 765.
Thanks - I'm not sure this helps me, as the numbers given are different
than the NEC table. Here's what I have:
(Sector-size sectors/track GPL1 GPL2 - all numbers are in decimal)
GPL1 = gap-length when reading/writing
GPL2 = gap=length when formatting
8" FM:
128 26 7 27
256 15 14 42
512 8 27 58
1024 4 71 138
2048 2 200 255
4096 1 200 255
8" MFM:
256 26 14 36
512 15 27 84
1024 8 53 116
2048 4 153 255
4096 2 200 255
8192 1 200 255
5" FM:
128 18 7 9
128 16 16 25
256 8 24 48
512 4 70 135
1024 2 200 255
2048 1 200 255
5" MFM
256 18 10 12
256 16 32 50
512 8 42 80
1024 4 128 240
2048 2 200 255
4096 1 200 255
Clearly the 200/255 are the maximum values. I have tried working the numbers
without these entries, and still cannot come up with a calculation.
As you can see the gap sizes differ quite a bit from the ones that you have
documented - with the 765, this is only one of several gaps, and the controller
does not provide complete access to the raw format like a 179x controller
would.
I assume the gap sizes need to decrease for formats which have an extra
sector (or two) over the NEC table, however I do not know by how much ...
Any additional table entries, or information on how to calculate this would
be much appreciated.
>The Manta docs only talk about gaps 1-4, however I know some of my Acorn
>docs reference a gap5 which sits between the gap4 at the end of the last
>sector on the track and the index marker - I have no idea what that's
>supposed to do as it's listed as being 0 bytes long in the Acorn
>examples!
Normally the last gap is filled from the end of the last sector until
the physical index mark occurs. The 765 appears to do this automatically
as part of the "Format Track" command. For a controller like the 179x,
you need to keep providing filler bytes until the physical end of track.
Regards,
Dave
--
dave04a (at) Dave Dunfield
dunfield (dot) Firmware development services & tools: www.dunfield.com
com Collector of vintage computing equipment:
http://www.parse.com/~ddunfield/museum/index.html
Hi Tim,
>Part of the calculation is the time it takes the data separator to re-sync
>after each gap. Now, a "true" 765 doesn't have a data separator so maybe
>they leave this out. It's also true that this number ought to be nearly
>constant depending on sector sizes.
I would assume this is covered by the minimum requirement that Allison was
talking about... Right now I am just trying to find the correct gap sizes
for formatting. Then I will have to worry about the gap size for writing
(which is different, as you obviously don't want to carry through to the
beginning of the next sector).
>Do you have the Intel 8272 data sheet? (This was Intel's part number
>for their 765 clone. It may not just be a clone but the exact same
>mask...). IIRC there are more details/examples/math in the 8272 data
>sheet, including some recommendations for data separators and the good/bad
>of different types.
I do have the Intel data sheet and application notes, however they do not
provide any additional information on selecting the Gap size - just the same
"magic table" that NEC provides.
Regards,
Dave
--
dave04a (at) Dave Dunfield
dunfield (dot) Firmware development services & tools: www.dunfield.com
com Collector of vintage computing equipment:
http://www.parse.com/~ddunfield/museum/index.html
>
>Subject: Re: FDC Gap Length?
> From: Dave Dunfield <dave04a at dunfield.com>
> Date: Sun, 17 Jul 2005 07:28:45 -0400
> To: "General Discussion: On-Topic and Off-Topic Posts" <cctalk at classiccmp.org>
>
>Hi Allison,
>
>>Is there a calculation, NO. Unless your formatting your own, then
>>it's use biggest gaps that allow sector data and a resonable end gap
>>on off speed drives. Most of the time you have to know how
>>that disk was formatted originally to arrive at the correct values.
>>Fortunatly there is a fair amount of wiggle room if you do not run
>>too close (too close is below) to minimums.
>
>I know how the disk was originally formatted to the extent that I know
>the sector size and the number of sectors on the track.
>
>I had assumed that it worked the way you described ... my problem is that
>I cannot make sense of the values in the NEC supplied table.
Effectively there are two sets. FM and MFM and the chip works differently
for both. It's tied to FM allowing for gaps as short as 8bytes and MFM
16bytes. The length of gaps are related to mode FM having more flux
transistions than MFM per bit and that most analog PLLs have a minimum
number of transistions (time) they need to aquire. Obviously the gaps
are made as long as possible allowing for the sectors containing data.
Since sector length is variable gaps will be. FYI: due to waste longer
sectors can end up with very long gaps.
>Using the IBM System 3740 (FM) and System 34 (MFM) disk format specifications,
>I tried working the NEC tables backward to get the "number of available bytes
>on a track" which they started with. I worked it through for both 8" and 5.25"
>drives in each format type, and the problem is that the results are not
>consistant. Using a given drive type and encoding method, for each sector size,
>number of sectors/track, and format GPL values in the NEC table, I get a "total
>bytes on track" values which are quite different - within a few 100 bytes, but
>you can make them all come out much closer by adjusting the gap length.
>
>In other words, I want to do a calculation something like:
>
> Total number of bytes assumed to be available on the track
> - track overhead
> - (#sectors * per-sector overhead) [not including gap]
> - (#sectors * data bytes/sector)
> / #sectors
> = actual sector gap length (for format)
>
>However the values from the NEC table do not fit such a calculation, because
>for each sector-size/number-of-sectors in the NEC table, you work out a "total
>number of bytes assumbed to be available on the track" which is only within a
>few 100 of the value worked out for other sector-size/number-of-sectors
>combinations at the same drive type and encoding method.
Yep thats true.
>For example, if you begin with a "total number of bytes assumed to be available
>on the track" which you worked out from 512 byte sectors, and reverse the
>calculation for 1024 byte sectors, the gap length you arrive at is different
>from the one in the NEC table. Another way to look at it is that by tweaking the
>sector GPL, you can always get a "total number of bytes" which is within
>number-of-sectors/track" of the "optimim value" you were aiming for, however the
>values in the NEC table often result in "total number of bytes" values which are
>a couple of 100 away from each other.
Also you need the ECMA/ISO {ECMA-70} spec for formatting. They are somewhat
different.
The problem is that somewher in the gap there will be a splice point and
there need to be enough gap bytes written after write is enabled to insure
the new sector is roughly in the smae place as the old one.
>Unfortunately the 765 based FDC in the PC is very limiting, and does not allow me
>to read the raw format information, nor can I determine the GPL that was used on
>the original disk - the only other option is to calculate a suitable GPL based on
>the format information.
The 765 does have a read diagnostic but it's not like the 1771/1791 read track
that tried to read every byte including gaps.
>If no calculation is possible, can anyone point me at a more complete table of
>suggested GPLs? The NEC table has some large holes, for example 9x512 and 10x512
>are missing.
They are missing because the table was written before the advent of 5.25 1.2 mb
and 3.5" floppies and the 765A really doesn't do the 10x512 (it will read but
format is not possible). The latter if done with 765A ends up truncating
the gap4 badly if the drive is 2% fast. The later 7265 chip does it and
you need the spc for that.
The PC varient of the FDC is a cell based on the 765/7265 so unless there's
a raw 765 on the board you can see you need to read between the line of the
spec for THAT chip. There are subtle variations in the 765 look alikes and
Tim and I encounted some of them while doing Fcopy. The test for 765/7265
is can it recalibrate more than 77 tracks. The 765 will only recalibate a
maximum of 77 tracks, the 7265 can do up to 255. The other differnce is
the 7265 does not write gap 4a/4b at all. Gap 4a coincides with index and gap
4b is the gap written after all sectors are formatted to the end of the track
(index).
Allison
>
>Subject: Re: FDC Gap Length?
> From: shoppa_classiccmp at trailing-edge.com (Tim Shoppa)
> Date: Sun, 17 Jul 2005 08:25:30 -0400
> To: cctalk at classiccmp.org
>
>> the gap length you arrive at is different from the one in the NEC table
>> [for different sector sizes]
>
>Part of the calculation is the time it takes the data separator to re-sync
>after each gap. Now, a "true" 765 doesn't have a data separator so maybe
>they leave this out. It's also true that this number ought to be nearly
>constant depending on sector sizes.
The base 765 expected there would be some form of external data seperator
either digital or PLL. In 1981 none of the FDC chips had data speration
as it was pushing the amount of variable hardware on the chip. In later
years that was integrated into the chip.
The gap will not be the same for all sector sizes as it's it serves the
function of filling the space between sectors. The gaps are those bytes
that are accounted for in the raw and formated disk space.
>Do you have the Intel 8272 data sheet? (This was Intel's part number
>for their 765 clone. It may not just be a clone but the exact same
>mask...). IIRC there are more details/examples/math in the 8272 data
>sheet, including some recommendations for data separators and the good/bad
>of different types.
Intel is a licensed mask. Their data sheet is not any more informative
than NEC full data sheet and user manual, it may be easier to find 20+
years later. The IBM softsector floppy disk specification is the origin
point for the whole show. I may add that the later chips are 765B or
7265 and Intel never did those. The differnce on those are coupled to
gaps 4a and 4b and the index gaps. Those came into being with the
3.5" floppy.
Allison
Hi Allison,
>Is there a calculation, NO. Unless your formatting your own, then
>it's use biggest gaps that allow sector data and a resonable end gap
>on off speed drives. Most of the time you have to know how
>that disk was formatted originally to arrive at the correct values.
>Fortunatly there is a fair amount of wiggle room if you do not run
>too close (too close is below) to minimums.
I know how the disk was originally formatted to the extent that I know
the sector size and the number of sectors on the track.
I had assumed that it worked the way you described ... my problem is that
I cannot make sense of the values in the NEC supplied table.
Using the IBM System 3740 (FM) and System 34 (MFM) disk format specifications,
I tried working the NEC tables backward to get the "number of available bytes
on a track" which they started with. I worked it through for both 8" and 5.25"
drives in each format type, and the problem is that the results are not
consistant. Using a given drive type and encoding method, for each sector size,
number of sectors/track, and format GPL values in the NEC table, I get a "total
bytes on track" values which are quite different - within a few 100 bytes, but
you can make them all come out much closer by adjusting the gap length.
In other words, I want to do a calculation something like:
Total number of bytes assumed to be available on the track
- track overhead
- (#sectors * per-sector overhead) [not including gap]
- (#sectors * data bytes/sector)
/ #sectors
= actual sector gap length (for format)
However the values from the NEC table do not fit such a calculation, because
for each sector-size/number-of-sectors in the NEC table, you work out a "total
number of bytes assumbed to be available on the track" which is only within a
few 100 of the value worked out for other sector-size/number-of-sectors
combinations at the same drive type and encoding method.
For example, if you begin with a "total number of bytes assumed to be available
on the track" which you worked out from 512 byte sectors, and reverse the
calculation for 1024 byte sectors, the gap length you arrive at is different
>from the one in the NEC table. Another way to look at it is that by tweaking the
sector GPL, you can always get a "total number of bytes" which is within
number-of-sectors/track" of the "optimim value" you were aiming for, however the
values in the NEC table often result in "total number of bytes" values which are
a couple of 100 away from each other.
Unfortunately the 765 based FDC in the PC is very limiting, and does not allow me
to read the raw format information, nor can I determine the GPL that was used on
the original disk - the only other option is to calculate a suitable GPL based on
the format information.
If no calculation is possible, can anyone point me at a more complete table of
suggested GPLs? The NEC table has some large holes, for example 9x512 and 10x512
are missing.
Regards,
Dave
--
dave04a (at) Dave Dunfield
dunfield (dot) Firmware development services & tools: www.dunfield.com
com Collector of vintage computing equipment:
http://www.parse.com/~ddunfield/museum/index.html
