Smart Response XE Re-purposed into Arduboy

(Josh Goebel) #243

It would be nice if someone compiled Hopper with the render code I posted earlier and then gave us some benchmarks (millis of render time, or even just CPU usage). Before everyone gets excited it’d be nice to have some baseline of what we might expect on this hardware. Again, we lose 17x as much time on SPI here as we do on Arduboy just because of the huge amount of data we have to send to the screen.

Math off the top of my head:


  • 16 million cycles per second
  • 384x136 resolution
  • 2.666 bits per pixel
  • 2 cycles per bit transmitted (at CLK/2)

That gives me 57.44 frames per second using 100% CPU just for SPI (or waiting on SPI). So the real question is how much CPU most Arduboy games use (or whatever you’re wanting to write for the XE). If you use 50% to render your graphics and do calculations that limits you to 30 FPS on XE, etc.

All this if assuming full-screen render/paint.

(Josh Goebel) #244

Depending on the type of game/app we’re getting to the point where it might start making sense to do some type of dirty rectangles and then skip rendering parts of the screen that haven’t changed. That wouldn’t really be helpful for super dynamic games like Hopper though that are essentially changing the entire screen every paint.

I’ve also been assuming we’re clocked at 16Mhz, but I don’t think we know that for sure… could anyone confirm that?


Might be better to investigate the practical refresh rate of the LCD before you worry too much about what frame rate the microcontroller can achieve? With ghosting, 60FPS isn’t all it’s cracked up to be! :smile:

(Josh Goebel) #246

AH true. We take so much for granted on the tiny, amazing little Arduboy.


I hadn’t noticed until you mentioned it. Probably will use DEL as enter because of it’s position. Maybe SYM / SHIFT + DEL to delete or SHIFT + 0 like the ZX Spectrum :smiley:

Not necessarily 17x slower. By using a 256 x 128 display window. It could be ~11x slower

The CPU could push out 81,37 fps 256x128 pixels x 2,667 bpp x 2,25 cycles per bit (18 cycles per SPI transfer @ CLK/2) at 100% CPU time

Since the LCD has a slow refresh rate we could interlace the display by using the set row address. Interlacing could be set to 2x, 3x or maybe even 4x

(Larry Bank) #248

Interlacing is normally something you do when you have a fast refresh display and your data can’t keep up with it; in this case, it will make it look even worse. The solution is probably to design games which don’t have tons of pixels changing each frame.


I don’t fully agree with that. it’s more a bandwidth issue.

effectively reducing the frame rate (for those pixels)

I don’t think so for high frame rates. By interlacing the already drawn pixels on LCD display will be exposed twice as long as if they where drawn progressively and become more visible.

Expanding 128x64 to 256x128 interlaced would be easy:

  • even frames: draw display buffer on 64 even LCD rows
  • odd frames: draw display buffer on 64 odd LCD rows

When I’m ready to play with my Smart Response XE I’ll have a go at this.

(Josh Goebel) #250

I don’t think interlacing is the answer, but that is one thing I didn’t think about at all. :slight_smile: I think if the LCD has a slow refresh rate that would just look weird though, but very curious if someone actually tries is.

My fear is that most people didn’t optimized their Arduboy games and I bet there are a lot of Arduboy games really pushing the CPU limits… so as soon as you take away all that extra CPU time you’re going to start hurting bad… but very curious to see how all this plays out.

Do people really want to use these are “large Arduboys” just to play games on them?


Do people really want to use these are “large Arduboys” just to play games on them?

I just wanted to make it do “something else” that it’s not supposed to :smile:
Pretty much the same thing with other device’s I’ve messed with in the past…


I think it’s a nice way of getting acquainted with them. Because of the high resolution and keyboard. These devices would be great for text adventures. Zork anyone? :smiley:

(Josh Goebel) #253

I’m working on a Terminal and Readline library right now. Kind of foundation you’d build something like that easily on top of.

