Jump to content
IGNORED

CV-NUC+ A Miniature CV Motherboard is in the Works


mytek

Recommended Posts

Something Just for grins ;-)

 

I was reading about all the fake AY-3-8910A chips out there in the wild, and thought let me see if any of the chips I got from 2 different vendors (a few from eBay and a few from AliExpress) were fakes. So out came the industrial Acteone (100% pure) and the Q-Tips. And here's what I soon discovered.

 

The top one I left as I got it, although I'm 99.9% certain that it too is a fake.

FAKE_AY-3-8910A.thumb.JPG.e36ede0fc5db822d8ffc9814c0de3aac.JPG

 

As can be seen these chips started out life as a Yamaha YM2149F which for all practical purposes is virtually the same as a GE/Microchip  AY-3-8910A. It was a licensed clone being produced at the time, which I guess there are still a lot in circulation.

 

Here's a good comparison : https://maidavale.org/blog/ay-ym-differences/

 

I do have some of what I hope will be genuine AY-3-8910A chips coming from a US Arcade Company. However these are coming at a cost of $30 for two when the only shipping choice offered was Priority Mail. I just want to compare for myself. However in the real world I don't see anything wrong with using the fakes, since they are essentially the same as what they are faking, and considerably cheaper.

 

In closing, I also found a chip that actually was a real AY-3-8910 that had been painted over and reprinted as an AY-3-8910:lolblue:

 

EDIT: I've decided to add the YM2149F as an alternate for the AY-3-8910A to my BOM, Schematic, and to the silk-screen on the CV-NUC+MSX Module. The YM chips can be purchased for as little as $2.50 each delivered to your door when more than one is purchased at the same time. And it'll likely come to you without a blacked out top and being re-labeled, having the original factory markings. In my opinion they work just as well as the AY chip.

 

5 on the way :)

image.thumb.png.c9abb5b83f7a85bc288975cb868cba9e.png

Link to comment
Share on other sites

System Compatibility

 

At this point in time stuff just seems to work as it's suppose to, all except for one thing...

 

And that thing is that these 5 Atari Soft games are holdouts, not wanting to respond to the controller. Very odd, and I have no explanation for why this is so.

  1. Centipede
  2. Dig Dug
  3. Defender
  4. Joust
  5. Pacman

However there is one AtariSoft game that does work, and that is Galaxian. Also the SGM version of Joust works like a charm, and looks the closest to an arcade version that I've ever seen, but it would be extra nice to get these 5 working as well.

 

So this leaves me wondering and scratching my head as to why these 5 games all by AtariSoft don't see the controller on my system??? There's obviously something odd that AtariSoft has done in these titles that is not normal or usual for reading the controllers.

I already tried substituting a 74LS00 for the HCT version, which made no change. And if my memory serves me correctly, I also tried substituting an LS part for the 138 decoder -- still no dice.

1002527196_CV-NUC_JOY-Decode_schema-1.thumb.png.5f843f21f7e2ce0a5a60dc4ef364b314.png

 

Does anyone have any ideas on something that I should look into?

Link to comment
Share on other sites

2 hours ago, 5-11under said:

No explanation, but I think I had that problem with my Collectorvision Arcade Controller... even though it was built to spec, with proper diodes. Maybe someone else who has one can test that out on a stock CV 

Thanks for the feedback :)

 

I'm testing with stock CV controllers, so it's very doubtful that both of them are defective in the same way. No its got to be something directly attributable to my CV-NUC+ that just doesn't like whatever AtariSoft has done in there controller read code. As to what that is, I'm no coder so that's not in my wheel house to answer at the moment. Likely a very 'edge' case, since I've not come across anything besides those 5 games that exhibit this behavior. An extremely small percentage, and not one that will keep me from releasing my board design, but it certainly will be enlightening to know why. 

Link to comment
Share on other sites

17 hours ago, mytek said:

Something Just for grins ;-)

 

