From Newsgroup: comp.sys.cbm

hmm, my ATN code is more like a frame: X_ATN_INIT before the first byte and >X_ATN_DEINIT after the last one. So it is sent as (LISTEN + address, >X_ATN_INIT) and (SECONDARY, X_ATN_DEINIT) so ATN won't go high between them.

its not only ATN, it is

set (atn)
set (clk)
release (data)
wait for 748 cycles

that has to be done before each byte under ATN. So
keeping ATN at 0V is not enough you have to run into
this "if satement" twice.

Kroko.

--- Synchronet 3.18b-Win32 NewsLink 1.113

From Newsgroup: comp.sys.cbm

Isn't this phase 4 of your diagram? It is there more than once...

sorry it was late last night .. you are right, its there more than
once, so forget what I said before ...

Kroko.

--- Synchronet 3.18b-Win32 NewsLink 1.113

From Newsgroup: comp.sys.cbm

send 0x29 (LISTEN + id)

stupid question: are you sure that your floppy is
device 9 ? usually it is 8, isn't it ?

Kroko

--- Synchronet 3.18b-Win32 NewsLink 1.113

From Newsgroup: comp.sys.cbm

send 0x29 (LISTEN + id)

send LISTEN to drive 9 (should be ok if it is really drive 9)

0xff (OPEN + secondary channel 0x0f)

send SECLISTEN: can you explain why you send $FF ? if you want to load
the directory I would suggest you use $60 as secondary address.

$

FILENAME : ok.

0x3f (UNLISTEN)

UNLISTEN: ok.

so far so good :-) Go on like this:
send TALK
sen SECTALK
receive data until EOF
send UNTALK
CLOSE_FILE

I have started to explain the serial protocol at my website.
Maybe it will help you a little: http://www.bitcity.de/theory.htm

Kroko
--- Synchronet 3.18b-Win32 NewsLink 1.113

From Newsgroup: comp.sys.cbm

Thanks, I'll have a look at your page!
Btw, my 1581 is dev. 8 and the 1541 is dev. 9. It seems my send routine is pretty much screwed up, although I don't understand why it seemed to work...
I think my documentation isn't that good.

send 0x29 (LISTEN + id)

send LISTEN to drive 9 (should be ok if it is really drive 9)

0xff (OPEN + secondary channel 0x0f)

send SECLISTEN: can you explain why you send $FF ? if you want to load
the directory I would suggest you use $60 as secondary address.

$

FILENAME : ok.

0x3f (UNLISTEN)

UNLISTEN: ok.

so far so good :-) Go on like this:
send TALK
sen SECTALK
receive data until EOF
send UNTALK
CLOSE_FILE

I have started to explain the serial protocol at my website.
Maybe it will help you a little: http://www.bitcity.de/theory.htm

Kroko

--- Synchronet 3.18b-Win32 NewsLink 1.113

From Newsgroup: comp.sys.cbm

Now I remember where I got that with the lines high: it's described in the COMPUTE! article by Jim Butterfield... he wrote both lines are initially
high


"Thomas M�ller" <eous@gmx.de> schrieb im Newsbeitrag news:beh221$8fg$1@newsreader2.netcologne.de...

@Kroko: After reviewing my line outputs, it seems all my line settings are upside-down since you write on your page that DATA high means device not present error (in my code it was DATA low). The bit setup looked correct (DATA high for bit set, DATA low for bit not set). Anyway I wonder why it seemed the 1541 accepted the bytes sent under ATN...

"Thomas M�ller" <eous@gmx.de> schrieb im Newsbeitrag news:befikf$dru$1@newsreader2.netcologne.de...

Thanks, I'll have a look at your page!
Btw, my 1581 is dev. 8 and the 1541 is dev. 9. It seems my send routine

is

pretty much screwed up, although I don't understand why it seemed to

work...

I think my documentation isn't that good.

send 0x29 (LISTEN + id)

send LISTEN to drive 9 (should be ok if it is really drive 9)

0xff (OPEN + secondary channel 0x0f)

send SECLISTEN: can you explain why you send $FF ? if you want to load the directory I would suggest you use $60 as secondary address.

$

FILENAME : ok.

0x3f (UNLISTEN)

UNLISTEN: ok.

so far so good :-) Go on like this:
send TALK
sen SECTALK
receive data until EOF
send UNTALK
CLOSE_FILE

I have started to explain the serial protocol at my website.
Maybe it will help you a little: http://www.bitcity.de/theory.htm

Kroko

--- Synchronet 3.18b-Win32 NewsLink 1.113

From Newsgroup: comp.sys.cbm

Hi Thomas ...

well, at least the C64 is releasing the DATA line and then it
is testing, if DATA is low. A high DATA line at the beginning of the byte-transfer means, that there is nobody pulling it down. Thats why
the C64 thinks the device is not present.

Kroko

Now I remember where I got that with the lines high: it's described in the >COMPUTE! article by Jim Butterfield... he wrote both lines are initially
high

"Thomas M�ller" <eous@gmx.de> schrieb im Newsbeitrag >news:beh221$8fg$1@newsreader2.netcologne.de...

@Kroko: After reviewing my line outputs, it seems all my line settings are >> upside-down since you write on your page that DATA high means device not
present error (in my code it was DATA low). The bit setup looked correct
(DATA high for bit set, DATA low for bit not set). Anyway I wonder why it
seemed the 1541 accepted the bytes sent under ATN...


