For me 1 or 4. The nice thing about the whole thing is that there can be many different implementation that don't require game recompilation. For me, a CVBS module seems the fastest and simplest way to get something running. Not perfect but good enough at this point IHMO. I've measured the above module and it consumes around 130ma. Quite reasonable in my opinion and the pcb is very small. Unfortunately this thing won't work with 5V and I can't seem to be able to patch in a 5V source either (yet). So to make it work I'd need a step-up converter to raise the voltage to 6V which willl be stepped-down later by the module. Not very efficient or elegant. The car monitor I mentioned has a PCB with a footprint for a header which you can patch in 5V, bypassing the onboard step-down converter.
Btw the green wedge artifact is due to bad timing in the kernel.
The quest to a portable Uzebox - update!
Re: The quest to a portable Uzebox
Got to think about it and some fgpa or pal(these things still exist?) would also be seem like a very elegant solution. Wouldn't Xmega require some insanely tight timing?
Re: The quest to a portable Uzebox
This idea is interesting to me since I always wanted to know more about FPGAs. Avoiding the whole D2A->AD725->A2D NTSC LCD conversion certainly appeals to what I think most here must have; an appreciation for efficiency. It seemed like the buy in was rather expensive, and the chips themselves were pretty expensive too(how cost efficient is it, versus keeping AD725 and a bigger battery for the limited units that will get made?). I hope this method gets explored simply so I can see it happen. The cheapest DIP FPGA I ever found is $40 here unless you want to go QFP/BGA stuff.uze6666 wrote:Got to think about it and some fgpa or pal(these things still exist?) would also be seem like a very elegant solution.
Personally I would rather have an UBP sooner rather than later and, somehow, the NTSC LCD really does look nice with all video modes. It's definitely a viable interim solution.
I bet that is the reason hes likes that methoduze6666 wrote:Wouldn't Xmega require some insanely tight timing?
-
- Posts: 1486
- Joined: Mon Feb 11, 2013 8:08 am
- Location: Brisbane, Australia
Re: The quest to a portable Uzebox
Modern FPGA come in tiny packages and are low voltage only. They also need a MCU or external EEPROM to program them (in most cases)
PAL don't really exist anymore. GAL are the modern enhanced equivalent. A GAL would not be enough by itself to do this job.
In between the two are CPLDs. They come in solder friendly 44 TQFP and are 5V tolerant for $2 for a unit that could do the TFT thing (XC9572).
Going by digikey - the cheapest FPGA that is in a solder friendly package (64 TQFP) is $10. More modern FPGA that have way more power than this needs are only $2 but they are in BGA package only. I don't mind soldering BGAs but I am pretty certain it would scare the hell out of most people.
The Xmega idea does not have that crazy a timing. Mainly because it has DMA that can point at I/O registers and be chained. The timing still has to be cycle exact, but there are no crazy tricks.
The other nice thing about the FPGA/CPLD/XMega to replace the AD725 thing, is that it could also replace the 4021 chips for the button inputs. So the XMega version for example really COULD be a two chip solution (XMega to drive LCD and Mega644 to run game)
PAL don't really exist anymore. GAL are the modern enhanced equivalent. A GAL would not be enough by itself to do this job.
In between the two are CPLDs. They come in solder friendly 44 TQFP and are 5V tolerant for $2 for a unit that could do the TFT thing (XC9572).
Going by digikey - the cheapest FPGA that is in a solder friendly package (64 TQFP) is $10. More modern FPGA that have way more power than this needs are only $2 but they are in BGA package only. I don't mind soldering BGAs but I am pretty certain it would scare the hell out of most people.
The Xmega idea does not have that crazy a timing. Mainly because it has DMA that can point at I/O registers and be chained. The timing still has to be cycle exact, but there are no crazy tricks.
The other nice thing about the FPGA/CPLD/XMega to replace the AD725 thing, is that it could also replace the 4021 chips for the button inputs. So the XMega version for example really COULD be a two chip solution (XMega to drive LCD and Mega644 to run game)
Re: The quest to a portable Uzebox
This is an extra lovely thing in the name of efficiency. I would guess 95+% of hobbyists wont attempt BGA. Even TQFP is very intimidating to us average solderers, if we consider the logic that the "fairly easy" AD725 comes pre-soldered in the kits to avoid failures. People would be pissy if all they managed to build was an expensive door stop.CunningFellow wrote:he other nice thing about the FPGA/CPLD/XMega to replace the AD725 thing, is that it could also replace the 4021 chips for the button inputs.
I am starting to like this line of thinking, if it looks as good, even at the expense of being able to connect to a real television. It seems pretty important that the 80 columns mode is feasible here for future Uzenet stuff. So many variables to think about...glad I get to simply speculate and enjoy the outcome
Edit - could we use the same screen Harty is using hereor too big?
Re: The quest to a portable Uzebox
The CPLD option might actually provide the ATmega644 RGB output to TFT conversion AND some kind of composite video output simultaneously.
I have been considering a CPLD for my console for some time now and should be possible to generate a clean NTSC signal with it. Just need to choose a device with enough memory to accommodate both output solutions. Don't have a clue about how much memory the TFT drive part would require, but the NTSC generation should fit in a XC9572 with much space left.
I have been considering a CPLD for my console for some time now and should be possible to generate a clean NTSC signal with it. Just need to choose a device with enough memory to accommodate both output solutions. Don't have a clue about how much memory the TFT drive part would require, but the NTSC generation should fit in a XC9572 with much space left.
-
- Posts: 1486
- Joined: Mon Feb 11, 2013 8:08 am
- Location: Brisbane, Australia
Re: The quest to a portable Uzebox
I think you would more need an FPGA to do that or at least a very large CPLD that could accommodate a look up table for RGB to Chroma/Luma. You can get by with a small CPLD when your CPU/GPU/Device is already outputting the pixels in Chroma/Luma space.Gabrias wrote:The CPLD option might actually provide the ATmega644 RGB output to TFT conversion AND some kind of composite video output simultaneously.
I have been considering a CPLD for my console for some time now and should be possible to generate a clean NTSC signal with it. Just need to choose a device with enough memory to accommodate both output solutions. Don't have a clue about how much memory the TFT drive part would require, but the NTSC generation should fit in a XC9572 with much space left.
Re: The quest to a portable Uzebox
It never came to my mind how Harty made it for his mini arcade. But, apart being a tad too big perhaps for a portable, I'm wondering if it could work without other parts?Edit - could we use the same screen Harty is using hereor too big?
Harty: do you have the schematics for your mini arcade?
Re: The quest to a portable Uzebox
I'd play Uzebox way more with one of these! I barely go near the TV these days.
Re: The quest to a portable Uzebox
Doh! I have received another of those monitors and it's a new PCB with no such 5V header. I'm about to throw the towel. If anybody here want's to take on the challenge to do the video part of this thing please join in!The car monitor I mentioned has a PCB with a footprint for a header which you can patch in 5V, bypassing the onboard step-down converter.