[CSDb] - User Forums - Multi-master on IEC bus

You are not logged in - nap

CSDb User Forums

Forums > C64 Coding > Multi-master on IEC bus

2022-01-04 17:34

Repose

Registered: Oct 2010
Posts: 225

Multi-master on IEC bus

Continuing an off-topic thread from https://csdb.dk/forums/?roomid=11&topicid=91766, starting from #117.

The question at hand, is imagine programming a set of drives to perform computations on behalf of the C64. How can you handle communication between the C64 and one or more drives such that the drives can initiate communication when they have a result to send?

Technical info of the CIA for reference:
https://ist.uwaterloo.ca/~schepers/MJK/cia6526.html

Mapping the C64:
https://e4aws.silverdr.com/project64/mapc64/ (search DD00)

Ultimate Drive Talk:
https://hackaday.com/2021/09/19/the-ultimate-commodore-1541-dri..

56576 $DD00 CI2PRA
Data Port Register A

Bits 0-1: Select the 16K VIC-II chip memory bank (11=bank 0, 00=bank 3)
Bit 2: RS-232 data output (Sout)/Pin M of User Port
Bit 3: Serial bus ATN signal output
Bit 4: Serial bus clock pulse output
Bit 5: Serial bus data output
Bit 6: Serial bus clock pulse input
Bit 7: Serial bus data input

56589 $DD0D CI2ICR
Interrupt Control Register
Bit 4: Read / was a signal sent on the FLAG line? (1=yes)
Write/ enable or disable FLAG line interrupt (1=enable, 0=disable)

It seems there's no way to make the serial bus an interrupt source, but by connecting FLAG to one of the pins you could.

Is polling that bad? What are the needs? For a use case, imagine plotting a fractal. I wouldn't mind if the screen filled in in arbitrary chunks. You could easily poll at 50/60Hz rate and it would seem instant. The method would be for the drive to set CLK high, on the next poll, the C64 pulls it low and holds, in up to another poll time the 1541 see it's low, sets DAT high... anyhow, from there we can synchronize the two CPUs by various methods used by drive loaders.
Ultimately, you can transfer bytes in about 32 cycles at a time. I've heard the CPUs can stay in sync for at least 40 bytes at a time.
They key to efficiency is keeping the two CPU's in sync, then the handshaking is fast, and from there you can do a big burst of data.

2022-01-04 18:24

Krill

Registered: Apr 2002
Posts: 2980

An idea that just occured to me is some kind of time-division multiplex.

Consider a C-64 and 4 drives on the bus, but no other computer on the other end of the chain. Numbers are somewhat arbitrary, and some tolerance may be assumed.

The C-64 would assert and release ATN once a video frame.
This would trigger interrupts in all drives, which would reset a VIA timer used to determine valid time slots.

Once a drive has finished its work, it would wait for the next timeslot it may use. This could be something like a fixed-position window of 64 cycles within a period of 256 cycles, with each window reserved for exactly one of the 4 drives.

Once the beginning of such a slot is reached, the drive would sense the bus for ongoing communication (DATA or CLK asserted within say 32 cycles).

If communication is going on, it would wait for the next slot and retry.
Otherwise, it would assert DATA or CLK to signal the C-64 that it has finished work.
Then it would wait for an acknowledgement, send its ID followed by the burst of result data, then receive a new chunk of work to process.

Now... some tricky bits could be avoiding interference of data transfers with the ATN sync signal once a video frame, and also keeping the polling overhead of the C-64 somewhat low, as it would need to check the bus for a work-finished signal periodically while also performing some work of its own.

Having two computers on the bus adds some more complexity, but this case can be ignored until later. :)

2022-01-04 18:56

Repose

Registered: Oct 2010
Posts: 225

Great thinking!
Time slots can certainly solve the problem. You could have 5 time-slots and whomever brings a line high in their time-slot gets control, then you can burst the data. If many people need to send, they go in priority round-robin order.

Or, you can use the CAN method; we can use CLK in/out for this. Idle is when CLK is high. The node that wants to send brings CLK low. Everyone else detects the low and switches to listening mode. This is normally done in hardware yes but can also be done in software. The other difference is doing it every tick so you aren't constantly polling.
To continue, the talker sends the ID of who it is and how much data it's sending, then the listeners can go back to what they're doing until the bus is expected to be free again, and due to the amount of data sent, this is allowed to even exceed the tick time.
The next tick after that it can start again.

2022-01-04 19:27

Krill

Registered: Apr 2002
Posts: 2980

Quoting Repose

The node that wants to send brings CLK low. Everyone else detects the low and switches to listening mode. This is normally done in hardware yes but can also be done in software.

This seems to be a bit too much overhead. Every device on the bus would need to poll for CLK going low, in between doing work.

Quoting Repose

the talker sends the ID of who it is and how much data it's sending, then the listeners can go back to what they're doing until the bus is expected to be free again

Having all devices (somehow) know when a transfer is expected to end sounds like a good idea. :) But then the devices don't need to know that until they have data to send and nothing else to do than to poll for an idle bus.

