[41CL] Image Database
#1

I've added documentation for the Image Database and the proposed Image Database Functions to the 41CL website:

IMDB documentation (pdf)

#2

Reading with utmost attention the documentation...

a sentence caught my eye:

"Only the four words of the new database entry are written to the Flash."

You mean only that 4k-block and thus those four bytes being the only new content, or you have figured out a way to only write to those four locations??

Eagerly awaiting the actual software, pls. let us know when it´ll be available.

Thanks a million, the CL is about to get even better.

ÁM

#3

Only the four words of the new database entry will be written. I structured the database specifically to allow this operation. This only works for a new entry, and the function will check that this is the case before doing the writes. So the only time that you need to worry about copying the database to RAM and then writing it back to Flash is when you need to modify an existing entry, which should be very rare. Which makes me realize that I need to add a function to null out an entry... because the IMDBINS won't allow you to do that.

#4

Rather than adding another function, could it be done by IMDBS if the entry in Alpha was single-cased? That would save one FAT entry.

#5

Yes, things can be simplified. Sorry, that's what happens when I type before thinking things through.

#6

It occurred to me that a good location for the new IMDB related functions could be a "parallel" block to the YNFS module. To overcome the FAT limitation it´ll be possible to use the header function "-YFNS 3C" to manually "switch" it, activating the IMDB block to replace it. After the function is executed it´ll leave things back the "normal" way.

Obviously said "parallel image" would need to contain some basic Y-Functions for housekeeping, at the very least one to manually return to the "main" block. For instance the "-YFNZ 3C" could of course do that job, in reciprocal fashion.

Not exempt from potential issues but a viable method to eliminate the FAT barrier. Food for thought...

#7

I don't think that an executable function can have a name longer than 7 characters, at least from the keyboard.

But you're probably right that I am over-thinking this. I imagine that the typical user only needs to be able to insert an entry into the database, and very rarely at that. Back to the drawing board.

But the idea of automatically switching in a different function set is interesting. It's easy to do. Just find the current location by querying the MMU, saving that information, and reprogramming the MMU to point to a modified version. Then the mirror function does the reverse.

#8

I didn't explain well, let me try again.

You're not overthinking the scheme at all, those seven functions in the IMDB write up are all great - pls. don't cut back!

The parallel block would have its own header and then the 7 functions - or as many more as you see fit. Things would look similar to this:

Main Block                        Parallel block

-YFNYS 3C <-- mirror fns---> -IMDB 1A
MMUCLR IMDB
MMUDIS IMDBRAM
MMUEN IMDB?
MMU? IMDBCPY
TURBOX IMDBUPD
TURBO2 IMDBINS
TURBO5 IMDBA
... ...
the beauty of this lies in that the parallel block is completely independent = can be used stand-alone. This is fine for normal users, and you're right about the executable length - but power users can use the XROM function, or the CCD catalog.

But it can also be used from within the main YFNS block, if the "switching function" is enabling the swap, execute, them swap back - playing with the MMU settings as you have suggested.

This can be further enhanced if in RUN mode "-YFNS 3C" puts up a selection prompt, like this for instance (concept is the launcher idea):

IMDB A:C:I:R:U:?

where each one of the allowed selections triggers the corresponding IMDB function.

Haven't thought out all the ramifications but in principle it looks viable. But anyway it's a second-degree tweak; much less important than the IMDB functions themselves.

All this assumes that none of the IMDBxx functions needs the YFNS code on-line, which may not be the case at all. If it's needed then both blocks will need to be on-line simultaneously.

Will you make us wait much longer?? :-)


Edited: 3 July 2012, 2:46 a.m.

#9

Just pitching in with a word of encouragement:

This-is-freakin'-awesome-please-continue.

Edited: 4 July 2012, 8:09 a.m.

#10

+1 ;)



Possibly Related Threads…
Thread Author Replies Views Last Post
  HP-41CL setup troubleshooting Xavier A. (Brazil) 2 1,848 12-02-2013, 06:29 AM
Last Post: Xavier A. (Brazil)
  How to add image to HP Forum Posting Harold A Climer 2 1,471 11-20-2013, 02:28 PM
Last Post: Han
  [41CL] New Extra Functions version Monte Dalrymple 0 1,084 11-08-2013, 04:32 PM
Last Post: Monte Dalrymple
  So, latest 41CL / Library 4 config is... Gene Wright 4 1,958 09-22-2013, 02:59 AM
Last Post: Ángel Martin
  HP-41CL anyone? Matt Agajanian 8 2,868 08-31-2013, 12:27 AM
Last Post: Sylvain Cote
  [41CL] A couple more rhetorical questions Monte Dalrymple 1 1,216 07-12-2013, 09:28 AM
Last Post: Ángel Martin
  41CL :TROUBLE IN FILE TRANsFER aurelio 22 5,976 06-18-2013, 03:44 PM
Last Post: aurelio
  [41CL] Another question for users Monte Dalrymple 28 8,024 06-03-2013, 10:04 AM
Last Post: Geir Isene
  [41CL] Updated Manual Monte Dalrymple 1 1,233 05-14-2013, 10:22 PM
Last Post: Matt Kernal
  HP-41CL & NoV(-64): Race condition? Geir Isene 11 3,253 05-03-2013, 01:59 PM
Last Post: Diego Diaz

Forum Jump: