Yeah, I noticed that it seems to take forever to get out of the main menu. Maybe a loading bar in the final edition?

That would probably be a good idea. A better idea would be a way to minimize the overhead of reading from Flash, though, which really shouldn't be that slow.

Yeah, I realize that that would be the best way, but im saying that if when he optimizes it fully, it still takes over .5 seconds to load, i think it should have a loading bar.

Agreed. I just added a small, unobtrusive hourglass to Graph3DP to show when it is calculating the points of a complex 3D graph, so the user doesn't think that the application has crashed. Again, though, I think we're putting the cart before the horse, the cart is a small tree not yet cut down for lumber, and the horse is a colt.

Haha, you got that right. But one more thought before going back on topic, I think that ALL adding should have a loading bar, even if it just flashes on the screen for a split second, so that if the addin has more features and load time slows down, the loading bar is already there. And, so that if the user has his calc underclocked without knowing it, he will know that his calc has not crashed.

[/offtopic]

I think you're making a good point about general useability issues, of which that is just one. Another useability issue is one that AHelper brought to everyone's attention, namely the proper usage of the [MENU] and [EXIT] keys. Yet another such issue is making consistent Prizm main menu icon designs. A final issue would be to try to make utilities (such as Graph3DP) match the native look-and-feel of Casio's own applications, from the menubars at the bottom of the screen to the menu flow.

In fact, my file was corrupted

Congratulations MPoupe, I had not seen great new programs for a long time in Casio community.

There is a lot of fun on this server.
It seems the most important thing for some of you is proper icon and progress bar.

Well, I was trying to do my best to get flyingfisch to stop worrying about the progress bar when finding sources of slowdown and overhead to speed up the engine are a more pressing problem. Do you have any ideas on that front yet?

CGDoom is creating map of the wad file on the start. It is done dumb way (the same way as CGplayer does), so it reads the wad in 4 KB pieces (sector size) and it searches in the whole flash for it. If the file is not fragmented, it requires to read (at most) once the whole flash.
If the file is fragmented, it restarts for each fragment.
So for example file has 10 fragment, so the file is read once by OS routine and flash is scanned 10 times.
This could be improved by caching - the map of the file may be stored in another (small) file, it has 4 bytes per fragment.
In addition there are also doom native initialisation routines, run classic doom on older PC (like 486), you will see the delay too.

But there are many more important problems in CGDoom than the speed of startup.

I am sorry if it sounded like it was the most important thing. I was just mentioning the fact that addins that take a while to load shoud have a load bar. And I didn't necessarily mean just you

I do understand that the more important thing is optimization, etc. at this point.

Maybe I should have made a new thread about loading bars instead of using yours?

But really, this is an amazing game. Especially for prizm

Note that sometimes drawing a loading bar and updating it takes more resources and time than just waiting while Casio's hourglass spins.

MPoupe, agreed. I meant the speed of the game itself, not the speed of the startup. I'd happily accept a slower startup in exchange for faster gameplay, and I think some kind of custom memory management is going to need to be done to make it work properly without memory errors.

I was trying to save lot of memory (and also CPU) by direct accessing the flash. But is seems sometimes read access to the flash causes exception . Do we have some information about that ?

We don't currently, but I'm sure we have enough Prizm hackers here that some of them would be interested in working on the problem. Were you trying to poke the flash ports, or directly access the memory-mapped Flash area? Either way, we might have to break out into physical address mode in order to directly read Flash. Are you confident about the numbers you're using?

Exactly I got this error:
System ERROR
ADDRESS (R)
TARGET = A1524CCD
PC = 00305BA0

Problem solved.
Reading word from A1524CCD must crash. Reading per bytes is OK

Hello,

For my interpretor Luafx, I programmed a way to use ram files to read and write data.
I create the file with the casio library, but after I use it with pointers and the access is fast. Maybe you can do a similar trick with the casio prizm.

Good idea, but this way I would get (at max) 60KB standalone RAM.
So it doesn't solve my problem

Vebveb, would you Introduce Yourself when you get a chance? Congratulations on LuaFX; I'm particularly interested in that project, as I hope to port it to the Prizm at some point, or at least help someone else port it if I end up not having enough time.