1088XEL Alternative Mother-Board Project

[+mytek]

Any updates on the PAL bug found?

 

Still chasing it, and no answers thus far as to what is causing it. The problem is strictly related to PMG graphics, and is only affecting the system when it is configured for PAL video.

 

Here's an explanation of the problem and a test that Stephen created (first test is in emulator, 2nd test is on actual XEL hardware)...

I've posted a video demoing the issue, but it's taking a while to process. I'm including the file I used to demo this (standard ATARI BASIC). Excuse my extremely hi-tech video capture equipment.

Outline of the issue:

I think data is being fetched incorrectly. My code clears out 2k of space for single line PMG

It then draws in the "strips" one at a time. When poking the data for Player 0, nothing is shown. When poking in the data for Player 1, Player 0 data shows up (properly), Player 1 data is mangled. When drawing in Player 3, it is mirrored to Players 3 and 4. However, each Player can be positioned independently.

 

https://www.youtube.com/watch?v=WNb8DBHIYfY

 

Here is the same test I did with my XEL configured for NTSC video (a little faster due to the speed increase by running under TurboBasic)...

 

https://www.youtube.com/watch?v=IA9mLl3OzXI

 

Since it's a PAL problem only, we've been targeting the circuitry that comes into play for that video mode. So that would mainly be what I call the PAL clock on my schematic, which is modeled after the one used in the 800XL, with the only exceptions being: 74HCT74 instead of 74LS74, PN2222 instead of 2N3904, and using a Digi-Key Crystal for X2 instead of the Atari one.

 

 

So far we've tried substituting the original 74LS74 for the 74HCT74, as well as a faster 74AC74 with nothing positive to report. Also reverted to a 74LS08 for the PH0 and PH2 buffering, without any luck (not shown on this schematic page).

 

Haven't tried substituting the X2 crystal for the Atari one, but that's coming.

 

Some of this troubleshooting has been dragging on due to having to order the different IC's and waiting for them to arrive and then me shipping them out to the Beta testers. On the plus side, during this troubleshooting phase additional corrections and tweaks have been discussed and implemented into the next rev design. But it's still frustrating none the less

 

- Michael

[+kheller2]

I think its wonderful that you are still finding issues and fixing them. No product is going to be perfect, and the more testing/debugging you do now the less you'll feel frustrated/crappy later when the product is finished and people don't complain about something. (I hope I worded that properly)

[Matej]

Please join:

https://www.facebook.com/groups/atarixelclub/

[+mytek]

Please join:

https://www.facebook.com/groups/atarixelclub/

 

Sorry Matej, but I don't do FB. Why don't you make it public so that joining is optional? Because I really don't see a need to have it be private.

 

- Michael

[Matej]

Fixed!!! Its open. But its group not page so you must still have FB account...

I dont like FB too. Anyways I am there as its like mobile today... Everyone is there.

 

We need prime wifi or ethernet and our own 8bit ataribook social network. Like in 80s BBS...

Edited June 21, 2017 by Matej

[+Stephen]

 

Still chasing it, and no answers thus far as to what is causing it. The problem is strictly related to PMG graphics, and is only affecting the system when it is configured for PAL video.

 

Here's an explanation of the problem and a test that Stephen created (first test is in emulator, 2nd test is on actual XEL hardware)...

 

https://www.youtube.com/watch?v=WNb8DBHIYfY

 

Here is the same test I did with my XEL configured for NTSC video (a little faster due to the speed increase by running under TurboBasic)...

 

https://www.youtube.com/watch?v=IA9mLl3OzXI

 

Since it's a PAL problem only, we've been targeting the circuitry that comes into play for that video mode. So that would mainly be what I call the PAL clock on my schematic, which is modeled after the one used in the 800XL, with the only exceptions being: 74HCT74 instead of 74LS74, PN2222 instead of 2N3904, and using a Digi-Key Crystal for X2 instead of the Atari one.

 

 

So far we've tried substituting the original 74LS74 for the 74HCT74, as well as a faster 74AC74 with nothing positive to report. Also reverted to a 74LS08 for the PH0 and PH2 buffering, without any luck (not shown on this schematic page).

 

Haven't tried substituting the X2 crystal for the Atari one, but that's coming.

 

Some of this troubleshooting has been dragging on due to having to order the different IC's and waiting for them to arrive and then me shipping them out to the Beta testers. On the plus side, during this troubleshooting phase additional corrections and tweaks have been discussed and implemented into the next rev design. But it's still frustrating none the less

 

- Michael