I was reading about all the fake AY-3-8910A chips out there in the wild, and thought let me see if any of the chips I got from 2 different vendors (a few from eBay and a few from AliExpress) were fakes. So out came the industrial Acteone (100% pure) and the Q-Tips. And here's what I soon discovered.

 

The top one I left as I got it, although I'm 99.9% certain that it too is a fake.

FAKE_AY-3-8910A.thumb.JPG.e36ede0fc5db822d8ffc9814c0de3aac.JPG

 

As can be seen these chips started out life as a Yamaha YM1249 which for all practical purposes is virtually the same as a GE/Microchip  AY-3-8910A. It was a licensed clone being produced at the time, which I guess there are still a lot in circulation.

 

Here's a good comparison : https://maidavale.org/blog/ay-ym-differences/

 

I do have some of what I hope will be genuine AY-3-8910A chips coming from a US Arcade Company. However these are coming at a cost of $30 for two when the only shipping choice offered was Priority Mail. I just want to compare for myself. However in the real world I don't see anything wrong with using the fakes, since they are essentially the same as what they are faking, and considerably cheaper.

 

In closing, I also found a chip that actually was a real AY-3-8910 that had been painted over and reprinted as an AY-3-8910:lolblue:

Interesting.  Is this chip socketed in the CV-NUC+ or soldered?  Is there any possibility that a genuine chip would run those 5 Atarisoft games?

Link to comment
Share on other sites

On 3/4/2023 at 6:29 AM, Atari Nut said:

Interesting.  Is this chip socketed in the CV-NUC+ or soldered?

Everything that is a THT chip on my board gets a socket. The exception is one SOIC 8-pin chip on the MAIN board, and a SOIC 16-pin chip on the QUAD board.

 

On 3/4/2023 at 6:29 AM, Atari Nut said:

Is there any possibility that a genuine chip would run those 5 Atarisoft games?

This chip has nothing to do with the controller ports, being strictly addressed as an auxiliary sound chip on the MSX Module. In fact it can be entirely removed with no ill effect to the system, since communication with it is a one way street.  Edit: I stand corrected on this. It is the SN sound chip that can be removed without any ill effect. The AY can be removed only if the game doesn't expect it to be there. If the game is SGM compatible, there will be a lack of data feedback if the AY chip is not present, since it has a 2-way communications protocol. However I'm not seeing how it would conflict with controller read routines on non-SGM games such as the 5 AtariSoft ones in question.

  • Like 1
Link to comment
Share on other sites

Maybe try something like the Joystick Test 2 ROM by Nitrofurano, which shows real data during joystick test and compare that with what you get on a real CV to see if you see a difference. That data may shed light on some unknown state that might be confusing those titles.

 

http://adamarchive.org/archive/ColecoVision/Cartridges/1996-202x - Homebrew Utilities/Joystick Test 2 - Keypad (2014) (Nitrofurano).rom

  • Like 1
  • Thanks 1
Link to comment
Share on other sites

5 hours ago, Tekman said:

Maybe try something like the Joystick Test 2 ROM by Nitrofurano, which shows real data during joystick test and compare that with what you get on a real CV to see if you see a difference. That data may shed light on some unknown state that might be confusing those titles.

 

http://adamarchive.org/archive/ColecoVision/Cartridges/1996-202x - Homebrew Utilities/Joystick Test 2 - Keypad (2014) (Nitrofurano).rom

No difference between stock CV and the CV-NUC+. I suspected that would be the case, since the AtariMax System Diagnostic Test said the same thing. Bottom line is that the AtariSoft games are using an unorthodox method to read the controller ports that isn't working on the CV-NUC+. Just to double check I also tried running the problem AtariSoft games on my stock CV, and they worked fine.

 

So what I need to know is what does AtariSoft's controller read routine look like, and how does it differ from the norm. 

Link to comment
Share on other sites

Update on AtariSoft Games ignoring controller...

 

DEFENDER

