Testing various ATMegas in the Uzebox

Topics regarding the Uzebox hardware/AVCore/BaseBoard (i.e: PCB, resistors, connectors, part list, schematics, hardware issues, etc.) should go here.
User avatar
Jubatian
Posts: 1561
Joined: Thu Oct 01, 2015 9:44 pm
Location: Hungary
Contact:

Testing various ATMegas in the Uzebox

Post by Jubatian »

I just bought a couple of different ATMegas to test with the Uzebox. I was particularly curious about the 'A' variant, which is recommended instead of the original ATMega644 by Microchip.

So now I have the followings:
ATMega644-20PU
ATMega644A-PU
ATMega644P-20PU
ATMega644PA-PU
ATMega1284P-PU

I have an Uzebox V.1.3.1 board and an E-Uzebox to test them in. I use the Uzeburn burn-in tester to verify whether they work all right.

My results were that all ATMega644's I have work fine in both boards (including the ATMega644A and the ATMega644PA chips which seemingly weren't tried before in Uzeboxes), the burn-in tester reports them being stable, they have stable picture, and ordinary gameplay works fine.

I used the SPI RAM Mode74 demo's image to verify how stable their picture actually is, which is probably the most intensive use of the hardware (as it streams from the SPI RAM requiring driving the SPI correctly, too). I took a look at this on the V.1.3.1 board. All the four chips appeared to produce identical result, image is completely stable.

The ATMega1284P was tried out by uploading the .hex of Uzeburn on it (fused to run without bootloader). On the E-Uzebox it appeared functional, no problems indicated by Uzeburn, however it kept resetting on the V.1.3.1 board without any specific error indication. It might be that the V.1.3.1 board lacks a pull-up on reset, and this chip has a weaker internal pull than the others (so it might not necessarily be an incapability of running overclocked).

Later I will also receive an ATMega1284 (I also have a plan for an own console design using two of these chips, so it might not be entirely useless even if it turns out to be incapable to run overclocked).

Anyway, the most notable point is that the ATMega644A and the ATMega644PA might also be just fine for a Uzebox.

(For now I swithed both of the boards to one of these 'A' chips, will see how they operate in the longer run)
User avatar
ry755
Posts: 226
Joined: Mon May 22, 2017 6:01 am

Re: Testing various ATMegas in the Uzebox

Post by ry755 »

Jubatian wrote: Fri Feb 09, 2018 6:33 pm I was particularly curious about the 'A' variant, which is recommended instead of the original ATMega644 by Microchip.
I did a little research and it looks like it's mostly the same just with a different fab process, and has lower power requirements.
See clawson's answer here: http://www.avrfreaks.net/comment/735028#comment-735028

I have a 1284P-PU that I can test later. But the 1284/1284P has been tested in the past, and even when increasing the voltage, not all of them are ok running at 28 MHz.
Jubatian wrote: Fri Feb 09, 2018 6:33 pm (I also have a plan for an own console design using two of these chips, so it might not be entirely useless even if it turns out to be incapable to run overclocked).
Sounds interesting! I'm curious to see what your console will be like.
User avatar
Jubatian
Posts: 1561
Joined: Thu Oct 01, 2015 9:44 pm
Location: Hungary
Contact:

Re: Testing various ATMegas in the Uzebox

Post by Jubatian »

ry755 wrote: Sat Feb 10, 2018 2:16 amI did a little research and it looks like it's mostly the same just with a different fab process, and has lower power requirements.
See clawson's answer here: http://www.avrfreaks.net/comment/735028#comment-735028
I knew about that, but since we use it out of specification, it wasn't necessarily trivial that it would work. It could still be weaker or even more stable in a Uzebox in overall for many chips tested.
ry755 wrote: Sat Feb 10, 2018 2:16 amI have a 1284P-PU that I can test later. But the 1284/1284P has been tested in the past, and even when increasing the voltage, not all of them are ok running at 28 MHz.
I was curious about whether it would work and how it would fail.

It might not be overclocking, rather things which could be remedied.

