R-Time8 problem

[+Stephen]

no doubt... find the chips, PCB's are easy ;')

 

sloopy.

Would this be an easy chip to reproduce with a PIC?

[russg]

So what do you think actually "fixed" it?

 

I'm particularly interested because mine has much the same behavior. (Although it looks a bit better than yours... ) Mine will work for a while then won't come up, etc. I touched up all the solder joints and that fixed it for a time, then same thing all over again.

 

-Larry

 

I know what fixed it. The only thing I did was replace the 138 chip, everything else I did had the potential to make it still not work, a solder bridge, an open place where solder should have made contact, a

broken trace on the circuit board with my thumb fisted technique, lots of things could have gone wrong, but only one thing fixed it and it was the new 138.

Are your edge contacts intact? I had to put solder on some of mine, it made it work once before. The edge contacts are gold plated, I think, and the gold wears off.

There can only be a few components go bad, because there are only a few components. I got every component except the vary capacitor and M3002. Check Fox-1 schematic and see if you have voltage

where there should be with the battery connected and continuity where there should be, like between pins 6 and 7 of the M3002 and pin 7 of the 138. You can check the traces by touching a trace

and one of the corresponding circles on the circuit board. The circles look covered with non-conductive green, but actually if you touch one with the ohm meter, it will make electrical contact.

I don't know how to use an oscilloscope, altho I have one. Nor a logic probe. There are address and data lines and I don't know what they're supposed to be. A sure way to test the

RT8 is to load RTIME8.COM Z: driver, if it loads, the RT8 is OK.

Edited January 28, 2012 by russg

[russg]

Hello all,

 

I just had a look at the schematics that I have for this RTC.

There must be some provision that prevents the battery from powering the computer, that's obvious.

And there are no diodes on the outside of the battery or RTC-chip. That much is certain.

So the chip has the circuits inside.

But the capacitor and timer-crystal are also connected to pin 1, just as the battery minus.

For this reason I come to the conclusion that this chip will not function properly when there's no battery connected.

Maybe a resistor (10K or so?) will also do.

And if you'd like to use a goldcap, that can also work fine.

In such case, place the charging resistor and a diode between the minus of the cap and GND. (e.g. pin 8 of the LS138)

The cathode of the diode (Ring on housing) to the GND.

Charching resistor has to limit the current into tha cap, as this would be much too high for cap and supply. about 100 Ohm is fine.

 

The fact that te computer hangs when the clock is present can also mean that the oscillator is not runing. (as expected)

In such case, it will not be possible to read the clock registers.

But if the LS138 is functioning, the clock will appear to be present.

So the program will keep trying to read the clock.

 

BR/

Guus

.... 'The oscillator....' Is the oscillator in the M3002? If I understand what you're saying, if the M3002 is bad, and TDLINE is installed, it will give a constant reading, not update the seconds, meaning the 138 is good.

[russg]

no doubt... find the chips, PCB's are easy ;')

 

sloopy.

I searched for some M3002. The company in Switzerland that made them, EM-MICROELECTRONIC-MARIN SA no longer mentions them. I found some places people looking for them, but no source.

There was one that said someplace in Israel had one to sell and in Germany had two, probably five years ago.

Edited January 28, 2012 by russg

[sloopy]

no doubt... find the chips, PCB's are easy ;')

 

sloopy.

I searched for some M3002. The company in Switzerland that made them, EM-MICROELECTRONIC-MARIN SA no longer mentions them. I found some places people looking for them, but no source.

There was one that said someplace in Israel had one to sell and in Germany had two, probably five years ago.

 

They havnt been made since 1990... making something new would be a better idea... I have a bunch of DS1302's just sitting here doing nothing...

 

sloopy.

[Fox-1 / mnx]

I searched for some M3002. The company in Switzerland that made them, EM-MICROELECTRONIC-MARIN SA no longer mentions them.

 

"Floppy-Doc" (ABBUC) tried to find a supplier some years ago and didn't succeed. I did the same last year (or 2 years ago?) and the only thing I managed to get was the data sheet of M3002, from EM-Micro.

 

There are a lot of Asian "companies" claiming they can get them. Just don't believe them. I created a seperate email address before contacting about all of them, or better, a few of them as many of those different suppliers are just the same people using different names. As of today the only things received at that mail address are tons of mails advertizing their latest iPod docks, phone chargers, etc... Much like I expected actually.

