+MrFish Posted April 11, 2017 Share Posted April 11, 2017 Congrats and nice call phaeron! Run Acid 5 Quote Link to comment Share on other sites More sharing options...
+mytek Posted April 11, 2017 Author Share Posted April 11, 2017 Thanks MrFish and everyone else for their well wishes and congrats I ran the acid800.atr (thanks for giving me that). End result... Passed: 53 Failed: 2 Skipped: 2 1st Fail... POKEY: Direct serial inputIssues an invalid read sector 0 request to D1: and attempts to receive the returned NAK byte by directly polling SKSTAT bit 4 at 19200 baud. This test will fail if the data returned by the disk drive is only readable through SERIN. An SIO status request is performed beforehand and the test will be skipped if D1: does not respond. This test will fail if D1: is a virtual drive, such as one emulated by custom firmware intercepting SIO requests. 2nd Fail... POKEY: Serial statusChecks for correct functionality of the SKSTAT serial input busy bit (bit 2) and overrun bit (bit 5). The first one looks to be a result of running this from the SIO2PC-USB, but I'm not sure about the 2nd one - Michael 3 Quote Link to comment Share on other sites More sharing options...
+MrFish Posted April 11, 2017 Share Posted April 11, 2017 I ran the acid800.atr (thanks for giving me that). End result... Passed: 53 Failed: 2 Skipped: 2 Great result! The first one looks to be a result of running this from the SIO2PC-USB, but I'm not sure about the 2nd one Well, you know who to ask. 3 Quote Link to comment Share on other sites More sharing options...
Noelio Posted April 11, 2017 Share Posted April 11, 2017 Nice work Mytek! The FUJI Force is strong in you for sure and I'm envious of your skill! I've been so frustrated for years now with ideas for new hardware but lacking the skill to put it all together. What you are doing is a great example of the mother of invention at work. I don't even think you realize or care how many people will want this and that's how truly great things happen. When the time comes (take your time) to order a board, I'm in. A rackable 8-Bit is a dream, if it will behave with a ps2 KVM, even better! Either way I'm in! Thank you so much for sharing your progress! Gorgeous board!Hats off to the other contributing/troubleshooting techno geniuses as well. One of the many reasons I LOVE this place is the abundant love of Atari hardware. 4 Quote Link to comment Share on other sites More sharing options...
+mytek Posted April 11, 2017 Author Share Posted April 11, 2017 Great result! Well, you know who to ask. Yep I sure do He'll see it soon enough, and I appreciate all the help he was at getting me past something that quite frankly had me stumped. Here's an actual test being run... https://www.youtube.com/watch?v=jH2Qe3fGUgg - Michael 3 Quote Link to comment Share on other sites More sharing options...
+mytek Posted April 11, 2017 Author Share Posted April 11, 2017 Nice work Mytek! The FUJI Force is strong in you for sure and I'm envious of your skill! I've been so frustrated for years now with ideas for new hardware but lacking the skill to put it all together. What you are doing is a great example of the mother of invention at work. I don't even think you realize or care how many people will want this and that's how truly great things happen. When the time comes (take your time) to order a board, I'm in. A rackable 8-Bit is a dream, if it will behave with a ps2 KVM, even better! Either way I'm in! Thank you so much for sharing your progress! Gorgeous board! Hats off to the other contributing/troubleshooting techno geniuses as well. One of the many reasons I LOVE this place is the abundant love of Atari hardware. Hi Noelio Thanks for the kudos... always appreciated. This project started as a dream almost two years ago. At first it was just that... a dream. Then about 6 months later I started drawing up a schematic, beginning with a variation of an XEGS mated to a U1MB. Then I set it aside for another 6 months while I worked on some of the things I knew I wanted to eventually integrate, such as a more refined version of the TK-II for the PS2 keyboard aspect. As time passed Bryan's UAV arrived on the scene, so it too got integrated. Then the VGATE (Video Overscan Elimination) and finally the Mousetari (PS2 ST Mouse) came into being. So now I had all the pieces to really make something nice and it was time to get serious about this project. But you nailed it on the nose when you speak of the techno geniuses here at AA. Without them this project would probably have failed, and/or never gotten off the ground. I owe the people here a lot for all the expertise that they brought forth either in postings within this topic, or by their contributions in other topics and/or developments of their own. - Michael 6 Quote Link to comment Share on other sites More sharing options...
JoSch Posted April 11, 2017 Share Posted April 11, 2017 (edited) That mod is to reverse the two address line inputs on the PIA chip (6520). Apparently Atari wanted to play a trick on me and routed A0 to PIA RS1 and vice versa with A1 going RS0. Or maybe this was their way of implementing a crude copy protection for their motherboard - Michael I guess you missed the pun Edited April 11, 2017 by JoSch Quote Link to comment Share on other sites More sharing options...
+mytek Posted April 11, 2017 Author Share Posted April 11, 2017 I guess you missed the pun You caught me with my serious hat on. Had to reread your original comment about 3 times and then it finally hit me :grin: Sorry for being a little sloooooooooow https://www.youtube.com/watch?v=IL2_MreyKMY - Michael 3 Quote Link to comment Share on other sites More sharing options...
phaeron Posted April 12, 2017 Share Posted April 12, 2017 Phaeron's notion about the transposed address lines on the PIA has paid off big time, since it was indeed the problem with the XEL. Thank you phaeron Bad Atari EDIT: Tested joystick ports again after the changes, and I'm happy to report they are still working. Funny thing was they worked even with the transposed PIA address lines. Go figure (PIA PORT A and B must be mirrored in the OS). It was a long shot, but looks like I got lucky! The reason this came to mind is that I got burnt by the same issue when I was trying to emulate the BlackBox in Altirra and couldn't figure out why its PIA addressing was so weird, only to realize that it was fine and it was the Atari that was weird. The Hardware Manual schematic didn't help because it shows A0/A1 mapping to RS0/RS1, and only if you compare it to the 6520 datasheet do you realize that Atari mislabeled the PIA pins too. Never trust the schematic.... Looking over the schematic once more, two other things do come to mind: Have you tested the XEL with paddles? There don't seem to be capacitors on the POT lines. The SIO input line is not connected on the second POKEY. Might want to add a pull-up on this; someone once emailed me about Acid5200 POKEY test failures on a custom 5200 motherboard and it turns out the floating data line was causing random serial input ready IRQs. The first one looks to be a result of running this from the SIO2PC-USB, but I'm not sure about the 2nd one The first one is indeed probably due to the SIO2PC-USB. I need to switch to another command as too many drives don't act like the 810 and 1050 for that one. The second one I'm not sure about either and would need to see the diagnostic information. Each test that fails prints out an additional line with more details about the failure. 4 Quote Link to comment Share on other sites More sharing options...
+mytek Posted April 12, 2017 Author Share Posted April 12, 2017 (edited) It was a long shot, but looks like I got lucky! The reason this came to mind is that I got burnt by the same issue when I was trying to emulate the BlackBox in Altirra and couldn't figure out why its PIA addressing was so weird, only to realize that it was fine and it was the Atari that was weird. The Hardware Manual schematic didn't help because it shows A0/A1 mapping to RS0/RS1, and only if you compare it to the 6520 datasheet do you realize that Atari mislabeled the PIA pins too. Never trust the schematic.... Looking over the schematic once more, two other things do come to mind: Have you tested the XEL with paddles? There don't seem to be capacitors on the POT lines. The SIO input line is not connected on the second POKEY. Might want to add a pull-up on this; someone once emailed me about Acid5200 POKEY test failures on a custom 5200 motherboard and it turns out the floating data line was causing random serial input ready IRQs. The first one is indeed probably due to the SIO2PC-USB. I need to switch to another command as too many drives don't act like the 810 and 1050 for that one. The second one I'm not sure about either and would need to see the diagnostic information. Each test that fails prints out an additional line with more details about the failure. Drats I forgot about the paddle capacitors, have to add those. And also add a pull-up on that SIO data line. Good call on all of this Thank you I should of had you on my design team As for the test failures here's what I got... POKEY: Direct serial input...Fail.Timeout while waiting for NAK. POKEY: Serial status...Fail. Timeout occurred while sending status command. The first one we've already dismissed. - Michael Edited April 12, 2017 by mytekcontrols Quote Link to comment Share on other sites More sharing options...
JoSch Posted April 12, 2017 Share Posted April 12, 2017 You caught me with my serious hat on. Had to reread your original comment about 3 times and then it finally hit me :grin: Sorry for being a little sloooooooooow - Michael It happens Quote Link to comment Share on other sites More sharing options...
+mytek Posted April 12, 2017 Author Share Posted April 12, 2017 Been running acid800 non-stop since about this time yesterday, and all is looking good - Michael 9 Quote Link to comment Share on other sites More sharing options...
+mytek Posted April 12, 2017 Author Share Posted April 12, 2017 Today I ordered a few components I need to fix my paddle inputs. So here's what the 600XL has setup going into Pokey's paddle inputs (P0-P3). And here is the XEL's paddle circuit as it will be once the parts arrive (mine are labeled P-A0, P-B0, P-A1, P-B1). Initially I'll be trying it without the additional .001uf capacitors that the 600XL has on the input side of the 1.8K resistor. I'm thinking that it should be fine, but nothing like seeing to be sure. - Michael 1 Quote Link to comment Share on other sites More sharing options...
+mytek Posted April 13, 2017 Author Share Posted April 13, 2017 Found a bug in the system. Nothing catastrophic this time, but it does affect graphics. here's what happens... I loaded Galaxian and pressed START to begin the game. When the ship appears at the bottom of the screen you can see some small rectangular objects appear directly above and in-line with the ship's gun. basically about 1/2 way up the screen is the first and larger one (normally white), and then about 2/3 up are 2-3 smaller closely spaced multi-colored ones. As you move your ship side to side, they move with it. At times if the upper ones cross into an invader it disappears making a boing sound as it disappears (like what would happen if you had fired and your missile hit it). The game is still playable as normal and doesn't lock up or do horrible things to the screen other than these 3-4 artifacts that follow the ship's movement. I'll try to capture this on video. Anybody have any ideas? - Michael Quote Link to comment Share on other sites More sharing options...
+MrFish Posted April 13, 2017 Share Posted April 13, 2017 (edited) It sounds like it's extra data in the player's (and missile's) memory area that isn't supposed to be there. Why is it there? I have no idea... yet (waiting video). [Edit] Missile data colliding with an enemy should kill him, since any data in the memory area at the correct position should trigger a collision. Edited April 13, 2017 by MrFish 1 Quote Link to comment Share on other sites More sharing options...
+MrFish Posted April 13, 2017 Share Posted April 13, 2017 It could be some problem related to Antic too, since it handles P/M's. 1 Quote Link to comment Share on other sites More sharing options...
Kyle22 Posted April 13, 2017 Share Posted April 13, 2017 Does this affect PMGs in other games? Quote Link to comment Share on other sites More sharing options...
+mytek Posted April 13, 2017 Author Share Posted April 13, 2017 (edited) Does this affect PMGs in other games? I've seen something similar in Fort Apocalypse, but quite a few games seem unaffected, although I've only looked at about 8 or 9 games thus far. Tomorrow I'll swap out Antic to see if it is possibly a faulty chip. - Michael Edited April 13, 2017 by mytekcontrols 1 Quote Link to comment Share on other sites More sharing options...
+MrFish Posted April 13, 2017 Share Posted April 13, 2017 (edited) How are the games being "loaded"? SIO2PC, SIDE2 Cart, Actual ROM Carts? Try different loading methods for the same games, if you have different methods available and working. Edited April 13, 2017 by MrFish 1 Quote Link to comment Share on other sites More sharing options...
foft Posted April 13, 2017 Share Posted April 13, 2017 For pmgs antic halts the CPU, sets the address for ram and then gtia reads the bus. Perhaps ram is read slightly too early or late by gtia. I guess double check halt on gtia. 3 Quote Link to comment Share on other sites More sharing options...
+mytek Posted April 13, 2017 Author Share Posted April 13, 2017 (edited) How are the games being "loaded"? SIO2PC, SIDE2 Cart, Actual ROM Carts? Try different loading methods for the same games, if you have different methods available and working. So far I've only seen this through SIO2PC-USB, and haven't been able to do a direct comparison of something like Galaxian on cart, since for one, my cart collection of games is extremely limited. But it certainly is a good point you are making, and would perhaps cast some light on what is truly behind this particular problem. EDIT: And I do have a SIDE2 cart as well as an UNO cart, so I'll load in Galaxian from one of those and see. For pmgs antic halts the CPU, sets the address for ram and then gtia reads the bus. Perhaps ram is read slightly too early or late by gtia. I guess double check halt on gtia. This is a very good observation foft. And perhaps this explains why some systems also buffer the GTIA chip select, thereby adding delay. - Michael Edited April 13, 2017 by mytekcontrols Quote Link to comment Share on other sites More sharing options...
+DrVenkman Posted April 13, 2017 Share Posted April 13, 2017 EDIT: And I do have a SIDE2 cart as well as an UNO cart ... - Michael The good thing about the Uno is that it can emulate all the odd-ball banking schemes used by different carts. It might be a good idea to seek out several example ROMs of each type and see how the new board design handles them all. 1 Quote Link to comment Share on other sites More sharing options...
Brentarian Posted April 13, 2017 Share Posted April 13, 2017 Michael, do you get the same results with Sophia/RGB as with UAV/Svideo? Quote Link to comment Share on other sites More sharing options...
+mytek Posted April 13, 2017 Author Share Posted April 13, 2017 Easy fix When I created the XEL logic circuitry, I mimicked something that many of the A8's do with PH0 coming out of Antic and over to the CPU (Sally). I buffered it with a spare 'AND' Gate (74HCT08). The only exception to this rule is the XEGS, which only buffers PH2 coming from the CPU. Anyway my first test was with no changes other then loading Galaxian from the SIDE2 instead of SIO2PC. This still exhibited the same behavior as before. Galaxian Artifacts... I also saw something equally interesting when bringing up the Side Loader in the U1MB... However when I changed from an Antic C021697-01 over to a C021697-11 that I pulled from my XEGS everything was fine on the XEL (same as it had been on the XEGS). So to take this a step further, I put the C021697-01 into the XEGS instead, and it too was okay. So not wanting to have my board be picky about what revision Antic chip could be used, I removed the PH0 buffering. And then I put the C021697-01 back into the XEL. End result: without the PH0 buffering both Antic chips work fine in the XEL (no artifacts). So I guess the old saying that "simpler is better" applies to this situation as well. I'll be doing more extensive tests, but it looks like the PH0 buffering will be eliminated. - Michael 6 Quote Link to comment Share on other sites More sharing options...
+mytek Posted April 13, 2017 Author Share Posted April 13, 2017 (edited) Michael, do you get the same results with Sophia/RGB as with UAV/Svideo? Haven't checked, but now I'm not too concerned about that now, since the problem has been discovered. But I will check at some point to be sure Sophia works correctly as well, although it should. - Michael Edited April 13, 2017 by mytekcontrols 2 Quote Link to comment Share on other sites More sharing options...
Recommended Posts
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.