Clockport Driver Question

Daedalus · 10 February 2016, 13:41

Here's one for anyone who has dealt with the clockport on a software level before... How does a driver differentiate and detect clockport devices on "extra" clockports, i.e. the ones at $D84000, $D88000 and $D8C000? Does it simply write a predetermined byte to each one until it gets a response it recognises? If so, how does that not mess up other devices that might interpret the write as a command?

I've been thinking about developing a sort of "GeekPort" for the clockport (multiple digital and analogue I/Os for hardware tinkering), and while the hardware is relatively straightforward, I'm not sure how to approach the software side. All I can think of now is either insist the port is at the original clockport address ($D80000), or else have the user manually define the base address.

Thanks!

strim · 10 February 2016, 21:43

Through the years of clockport devices development, these problems were never really solved.

I am developing clockport expansion now - I2C controller, which, coupled with additional hardware would serve similar purpose to your GeekPort. See here. I was thinking of writing some clockport.library to have a single abstraction layer for all the future clockport drivers.

Currently it's a mess. Typically the drivers have some kind of probe procedure that check all the possible locations for clockport. Note, there's a lot of them, since a lot of third party clockport expanders were developed. So not all drivers support all possible clockport locations, depending on how thoughtful the programmer was and in what year the driver was made... And don't forget clockports on Zorro boards. These don't have a static location, it is an offset from the base address of a given Zorro board.

Regarding the probe procedure itself, of course the easiest kind of probe to implement is where you write some byte(s) to a given location, then read back stuff and compare to values in your driver. But writing to locations that might have some other hardware attached is not the best idea. So more clever hardware developers create devices that can be identified with just reads. For example reading a byte multiple times from a given location will give you a sequence that you can use to identify the device.

If you don't want to deal with all of this, just let the user specify base location. Not exactly user friendly, but probably better than half-hearted attempt at automated detection.

Btw. if you want an example of rather simple test program for clockport device, here it is:
https://github.com/Sakura-IT/akuhei-.../src/akutest.c
(does not implement any probe procedure though)

Daedalus · 11 February 2016, 13:30

Excellent, thanks for that. It was actually your I2C project that re-ignited my Geekport idea and got me thinking along those lines... So it's pretty much as I suspected then, which is a shame. I also thought a clockport.library API for handling addresses and device identification would be great, but since most drivers are unlikely to be updated at this stage it's not that likely to help in most cases. Still, it could be a great starting point for future developments!

To be honest it would probably make more sense to simply build an I2C Geekport so it could be used with your interface or any other I2C implementation.

Thanks again!

strim · 11 February 2016, 20:11

Quote:

Originally Posted by Daedalus

To be honest it would probably make more sense to simply build an I2C Geekport so it could be used with your interface or any other I2C implementation.

Probably you are right, especially that I have just received components to produce a batch of these controllers. The idea I have is to make them as cheap as possible (probably something around 25-30 EUR).

I am definitely open to collaboration in this area. If you would design this I2C Geekport and release it under open source license, I could also make a batch of them and market it along the controller.

Marcus Gerards (of boards.library fame) is also working on temperature sensors and fan control stuff.

Daedalus · 11 February 2016, 23:57

Interesting... Interesting... It's on the projects list!

rockape · 12 February 2016, 10:34

Hi Daedalus,

Have you seen Ian Steadmans site ref Clock Port Adapters and Memory Maps ?

See http://www.ianstedman.co.uk/Amiga/am...lock_port.html

Regards, Michael

aka rockape

Daedalus · 12 February 2016, 11:27

Hi Rockape,
I have indeed, thanks very much. The hardware side is fine, it doesn't really cover the software side beyond bit-banging unfortunately, which is what I was already doing.

10 February 2016, 13:41	#1
Daedalus Registered User Join Date: Jun 2009 Location: Dublin, then Glasgow Posts: 6,348	Clockport Driver Question Here's one for anyone who has dealt with the clockport on a software level before... How does a driver differentiate and detect clockport devices on "extra" clockports, i.e. the ones at $D84000, $D88000 and $D8C000? Does it simply write a predetermined byte to each one until it gets a response it recognises? If so, how does that not mess up other devices that might interpret the write as a command? I've been thinking about developing a sort of "GeekPort" for the clockport (multiple digital and analogue I/Os for hardware tinkering), and while the hardware is relatively straightforward, I'm not sure how to approach the software side. All I can think of now is either insist the port is at the original clockport address ($D80000), or else have the user manually define the base address. Thanks!

10 February 2016, 21:43	#2
strim NetBSD developer Join Date: May 2012 Location: Warsaw, Poland Posts: 411	Through the years of clockport devices development, these problems were never really solved. I am developing clockport expansion now - I2C controller, which, coupled with additional hardware would serve similar purpose to your GeekPort. See here. I was thinking of writing some clockport.library to have a single abstraction layer for all the future clockport drivers. Currently it's a mess. Typically the drivers have some kind of probe procedure that check all the possible locations for clockport. Note, there's a lot of them, since a lot of third party clockport expanders were developed. So not all drivers support all possible clockport locations, depending on how thoughtful the programmer was and in what year the driver was made... And don't forget clockports on Zorro boards. These don't have a static location, it is an offset from the base address of a given Zorro board. Regarding the probe procedure itself, of course the easiest kind of probe to implement is where you write some byte(s) to a given location, then read back stuff and compare to values in your driver. But writing to locations that might have some other hardware attached is not the best idea. So more clever hardware developers create devices that can be identified with just reads. For example reading a byte multiple times from a given location will give you a sequence that you can use to identify the device. If you don't want to deal with all of this, just let the user specify base location. Not exactly user friendly, but probably better than half-hearted attempt at automated detection. Btw. if you want an example of rather simple test program for clockport device, here it is: https://github.com/Sakura-IT/akuhei-.../src/akutest.c (does not implement any probe procedure though) Last edited by strim; 10 February 2016 at 21:56. Reason: typo

12 February 2016, 10:34	#6
rockape Registered User Join Date: Feb 2010 Location: Lincolnshire, England. Age: 75 Posts: 167	Clock Port Info. Hi Daedalus, Have you seen Ian Steadmans site ref Clock Port Adapters and Memory Maps ? See http://www.ianstedman.co.uk/Amiga/am...lock_port.html Regards, Michael aka rockape

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
4-way clockport expander	DJBase	Hardware mods	231	09 January 2017 17:52
A1200 2B - 20pin clockport	ancalimon	support.Hardware	0	18 July 2014 19:14
WTB: Clockport soundcard	Doc Mindie	MarketPlace	0	30 March 2009 10:58
Clockport connection...PLEASE help!	Fingerlickin_B	support.Hardware	9	10 July 2008 14:38
Clockport switcher	thinlega	Amiga scene	0	22 April 2003 22:01

11 February 2016, 13:30	#3
Daedalus Registered User Join Date: Jun 2009 Location: Dublin, then Glasgow Posts: 6,348	Excellent, thanks for that. It was actually your I2C project that re-ignited my Geekport idea and got me thinking along those lines... So it's pretty much as I suspected then, which is a shame. I also thought a clockport.library API for handling addresses and device identification would be great, but since most drivers are unlikely to be updated at this stage it's not that likely to help in most cases. Still, it could be a great starting point for future developments! To be honest it would probably make more sense to simply build an I2C Geekport so it could be used with your interface or any other I2C implementation. Thanks again!

11 February 2016, 23:57	#5
Daedalus Registered User Join Date: Jun 2009 Location: Dublin, then Glasgow Posts: 6,348	Interesting... Interesting... It's on the projects list!

12 February 2016, 11:27	#7
Daedalus Registered User Join Date: Jun 2009 Location: Dublin, then Glasgow Posts: 6,348	Hi Rockape, I have indeed, thanks very much. The hardware side is fine, it doesn't really cover the software side beyond bit-banging unfortunately, which is what I was already doing.

Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)