[Marius]

As of today the only things received at that mail address are tons of mails advertizing their latest iPod docks, phone chargers, etc... Much like I expected actually.

 

Didn't you know that all those things they are advertising do actually contain that M3002 chip. They send you all that mails like a service!

[Fox-1 / mnx]

Didn't you know that all those things they are advertising do actually contain that M3002 chip.

You've got that right. I didn't knew.

[falcon_]

no doubt... find the chips, PCB's are easy ;')

 

sloopy.

Would this be an easy chip to reproduce with a PIC?

 

I second this thought. Couldn't the m3002 be emulated by a current AVR/PIC/ARM ??

 

@Fox-1 You have the datasheet, and certainly what is needed from the chip for the

atari clock to work is known. I say there could be a decent replacement made using

a new microcontroller for < $3.

 

Comments anyone?

[Fox-1 / mnx]

@Fox-1 You have the datasheet, and certainly what is needed from the chip for the

atari clock to work is known. I say there could be a decent replacement made using a new microcontroller for < $3.

 

I'm certain that someone who's familar with programming CLPD/PIC/etc. can make a hardware compatible clone. Unfortunately, I'm not one of them and not many people are interested in it as they seem to prefer the wildgrow of various other implementations of adding RTC's to the 8-bits like using the different flavors of the DSxxxx types.

 

I had the plan to dive into PIC's stuff to give it a try myself but since figuring out how to pay my next groceries it has a very low priority right now.

[guus.assmann]

Some time ago I discussed the same thing, about a PIC to emulate the clock chip.

And we came to the conclusion that it's not likely to get it done.

The PIC may be too slow for it.

As the clock chip may have a quite high acces speed that the PIC may not be able to match.

In this case, the data sheet might give some clues. But I've never been able to find the data sheet.

[guus.assmann]

Removed double post due to some hickup.

BR/

Guus

Edited January 30, 2012 by guus.assmann

[Marius]

A better solution would be a whole new creating a compatible RT8 cart, with probably more logic on it.

 

Needed: A dallas RTC (DS1305 or 1307 will do fine), A microcontroler with program that reads and sets time/data from Dallas RTC and translate it in the needed RT8 bit format.

 

Decent Logic that transfers it between the desired data/adress lines in Atari.

 

Although I'm not a technical genius, I think this is a rather realistic idea of creating a compatible RT8 solution.

 

I think DS1305 and DS1307 are very fine RTC chips. In both Ultimate1MB and Arduino boards they work fine. They are accessed real easy. The DS1307 uses I2C protocol.

 

Greetz

M.

[Fox-1 / mnx]

The PIC may be too slow for it. As the clock chip may have a quite high acces speed that the PIC may not be able to match.

As even 80MHz PIC's are available I find it hard to believe that it can't emulate a clock that runs at 32.768KHz

 

In this case, the data sheet might give some clues. But I've never been able to find the data sheet.

It's on my site: http://mixinc.net/atari/datasheet/datasht.htm

[guus.assmann]

Then consider the this:

At some point in time, the Atari computer will access the chip emulating the RTC.

The PIC will notice this, because of an interrupt.

Next the interrupt service routine has to determine 1: the command 2: register 3: data 4: fetch or store data 5:present data if applicable and finish the access.

All of this has to be done in such time that it looks like a RTC chip that manages this in about 20 to 40 nS.

 

Aside from the access, the PIC will have to keep track of the time. It's way fast enough for that, but is must not interfere with the access.

All of this is quite a big job and if done by a processor, takes a lot of time.

 

BR/

Guus

Edited January 30, 2012 by guus.assmann

[Fox-1 / mnx]

All of this has to be done in such time that it looks like a RTC chip that manages this in about 20 to 40 nS.

 

Since the RTC speed is over 1000 times slower then the PIC speed I still think this is not a problem at all.

 

But using a PIC to only translate the I/O from an external RTC is a better idea anyways. That way only the RTC has to have a battery or GoldCap. I can imagine a PIC would require more juice to keep it running compared to an RTC IC.

[sloopy]

wouldnt it be easier to make a new cart with a modern RTC? sure you would have to make a new driver, but its not that hard to make a driver, compared to all the work involved in emulating and old IC...

 

Why make a replica of a 25 year old wheel, when you can put a new tire on and just make a new lug pattern in the rim?

 

sloopy.

[Mathy]

Hello sloopy

 