Ignores the 1 or 2 key to start game, however if you let it sit on the screen for 5 minutes the game will start on its own and you can play. All the controls appear to work at this time. But... after you lose, you are taken back to the game select blue screen, and once more the number keys fail to work.

 

I've tried taking the 74LS00 from my original factory stock CV and putting it into the CV-NUC+ in place of the 74HCT00 that I have spec'ed -- no dice.

 

On a separate subject: I've also discovered that I can remove the -5V and the two resistors (R18 & R19), and it makes no difference in the games that do correctly recognize the controller, so this confirms my suspicion that biasing the outputs of the NAND gate flip-flop circuit  to -5V is not needed. I always wondered about that, and it was the only reason I still had for providing -5V on my board. This also means I get to eliminate a few components from the BOM, always nice.

 

1545867054_CV-5V.thumb.png.4acdce7c355eb787b778da8c60717ca8.png

Link to comment
Share on other sites

Update March 8th 2023: Yeah I've seen zero affect from not having -5V and that pull-down resistor in play on the HCT00 outputs. The more I looked at that circuit, the more I scratched my head on how that could possibly have any influence on the voltage level of the outputs. 1.5K only represents a 3 ma current flow to -5V, which would be easily overridden by an HCT chip on either logic level. Maybe it played a role in doing something when all LS logic was in use, since an LS chip doesn't have much drive current for a logic HIGH. Anyway I'm leaving out the -5V charge pump and the pull-down resistors on my board until I see some evidence that it should be there.

Link to comment
Share on other sites

39 minutes ago, mytek said:

Update on AtariSoft Games ignoring controller...

 

DEFENDER

Ignores the 1 or 2 key to start game, however if you let it sit on the screen for 5 minutes the game will start on its own and you can play. All the controls appear to work at this time. But... after you lose, you are taken back to the game select blue screen, and once more the number keys fail to work.

 

I've tried taking the 74LS00 from my original factory stock CV and putting it into the CV-NUC+ in place of the 74HCT00 that I have spec'ed -- no dice.

 

On a separate subject: I've also discovered that I can remove the -5V and the two resistors (R18 & R19), and it makes no difference in the games that do correctly recognize the controller, so this confirms my suspicion that biasing the outputs of the NAND gate flip-flop circuit  to -5V is not needed. I always wondered about that, and it was the only reason I still had for providing -5V on my board. This also means I get to eliminate a few components from the BOM, always nice.

 

1545867054_CV-5V.thumb.png.4acdce7c355eb787b778da8c60717ca8.png

Thanks for the update.  Do you know if Captain Cozmos is willing to look at the Atarisoft titles to see how they interact with the controllers?

Link to comment
Share on other sites

5 hours ago, Atari Nut said:

Thanks for the update.  Do you know if Captain Cozmos is willing to look at the Atarisoft titles to see how they interact with the controllers?

It wasn't me that suggested it, so I really don't know. But if he wants to and has the time to spare that would be great, because I'm rather stumped by what's going on so the more eyes looking at this the better. Obviously there are some differences in the chips and the gate allocations on my board vs. a stock CV. But I'm really not seeing how that is causing this issue. And even when I duplicated the use of LS parts for the controller interface I still saw the same result with the AtariSoft games.

Link to comment
Share on other sites

4 hours ago, dankcomputing said:

Could you use a YMZ284 instead of a full AY-8910? That would really save on space provided there's a supply available.

Unless I'm mistaken that doesn't look like a drop-in for the AY as far as the interface and operation is concerned, which makes it a no-go if I want this to reproduce audio on the SGM games that have already been developed.

 

EDIT: Just found the datasheet and took a quick glance, it just might work. And it looks like it's available from the usual sources for these discontinued chips. I'll have to sample one. It could make a dramatic change in the height of the MSX Module which could be enough to get it to fit the 576NUC+ case without any changes other than adding a few holes. I'm game 👍

 

Layout looks possible...

589553567_CV-NUCMSXII.thumb.png.39c22410f13c4ee234b3ecd4ae4d93f6.png

 

  • Like 1
