Uzebox AVCore+Baseboard Kit Selling Now!

[rolando]

same question as DavidEtherton... is the kit still available? what do we need to program this? and if it's still available, how much is the international shipping?

Rolando./

[havok1919]

What magic USB dongle do I need to program this? It's priced similarly to the adafruit fuzebox except that I don't have to assemble it myself (and spend another $50-100 on a decent soldering / multimeter setup)? Are extra SNES controllers available for dual-player-megatris goodness? (This thread is fairly old, is it still available for this price?)

Yep, mine are pre-assembled/tested. So that's either a plus or a minus depending on your point of view.

My preference for a programmer is the AVR ISP MkII. Digikey has them (as well as other places I'm sure). Digikey part number: ATAVRISP2-ND It's $34, but works with pretty much every AVR out there and is seamlessly integrated into AVR Studio. You also get some free samples of whatever AVR processors you want from Digikey (they email you after you buy the programmer).

Pricing is still good on the AVCore/baseboard bundle. My only restriction is that once SparkFun puts them up for sale I have to match their pricing. They'll probably have it up this week, so if you'd like one let me know and I can set it aside for you and mark it 'sold' at the current (lower) price.

-Clay

[DavidEtherton]

Is there code to exercise the memory card anywhere? Any chance that the same mmc code will run on both your board and fuzebox?

Does SPM (store to program memory) work on the ATmega644? That seems to allow the device to "reprogram" itself.

I'd love to do a raw sector dump to an mmc, where the first 64k is a menu app that can spawn to any other 64k apps later in the raw image. Is the bootloader somehow separate? Can we replace the stock bootloader with one that pulls in the menu app off MMC? Is that dangerous at all, or can you reset everything back to a known state if you screw things up?

-Dave

[ladyada]

i have sd example code that works just fine on the fuzebox (tested it using a FAT16 card). i dont have any microsd cards but i assume it would work since there's kinda only one way to connect an SD card to an avr, with the hardware spi

[havok1919]

Is there code to exercise the memory card anywhere? Any chance that the same mmc code will run on both your board and fuzebox?

Does SPM (store to program memory) work on the ATmega644? That seems to allow the device to "reprogram" itself.

I'd love to do a raw sector dump to an mmc, where the first 64k is a menu app that can spawn to any other 64k apps later in the raw image. Is the bootloader somehow separate? Can we replace the stock bootloader with one that pulls in the menu app off MMC? Is that dangerous at all, or can you reset everything back to a known state if you screw things up?

So yeah... This is a long topic we've been beating on for a while. Search the forums and you'll see we've started down this path with some debate (I can't remember the thread name though!).

In a nutshell: the goal is to have standard bootloader that pulls up a menu of games and will use SPM to reprogram the device. Alec already wrote a nice, compact little menu app that doesn't take much space (since we don't want to have to make the bootloader too big).

My preference is to have the card remain PC/Mac/Whatever compatible. AKA, plug the card into a PC, drag and drop a file to it, pop it back into an Uzebox and you're up and running. The problem there is that you really want Microsoft FAT-16 support to do that and that starts to get a little piggy on the ROM space. (Although we've not actually *tried* it yet with a limited read-only implementation of FAT-16 or something.)

An alternative is to do about what you said-- just make a custom filesystem that uses the sea of sectors on the card. The downside there is that you can't just plug it in to a PC and expect it to work without a 'helper' app. That's when I start getting nervous. My fear is that in order to do direct sector writes to the card, you're going to open up the opportunity to do direct sector writes to *anything* attached to the machine. (Especially if they have to specify a LUN or something to address the drive!) A 2G USB thumb drive looks an awful lot like a 2G SD card, so I fear someone will smoke the wrong disk at some point. Some of that might be mitigable with warning dialogs, etc. but I develop muscle memory in OK'ing common dialog boxes after a few tries, so I fear someone will still get bit by data loss at some point.

I haven't tried to skinny-down any of the freeware/opensource FAT16 stuff to see how small we could make a read-only filesystem to fit in a bootloader. I use a commercial library for SD stuff on my other projects and with read/write access and some demo code (and a full suite of C-like fopen, fseek, fclose, fread, fwrite, printfs, etc.) it's about 5K.

After talking to Alec we had sort-of decided to just declare "the boot block shall be 4k". If we can't do FAT16 in that space, then we *have* to do something else. In the meantime, everyone has been warned to keep their binaries under 60K (61440 bytes) to be sure they will work when loaded from the 4K bootloader.

-Clay

[uze6666]

Is there code to exercise the memory card anywhere? Any chance that the same mmc code will run on both your board and fuzebox?