(Larry Bank) #254

I believe that this will create an ugly tearing effect. You can see this on youtube with some interlaced videos. The LCD seems to only refresh at 8-10FPS. Maybe create a game where display ghosting is a feature instead of a bug :slight_smile:

(Larry Bank) #255

okay, I guess I’m a glutton for punishment. I saw an opportunity on ebay to snag another set of 36 of these things and I took it. I’ll be able to offer them at an even lower price if anyone still wants a few. They should arrive next week. If they’re all in good shape, I’ll offer them direct to you guys for $6 each (plus shipping) and offer them on ebay for a higher price to cover their fees.

(Simon) #256

36? You could build a large multi-player game and invite the neighbourhood around!

(Larry Bank) #257

A quick update on my wireless bootloader progress. I’ve got it nearly done! I did a lot of experimenting and concluded that sending avrdude commands over wireless was an exercise in frustration. I changed plans and now I wrote a STK500 state machine on my local XE device to capture the sketch into SPI flash memory, then forward it to the remote XE device using my own wireless protocol. It works 100% at capturing the sketch into SPI flash and mostly works at sending it forward. So close… will publish a detailed blog post with all the details when I have it working.

(Josh Goebel) #258

I wonder if AFTER you sort out the wireless details if both approaches would work just fine. From the specs I read the wireless hardware is pretty capable. Maybe it just doesn’t like really small packets? But I think once the transmission started you wouldn’t be sending tiny packets…

Caching it in memory then passing it on is probably a faster/better approach, but I just find it hard to believe the former would be so unreliable as to be unworkable.

(Larry Bank) #259

It’s hard to respond to your statement without sounding harsh, but you need to work on it yourself to understand the problems involved. It would be great if you worked on your idea in parallel and we could have two different solutions to the same problem. The wireless details don’t really need to be sorted out. The STK500 protocol is really poor at dealing with lost/corrupt data; it expects an error free channel and gets flustered when anything goes wrong.

(Josh Goebel) #260

I’m not saying it’s easy or trivial. I’d prolly have just as much frustration figuring it out from scratch… but it just seems hard to believe the hardware would be that flakey once you had it programmed “just right”, whatever the magic just right is. Or maybe there is a ton of wireless interference where you live? I’m not sure what spectrum these radios operate in. Saying any protocol is “really poor” at dealing with lost/corrupt data begs the question of why there is so much lost/corrupt data in the first place.

I guess it just seems like the error correction/auto-retry stuff should either work or not… and then it should be just a matter of speed.

I only have one XE (my friend has the other), so unless someone points to an easy way to do the wireless stuff with my computer itself as one end of the connection may not be playing with the wireless for a while.

(Larry Bank) #261

You misunderstand my response. There’s nothing wrong with the wireless, it behaves quite well actually. The problem lies in the STK500 protocol which avrdude speaks. It doesn’t work great over serial and works much worse when there are added delays and data loss. It’s especially bad during the initial back and forth sequence before the data is actually sent. I started absorbing more and more of the protocol startup into my state machine and finally got down to just sending the actual data packets over wireless. Even this was a disaster due to the way both ends expect the data to be sent and received. I collected up the bytes into logical message groups, I also tried sending them one at a time in their own packets. It didn’t matter the protocol (STK500, not 802.15.4) is so finicky that it would fail after a few successful exchanges.

(Josh Goebel) #262

Maybe we should chat. I guess I just don’t understand why one protocol would fail but another would work - in an absolute sense - not a “one is better than the other” sense. If the wireless network layer is reliable then STK500 over wireless should work. Maybe it’s a timeout issue? If the networking layer is reliable at the hardware layer then I don’t know why your “custom protocol” would transmit more reliably than a STK500 packet would be - it’s all just bits to the networking hardware.

I can easily believing caching it all and sending it in a batch special format would be OPTIMAL… but it just seems strange that the other way wouldn’t work at all.