Link to comment
Share on other sites

6 hours ago, mytek said:

DEFENDER

Ignores the 1 or 2 key to start game, however if you let it sit on the screen for 5 minutes the game will start on its own and you can play. All the controls appear to work at this time. But... after you lose, you are taken back to the game select blue screen, and once more the number keys fail to work.

I'm not Captain Cosmos and I don't have much practice doing this sort of thing, but I've been looking for an excuse to mess with the Gearcoleco emulator's debugger.  Looking at what is going on during the Defender player-select screen was a wonderfully small/simple/reproducible test case to dig into (especially with your extra info about the 5 minute timer that would have otherwise probably stumped me).

 

The inner loop while waiting for the user to make a choice is only 18 instructions long, so it's not even that onerous to post the whole thing here (including my rough pseudo-C conversion at the side):

 

...
8749 LD A, $80     // A = 128;
874B OUT ($80), A  // port[0x80] = A; // Writing to port 80h enables keypads and right trigger.
874D NOP           // (wait)
874E NOP           // (wait)
874F IN A, ($FC)   // A = port[0xFC]; // Read from port FCh, containing controller 1's buttons.
8751 CP $7D        // Z = A - 0x7D; // Mask for controller 1 button 1.
8753 JR Z, $876D   // if (Z != 0) goto OnePlayerSelected;
8755 CP $77        // Z = A - 0x77; // Mask for controller 1 button 2.
8757 JR Z, $8773   // if (Z != 0) goto TwoPlayersSelected;
8759 IN A, ($FF)   // A = port[0xFF]; // Read from port FFh, containing controller 2's buttons.
875B CP $7D        // ...
875D JR Z, $876D   // if (controller2 button1) goto OnePlayerSelected;
875F CP $77        // ...
8761 JR Z, $8773   // if (controller2 button2) goto TwoPlayersSelected;
8763 DEC DE        // DE--;
8764 LD A,E        // A = E;
8765 OR D          // A |= D;
8766 JR NZ, $8749  // if (A != 0) goto beginning of loop; 
...

 

It's super simple and boils down to the following:

 

- Select keypad input.

- Wait two NOPs.

- Read from controller 1.

- If button 1 is pressed, choose a one player game.

- If button 2 is pressed, choose a two player game.

- Read from controller 2.

- If button 1 is pressed, choose a one player game.

- If button 2 is pressed, choose a two player game.

- Count the timer down.

- Unless the (shorter) timer (stored in DE) has reached zero, jump back to the beginning.

 

(There is an outer loop that handles counting down a longer timer stored in HL because DE's 16-bit count runs out every ~3 seconds, but it's presumably inconsequential for our purposes here.)

 

I haven't looked at the input circuit in detail, but only two hypotheses come to mind:

 

1. Two NOPs aren't long enough in your machine for something to settle/update (are your filter/bypass capacitors larger than on the stock machine so they transition slower)?

 

2. Those four compares (CP) depend on the returned flags matching exactly.  I suspect on stock hardware if you were to, say, hold down button 5 while attempting to press 1 or 2, the game would probably not proceed past that screen.  It needs to be only button 1 or only button 2.  So, if the high bits from port FC and FF are coming back with garbage or zeroes (instead of being set to 1 for "not pressed"), then those compares will never match.

 

EDIT: I just tested that "holding button 5" assumption in the emulator and pressing 1 or 2 did nothing, as expected.  Also, it's worth noting that the 0x77 and 0x7D button comparison masks seem to assume bit 7 is always going to be 0.  Is that the case on the CV-NUC+?  With no keypad buttons pressed, reading from the input ports should come back as 0111 1111.

Edited by Falonn
  • Like 1
  • Thanks 1
Link to comment
Share on other sites