"Thomas M�ller" <eous@gmx.de> schrieb im Newsbeitrag
news:befikf$dru$1@newsreader2.netcologne.de...

Thanks, I'll have a look at your page!
Btw, my 1581 is dev. 8 and the 1541 is dev. 9. It seems my send routine >is
pretty much screwed up, although I don't understand why it seemed to

work...

I think my documentation isn't that good.

send 0x29 (LISTEN + id)

send LISTEN to drive 9 (should be ok if it is really drive 9)

0xff (OPEN + secondary channel 0x0f)

send SECLISTEN: can you explain why you send $FF ? if you want to load >> > > the directory I would suggest you use $60 as secondary address.

$

FILENAME : ok.

0x3f (UNLISTEN)

UNLISTEN: ok.

so far so good :-) Go on like this:
send TALK
sen SECTALK
receive data until EOF
send UNTALK
CLOSE_FILE

I have started to explain the serial protocol at my website.
Maybe it will help you a little: http://www.bitcity.de/theory.htm

Kroko

--- Synchronet 3.18b-Win32 NewsLink 1.113

From Newsgroup: comp.sys.cbm

Ahhh, I just read the article by Jim Butterfield again and found this: "When
no device puts a ground on a signal line, the voltage rises to almost five volts. We call this the 'false' logic condition of the wire. If any device grounds the line, the voltage drops to zero; we call this the 'true'
condition of the line". So your explanation with HIGH and LOW means HIGH = false, LOW = true... now your's and Jim's documentation match :)
So my "screwed up function" wasn't so bad, although I still don't understand why the 1541 doesn't recognize normal bytes - maybe I should check my timings...

Thomas


"Kroko" <Kroko@Nil.COM> schrieb im Newsbeitrag news:c4uogvgg73j225h8jp7ab3tm999q49r1o0@4ax.com...

Hi Thomas ...

well, at least the C64 is releasing the DATA line and then it
is testing, if DATA is low. A high DATA line at the beginning of the byte-transfer means, that there is nobody pulling it down. Thats why
the C64 thinks the device is not present.

Kroko

Now I remember where I got that with the lines high: it's described in

the

COMPUTE! article by Jim Butterfield... he wrote both lines are initially >high

"Thomas M�ller" <eous@gmx.de> schrieb im Newsbeitrag >news:beh221$8fg$1@newsreader2.netcologne.de...

@Kroko: After reviewing my line outputs, it seems all my line settings

are

upside-down since you write on your page that DATA high means device

not

present error (in my code it was DATA low). The bit setup looked

correct

(DATA high for bit set, DATA low for bit not set). Anyway I wonder why

it

seemed the 1541 accepted the bytes sent under ATN...


"Thomas M�ller" <eous@gmx.de> schrieb im Newsbeitrag
news:befikf$dru$1@newsreader2.netcologne.de...

Thanks, I'll have a look at your page!
Btw, my 1581 is dev. 8 and the 1541 is dev. 9. It seems my send

routine

is

pretty much screwed up, although I don't understand why it seemed to

work...

I think my documentation isn't that good.

send 0x29 (LISTEN + id)

send LISTEN to drive 9 (should be ok if it is really drive 9)

0xff (OPEN + secondary channel 0x0f)

send SECLISTEN: can you explain why you send $FF ? if you want to

load

the directory I would suggest you use $60 as secondary address.

$

FILENAME : ok.

0x3f (UNLISTEN)

UNLISTEN: ok.

so far so good :-) Go on like this:
send TALK
sen SECTALK
receive data until EOF
send UNTALK
CLOSE_FILE

I have started to explain the serial protocol at my website.
Maybe it will help you a little: http://www.bitcity.de/theory.htm

Kroko

--- Synchronet 3.18b-Win32 NewsLink 1.113

From Newsgroup: comp.sys.cbm

Yo Thomas!

That project sounds very interesting! Keep up working on it, I think a LOT
of people would be interested in a native Win32 application to transfer
files!
Just one question: On which OS are you developing?

Best regards,
Stephan


--- Synchronet 3.18b-Win32 NewsLink 1.113

From Newsgroup: comp.sys.cbm

Hi Thomas,

Ahhh, I just read the article by Jim Butterfield again and found this: "When no device puts a ground on a signal line, the voltage rises to almost five volts. We call this the 'false' logic condition of the wire. If any device grounds the line, the voltage drops to zero; we call this the 'true' condition of the line". So your explanation with HIGH and LOW means HIGH = false, LOW = true...

Oh, this stuff is a major headache, isn't it? Without any electronical
testing equipment and proper documentation, _I_ spent _days_ with
experimenting to find out the meaning of 0/1, false/true and low/high
on the Commodore serial bus! 8-)

If I'm not mistaken, there are inverters on the serial bus so when you
put a 0 bit into the serial bus data register then that will result in
a high voltage on the wire. And, vice versa, a 1 bit is a low voltage.
This is, for sure, trivial for the hardware guys but not for me... ;-)

Joe Forster/STA
sta@c64.org
--- Synchronet 3.18b-Win32 NewsLink 1.113

From Newsgroup: comp.sys.cbm

Hi Stephan,

