Mega STe specifics

Troubles with your machine? Just want to speak about the latest improvements? This is the place!

Moderators: Mug UK, Zorro 2, Greenious, spiny, Moderator Team

ijor
Hardware Guru
Hardware Guru
Posts: 2904
Joined: Sat May 29, 2004 7:52 pm
Contact:

Mega STe specifics

Postby ijor » Mon Aug 16, 2004 4:24 pm

Hi,

I would like some information about was new at the hardware level in this model (Mega STe). Specifically, I am very interested in getting some information about the FDC (Floppy Disk Controller). I understand the Mega STe supports HD floppies. This means it should have a different FDC than earliers STs models.

Thanks

User avatar
Greenious
Hardware Guru
Hardware Guru
Posts: 987
Joined: Sat Apr 24, 2004 5:39 pm
Location: Sweden

Postby Greenious » Mon Aug 16, 2004 11:35 pm

Actually, a Mega STE is very much similar to the standard STE, they actually use the very same customchips aswell.

However, the Mega STE has some extras...
Apart from the obvious bit with separate keyboard etc...
The most notable is the 16 MHz with cache CPU. (Of course you can turn it off and run in a 100% compatible 8 MHz non-cache mode)
VME bus, for graphiccards and such.
Optional math co-processor. (Compatible with the FPU card for Mega ST)
Optional HD floppy
Optional built in harddrive
Extra serial ports
LAN port (similar to appletalk)
TOS 2.06 (2.05 on older machines)

Now, when it comes to the HD Floppy. Atari didn't really do much to implement it. TOS already can read & write HD floppies. The only thing they added in TOS 2 was the ability to format them. As for the hardware, atari implemented a $2 circuit that detected what kind of floppy was in the drive, and either fed 8 MHz (DD floppy) or 16 MHz (HD floppy) to the floppy disk controller (FDC).

Now, the standard FDC that comes in any ST(E) in many cases are able to work in 16 MHz as required to handle HD floppies, but to be sure, Atari manufactured a "new" FDC with higher quality, that they named "ajax".

So, the FDC used was basically the same.

ijor
Hardware Guru
Hardware Guru
Posts: 2904
Joined: Sat May 29, 2004 7:52 pm
Contact:

Postby ijor » Tue Aug 17, 2004 12:31 am

Greenious wrote:As for the hardware, atari implemented a $2 circuit that detected what kind of floppy was in the drive, and either fed 8 MHz (DD floppy) or 16 MHz (HD floppy) to the floppy disk controller (FDC).

Now, the standard FDC that comes in any ST(E) in many cases are able to work in 16 MHz as required to handle HD floppies, but to be sure, Atari manufactured a "new" FDC with higher quality, that they named "ajax".

So, the FDC used was basically the same.


Thanks Greenious, very interesting info. I have some question on this:


Do you know how that HD disk detection circuit worked?
How exactly the FDC clock is changed, automatically by that circuit or the software has some control over it ?

What do you mean by Atari manufactured the Ajax? Did Atari licensed the mask from Western Digital or they just ordered from WD a special version more tolerant to over-clocking?

BTW, overclocking the FDC is a dirty hack. Writing won’t be optimal because some timings should be the same in both densities. But on the other hand, it would be very difficult to implement a true DD-HD solution and yet don’t break compatibility with older software.

User avatar
Greenious
Hardware Guru
Hardware Guru
Posts: 987
Joined: Sat Apr 24, 2004 5:39 pm
Location: Sweden

Postby Greenious » Tue Aug 17, 2004 9:09 am

ijor wrote:Thanks Greenious, very interesting info. I have some question on this:


Do you know how that HD disk detection circuit worked?
How exactly the FDC clock is changed, automatically by that circuit or the software has some control over it ?


Automatically. It requires the floppy to output a media detect signal on pin 2 I believe. If the floppy signals that a HD Floppy is present, the clock changes from 8 to 16 MHz.

ijor wrote:What do you mean by Atari manufactured the Ajax? Did Atari licensed the mask from Western Digital or they just ordered from WD a special version more tolerant to over-clocking?