Upon proof-reading, I just spotted something in my pseudocode that might be confusing or considered a mistake.  The "Z != 0" tests for the CP lines are technically correct ("JR Z" checks the Z flag to see whether it is "set"), but the lines before it "Z = ..." aren't quite how you'd render the Z flag update as C-like code.  It should be something closer to "Z = !(A - 0x7D)", making the "did it end up as zero" a little more explicit.  I understood and relayed the final explanation correctly, but just reading the pseudocode might give you the wrong impression.  And apparently the edit time window for that post has passed.  Sorry for the confusion!

 

On 3/4/2023 at 3:10 PM, mytek said:

No difference between stock CV and the CV-NUC+ [in the  Joystick Test 2 ROM by Nitrofurano]...

Were you looking at all of the bits?  If you hold the 1 button on controller 1 while running the joystick test ROM, this is the important bit pattern (especially that leading zero):

 

image.thumb.png.27405c6caa6f7e608ec1ea4423c61e68.png

 

If that matches, then Defender should advance beyond the player count select screen when you press 1.

 

  • Thanks 1
Link to comment
Share on other sites

Thank you @Falonn for all your hard work and insight on this problem I am having. I just woke up to find your posts, and will do some further testing a bit later today.

 

8 hours ago, Falonn said:

I haven't looked at the input circuit in detail, but only two hypotheses come to mind:

 

1. Two NOPs aren't long enough in your machine for something to settle/update (are your filter/bypass capacitors larger than on the stock machine so they transition slower)?

I'm using the same RC network on the 74LS00 Flip-Flop outputs as a real CV (120 ohms and 10nF), and have matched the 22K pull-ups on the 74LS541 interface chips. So just like a stock CV, that RC filter on the 'common' for either the keypad or the joystick aspects is really the only filtering that exists. And although I had substituted a 74HCT00 part in my design, I also tested with a 74LS00 pulled from my working original CV with no change in operation. I can certainly try reducing the value of the caps to see what happens.

 

6 hours ago, Falonn said:

Were you looking at all of the bits?  If you hold the 1 button on controller 1 while running the joystick test ROM, this is the important bit pattern (especially that leading zero):

 

image.thumb.png.27405c6caa6f7e608ec1ea4423c61e68.png

 

If that matches, then Defender should advance beyond the player count select screen when you press 1.

I probably wasn't paying good attention to that detail. I'll look again before I make any changes.

Link to comment
Share on other sites

13 hours ago, mytek said:

Unless I'm mistaken that doesn't look like a drop-in for the AY as far as the interface and operation is concerned, which makes it a no-go if I want this to reproduce audio on the SGM games that have already been developed.

 

EDIT: Just found the datasheet and took a quick glance, it just might work. And it looks like it's available from the usual sources for these discontinued chips. I'll have to sample one. It could make a dramatic change in the height of the MSX Module which could be enough to get it to fit the 576NUC+ case without any changes other than adding a few holes. I'm game 👍

 

Layout looks possible...

589553567_CV-NUCMSXII.thumb.png.39c22410f13c4ee234b3ecd4ae4d93f6.png

 

will it work since you cant read from the ymz284? sgm test will probably fail since to detect the chip you write to and than read from looking for your data ? 

  • Thanks 1
Link to comment
Share on other sites

15 minutes ago, chart45 said:

will it work since you cant read from the ymz284? sgm test will probably fail since to detect the chip you write to and than read from looking for your data ? 

Good point 👍

 

If I had full access to all of the data lines from the CPLD I could've had the CPLD fake a read response, but unfortunately I don't have that full access (only D0 & D1) :|

 

Kinda sad since that YM chip would've worked if it weren't for the AY detection test, and it's no bigger than the SN chip. I think in all other regards it's suppose to be software compatible with its big brother the YM2149F from a sound generation point of view.

Link to comment
Share on other sites

yep should work if game dont look for the psg i dont know how many game work without the psg. i have an adam that play sgm game with no soud and another adam that dont play sgm game if the sound chip is not there so its weird for the psg detection. can you get this chip from a us seller ?  cause you could test it with a breadboard hard wire to your system

Link to comment
Share on other sites

20 minutes ago, chart45 said:

