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

[+mytek]

I got a question...

 

I did get full SGM support on this project this morning, but I noticed an odd thing when the AY-3-8910 is playing and then I push reset on my AtariMax Ultimate SD Cart -- the last sound keeps on going. The only way to stop it, is to either push system reset, or load up another SGM compatible game.

 

So is this normal?

 

[juansolo]

11 hours ago, mytek said:

I got a question...

 

I did get full SGM support on this project this morning, but I noticed an odd thing when the AY-3-8910 is playing and then I push reset on my AtariMax Ultimate SD Cart -- the last sound keeps on going. The only way to stop it, is to either push system reset, or load up another SGM compatible game.

 

So is this normal?

 

Interesting in that seems to be almost the same problem the Dragonfly 7800 cart used to have with the Yamaha sound chip. No idea how @rj1307 fixed it in the end. Originally there was a hardware bodge, but I think he fixed it in software later.

[+mytek]

26 minutes ago, juansolo said:

Interesting in that seems to be almost the same problem the Dragonfly 7800 cart used to have with the Yamaha sound chip. No idea how @rj1307 fixed it in the end. Originally there was a hardware bodge, but I think he fixed it in software later.

Yeah after thinking about it, I figured that it was probably not unusual for this to happen for this use case. Since the AY is designed to autonomously produce whatever sound it was last programmed to create, this sound wouldn't get terminated when leaving the game via the AtariMax reset switch. Likely it would require a software revision in the Atarimax to have it send a sound shutdown sequence to the AY chip, thus being a software fix for the problem.

[+mytek]

Got the First CV-NUC+ Test Board Built and Running!!!

 

I got the first assembled PCB up and running with full SGM support. However it took me 2 days to have a working system after doing the assembly, with the CPLD holding up the show at first. But once I figured out that I had an unnecessary inverter in the path of the 'mirror RAM' function, it fired up and worked like a dream.

 

Here's a quick demo video of it in action (BTW I'm suffering from a cold, hence the nasally sound of my voice)...

 

System Highlights