The circumstances around it I don't know. But afaik Atari has never owned a factory for manufacturing IC chips, atleast not during the ST years. They once had an assembly factory in Taiwan I think, which they later sold for a hefty sum of money, but never an IC plant.

ijor wrote:BTW, overclocking the FDC is a dirty hack. Writing won’t be optimal because some timings should be the same in both densities. But on the other hand, it would be very difficult to implement a true DD-HD solution and yet don’t break compatibility with older software.


I don't know if it is dirty. But I've had a HD floppy in my Atari for many years, and never experienced any problems with it, not even when using a FDC that wasn't certified for 16 MHz. It was also for many years the only way I had to transfer files between Atari & PC, so I think the method is safe enough.

User avatar
PaulB
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2168
Joined: Tue Jun 11, 2002 10:56 pm
Location: You Kay

Postby PaulB » Tue Aug 17, 2004 9:41 am

For a HD floppy drive solution for all Atari's see this site:

http://www.cps-electronics.co.uk/

Paul.

ijor
Hardware Guru
Hardware Guru
Posts: 2904
Joined: Sat May 29, 2004 7:52 pm
Contact:

Postby ijor » Tue Aug 17, 2004 4:06 pm

Greenious wrote:
ijor wrote:BTW, overclocking the FDC is a dirty hack.


I don't know if it is dirty. But I've had a HD floppy in my Atari for many years, and never experienced any problems with it


It might be a semantic issue if it is dirty or not, but it is not optimal. As said, some timings should not change, or at least should not be halved at HD.

For example, write precompensation will be far from optimum. Of course it will still work, it would work even without precompensation. This doesn't mean it is very good. It just means that the quality of the recording would be lower. And that the chances for data loss over time are increased.

User avatar
PaulB
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2168
Joined: Tue Jun 11, 2002 10:56 pm
Location: You Kay

Postby PaulB » Tue Aug 17, 2004 9:40 pm

But with my Mega Ste (tos 2.05), the high density disk drive is supported as native (built into hardware) so surely that would not affect anything? So far everything has worked perfectly and the drive i have recognises 720k disk too, including any game disk i have thrown at it. The only probs i have found are 16mhhz with cache an 16 mhz and no cache doesn't always work with games (even ste games). If i find these probs i switch to 8mhz for compatibility. If that doesn't work i use seltos to load TOS 1.02 which is compatible with most, if not all of the Atari games that are available.

Paul.

ijor
Hardware Guru
Hardware Guru
Posts: 2904
Joined: Sat May 29, 2004 7:52 pm
Contact:

Postby ijor » Wed Aug 18, 2004 12:12 am

PaulB wrote:But with my Mega Ste (tos 2.05), the high density disk drive is supported as native (built into hardware) so surely that would not affect anything?


Why are so sure? Just because it is a factory design it doesn't mean it is flawless.

So far everything has worked perfectly ...


As said, it would work for everyday use. The problems are only likely to appear in the long term. And again, you might not find any problems. You are just increasing the chances of data loss and corruptions.

And btw, nobody can blame Atari for this design. It would have been extremelly difficult to achieve backwards compatibility without some sort of hack one way or the other.

simbo

Postby simbo » Fri Aug 20, 2004 9:26 pm

if you speed up a controller all your doing is increasing the data rate of either the program core it runs using or the firmware hardwired program for the chip


so speeding up the clock is fine

as tos 2.06 supports hd drives in o/s firmware this method is perfect

just to switch the clock on a detect line
is just exactly what would have been added by atari like the falcon

so... .. i recomend you just add

http://atari4ever.free.fr/hardware/zip/hdswch98.zip


this


it is very cheep and easy to make on hobby vero board {strip board if your a yank}

for about 5 quid
and a new floppy out of an old 486 / p1 build
i tend to look for compaq systems as these have a drive that you can click the old atari button onto and also fit better without cutting it to bits
as they have no front anyway

{basicaly the older the better modern drives have some compatability stripped out ...and now use software core micros instead of a complex controller}



BUT !!!!!!!

