Jetz könte ich etwas Hilfe gebrauchen. Und es gibt hier wohl einige Leute die ich mit die Sache auskennen.....
Mein Problem: Ich möchte eien Echtzeit Uhr haben der mit Sparta-Dos zusammen arbeitet.
Da hab ich also den ARC Clock gebaut. Zwei Varianten, auf den internen SDX und auch als Cartridge.
Die gehen aber beide nicht, obwohl ich ziemlich sicher bin die Hardware ist ok.
Und auch eine andere Uhr geht nicht richtig. (Aber mit meine alten Programme alles prima)

Nun mal die Frage:
Wie soll ich genau vorgehen um die Uhr unter Sparta-Dos zu benützen.
Also wass muss im "Autoexec.bat" welche Treiber brauch ich?
Es gibt ARCLOCK, Z, TD, TDLINE, JTC.
Nach ein Reset sollte die Zeit noch stimmen.
Wie mach ich das?

guus hat geschrieben:Jetz könte ich etwas Hilfe gebrauchen. Und es gibt hier wohl einige Leute die ich mit die Sache auskennen.....
Mein Problem: Ich möchte eien Echtzeit Uhr haben der mit Sparta-Dos zusammen arbeitet.
Da hab ich also den ARC Clock gebaut. Zwei Varianten, auf den internen SDX und auch als Cartridge.
Die gehen aber beide nicht, obwohl ich ziemlich sicher bin die Hardware ist ok.
Und auch eine andere Uhr geht nicht richtig. (Aber mit meine alten Programme alles prima)

Nun mal die Frage:
Wie soll ich genau vorgehen um die Uhr unter Sparta-Dos zu benützen.
Also wass muss im "Autoexec.bat" welche Treiber brauch ich?
Es gibt ARCLOCK, Z, TD, TDLINE, JTC.
Nach ein Reset sollte die Zeit noch stimmen.
Wie mach ich das?

Hallo Guus!

Hast eine E-Mail ...

Den Schaltplan hab ich von eine Polnische Website. (Start bei Draco, dann link züm SDX folgen.)
Ich hab den 6242 und 72... Uhrenchip beide probiert.
Heute Abend werde ich versuchen den Schaltplan hoch zu laden.

Wie soll ich den Autorun.exe erstellen, in welche reinfolge kommen die Treiber?

Die Schaltpläne sind in PDF.
Leider kann ich die nicht hochladen.
Der Entwurf ist von Pasiu.

guus hat geschrieben:Die Schaltpläne sind in PDF.
Leider kann ich die nicht hochladen.
Der Entwurf ist von Pasiu.

http://hardware.atari8.info/ und http://atariki.krap.pl/index.php/ARC_(zegar)

Stimmt, diese sind die Schaltpläne.
Auch hab ich die Interne variante, mit den GAL.
Und die Ausgänge hab ich getestet auf eine Expermentier-Platine. (Breadboard)
Geht alles gut.
Auch hab ich mit verschiedene Atari's getestet.....

Die RTC in der SDX-Cart nach dem Schaltplan von Pasiu funktioniert.
so sieht es aus, wenn man TD ON setzt ...

GoodByteXL hat geschrieben:Die RTC nach dem Schaltplan von Pasiu funktioniert. ...

Die RTC 72421A von EPSON scheint die bessere Wahl zu sein, da diese einen internen Oszillator hat. Die M6264B benötigt einen externen Oszillator, der dann genau eingestellt werden muss, was sicher nicht ganz einfach ist. Wen ich mich recht erinnere, war das auch ein Problem der R Time 8.

Bei den RT 8 weiss ich nicht.
Aber beide, den 6264 und 72421 haben an Pin 1 ein Ausgang. Wenn diese mit ein Pull-Up versehen wird, erscheint dort ein Puls.
Den Frequenz kann eingestellt werden im Register den RTC's.
So ist diesen Ausgang auch für Frequenzabgleich zu benützen.

guus hat geschrieben:Bei den RT 8 weiss ich nicht.
Aber beide, den 6264 und 72421 haben an Pin 1 ein Ausgang. Wenn diese mit ein Pull-Up versehen wird, erscheint dort ein Puls.
Den Frequenz kann eingestellt werden im Register den RTC's.
So ist diesen Ausgang auch für Frequenzabgleich zu benützen.

Hm, interessant, und wie macht man das dann?