Often I saw here that problematic chips exhibit unstable display while apparently running code properly (such as Larry's Uzebox JAMMA last time). It may be simply that the chip can't drive the high frequency oscillator. You could add some crystal oscillator driver chip to bypass this and feed the ATMega with the result to get things nice and stable. The XMegas are easy to overclock as they have a PLL, so with them you can keep using an oscillator which they can drive just fine, but the Megas don't have it. I would be curious how well ATMega's work if this issue was ruled out, maybe they wouldn't even need the ovevoltage (Uzeburn could pinpoint issues then).

Maybe this knowledge could also help people building an SMD Uzebox to have it performing better, if they knew that adding a cheap (about $1) 6 pin crystal driver they could get any ATMega doing it fine.
User avatar
ry755
Posts: 226
Joined: Mon May 22, 2017 6:01 am

Re: Testing various ATMegas in the Uzebox

Post by ry755 »

I tired using the 1284P, and like I expected, it didn't work.

First I tried running Uzeburner with the hex file from the forum post, and that didn't work. When I changed the MCU flag in the makefile to "atmega1284p", it gave me this error when trying to compile it:

Code: Select all

mkdir ./_xmb_o_
avr-gcc -mmcu=atmega1284p -Wall -gdwarf-2 -std=gnu99 -Os -fsigned-char -ffunction-sections -fno-toplevel-reorder -fno-tree-switch-conversion -DXMB_COMP_SECTION=.high -x assembler-with-cpp -Wa,-gdwarf2 -c xmburner/xmburner/xmb_jump.s -o _xmb_o_/xmb_jump.o
avr-gcc -mmcu=atmega1284p -Wall -gdwarf-2 -std=gnu99 -Os -fsigned-char -ffunction-sections -fno-toplevel-reorder -fno-tree-switch-conversion -DXMB_COMP_SECTION=.high -x assembler-with-cpp -Wa,-gdwarf2 -c xmburner/xmburner/xmb_glob.s -o _xmb_o_/xmb_glob.o
avr-gcc -mmcu=atmega1284p -Wall -gdwarf-2 -std=gnu99 -Os -fsigned-char -ffunction-sections -fno-toplevel-reorder -fno-tree-switch-conversion -DXMB_COMP_SECTION=.high -x assembler-with-cpp -Wa,-gdwarf2 -c xmburner/xmburner/xmb_main.s -o _xmb_o_/xmb_main.o
avr-gcc -mmcu=atmega1284p -Wall -gdwarf-2 -std=gnu99 -Os -fsigned-char -ffunction-sections -fno-toplevel-reorder -fno-tree-switch-conversion -DXMB_COMP_SECTION=.high -x assembler-with-cpp -Wa,-gdwarf2 -c xmburner/xmburner/xmb_creg.s -o _xmb_o_/xmb_creg.o
avr-gcc -mmcu=atmega1284p -Wall -gdwarf-2 -std=gnu99 -Os -fsigned-char -ffunction-sections -fno-toplevel-reorder -fno-tree-switch-conversion -DXMB_COMP_SECTION=.high -x assembler-with-cpp -Wa,-gdwarf2 -c xmburner/xmburner/xmb_cond.s -o _xmb_o_/xmb_cond.o
avr-gcc -mmcu=atmega1284p -Wall -gdwarf-2 -std=gnu99 -Os -fsigned-char -ffunction-sections -fno-toplevel-reorder -fno-tree-switch-conversion -DXMB_COMP_SECTION=.high -x assembler-with-cpp -Wa,-gdwarf2 -c xmburner/xmburner/xmb_crc.s -o _xmb_o_/xmb_crc.o
xmburner/xmburner/xmb_crc.s: Assembler messages:
xmburner/xmburner/xmb_crc.s:102: Error: number must be positive and less than 64
xmburner/xmburner/xmb_crc.s:135: Error: number must be positive and less than 64
xmburner/xmburner/xmb_crc.s:216: Error: number must be positive and less than 64
xmburner/xmburner/xmb_crc.s:406: Error: number must be positive and less than 64
xmburner/xmburner/xmb_crc.s:420: Error: number must be positive and less than 64
xmburner/xmburner/xmb_crc.s:470: Error: number must be positive and less than 64
make: *** [_xmb_o_/xmb_crc.o] Error 1
Using "MCU = atmega1284" (without the P at the end) gives the same error.

I tried compiling some of the demos with MCU set as atmega1284p, and while they did compile properly, my projector always said No Signal after flashing the demo. Most of the time the green status LED on the Uzebox wouldn't even light up! If I kept pressing reset, it would eventually light up (sometimes very dim, sometimes bright like normal), however it still wouldn't show anything on the screen.

I also tried different fuse settings, changing the clock settings, boot reset vector, and brown-out detection levels.
I haven't tried increasing the voltage as I don't have a variable power supply.

I think you're right, it's probably having a hard time driving the crystal. Would a driver chip like this work? https://www.digikey.com/product-detail/ ... -ND/722180
User avatar
Jubatian
Posts: 1561
Joined: Thu Oct 01, 2015 9:44 pm
Location: Hungary
Contact:

Re: Testing various ATMegas in the Uzebox

Post by Jubatian »

ry755 wrote: Sun Feb 11, 2018 5:11 am I think you're right, it's probably having a hard time driving the crystal. Would a driver chip like this work? https://www.digikey.com/product-detail/ ... -ND/722180
Yes, I meant one of those (or anything similar you can get)!

Did you remove the bootloader fuse by the way? I programmed mine with the following settings: Extended: 0xFF, High: 0xD3, Low: 0xD7 (note the difference to Uzebox on the High fuse bits, it is 0xD3 instead of 0xD2, so Bit 0 is set, making the CPU boot at address 0).

You wouldn't have to recompile UzeBurn, but I will look at it. The XMBurner library should be capable to compile for the 1284, and you are getting errors in it, so I will have to fix that.
User avatar
ry755
Posts: 226
Joined: Mon May 22, 2017 6:01 am

Re: Testing various ATMegas in the Uzebox

Post by ry755 »

Jubatian wrote: Sun Feb 11, 2018 7:07 am Did you remove the bootloader fuse by the way? I programmed mine with the following settings: Extended: 0xFF, High: 0xD3, Low: 0xD7 (note the difference to Uzebox on the High fuse bits, it is 0xD3 instead of 0xD2, so Bit 0 is set, making the CPU boot at address 0).

You wouldn't have to recompile UzeBurn, but I will look at it. The XMBurner library should be capable to compile for the 1284, and you are getting errors in it, so I will have to fix that.
Yes, I removed the bootloader fuse, and I messed around with all of the different options.
So the 1284 is backwards compatible with 644 binaries? That's good because if we do eventually find a way to get the 1284 successfully overclocked, and people upgrade to it, backwards compatibility is a must-have.

I'll order that driver IC, and let you know if it works.
User avatar
Jubatian
Posts: 1561
Joined: Thu Oct 01, 2015 9:44 pm
Location: Hungary
Contact:

Re: Testing various ATMegas in the Uzebox

Post by Jubatian »

ry755 wrote: Sun Feb 11, 2018 10:32 amSo the 1284 is backwards compatible with 644 binaries? That's good because if we do eventually find a way to get the 1284 successfully overclocked, and people upgrade to it, backwards compatibility is a must-have.

I'll order that driver IC, and let you know if it works.
Yes, it mostly is, I doubt any game would show any problem if the 1284 itself did its job proper. It needs porting the bootloader (as the loader then would sit in the region 0x1F000 - 0x1FFFF which demands some changes, notably any use of lpm needs to be adjusted, and of course it should also permit flashing larger games).
User avatar
ry755
Posts: 226
Joined: Mon May 22, 2017 6:01 am

Re: Testing various ATMegas in the Uzebox

Post by ry755 »

I ordered a few of the driver ICs and they'll arrive in a few days.

What clock setting should I use for the 1284P? Should I use "Ext. Clock; Start-up time: 6 CK + 65 ms; [CKSEL=0000 SUT=10]"?
User avatar
D3thAdd3r
Posts: 3221
Joined: Wed Apr 29, 2009 10:00 am
Location: Minneapolis, United States

Re: Testing various ATMegas in the Uzebox

Post by D3thAdd3r »

Just wanted to chime in with some info. The 1284 has been investigated in depth by several people over the years, with mixed results across the board for glitches. Apparently some 1284 seem fine, sometimes, but are a rarity with the majority not working as a drop in replacement for the kit. The threads are scattered around, but the consensus basically is you can't just replace the '644 and expect it to be reliable (maybe if you luck out and get some "golden 1284").

I can't recall who researched it out the furthest, but someone successfully modified from the standard to moderately overvolt the 1284, and reported this was the only thing in his testing which brought it to be reliable. I will try to find that thread, but the downside there is that many resistors in the kit have to change then. Voltage dividers, video DAC, etc. I am rolling with that idea on my end for KUzebox 1284 and am convinced it is a reliable solution, just a question of what the minimum voltage is to make all of them work. Maybe 5.5V. Even some 644 apparently have issues overclocking at 5v, but I probably have 20 various 644, 644ps, etc. floating around and never saw it firsthand.
User avatar
ry755
Posts: 226
Joined: Mon May 22, 2017 6:01 am

Re: Testing various ATMegas in the Uzebox

Post by ry755 »

D3thAdd3r wrote: Tue Feb 13, 2018 10:13 pm Just wanted to chime in with some info. The 1284 has been investigated in depth by several people over the years, with mixed results across the board for glitches. Apparently some 1284 seem fine, sometimes, but are a rarity with the majority not working as a drop in replacement for the kit. The threads are scattered around, but the consensus basically is you can't just replace the '644 and expect it to be reliable (maybe if you luck out and get some "golden 1284").

I can't recall who researched it out the furthest, but someone successfully modified from the standard to moderately overvolt the 1284, and reported this was the only thing in his testing which brought it to be reliable. I will try to find that thread, but the downside there is that many resistors in the kit have to change then. Voltage dividers, video DAC, etc. I am rolling with that idea on my end for KUzebox 1284 and am convinced it is a reliable solution, just a question of what the minimum voltage is to make all of them work. Maybe 5.5V. Even some 644 apparently have issues overclocking at 5v, but I probably have 20 various 644, 644ps, etc. floating around and never saw it firsthand.
Do you think it could be unstable because it just can't drive the higher frequency crystal? Jubatian suggested trying a crystal driver IC.

As an experiment, I tried connecting the crystal to a 644 and enabling the CKOUT fuse. This gives a clock output on PORTB1. Then I connected the 644's PORTB1 to the 1284P's XTAL1. I'm no expert when it comes to this type of thing, but this should mean the 644 is acting as a separate crystal driver, bypassing any issues the 1284 might have with driving higher frequency crystals. While the 1284 was getting a clock pulse and the green status LED came on, still nothing came up on the screen.
Post Reply