• Currently this is ONLY an NTSC system.
• Motherboard Foot Print: 4.5" x 4.5" (11.43 CM Square).
• Power supply to be single voltage 12VDC @ 2 Amps wall adapter with 2.5mm x 5.5mm coaxial plug.
• Super Game Module is built-In via plug-in daughter board (it isn't optional, since it contains all the main system RAM as well as the TI sound chip).
• The CPLD on the SGM daughter board runs the show, and in essence serves as the MMU, eliminating numerous 7400 series ICs that would have otherwise been required.
• Roller Controller support and USB Mouse-to-Quadrature handled by additional daughter board.
• High Quality noise-free S-Video and Composite output via 5-pin DIN jack matching Atari 8-bit pin-out (also carries audio signal).
• Only two 4-bit x 16K '5V only' DRAM chips required for Video RAM (there are 8 on the stock CV). This was made possible by using the *TMS9128 VDP (different VDP than standard Colecovision).
• True hardware Pause Switch, with flashing LED 'active' indicator. This will pause any game indefinitely.
• 3D printed case planned, with built-in numeric keypad.
• Full public release of all build files to happen no later than June, and might even see a March 2023 time frame.
• Files will be released without any stipulations, to be freely used in whatever way a person sees fit, as well as no conditions will be attached about making units for sale.
• To be perfectly clear, I expect no monetary kick back what-so-ever, and people are allowed to make a profit from what they do sell.

 

*The TMS9128 VDP chip still has R-Y, B-Y, and Y outputs same as original VDP so theoretically it should still work with the F18A VGA adapter.

 

CV-SGM CPLD Internal Representation as a Schematic (thanks to Protel99 SE software)

 

Protel CV-SGM CPLD Schema V1.3.pdf

 

This got translated to PLD source code and then compiled into a jed file for flashing the CPLD. It also marks the very first time I coded a CPLD, or any PLD (or GAL) for that matter. Although I've usually implemented other peoples PLD code in my projects, this one required me to "science the shit out of it" on my own, as well as heeding the advice of several of the members here   And the Adam Technical Manual really spelled out the memory management aspect, after I read that section upteen times until it soaked into my brain.

 

I would like to thank and acknowledge the following people that led me down the correct path on this project: @ChildOfCv, @chart45, @leaded solder, @fieroluke, @5-11under  and  @nanochess for his great little SGM test program that let me know I got it right, and @Pixelboy for providing free downloads of some of his SGM games for a final test 👍

[chart45]

wow its pretty awesome to see your project  in action 

[+mytek]

23 hours ago, chart45 said:

wow its pretty awesome to see your project  in action 

Thanks

 

Yeah when I first fired up the system a few days ago and all I got was color static on screen, that was a sad day, and a sense of foreboding as to how to troubleshoot this set in (can't really scope probe a CPLD very easily). This being my first ever attempt at coding a CPLD was certainly not done in baby steps, and because of the magnitude of the project I started to feel like I bit off more than I could chew for sure. So I built a very simple bit of CPLD code that only decoded the bare necessities, that being one 74138 decoder, and routed it's outputs to select the OS ROM, RAM, and the Cart, with the RAM addresses from A10-A14 deactivated (1K mirrored RAM). This basically made it into a stock CV and greatly reduced the complexity of the CPLD. When I re-flashed the CPLD with this code, the system did indeed work as a stock CV 👍

 

So at least at that point I knew the overall concept and execution was sound, and that there must have been an error in my SGM code. And that's when I suspected that there might be a problem centered around my method of terminating all unused outputs of the SGM 74138 decoder in the code. So I took a different approach for doing that and things began to fall into place. Except it wouldn't pass @nanochess's SGM test program, still thinking it was a stock CV. Later I found the offending inverter in the code, which when removed allowed the SGM version to start working.

 

When you originally shared your 7400 series SGM circuit with me, that really became the basis for what came next, and gave me a great initial launch and understanding of how the SGM worked. Thank you for that. And I can also thank the size constraints of this project for forcing me to come up with a way to program a CPLD to replace the 7400 series logic 👍

 

Besides the CPLD issues, there were other small problems with the board in general, which was to be expected. Out of all of those I think the biggest was the 10.73 Mhz VDP oscillator being way off frequency and unstable. Luckily this was a very easy fix, only requiring the addition of one more capacitor. Also had to de-complicate my audio mixing circuit which wasn't working well for the AY chip (very distorted). It was a case of just implementing the audio output circuit shown in the datasheet (2 resistors and a capacitor), and adding one more resistor to mix in the SN chip's audio, so as to have a single audio stream. Keep it simple principle in play.

 

So pretty soon I'll be ordering a 2nd set of boards with all the fixes integrated.

[+mytek]

I just discovered that my system was being identified as an ADAM and not a CV. Which actually made a lot of sense when I looked at my PLD source schematic from yesterday. I hadn't taken in account the default power-up state of the latch associated with 1K vs. 24K assignment. In V1.3 it was set to come up with 24K RAM enabled -- essentially an ADAM. So it was as simple matter to fix the latch to power-up in 1K CV mode.

 

Updated Protel CPLD Schematic

 

Protel CV-SGM ATF1500 CPLD V1.4 schema.pdf

 

 

Now it tests 100% correctly 👍

 

This is where having a programmable device for the MMU really pays off

[+mytek]

Well I spoke too soon. When I went to test the 42 Pixelboy SGM games I had downloaded using this new CPLD core (V1.4), over half of them didn't work resulting in a black screen. However when I went back to the previous CPLD version (V1.3) all but one of the games worked (Ghost Busters).

 

Here's the SGM verification test with the V1.3 CPLD core.

Definitely recognized as being an ADAM.

 

So this leaves me a bit confused 🤔

 

I guess I could just leave it at using the V1.3 core which still seems to work fine with non-SGM games, but I'd really like to know why the V1.4 core isn't working as well with SGM games.

 

EDIT: Thinking about this a bit more, I have to keep in mind that my SGM implementation is a bit different with it not being an add-on, but integrated instead. I know opcode has mentioned that his SGM comes up with it's RAM disabled, so as not to conflict with the ADAM's internal memory, and relies on the the SGM specific games to test whether the module is plugged into a CV or an ADAM before enabling the module's extra RAM. I'm not privy to all the details surrounding this, but perhaps my integrated version somehow looks different and confuses certain games when it's configured for 1K, but then appears ok when looking like an ADAM.

 

In fact that might very well be the problem, since I need my version to supply at least 1K of working RAM, whereas I'm imagining that opcode's SGM doesn't. But if I instead provide 24K of non-mirrored RAM the SGM game's test routine is happy, since my board simply looks like an ADAM, with an SGM attached.

[chart45]

less problem for you to not use sgm since its opcode trade mark.. the adam + sound chip will give you the same result without the sgm trouble... im waiting to order and try my f18a on your project.

[+mytek]

15 hours ago, chart45 said:

less problem for you to not use sgm since its opcode trade mark.. the adam + sound chip will give you the same result without the sgm trouble... im waiting to order and try my f18a on your project.

I thought it was a possible Coleco trade mark from back in the 80's? Well I used the name because it allows 'SGM' games to be played on this mini system. I guess I could have called it an MSX module instead, since many of those games are where the SGM ports began life as

 

Bottom line what I'm doing is not a threat to anyone, and I never intend to profit off of the CV-NUC, nor make any for sale. And as far as the tech and what registers are involved, it came out of documentation freely available online, with some of it dating back to the early 80's. My design and the CPLD core are a unique creation and not a copy of any pre-existing design. In fact I've never ever had in my possession any opcode SGM, schematics of such, or the CPLD source or jed files for it. In fact if anyone skims through this thread they'll see the evolution of what I've done, and how it came to be

 

And I'm certainly not the first person to incorporate this idea into a Colecovision clone of a non-commercial nature.

 

EDIT: Hey isn't the name Colecovision a trademark as well? Boy if so, then there are a lot of people infringing on it. And what about all those commercial game ROMs that you can download for free? I doubt that each and every author gave his or her permission to do that. This goes round and round in circles over on the Atari forums all the time where I frequent, and just ends up being a fruitless discussion.

 

EDIT2: Well since I will have to make some revisions to both boards anyway due to technical reasons, I may as well scrub the SGM name from the silk screens and schematics just so there's no possible issues down the road.

[+mytek]

I've decided that the CV-NUC+ is going to look like an ADAM, with 24K enabled from the get go (it'll use the V1.3 CPLD core). This gives it very good compatibility with existing SGM games as well as non-SGM games. If someone does want it to be a CV, then their software merely has to set bit 0 of the 53h register to 0, and it becomes a CV with 1K mirrored RAM.

 

In either case, the AY-3-8910 sound chip is accessible via registers 50h-52h.

 

And of course swapping RAM for the BIOS ROM is via register 7Fh (as per the ADAM Technical Manual).

 

EDIT: When I say "look like an ADAM" I meant only from an initial RAM standpoint. It certainly isn't an ADAM in most regards (missing keyboard port, drive support, ADAM-NET, and the expansion slots)

[massiverobot]

53 minutes ago, mytek said:

I've decided that the CV-NUC+ is going to look like an ADAM, with 24K enabled from the get go (it'll use the V1.3 CPLD core). This gives it very good compatibility with existing SGM games as well as non-SGM games. If someone does want it to be a CV, then their software merely has to set bit 0 of the 53h register to 0, and it becomes a CV with 1K mirrored RAM.

 

