My Atari XEGS Project

[Rybags]

That's just wrong. Looks like it's occurring early in the scanline before the Refresh burst.

 

Could it be some threshold setting on the meter not right or something?

 

We can't just halt all the clocks - just about everything else would grind to a halt as well.

 

You could leave /RDY out - the OS doesn't use it other than possibly when the Self-Test is running.

 

Instead, could you sample the CSYNC pin from GTIA ? That's pin 25, the IC should have "CO14805" printed on top.

Having the CSync reference allows to work out where in the scanline everything's occurring.

Edited February 2, 2012 by Rybags

[boisy]

Sounds a bit weird to me - can you post up a capture pic?

 

Any "clock halting" should be internal to the 6502C as far as I see it. Only the early 400/800 used a standard 6502 with an external circuit that halted the clock going to the CPU.

 

One thought. According to the XE schematics I have, it looks like PHI0 is sourced from the ANTIC on pin 34. Could the ANTIC be driving PHI0 this way? I would think that's what the RDY line is for. Again, probably off base, but looking for explanations.

[Rybags]

I don't see any reason why Antic would do that. We have extensive knowledge of what cycles Antic uses for Refresh and graphics DMA, cycle-exact demo and game coding has been the norm for a long time.

 

Phi2 is derived from Phi0 and used extensively within the system, the whole deal would just break down if it periodically stopped. We're talking sound, I/O, even graphics generation from GTIA.

[boisy]

I don't see any reason why Antic would do that. We have extensive knowledge of what cycles Antic uses for Refresh and graphics DMA, cycle-exact demo and game coding has been the norm for a long time.

 

Phi2 is derived from Phi0 and used extensively within the system, the whole deal would just break down if it periodically stopped. We're talking sound, I/O, even graphics generation from GTIA.

 

Wow.

 

I was doing my testing with the original ROM, so Missle Command was running with these tests.

 

I put in the ROM emulator and loaded the OStest2 sound program, then resampled, and now the clock is always there.

 

Go figure.

 

I loaded the ROM emulator with the 32K standard XEGS ROM, and now its back in Missle Command...

 

And sampling shows a constant clock.

 

I have no idea what to make of the missing clock pulses. But it's not happening anymore. As you noted, this would be so detrimental to the working of the system.

 

Sorry for the false alarm.

[+bob1200xl]

You seem to have 'all lines high', which does not follow the logic (01 and 02 are inverted). Try moving your threshold voltages (set to 1.4 v in your picture) to see if it might be a floating ground or such. Attach as many grounds as possible from the probe body to the system.

 

Bob

[boisy]

You seem to have 'all lines high', which does not follow the logic (01 and 02 are inverted). Try moving your threshold voltages (set to 1.4 v in your picture) to see if it might be a floating ground or such. Attach as many grounds as possible from the probe body to the system.

 

Bob

 

I've solved the PHI0 clock problem as I noted earlier. Now I'm debugging the satellite board. Right now, E and Q aren't being generated. At least I can determine that now, thanks to the LogicPort.

[boisy]

Now we're making progress. After finding a fault with the circuit design, Gary and I doubled back on a slight adjustment. Now E and Q are definitely being generated and going to the 6809E. E and Q are 180 degrees out of phase instead of 90, so we need to address that. But gone is the dark green screen on the XEGS when it fires up. We're seeing some actual flickering of random graphics!

[boisy]

I've posted a video of where I am at with the board:

[sloopy]

Very nice, its a another stop in the journey to your destination :')

 

cant wait to see it fully working!

 

sloopy.

[boisy]

Ok, things have gotten a little more complicated than I thought.

 

It appears that the RC time constant approach to generating E from Q is not working as noted in the video above. In fact, in talking with a friend who knows hardware well, he thinks the resistor/capacitor time constant approach is flawed and will only yield problems in a mass produced product environment.

 

His recommendation would be to tie in directly to the 14MHz clock on the Atari, and use a CPLD to detect the leading edge of PHI0, then count the number of 14MHz crystal oscillations until we get a quarter way into the PHI0 cycle. The CPLD would then assert an output pin high (the E clock) for a predetermined time, then drop it, and wait for the next rise of PHI0.

 

I don't like this approach because it adds complexity of a CPLD, and also would require a physical wiring between the crystal and the satellite board. That's not something I would want to do. I want to be able to generate the required clocking right from PHI0 coming in from pin 37 of the CPU socket, and do it consistently.

 

He also mentioned the possibility of using a PLL, but he wasn't an expert on phase locked loops.

 

Anyone here have some input on the best approach to use at this point?

[linville]

I'm not an expert either, but I concur that using an RC timing approach seems flawed -- especially if you want to produce more than a single board or use it outside of your current location.

[+bob1200xl]

There are at least two options. I use an IDT clock multiplier (ICS570A) to generate a 28MHZ clock from the Atari 1.79MHZ clock. You can then divide that down and decode to give you a broad range of timing. I will warn you that you need very good grounding to run at that frequency - I use a 4-layer board for this.

 

