New PCB rev on the horizon

Topics regarding the Uzebox hardware/AVCore/BaseBoard (i.e: PCB, resistors, connectors, part list, schematics, hardware issues, etc.) should go here.
User avatar
D3thAdd3r
Posts: 3221
Joined: Wed Apr 29, 2009 10:00 am
Location: Minneapolis, United States

Re: New PCB rev on the horizon

Post by D3thAdd3r »

uze6666 wrote:Initially I didn't put the luma trap and after Clay Cowgill made the AVCore
Better video for the new version, nice!
uze6666 wrote:I also connected PA7 to GPIO0 to allow upload of new firmware to the esp8266.
Been waiting to see this, it looks great :D Being able to upgrade firmware easily will be a game changer as well. Does the ESP12 solder down surface mount style?

1 possible thought would be to break out 2 reserved pins(if there are still some free, or could coexist with JAMMA for accessories that wouldn't be practical for JAMMA anyways), to the controller port for the SNES IO Bit and Data2. It could allow more peripheral expansion for at least the Tribal Tap or other 5 player adapters. It could also be used as a /RST pin if we ever wanted to bit-bang ISP programming like they do on Arduino, you would have all the pins you need for any future peripheral to upgrade firmware for keyboards or whatever.

Anyways, please put me on the pre-order list!
User avatar
uze6666
Site Admin
Posts: 4801
Joined: Tue Aug 12, 2008 9:13 pm
Location: Montreal, Canada
Contact:

Re: New PCB rev on the horizon

Post by uze6666 »

Been waiting to see this, it looks great :D Being able to upgrade firmware easily will be a game changer as well. Does the ESP12 solder down surface mount style?
It can use pins and is also castellated. The pin spacing is not too bad, should not be harder than the the sd card socket. The esp-12e is the latest version and seem it has even better signal handling than the others.
1 possible thought would be to break out 2 reserved pins(if there are still some free, or could coexist with JAMMA for accessories that wouldn't be practical for JAMMA anyways), to the controller port for the SNES IO Bit and Data2. It could allow more peripheral expansion for at least the Tribal Tap or other 5 player adapters. It could also be used as a /RST pin if we ever wanted to bit-bang ISP programming like they do on Arduino, you would have all the pins you need for any future peripheral to upgrade firmware for keyboards or whatever.
You mean using some free i/o pins to the SNES port? For P2 port only I guess? There's not much left unfortunately, pretty much just PA5 & PA6.
User avatar
D3thAdd3r
Posts: 3221
Joined: Wed Apr 29, 2009 10:00 am
Location: Minneapolis, United States

Re: New PCB rev on the horizon

Post by D3thAdd3r »

uze6666 wrote:You mean using some free i/o pins to the SNES port? For P2 port only I guess?
I'm thinking the only practical thing those pins can be used for at this point is /CE for more SPI stuff? 5 player adapter I think is superseded by Uzenet really, so a moot point, but perhaps people would do new stuff like Uze Thermometer or such. Or multiple bit-banged SPI devices with /CE...if this is "the" expansion to the finalized Uzebox form, might as well use it all. This is random thoughts from a professed non-hardware guy so...a few grains of salt may be necessary.

The 12 is a good idea to keep us in the loop of future firmware. The addon module as it currently is, could probably remain viable as well if we play our cards right or were you thinking of a new version using the 12+ also?
User avatar
Artcfox
Posts: 1382
Joined: Thu Jun 04, 2015 5:35 pm
Contact:

Re: New PCB rev on the horizon

Post by Artcfox »

uze6666 wrote:
Artcfox wrote:
uze6666 wrote:Finally been working on the next revision of the uzebox PCB that integrates the ESP8266 and SPI RAM. I've basically added the content of the Uzenet module. I have to add another 3.3v regulator since the current one risk not being enough to power both the module and the sd card at the same time (we could try). I also connected PA7 to GPIO0 to allow upload of new firmware to the esp8266.

Here's the schematic and PCB layout. Please check it out for comments and obvious flaws, I'll order some prototypes this week. 8-)
f5.png
Uzebox Game Console F5.pdf
I've been meaning to ask you this since before I ordered my Uzebox kit. Why is the Luma trap notch filter tuned to the PAL frequency rather than NTSC? The schematic shown on page 15 the AD725 data sheet shows a 9 pF and an 18 pF capacitor connected in parallel for NTSC. If you leave out the 9 pF capacitor, then the notch filter is set to the PAL frequency. Shouldn't we be using a 27 pF capacitor there instead of the 18 pF that the kit currently ships with?
Initially I didn't put the luma trap and after Clay Cowgill made the AVCore, I blindly followed his schematic since he was the "real" engineer! That said, seems you are right, it's tuned to PAL. :? No wonder I never was too impressed with the luma trap. I'll order some 27pf to see how it looks.

Nice catch! :)
Ah okay. Thanks! :)

I've never tried the S-Video output, but I think that it might be a good baseline to judge how well the luma trap performs.
User avatar
Artcfox
Posts: 1382
Joined: Thu Jun 04, 2015 5:35 pm
Contact:

Re: New PCB rev on the horizon

Post by Artcfox »

uze6666 wrote:The big problem with it though is that it is slooow. Reading a single byte randomly with take ~110 clocks cycles vs 2 for the internal sram. In the best case where you read a stream of sequential bytes, it takes 18 cycles. That's still 10 times slower than the internal sram. Btw it's exactly the same speed as the SD interface.
I know I'm late to this thread, especially since you've designed a new PCB already, but have you looked into using the SPI RAM the way that the Logic Pirate uses it? I'm not sure if you saw the post I made about it in another thread.

Doing it that way, for streaming reads from SPI RAM (after setting up the address), you should be able to read an entire byte from SPI RAM -> internal SRAM in just a few clocks. The only hurdle with this approach is I'm not sure that you have an entire PORT free on the ATmega644 to read the entire byte from SPI RAM at once. Though, if you can spare 4 pins from the same PORT, you could probably beat 18 clocks per byte just by using a single RAM chip in QSPI mode, where each clock pulse allows you to read 4 bits out at once.

The other, even crazier option that might be possible, would be to use a tri-state buffer to somehow hook all 8 lines from two QSPI RAM chips directly into the R2R DAC, so you can dump an entire byte of raw color data directly to the video chip on every clock pulse.
User avatar
uze6666
Site Admin
Posts: 4801
Joined: Tue Aug 12, 2008 9:13 pm
Location: Montreal, Canada
Contact:

Re: New PCB rev on the horizon

Post by uze6666 »

'm thinking the only practical thing those pins can be used for at this point is /CE for more SPI stuff? 5 player adapter I think is superseded by Uzenet really, so a moot point, but perhaps people would do new stuff like Uze Thermometer or such. Or multiple bit-banged SPI devices with /CE...if this is "the" expansion to the finalized Uzebox form, might as well use it all. This is random thoughts from a professed non-hardware guy so...a few grains of salt may be necessary.
Rethinking about it, to make custom things using the SNES port, we would need a SNES cables that has 7 wires. All that I have from controllers have only 5. Also, It's probably better to use the EXT port since most uzebox out there already have it. I also see wifi being better than any multitap! So I think we should keep those two free pins for future use.
The 12 is a good idea to keep us in the loop of future firmware. The addon module as it currently is, could probably remain viable as well if we play our cards right or were you thinking of a new version using the 12+ also?
The simplest would be that I make a new version.

Code: Select all

I know I'm late to this thread, especially since you've designed a new PCB already, but have you looked into using the SPI RAM the way that the Logic Pirate uses it? I'm not sure if you saw the post I made about it in another thread.

Doing it that way, for streaming reads from SPI RAM (after setting up the address), you should be able to read an entire byte from SPI RAM -> internal SRAM in just a few clocks. The only hurdle with this approach is I'm not sure that you have an entire PORT free on the ATmega644 to read the entire byte from SPI RAM at once. Though, if you can spare 4 pins from the same PORT, you could probably beat 18 clocks per byte just by using a single RAM chip in QSPI mode, where each clock pulse allows you to read 4 bits out at once.