Because the old wheel fits just about everything.

 

Mathy

[Fox-1 / mnx]

wouldnt it be easier to make a new cart with a modern RTC?

 

No need to develope one at all. There are several solutions all using their own implementation and driver.

 

I don't need a physical cart. I want to have the RTC into the Atari and I want it to be compatible. If I boot a random disk the RTC just has to work out of the box. If I switch systems I still want it to work. If I switch to a system without an internal RTC I want to put in an RT8 and still want it to work out of the box.

[guus.assmann]

Although it's not 100% on topic anymore.... The fast PIC's may work, but probably "on the tips of it's toes"

You make the same mistake that I initially did.

You compare the 32Kc or the (almost) 2Mc of the chip or computer with the PIC.

And that's where it goes wrong.

So I'll explain in another way.

Looking at the data sheet, you can see the access time of 150nS This equals about 6,6Mhz.

These 150nS is the time the chip has to "answer" to the CE and OE lines and present the data.

But the data is not coming from registers, the PIC has to present them on the I/O ports.

When running at 80Mhz, the cycle time is 12,5nS.

Now the PIC has 150/12,5 = 12 cycles to find out what's wanted and present the data.

It may be enough if the program is really good. And I'm not sure if 12 cycles is also 12 instructions.

To get it done, I guess a branch or fetch from a table is needed.

Unfortunatelly, I don't know the PIC well enough. So I'm not sure it's possible.

On the 6502, a branch or fetch from table needs more cycles.

 

On topic: Another clock with drivers would do fine in many cases.

And it is possible to make it so the data the driver produces is RT8 compatible.

BR/ Guus

Edited January 31, 2012 by guus.assmann

[Fox-1 / mnx]

You make the same mistake that I initially did. You compare the 32Kc or the (almost) 2Mc of the chip or computer with the PIC.

 

You obviously did a lot more research than I did.

 

I was actually thinking of a way different approach to get it to work but now I'm in doubt if that could ever work at all.

 

 

A simplified way of how I saw it:

 

Use 4 bi-directional (BCD) I/O lines, accessable by both the PIC and the cartridge bus. These I/O lines are a kind of buffer so the Atari never directly communicates with the PIC. All it does is sensing and setting these 4 signals. The PIC does the same from "the other side".

 

Both the Atari driver (I take Sparta-Dos as the default example) and the original RT8 hardware have a "busy" signal so there is no way that one "side" can change the status of the I/O lines while the "other side" is fiddling with it. One has to wait until the other is finished.

 

The same can be implemented in a PIC set-up. The PIC is just setting the I/O lines when he's at it, the Atari driver just reads it at request. The PIC doesn't have to update these I/O lines at an insane rate. Even when only updating once every 500mS or so would do.

 

Maybe I'm just taking the wrong approach.

 

 

On topic: Another clock with drivers would do fine in many cases.

And it is possible to make it so the data the driver produces is RT8 compatible.

 

And this is exactly what I'm trying to avoid. If I boot a Sparta-Dos partition from CD or an ATR (or any other DOS config that has been set-up to use the Z: driver) an original RT8 works out of the box because Sparta-Dos has the driver built-in. I consider this as a standard (others may disagree). Any other RTC will be useless as the driver is simply not there.

[+bob1200xl]

Looking at the clock chip from the outside world, it is essentially a block of RAM, with TOD data updated by the chip. So, not so difficult to set up - unless you use the timers and interrupts. (does it?)

 

Have the new 'clock' update SRAM while it shares access from the Atari side bus. Reads and writes can be done at way more than Atari speeds.

 

Bob

[Fox-1 / mnx]

Looking at the clock chip from the outside world, it is essentially a block of RAM, with TOD data updated by the chip. So, not so difficult to set up - unless you use the timers and interrupts. (does it?)

 

It's ineed just a bit of RAM that appears at $D5B8-$D5BF. No interrupts involved AFAIK.

[+bob1200xl]

Piece of cake, then. If the data is all in $D5xx, it should be easy.

 

No reason why it could not also be internal, is there? Carts are such a PITA...

 

Bob

[flashjazzcat]

I'm not sure I see the problem with drivers for "non-standard" RTCs under SpartaDOS 3.x. You can load any driver you like via an autorun batch file. I'm sure someone could be persuaded to code a driver up. Surely RealDOS should be natively supporting all this fancy new hardware by now, too.