In either case, the AY-3-8910 sound chip is accessible via registers 50h-51h.

 

And of course swapping RAM for the BIOS ROM is via register 7fh (as per the ADAM Technical Manual).

 

OK now that it's an ADAM I'm def. waiting for the FujiNet daughter board for this thing!

 

 

[+mytek]

5 minutes ago, massiverobot said:

OK now that it's an ADAM I'm def. waiting for the FujiNet daughter board for this thing!

Better get yourself several books to read (maybe even a library of them), because you'll be waiting a long time

 

Bottom line there is no readily available system bus to tie that into, unless someone were to piggyback the CPU somehow. I'd say give it up and just go buy yourself an AtariMax Ultimate SD Cart for this and be content to play games offline, or use your 'real' ADAM instead.

[massiverobot]

31 minutes ago, mytek said:

Better get yourself several books to read (maybe even a library of them), because you'll be waiting a long time

 

Bottom line there is no readily available system bus to tie that into, unless someone were to piggyback the CPU somehow. I'd say give it up and just go buy yourself an AtariMax Ultimate SD Cart for this and be content to play games offline, or use your 'real' ADAM instead.

Oh so it doesn't implement the ADAMnet? I guess that is an issue if it doesn't.

 

I sold my real ADAM and was waiting for this one for the space savings

 