The other, even crazier option that might be possible, would be to use a tri-state buffer to somehow hook all 8 lines from two QSPI RAM chips directly into the R2R DAC, so you can dump an entire byte of raw color data directly to the video chip on every clock pulse.
We definitely don't have a free port for 8 bits, not even 4 right now with the SPI RAM CS, ESP reset and prog pins. Besides, adding all those chips defeats the idea of the Uzebox being simple and two chips. I was never hot even for the SPI ram since I never saw much gain that we can't already do with the SD interface. But it should comes handy with the ESP8266 (I hope!).
User avatar
Artcfox
Posts: 1382
Joined: Thu Jun 04, 2015 5:35 pm
Contact:

Re: New PCB rev on the horizon

Post by Artcfox »

uze6666 wrote:
Artcfox wrote:I know I'm late to this thread, especially since you've designed a new PCB already, but have you looked into using the SPI RAM the way that the Logic Pirate uses it? I'm not sure if you saw the post I made about it in another thread.

Doing it that way, for streaming reads from SPI RAM (after setting up the address), you should be able to read an entire byte from SPI RAM -> internal SRAM in just a few clocks. The only hurdle with this approach is I'm not sure that you have an entire PORT free on the ATmega644 to read the entire byte from SPI RAM at once. Though, if you can spare 4 pins from the same PORT, you could probably beat 18 clocks per byte just by using a single RAM chip in QSPI mode, where each clock pulse allows you to read 4 bits out at once.

The other, even crazier option that might be possible, would be to use a tri-state buffer to somehow hook all 8 lines from two QSPI RAM chips directly into the R2R DAC, so you can dump an entire byte of raw color data directly to the video chip on every clock pulse.
We definitely don't have a free port for 8 bits, not even 4 right now with the SPI RAM CS, ESP reset and prog pins. Besides, adding all those chips defeats the idea of the Uzebox being simple and two chips. I was never hot even for the SPI ram since I never saw much gain that we can't already do with the SD interface. But it should comes handy with the ESP8266 (I hope!).
Ah okay. Will both the ESP8266 and the SPI RAM be an optional add-on for the new PCB, similar to how the MIDI IN port is now? (Right now, I can't see myself wanting to add an ESP8266, nor SPI RAM if it's not going to be faster than reading from the SD card, nor would I want our already small ecosystem to become fragmented.)
User avatar
D3thAdd3r
Posts: 3221
Joined: Wed Apr 29, 2009 10:00 am
Location: Minneapolis, United States

Re: New PCB rev on the horizon

Post by D3thAdd3r »

uze6666 wrote:These are SNES and Genesis cable made to plug into the "JP-21" connector that comes with the upscaler.
Perhaps the video expansion header could be moved closer to the back side to better allow such possibilities? ;)
User avatar
Artcfox
Posts: 1382
Joined: Thu Jun 04, 2015 5:35 pm
Contact:

Re: New PCB rev on the horizon

Post by Artcfox »

My only other comment about the PCB concerns the audio out portion. I'm not familiar with the circuitry inside the television that accepts the audio signal, but would adding a simple RC low-pass filter before the audio out jack help suppress any harmonics, or is that already handled inside the television?
User avatar
uze6666
Site Admin
Posts: 4801
Joined: Tue Aug 12, 2008 9:13 pm
Location: Montreal, Canada
Contact:

Re: New PCB rev on the horizon

Post by uze6666 »

Perhaps the video expansion header could be moved closer to the back side to better allow such possibilities? ;)
Yeah some sort of port would be the best, but there's not much space as you know and I don't wan't to move stuff in that area otherwise I'll have to redo the routing.
My only other comment about the PCB concerns the audio out portion. I'm not familiar with the circuitry inside the television that accepts the audio signal, but would adding a simple RC low-pass filter before the audio out jack help suppress any harmonics, or is that already handled inside the television?
From my experience, the TV already does it. Initially there was a RC filter but it kinda muffle the sound and worst it created some slight artifacts in the video signal probably due to some ground plane thing that I could never resolve.
Post Reply