Uzebox Forums

For the fuses I think the followings should be set for a safe start on the 1284 driven by external clock (or a 644 if you decided to use a crystal oscillator driver):

Low: 0xE0
High: 0x99 (or 0x98 if you want to use a bootloader on a 644)
Ext: 0xFC

The crystal oscillator driver of course is just an idea I think worth to try, I originally suggested it for the 644 as I saw here symptoms which suggest that there is a problem related to the capability of driving the oscillator proper. Routing through a proven working 644 might work, but I wouldn't rely on such result (the 644 may still not be able to drive it all right, just enough for itself to work and the monitor to sync, and the output may slightly wobble around in frequency).

In my setup, the ATMega1284p worked in the E-Uzebox, and did occasional resets in the V.1.3.1 Uzebox while on neither did Uzeburn detect anything. When I was overclocking the XMega, it detected occasional faults long before the whole thing went south. So it seems like whatever prevents the 1284 running at this increased clock frequency is not its ALU.

Anyway, this is rather just a curiosity. I am more focused on doing something with the 1284 within its specs

(Meanwhile I fixed the bug in Uzeburn preventing it compiling for an ATMega1284)

It sounds interesting. I don't remember anyone talking about experimenting with the oscillator, so perhaps it could lead to a modless 1284 drop in which would be quite nice.

@Jubatian, did you already add support in CUzeBox for the 1284?

D3thAdd3r wrote: ↑Thu Feb 15, 2018 1:45 am@Jubatian, did you already add support in CUzeBox for the 1284?

No, I didn't, although it shouldn't be too difficult if you were OK with a 1284 fork (adding it as being selectable or auto-detecting would be more difficult).

I would be fine with a fork. I can implement something unless you want to, but I am only aware of the ram needing to be increased and the LPM and SPM need to be added for the extended area. Then you mentioned there is some bootloader specific change that would be required, so I think there is a detail I don't grasp yet on that. There is no change for ld,lds, etc right?

The crystal driver ICs came and I soldered one to a breadboard adapter. Unfortunately, the 1284 still wouldn't work. I tried the driver with a 644, and it worked so I know the IC was working correctly.
Then I tried overvolting it with a trick mentioned here: viewtopic.php?f=4&t=651&hilit=1284P&start=10#p5993
While the status LED did come on almost every time, nothing came up on the screen.

I tried almost every combination of clock fuse setting.
I also tried overvolting and using the crystal without the separate driver.

I guess my 1284 isn't one of the few that are overclockable.

ry755 wrote: ↑Sat Feb 17, 2018 8:43 amI guess my 1284 isn't one of the few that are overclockable.

Anyway, if you have that crystal driver, you might try some 644's with it if you had any you tossed away due to not running too well in the Uzebox. For example Larry here has a suspect whose problem could well be that the ATMega can't drive the crystal properly (see third picture, it apparently runs, but the display can't sync to it, likely because the frequency isn't stable, a different ATMega644 runs properly in that JAMMA board).

It could also be nice to know, for example for designs like CunningFellow's DTV (which uses SMD parts) which could afford one, maybe helping them getting a bit more robust.

Well, I only have 2 Atmega644s, and they both work fine when overclocked. But I'll still keep the driver in my parts collection since it could be useful for something else.

That is disappointing it didn't work, as I imagined most would work with extra voltage. What voltage did you end up using? For my purposes even 75% not working doesn't matter since only 5 will be made, but then it could be batch related where none in a batch worked(or no batches in the future will!?). I would be curious to see what happens on a variable power supply and push until something gives: either correct operation or smoke

The following is just my two cents as i continue to watch this thread:

I like the idea of a drop-in replacement for the ATMEGA644. However, isn't it important to have a stable and repeatable product?

The goal is to just replace the ATMEGA644 DIP, right? What if it could be an entire circuit board (mini of course) that is made to have a compatible pin-out? That seems like a better idea. This 1284 idea has been up and down for years and always with the same result: inconsistent or not working well.

D3thAdd3r wrote: ↑Tue Feb 20, 2018 3:36 am That is disappointing it didn't work, as I imagined most would work with extra voltage. What voltage did you end up using? For my purposes even 75% not working doesn't matter since only 5 will be made, but then it could be batch related where none in a batch worked(or no batches in the future will!?). I would be curious to see what happens on a variable power supply and push until something gives: either correct operation or smoke

It was about 5.6 volts. But since the 1284 seems to be more sensitive, maybe it wasn't working because I was testing it on a breadboard with messy wires. I ordered the official kit from Adafruit, and it should arrive on Wednesday (the 21st). Once that comes I'll try the 1284 in that.

nicksen782 wrote: ↑Tue Feb 20, 2018 5:10 am The goal is to just replace the ATMEGA644 DIP, right? What if it could be an entire circuit board (mini of course) that is made to have a compatible pin-out? That seems like a better idea. This 1284 idea has been up and down for years and always with the same result: inconsistent or not working well.

Since it would have to be overvolted, it would also need a new DAC. There could be a mini PCB that plugs into the ATmega socket, but also includes a DAC with the altered resistor values. It could then plug into the AV header, which bypasses the kit's built-in DAC.

This would make it so a Uzebox is able to be switched between the 644 and 1284 without needing to replace the resistors.