This modification is unnecessary for the MegaSTE, TT, and Falcon, because
they can already deal with HD floppies "from factory".
In order to use HD floppies you MUST have a 1.44MB (sometimes referred to
as 2Mb) diskdrive. The old SF314 won't do the job. Teac's FD235HF-drives
are suitable, as is Sony's model MPF520-1. There are other drives too, but
I can't name them all here.




so plug in a 1.44 and stop ranting 8O

ijor
Hardware Guru
Hardware Guru
Posts: 2904
Joined: Sat May 29, 2004 7:52 pm
Contact:

Postby ijor » Fri Aug 20, 2004 9:44 pm

simbo wrote:if you speed up a controller all your doing is increasing the data rate of either the program core it runs using or the firmware hardwired program for the chip

so speeding up the clock is fine


It is not. By doubling the FDC clock you aren’t just doubling the data rate, you are doubling every single process of the FDC. Or in other words, you are halving all the timings.

An FDC with built-in HD support does NOT work like this, it has independent clocks. Some timings are in direct relation to the bit-rate. Some depend on the bit-rate but not in a direct one to one relation. And some other timings are constant disregarding the bit-rate.

Specifically, the write precompensation time at HD should NOT be half of the DD one.

ijor
Hardware Guru
Hardware Guru
Posts: 2904
Joined: Sat May 29, 2004 7:52 pm
Contact:

Postby ijor » Sat Aug 21, 2004 2:57 am

I wanted to clarify that this is more a theoretical issue than a practical one.

The effects of using a non-optimal precompensation setting won’t likely appear in the short term. It is just decreasing the average life-time of the recorded data. But today, I guess nobody will use floppies for long term storage anyway.

Reading HD should not be a problem, any differences in the timing shouldn’t have any practical significance.

So I don’t see anything wrong in using HD drives on newer models, or installing HD mods for older models. Just be aware that this is a hack and the implied limitations.

simbo

Postby simbo » Sat Aug 21, 2004 10:52 am

ijor wrote:
simbo wrote:if you speed up a controller all your doing is increasing the data rate of either the program core it runs using or the firmware hardwired program for the chip

so speeding up the clock is fine


It is not. By doubling the FDC clock you arenÂ’t just doubling the data rate, you are doubling every single process of the FDC. Or in other words, you are halving all the timings.

An FDC with built-in HD support does NOT work like this, it has independent clocks. Some timings are in direct relation to the bit-rate. Some depend on the bit-rate but not in a direct one to one relation. And some other timings are constant disregarding the bit-rate.

Specifically, the write precompensation time at HD should NOT be half of the DD one.






look man
it dosnt matter if you double the punny timing clock of any chip in the same situation

it just demands data faster actualy three times faster

so the timings WONT be affected if the data can be easily supplied fast enought and in the correct format

tos2.06 deals with this part

it is exactly the method employed by subsiquent models
with very little change to the setup

write precompensation is a trate of hard disk drives and this part of atari is controlled via the dma controller not the fdc controller
this chip provides its own timings
{for handshake with the floppy controler in the drive}
its this controller
in the drive that deals with floppy writes precomp etc

now youll tell us that this is wrong i suppose???

appart from the fact someone so knowlageable about atari chooses to post a please help me understand notice
i am at a loss as to why you choose to ask us and then tell us that its all wrong,
since 1985 {prob 1983} as far back as i can remember
people have been placing clock doublers
with the floppy disk controller

and beleve it or not they all get the same result

it works as expected right back to guys modifying extracted tos images
to add support

if you tighten the "clock" of a chip
it DOSNT mean that command timings will change

ATALL any commands the fdc needs are supplied as data anyway


to avoid further posts on this poorly choosen topic to argue about

im gona lock this topic {ill leave it open for more retort on this important topic :roll: }

as it gains nothing to re-invent the wheel

surpase to add that if you want more information about atari hardware
study the circuit diagrams and detailed explinations of each hardware unit function
youll find heeps of readme's and explins in the ftp servers where stuff for atari lives there are plenty in a multitude of language