Edited January 9, 2023 by massiverobot

[+mytek]

10 hours ago, massiverobot said:

Oh so it doesn't implement the ADAMnet?

Nope this is still essentially the game console, with extra RAM and a sound chip. And due to its small size, it doesn't even have the standard expansion port. So please don't confuse this with the Atari 576NUC+ which was a full computer.

 

It's not to say that somebody down the road couldn't make an alternative RAM/Sound daughter board with Fujinet incorporated. Pretty much the whole system bus is available from that plug-in slot. But I would imagine it would need to also provide a way to support a wireless USB keyboard as well so that you can input URLs, passwords, and that sort of stuff. Pretty tall order, but likely doable. However it won't be me doing it

[NIAD]

18 hours ago, massiverobot said:

 

OK now that it's an ADAM I'm def. waiting for the FujiNet daughter board for this thing!

 

 

It won’t work as mytek explained. However, the FujiNet team has stated that they want to bring FujiNet to as many platforms as possible, including dedicated videogame systems. So far, the Atari Lynx is the only dedicated videogame system that has seen a FujiNet device developed, but I think there is a lot more development needed before it’s ready.

[+mytek]

3 hours ago, NIAD said:

It won’t work as mytek explained. However, the FujiNet team has stated that they want to bring FujiNet to as many platforms as possible, including dedicated videogame systems. So far, the Atari Lynx is the only dedicated videogame system that has seen a FujiNet device developed, but I think there is a lot more development needed before it’s ready.

The only way that would be possible on the CV would be if it also brought USB keyboard support with it. How else are you suppose to enter URLs and WiFi passwords? How was this accomplished on the LYNX version?

 

And so as not to block the expansion port for things like the steering wheel, it probably should be a cart, which also makes sense because it replaces carts

[NIAD]

1 hour ago, mytek said:

The only way that would be possible on the CV would be if it also brought USB keyboard support with it. How else are you suppose to enter URLs and WiFi passwords? How was this accomplished on the LYNX version?

I don’t recall and the posts would have to be searched for on the FujiNet FB Group.

 

Fir a videogame system, a FujiNet USB port would be the best option. A pop-up keyboard within the CONFIG program would be an option. One could also use the Lynx’ control pad and buttons to cycle thru but that would be tedious.

1 hour ago, mytek said:

And so as not to block the expansion port for things like the steering wheel, it probably should be a cart, which also makes sense because it replaces carts

The Steering Wheel does not connect to the Expansion Port… none of the extra controllers do.

 

Devices that use the Expansion Port are the Atari Adapter, EM#3 ADAM, Add-a-Halt Pause, Opcode SGM and RAMBOard.

I agree that if a ColecoVision FujiNet device was made, that it would be best to use the Cartridge Port (if all the needed lines are available) seeing as we wouldn’t want to have to remove the Opcode SGM or:

 