I have done some rough test code, basically a proof of concept. I used some open source code to read raw sectors and that was working quite well (check for a post on the forums). The same code should works for MMC, SD or MicroSD. It's all the same SPI protocol.

Does SPM (store to program memory) work on the ATmega644? That seems to allow the device to "reprogram" itself.

Sure. That's essential to boot loaders as they are responsible to reprogram the chip.

I'd love to do a raw sector dump to an mmc, where the first 64k is a menu app that can spawn to any other 64k apps later in the raw image. Is the bootloader somehow separate? Can we replace the stock bootloader with one that pulls in the menu app off MMC? Is that dangerous at all, or can you reset everything back to a known state if you screw things up?

I agree its the easiest way, and I even proposed just that quite a few times. However theres a real risk when developing or using raw sector writers you accidentally overwrite some sectors on the wrong disk...like your C: drive! So the idea was put on the ice.

Uze

EDIT: Crap. Clay beat me again on that post.

[uze6666]

Reading Clay's last post I've tough of one more option. Prepare a SD card for the Uzebox -- on the Uzebox. A simple rom that would format the card clean to be unrecognizable by windows but with some magic numbers or header that a custom tool would recognize easily.

Note that I would really like to see some real FAT code included in the standard libraries. That would be just awesome for a lot of applications. Just think about a patch, music or tiles making tool straight on the Uzebox. Create then save your work on the SD, then import easily on your PC. Dataloggers, screen captures are just other examples...

Uze

[DavidEtherton]

I just ordered a kit from Clay. I'll be happy to slap together a really simple FAT16 reader once I track down the raw sector read routines. I've done my share of software-level device hacking over the years (linux device drivers etc back in the 90's when it was still cool).

Is the sector size fixed or variable on an MMC? One problem of course is that we only have 4K of RAM...

I assume it would be sufficient to only support the root directory? FAT16 is a lot easier than FAT12, a lot less bit twiddling

(I'm going away on business for a week starting this Saturday though, sigh)

-Dave

[havok1919]

Is the sector size fixed or variable on an MMC? One problem of course is that we only have 4K of RAM...

Yep-- 512 bytes per sector. The cards handle all wear leveling (at least they're supposed to-- depends on how crappy the controller chip is! ) so you just point it at a sector and go. For the time being I'm sure we're OK with just standard SD cards. SDHC cards use the same scheme, but the 'sector' address is actually a 'block' address (to sneak by the 2G limit). <2G cards still seem readily available and cheap, so I think that's safe for the time being!

The strategy for low RAM usage seems to be to not cache any directory data (so there's a performance hit, but in this case probably no big deal) or cluster chain stuff. In the case of the bootloader there's no app demands for RAM, so other than the basic tile mode requirements there's space to snag a couple sectors at a time and do a ping-pong buffer for the SPM usage.

I assume it would be sufficient to only support the root directory? FAT16 is a lot easier than FAT12, a lot less bit twiddling

Yeah, I think pretty much any restrictions are fine as long as they're spelled out up front. Worst case, if we *had* to, we could even do stuff like require a freshly formatted card (sequential sector assignments that way). One other idea that came up (I don't remember if it was me or somebody else) for a cheap and easy 'write' system on the card-- create a file on the PC with however big you want the dataset to be, then just over-write the file data in place with the AVR and leave all the cluster/FAT stuff intact.

Another consideration would be to have an intermediate 'helper' app on the host PC (generic term). Basically just have a single file that the code needs to go find, then have all the games packed into that one file. (a WAD essentially)

The upside to that is that the first few blocks could be the entire 'directory' complete with long application names that just point forward to the offsets for that particular game flash data, so getting the game list would be trivial and we could show 'long file names' without needing to open files or anything. (Since we definitely do not want to try to do long filename support in the bootloader otherwise.)

Lastly, one other thought-- we could also create the bootloader using some 'professional' grade AVR tools. IAR or even Codevision. Both will product code (sometimes *much*) smaller than GCC will. We could just make the .hex available for whoever needs it (and still release the code-- even if not everyone can build it). I this IAR offers a free full version of EWAVR with a 4K limit-- if it can do bootloaders that's all we'd need/want anyway. And one other permutation there-- if one of the commercial libraries made the SD support smaller/more workable we could even use that and just only distribute the .hex and source without the library source.

(I'm going away on business for a week starting this Saturday though, sigh)

D'oh! Well, your kit should be waiting when you get back!

-Clay

[DavidEtherton]

To keep this thread from drifting too far off topic, I started a new thread with a simple FAT16 root directory scanner.

viewtopic.php?f=3&t=167

-Dave