Well, unfortunately I just tried running an original Atari xtal and there is no change.

[Xuel]

 

Still chasing it, and no answers thus far as to what is causing it. The problem is strictly related to PMG graphics, and is only affecting the system when it is configured for PAL video.

 

Perhaps GTIA is sampling the AN# lines in the wrong cycle for PMGs. What if you disable PMG DMA on GTIA (GRACTL=0) and manually set the GRAFP# registers instead. Do those work properly?

[+mytek]

Perhaps GTIA is sampling the AN# lines in the wrong cycle for PMGs. What if you disable PMG DMA on GTIA (GRACTL=0) and manually set the GRAFP# registers instead. Do those work properly?

 

I'll let some of my more capable Beta Testers try that out (and it is a good suggestion). However I am left with the question: "Why is this happening, and why only in PAL?" Because when you think about it, what I've put together is essentially a 'real' 8-bit Atari, with most everything pretty much the same as what they did (especially around ANTIC and GTIA). And even where there were slight differences, such as logic chip family in use, no difference was seen when reverting back to the older 74LS series chips, or by trying complete swaps of the Antic and GTIA chips for other ones. Hopefully soon we will have a 2nd PAL version ready to go... be interesting to see if it shares the same problem.

 

- Michael

[Xebec]

Please join:

https://www.facebook.com/groups/atarixelclub/

Please Please Please make this public - I don't have a facebook account.

 

XEL = awesome

[_The Doctor__]

Is the pmg also shifted to the right as if generated late on the clock? since I do not have an xel to test, can we see the timing and data with a logic analyzer against the clocks while running... might be interesting picture...

[Xuel]

 

I'll let some of my more capable Beta Testers try that out (and it is a good suggestion). However I am left with the question: "Why is this happening, and why only in PAL?" Because when you think about it, what I've put together is essentially a 'real' 8-bit Atari, with most everything pretty much the same as what they did (especially around ANTIC and GTIA). And even where there were slight differences, such as logic chip family in use, no difference was seen when reverting back to the older 74LS series chips, or by trying complete swaps of the Antic and GTIA chips for other ones. Hopefully soon we will have a 2nd PAL version ready to go... be interesting to see if it shares the same problem.

 

- Michael

 

That is a good question.

 

Thinking about it some more, I think I remember that ANTIC doesn't actually send the PMG data over the AN# lines but just leaves on the data bus for GTIA to pick it up. So misalignment of the various PHI signals could be the culprit.

[Van]

Is the pmg also shifted to the right as if generated late on the clock? since I do not have an xel to test, can we see the timing and data with a logic analyzer against the clocks while running... might be interesting picture...

It does appear so in Simon's test video; as player 0 is read and displayed, some data is being written to the player 1 memory.

[+Stephen]

Guys, let me know what I can do as far as test code to help assist with this. I unfortunately do not have a logic analyzer so the best I can do is test code (I can do asm if needed).

[+mytek]

Ok I've done a little more research going over the various schematics, and in some cases (although very few) Atari added a buffer between the 74LS138 GTIA related output and the GTIA's /CS input. So it appears in some cases they needed to add a bit of delay before GTIA was brought on-line. Twitchy finicky stuff.

 

Since we have an extra gate in the 74HCT08, maybe it would be worth a try to add this same buffer and see what happens.

 

- Michael

[+mytek]

Guys, let me know what I can do as far as test code to help assist with this. I unfortunately do not have a logic analyzer so the best I can do is test code (I can do asm if needed).

Xuel mentioned something a few posts back that might be informative to try.

 

- Michael

[Xuel]

Guys, let me know what I can do as far as test code to help assist with this. I unfortunately do not have a logic analyzer so the best I can do is test code (I can do asm if needed).

 

Can you try the attached BASIC program? It should show all four players cycling through the same pattern.

 

test.bas

[+Stephen]

 

Can you try the attached BASIC program? It should show all four players cycling through the same pattern.

 

test.bas

Looks like that worked.

 

I also - put data into one player at a time to see if there is "overlap", and there wasn't.

[foft]

To me gtia seems too late reading the bus, since player 2 is in the 1 slot.

 

CS isn't involved I'd have thought, gtia is not selected when reading player data.

 

I guess it syncs to the start of line from antic AN0-2. Could it be one colour clock late? Relative timing of phi2 and colour clock?

[+Stephen]

Is the pmg also shifted to the right as if generated late on the clock? since I do not have an xel to test, can we see the timing and data with a logic analyzer against the clocks while running... might be interesting picture...

