Uzebox AVCore+Baseboard Kit Selling Now!

[DavidEtherton]

Hey Clay,

I assume the 644 is soldered in, and not in a socket? Assuming the 1284 ever comes out in quantity, what are the odds of getting an "upgrade" produced?

(Searched the forums and found some pictures -- looks like it's the square surface-mounty thing, not a DIP, so no socket)

-Dave

[havok1919]

I assume the 644 is soldered in, and not in a socket? Assuming the 1284 ever comes out in quantity, what are the odds of getting an "upgrade" produced?

Ehhhh, it *could* be desoldered and replaced, but it would be a PITA. The module wasn't really meant to be upgraded-- it's more like a BasicStamp kinda thing. An entire Uzebox compatible computer on a 40-pin DIP, so people can plug those capabilities into "whatever" and not have to mess with building it (or taking up the space of through-hole parts). About half my interest is in using the basic Uzebox kernel for non-gaming applications. (Hence the microSD and trying to keep as many I/Os and ADC channels 'free' to the user.)

I could always offer a trade in or (more likely) just a deep discount on 2nd module for an 'upgrade' down the road.

-Clay

[funkaster]

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

just a random thought here:
how about a partition? I mean, you could have the SD card preprared in the uzebox (or by a special cli utility), creating a partition table leaving a reasonable size partition: 100 - 200MB should be enough for everybody and use that partition in a format that would be easy to read from the uzebox. We could write a simple cli utility so that we could upload/list/remove our apps to this partition. That way, you could even have that cli utility in the other partition of the SD card, to ensure portability

[DavidEtherton]

I'm pretty sure we can get at least the following minimal FAT16 support in for a very small amount of code:

- Iterate files in root directory (8.3 only).
- Read files
- Write files without making them bigger (ie create empty files on pc first)

Long filenames wouldn't be hard to support, but Microsoft has claimed patents related to them.

It wouldn't be too much harder to support growing and shrinking files -- the FAT is just a big array of linked lists.

The hardest part is probably giving up the 512 bytes for a sector buffer, although we could use a half-sized or quarter-sized buffer easily enough, at some loss in performance since apparently it's not safe to do partial sectors reads/writes on the cards.

-Dave

[uze6666]

Interesting! I'm not to familliar with the low-level details of partitions, but I'm wondering what Clay is thinking about the risks of this one.

Nice thing would be the use of stantard (and safe?) windows tools to partition. Quick and dirty bootloader would be greatly simplified, yet let the main program have a more complete FAT library if required to interact with a PC. Ie. design patches on tiles on the Uzebox and transfer to PC. Yeah, I'd advocate this, specially if we make the first partition the Uzebox one.

If someone has free time and knows how, coding a Windows Explorer Shell extension (or equivalent on other OS) to access that special partition would be the cream of the crop! Easy drag and drop!

What do you guys think?

Uze

[Lerc]

I partitioned an usb thumbdrive the other day, Mac and Linux handled it fine. Windows (xp) only saw the first partition. Opening up a partition view of the drive it actually said 'partitions not relevant to this device' or something like that.

As for a custom format card with a special writer program. It would be fairly safe if you had a identification key on the card so you don't block other cards by mistake.

My concern with fat reading wasn't so much the difficulty of following the format but the speed of doing so and the chance of non contiguous files.

[Stickboy]

Just ordered mine yesterday!

Cannot wait to get my hands on it and start working!

Shan

[Kamilion]

Anyone considered bridging to the SD with a http://dosonchip.com/ ?

Alternatively, the partition idea.

Any PC OS will recognise multiple partitions on a usb mass storage device.
To the OS, there is no fundamental difference between a USB flash drive and a USB to SATA device connected to a harddrive.
They are both USB Mass Storage class devices. It's extremely rare to have a NON-USB flashcard drive, even internal ones on desktop PCs are connected via USB.
Some linux based netbooks with SDIO are exceptions to this rule.

Disks can contain four primary partitions, or three primary partitions and an extended partition to act as a container for further filesystems.

http://en.wikipedia.org/wiki/Master_boot_record

The MBR is 512 bytes long. It is always the first sector on disk, or Sector 0.
It defines the partition table and has an magic number to identify the end of it (0xAA55).
I would suggest an 8MB raw partition at the beginning of the device, followed by a FAT filesystem partition filling the rest of the device.
Contained within this 8MB, would be:

A signature (0x55 0x5A 0x45 0x42 0x4F 0x58) (UZEBOX)followed by a configuration table, and padded to 512 bytes. This would be Sector 1.

Sector 2-10: Boot code.
Sector 10-100: FAT12/16/32 filesystem support code
Sector 100+: Menu system


This would be the easiest to bootstrap all you would need for the amtel while keeping a minimal amount of code in it's flash:
Verify_Sector_1_Signature(Load_Sector_2_From_Mass_Storage(dev.storage.mass))

Initial formatting of a card would occur from a PC program that would verify the existence of a completely empty FAT filesystem on a card (to prevent data loss), write a new MBR & partition table, Write the 8MB Raw partition, and ask the host OS to format the new second partition on the device with the FAT filesystem.

Also, remember, there is a whole boatload of SD-connected devices, from cameras to wifi adapters.
http://en.wikipedia.org/wiki/Secure_Digital_card#SDIO
"SDIO cards are fully compatible with SD Memory Card host controller (including mechanical, electrical, power, signaling and software). When an SDIO card is inserted into a non SDIO-aware host, it will cause no physical damage or disruption to device or host controller. SPI bus topology is mandatory for SDIO, unlike SD Memory. Most of the SD Memory commands are not supported in SDIO. SDIO cards can contain 8 separate logical cards, though at the moment this is at most a memory and IO function."

Good luck, hope this is helpful!

[Tinctu]

I was learning this year so after long time I am back.
And development here is AWESOME.
All PCBs with SD-Cards and SNES gamepads looks super cool.
Time to buy one.
I have emailed to Clay.
So I hope I will be new UzeBox owner soon...

[uze6666]

Welcome back! Lot's of cool stuff still coming!