I'm developing under Windows XP Professional using MS VC++ 6. The cable is a XA1541.

Best regards,
Thomas


"Steppe" <steppe_not_for@spam_demodungeon.com> schrieb im Newsbeitrag news:3f0d09eb$1@news.nefonline.de...

Yo Thomas!

That project sounds very interesting! Keep up working on it, I think a LOT
of people would be interested in a native Win32 application to transfer files!
Just one question: On which OS are you developing?

Best regards,
Stephan

--- Synchronet 3.18b-Win32 NewsLink 1.113

From Newsgroup: comp.sys.cbm

I can add support for it, as soon as I know how to implement it :)

Thomas


"Tomaz Kac" <tomcat@sgn.net> schrieb im Newsbeitrag news:7beqgvki0rr39mmso0smv10tv73odktt5d@4ax.com...

Will this also work with XE1541 cable (the one with diodes) ?

TC

--- Synchronet 3.18b-Win32 NewsLink 1.113

From Newsgroup: comp.sys.cbm

Hi Joe,

I know what you mean. I really get confused by this TRUE/FALSE, 0/1,
high/low thing. After hours of work spent on the project, it feels like
being drunk... "Hey, wait, what was it with high/low..." - "Isn't high equal
to false?". I wouldn't wonder if the C64 kernal programmers were a bit mad nowadays :D

Thomas


"Joe Forster/STA" <sta@ludens.elte.hu> schrieb im Newsbeitrag news:O9ZijQc$LEXx@ludens...

Hi Thomas,

Ahhh, I just read the article by Jim Butterfield again and found this:

"When

no device puts a ground on a signal line, the voltage rises to almost

five

volts. We call this the 'false' logic condition of the wire. If any

device

grounds the line, the voltage drops to zero; we call this the 'true' condition of the line". So your explanation with HIGH and LOW means HIGH

=

false, LOW = true...

Oh, this stuff is a major headache, isn't it? Without any electronical testing equipment and proper documentation, _I_ spent _days_ with experimenting to find out the meaning of 0/1, false/true and low/high
on the Commodore serial bus! 8-)

If I'm not mistaken, there are inverters on the serial bus so when you
put a 0 bit into the serial bus data register then that will result in
a high voltage on the wire. And, vice versa, a 1 bit is a low voltage.
This is, for sure, trivial for the hardware guys but not for me... ;-)

Joe Forster/STA
sta@c64.org

--- Synchronet 3.18b-Win32 NewsLink 1.113

From Newsgroup: comp.sys.cbm

What makes you think C= programmers were not a little "mad" back then too ( and I don't mean angry )..... and by the way.... now-daze .... they are probably just as "mad" and designing stupid things like AOL and Ebay... God bless them "Thomas M�ller" wrote:

Hi Joe,

I know what you mean. I really get confused by this TRUE/FALSE, 0/1,
high/low thing. After hours of work spent on the project, it feels like> being drunk... "Hey, wait, what was it with high/low..." - "Isn't high equal
to false?". I wouldn't wonder if the C64 kernal programmers were a bit mad nowadays :D

Thomas

"Joe Forster/STA" <sta@ludens.elte.hu> schrieb im Newsbeitrag news:O9ZijQc$LEXx@ludens...

Hi Thomas,

Ahhh, I just read the article by Jim Butterfield again and found this:

"When

no device puts a ground on a signal line, the voltage rises to almost

five

volts. We call this the 'false' logic condition of the wire. If any

device

grounds the line, the voltage drops to zero; we call this the 'true' condition of the line". So your explanation with HIGH and LOW means HIGH

=

false, LOW = true...

Oh, this stuff is a major headache, isn't it? Without any electronical testing equipment and proper documentation, _I_ spent _days_ with experimenting to find out the meaning of 0/1, false/true and low/high> > on the Commodore serial bus! 8-)

If I'm not mistaken, there are inverters on the serial bus so when you
put a 0 bit into the serial bus data register then that will result in
a high voltage on the wire. And, vice versa, a 1 bit is a low voltage.
This is, for sure, trivial for the hardware guys but not for me... ;-)

Joe Forster/STA
sta@c64.org

--
******************************************************
3000 + C=ommodore Games, Utilities and More
now on CD from the Commie Kazez BBs collection
* Satisfaction Garanteed *
Click here for info http://users.commspeed.net/wlbbs ******************************************************
--- Synchronet 3.18b-Win32 NewsLink 1.113

From Newsgroup: comp.sys.cbm

If I'm not mistaken, there are inverters on the serial bus so when you
put a 0 bit into the serial bus data register then that will result in
a high voltage on the wire. And, vice versa, a 1 bit is a low voltage.
This is, for sure, trivial for the hardware guys but not for me... ;-)

Yes, this is important if you examine code of the 1541 or the C64,
because they both use SN7406 inverter drivers. But if you are
setting the lines from windows, there are no inverters. It really
helps a lot to think in the real line voltages that are on the bus
cables. For the serial protocol, its often hard to say, what "active"
really means. The easiest thing is to just think in line voltages. So
HIGH = 5V and LO = 0V. In most articles, 0V is called "active"
because the serial bus is "active low".

Kroko.




--- Synchronet 3.18b-Win32 NewsLink 1.113

From Newsgroup: comp.sys.cbm