- wouldn’t want to have to add a Multi-Unit adapter

 

- wouldn’t want a CV FujiNet made for the Expansion Port to also have to include the extra RAM and AY sound chip of the SGM

 

[NIAD]

Actually, any possible CV FujiNet device would have to be very carefully thought out between using the Cartridge Port or the Expansion Port.

 

If the Cartridge Port was to be used, then it would have to include a Pass-Thru connector to attach other cartridges to otherwise any and all FujiNet compatible cartridges could only be made available as rom images to be placed on the SD Card. I prefer the rom image format over physical carts, but many do not including most CV Homebrewers… at least until after they sell out of their physical stock.

[+mytek]

4 hours ago, NIAD said:

The Steering Wheel does not connect to the Expansion Port… none of the extra controllers do.

Well now everyone knows I don't own a steering wheel

 

For some odd reason I thought it did connect through the expansion port. But now that I think about it, why would it need batteries if that were the case

 

4 hours ago, NIAD said:

Devices that use the Expansion Port are the Atari Adapter, EM#3 ADAM, Add-a-Halt Pause, Opcode SGM and RAMBOard.

Thanks for the info on this. Eventually I'll be fully up to speed on all things CV and maybe even ADAM. I'm definitely a newbie to this stuff, and never had any of this equipment back in the day. In fact as of 6 months ago I didn't have the faintest clue. Now look at me designing and building my own clone CV system with a few extra features to boot.

 

4 hours ago, NIAD said:

I agree that if a ColecoVision FujiNet device was made, that it would be best to use the Cartridge Port (if all the needed lines are available) seeing as we wouldn’t want to have to remove the Opcode SGM or:

 

- wouldn’t want to have to add a Multi-Unit adapter

 

- wouldn’t want a CV FujiNet made for the Expansion Port to also have to include the extra RAM and AY sound chip of the SGM

Yep all good points 👍 Including...

4 hours ago, NIAD said:

If the Cartridge Port was to be used, then it would have to include a Pass-Thru connector to attach other cartridges to otherwise any and all FujiNet compatible cartridges could only be made available as rom images to be placed on the SD Card.

 

4 hours ago, NIAD said:

I prefer the rom image format over physical carts, but many do not including most CV Homebrewers… at least until after they sell out of their physical stock.

Me too since I purchased an AtariMax Ultimate SD Cart. And I've found quite a few carts as rom images on the ColecoVision Addict website, and was also pleasantly surprised at all the SGM releases by Pixelboy (42 according to my last count).

[NIAD]

2 hours ago, mytek said:

Well now everyone knows I don't own a steering wheel

No shame! 😃 The Driving Module connects to joystick port #1 and the hand controller connected to port #02 sits in a controller bay in the Driving Module. Then the foot pedal plugs into the Driving Module. Coleco really confused everyone by called it the Expansion Module #2 and I guess they learned their lesson seeing as they did not call the Super Action Controllers or the Roller Controller an Expansion Module.

2 hours ago, mytek said:

In fact as of 6 months ago I didn't have the faintest clue. Now look at me designing and building my own clone CV system with a few extra features to boot.

Um, yeah, a lot of us have noticed and are impressed! 👍

2 hours ago, mytek said:

Yep all good points 👍 Including...

The more that I consider it, I would prefer a possible CV FujiNet to be made for the Expansion Port with a pass-thru card-edge connector to allow for the SGM to be daisy chained. The FujiNet devices/PCB are pretty small and a USB Port for keyboards could be placed on the right side and the 3 FujiNet buttons, 3 leds and SD drive slot on the top... preferrably a full size SD and not the Micro, but gotta take what is offered.

2 hours ago, mytek said:

Me too since I purchased an AtariMax Ultimate SD Cart. And I've found quite a few carts as rom images on the ColecoVision Addict website, and was also pleasantly surprised at all the SGM releases by Pixelboy (42 according to my last count).

