ATmega32u4 vs. Intel 80286

Even better, (got in on the Arduboy party like few days ago so haven’t learned all the details yet) well the higher end 286 ran at 8Mhz, that means double power in your wallet, not taking a whole desk in your room, lol. Anyway i’ve been also thinking about combining the Arduino lang./C with the Atmel AVR Assembler. I know of older PC titles that did this (combining main language with a corresponding ASM) to speed up the code, make it more efficient (namely id-s Doom). It’s just an idea for now however.

Adding also the fact that NES was like assembly language only (the good old 6502) although i’m not sure how this ties in with the subject at hand now.

Yeah, I’ve been wondering if it would be worth trying to improve performance with assembly. I know the Arduino’s compiler is supposed to be quite efficient, but there are always little hacks to be found.

NES games can actually be programmed in C these days, though as expected it’s pretty inefficient and mostly useful for prototyping, or very simple games that don’t need to be concerned with optimization.

Yes. Optimization was the word I was looking for. I’m pretty sure performance can be improved in certain situations even on Arduino (must look further into that). Currently i’m working through several of Michael Abrash’s writings on these subjects and this guy knows is assemblys and can make you think completely outside the box, in fact you can’t even see the box from where he’s coming from haha.

It can run at 16MHz, however I’m pretty sure it will be set at 8MHz by default. 16MHz requires a higher voltage which I don’t think the battery can push. You may be able to overclock it to higher than 8MHz without a voltage increase at the expense of battery life and possibly stability.

1 Like

My thoughts exactly. Motorola MC68A09 used in the old GCE Vectrex system ran @ 1.5 MHz for example and there’s some cool games on it (read: Berzerk).

I also think there will be plenty of room for optimization. Unlike a modern computer, where accessing the hardware directly is not really feasible. It is more than possible here and some interesting optimizations can definitely be made with direct access to the hardware. And if someone can get the screen to use 1bit per pixel that would save a huge amount in RAM.

1 Like

“And if someone can get the screen to use 1bit per pixel that would save a huge amount in RAM”

I don’t get this statement. The screen is 128x64 pixel that is 8192 pixels that are represented by exactly 1KB. That is what the example game does.

(In fact, the OLED display has its own driver and own memory. What the game does is setup of driver at the beginning and then copying array from SRAM to OLED’s RAM again and again. So if you want save some of leonardo’s ram, just write directly to OLED.

And one note on hand assembly - the ATMEL chip has 32 registers and orthogonal instruction set. That really fits well for C compiler, so don’t expect that your hand assembled code would be significantly faster or smaller. Yes, the Arduboy hw is fixed, you can do some shortcomings that general C lib can’t do because it have to run everywhere but I wonder it is worth of time.

1 Like

My bad, I should have done the calculations of the resolution haha.

We are at 16mhz!! Dev kit is overlocked when using the coin cell (3.0-2.4 volts) but the final version uses a lipo battery so it’s maybe still slightly overlocked at 4.7.

If you guys get some assembly code running on this bad boy you will seriously be my heroes. I’m not elite enough in the ways of coding to get that done! Will have to come up with some rewards for badass community members :wink:

And I can’t really believe you are comparing this to a 286 but hey, why not lol :slight_smile:

1 Like

[quote=“bateske, post:12, topic:84”]
We are at 16mhz!! Dev kit is overlocked when using the coin cell (3.0-2.4 volts) but the final version uses a lipo battery so it’s maybe still slightly overlocked at 4.7.[/quote]

Are you sure you don’t mean 3.7, not 4.7? Every single cell lithium-polymer battery I’ve seen has a nominal output voltage of 3.7V.

If it actually is 3.7V then I wouldn’t overclock it at 16Mhz. You’re just asking for trouble when some users get chips that aren’t very tolerant of overclocking and start complaining about the unit crashing or being flakey. Overclocking is fine for a user to experiment with at their own risk, but not for the design of a standard high volume product. Please stay within the recommendations in the datasheet.

On the other hand, if you actually did mean 4.7V then I hope you’ve included level shifting for the signals going from the CPU to the display (MOSI, CLK, CS, DC, RST). These signals are specified as 3.3V and even driving them at 3.7V is getting close to being above the comfort zone. The voltage from a fully charged 3.7V battery may even be too high.

And what do you do when powering from USB? Do you regulate the overall voltage down to something safe for the display, or do you have level shifters on the signals to the display?

What do we even mean here by overclocked? The Atmega32u4 chip is rated for up to 16Mhz.

16MHz is meant for when the chip is running at 4.7V. 8MHz is for 2.7V. It’s possible to get 16MHz but it may result in some instability and even crashes. At 1.7V it is set to 2MHz. Potentially usable if we are looking for a longer-lasting battery and applications that are not so demanding.

Also a suggestion to devs, if it is possible, allow us to set custom clock speeds on the fly with relative ease. If we are sitting in a menu it isn’t likely that we would be using a full 8MHz and could clock down. And with testing, at certain stages of the game we may find low CPU usage, so we can change it for those specific points. Just thinking about ways of maximising battery life that’s all.

It’s only rated 16Mhz at Vcc voltages above 5V. Below 5V the maximum clock speed must be derated. See section 29.5 Maximum speed vs. Vcc in the datasheet.

I’m not sure how easy that is to do with an external clock crystal (or even internal). I think I read you have to adjust the fuses to change the clock settings? I could be mistaken though.

16MHz is meant for when the chip is running at 4.7V. 8MHz is for 2.7V.

Ah, that makes sense. Thanks for clarifying.

I got this information from a book and a google search, so I have not tested this. There is a Prescaler.h library for arduino which easily allows you to switch clock speeds from 16MHz, 8MHz, 4MHz, 2Mhz, 1Mhz, 500Khz 250khz, 125khz, 62.5khz with one function call.

“The AVR USB has a system clock prescaler, and the system clock can be divided by setting the “CLKPR – Clock Prescaler Register” on page 37. This feature can be used to decrease the system clock frequency and the power consumption when the requirement for processing power is low. This can be used with all clock source options, and it will affect the clock frequency of the CPU and all synchronous peripherals. clkI/O, clkADC, clkCPU, and clkFLASH are divided by a factor as shown in Table 6-10 on page 37.”

So actually I think that’s a yes. You can divide the clock 1, 2, 4, 8, 16,32, 64, 128, or 256. I’d think the OLED screen uses a lot more power than the CPU though… so I’m not sure it would help significantly to slow the CPU down…

The OLED brightness can be changed, I’m working on trying to do it myself. It requires more than just the function call and brightness data.

8-12MHz might be more reasonable (for 3.7V) based on the docs. Might require a different external oscillator chip though. Of course after boot we can always slow it down to 8MHz ourselves, provided we can get thru the boot sequence.

I think it would be best to be as compatible to a real Arduino as possible, because people may wish to make use of standard available libraries developed for Arduino boards. Some of these libraries may have timing dependencies that assume standard Arduino clock speeds.

All official ATmega32U4 based Arduino’s that I know of run at either 16Mhz or 8Mhz. So, to avoid overclocking, the Arduboy should probably be run at 8Mhz, not something higher like 12Mhz.

If they are written properly they should still work. Arduino can run at tons of different speeds (from very fast to VERY slow) and the core source code sets all sorts of constants to make sure you can write code at any of those speeds. It’s possible some libraries aren’t written well though and this might be a practical problem even when it shouldn’t really be.