RTC module for MegaSTe MonSTer

[spiny]

OK, here are some pics and some info, let me know if anything needs explaining better.

pin info:

Monster pins, looking at board from above, with the RTC block being at the bottom

1 2
3 4
5 6
7 8
9 10
11 12

pins on clock:

gnd > 9 on monster
scl > 12 on monster
sda > 10 on monster
vcc > 11 on monster

resistor between scl and vcc
rsistor between sda and vcc

Images:

My STM, has the monster board, RTC and exxos 4meg:

DSCN2182.JPG

Close up of rtc with veroboard

DSCN2183.JPG

pinout of rtc

DSCN2184.JPG

veroboard side

DSCN2185.JPG

'top' side showing resistors

DSCN2186.JPG

connecting pins, yellow is vcc, then sda, then scl, then gnd

DSCN2187.JPG

monster pins

DSCN2188.JPG

[spiny]

If I remember, I'll take some pics if it actually fitted later on this evening.

Please do, that would certainly be of interest

a bit late, but pics are above

[Fujiyama]

I used a DS1338 with my Monster board OK, but I did need to add two resistors, in order for it to read the time correctly:

viewtopic.php?f=15&t=27627&hilit=rtc+dallas+monster&start=450#p307565

I bought a cheapo eBay (probably fake, but OK for testing) Chronodot 2, based on the DS3231 which I haven't tried out with the MonSTer yet. The wiring info is in the MonSTer thread somewhere, isn't it?
Please tell more about those resistors -values and where you connected them?

the info is in the thread I linked to.

After trying out the clock module and not having it remember the time/date I suppose I'll have to try adding pullup resistors.
According to the eBay page of the DS3231-based RTC module I bought, it says (in typical Chinglish): "The pull-up resistor R1 R2 own welding on the I2C bus".

And sure enough: there are two empty component locations on the PCB marked R1 and R2. With a multimeter I confirmed that they each have one end going to the SDA and SCL signals.

I've read the thread you linked to and Alanh suggests 10K resistors for each line. But in this thread, 4.7K, 1K and 10K have all been discussed and there's a reference to a highly technical I2C document which is mostly way over my head. Apparently the different values have something to do with eliminating noise from long cables while still getting a proper square wave signal from the RTC module. In my case the 4 IDC wire strands with Dupont connectors are 20cm long if that makes any difference. I plan to mount the RTC module to one of the power supply screws for a secure attachement.
Is it a matter of getting the resistor value as low as possible (1K), but with more noise you'll also need higher resistor values (such as 10K, which in turn will weaken the square wave signal), so 4.7K might be a compromise? Unless the 20cm cable of mine makes a difference that is...

[Fujiyama]

Spiny, I just saw your pictures (which I didn't see when posting the above). I should have done a refresh of the page first!
Thanks for your efforts. Your RTC module is different from mine, but the connections to my (Mega STe) MonSTer board pins are the same.

You cleared up one thing for me: I thought the resistors were to be placed at the end of each of the two signal wires (i.e. between the MonSTer SDA pin and the RTC SDA pin, and another resistor between the MonSTer SCL pin and the RTC SCL pin) while it is in fact between the RTC module's SDA pin and the same module's GND, and similarly a resistor between the RTC module's SCL pin and the same RTC module's GND).
Did you use 10K resistors as Alanh suggested or something else.

Fortunately I don't need to add a veroboard with mine as it's just a matter of soldering in the two resistors on the RTC module board itself once I have the right resistor values.

[Fujiyama]

Does the need for the Y2K fix or not apply for all sorts of clocks in a plain ST/STe (internal clock boards, RTC modules attached to the MonSTer, clock cartridges etc.)?

The Y2K-fix applies to all ST's that does not have the Mega/MegaSTE/Stacy RTC. However, if you use a third party RTC and some autofolder utility to update GEMDOS time from this, TOS 1 usually does not need to be patched (depending on how the RTC software works). In this case only TOS 2.x is affected on these machines.

I guess I'm wondering how the computer knows if it should use the keyboard processor or whatever else the Mega STe/STacy/Mega ST uses?

TOS from 1.02 and upwards will attempt to access the Mega/MegaSTE/Stacy RTC when booting. If the RTC responds, TOS will read the RTC and update the GEMDOS internal clock (a pure software clock running off the 200Hz timer interrupt) with the RTC time/date. From then on GEMDOS will only refer to this software clock, not the RTC.

If the RTC does not respond TOS reads the time/date from the keyboard processor and sets the GEMDOS time to this. A warm reset does not reset the keyboard clock so you don't have to set the time/date after a warm reset.

The original Atari RTC (or keyboard clock if no RTC is present) is only accessed by TOS in these cases:

1. When booting the GEMDOS clock is updated with RTC time/date.
2. When the XBIOS Settime/Setdate functions are called. These are the interface to the RTC hardware, used to change RTC time/date.
3. In TOS 2 the RTC will be updated also when the GEMDOS time/date is changed using the GEMDOS Tsettime/Tsetdate calls. TOS then reads back the time from the RTC and updates it's internal GEMDOS clock according to this. This does not happen in TOS 1.

(3) is important, and the reason why TOS 2 needs to be patched when using an aftermarket RTC. The RTC software reads time/date from this custom RTC, and sets GEMDOS time accordingly using Tsettime/Tsetdate. Because there is no stock RTC, TOS falls back to the keyboard clock and when reading back the year the year is wrong. On a Mega/MegaSTE this is not a problem, because the keyboard clock is never used by TOS in this case.

So why is the keyboard clock year wrong? Because GEMDOS year 0 is actually 1980, while keyboard clock year is the last two digits of the actual year. So GEMDOS year 10 is displayed as 1990, and inside the keyboard clock it's stored as 90. This means that when TOS updates the keyboard clock, it actually writes GEMDOS year + 80, and when reading keyboard clock it reads keyboard year - 80.

Now, this is no problem when year is between 1980 and 1999. But try to do this math with a year after 2000, and you'll see that this does not add up

It is not a problem with the original RTC, because RTC year 0 is also 1980 so no conversion is needed between RTC and GEMDOS time.

So to sum up this rather confusing post - when using a MonSTer RTC and the M_RTC.PRG utility the Y2K fix is only needed on machines with TOS 2 and no original Atari RTC. I don't know if MagiC is affected. EmuTOS is not.

Thanks. You already explained it in this thread though I must admit I don't fully understand it yet. My big question is how TOS "knows" if a clock was factory fitted by Atari as part of the motherboard design (e.g. my Mega STe) or if an after-market third party clock board (as in my STe where I've placed a battery-backed clock between one of the TOS EPROM sockets and the EPROM itself)? You mention something about after-market clocks above, but I'm a little slow at getting it. Sorry

Is the difference (between needing a Y2K fix patch or not) really if the computer has no clock at all or if it has a hardware battery-backed clock (regardless of it being part of the Atari motherboard design or added as a 3rd party board later)? At least I get that the keyboard clock is the one causing problems (and thus needs a Y2K fix of some kind), but I don't get why TOS falls back to this keyboard clock when in fact the computer has a battery backed hardware clock already (my STe with the clock board in the TOS socket).

PS. I realize I've quoted the entire posting but though it necessary to get things straight.

[joska]

My big question is how TOS "knows" if a clock was factory fitted by Atari as part of the motherboard design (e.g. my Mega STe) or if an after-market third party clock board (as in my STe where I've placed a battery-backed clock between one of the TOS EPROM sockets and the EPROM itself)?

TOS only knows about the factory fitted RTC, or retrofitted RTC of the exact same type. If any other RTC is fitted TOS will never know about it, and you need a separate "driver" for it.

Is the difference (between needing a Y2K fix patch or not) really if the computer has no clock at all or if it has a hardware battery-backed clock (regardless of it being part of the Atari motherboard design or added as a 3rd party board later)? At least I get that the keyboard clock is the one causing problems (and thus needs a Y2K fix of some kind), but I don't get why TOS falls back to this keyboard clock when in fact the computer has a battery backed hardware clock already (my STe with the clock board in the TOS socket).

You can retrofit your STE with an atomic clock if you want, it does not help if TOS doesn't know how to talk to it Of course, the RTC driver could replace TOS' Settime/Setdate XBIOS functions, in that case there will be no Y2K-bug even with a non-standard RTC. But I don't think many RTC drivers does that. It's one way to work around the Y2K bug in TOS 2, but since most (all?) retrofitted RTC's were made long before Y2K I don't think anybody cared/bothered.

Again, with a MonSTer RTC you only need a Y2K-patch if you have an ST/E *without* a factory fitted RTC *and* you're using TOS 2. With your MegaSTE the Y2K-patch is not needed and has no effect.

[Fujiyama]

The Mega STe clock circuitry doesn't appear to have any "identifying" logic built in (ROM, PAL, GAL etc.) so an estimated guess is that the clock (time/date) signal goes to somewhere else in the comupter than the after-market clocks, and TOS therefore understands this is a built-in clock.
Regardless, as long as I can't add a "factory built-in" clock to my STe (not Mega STe) it doesn't matter and the patch is the only way.

As long as the patch doesn't involve a lot of messing about and doing geeky things (like this solution, which I tried out and does work) I'm OK with having it in my AUTO folder or as a patched version of TOS 2.06 which can be burnt into EPROMs or flashed into the MonSTer board.
I haven't tried it yet, but from this posting of yours it appears I first need to read the TOS EPROMs (in order to get a TOS dump), then run the TOSdump file through the Y2K patcher to have it create a new, Y2K patched TOSdump file which can be used for burning new TOS EPROMs or flash the MonSTer board, correct? From then on I assume it's just a matter of setting the time any way you like such as through the Xcontrol control panel accessory?

I know several Atari users who don't have MonSTer boards (some without hard drives even) -do you have a similar patcher which can be put in the AUTO folder?

[joska]

I haven't tried it yet, but from this posting of yours it appears I first need to read the TOS EPROMs (in order to get a TOS dump), then run the TOSdump file through the Y2K patcher to have it create a new, Y2K patched TOSdump file which can be used for burning new TOS EPROMs or flash the MonSTer board, correct?

Correct. Or just download the desired TOS-image and then patch it.

From then on I assume it's just a matter of setting the time any way you like such as through the Xcontrol control panel accessory?

Yes, everything works just like normal, as long as you don't try to set a date before 2000. Shouldn't be a problem now...

I know several Atari users who don't have MonSTer boards (some without hard drives even) -do you have a similar patcher which can be put in the AUTO folder?

The nature of this patch is to modify the TOS binary itself. So if anybody wants to use this patch but not flash/burn it to a TOS ROM, they would have to load and run the patched TOS with SELTOS.

[Fujiyama]

That sounds good!
I like solutions which the user can forget about once set.
I will look into patching TOS myself, then try to flash them on to the MonSTer. I've never done it before and it appeared a little complicating judging by previous discussions, but I believe you posted a "how to" on that a while back (in the MonSTer thread I think?).

I know several Atari users who don't have MonSTer boards (some without hard drives even) -do you have a similar patcher which can be put in the AUTO folder?

The nature of this patch is to modify the TOS binary itself. So if anybody wants to use this patch but not flash/burn it to a TOS ROM, they would have to load and run the patched TOS with SELTOS.

I think I used SELTOS many years ago when experimenting with TOS 2.06 -it loads TOS (preferrably a patched one) from a file into RAM, right?
I know several musicians who still uses the ST for MIDI purposes and I was looking for a solution for them. Using up the preacious RAM isn't such a good idea IMHO as that would be used for MIDI. Are there other ("install and forget" type of) Y2K solutions around which go in the Auto folder?

[spiny]

I'm not using any kind of patched TOS, I'm just using the clock set PRG from Alan, which I have put ion the AUTO folder of my hard drive.

[Fujiyama]

I'm not using any kind of patched TOS, I'm just using the clock set PRG from Alan, which I have put ion the AUTO folder of my hard drive.

What kind of Atari are you using?
You mean the RTC software found on the MonSTer ordering/info page?
So you're saying that by putting it in the AUTO folder it does the Y2K fix upon booting so you don't have to re-enter the current date/time?


Back to the pullup resistors I looked up several sites where several of them mentioned 10K, likewise the DS3231 "Chronodot" RTC module's own site where it says "Since many devices that have I2C buses already have the resistors in place, these are not provided with the ChronoDot. But there are two locations for 4.7K or 10K resistors to be soldered, in case your controlling device does not have its own pullup resistors" so I went for two 10K resistors as Alanh suggested.

For some reason though the time isn't kept after powering off the computer, then on again later. The battery is brand new and all the connections are good.

[spiny]

I'm not using any kind of patched TOS, I'm just using the clock set PRG from Alan, which I have put ion the AUTO folder of my hard drive.

What kind of Atari are you using?
You mean the RTC software found on the MonSTer ordering/info page?
So you're saying that by putting it in the AUTO folder it does the Y2K fix upon booting so you don't have to re-enter the current date/time?

in a word, yes the software sets the clock properly, when i save files the date and year are correct.
I'm using an STM for this one, but I see no reason that it won't also work on an STe.

Back to the pullup resistors I looked up several sites where several of them mentioned 10K, likewise the DS3231 "Chronodot" RTC module's own site where it says "Since many devices that have I2C buses already have the resistors in place, these are not provided with the ChronoDot. But there are two locations for 4.7K or 10K resistors to be soldered, in case your controlling device does not have its own pullup resistors" so I went for two 10K resistors as Alanh suggested.

For some reason though the time isn't kept after powering off the computer, then on again later. The battery is brand new and all the connections are good.

do you mean the time is not read correctly, or that the time on the RTC itself is resetting to some default value ?

[spiny]

just to confirm, this is how I have wired the resistors on my setup. I used 1k, as that was all I had at the time, but they seem to work and the clock and clock software are working.

rtc.png

[Fujiyama]

What kind of Atari are you using?
You mean the RTC software found on the MonSTer ordering/info page?
So you're saying that by putting it in the AUTO folder it does the Y2K fix upon booting so you don't have to re-enter the current date/time?

in a word, yes the software sets the clock properly, when i save files the date and year are correct.
I'm using an STM for this one, but I see no reason that it won't also work on an STe.

Interesting. I'll have to give that a go.

For some reason though the time isn't kept after powering off the computer, then on again later. The battery is brand new and all the connections are good.

do you mean the time is not read correctly, or that the time on the RTC itself is resetting to some default value ?

When I turn on the computer again I have the time/date showing some random values. I believe the time is read correctly, because I've tried doing a reset after setting the time/date, and it displays it correctly after restarting.
I find LEDpanel very useful for testing this sort of thing as I can configure it to show the time/date (and other things) in the menu bar. Just put it in the AUTO folder. A separate configuration program is used to set which things you want to see etc.

[Fujiyama]

just to confirm, this is how I have wired the resistors on my setup. I used 1k, as that was all I had at the time, but they seem to work and the clock and clock software are working.

rtc.png

I put the pullup resistors in the empty places for them on the RTC board but I will check to see if the connections are the same as yours.

What happened before putting the pullup resistors in place? Did the clock not remember the time/date after turning off the computer, just like I'm experiencing, or something else?

[spiny]

before i put the resistors in, the PRG from alan was unable to read the time, so the ST just defaulted to the factory value of 1987 as it would if there was no clock fitted.

I use LEDPanel too, it's very useful

[Fujiyama]

I just checked, and my Chronot RTC module appears to have the same pullup connections as yours.
The DS3231 should be compatible with the DS1307 (as mentioned here and here), and Alanh said that the DS1307 is compatible with the DS1338 (provided it's fed +5V instead of +3.3V as the MonSTer outputs), so the conclusion is that they should all be useable with the MonSTer.

Apart from checking that the battery reaches the correct pins of the DS3231 and the wires to the MonSTer are good, is there something else I can check? I have a multimeter and a small oscilloscope.

My clock doesn't default to 1987 like yours but to 00-00-95 00:01:xx (I can't remember the seconds) when I powered up the Mega STe again (it's been turned off since yesterday, so no capacitor could be keeping the time). Then I turned it off again for a couple of minutes, turned it on again and to my surprise the clock had changed to 00-00-95 00:04:xx
So it appears to somewhat keep the time, but not correctly. Strange. I'll turn it off again, keep track of the time and on again to see what comes up as the time......

So my next test:
1) wait till the clock shows exactly 00:09:00, then immediately turn the computer off
2) start a stopwatch
3) wait until exactly 5 minutes has passed on the stopwatch, then turn on the computer again
4) if the RTC module is keeping track of time with its battery, the clock on the ST should now show "00:14:xx" ("xx" being the second it takes for it to boot and any additional time it takes to get to the stopwatch etc.)

Nope... when I turn on the ST's power again and reboot the clock shows: 00-09-95 00:11.20
This doesn't make much sense to me. At least the clock has kept going and not reset to 00:00:xx but the minutes elapsed are completely wrong, so something is messing it up. Perhaps the cheap eBay RTC module just doesn't work properly.

[Fujiyama]

I think I've solved the problem by putting M_RTC.PRG (the RTC module setter found at Alanh's MonSTer page) in the AUTO folder (just like you mentioned doing), and somehow after booting the garbled time is turned into the correct time! So simple!
There really should be a small readme with the MonSTer RTC software as it isn't obvious that it acts as a RTC module driver in addition to being a date/time setter.

I'm going to continue testing by having the Mega STe turned off for extended periods of time then power up again and see, but that program in the AUTO folder seems to do the trick.

When I get my STe out (currently without a MonSTer board) which has a clock board (a small circuit board with a battery in between one of the TOS EPROMs and its IC socket) it'll be interesting to see if the same Monster RTC software will act as a Y2K fix.

[spiny]

yes, TOS is not 'aware' of RTC devices, so you need to have some way of 'reading' the time from the RTC, then 'writing' the time to the system on boot. the RTC.PRG does this

[Fujiyama]

That makes sense as per Joska's explanation of the difference between built-in and factory installed RTC circuitry.
... so despite the Mega STe already having a built-in clock, when attaching a RTC module to the MonSTer board it seems the computer recognizes an additional add-on (non-standard) clock, hence the need for additional driver software.

Is it correct to assume that the clock hardware isn't (usually) the source of the Y2K problems but just the keyboard clock limitation, so additional software is needed to translate and fix this for TOS to be able to use?

[spiny]

Is it correct to assume that the clock hardware isn't (usually) the source of the Y2K problems but just the keyboard clock limitation, so additional software is needed to translate and fix this for TOS to be able to use?

to the best of my knowledge, yes. the Y2K issues are with much older RTC hardware, like the 'forget-me-clock' and similar which didn't roll over from 99 to 00 properly I believe.

the Dallas RTCs are fine, and the software from Alan will be reading and writing the date correctly anyway, as it was written recently.

[joska]

I'm going to continue testing by having the Mega STe turned off for extended periods of time then power up again and see, but that program in the AUTO folder seems to do the trick.

That's because without this program in the auto-folder the MonSTEr RTC is never used... But I don't understand why you would want to use a retrofitted RTC in your Mega STE? It has it's own RTC, adding another RTC does only one thing - complicate stuff.

When I get my STe out (currently without a MonSTer board) which has a clock board (a small circuit board with a battery in between one of the TOS EPROMs and its IC socket) it'll be interesting to see if the same Monster RTC software will act as a Y2K fix.

TOS does not know ANY OTHER RTC than the original, factory fitted RTC you'll find in the Mega, Mega STE and Stacy. Is the retrofitted RTC in your STE of this type, or does that STE have any other OS than TOS 2.0x? If yes to either of these questions, then you have no Y2K problem on that machine. Don't do anything, just set time/date with the Control Panel and leave it alone. Oh, and make sure that the battery is OK.

If it's NOT of the same type as the original, factory fitted Mega/Stacy RTC you'll need the driver for this RTC to be able to use it. Depending on the RTC and the driver this may or may not handle the Y2K bug. But unless the RTC driver (not the MonSTer RTC driver, but the driver for the particular RTC in that particular machine) hacks around the Y2K-bug somehow you WILL need a patched TOS or other Y2K-fix to avoid the Y2K-bug.

