exxos's Atari, Amiga & retro forum

Apologies; my input here will be sporadic (had to do school/work pickup run and tea for everyone between my last post. Phew!)

Anyway, I will start with not recommending using *any* of the AI bots for programming.

From what Ive seen so far, they all seem to 'talk the talk' and can use boilerplate code to appear correct. However, when it comes to creative thinking in between the cracks, they seem to fail bad; like worse than a noob coder.

If you use them then the time saved in coding a function/program is offset to bugfixing and can take as much time as writing the code yourself in some cases.

Also, I will refer you to the thread on AF that I *think* @Steve referenced and the growing divide (love/hate) of coders opinions of AI: https://www.atari-forum.com/viewtopic.p ... 70#p492111



Ok, back to specifics...

I think you had it 99% right just before my first response (as far as I could tell whilst from heavily relying on an AI generated program), other than the subtracting of 255 from the high byte, which seemed a weird thing to do to me. I would have thought it would be masked out instead.
But I gave it the benefit of the doubt, as you said it worked.

However, as it doesnt fully work, Im not sure doing that is correct.

But as I dont have any idea of the format of the value in the RTC_data output, I cant actually help you here.

This is the RTC chip which shows all the values

https://www.analog.com/media/en/technic ... 2c887a.pdf

Though the hisoft basic code I wrote years ago. It works to the point that values are read and saved correctly. But there could be a bug in my original code I am unaware of. I really can't remember about the 255 add subtract thing either. I am just trying to figure out why I did what I did.

The AI simply converted the basic code to assembly code. hours,mins,seconds, day, month, work fine, just not the year. No idea why :(

EDIT:
So the 255 add would be to clear the high byte as I assume nothing is connected on that half of the bus, so it returns all 1's. I just added 255 to zero the result.. Lazy I guess more than anything, but should likely all be subtracted I guess.. or just written better.

AI moaning at that conversion, now its moaning somewhere I've confused decoding methods in my code.. So its just assuming DM=0 now, which is what its supposed to use. I must have programed in DM=1 as well, but was never used and might be buggy.

Ok, as the code 'worked' apart from the year, lets start with that.

Looking at the spec sheet you posted:
We need to focus on register offset $9h (although either the sheet has errors, or I have not noticed where it explains why it says 'range 0-63' instead of a 0-127 range - 7 LSB bits seem to be valid entries according to the the right side of the chart(?) and also, we need 7 bits to reach up to the number 99).

Theres a BCD coded register ($32h) which automatically writes a value of 20 for the century, so it looks like we can leave that alone.

Ok, now we have some sort of idea whats being set where and in what format, we can look at the code and see.

Im going to concentrate on the code directly before my first reply, as it seems to be the closest to fully operational.

Bear with me and I will come back to this later on.

@mrbombermillzy AI think ive confused DM=0 with DM=1 now.

My basic code had

POKEW (RTC_ADDRESS&),&B1111111100001011 ' SET ADDRESS 0BH

So bit 2 (DM) = 0 .

AI is just doing the changes and masking the bits properly..

exxos wrote: 09 Feb 2026 18:32 So the 255 add would be to clear the high byte as I assume nothing is connected on that half of the bus, so it returns all 1's. I just added 255 to zero the result.. Lazy I guess more than anything, but should likely all be subtracted I guess.. or just written better.

Trying to keep up with the edits... :lol:

No, adding 255 does not clear the high byte. It would just be the equivalent of setting a carry flag.

To really clear the top byte, you would have to do something like 'and $00ff,d0' to d0.

exxos wrote: 09 Feb 2026 19:03 @mrbombermillzy AI think ive confused DM=0 with DM=1 now.

My basic code had

POKEW (RTC_ADDRESS&),&B1111111100001011 ' SET ADDRESS 0BH

So bit 2 (DM) = 0 .

AI is just doing the changes and masking the bits properly..

Im not familiar with Hisoft Basic, but it seems you are ANDing the high byte and some of the low byte (bits 0,1 and 3).


Edit: and I dont know what DM is. :)

mrbombermillzy wrote: 09 Feb 2026 19:05 Im not familiar with Hisoft Basic, but it seems you are ANDing the high byte and some of the low byte (bits 0,1 and 3).
Edit: and I dont know what DM is. :)

Its the "Decode mode" I think..


I am trying to figure out what mode my RTC setter program actually sets at this point..

I dont think you are setting DM anyway. You seem to be setting SQWE 24/12 and DSE. (Whatever they do!) :lol:

mrbombermillzy wrote: 09 Feb 2026 19:13 I dont think you are setting DM anyway. You seem to be setting SQWE 24/12 and DSE. (Whatever they do!) :lol:

bit 2 = DM = 0

bit 0 and 1 , 24 hour clock and daylight savings enabled. rest is turned off.. dont care about it..

I don't get it, value returned is DM=1 according to the AI code..

Ive just checked (in case the values are reversed) but it seems 0=BCD and 1=Binary mode.

So as far as I can see with the above bitcode pattern: (00001011)

and the table:



DM is set to =0. Despite what AI says. :)

Try setting the bitmask to 00000111 and see what happens.

You may well be trying to set the year value in BCD format.