Hi Kroko,

Kroko wrote:

If I'm not mistaken, there are inverters on the serial bus so when you

Yes, this is important if you examine code of the 1541 or the C64,
because they both use SN7406 inverter drivers. But if you are
setting the lines from windows, there are no inverters. It really

This is not true, I think. The LPT parallel port does contain
inverters on _some_ lines. Check out the page:

http://www.doc.ic.ac.uk/~ih/doc/par/

and you will see, that the outputs C0, C1 and C3 are inverted,
while C2 is not. Nearly the same goes for the inputs, S7 is
inverted, but S3, S4, S5 and S6 are not.

Maybe Thomas M�ller encountered some problems with this, but
I'm sure, that he knows the details of the parallel port.

helps a lot to think in the real line voltages that are on the bus
cables. For the serial protocol, its often hard to say, what "active"
really means. The easiest thing is to just think in line voltages. So
HIGH = 5V and LO = 0V. In most articles, 0V is called "active"
because the serial bus is "active low".

All you need to do is defining some makros or funtions, that
convert all logical expressions into the corresponding line
levels. Such converters are defined for each single X cable,
since some invert the signals, some don't. Some only invert
the output levels of some pins, others need special
conversions for the input pins (bitshifting and/or inverting).

All you need to do for each new interface is measuring the
output line levels and the corresponding inputs, if the
logical expression Set or isSet corresponds to a 0V level
on the IEC cable. Bitshifts are needed additionally to set
or get the correct line.

This way you need to think only once (for each cable type)
about inversions and so on. Further programming steps only
depend on the logical view then.


Take note, that I simplified it a little bit too much, because
you will need some more sophisticated makros or C++ templates
to become able to do combined sets of several lines at the
same time or working with bitmasks.


Womo

--- Synchronet 3.18b-Win32 NewsLink 1.113

From Newsgroup: comp.sys.cbm

This is not true, I think. The LPT parallel port does contain
inverters on _some_ lines. Check out the page:
Womo

ups ... you got me. I actually don't know anything about the
parallel port. It was just a guess :-)

Kroko.
--- Synchronet 3.18b-Win32 NewsLink 1.113

From Newsgroup: comp.sys.cbm

Hi,

well, I'm using the routines from cbm4linux for setting and releasing a
line, as I think they are well programmed. Every cable has a "inverter-mask" byte. So these lines which have to be inverted are inverted by this byte - I think that's easier (and maybe faster) than working with function variables. They are not too hard to understand and work with only one line of code :).

Thomas


"Kroko" <Kroko@Nil.COM> schrieb im Newsbeitrag news:p9cugvs11unb2hrjo5bempcr27f4cq73r6@4ax.com...

This is not true, I think. The LPT parallel port does contain
inverters on _some_ lines. Check out the page:
Womo

ups ... you got me. I actually don't know anything about the
parallel port. It was just a guess :-)

Kroko.

--- Synchronet 3.18b-Win32 NewsLink 1.113

From Newsgroup: comp.sys.cbm

Hi Kroko,

Kroko wrote:

This is not true, I think. The LPT parallel port does contain
inverters on _some_ lines. Check out the page:

ups ... you got me. I actually don't know anything about the
parallel port. It was just a guess :-)

No problem, I only wanted to clarify this out, so that Thomas
doesn't get confused. His attempt to write (stable?) IEC bus
routines for the Win32 operating systems is difficult enough.
We all know (and experienced) the negative effects of
multitasking systems as well as other side effects of the IBM
PC architecture (IO port waitstates).


Womo

--- Synchronet 3.18b-Win32 NewsLink 1.113

From Newsgroup: comp.sys.cbm

Hi Thomas,

Thomas M�ller wrote:

well, I'm using the routines from cbm4linux for setting and releasing a
line, as I think they are well programmed. Every cable has a "inverter-mask" byte. So these lines which have to be inverted are inverted by this byte - I think that's easier (and maybe faster) than working with function variables.

That's true as long as you only use the XM1541 or XA1541 cable.
You don't need to swap or shift bits, since they both connect
the same port bits to a dedicated wire.

You would need extend this concept, if you want to add the
XE1541 and X1541 cables. But I'm sure now, that you don't
want to this, because it complicates programming and
especially the timing :-)

They are not too hard to understand and work with only one line of code :).

The Star Commander worked the same for many years, when
only the X1541 and XE1541 cables were supported. But when
the XM1541 was introduced, we (Joe of course) needed more
flexibility.


One question: Now that you mentioned, that you took parts
of cbm4linux. Are you going to use LPT port generated
interrupts with your programming concept to perhaps
circumvent timing problems and that may result in a rock
solid stable connection (same as with the concept of the
cbm4linux kernel driver)?


Womo

--- Synchronet 3.18b-Win32 NewsLink 1.113

From Newsgroup: comp.sys.cbm

Hi,

hmm, looks like it accepts ATN bytes again, but I get "no dev" errors when trying to send a normal byte (I'll be working on it, so you don't have to
care about this now). I had it wrong with set and release in my atn setup
(set clk and release data, not other way round). By the way, it seems to be
the first time, this "no device" check works (1541 off = no device, 1541 on
= byte sent (at least with atn)), thank you for this one :).

Does the 1541 always accept data or only if a correct command was sent
before?

My get routine returns TRUE, if the line is low (0 V), for your interest.

Thomas


--- Synchronet 3.18b-Win32 NewsLink 1.113

From Newsgroup: comp.sys.cbm

Hi Wolfgang,

the cbm4linux method works for me, so I'm not going to change it until I'm publishing something of the project (would be too much work now).

A more stable timing would be nice but I'm not that hardware expert, that I could implement this right now.

My timing routines are, btw, currently just workarounds as Windows does not supply good timing functions (only the Sleep() procedure...).

Thomas


"Wolfgang Moser" <wnah@d81.de> schrieb im Newsbeitrag news:beoqk7$q2a$1@online.de...

Hi Thomas,

Thomas M�ller wrote:

well, I'm using the routines from cbm4linux for setting and releasing a line, as I think they are well programmed. Every cable has a

"inverter-mask"

byte. So these lines which have to be inverted are inverted by this

byte - I

think that's easier (and maybe faster) than working with function

variables.

That's true as long as you only use the XM1541 or XA1541 cable.
You don't need to swap or shift bits, since they both connect
the same port bits to a dedicated wire.

You would need extend this concept, if you want to add the
XE1541 and X1541 cables. But I'm sure now, that you don't
want to this, because it complicates programming and
especially the timing :-)

They are not too hard to understand and work with only one line of code

:).

The Star Commander worked the same for many years, when
only the X1541 and XE1541 cables were supported. But when
the XM1541 was introduced, we (Joe of course) needed more
flexibility.

One question: Now that you mentioned, that you took parts
of cbm4linux. Are you going to use LPT port generated
interrupts with your programming concept to perhaps
circumvent timing problems and that may result in a rock
solid stable connection (same as with the concept of the
cbm4linux kernel driver)?

Womo

--- Synchronet 3.18b-Win32 NewsLink 1.113

From Newsgroup: comp.sys.cbm

Hi guys,

Just two short notes:

1. I wouldn't be telling the truth if I said I know pretty much
everything about the parallel port. Actually, I still know pretty
much nothing about it but I _experimented_ enough to make the
shit work. So, don't worry about not understanding much... ;-)

2. If you ask me, you really shouldn't bother with supporting the
old X1541 cable. However, support for the XE1541 extended cable
_may_ be a good idea as, according to the statistics of my little
shop, this is by far the most favorite X1541-series serial cable.

Joe Forster/STA
sta@c64.org
--- Synchronet 3.18b-Win32 NewsLink 1.113

From Newsgroup: comp.sys.cbm

Hi Joe,

I agree with you that there won't be many of the X1541 cables left. The XA-
and XM1541 are supported directly (with the cbm4linux way), maybe there is a solution for XE1541's, too.

Thomas


"Joe Forster/STA" <sta@ludens.elte.hu> schrieb im Newsbeitrag news:OFyrLlHh5NqO@ludens...

Hi guys,

Just two short notes:

1. I wouldn't be telling the truth if I said I know pretty much
everything about the parallel port. Actually, I still know pretty
much nothing about it but I _experimented_ enough to make the
shit work. So, don't worry about not understanding much... ;-)

2. If you ask me, you really shouldn't bother with supporting the
old X1541 cable. However, support for the XE1541 extended cable
_may_ be a good idea as, according to the statistics of my little
shop, this is by far the most favorite X1541-series serial cable.

Joe Forster/STA
sta@c64.org

--- Synchronet 3.18b-Win32 NewsLink 1.113

From Newsgroup: comp.sys.cbm

Hi,

Hi !

thank you for this one :).

np !

Does the 1541 always accept data or only if a correct command was sent >before?

I never tried that, i don't know ...

My get routine returns TRUE, if the line is low (0 V), for your interest.

ah, thats sounds good :-)

Kroko.



--- Synchronet 3.18b-Win32 NewsLink 1.113

From Newsgroup: comp.sys.cbm

"Thomas Mller" <eous@gmx.de> writes:

2. If you ask me, you really shouldn't bother with supporting the
old X1541 cable. However, support for the XE1541 extended cable
_may_ be a good idea as, according to the statistics of my little
shop, this is by far the most favorite X1541-series serial cable.

Some of us are still using X1541 cables, though. I got one with my
registered copy of C64S (ages and ages ago), and I still use it with
the 486 laptop to do disk imaging.

--
Cameron Kaiser * ckaiser@floodgap.com * posting with a Commodore 128
personal page: http://www.armory.com/%7Espectre/
** Computer Workshops: games, productivity software and more for C64/128! **
** http://www.armory.com/%7Espectre/cwi/ **
--- Synchronet 3.18b-Win32 NewsLink 1.113

From Newsgroup: comp.sys.cbm

Hello again,


I hope, I'm not getting on your nerves with this, but I worked on the
project again and found out something strange:

I saw that ATN does not get high between LISTEN and SECLISTEN in your and
the kernal code (both bytes sent at once). So I modified my code and I can
now set or release ATN with flags.

I'm sending the first byte with X_ATN_INIT, which activates ATN, this seems
to work, when I'm sending the second byte with X_ATN_DEINIT (which pulls ATN up), I get a "no device" error (before the modification, I pulled ATN up
after every single byte). I don't know what this could mean. With normal
bytes, I'm getting "no device" errors anyway. So it seems it has something
to do with my ATN initialization.

