the problem with your protocol is the 6 cycles
 so it's not full ack..
because of the timing nneded
i thought this thing up
setup is:
sender: data undetermined, clock hi
receiver: data lo, clock lo
now
sender: sees clock lo, puts data bit to data, puts clock hi
waiterase that
 sender: sees clock lo, puts data bit to data, puts clock lo
receiver: sees clock lo, gets bits, deals with it, puts clock hi
sender: sees clock hi, toggles data, puts clock hi
receiver: sees data toggle, puts clock lo
repeat ad infinitum
i think this'll work
ok.. let me summarize to a txtfile.
I'll see if it looks right too
with this protocol, you dont need to slow down your scpu for transfers
(receiving, that is)
so no master/slave thingie
> how about transmit?
> this is heavily irq'ed and possibly bidirectional
> ok.  hardware question (I should know this..)
> is it possible on all 15xx/fd devices to see the true state of the bus,
> f/e if it's pulled low is it possible to see if another device is pulling
> high?
 i think so... afaik it's the iec standard for commodore devices.
 you could check that.
Ok.  Your proto looks good if thi sis true.
as fd'S/hd's have an emulation mode, it should be like that
but I think IEC is OC-output, so it can only pull low, not pull high
also afaik hd/fd use the same I/O hookups to the iec
fact is:
if the bit is cleared in the REGISTER
you can see the true bus state from the other device.
ok.  so if I set the bit, I cant see if someone else has it cleared.?
then reciever sees it and puts clock lo
without triggering an accidental handshake in step 3, how does the sender
see clock hi?
oh wait.. I see.
I was thinking backwards.. you can force hi, but not force low(?)
ehrm, dunno. hardware wiring shit sux... especially when commodore saved
that inverter in only one direction...
well, that's workable though.  You can read the bus in spite of the
inverter, and its needed for multi host protocols like iec.
scsi uses the same.
of course it works.
anyway, do you think the protocol would work, given that of a line is lo
(bit cleared), you can see the bus?
so... if this protocol is used, who'd get the credit? ;)
i think it doesnt matter about the clock state, you can invert it in all the
4 steps, imho
ok.  I'll do some poking and probing 
 I suck at coding but I have good ideas 
recognized a flaw
but killed the bug
will tell you in an hour maybe
the prob is: in step 1, the sender can't see the bus clock state
I was asking this, but am not sure about drivecode
well... that's the best solution i could come up with
setup:
sender has data undetermined, clock hi
receiver has data hi, clock lo
1) sender: puts data lo, sees data hi, puts data bit 0 to data, puts 
   clock lo
2) receiver: puts data lo, sees clock lo, gets data bit 0, puts clock hi
3) sender: sees clock hi, puts data bit 1 to data, puts clock hi
4) receiver: puts clock lo, sees clock hi, gets data bit 1, puts data hi 
   so it's 2 bits per round