In dem Datenblatt vom 72421 steht auf Seite 8 die Struktur einer der Controll-Register.
Da ist den Ausgangspuls ein zu stellen. Auch auf 1/64-e Secunde. (64Hz)
Diese Frequenz ist mit viele Universal Messgeräte zu messen. Dies ist nicht so genau, gibt aber shon eine Richtung.
Und danach ist mit das gleiche Trimpoti (Bein Quartz Version) die Zeit zu corrigieren.
Den Datenblatt kann ich gerne zuschicken. (Ist aber auch bei Epson zu finden)

Sorry for English Reply,

A few days ago I bought a DS1307 board. This is an I2C based RTC. Bob1200XL (on AtariAge) wrote some routines for this RTC, and I made those routines work with SpartaDos.

Most of my atari's did not let the RTC operate connected to the joystick port. But... when I installed the RTC inside the atari, direct connected to PA0 and PA1 of PIA, it works perfect.

Ofcourse it is not really a REALTIME, since you have to download time from the RTC to atari, but for most purpouses that's good enough.

When the Atari is switched off the time continues running through a battery (also installed on the PCB)

I'm very excited about these boards. They seem to work great, and are not expensive (around 6-7 euro)

Greetz
M.

Hi Marius,

Marius hat geschrieben:A few days ago I bought a DS1307 board. This is an I2C based RTC. Bob1200XL (on AtariAge) wrote some routines for this RTC, and I made those routines work with SpartaDos.

Sounds interesting. Do you have more informations or links? Myself thoughts about using an I2C based RTC, but if somebody else have already done it, it´s not needed to reinvent the wheel.

Marius hat geschrieben:Most of my atari's did not let the RTC operate connected to the joystick port. But... when I installed the RTC inside the atari, direct connected to PA0 and PA1 of PIA, it works perfect.

I think this is a result of the weak output drivers from the PIA and the resistors and coils in the line from PIA to joystick port.

Solution: Use a standard transistor (i.e. BC547) to drive the RTC´s input and don´t connect the PA-pins directly. The software must negotiate the output, of course - or you use two complement transistors in serial.

Regards, Juergen

To accomodate also the non-German reply, I'll continue in English as well.

My RTC finally works. Thanks to the help of GoodbyteXL and some more people.
The hardware has been ok from the start. (Other than some better protection for power outage, it's fine)
But the right drivers in the correct order need to be loaded, using CONFIG.SYS.
Also, the driver ARCLOCK5.SYS /F is needed for good operation. This is a very new piece of software, hence the 5 in the name.

I do also have a clock using IIC. It's based on a Philips chip, the PCF 8583 in SMD version. (Big SMD-chip)
There's also room for a 24C16 or other EEprom in a DIL housing.
It also has an LED that can blink once per second and interrupt capabilities under chip/software controll.
The PCB has a sub-D connector that plugs into a cartdidge port.
And the drivers were written by Hias.
For now, I still want to do some testing and try to get it to work with Sparta-Dos.
But if anyone is interested, all data can be made available. Just ask and provide the E-mail address to send it to.

There's two ways to get the IIC bus working well on the outside of the Atari.
1) Slow down the clock, this makes communication slower than it can be, but no alterations are needed.
2) Remove the capacitors on the clock and data lines. Short circuit the chokes is also a good idea.

@guus

Slowing down the clock did not work for I2C RTC! I created a program in Basic to monitor the joystick/pia lines and watch what happened on every step. I manually could drive SCL high and low with this little basic program and watch the results.

It simply failed. It probably has something to do with lines not going high or low enough.

In assembler it failed too. I patched the working routines. I inserted a JSR PAUSE routine after each clock instruction, but that was not the solution.

Since I'm not a hardware man, I can not invent solutions with transistors or other components. the only thing I could think of was directly connect my I2C RTC boad to Pia and that works great. It's installed for about 3 or 4 weeks now in my Atari and it works perfect. No problems so far. Since I already installed my RF shield back I think i will leave it this way. It is not disturbing the joystick or paddle controlers. I'm not sure about other joystickport hardware like XEP80, but since I don't use that... it is not important for me.

Only problem with this RTC board is that it gains around 5 seconds a week. Since there is no trimmer on this I2C RTC board, I can not easily fix this. 5 seconds a week is not really an issue for me, but it is still around 4 or 5 minutes a year.

Somewhere in January I wrote a small tool that downloads time from a timeserver to my Atari. This works through my Lantronix MSS100. Now I updated this tool a bit... now it downloads time from timeserver and put time and date in that I2C RTC board. So once a month I run this tool and I'm right-in-time again

I had no need yet to create a set-time-through-command-line tool. To set time manually I have to go to mac/65 and put the right time into a string and run the program. So no releasing time yet. Sorry...

If someone really want and/or need it... let me know, it might work on it again.

Greetz
M.

Hi Marius!

Marius hat geschrieben:Slowing down the clock did not work for I2C RTC! I created a program in Basic to monitor the joystick/pia lines and watch what happened on every step. I manually could drive SCL high and low with this little basic program and watch the results.

It simply failed. It probably has something to do with lines not going high or low enough.

Most certainly this is because of the slowly rising/falling edges on the joystick port (due to the inductors and capacitors on the joystick port lines). I had similar problems when I tried to run JTAG over the joystick port - it didn't work at all (tons of errors) but worked perfectly fine when I connected the wires directly to the PIA.

You could try adding schmitt-triggers to the output lines, but this also means you have to change the interface: SCL is easy, as it's only used for output. But SDA is a little bit more complicated (since it's used for both output and input). The easiest solution would be to use 2 PIA ports for SDA: one for output, running through a schmitt trigger and a diode (to make it "open collector") and another one for the input. You'd then use, for example, PA0 for SDA out and PA1 for SDA in. Whenever you are doing inputs you have to set PA0 to high, so that it's unconnected ("open collector"). This is the way it's implemented in a lot of I2C interfaces.

BTW: The new Turbo Freezer will have a builtin I2C interface (which is also brought out to an external connector) plus a DS1307. I'm currently thinking about where to map it into address space (most certainly it'll be somewhere at $D5xx) and I also plan to add SDX 128k support together with a "stackable cart" feature into the new CartEmu logic. Now I just need to find the time to implement the logic and new software...

so long,

Hias

Hi Marius!

Marius hat geschrieben:Only problem with this RTC board is that it gains around 5 seconds a week. Since there is no trimmer on this I2C RTC board, I can not easily fix this. 5 seconds a week is not really an issue for me, but it is still around 4 or 5 minutes a year.

There's not much you can do about this, this is approx. within specs. Most 32kHz crystals are specced at +/- 20ppm accuracy, and since a week has approx. 600000 seconds that would be +/- 12 seconds per week over the specced temperature range.

BTW: There's an appnote about crystals and RTCs on the Dallas/Maxim website which contains more detailled information and recommendations for board layout etc.
http://www.maxim-ic.com/app-notes/index.mvp/id/58

so long,

Hias

HiassofT hat geschrieben:BTW: The new Turbo Freezer will have a builtin I2C interface (which is also brought out to an external connector) plus a DS1307. I'm currently thinking about where to map it into address space (most certainly it'll be somewhere at $D5xx) and I also plan to add SDX 128k support together with a "stackable cart" feature into the new CartEmu logic. Now I just need to find the time to implement the logic and new software...

I just saw this. Hias, if you're planning a new Freezer with expanded SDX support, then maybe it is worth saying that we're planning to enlarge the TF2005 builds of SDX to 256k. This way the *.MAN files (command manuals) would fit on the cartridge. So maybe it makes sense to provide 256k for SDX in the new freezer, because otherwise neither option would give full functionality (TF build - MAN files, but no passthrough connector; SDX emulation - passthrough connector, but no MAN files).

KMK hat geschrieben:I just saw this. Hias, if you're planning a new Freezer with expanded SDX support, then maybe it is worth saying that we're planning to enlarge the TF2005 builds of SDX to 256k. This way the *.MAN files (command manuals) would fit on the cartridge. So maybe it makes sense to provide 256k for SDX in the new freezer, because otherwise neither option would give full functionality (TF build - MAN files, but no passthrough connector; SDX emulation - passthrough connector, but no MAN files).

Thanks for the info!

I'm currently thinking about adopting the same banking scheme candle uses with his ultimate 1mb upgrade instead of the 128k int-SDX scheme. I never liked the convoluted, inverted (int-)SDX scheme too much, having a simple 6-bit bank register plus 2 config bits is a lot easier to implement. We'd then have plenty of space for SDX and you don't need to release yet another SDX version.

so long,

Hias