The only reason why the MonSTer RTC driver fixed the time/date-problem on your Mega STE is that you probably don't have a battery for the original, factory-fitted RTC, and when the MonSTer RTC driver was installed the MonSTer RTC was actually being read. The MonSTer RTC driver is NOT a Y2K-fix at all, and I can assure you that it will have no other effect than slowing down boot on any machine that does not have a MonSTer and a DS1338-compatible RTC connected to the MonSTer.

[GokMasE]

just to confirm, this is how I have wired the resistors on my setup. I used 1k, as that was all I had at the time, but they seem to work and the clock and clock software are working.

rtc.png

I forgot to say thanks for all the pics and info you uploaded, much appreciated!

Since I previously was not familiar with the concept of pull up resistors, I could easily have installed them completely wrong.
Your explanation did for sure clear up that and a few other things.

This is my take on adding the needed resistors:


(There wasn't much space, so had to use both sides of the board to make the resistors fit)


Hopefully I got it right, at least nothing has been shortened


Regards,

/Joakim

[spiny]

This is my take on adding the needed resistors:


(There wasn't much space, so had to use both sides of the board to make the resistors fit)


Hopefully I got it right, at least nothing has been shortened


Regards,

/Joakim

thats a good idea, I may re-solder mine like that, it'll take up less space

[Fujiyama]

I'm going to continue testing by having the Mega STe turned off for extended periods of time then power up again and see, but that program in the AUTO folder seems to do the trick.

That's because without this program in the auto-folder the MonSTEr RTC is never used... But I don't understand why you would want to use a retrofitted RTC in your Mega STE? It has it's own RTC, adding another RTC does only one thing - complicate stuff.

Because the expensive/hard-to-find lithium battery inside the Mega STe is dead, and with a MonSTer board installed I thought it might be a good idea to try out one of those cheap eBay RTC modules which uses easily available and cheap coin cell batteries.

When I get my STe out (currently without a MonSTer board) which has a clock board (a small circuit board with a battery in between one of the TOS EPROMs and its IC socket) it'll be interesting to see if the same Monster RTC software will act as a Y2K fix.

TOS does not know ANY OTHER RTC than the original, factory fitted RTC you'll find in the Mega, Mega STE and Stacy. Is the retrofitted RTC in your STE of this type, or does that STE have any other OS than TOS 2.0x? If yes to either of these questions, then you have no Y2K problem on that machine. Don't do anything, just set time/date with the Control Panel and leave it alone. Oh, and make sure that the battery is OK.

No to both. I'm using TOS 2.06.

If it's NOT of the same type as the original, factory fitted Mega/Stacy RTC you'll need the driver for this RTC to be able to use it. Depending on the RTC and the driver this may or may not handle the Y2K bug. But unless the RTC driver (not the MonSTer RTC driver, but the driver for the particular RTC in that particular machine) hacks around the Y2K-bug somehow you WILL need a patched TOS or other Y2K-fix to avoid the Y2K-bug.

I believe I was told the clock didn't need any software at all and was completely transparent to the rest of the computer. I can't remember the manufacturer but it might have been Hard & Soft from Germany. I can take a closer look if needed and also see what kind of chip it uses.
I'm still working on the Mega STe in order to get it fully up and running but will get to the STe next.

The only reason why the MonSTer RTC driver fixed the time/date-problem on your Mega STE is that you probably don't have a battery for the original, factory-fitted RTC, and when the MonSTer RTC driver was installed the MonSTer RTC was actually being read. The MonSTer RTC driver is NOT a Y2K-fix at all, and I can assure you that it will have no other effect than slowing down boot on any machine that does not have a MonSTer and a DS1338-compatible RTC connected to the MonSTer.

Correct. There's no battery connected to the original Mega STe clock.
With a patched TOS 2.06 flashed into the MonSTer I shouldn't have any issues with the add-on clock board in the STe. If it turns out the clock hardware itself has Y2K issues I can always add a DS1338 compatible RTC to it because I plan to buy a MonSTer board for it as well.

But it would be nice to present a Y2K solution (with or without a battery backed add-on clock) for my musician friends who aren't going for a MonSTer board.