Re: Anyone interested in . . .

On Sat, 10 Jun 2006 19:37:19 -0500, Claudio Lapilli wrote:

a simple STO routine I wrote for SD cards can store objects
with or without the HPHP49-... header

Does "store" mean the same as "ascii vs. binary" modes
of sending data over cable to a computer,
plus an additional "verbatim" mode for storing strings?

In binary mode, which means exactly
as the object appears in RAM when used inside the calculator,
which *always* includes some hard-coded ROM addresses,
there must *always* be an HPHP49-x header,
so that only the calc series on which the object was made
will later recognize and accept it (one can override this
safety feature by using a FIXOB or OBJFIX program).

Since the calc can always recall such objects properly,
directly from the SD card, there is no reason to omit
the HPHP49-x header from binary objects,
as the next thing following that 8-byte string
is *always* a 2.5-byte binary calc ROM address,
which never means anything to other computers anyway.

Ascii mode means the displaying of the object
as it would appear when edited in the command line
(and then with some 8-bit or other characters possibly expanded
for representation in pure ascii),
prefixed by a "%%HP" line to indicate how most modes
that affect proper interpretation are currently set
(character translation mode, angle mode, and decimal point mode,
but unfortunately nothing about Exact/Approximate mode).

The only other style not provided for during cable transfers
would be the transmission of character (or hex) strings
representing exactly what one would want an external file to contain;
this is what seems to be desired for GPS data or other external formats
that other computers or programs might need.

Now, since the SD card cannot realy be used as a calculator "port"
(to host libraries, for example), and since the card actually represents
a form of disk storage for other computers and devices,
the SD card should really always have been treated exactly the same way
that we handle external computers connected via a cable,
and we should have been able to transmit files in both directions
in at least the two usual ways (binary transfer and ascii transfer)
that we have always had available for those transfers.

However, what actually has been provided thus far, built into the calc
while using STO and RCL, is the exact equivalent of *binary* transfer alone,
producing the same results for STO as binary cable transfer
to an external computer, and the same results for RCL
as binary transfer from an external computer to the calc
(this includes the ability to *receive* any file as a literal string,
which is what happens by default when HPHP49-x is missing,
but there is no such equivalent ability for sending literal strings).

What I am thus proposing is the expansion of STO as you perhaps
have already offered, with a command permitting output
of any literal string (character or hex),
plus the currently missing ability to transfer in both directions
in the "ascii mode" available over cable.

I was at first suggesting to incorporate all possible modes
into a common command, but now I'm thinking that it might be better
if each mode had its own command, so perhaps a command set like this:

STO - existing (binary) STO

STOC - store literal character (or hex) string (valid only for these types).

STOA - store "in ascii mode," exactly like a cable transfer in ascii mode.

RCL - existing (binary) RCL (this already includes "RCLC" by default,
but you could implement an extra RCLC to deliberately prevent the
automatic attempt to convert strings beginning HPHP49-x to internal objects)

RCLA - recall "in ascii mode," exactly like a cable transfer

If file already starts with HPHP49-x and is a string,
then perhaps RCLA might interpret that string in the same way.

RCLA could optionally default to binary import for other object types,
or for strings which have compile errors, which would in effect
make RCLA a nearly "universal" import function,
or perhaps it might be best to let a short "user" program
embed a strategy of trying RCLA on a file, then proceeding
to try RCL if RCLA errors, allowing the user to decide
whether or not to "overload" the RCLA command.

[Claudio's STO]
can store objects with or without the HPHP49-... header
and can also store raw data if you provide a string,
hxs string, etc. The companion RCL routine will open any file
with or without HPHP header, and if it doesn't find a valid object,
it returns the file as a string (raw data).

I think it very dangerous to do a straight binary output,
simply removing the 8-byte HPHP49-x header, and even more dangerous
to do import binary objects without that "series identifying" indicator,
because this entirely removes the "safety interlock" wisely designed in
by the original HP design team, anticipating that binary objects
made using different ROMs can be incompatible, and could
cause crashes if transmitted between incompatible series,
as is very much the case now that the HP49 series
has a completely different set of even the "supported" ROM addresses.

Even though the initial ROM address
which is always present immediately following HPHP49-x
remains the same for those object types common to the HP48S/G series,
note that any program, any list, any directory, any unit object,
any object which didn't exist in the prior series, and even
some real numbers are likely to have incompatible ROM addresses,
and thus are dangerous to exchange between series
(possibly even including any future models like the HP60 series :)

Thus I would suggest re-considering, to never allow discarding of the
series-identifying HPHP49-x headers on all binary object files
(note again that FIXOB and OBJFIX are available to override
header discrepancies, at the user's own risk).

By the way, do all current ARM-based products (48Gii, 49G+, 50G)
employ the same binary object prefix "HPHP49-x" ?
[examine the internal VERSTRING function]

Tim was talking about a filer, but other people like you want a library
for advanced SD card access. I guess some commands could be left
visible for programmers, or even put on a separate library.

A separate library would be extremely handy!

Thanks for everything.

[r->] [OFF]
.

Relevant Pages

  • Re: Is it possible for me to have an alert pop-up when I open a do
    ... them and clean up the whole header. ... Dim TheWeekOfStr As String ... After I enabled macros and changed the security level, as per Dave Peterson, ... I got almost what I wanted, except that the pop-up box contains the font ...
    (microsoft.public.excel.misc)
  • Re: Zero terminated strings
    ... For doing major string handling you want a language where strings are a ... Check the header bytes as they are coming in and assume that you have dropped at least one byte if any of them are wrong. ... When you have a complete valid message (at the final destination, however many hops down the line it is) the final destination acknowledges it, and keeps sending ACKs for it until it receives the next message. ... The sender keeps trying to send it until it gets the acknowledgment. ...
    (comp.lang.c)
  • Re: Compile Error (ADO) Ron De Bruin
    ... Public Sub GetData(SourceFile As Variant, SourceSheet As String, _ ... Dim rsData As ADODB.Recordset 'THE ERROR IS ALWAYS HERE ... If Header = False Then ...
    (microsoft.public.excel.programming)
  • Re: Error With ADO (Starting to pull my hair out)
    ... 'It will copy the Header row also ... Public Sub GetData(SourceFile As Variant, SourceSheet As String, _ ... Dim rsData As ADODB.Recordset ...
    (microsoft.public.excel.programming)
  • Re: Error With ADO (Starting to pull my hair out)
    ... 'It will copy the Header row also ... Public Sub GetData(SourceFile As Variant, SourceSheet As String, _ ... Dim rsData As ADODB.Recordset ...
    (microsoft.public.excel.programming)