There are also accurate delay lines available from Maxim (DS1100) that come in a good selection of values. Never tried one, but they look pretty bulletproof.

 

Bob

 

 

Ok, things have gotten a little more complicated than I thought.

 

It appears that the RC time constant approach to generating E from Q is not working as noted in the video above. In fact, in talking with a friend who knows hardware well, he thinks the resistor/capacitor time constant approach is flawed and will only yield problems in a mass produced product environment.

 

His recommendation would be to tie in directly to the 14MHz clock on the Atari, and use a CPLD to detect the leading edge of PHI0, then count the number of 14MHz crystal oscillations until we get a quarter way into the PHI0 cycle. The CPLD would then assert an output pin high (the E clock) for a predetermined time, then drop it, and wait for the next rise of PHI0.

 

I don't like this approach because it adds complexity of a CPLD, and also would require a physical wiring between the crystal and the satellite board. That's not something I would want to do. I want to be able to generate the required clocking right from PHI0 coming in from pin 37 of the CPU socket, and do it consistently.

 

He also mentioned the possibility of using a PLL, but he wasn't an expert on phase locked loops.

 

Anyone here have some input on the best approach to use at this point?

[+bob1200xl]

Well, you have two ICs in the design, now. You could do all this in one 24-pin CPLD, most likely. Not that you want to use the 14MHZ clock - most Ataris do not have such a thing, only XEs.

 

Bob

 

Ok, things have gotten a little more complicated than I thought.

 

It appears that the RC time constant approach to generating E from Q is not working as noted in the video above. In fact, in talking with a friend who knows hardware well, he thinks the resistor/capacitor time constant approach is flawed and will only yield problems in a mass produced product environment.

 

His recommendation would be to tie in directly to the 14MHz clock on the Atari, and use a CPLD to detect the leading edge of PHI0, then count the number of 14MHz crystal oscillations until we get a quarter way into the PHI0 cycle. The CPLD would then assert an output pin high (the E clock) for a predetermined time, then drop it, and wait for the next rise of PHI0.

 

I don't like this approach because it adds complexity of a CPLD, and also would require a physical wiring between the crystal and the satellite board. That's not something I would want to do. I want to be able to generate the required clocking right from PHI0 coming in from pin 37 of the CPU socket, and do it consistently.

 

He also mentioned the possibility of using a PLL, but he wasn't an expert on phase locked loops.

 

Anyone here have some input on the best approach to use at this point?

[boisy]

There are at least two options. I use an IDT clock multiplier (ICS570A) to generate a 28MHZ clock from the Atari 1.79MHZ clock. You can then divide that down and decode to give you a broad range of timing. I will warn you that you need very good grounding to run at that frequency - I use a 4-layer board for this.

 

There are also accurate delay lines available from Maxim (DS1100) that come in a good selection of values. Never tried one, but they look pretty bulletproof.

 

Bob

 

 

Ok, things have gotten a little more complicated than I thought.

 

It appears that the RC time constant approach to generating E from Q is not working as noted in the video above. In fact, in talking with a friend who knows hardware well, he thinks the resistor/capacitor time constant approach is flawed and will only yield problems in a mass produced product environment.

 

His recommendation would be to tie in directly to the 14MHz clock on the Atari, and use a CPLD to detect the leading edge of PHI0, then count the number of 14MHz crystal oscillations until we get a quarter way into the PHI0 cycle. The CPLD would then assert an output pin high (the E clock) for a predetermined time, then drop it, and wait for the next rise of PHI0.

 

I don't like this approach because it adds complexity of a CPLD, and also would require a physical wiring between the crystal and the satellite board. That's not something I would want to do. I want to be able to generate the required clocking right from PHI0 coming in from pin 37 of the CPU socket, and do it consistently.

 

He also mentioned the possibility of using a PLL, but he wasn't an expert on phase locked loops.

 

Anyone here have some input on the best approach to use at this point?

 

Bob,

 

The second option seems intriguing... I found the data sheet here: http://datasheets.maxim-ic.com/en/ds/DS1100.pdf

 

It looks like DS1100Z-175 would fit the bill, as tap 4 has a 140ns delay which is almost dead on the required 139.6ns delay.

 

I'll see if I can get some samples of this part.

[Rybags]

Or how about a timer IC running off 14 MHz ? Although that's probably going to give somewhat limited options.

[dmlloyd]

Bob,

 

The second option seems intriguing... I found the data sheet here: http://datasheets.ma...n/ds/DS1100.pdf

 

It looks like DS1100Z-175 would fit the bill, as tap 4 has a 140ns delay which is almost dead on the required 139.6ns delay.

 

I'll see if I can get some samples of this part.

 

Sounds like a winner to me... simple and it exactly fits the bill.

[boisy]

Bob,

 

The second option seems intriguing... I found the data sheet here: http://datasheets.ma...n/ds/DS1100.pdf

 

It looks like DS1100Z-175 would fit the bill, as tap 4 has a 140ns delay which is almost dead on the required 139.6ns delay.

 

I'll see if I can get some samples of this part.

 

Sounds like a winner to me... simple and it exactly fits the bill.

 

It does indeed seem to be what is needed. I placed a sample order with Maxim, and hope to get the samples soon.

 

There are two things that worry me, however:

 

1. Cost. The part is over $6 at Digikey in quantities under 25.

2. Flexibility. The part used depends on the period of PHI0. Whatever PHI0's period is, the part needs to handle 1/4 of that as exact as possible.

 

Which leads me to this question: what other Atari computer systems clock the 6502 at 1.789MHz, and for the systems that don't clock at that rate, what are those other clock rates?

[+Stephen]

Which leads me to this question: what other Atari computer systems clock the 6502 at 1.789MHz, and for the systems that don't clock at that rate, what are those other clock rates?

All NTSC 8-bit Atari's have the same clock rate, as it is exactly one half of the color carrier frequency. PAL is ever so slightly different - somewhere around 1.77x MHz.

[boisy]

Which leads me to this question: what other Atari computer systems clock the 6502 at 1.789MHz, and for the systems that don't clock at that rate, what are those other clock rates?

All NTSC 8-bit Atari's have the same clock rate, as it is exactly one half of the color carrier frequency. PAL is ever so slightly different - somewhere around 1.77x MHz.

 

Well, that's good to know. It means that if this chip is part of the design, then it will work with all 6502 based Atari systems without needing a different speed. Even at 1.77MHz, one quarter of a period is 141ns, which is still close enough for the same chip.

[Rybags]

7800 runs at 1.79 and uses the same master frequency ~ 14 MHz as the XE computers.

 

2600 uses 6507 (cut down 6502) and runs at 2/3rds speed ~ 1.19 MHz.

 

6502 based Atari arcade games used different frequencies - 1.79 MHz was fairly common but there were also other slower ones.

 

We're pretty much stuck with the stock frequency since the TV signal relies on it.

[dmlloyd]

Yeah the derivation of clock speed in 8-bit NTSC systems is pretty interesting. Our A8s use a conceptual 14.31818 MHz base clock divided by 4 to get the color carrier signal @ 3.579545 and by 8 to get the CPU clock @ 1.789772 (though only the XEs and later XLs literally divide down from 14.31818 - the older systems started right with 3.58); other systems take a different approach. For example Apple II and (I think) C64 divide by 14 to get 1.023 MHz. But in the end all these classic systems were designed with TV sync in mind from the beginning with varying degrees of cleverness.

[boisy]

Well, I have some good news to report.

 

The Maxim part made it in yesterday and I finally had some time to wire it up. After a bout of rewiring, the 6809's Q clock is now coming in perfect, and the 09 is coming to life! You can see with the attached screenshots that the DATA lines D0-D7 are showing pretty much what's in the 3rd column of the assembly below (the actual instructions):

 

 

00008 FF00 1A50 orcc #$50

00009 ifne 0

00012 else

00013 FF02 5F clrb

00014 cleario

00015 FF03 8ED000 ldx #$D000

00016 FF06 6F85 clr b,x

00017 FF08 8ED200 ldx #$D200

00018 FF0B 6F85 clr b,x

00019 FF0D 8ED300 ldx #$D300

00020 FF10 6F85 clr b,x

00021 FF12 8ED400 ldx #$D400

00022 FF15 6F85 clr b,x

00023 FF17 5A decb

00024 FF18 26E9 bne cleario

 

It's not consistent, however. There's still a problem, as evidenced when I keep pressing restart. In many instances, some of the instruction bytes come across different.

 

But it's progress, and I'll take it.

Edited February 9, 2012 by boisy

[frogstar_robot]

I've been fascinated by your project.

 

Any progress to report?

[boisy]

I've been fascinated by your project.

 

Any progress to report?

 

I haven't posted in quite a while. Been busy with work and other more pressing matters.

 

We've modified the design to use a J/K flip-flop and are currently trying to debug some issues in the prototype. As soon as those get sorted out, we'll see how the J/K flip-flop design works and hopefully (fingers crossed) we'll have a consistently working daughterboard.

[boisy]

Ok. Progress made today. After finding a few shorts in my soldering, I've finally gotten the Liber809 to execute the following code successfully. The screen cycles through various colors!

 

org $FF00

 

reset orcc #$50 mask interrupts

lds #$2000 set stack pointer to $2000

clra clear A

xxx sta $D01A put A in graphics reg

inca increment A

pshs a save on stack

ldd #$1000 load D with delay

yyy subd #$0001 subtract 1

bne yyy if D<>0, go to yyyy

puls a get A from stack

bra xxx go back and do it again

wait jmp wait we currently never get here.

 

fill $FF,$FFF0-*

fdb reset

fdb reset

fdb reset

fdb reset

fdb reset

fdb reset

fdb reset

fdb reset

Edited February 19, 2012 by boisy