Petit FS

[D3thAdd3r]

How difficult is it to implement writing partial sectors to the SD card? We just need disk_writep implemented to be able to have save/load states fairly easily in hardware. As long as all it takes place in the same WaitVsync/Save or Load/WaitVsync place in code I figure it should be fine...maybe?

[uze6666]

Note sure what you mean, but Petit FatFS (PFFS) already implemented both partial sector read and write. In fact, it only use partial sector ops. That's why it can work with a very little buffer (but be really slow) or use 512 bytes and be much faster. It can read/write anywhere in time, it's not confined to vsync. What did you have in mind?

[D3thAdd3r]

I figured it you copied most of the ram to SD you could later recover your vram,game variables, etc back to restore the state. Probably something stupid on my part, but I am getting ...kernel/petitfatfs/pff.c:933: undefined reference to `disk_writep' when I try and use pf_write()

[uze6666]

Oh, I think I see why. I added conditionals build switches in pff.h but I should have added a value to the de corresponding IF statement in mmc.c. I'll fix this.

[D3thAdd3r]

I am a bit confused I have something like this

Code: Select all

FATFS fs;            
BYTE buffer[40];
FRESULT res;
WORD br;
////
	pf_mount(&fs);            
	pf_open("BinSong.inc");

	for(u8 i=0;i<5;i++){
		pf_lseek(i);
		pf_read(buffer,1,&br);
		PrintByte(6,i,buffer[0],true);
	}

Lets say my file has 0x00,0xc0,0x09,0x00,0xc1,0x0a.... I would expect to see from top to bottom printed the decimal value of the first 5 bytes but that is not what is happening. I understand I only need to fill the buffer up and I can read different positions like buffer but that is not what I am after. I want to address individual bytes on the SD card. I really can't understand what is happening here Also petitfs says it has auto increment on file pointer but it appears that is not the case in the Uzebox implementation.

[uze6666]

Addressing individual bytes with PFF is *highly* inneficient, just look at the implementation of disk_readp in mmc.c. For each call to pf_read() all the sector is read byte per byte until it reaches the offset you need and then reads all the trailing bytes after. This is not my stuff, it's the original implementation. Since I guess we'll want to stick to the "no fragmentation" approach, the best thing would be to extend pff with a new read function that works with multiple block read and ignores fragmentation. You'd still use pff to mount, open and seek the files.

That said, I've looked at the code and it should increment the file pointer...so that weird. It's a bit late tonight and I'm very tired so I'll give it a look tomorrow.

[D3thAdd3r]

Thanks Alec I'd appreciate you checking that out. I will look at the implementation again even though that kind of stuff is "scary" code to me. I will have to try it on hardware tomorrow just to eliminate that possibility.

-Edit I tried it on real hardware and it doesn't work for me.

[D3thAdd3r]

An oversight on my part I thought I wasn't getting an error code before so removed the error checking, but I guess I made a mistake there...as soon as lseek() is called a second time it is returning FR_NOT_ENABLED. I am reading through the code and scratching my head a bit trying to understand how that exactly happens.

[uze6666]

Hmmm not easy to say what's going on. Can you post you whole test projet, the kernel version and if you're running from uzem or hardware?

Edit: It work on my side, the file pointer is incremented in pff. However there seems to be a bug in uzem. The second character is actually skipped in uzem where it appears ok on the hardware.

[D3thAdd3r]

I tried it in a different project setup that works fine as far as I can tell and I get different results....It lseeks and reads without error but doesn't pull the values I would expect and I do not know why??!

So I don't know if memory is getting corrupted or what I am lost on SD..again.

kind of a messy project the hex is snowpunkz.hex in default