Jump to content
IGNORED

My Atari XEGS Project


boisy

Recommended Posts

Look at the address and data bus. Perhaps write $B4 to $B400, read from $B400, read $F400, write $F4 to $F400, and then read $F400 and $B400. See if you get what you expect from each write.

 

Are you sure that this XEGS is not broken? It sounds like a bad LS158 to me. Did it run memory tests before you converted it?

 

Connect one probe to the output of the multiplexer chip that uses A14. If A14 is bad out of the multiplexer, other addresses should fail and you just haven't seen them. The XEGS would probably run carts and such, maybe, but still be broke.

 

Bob

 

Bob,

 

I don't see an LS158. There's an LS138 but A14 doesn't go into that chip.

 

A14 does go into the FREDDIE, and that's responsible for driving the RAS/CAS to the memory. Is it possible the FREDDIE may be defective?

Link to comment
Share on other sites

That schematic shows a Freddie chip. Don't know the internals of the chip, but one of those RA lines is address bit 14 multiplexed with another address bit. What I expect is the bad RA bit will be high all the time - probably following A15. If A15 is high, A14 will be high. That would break memory above $8000, which you may not notice.

 

Bob

Link to comment
Share on other sites

It wouldn't have to be Freddie - one of the memory chips could be holding up the RA bit. Or, a short on the m/b holding it up. It depends on the failing addresses. You may not notice an error unless you test for it. See if any of the RA bits are 'stuck'.

 

Bob

Link to comment
Share on other sites

SOLVED!

 

I desoldered the two RAM chips, socketed then replaced them with known working ones, but that didn't fix the problem.

 

Then I desoldered the FREDDIE chip from my 130XE and put it in the socket of the XEGS. Now it boots NitrOS-9 just fine!

 

So there you have it. Looks like I'll have to find a new FREDDIE chip somewhere.

 

Thanks for all the pointers!

Link to comment
Share on other sites

Here's one additional datapoint to add to this problem.

 

This morning, I put a 40 pin socket on the 130XE where I had removed the FREDDIE last night. I then took the "bad" FREDDIE from the XEGS and put it in the 40 pin socket of the 130XE, and it boots up fine!

 

This is a bit mystifying. The FREDDIE that was in the 130XE works fine in the XEGS, and the FREDDIE that failed in the XEGS works fine in the 130XE.

 

Just to make sure, I put the original XEGS FREDDIE in the XEGS again, and it still failed.

  • Like 1
Link to comment
Share on other sites

Weird. Sounds almost like that cart issue Bob had with his 1200XL that came down to timing.

 

Freddie gets Phi2 from the CPU so I guess it must use that as a basis for Ras/Cas transitions? Could it be that a problem CPU matched with some Freddie chips can create problems, and swapping either chip might fix it?

 

I don't suppose you have socketed 6502? It'd be interesting to see if the original pairings worked in the "other" machine.

Link to comment
Share on other sites

Rybags, I can try that. I still have the 6502C and ROM that I pulled, so I can do some swapping around to see if that helps.

 

The Liber809 board now generates phi2. I did not try swapping the Liber809 board in the 130XE as well, but that's another datapoint I could try.

 

But doesn't the BASIC come up running from ROM? If so, putting the BASIC in RAM and running it from there *might* show the problem up with the 6502C in place.

Edited by boisy
Link to comment
Share on other sites

You should try the 6809 in the 130XE with the 'bad' Freddie chip.

 

Bob

 

Bob, that does work. It's almost as though that particular FREDDIE has trouble in that particular XEGS system.

 

Another datapoint would be to try another XEGS system to see how the Liber809 worked.

Link to comment
Share on other sites

  • 1 year later...

I've been looking at the 6809 and I'm still puzzled at how it's stopped during a badline. Since !HALT has an indeterminate delay and you can't stop the clock for a whole DMA line without losing the CPU state, what was the final solution? The datasheets don't seem to indicate that TSC acts as a halt.

Link to comment
Share on other sites

I think it must use TSC since the /HALT only comes into effect once the current instructions finishes.

 

The only other thing I could think of is if the clock inputs are held in similar fashion to pre-Sally Atari machines.

It just doesn't make sense from the documentation. There are notes on using the TSC along with an external circuit to stop the clocks to simulate the BREQ features of the non-E CPU. This is similar to the 800's CPU circuit. However, the BREQ feature says it refreshes every 16 cycles. There's nothing like that on the E CPU if you stop the clocks. I'm still looking for that magic bit of info that explains how it all works. I'm surprised that the Motorola documentation is so light on the subject.
Link to comment
Share on other sites

Yeah, I see discussion of the problem on page 3 of this topic but not the solution. From everything I've read you need the HALT pin for long stops. This takes the CPU out of the instruction stream and just makes it perform idle cycles until HALT is released. You can stop the 6809 for up to 15 cycles with the BREQ function, and the 6809E's TSC function is only described as an enable for the bus drivers (which would make it kinda useless by itself). If it did more you'd think it would be mentioned, though.

 

I'm still searching for a really good interfacing document. You'd think they'd be all over the net.

 

EDIT:

I found this comment about adding a 6809 to a C64 which addresses the same concerns.

There is one very good reason why nobody has built a 6809 card for the64 similar to the CP/M card.  Can you say dynamic?  Normally the 6809 couldhave the bus when phase 2 is high, which would be wonderful.  The problem isthat the VIC chip needs to fetch the 40 character cell bytes once every 8scan lines, and a couple for the sprite data, during phase 2.  There arefour ways to get a 6809 to wait: HALT the CPU; use the wait line (MRDY, 6809CPU); request DMA (6809) or stop the clock (6809E CPU).  None of these arecompatible with the VIC scheme.  The VIC chip only gives you three phase 2cycles warning before it starts using the bus and it could take 20 cyclesfor the CPU to finish an instruction and HALT, MRDY has a time limit of 10microseconds, when you request DMA you only have 15 phase 2 cycles beforethe CPU takes the bus back for self refresh and the returns it, and lastof all the minimum clock frequency for a 6809 is 100 KHz, again limitinga delay to less than 10 microseconds.  If it weren't for the VIC stealingthe bus the 6809E would be almost a perfect shoe-in.  It might even notneed address and data buffers since it has a tristate control pin thatlooks like it's compatible with the specs in the 64 programmers guide,although the specs there are vary vague about the exact timing.  Thenagain, if you blank the screen and disable the sprites the VIC chipdoesn't use any phase 2 cycles, so you can have your cake, you justcan't eat it :-)
Link to comment
Share on other sites

I've been looking at the 6809 and I'm still puzzled at how it's stopped during a badline. Since !HALT has an indeterminate delay and you can't stop the clock for a whole DMA line without losing the CPU state, what was the final solution? The datasheets don't seem to indicate that TSC acts as a halt.

 

I'm always amused when a necrobump happens to a topic thread that's been dormant for a year-and-a-half with no explanation whatsoever...

Link to comment
Share on other sites

  • 6 months later...

 

There is one very good reason why nobody has built a 6809 card for the 64 similar to the CP/M card.

 

There are four ways to get a 6809 to wait

 

(Something is odd about the post layout here...)

From the deep dungeons of my easily distracted memory I seem to remember something similar being done for the 68000 that solved it by playing tricks with the rise/fall of the bus signals?

Are there any similar pins on the 6809 that can be abused to get a halt effect?

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...