a good indication that a system works as expected is
this

quite simple
i have repaired thousands of these machines and there ilk
and never has someone moaned so much about the floppy controller


i bet your atari uses a duff controller chip
model WD1772-ph this chip actualy has a flaw
so needs replaced with an ITT varient

it may connect to the asci port but only as part of the dma bus
i could see your point if both hdd and floppy were used at the same time

but this is imposible anyway


however put this mod is fine and works 100%
with any amount of hdd also attached

i know guys who have used this for music from day one and never complain
and if they dont you know it works

appart from this your a lucky swine with a mega ste so dont complain
you just need to plg in a 1.44mb drive into your
{exactly the same set up as re- engineered st series with hd floppy fitted }
fdc running at 16 mhz /32mhz switched


you may be interested in how to enable high density in your mega

http://atari4ever.free.fr/hardware/docs.html
youll find the schematic here
{a tip is to use paint shop pro and change each image to grayscale {there is a choise to do this in the menus somewhere}
then save them as jpgs's}

if you look at pcx6 {page 6} youll find the fdc and dma controllers
youll also find there is a GAL supplied the clock to the fdc

this gal takes its commands from the switch block and tos2.06 via the bus

and so is the hd/dd switch software block enable that clock doubles as hd disks are detected

a gal is a gate array logic lattice that has a small core program mostly used as some form of finite state machine or basicaly a primative microcontroller for use in repetative switching systems
whos timings need to be event driven
so the dip switch 7 will just switch on the switch over circuit

so your dd factory fitted drive dosnt sound like a paper shreader chewing a phone directory



8)
You do not have the required permissions to view the files attached to this post.
Last edited by simbo on Sat Aug 21, 2004 12:43 pm, edited 3 times in total.

simbo

Postby simbo » Sat Aug 21, 2004 12:20 pm

Greenious wrote:.......
--------------------------



Aargh! You locked the topic while I was writing a reply!
---------------------------------------------------------------



ijor wrote:
It is not. By doubling the FDC clock you arenÂ’t just doubling the data rate, you are doubling every single process of the FDC. Or in other words, you are halving all the timings.

An FDC with built-in HD support does NOT work like this, it has independent clocks. Some timings are in direct relation to the bit-rate. Some depend on the bit-rate but not in a direct one to one relation. And some other timings are constant disregarding the bit-rate.

Specifically, the write precompensation time at HD should NOT be half of the DD one.


I think you are mixing apples & pears here, or you don't fully understand what write precompensation does.

The only timing problem that arises from changing the clock to the FDC is the steprate. Since most floppys has a 3 ms steprate, doubling the clockfrequency makes the FDC expect a 1.5ms steprate. In practice, it will make your floppy make a lot of noise when changing tracks, but other than that it will still work. There is a small program that changes the steprate to 6ms (or back to 3ms when in 16 MHz mode).

Write precompensation is another thing. And to fully understand it, I'll make a short explanation of what it does, and how the FDC handles it, and you will see that it is not a problem.

Write precompensation is used on the innermost tracks on a floppy. The reason is that the shorter tracklength forces the FDC to pack the bits a little bit more denser than on the outer tracks. By delaying or advancing the bitstream according to certain set rules, maximum distance is put between bits that can have a negative, i.e. destructive, effect on eachother, so that a "bit-shift" doesn't occur. (one bit changing the polarity of the one next to it)

Precompensation is 1/8 of a cycle. Regardless of working in single density, double density or high density. (Cycle in this case refers to the current bit-length. 3ms for DD, 1.5ms for HD.)

Now, if precompensation was not relative to the speed you're currently working in, 1/8 of a cycle in single density mode, would represent 2/8 (1/4) of one cycle in DD mode, 4/8 or 1/2 the bitlenght of HD mode, or even 1 full cycle in ED (2.88 floppy) mode, you don't have to be Einstein to figure out what a mess that would make of the data.

The conclusion is...

