Another Idea for a RAM-based Program

[Iambian]

I've been talking to someone online and I've been enlightened on a way to provide most of the benefits of a FlashAPP in a RAM-based program. This would work, of course, only if I was allowed to uninstall all the hooks and all the other FlashAPPs on the calculator, since this idea would require that only "Celtic IV" be installed.

The idea is to set up a RAM-based parser hook that sits in the appbackupscreen buffer. The hook then copies a piece of code from a file that sits in Flash to the savesscreen buffer for execution for the features that you want. Sure, this will be slower than an app, but there would be far less of a memory footprint, and it will be most certainly faster than the Celtic III RAM-based version, since memory does not need to be rearranged every time the program is called, save for the normal stuff the parser has to do when passing values through the hook.

Since a bunch of RAM needs to remain intact throughout the execution of the BASIC program, other applications that like to use the appbackupscreen as scratch memory cannot be running. By the time this project takes effect, however, I'll probably have a suitable replacement for xLIB. That means this project won't happen for quite a while.

When the BASIC program quits, the hook uninstalls itself quiety so if (and when) the appbackupscreen gets corrupted from the execution of other things on the calculator, the calculator won't crash. Call it good housekeeping?

So, let me know what you think, ye who refuse to use the APP version for its huge size. And maybe other people, too...

EDIT: I was also suggested that I should cache the commands so that code isn't repeatedly copied if the same set of commands were "abused" frequently. This would help out in an environment where speed is essential, such as drawing a whole load of sprites, or perhaps, grayscale.

[nitacku]

How much memory is available in the appbackupscreen?
Would it be possible to load the app into the appbackupscreen through an installation command?
This way everything would be fast.

It doesn't really matter if the program takes a while to load.
Speed is only crucial once a program starts getting into the meat and potatoes.

[TheStorm]

nowhere near enough sorry.

[Harrierfalcon]

Celtic III is ~2200 bytes. The appsbackupscreen is 768. Hm.

[Iambian]

It seems you fail to see the scheme I am planning. Don't you already know that I know that 2000-ish bytes will not fit in appbackupscreen?

The loader is in the appbackupscreen buffer. It contains all the information needed to run as the parser hook. It loads individual functions to the savesscreen buffer. You have to realize how Celtic III is built. No single function EVER exceeds 500 bytes. savesscreen is used to buffer the function prior to execution. It is also 768 bytes.

I am just saying that although it will be slower than the app, some people will not use it because it is size-prohibitive. It will be faster than the Celtic III ASM program because RAM does not need to be rearranged each time the program is called.

Need I explain more?

[vuurrobin]

so if a fuction is called, you just copy the code of that funcion to appbackupscreen, correct?


what kind of functions will be included, only that of celtic 3 program or also functions like the string based tilemapper?

since this cannot be used with xlib, I am not to sure if many people will use this (unless this can replace xlib), but then again, I could be wrong .


instalation can happen from other programs, right?

and can the program be in arc when used?

[Iambian]

The installer and the hook is copied to appbackupscreen.
The function code seen from the hook is copied to savesscreen for execution.

This program will be developed only when Celtic III APP is done. By the time that happens, I hope to have Celtic III as a decent replacement for xLIB. Keep in mind that this implies that I will further develop Celtic III to add in functions such as a string-based tilemapper, among many other functions.

Installation can happen as long as the BASIC program executes the installer. The seperate data file that holds all the functions are *expected* to be in FlashROM. After the installer is used, it may be archived as well.

Just as this program's title indicates, Celtic IV will only be developed AFTER Celtic III has reached completion. If nothing else indicates the completion status of Celtic III, I can say that it is nowhere near complete. This leaves a lot of room.

For the features in Celtic IV, it will match or exceed that of Celtic III APP.

Any further questions?

[Harrierfalcon]

[ZagorNBK]

I think that Celtic as an app is better than as a program.

[darkstone knight]

cant you just use a serparpate program to install the hook (prgmCELTIC on first line of the prog) that "installs" some huge jump table in appbackupscreen, that is called each time you use real(

[Iambian]

Three things.

One: This is what we like to call "necroposting". If you haven't noticed, the third post behind this one almost a year old. It kinda tells you about the status of that particular leg of the project.

Two: This particular project is dead. Its basis was that I would never simulate xLIB within my own application, which by the way, is being done so already (although not perfectly).

Three: Because of item two, I'm locking this thread. If the idea ever resurfaces, I'll create a new one.