Great site that is run by a great guy! Also check out the ColecoVision section on www.adamarchive.org

 

Edited January 11, 2023 by NIAD

[leaded solder]

This is a super cool project! Great work doing the "last 99%" and getting it to run, CPLD stuff is still a terrifying mystery to me.

[+mytek]

6 hours ago, leaded solder said:

This is a super cool project! Great work doing the "last 99%" and getting it to run, CPLD stuff is still a terrifying mystery to me.

Thanks 

 

I was terrified of it as well, and kept thinking what if what I did wasn't correct, how would I ever know for sure. And of course that is exactly what happened when I first powered the system up, all I got was static. So the best approach I could think of at that point was to simplfy it down to the bare minimum of one decoder and 1K of RAM. And that did work. So at least I knew the CPLD was working, and that I could accurately flash from a schematic entry. Then it was just a matter of analyzing the full MMU schematic and looking for errors.

 

When I first approached the idea of using a CPLD, I tried to take the equation approach, but I just couldn't wrap my head around it. So I kept looking for a more graphical method and discovered the older Protel software. It did have its quirks, but once I got the hang of it, things became pretty easy.

[+mytek]

After testing 300+ games with over 40 of those being SGM games, these don't work for me...

 

Black Screen right from the get go

• TeleBunny
• Arcomage
• Armageddon

Keypad/Fire Buttons and Joystick Not Recognized, either at the start, or maybe a couple of menus in

• Crazy Climber
• Crazy Chicky Jr
• DK3
• Jewel Panic
• Deep Dungen Adventure
• Math Quest
• The Black Onyx
• Bankruptcy Builder
  • The following are Atarisoft Titles -- many being prototypes
• Centipede
• Dig Dug
• Defender
• Pac Man
• Joust (the Joust from Williams did work, and it looks far more complete & has sound)

 

Title Screen comes up and then the system Locks Up

• Pitfall II

So approximately 5% don't like some aspect of my system. Not bad considering.

 

I was using the V1.3 CPLD core, which comes up with a memory configuration looking like a 24K ADAM. I'm also using the Fire-Skip BIOS ROM image. And loading all games from an AtariMax Ultimate SD Cart.

 

Does anyone see a pattern as to why these games have an issue?

 

EDIT: Obviously the main issue is the game ignoring controller input.

 

EDIT2: the ones that come up as a black screen were all SGM games, and one SGM game with the same problem that I didn't list was Ghost Busters which I already knew was an AtariMax issue. Might also be the case with the others as well. The ones that essentially ignore the controller, are starting to appear to be a problem associated with my clone CV system.  My stock CV is temporarily down for the moment after ripping out the RF modulator for some other experiments, so I have been relying on someone else to verify my results. Thus far this problem in particular really has me stumped. And It has been suggested that it might be a difference in RAM initialization on power-up, which might be the case, but presently it seems like a long shot and difficult to prove. Although it's made a bit more plausible by all the AtariSoft protos that exhibit the problem, making me think that those might have gotten sloppy with properly initializing stuff, and don't have a problem with how the stock 1K RAM comes up, but might with the 32K RAM chip I'm using instead.

[+mytek]

Well we've ruled out a number of the non functioning games to either a bad cart image or they are not intended to work from an AtariMax Ultimate SD Cart. What's left all ignore controller input. And I scratched off the Atarisoft ones due to them being prototypes, and the fact that there are good working alternatives for most all of them. So although I haven't been able to test all the possible games out there, 6 out of the 300+ games that were tested is probably acceptable losses unless I can pinpoint the actual problem and implement a fix for it (likely won't be possible without major hardware changes).

 

• Crazy Climber
• Crazy Chicky Jr
• DK3
• Deep Dungen Adventure
• The Black Onyx
• Bankruptcy Builder
  • The following are Atarisoft Titles -- many being prototypes
• Centipede
• Dig Dug
• Defender
• Pac Man
• Joust (the Joust from Williams did work, and it looks far more complete & has sound)