The underlying bit format of all floppys, even 5.25", is the same. The only thing that does differ between the different formats is the density. And to remain compatible with previous generations (why change a working concept?), the only thing that changes is density, that doubles every time. Cutting timing (and bitlength) in half every time. So in practice, the timings and bitlenghts, relatively speaking (as Einstein once put it), remains the same.

So, after investigating your claims... You are wrong. doubling the clock is the exact right thing to do!

Sources:
ST Diskdrives: Inside and Out (Abacus)
WD1772 datasheet
Various internetsites

:?

simbo

Postby simbo » Sat Aug 21, 2004 12:37 pm

its saterday after friday and im a bit short tempered i was told...

so.... im sorry in advance if i was short ..... :cry:

User avatar
Greenious
Hardware Guru
Hardware Guru
Posts: 987
Joined: Sat Apr 24, 2004 5:39 pm
Location: Sweden

Postby Greenious » Sat Aug 21, 2004 2:00 pm

Thanks simbo for posting my reply.

But it seems I read my datasheets a little bit too fast and mixed a few apples & pears myself. :)

Anyway, forget the references to single density. It is a misleading name on a definition for an entirely different ENCODING method (FM) of older floppys that is long gone today, rather than a definition of how much data a floppy holds. (Apparantly a pre-5.25" floppy thing)

All "modern" floppys use the double density ENCODING format (MFM), and the high density format (ie 1.44mb floppy), is infact still using double density (MFM), but at a higher data-rate.

However, disregarding my ranting about single/double density above, the conclusion is still valid. I did some searching, and found out that the write precompensation (that is 125ns for a 720kb floppy), is about 1/4 on a 2.88mb floppy (or 40 ns). Seems natural to me that write precompensation on a 1.44mb floppy should be half of that of a 720kb floppy (67,5ns), or that it atleast shouldn't be a problem, although I've seen some references to 1.44mb format also using 125ns write precompensation.

Also, to further confuse things...
Write precompensation is more about putting a smaller distance between bits that repell eachother, than a greater distance between bits that attract eachother, which I implied above.

I think this concludes my findings. :)

ijor
Hardware Guru
Hardware Guru
Posts: 2904
Joined: Sat May 29, 2004 7:52 pm
Contact:

Postby ijor » Sat Aug 21, 2004 5:22 pm

Simbo wrote:appart from the fact someone so knowlageable about atari chooses to post a please help me understand notice
i am at a loss as to why you choose to ask us and then tell us that its all wrong,


I had no idea how the Mega STe and later models support HD drives. That’s what I was asking.

What I am arguing is not specific to any Atari model, neither about Atari at all. It is a generic issue about the problems related to hacking a DD FDC to use it for HD disks.

So what I was asking was one thing, and what I am arguing is another.

Simbo wrote:write precompensation is a trate of hard disk drives and this part of atari is controlled via the dma controller not the fdc controller
this chip provides its own timings
{for handshake with the floppy controler in the drive}
its this controller in the drive that deals with floppy writes precomp etc

now youll tell us that this is wrong i suppose???


Yes, I am afraid everything in that quote is wrong. Write precompensation is not exclusive to hard disks, it is used in floppies as well. The DMA chip has nothing to do with this. Write precompensation has no relation to the handshake with the controller. And no, it is not performed by the floppy drive electronics.

a good indication that a system works as expected is
this quite simple


I never said it will not work. Actually, I said from my first post that this should work. It is just producing a recording with a lower quality. Which would only likely affect data on the long term.

to avoid further posts on this poorly choosen topic to argue about
im gona lock this topic {ill leave it open for more retort on this important topic }


Sorry if we have degenerated the topic to a slightly different issue. But they are both closely related.

ijor
Hardware Guru
Hardware Guru
Posts: 2904
Joined: Sat May 29, 2004 7:52 pm
Contact:

Postby ijor » Sat Aug 21, 2004 5:25 pm

Greenious wrote:Write precompensation is used on the innermost tracks on a floppy


No, on 3.5 and smaller floppies write precompensation is used on all the tracks. The distinction between outermost and innermost tracks is usually only done on bigger (5.25) floppies.