I'm not aware of any issues with the positions being shifted. This seems to be a matter of the data not loading at the correct time. I know when setting the player positions to the left edge of the screen, they match up to my other machines.

[Daschewie]

I am loving the project, and cant wait for the 1.1 revision. Kudos for the fine work and effort.

 

This is a long thread, so please ignore the following if it has already been mentioned:

 

Will it be possible to control the mouse/joystick switch via the U1M like the Rapidus board? I think it would look cleaner than having to drill a whole for an external switch.

 

It would be nice to map a keyboard key or combination to crash the app for resetting games, in order to leave the lid on the case with a cart inside.

 

Thanks

[+mytek]

I am loving the project, and cant wait for the 1.1 revision. Kudos for the fine work and effort.

 

This is a long thread, so please ignore the following if it has already been mentioned:

 

Will it be possible to control the mouse/joystick switch via the U1M like the Rapidus board? I think it would look cleaner than having to drill a whole for an external switch.

 

It would be nice to map a keyboard key or combination to crash the app for resetting games, in order to leave the lid on the case with a cart inside.

 

Thanks

To answer the first question... It would require 2 free I/O bits to have the mouse to joy port function be software controlled as you suggested (3 selections: select 1, select 2, select none). Currently the ext device control bits on the U1MB are all spoken for if you were to have a VBXE and a Rapidus, but if those devices were not to be used I suppose the bits assigned to them could be repurposed. Or there is also the possibility of hanging an addressable latch off the MPBI port to give you extra control bits. However in my opinion the real physical switch is preferred over having to jump into the U1MB's Setup each time you wish to change mouse ports. If you used the system you would understand why I say this.

 

You can always crash a game as you said, by hoping into U1MB Setup and then exit with the Cold Boot key, which effectively restarts the system. I don't know if that's what you meant or needed, but it is one possibility.

 

- Michael

[flashjazzcat]

M0 = Stereo, S0 = Rapidus, VB = VBXE. Are S1 and M1 also spoken for?

 

EDIT: I see S1 has been appointed the task of controlling the IRQ line on the second POKEY.

Edited June 26, 2017 by flashjazzcat

[+mytek]

M0 = Stereo, S0 = Rapidus, VB = VBXE. Are S1 and M1 also spoken for?

 

EDIT: I see S1 has been appointed the task of controlling the IRQ line on the second POKEY.

 

On the XEL these are assigned...

 

S0 = VGATE-ENABLE

S1 = 2nd POKEY IRQ-ENABLE

M0 = POKEY-STEREO

 

And these are available at the MPBI connector for use wherever needed...

 

VB

M1

 

So it looks like S0 is used by something on Rapidus? What for?

 

- Michael

Edited June 26, 2017 by mytekcontrols

[thorfdbg]

 

Still chasing it, and no answers thus far as to what is causing it. The problem is strictly related to PMG graphics, and is only affecting the system when it is configured for PAL video.

 

Some of this troubleshooting has been dragging on due to having to order the different IC's and waiting for them to arrive and then me shipping them out to the Beta testers. On the plus side, during this troubleshooting phase additional corrections and tweaks have been discussed and implemented into the next rev design. But it's still frustrating none the less

 

- Michael

 

The way how PMGs work is that GTIA samples the bus in the right time while Antic puts the address on the bus. If GTIA shows the wrong data, then because it is sampling at the wrong bus cycle.

The question is how GTIA knows what the right cycle is - probably because it receives the horizontal sync from Antic.

 

Additionally, how do you switch between PAL and NTSC? It's a different ANTIC, system dependent. One of the differences between PAL and NTSC is that NTSC has long and short lines, depending on the frame, so the timing (as based on color clocks) may be a off. By a cycle.

 

[+Stephen]

 

The way how PMGs work is that GTIA samples the bus in the right time while Antic puts the address on the bus. If GTIA shows the wrong data, then because it is sampling at the wrong bus cycle.

The question is how GTIA knows what the right cycle is - probably because it receives the horizontal sync from Antic.

 

Additionally, how do you switch between PAL and NTSC? It's a different ANTIC, system dependent. One of the differences between PAL and NTSC is that NTSC has long and short lines, depending on the frame, so the timing (as based on color clocks) may be a off. By a cycle.

There is a crystal swap, and the ANTIC & GTIA are also swapped out.

 

One thing I think I showed by using Xuel's test program is that correct PMG data is displayed when stuffing GRAFCTL directly, but when using DMA, there are errors. I believe this would then also point to ANTIC being the culprit?