current state of AVCore and Baseboard

[funkaster]

Hi all,
I'm going to be ordering (actually, I convinced my girlfriend to buy it as my xmas gift ) the AVCore + Baseboard kit from Clay during this week...
So a few questions to know the current state of the uzebox:

- I've read that there's still no official support for FAT16/32, but the interface is there, right?
- Any work on a portable uzebox? maybe with some sort of Nokia-compatile LCD? (that's both cheap and easy to interface [1], although the resolution is somewhat limited: 128x128)
- How about an extra ram chip, or some extra EPROM to store the kernel? I know the idea is to keep the design at the lowest possible chip count, but maybe storing the kernel in external EPROM, or some extra RAM chip would not be that bad idea...

I'm getting really excited about this
I'll start coding as soon as I get my hands on the kit!

[1] http://www.idleloop.com/robotics/ColorLCD/

[uze6666]

Hey, glad you like project!

- I've read that there's still no official support for FAT16/32, but the interface is there, right?

Not yet, but it's getting close. We internally agreed to make it FAT16 (at least to start). We have two guys tinkering about that right now.

- Any work on a portable uzebox? maybe with some sort of Nokia-compatile LCD? (that's both cheap and easy to interface [1], although the resolution is somewhat limited: 128x128)

I'm glad to annouce that yes, there's at least one version out there...Check this out!

- How about an extra ram chip, or some extra EPROM to store the kernel? I know the idea is to keep the design at the lowest possible chip count, but maybe storing the kernel in external EPROM, or some extra RAM chip would not be that bad idea...

Although it would be a nice expansion option, you can't externalize code on the AVRs. Program must run from within the integrated flash. Now data could be externalized on some serial EEPROM or SRAM but as you mentionned that would increase cost and a bit complexity. In the end, we have decided to go with a SD card interface that will provide humongous amounts of storage at --almost-- no cost!

Cheers,

Uze

[havok1919]

- Any work on a portable uzebox? maybe with some sort of Nokia-compatile LCD? (that's both cheap and easy to interface [1], although the resolution is somewhat limited: 128x128)

Kinda related-- I will soon have a large number of 480x272 TFT LCD's (WQVGA). That's a fair bit more pixels to deal with, but if they can be hacked to work I can price them "competitively". (They're parallel interface, but if anyone wants to drive one from a microcontroller or USB LMK 'cause I have a little solution that makes those work as well...)

How about an extra ram chip, or some extra EPROM to store the kernel? I know the idea is to keep the design at the lowest possible chip count, but maybe storing the kernel in external EPROM, or some extra RAM chip would not be that bad idea...

Like Uze said, code execution is a no-go there and for extra storage it's just impossible to beat SD now. (For another project just recently I was quoting 16Mbit (2Mbyte) serial page based SPI flash. In >1M annual unit volume they were still ~$0.50-0.65 USD. Compare that to a 1-2GByte SD card for $3-5 from time to time...

-Clay

[ravyne]

You know... just an utterly crazy thought perhaps, but maybe it might be worthwhile to have a very barebones kernal -- stuff that absolutely must be resident, and pair that with say a small Forth kernal for more ancillary tasks and system utilities -- presuming there are any, and presuming they are large enough en mass that the forth kernal might be smaller than just having them resident. OpenBIOS, (or maybe it was EFI?) uses Forth for similar things, as well as low-level hardware drivers -- of course, they've got gobs of RAM to spare too, and we don't have that luxury, especially with game code running -- but it might be viable for the SD loader, an eeprom management application or similar things.