Precompensation is 1/8 of a cycle. Regardless of working in single density, double density or high density. (Cycle in this case refers to the current bit-length. 3ms for DD, 1.5ms for HD.)


Precompensation is NOT 1/8 of the bit time, is much smaller. And those numbers are not the bit time for any density. They are not even close (don’t know where you got those numbers). And precompensation is normally not used at all in single density.

Now, if precompensation was not relative to the speed you're currently working in, 1/8 of a cycle in single density mode, would represent 2/8 (1/4) of one cycle in DD mode, 4/8 or 1/2 the bitlenght of HD mode, or even 1 full cycle in ED (2.88 floppy) mode, you don't have to be Einstein to figure out what a mess that would make of the data.


Precompensation time has some relation to the bit-rate. It doesn’t have a direct one.

The underlying bit format of all floppys, even 5.25", is the same. The only thing that does differ between the different formats is the density. And to remain compatible with previous generations (why change a working concept?), the only thing that changes is density, that doubles every time


This has nothing to do with precompensation, but it is also wrong. The format (actually, the encoding) is not always the same. Single density uses FM, double density is MFM, and some newer floppies use other encoding and sometimes even different recording techniques (perpendicular recording).

Seems natural to me that write precompensation on a 1.44mb floppy should be half of that of a 720kb floppy (67,5ns)


I don’t know why you say it should be natural. The optimal precompensation values are obtained by long empirical tests. It is not something that you could conclude just by a natural judgement.

although I've seen some references to 1.44mb format also using 125ns write precompensation.


Oh, so you finally investigated and found out that I was right. Yes, precompensation on HD disks should use the same precompensation time than DD disks. Actually, it could be a little smaller as is used in some systems. But using half the period of DD (62.5 ns) is certainly out of specs.

Write precompensation is more about putting a smaller distance between bits that repell eachother, than a greater distance between bits that attract eachother, which I implied above.


It is actually both of them. Although it is not exactly bits because the bits are encoded before being recorded.

simbo

Postby simbo » Sat Aug 21, 2004 5:37 pm

i still maintain that write precompensation is used mostly with hard disks as its a setting that can be changed by software more easily in there domain via dma

but in floppy land it is a hardware entity to distance
the very problems you mention to just one controller chip
the controller mounted on the floppy drive its self
not the fdc chip in the atari it is just for data interchange and has a limited stack etc .... fifo and a few registers

later ide drives do all this in the controller but scsi dosnt it needs this data also from its controller chip but this can only be adjusted at format time
for setting the interleave and this info is stored in the boot record and other tables

floppy's on the other hand cannot be low level formated so the interleave is set by sector insectors per cluster blocks

there is no such thing as two identical formated hard disk drives even if they are the same maker time of manufacture and match together
but a floppy is much like a floppy if formated the same

with floppies only at format time is the original factory format
" recreated "{stomped down} like a worn line in the field that grows over as a building falls from use
then the building slowly decays and the path grows over

then restoration wave a magic wand
knock the house down and replace/render it
and they start tramping the path again

same symantics as housebuilding
and the same worn paths

but format is format and anyway i am not interested mine buzzies goes thunk thunk thunk and loads data

:roll: im just sad we are all arguing about a fdc issue i have never seen any posts about appart form how to do it

better wait till the football starts fully up again


a better idea is for someone to write
a crc kernel that sits in the spare space on a floppy
so this can be used to prempt problems in the disk


i think this is a good method to preserve data

anyway you need precharge memory architecture to use this setting extensivly
atari architecture dosnt support adjustment of precompensation even the hdd system has trouble with some settings becouse it is asci not scsi

ijor
Hardware Guru
Hardware Guru
Posts: 2904
Joined: Sat May 29, 2004 7:52 pm
Contact:

Postby ijor » Sat Aug 21, 2004 6:29 pm

simbo wrote:i still maintain that write precompensation is used mostly with hard disks as its a setting that can be changed by software more easily in there domain via dma


I sent you a PM.

simbo

Postby simbo » Sat Aug 21, 2004 6:46 pm

i answered your pm

as a point

if this hack is dirty
what about the ps2 series of hacks for the cd drive logic control

???
would you concider this a dirty hack :mrgreen:
and can you let us know

???? :? what to connect and where in the atari to correct our error :P

then we can try it and see if it makes one iota of a differance
if any....

and can we have charts and stats to show the error in black and white


http://homepages.tesco.net/~rainstorm/fdc-combined.htm


P = Write precompensation
0 = Enable write precompensation
1 = Disable write precompensation


so..... when a register i/o supplied data to a controller over the bus
via dma
it will clock the register as a strobe
in this time each port pin /io has a preset time called its glitch

infact as pointed out the data rate dosnt change only the density used

so even if the datarate did change
this stobe effect from the dma controller ensures the correct data pulses are supplied at exactly the right time

to double the clock is perfect

i would always use personaly a pair of exorgates

and not a xtal source ..... as this can cause packet loss

schematic attached



defragmentation programs use this data and adjustment to write efficient contiguious data to any disk type even floppys can be defraged and should be

it can be toggled but the mode is off or on
and as per the speed of the motor and the sync between track info and the read head position is maintained
this adjustment isnt that crytical as it always will be symetrical even if the data rate changes
as its a hardware encoded bilateral adjustment in head position relative to speed that encodes the sector in sector traffic


a usefull link if you decide too
shows write precomp adjustments in and around the controller :P

please :idea: :roll:

i could write a dll in a few hours to fully simulate this chip

http://www.poppyfields.net/acorn/tech/1770.shtml

if you view this url
youll see that the command set

Command summary
===============

Command register bits
Type Command 7 6 5 4 3 2 1 0
-------------------------------------------------------
I Restore 0 0 0 0 h v r1 r0
I Seek 0 0 0 1 h v r1 r0
I Step 0 0 1 u h v r1 r0
I Step in 0 1 0 u h v r1 r0
I Step out 0 1 1 u h v r1 r0
II Read sector 1 0 0 m h/s e 0/c 0
II Write sector 1 0 1 m h/s e p/c a << here bit 1
III Read address 1 1 0 0 h/0 e 0 0
III Read track 1 1 1 0 h/0 e 0 0
III Write track 1 1 1 1 h/0 e p/0 0 <<< here bit 1
IV Force interrupt 1 1 0 1 i3 i2 i1 i0


is the only place a run the precompression algurithm in the floppy disk controller


so... given this and the fact the data rate
{frequency in baud} i think 19600 if i remember
} dosnt change

only the mark ratio of the controller data relative to the clock that runs the routines

this chip has

1} adjustment in hardware for this function and also the algurithm used is preset by mode
2} a control word that has a simple enable and disable clocked at the same times as other command data so preserving sync
3} only and enable disable no adjustment other than subble data rate via the clock can be made


and its back to nearly the very first post i made on the forum about a centralised clock bocken out single clocks

as the machine runs far better

using an inverter and a dip switch you can also step the clocks phase

with other logic you could adjust the phase of each output and this would have a benifit as well as each chip getting exactly the same clocks at the right times
or you can rotate the phase at 4mhz have you ever done this ?????

or ramp it from 0 - 16




so i think this is the point

that if the control word and data sync with the floppy its self then there is little or no need to even think of adjuting a hardware algiurith encoded controller made by western digital
to a comand set data driven
sync time parallel serial input output controller

that according to the data sheet is good to 32 mhz using a heatsink

and military hardened ones are good to 50mhz for the more elusive ones 75mhz and have 2.88 support in hardware also if you look at the command set youll see this


in this schematic the chip i used are good to 20mhz or lots more {most to 50mhz} and have a glitch threshold of about 100ns from
D to Q

so are fine for the task
and will give a nice square wave output sufficient for the task

some gates in the device are spent
there i and o should be connected to gnd via 10k resistors

i think this is a more symetrical clock doubler than dodge xtals and is the only thing you said i agree with
You do not have the required permissions to view the files attached to this post.


Social Media

     

Return to “Hardware”

Who is online

Users browsing this forum: No registered users and 4 guests