Well, here's some code explained (again, now simplyfied):

if (atn) <- if X_ATN_INIT is set
{
set (atn) <- pull down
set (clk)
release (data)
wait for 748 cycles
}

<now normal byte send>

release (data) <- again, according to your description
wait for 22 cycles
check data, if it is high (= false) - if it is, -> no device
delay for 18 cycles

release clk
wait for 37 cycles

wait for floppy to release data
wait for 16 cycles

set clk
delay for 11 cycles

<send 8 bits>

wait for 14 cycles
check, if data is low, if it is -> timeout
wait 23 cycles
if bit is set, set data
wait for 22 cycles
release clock (signal data valid)
wait 26 cycles
set clk
release data
delay 7 cycles
<send next bit, if there is any>

delay 30 cycles (the floppy needs at least 30 to respond)
wait 1 ms max. for data to get low
if data is still high -> no ack error

if (atn) <- X_ATN_DEINIT is set
{
release atn (pull it high)
}

delay 200 ms (between-bytes-time)
return

This is what the routine looks like. Before I modified it, it seemed, the ATN-low bytes were all accepted. Now I modified it to be more "kernal-like", now it doesn't work at all :-/

It's cruel to work on this for days and still nothing happens :-(

Thomas


--- Synchronet 3.18b-Win32 NewsLink 1.113

From Newsgroup: comp.sys.cbm

I hope, I'm not getting on your nerves

no, the serial bus is pure fun :-)

if (atn) <- if X_ATN_INIT is set
{
set (atn) <- pull down
set (clk)
release (data)
wait for 748 cycles
}

sounds good, but you also have to do this, when X_ATN_DEINIT
is set, because this is also a byte under ATN. I don't know your code,
but make sure you call this in both cases.

release (data) <- again, according to your description
wait for 22 cycles
check data, if it is high (= false) - if it is, -> no device

yes ! if you get errors here, check your logic again and measure the
voltage level. It should be 0V on the line. maybe a breakpoint and a
multimeter do the job :-) If you get device not present here, then
you will have no luck in going on, because you have a serious problem
either with you logic or elsewhere. But you definitely have to solve
this first.

delay for 18 cycles
release clk
wait for 37 cycles
wait for floppy to release data
wait for 16 cycles
set clk
delay for 11 cycles

ok, so far so good ....

<send 8 bits>
wait for 14 cycles
check, if data is low, if it is -> timeout
wait 23 cycles
if bit is set, set data
wait for 22 cycles
release clock (signal data valid)
wait 26 cycles
set clk
release data
delay 7 cycles
<send next bit, if there is any>

yes, but the timeout is only checked once before all 8 bits.

delay 30 cycles (the floppy needs at least 30 to respond)
wait 1 ms max. for data to get low
if data is still high -> no ack error

yes, sounds good.

if (atn) <- X_ATN_DEINIT is set
{
release atn (pull it high)
}

only call this if X_ATN_DEINIT is set. I think
the floppy checks ATN very often, when it is
scanning for commands. In case ATN goes
high, it will cancel the command processing
immediately. LISTEN and TALK are 2 byte
commands. You have to send them in a row,
without ATN going up.
If you are interested in the details, have a look
at adress ($E85B) in the 1541 Kernel.

delay 200 ms (between-bytes-time)
return

yes, ok !

This is what the routine looks like. Before I modified it, it seemed, the >ATN-low bytes were all accepted. Now I modified it to be more "kernal-like", >now it doesn't work at all :-/

Well if the floppy is detecting ATN high, it will immediately cancel
command processing. So if you send a new byte, it will interpret it
as a new command, i guess. Not sure, but this will not work, if you
ask me.

It's cruel to work on this for days and still nothing happens :-(

yea, it was the same here ! and don't forget ...the WinXP timing
problems may be your problem as well.

Kroko.
--- Synchronet 3.18b-Win32 NewsLink 1.113

From Newsgroup: comp.sys.cbm

Hi,

if (atn) <- if X_ATN_INIT is set
{
set (atn) <- pull down
set (clk)
release (data)
wait for 748 cycles
}

sounds good, but you also have to do this, when X_ATN_DEINIT
is set, because this is also a byte under ATN. I don't know your code,
but make sure you call this in both cases.

hmm, my ATN code is more like a frame: X_ATN_INIT before the first byte and X_ATN_DEINIT after the last one. So it is sent as (LISTEN + address, X_ATN_INIT) and (SECONDARY, X_ATN_DEINIT) so ATN won't go high between them.

<send 8 bits>
wait for 14 cycles
check, if data is low, if it is -> timeout
wait 23 cycles
if bit is set, set data
wait for 22 cycles
release clock (signal data valid)
wait 26 cycles
set clk
release data
delay 7 cycles
<send next bit, if there is any>

yes, but the timeout is only checked once before all 8 bits.

I'll change that.

Thomas


--- Synchronet 3.18b-Win32 NewsLink 1.113

From Newsgroup: comp.sys.cbm

Kroko <Kroko@Nil.COM> wrote in
news:s5r5hvkq784upq0428h4rb0slkqlr1cnsj@4ax.com:

hmm, my ATN code is more like a frame: X_ATN_INIT before the first
byte and X_ATN_DEINIT after the last one. So it is sent as (LISTEN + >>address, X_ATN_INIT) and (SECONDARY, X_ATN_DEINIT) so ATN won't go
high between them.

its not only ATN, it is

set (atn)
set (clk)
release (data)
wait for 748 cycles

that has to be done before each byte under ATN. So
keeping ATN at 0V is not enough you have to run into
this "if satement" twice.

Kroko.

Hmm this changed nothing, but I noticed that my bit-setup for sending
the byte was wrong. I changed some timings, but still only the command
bytes get through... I found another bug, when trying to send anything
to a device number which doesn't exist, I get a "no device" error -
that's okay. But when I sent something to device 9 (the 1541), I can
send something to any other device address and I don't get this error
anymore.
I compared my code with cbm4linux again and couldn't find anything which
would be extremely different from my code. There's a major bug in my
routines and I can't find it... :/

Thomas
--- Synchronet 3.18b-Win32 NewsLink 1.113

From Newsgroup: comp.sys.cbm

There's a major bug in my routines and I can't find it... :/

Which is the first byte that is not accepted ?
You send LISTEN and it is accepted ?
You send SECLISTEN and it is accepted ?

what do you send now, and where does the communication stop ?
and the end of the 8 bits or before them ?

Did you send the bits in the correct order ? LSB first MSB last ?
Do you signal EOI when you send the last byte ?

Well, that all can think of for now :/

Kroko

--- Synchronet 3.18b-Win32 NewsLink 1.113

From Newsgroup: comp.sys.cbm

for (a = 0; a < 8; a++)
{
if (!((data >> a) & 0x1)) this->set(X_DATA);
}

Can you post the complete byte send routine ?
Maybe I can see someting. Please post the original code,
no the "pseudo code".

Kroko.
--- Synchronet 3.18b-Win32 NewsLink 1.113

From Newsgroup: comp.sys.cbm

Kroko <Kroko@Nil.COM> wrote in news:o3o8hv087o7mimrlbnp10crk48bsda4hon@ 4ax.com:

for (a = 0; a < 8; a++)
{
if (!((data >> a) & 0x1)) this->set(X_DATA);
}

Can you post the complete byte send routine ?
Maybe I can see someting. Please post the original code,
no the "pseudo code".

Kroko.

u16 x_bus::send(u8 data, u8 flags)
{
u8 a;

/*
* Sending under atn?
*/
if (bit_set(flags, X_ATN_INIT))
{
this->release(X_DATA);
this->set(X_ATN | X_CLK);

/*
* Wait 748 cycles
*/
cdelay(0x2ec);
}

/*
* Test data line
*/
this->release(X_DATA);
for (a = 0x0; a < 0x64; a++)
{
cdelay(0xa);
if (this->get(X_DATA)) break;
}

/*
* If data is not set then there's no device
*/
if (!this->get(X_DATA))
{
this->release(X_CLK | X_ATN);
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);

/*
* Set clk
*/
this->set(X_CLK);
cdelay(0xb);

for (a = 0x0; a < 0x8; a++)
{
cdelay(0xe);

/*
* Test for timeout
*/
if (this->get(X_DATA)) return (X_TIMEOUT);

cdelay(0x17);

/*
* Set up bit a
* If bit a is set, release data line (we're on active
low!)
*/
if (!((data >> a) & 0x1)) this->set(X_DATA);

/*
* Wait 22 cycles
*/
cdelay(0x16);

/*
* Release clk to signal "data valid"
*/
this->release(X_CLK);

/*
* Signal "data valid" for 26 cycles
*/
cdelay(0x1a);

/*
* Set clk, release data
*/
this->set(X_CLK);
this->release(X_DATA);

/*
* Delay for 7 cycles
*/
cdelay(0x7);
}

/*
* Wait 30 cycles (in case floppy responds immediately)
*/
cdelay(0x1e);

/*
* Floppy ack delay (max. 1 ms)
*/
for (a = 0x0; a < 0x64; a++)
{
if (this->get(X_DATA)) break;
udelay(0xa);
}

/*
* Still not acknowledged?
*/
if (!this->get(X_DATA)) return (X_NO_ACK);

/*
* If byte was sent under atn, release it now
*/
if (bit_set(flags, X_ATN_DEINIT))
{
this->release(X_ATN);
}

udelay(0xc8);

return (X_OK);
}
--- Synchronet 3.18b-Win32 NewsLink 1.113

From Newsgroup: comp.sys.cbm

One more thing ....Do you still send $FF with seclisten ?
Can you try what happens if you send $F0. As far as I know
you should use secondary address 0 for a load command.
sec adr 15 will access the command and error channel....
or is this what you want to do ?

Kroko.

--- Synchronet 3.18b-Win32 NewsLink 1.113

From Newsgroup: comp.sys.cbm

Hi,

unfortunately i can not see any errors here. But I still think
you should change this statement:

if (bit_set(flags, X_ATN_INIT))

to

if (bit_set(flags, X_ATN_INIT) || bit_set(flags, X_ATN_DEINIT))

Did you measure the line voltages that are on the cable after you have
set them with your routines. Can you confirm, that the voltages are
really as you expect them to be ?

Kroko.

--- Synchronet 3.18b-Win32 NewsLink 1.113

From Newsgroup: comp.sys.cbm