2022-01-04 19:39

Repose

Registered: Oct 2010
Posts: 225

Quoting Krill

Quoting Repose
The node that wants to send brings CLK low. Everyone else detects the low and switches to listening mode. This is normally done in hardware yes but can also be done in software.
This seems to be a bit too much overhead. Every device on the bus would need to poll for CLK going low, in between doing work.

I agree that I've failed to make use of ATN here to interrupt each device; however, whether a device is interrupted by ATN or interrupted by a timer, it's the same thing. Just to be clear, I don't propose that the drives are in an infinite loop waiting for CLK low; they only do this once a tick, and for a limited time. In other words, I see this as a loop of maybe 100 cycles every 1/60th of a second. ATN is one way if the c64 wants to send to a drive, instead of using that, I'm saying have them all listen for each other once in a while, and if no one has anything to say, you can quickly go back to work.

Quoting Repose

the talker sends the ID of who it is and how much data it's sending, then the listeners can go back to what they're doing until the bus is expected to be free again

Quoting Krill

Having all devices (somehow) know when a transfer is expected to end sounds like a good idea. :) But then the devices don't need to know that until they have data to send and nothing else to do than to poll for an idle bus.

Polling can be very minimal; it only adds latency. For the use cases I'm thinking of, a latency equal to screen refresh will always be sufficient.

2022-01-04 19:49

Krill

Registered: Apr 2002
Posts: 2980

Quoting Repose

whether a device is interrupted by ATN or interrupted by a timer, it's the same thing.

The point of an ATN interrupt once a videoframe is the synchronise the clocks, as they would sooner or later all drift apart. Synchronised clocks are required to properly determine valid time slots for each device.

Quoting Repose

Polling can be very minimal; it only adds latency. For the use cases I'm thinking of, a latency equal to screen refresh will always be sufficient.

Polling is minimal if a device only polls after having finished work, as it doesn't have anything else to do.
So it can just as well poll in a loop and have minimum latency, while only being interrupted once a video frame for the ATN sync strobe, doing its work with minimum overhead.

Main source of latency would be something with the time slot granularity.

The use cases i'm thinking of shall certainly produce video measurable in frames per second, not seconds per frame. :)

2022-01-04 20:03

Repose

Registered: Oct 2010
Posts: 225

Quoting Krill

Polling is minimal if a device only polls after having finished work, as it doesn't have anything else to do.
So it can just as well poll in a loop and have minimum latency, while only being interrupted once a video frame for the ATN sync strobe, doing its work with minimum overhead.

Yes, that's a good point. But, I'm noticing a new assumption here; you are thinking of them in a more restricted sense as slaves only reporting back calculations and not accepting any new commands (such as a status check or more work) until completing the work. In that case, they can simply not participate during the polling interval. If a node is not expecting work due to it not sending finished work, it has no need to participate in arbitration.
So, when it is finished, it has to wait until the next ATN to indicate it's ready to send. It can send as long as it wants, the c64 can stop the regular ATN until the bus is free again.

2022-01-04 20:41

Krill

Registered: Apr 2002
Posts: 2980

Quoting Repose

But, I'm noticing a new assumption here; you are thinking of them in a more restricted sense as slaves only reporting back calculations and not accepting any new commands (such as a status check or more work) until completing the work.

Any commands to unsuspecting devices can be sent along with the ATN sync. They are interrupted anyways and can then check the other two lines for being asserted.

Quoting Repose

In that case, they can simply not participate during the polling interval.

Which polling interval do you mean?

Quoting Repose

So, when it is finished, it has to wait until the next ATN to indicate it's ready to send.

The ATN sync is just there to sync the clocks (and possibly dish out commands). If a device has data to send, it would not wait for ATN but its next valid time slot.

Quoting Repose

It can send as long as it wants, the c64 can stop the regular ATN until the bus is free again.

True, the ATN sync does not have to be aligned to video frames.

2022-01-04 21:08

mankeli

Registered: Oct 2010
Posts: 146

I thought it's really not possible to daisy chain too many devices on the IEC bus, because the every NMOS device has a pull-up resistor and the transistors are not strong enough?

2022-01-04 21:41

tlr

Registered: Sep 2003
Posts: 1790

Quote: I thought it's really not possible to daisy chain too many devices on the IEC bus, because the every NMOS device has a pull-up resistor and the transistors are not strong enough?

There's a 7406 TTL buffer in there. I always thought it would be the capacitive loading making the edges too slow, but I see now that the pull ups are only 1k so maybe that's it.

2022-01-04 21:49

Krill

Registered: Apr 2002
Posts: 2980

Quoting mankeli

I thought it's really not possible to daisy chain too many devices on the IEC bus

That's quite a tautology. :)

The official specs support at least 4 devices additionally to the host computer, so... will be fun to find out how many more drives people can add until it starts acting funny. =)

... 10 posts hidden. Click here to view all posts....

Previous - 1 | 2 - Next

Refresh

Subscribe to this thread: