Marius Posted February 11, 2011 Author Share Posted February 11, 2011 On the joystick connector: Pin 1 is PA0 - goes to CLK (SCL) Pin 2 is PA1 - goes to DATA (SDA) Pin 8 is ground (GND) Pin 7 is +5v (Vcc) If you look very closely at the face of the 9-pin connector, you will see the pin numbers cast into the plastic. That is very nice information. Thank you VERY much! When you first install the battery, the chip will initialize with the clock disabled. You have to store $00 into register $00 to start timing. But how? I don't understand the s2c protocol. How do I realise this? Is there a 'baud rate' I should look after? I never programmed the joystick port for data transfer. So I hope you will be able to get your code to AtariAge. I would be very happy then Sorry for all this questions. I'm really excited by the idea that this will work! Greetz and thanks AGAIN! Marius Quote Link to comment Share on other sites More sharing options...
+bob1200xl Posted February 11, 2011 Share Posted February 11, 2011 I'll try it again... On the joystick connector: Pin 1 is PA0 - goes to CLK (SCL) Pin 2 is PA1 - goes to DATA (SDA) Pin 8 is ground (GND) Pin 7 is +5v (Vcc) If you look very closely at the face of the 9-pin connector, you will see the pin numbers cast into the plastic. That is very nice information. Thank you VERY much! When you first install the battery, the chip will initialize with the clock disabled. You have to store $00 into register $00 to start timing. But how? I don't understand the s2c protocol. How do I realise this? Is there a 'baud rate' I should look after? I never programmed the joystick port for data transfer. So I hope you will be able to get your code to AtariAge. I would be very happy then Sorry for all this questions. I'm really excited by the idea that this will work! Greetz and thanks AGAIN! Marius RTC.ATR 1 Quote Link to comment Share on other sites More sharing options...
Marius Posted February 12, 2011 Author Share Posted February 12, 2011 Somewhere in the thread you told us that the first time you had to write a zero in register $00. Is your code doing that already? Or is this something I have to do? Only the very first time? Or is it ok to do that everytime you read/write to the RTC? Thanks Marius Quote Link to comment Share on other sites More sharing options...
+bob1200xl Posted February 12, 2011 Share Posted February 12, 2011 Actually, only bit 7 of register 00 has to be cleared. Once it is 0, you don't have to worry about it again. (except: if you pull the RTC while it is under power, it may set the bit again) There are two routines - RTCRD and RTCWR. They only run when they are called by JSR $600. (change the BRK at $623 to an RTS) RTCRD reads all 64 bytes of the RTC into memory locations $6C0-$6FF. The sequence is to write the RTC ID (to select the RTC chip), write the address of the register that you are going to select and then read (once or many times) the data from the RTC reg(s). This does not change any data stored in the chip. RTCWR writes a byte of data into any one register of the chip. The register address goes in $609 and the data goes in $60E. This is how you set the clock. Writing to reg $00 will alter the data in the Seconds field - not a good idea if you want to keep accurate time. Do it once and then leave it alone. These routines can be consolidated or perhaps made more efficient. I just generated them to get the RTC up and running. My target is to run the code in the PBI when data is written to sectors 361-368 (directory update). Half the sector (if DD) is blank and never used - drop the time in there on the unused space. No code changes in DOS 2.0... Bob Somewhere in the thread you told us that the first time you had to write a zero in register $00. Is your code doing that already? Or is this something I have to do? Only the very first time? Or is it ok to do that everytime you read/write to the RTC? Thanks Marius 1 Quote Link to comment Share on other sites More sharing options...
Marius Posted February 12, 2011 Author Share Posted February 12, 2011 @bob It sounds very good! You deserve a +1! Now it is waiting for my RTC's. I'll let you know how I'm doing! Thanks for all your efforts! Marius Quote Link to comment Share on other sites More sharing options...
Marius Posted February 19, 2011 Author Share Posted February 19, 2011 Hi Bob, Today I received my RTC boards. But I have to say: I don't understand it. I don't understand: * What should I change to your source or RTCWT.ASM to write that first zero? * How to set time? Do I have to run the complete routines a few times (for seconds, minutes, hours?) * What commands for writing date? Sorry for all questions. I don't have documentation (and if I had it, I probably wouldn't understand it). I hope you can help! Thanks Marius Quote Link to comment Share on other sites More sharing options...
Marius Posted February 19, 2011 Author Share Posted February 19, 2011 Some debuggin information. When I use your RTCWT.OBJ file, I assume in register 08h there is written the value #$AA right? When I run that OBJ file. And THEN I run the RTCRD.OBJ, There is NO #$AA placed in whatever adress from $06c0 - $06ff. I guess it should have been placed on $06c8, but it isn't there. As far as I can see it, the seconds are running now. I don't understand the values coming in $06c0 but ok. When I calculate them back to decimal, I see: 1, 3, 7, 11 ... All other registers stay to #$FF. Last thing: When I change your "RTCWT.OBJ" file (I change the values on $0609 and $060E) into let's say: $0609 - > #$01 $060E -> #$10 The routine crashes (hangs stuck) I have no idea what is going wrong here. The cable is good. Thanks Marius Quote Link to comment Share on other sites More sharing options...
Marius Posted February 19, 2011 Author Share Posted February 19, 2011 The problem is that it hangs on NAK BNE NAK (I DID EDIT THIS LINE YES!) What is that? Is this some kind of 'error-checking' system? What does it say to me? Your cable is fault? Your RTC is fault? Pin 1 of the first joystick port goes to SCL Pin 2 of the first joystick port goes to SDA VCC and Ground are good (checked with Multimeter) greetz M. Quote Link to comment Share on other sites More sharing options...
Marius Posted February 19, 2011 Author Share Posted February 19, 2011 Completely strange... On my Atari 800XL with 64KB it just works fine. On my Atari 130XE with 320KB it fails. Fails also on my 576XL What is going on here? PortB is not involved? And still it does not work on upraded XL/XE's? any suggestions? Thanks Marius Quote Link to comment Share on other sites More sharing options...
+bob1200xl Posted February 19, 2011 Share Posted February 19, 2011 Does it always fail in NAK? Some machines may need delays for the RTC to respond. A NAK occurs when the RTC does not acknowledge the 8 bits that we sent to it. When it NAKs, does the data still get loaded? Let me see if more of my machines run OK... Here is the data sheet on the RTC chip - DS1307. Are you using the exact same RTC that I am? Bob Completely strange... On my Atari 800XL with 64KB it just works fine. On my Atari 130XE with 320KB it fails. Fails also on my 576XL What is going on here? PortB is not involved? And still it does not work on upraded XL/XE's? any suggestions? Thanks Marius DS1307.pdf Quote Link to comment Share on other sites More sharing options...
Marius Posted February 19, 2011 Author Share Posted February 19, 2011 Yes I use the same. No. Reading also fails on the "NAK" machines. I checked a stock 130xe -> also fails. Let me check some more xl/xe computers. I have plenty, so I'm curious. I can't believe memory upgrade has something to do with it, since PORTA ($d300 and control register $d302) are not involved with any memory expansion at all. Strange it is! Marius Quote Link to comment Share on other sites More sharing options...
Marius Posted February 19, 2011 Author Share Posted February 19, 2011 Ok found an 800XL with 64KB which also has the problem. Reading with the 'it doesn't work' computer results in: 06C0 -> a wrong result 06C1 - 06FF -> #$FF That's it. I hope this can be fixed Marius Edit: and my 600XL reads wrong numbers on all the registers. Rather strange. To be complete: I have 2 64KB computers who do it right, the rest do all fail. Quote Link to comment Share on other sites More sharing options...
Marius Posted February 19, 2011 Author Share Posted February 19, 2011 Well... I don't know how to fix it. I hope you have a solution. I looked in your source, but I have no idea how important the timing is. I tried to insert after each 'STA $d300' a JSR PAUSE routine. But that did not do it. It's too complicated for me, since I'm totaly uneducated on the I2C thing and all that. Till then I keep waiting patient Greetz M. Quote Link to comment Share on other sites More sharing options...
+bob1200xl Posted February 19, 2011 Share Posted February 19, 2011 If you write the data on a working system, can you read it back on a 'broken' system? What I want to know is: does it fail on read and write, or just write? So, if you write data (and read it back OK) on a good machine and then move the RTC to a bad system, does it read OK at all? For the NAK in the write routine, try BNE back to $600 and see if it can complete OK on retry. BTW - did you solder in the resistors that they sent with the device? Does the battery measure good? Works OK on my RAMBO 1200XL... Bob Yes - I don't know I2C. either. Well... I don't know how to fix it. I hope you have a solution. I looked in your source, but I have no idea how important the timing is. I tried to insert after each 'STA $d300' a JSR PAUSE routine. But that did not do it. It's too complicated for me, since I'm totaly uneducated on the I2C thing and all that. Till then I keep waiting patient Greetz M. Quote Link to comment Share on other sites More sharing options...
Marius Posted February 19, 2011 Author Share Posted February 19, 2011 If you write the data on a working system, can you read it back on a 'broken' system? What I want to know is: does it fail on read and write, or just write? So, if you write data (and read it back OK) on a good machine and then move the RTC to a bad system, does it read OK at all? The RTC works only well on the 2 atari 800xl's. All others fail. Even when I succeed writing the time to it (on the 2 good working atari's) I can not read them out on the non-working Atari's. Only on the two working atari's I can do both good read and write. On all others both read and write fail (writing = hanging stuck, reading = wrong values) For the NAK in the write routine, try BNE back to $600 and see if it can complete OK on retry. No Luck. Keeps running. BTW - did you solder in the resistors that they sent with the device? Does the battery measure good? Yes (I guess this is right?) and Yes. Works OK on my RAMBO 1200XL... Could there be a NTSC -> PAL problem here? PAL = Slower. Thanks M. Quote Link to comment Share on other sites More sharing options...
+bob1200xl Posted February 19, 2011 Share Posted February 19, 2011 When the write routine NAKs, (put the BNE NAK back in) what is in the accumulator? What does $D300 read? Are you gatting $FF everywhere? Can you manually store $FC in $D300? Do you have a different OS in the failing machines? Bob Quote Link to comment Share on other sites More sharing options...
+bob1200xl Posted February 20, 2011 Share Posted February 20, 2011 I tried it on a 130XE and it fails solid. Get all $FF in $6C0-$6FF. I'll fix it and get back to you. Weird... the circuits are the same. A 1200XL with the same OS works fine. An 800 works fine. An 800XL works fine. Bob If you write the data on a working system, can you read it back on a 'broken' system? What I want to know is: does it fail on read and write, or just write? So, if you write data (and read it back OK) on a good machine and then move the RTC to a bad system, does it read OK at all? The RTC works only well on the 2 atari 800xl's. All others fail. Even when I succeed writing the time to it (on the 2 good working atari's) I can not read them out on the non-working Atari's. Only on the two working atari's I can do both good read and write. On all others both read and write fail (writing = hanging stuck, reading = wrong values) For the NAK in the write routine, try BNE back to $600 and see if it can complete OK on retry. No Luck. Keeps running. BTW - did you solder in the resistors that they sent with the device? Does the battery measure good? Yes (I guess this is right?) and Yes. Works OK on my RAMBO 1200XL... Could there be a NTSC -> PAL problem here? PAL = Slower. Thanks M. Quote Link to comment Share on other sites More sharing options...
Marius Posted February 20, 2011 Author Share Posted February 20, 2011 Do you have access to something like a blackbox? I mean: can you write REALTIME (during a program) in a memory location? All test results I'm posted here are on a failing machine. When I try to write a #$01 in register #$01 The program hangs stuck on $067f (the NAK thing) At that moment $D300 reads #$FF When I write #$FC to $d300 it das actually change to #$FC Yesterday before I went to bed I tried a few other things (all with no luck) I tried a PAUSE between a few routines. No changes I build a new -very short- cable. Still no changes. I measured the SCL and SDA lines when the computer hangs stuck on $067F SCL = +5V SDA = +4.99V I also measured the SCL and SDA lines after reading: SCL = 0.30V SDA = +4.99V Perhaps you can do something with that info. Thanks! Marius Quote Link to comment Share on other sites More sharing options...
Marius Posted February 20, 2011 Author Share Posted February 20, 2011 I was wondering: Is there a certain speed (let's call this a baudrate) to use? Is the clock line meant to sync that speed? Should there be a tiny delay between clock high and data high (or low) Marius Quote Link to comment Share on other sites More sharing options...
Marius Posted February 20, 2011 Author Share Posted February 20, 2011 I try to understand the way data is transferred. Am I right on this: to write a bit: Clockline is low DataLine set high (to write the bit) then Clockline set high (the bit is actually transferred here) then Clockline set low (to be able to go to the next bit) Is this what happens on writing? Thanks Marius Quote Link to comment Share on other sites More sharing options...
Marius Posted February 20, 2011 Author Share Posted February 20, 2011 When the computer hangs stuck on $067F A = #$02 Y = #$00 X = #$06 in the read routine you put a SEC around a AND #$02. I'm not competely sure WHY, but in the write routine that SEC isn't there. Another thing: When the Bits direction is set through $D302. Does this mean PortA is read AND write? Don't you have to change $D302 'all the time' to do a read and write over these lines? Just a question. M. Quote Link to comment Share on other sites More sharing options...
Marius Posted February 20, 2011 Author Share Posted February 20, 2011 Look what I found here; http://members.casema.nl/hhaydn/howel/logic/i2c_bus.htm And read the LAST line: A 6502 running at 1.77 MHz is not fast enough to bit-bash I2C at 100 kHz, let alone 400 kHz, so you will have to find the actual rate by experiment. Is that a clue that the chance that it will never work exists? Greetz M. Quote Link to comment Share on other sites More sharing options...
+bob1200xl Posted February 20, 2011 Share Posted February 20, 2011 Yes - that is the sequence once you have selected the device. Bob I try to understand the way data is transferred. Am I right on this: to write a bit: Clockline is low DataLine set high (to write the bit) then Clockline set high (the bit is actually transferred here) then Clockline set low (to be able to go to the next bit) Is this what happens on writing? Thanks Marius Quote Link to comment Share on other sites More sharing options...
Marius Posted February 20, 2011 Author Share Posted February 20, 2011 I'm not sure yet... First test results are promising. I have been debugging for hours, and It SEEMS I have a working WRITE to Clock routine now. When I write to the RTC on the nonworking atari, it does not hang stuck anymore, and when I read it back on the WORKING Atari I got the right results. I can't tell you at THIS moment what the changes are, since i have been using workfile10 right now. When it is finished I come back here. The reading tool is not working yet. Greetz M. Quote Link to comment Share on other sites More sharing options...
+bob1200xl Posted February 20, 2011 Share Posted February 20, 2011 I don't know about the SEC, but the $D302 setting makes the lines outputs rather than inputs. The clock line is always writing - no issues there. The data line, however, reads and writes. It turns out that the line is what they call an open collector, which means that it only pulls the line low - it does not pull the line high. This allows any number of devices to share the interface. I have set this up so that the data line pulls the PA1 line low, as if it were also an open-collector net. This seems to work fine, but it may be a poor design. I'll add back the MAKEIN routine (that I removed from the later versions) and see if that resolves the problem. It may be that the later versions of the 6520 had a higher current sink than the older ones. The maximum frequency of the DS1307 is 100KHZ, I believe. (does not work as written on the XL7) Regardless, the minimum frequency appears to be 0KHZ, so we don't have to be concerned with how long something takes. Bob When the computer hangs stuck on $067F A = #$02 Y = #$00 X = #$06 in the read routine you put a SEC around a AND #$02. I'm not competely sure WHY, but in the write routine that SEC isn't there. Another thing: When the Bits direction is set through $D302. Does this mean PortA is read AND write? Don't you have to change $D302 'all the time' to do a read and write over these lines? Just a question. M. Quote Link to comment Share on other sites More sharing options...
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.