Kroko <Kroko@Nil.COM> wrote in news:f86bhvglho64p9sboupplfsh3cepa24urh@ 4ax.com:

One more thing ....Do you still send $FF with seclisten ?
Can you try what happens if you send $F0. As far as I know
you should use secondary address 0 for a load command.
sec adr 15 will access the command and error channel....
or is this what you want to do ?

Kroko.

I sent 0x60 till now (you told me to do so...). I tried 0xf0 now AND IT
WORKS :D. I'll work on this talk-command thing now (you know, after the unlisten cmd)

Thomas
--- Synchronet 3.18b-Win32 NewsLink 1.113

From Newsgroup: comp.sys.cbm

I sent 0x60 till now (you told me to do so...).

Sorry for the $60. This is the value that is forwarded to
a C64 kernel routinewhich ORs it with $F0. So the
value that is really sent is $F0 not $60.

Kroko.
--- Synchronet 3.18b-Win32 NewsLink 1.113

From Newsgroup: comp.sys.cbm

On Wed, 16 Jul 2003 18:56:27 +0000 (UTC), "Thomas M�ller"
<eous@gmx.de> wrote:

Hi,

hmm, there was something to do to let a device talk, do you have any docs >(otherwise I could check out the C64 programmer's manual..)

Regards,
Thomas

I am not sure if i understand your question, but TALK works almost
exactly like LISTEN.

you have to send TALK and SECTALK. After the drive accepted
SECTALK, it will send the directory to you. It will signal the last
byte with EOI. This should be on my page ....

If you have any feedback for me, where the description on my page
is misleading or difficult to understand, please tell me and i will
try to change it.

Kroko.

--- Synchronet 3.18b-Win32 NewsLink 1.113

From Newsgroup: comp.sys.cbm

Kroko <Kroko@Nil.COM> wrote in
news:189bhvoqj54htuqgks4p430mrmlpasla31@4ax.com:

On Wed, 16 Jul 2003 18:56:27 +0000 (UTC), "Thomas M�ller"
<eous@gmx.de> wrote:

Hi,


hmm, there was something to do to let a device talk, do you have any
docs (otherwise I could check out the C64 programmer's manual..)

Regards,
Thomas

I am not sure if i understand your question, but TALK works almost
exactly like LISTEN.

you have to send TALK and SECTALK. After the drive accepted
SECTALK, it will send the directory to you. It will signal the last
byte with EOI. This should be on my page ....

If you have any feedback for me, where the description on my page
is misleading or difficult to understand, please tell me and i will
try to change it.

Kroko.

It does not work unchanged. If you want a device to talk, you have to
complete SECLISTEN with

set DATA
release ATN
wait 30 us
release CLK

according to the cbm4linux sources. It's not sufficient just to pull ATN
up.

Thomas
--- Synchronet 3.18b-Win32 NewsLink 1.113

From Newsgroup: comp.sys.cbm

It does not work unchanged. If you want a device to talk, you have to complete SECLISTEN

Oops, that's SECTALK, not SECLISTEN. You have to complete SECLISTEN with
this sequence.


Thomas
--- Synchronet 3.18b-Win32 NewsLink 1.113

From Newsgroup: comp.sys.cbm

It does not work unchanged. If you want a device to talk, you have to >complete SECLISTEN with

set DATA
release ATN
wait 30 us
release CLK

Here is the code from my page:

; -------------------------------------------------------------------
; send secondary address for LISTEN ($EDB9 C64 kernel)
; -------------------------------------------------------------------
SECLISTEN: LDS R30,SEK_ADR ; this is where the secondary ..
ORI R30,0xF0 ; the hi-nibble must be F for ..
STS OUTBYTE,R30 ; we want to send this byte .. �
RCALL SEND_BYTE_ATN ; ($ED36 C64 kernel) send byte ..
RCALL SET_ATN ; ATN HI (the listen command is .
RET ; done.

; -------------------------------------------------------------------
; send secondary address for TALK ($EDC7)
; -------------------------------------------------------------------
SECTALK: LDS R30,SEK_ADR ; this is where the secondary .
STS OUTBYTE,R30 ; we want to send this byte
RCALL SEND_BYTE_ATN ; ($ED36 C64 kernel) send byte ..
RCALL CLEAR_DATA ; clear the DATA line
RCALL SET_ATN ; we need to set ATN ...
RCALL WAIT_100 ; wait for 100 �s
RCALL SET_CLK ; CLK hi
TALK_1: RCALL GET_CLK ; get CLK in R30
CPI R30,CLK_IN ; is it still HIGH ?
BREQ TALK_1 ; yes, so wait until the ..
RET ; done.


So what i do is:

After sending the byte:

- set data to 0V
- set atn to 5V
- wait 100�s
- set clk to 5V
- wait for clk to be 0V


Thats almost exactly the same, isnt it :-) ?

Kroko

--- Synchronet 3.18b-Win32 NewsLink 1.113

From Newsgroup: comp.sys.cbm

Yeah, this must be this "talk-attention turn around" thing (see the 3rd diagram of figure 6-4: http://www.devili.iki.fi/Computers/Commodore/C64/Programmers_Reference/Chap ter_6/page_364.html).


Thomas
--- Synchronet 3.18b-Win32 NewsLink 1.113