From Newsgroup: comp.sys.cbm
Hi Thomas !
a) You mention to "Clear the Clock-Line, set the Data-Line and wait for
about 754 cycles of a 6510 processor" when sending under ATN. For me this >sounds like "releasing clk (= low) and setting data (= high)". Then I wait >for 754 cycles.
Yes, this is what the C64 does, before it sends a byte with ATN low
(= command). You can have a look at adress $ED36 in the C64 Kernel
Rom. I decided to do the same as the C64 does, and it works ...
Be careful with "release". By release, I always mean, set the line
voltage to 5V. If a bus is "active low", like our C64 bus, releasing a
line means, that you set the line level to 5V. By "clear" i always
mean, set the line voltage to 0V and by "set" i mean set it to 5V.
By "pull down" i mean, set the voltage to 0V.
After this, what happens to clk and data?
After this, you can send a byte just as if it was a normal byte. Just
keep the ATN line pulled down (0V = low). The rest is like this:
1. Release the data line (set it to 5V) (well, we have already done
this 754 cycles earlier, but the normal byte send routine does it
again, so we do it again, too ...)
2. After this, test if the data line is pulled down (is it 0V ?). If
no, the device is not present. This is Phase (1) in my diagram.
from now on, do the same as a C64 would do. I have described
all details in the little picture on my page ... all these phases, you
know :-)
I thought
releasing clk signals data transfer to the 1541
You are the TALKER. So you have to set the line level of the
CLK line to 5V to signal, that a byte will be sent. This is what I
call "release". (we have set it to 0V a little while ago, so this
will lead to a change in line level from 0V to 5V) This is the end
of phase 1 in my diagram.
- my code looks like this:
/*
* Sending under atn?
*/
if (bit_set(flags, X_ATN))
{
this->set(X_ATN);
this->release(X_CLK);
this->set(X_DATA);
/*
* Wait 748 cycles
*/
cdelay(0x2ec);
}
/*
* Test data line
*/
this->set(X_DATA);
cdelay(0x16);
if (!this->get(X_DATA)) return (X_NO_DEV);
cdelay(0x12);
/*
* Release clk
*/
this->release(X_CLK);
cdelay(0x25);
/*
* Wait for floppy to release data
*/
while (this->get(X_DATA));
cdelay(0x10);
Actually, the 1541 does not release data (I think due to the released clk >before...). Did I forget something???
puh ...
this->set(X_ATN); should result in 0V on the ATN line !!!! this->release(X_CLK); should result in 0V on the CLK line this->set(X_DATA); should result in 5V on the DATA line
Don't forget: Sending a byte under ATN does mean that the ATN line
level is 0V while you send. I think you are setting it to 5V, which
means you don't send a command byte, but a normal byte.
this->set(X_DATA): should again set the voltage to 5V
cdelay(0x16): just a delay.
if (!this->get(X_DATA)) return (X_NO_DEV);
you should return X_NO_DEV, if the DATA line level is 5V.
So, your get routine must return TRUE if the line level is 0V. But i
guess it returns TRUE if the line level is 5V ??!!
I think your logic could be wrong, but this depends on what your get
routine will return in case of a 0V or a 5V.
here is the Version, if 5V = TRUE: and the line level is 5V (which
means device not present)
if (!this->get(X_DATA)) return (X_NO_DEV);
same as
if (!TRUE) return (X_NO_DEV);
same as
if (!5V) return (X_NO_DEV);
same as
if (0V) return (X_NO_DEV);
so this would be wrong .....please double check your GET routine :-)
b) What is the "initial" serial bus setup?
All lines have to be set to 5V by all devices. A 0V level means that
there is some talking going on on the bus.
Clk and data low, atn and reset
high?
No, all lines are 5V
I read some source code from cbm4linux, seems like they are releasing >everything but clk.
CLK must be pulled down when ATN is pulled down. A state transition
from 0V to 5V signals the listening devices, that a byte will be sent.
There are some other lpt lines like BIDIR and IRQ, what
about them?
I never heard about them, I have only had a look at the C64 serial
bus. My transfer is not based on a parallel cable ...
Kroko.
BTW.: You could get some serious timing trouble in an operating
system like windows XP, because any delays while sending the byte
could lead to transmission errors or wrong interpretations of the
signals. For example a EOI could accidentaly be sent, where no EOI
should be sent, just because your code is not called when it should
be.
--- Synchronet 3.18b-Win32 NewsLink 1.113