Sideshow from SD-Card

Topics related to the API, programming discussions & questions, coding tips, bugs, etc. should go here.
Post Reply
User avatar
PitfallJones
Posts: 39
Joined: Mon Aug 16, 2010 12:01 am

Sideshow from SD-Card

Post by PitfallJones » Sat Aug 16, 2014 1:39 pm

Hi,

I want to display a side show of pictures from a SD-Card.
I see there is mention of using the SD-Card here:
http://uzebox.org/wiki/index.php?title= ... Store_Maps
But I can't actually find a link there to download a compilable project.
Can anyone post a zip here (or a link) of the source code to do this.

Also this may have been mentioned before but has anyone accomplished making a multi level game where the next level is loaded off the SD-Card as a new program?

Thanks

- PJ

User avatar
uze6666
Site Admin
Posts: 4487
Joined: Tue Aug 12, 2008 9:13 pm
Location: Montreal, Canada
Contact:

Re: Sideshow from SD-Card

Post by uze6666 » Sat Aug 16, 2014 8:02 pm

As far as I know, only the Uze mario game loaded map info from a SD card. But it was a bit choppy, perhaps pecause of the slow speed of the PetitFatFS API.

There's no stable released code to display a full screen pictures so far. The movieplayer is broken since a while and was not very reusable. CunningFellow code for Tempest will allow some streaming of a repeated frame so that may be your best bet in the long run (but it's 1 Bpp). In any cases there's some limitations. Speed of SD cards vary and makes the code tricky because we have to push bytes to the video DAC on a tight CPU cycle schedule. Good brand card like Kingston and Sandisk are ok and have 1 or 2 delay bytes in between sectors, but cheaps cards need much more, i.e >100. This ruins the picture, but it can be detected and the game could inform the user to "switch to a better SD card brand to play that game".

What kind of pictures did you have in mind in terms of resolution, colors, etc?

CunningFellow
Posts: 1196
Joined: Mon Feb 11, 2013 8:08 am
Location: Brisbane, Australia

Re: Sideshow from SD-Card

Post by CunningFellow » Sat Aug 16, 2014 10:30 pm

The tempest code displays 1Bpp at 40 clocks per SD card byte.

You could make that 2Bpp at 20 clocks per SD byte without having to play any silly tricks.

I am pretty sure with silly tricks and some image compression you could get a 240x224 pixel screen at 8Bpp.

It's not going to be an easy task though.

User avatar
PitfallJones
Posts: 39
Joined: Mon Aug 16, 2010 12:01 am

Re: Sideshow from SD-Card

Post by PitfallJones » Sat Aug 16, 2014 11:25 pm

Hi,

Thanks for the response.

It's actually not the displaying of the picture that I'm confused about, just how to load a file from the SD-Card.

I'm using the 240x224 6x8 character mode and I already have my pictures converted into tile sets ready to be displayed (approx 1200 6x8 tiles).

My demo program just has one tileset embedded in it's .hex file and it displays fine.

So on a keypress I want to load subsequent 'screen images' from SD-Card, speed is not an issue here, I just want to see on a real TV how well certain images appear.

- PJ

CunningFellow
Posts: 1196
Joined: Mon Feb 11, 2013 8:08 am
Location: Brisbane, Australia

Re: Sideshow from SD-Card

Post by CunningFellow » Sun Aug 17, 2014 4:55 am

Pitfall,

Sorry. I thought you where intending on a custom video mode.

To display pictures in a regular video mode with a different tile set per picture would require reflashing the ROM for the tiles.

I guess look at the bootloader code for how that is done. (Its ASM only is my guess though)

If all you pictures could get by with the same tile set, then you could probably just read from the SD card to VRAM.

I used the SDCard Demo and the video demo as my examples I worked off, but I think UzeAmp would be a good one for the file system stuff.

If your keen on making a custom video mode that just shows a picture straight of the SD with out using tiles, then I can lend a hand with hairy ASM stuff.

User avatar
D3thAdd3r
Posts: 2424
Joined: Wed Apr 29, 2009 10:00 am
Location: Minneapolis, United States

Re: Sideshow from SD-Card

Post by D3thAdd3r » Sun Aug 17, 2014 7:11 am

PitfallJones wrote:...where the next level is loaded off the SD-Card as a new program?
I have a 95% complete game that loads level data from SD and it is very easy with petitfs BUT it is not a new program and you have to have enough ram to hold everything you load..a rather limiting factor of course. There was some discussions a while back about the chip self flashing itself, or resetting and letting the bootloader do it based on what the program told it to do(indicated by eeprom flags perhaps) but I don't think it's going to happen.

You are interested in loading a new program off the SD so you can have new graphics per level or such?

User avatar
uze6666
Site Admin
Posts: 4487
Joined: Tue Aug 12, 2008 9:13 pm
Location: Montreal, Canada
Contact:

Re: Sideshow from SD-Card

Post by uze6666 » Mon Aug 18, 2014 7:41 pm

So, what you are looking for is an example of how to use FatFS or petitfatfs (I've ported both apps to the Uzebox last year) ? The uze8 emulator, part of the demos in SVN uses petitfatfs and it's relatively simple. If speed is not issue, this will do fine. For more speed (and more ram usage too) use FatFS.

User avatar
PitfallJones
Posts: 39
Joined: Mon Aug 16, 2010 12:01 am

Re: Sideshow from SD-Card

Post by PitfallJones » Wed Aug 20, 2014 1:49 am

Great just what I needed - I'll check out that source out then.
Is there a good example how to re-flash the data area of a program while it's running too? (as a picture's tileset will take more than the available ram).

- PJ

User avatar
uze6666
Site Admin
Posts: 4487
Joined: Tue Aug 12, 2008 9:13 pm
Location: Montreal, Canada
Contact:

Re: Sideshow from SD-Card

Post by uze6666 » Thu Aug 21, 2014 12:09 am

PitfallJones wrote:Great just what I needed - I'll check out that source out then.
Is there a good example how to re-flash the data area of a program while it's running too? (as a picture's tileset will take more than the available ram).
This one may be problematic. Flash writes can only be initiated from the bootloader area, that is, the SPM instruction must reside in the upper 8K. The bootloader takes only 4K so there 's still a 4K usable by the user program. But I have never tested that and there's no code example on the Uzebox so far. The only flash writing code is in the bootloader in SVN, you can give it a look and try it out. You'd have to put that function within it's own section and tell the linker via the makefile to place it in the upper 8k of program memory. Not sure uzem support SPM correctly (or at all) though.

Btw, your application would requires lots of reflashing, reducing the life of the atmega. Though it's been proven not to be a real issue considering the 100K+ rewrites supported, some bug could brick the chip in no time. So it's critical to be well tested before releasing.

Post Reply

Who is online

Users browsing this forum: No registered users and 1 guest