yep should work if game dont look for the psg i dont know how many game work without the psg. i have an adam that play sgm game with no soud and another adam that dont play sgm game if the sound chip is not there so its weird for the psg detection. can you get this chip from a us seller ?  cause you could test it with a breadboard hard wire to your system

I do have a few coming from a Chinese eBay seller. But even if it worked with a few SGM games, it probably would fail many others. Opcode gave a very simple outline of how to test for the AY chip, but it wasn't specific in the sense of what to write, which register(s) to write into, and how many different registers to test in order to verify that the AY chip exists. So the only way to insure that every possible test would pass is to have at least the same number of read and writable registers as the AY chip. An impossible task with where my hardware presently stands if there isn't the equivalent to the AY or fully compatible chip on the other end.

 

If we could rewind time and come to a consensus that chip detection isn't required, this much smaller, but equally capable YM chip would have been the way to go. I think this would have made the early 74xxx based SGM Module a hell of a lot easier to build and given it a much smaller footprint. Those AY chips are huge, and quite frankly the extra I/O they have is just wasted in the SGM. Oh well no sense crying over spilled milk ;-)

Link to comment
Share on other sites

3 hours ago, mytek said:

I can certainly try reducing the value of the caps to see what happens...

My money is on the second hypothesis.  It fits the evidence better.  Checking the whole keypad byte at once would definitely fall into the realm of the "what is Atarisoft doing differently than the way 'normal' games check controller input" question that you had asked.  There is a Z80 instruction (BIT) that was basically made to do this kind of test.  That method only checks a single bit (for a single button at a time) and I'm guessing it was used by game developers in 98% of situations.  I'm having trouble even coming up with a reason you'd want to do it the way Defender does unless you really wanted to make sure no other buttons were pressed at the same time.  That would help explain why the problem has been so rare in your testing.

 

So my guess is you won't have to tinker with any RC networks.

 

EDIT: "Why would Defender do it that way?": maybe cycles?  This flavor of CP is 7 cycles while the equivalent BIT is 8 cycles.  Maybe they needed to squeeze out a tiny bit extra to help calibrate their 5-minute timer?

Edited by Falonn
Link to comment
Share on other sites

On 3/7/2023 at 10:02 AM, Falonn said:

So my guess is you won't have to tinker with any RC networks.

You were right. here's what I'm seeing.

Controller_Test.PNG.30aa5da96cd1b4e473f5c1dd27b3564b.PNG

 

And it's my fault (of course). Because I had included the A8 (D7) input of the 74LS541 into the SIP resistor array 2.5V pull-up circuit on my design. This caused it to register a '1' in that last bit position. So the fix is to change from a 9-pin 22K SIP, over to an 8-pin SIP instead, as well as add a 10K pull-down resistor to the A8 input on the 74LS541 chip.

 

1443101296_CV-NUC_Controller_Fix.thumb.png.37bf354539a717550cc060472303c4c8.png

 

But I think because of the lack of room down in that area of my board, I' won't bother to update the PCB, but instead simply tack a 10K resistor on the bottom side of the board between the now empty SIP resistor pad and pin-10 on the 74LS541 IC chip (see photo below). This will serve to keep the D7 bit pulled low when no USB Mouse or Roller-Controller is present. However one concession is that if you want to play those particular AtariSoft games, you do need to be sure that the USB mouse or its wireless receiver are not plugged in.

 

1853936063_CV-NUC_Controller_Fix_PCB.thumb.png.90f85ceff3b184b4b21e5ca2d049d41e.png

 

After I did this fix, all appears to be well and I can now activate the 5 AtariSoft games that failed to acknowledge any of the keypad buttons.

 

I also discovered as part of this adventure that none of the -5V circuitry is needed. So none of that will get stuffed into the board during the assembly (EDIT: I've updated the gerbers and removed those parts).

 

EDIT: BTW @Falonn I don't think I would have ever figured this out without your help -- thank you from the bottom of my heart.

  • Like 3
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...