Text Files on HP 50G
perr...@gmail.com
SD card and want to put some stuff on it.
John H Meyers
> How do you ass text files and read text files on the HP 50G,
> I have a SD card and want to put some stuff on it.
Do you mean files containing any general text,
such as saved email, Notepad files, etc.,
which you simply want to view on the calc?
Just copy to SD card;
the results of reading an SD card in the calculator
are the same as the results of transferring files
from a computer (via cable) in "binary" mode;
all files not created by a calculator
will be considered "string" objects
when copied or recalled in the calc,
and the "string" will be exactly what the file contains.
If the extra "carriage return" at the end of each line
(which may appear as a "black dot") is annoying,
it can be removed using a simple program,
assuming string to be processed is on the stack:
\<< 13 CHR "" SREPL DROP \>>
If you want to include a viewer in the above program:
\<< 13 CHR "" SREPL DROP DUP SCROLL \>>
If the files are UserRPL programs in *text* form,
where an "ascii translation" has been applied
to represent 8-bit characters using only 7-bit characters
(e.g. \<< and \>> for "program delimiters"), then see:
http://groups.google.com/group/comp.sys.hp48/msg/6598370f0778be6e
(this also contains links to other related articles)
If the files are SysRPL text, then use just the "translation"
part of the above (do not evaluate with STR\->);
most SysRPL program text is plain 7-bit text to begin with,
in which case the text could even be assembled as-is,
directly from the original computer file.
[r->] [OFF]
John H Meyers
on the calculator, then *export* them to a PC:
(assuming the "string" object is on the stack)
\<< 13 CHR "" SREPL DROP
10 CHR 13 CHR OVER + SREPL DROP \>>
When the adjusted string is saved by the *calculator*
as a file on the SD card,
it will have 13 extra initial characters
("HPHP49-x" followed by five binary characters),
which may be edited out on the PC.
At present (and probably in the future too),
it's not possible for the calculator
to write an SD file without a similar "binary prefix,"
except by using a third-party "Filer" program.
[r->] [OFF]
Ingo Blank
Hash: SHA1
John H Meyers wrote:
<..>
> At present (and probably in the future too),
> it's not possible for the calculator
> to write an SD file without a similar "binary prefix,"
> except by using a third-party "Filer" program.
No need for a third-party "Filer"...
This tiny HP-GCC program does it as well.
And in the "future" it will be possible to launch HP-GCC programs
without the 'ARM-Toolbox' by simply EVAL'uating them, like any other
executable object.
(The upcoming HP-GCC version 3.0 will feature a new built-in executable
'ARMC' object.)
Furthermore, ARMC objects will be tiny compared to today's HP-GCC L3
strings, since the majority of the runtime libs will reside in Flash
ROM. So stay tuned...
> /*
> * Write a string in stack level #2 to a file named as string in stack level #1
> * on the SD card.
> * The string is stored as a regular text file, without the HPHP49 object header.
> *
> * Ingo Blank
> * 2005-08-11
> */
>
>
> #include <hpgcc49.h>
>
> int
> main()
> {
>
>
> char *filename,*string_data;
> FILE *f;
>
> if( (filename = sat_stack_pop_string_alloc()) &&
> (string_data = sat_stack_pop_string_alloc()) &&
> (f = fopen(filename,"w")) ) {
>
> fputs(string_data,f);
> fclose(f);
>
> } else beep(); // error!
>
>
> return 0;
> }
>
- --
Ingo Blank
http://hpgcc.org
http://blog.hpgcc.org
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFFuzwDr9bi0BQTf30RAuL7AKDKHLRvMGwWk7LfD4R4qhUl8DRAEwCeN/e0
wjdF44bE26nK6b03geQntmg=
=cyNM
-----END PGP SIGNATURE-----
Veli-Pekka Nousiainen
news:45bb3c04$0$5724$9b4e...@newsspool3.arcor-online.net...
X
> And in the "future" it will be possible to launch HP-GCC programs
> without the 'ARM-Toolbox' by simply EVAL'uating them, like any other
> executable object.
> (The upcoming HP-GCC version 3.0 will feature a new built-in executable
> 'ARMC' object.)
>
> Furthermore, ARMC objects will be tiny compared to today's HP-GCC L3
> strings, since the majority of the runtime libs will reside in Flash
> ROM. So stay tuned...
I've been holding my breath so long that I'm now a Zombie!
The wait is worth it
I want my new ROM 2.10 with patched HPGCC
BUT
only when it's really ready
I would call that rom: ROM 3.0
The inclusion of the full HPGCC 3.0 support
is THAT important to this ARM based calc
Albert Graef
> No need for a third-party "Filer"...
> This tiny HP-GCC program does it as well.
Great, many thanks.
> (The upcoming HP-GCC version 3.0 will feature a new built-in executable
> 'ARMC' object.)
>
> Furthermore, ARMC objects will be tiny compared to today's HP-GCC L3
> strings, since the majority of the runtime libs will reside in Flash
> ROM. So stay tuned...
Fabulous! I'm waiting ... as fast as I can. ;-)
--
Dr. Albert Gr"af
Dept. of Music-Informatics, University of Mainz, Germany
Email: Dr.G...@t-online.de, a...@muwiinfa.geschichte.uni-mainz.de
WWW: http://www.musikinformatik.uni-mainz.de/ag
Claudio Lapilli
Hi,
> I've been holding my breath so long that I'm now a Zombie!
> The wait is worth it
> I want my new ROM 2.10 with patched HPGCC
> BUT
> only when it's really ready
Exactly, that's why you don't hear from us too often. We will never
release something in rom that is not ready. We are not planning to
release rom updates every week, so you'll have it when it's ready, not
a minute earlier.
>
> I would call that rom: ROM 3.0
No, I would call that: "HPxx rom with HPGCC3 patch". That way we are
clear that this will NOT be an official rom, not endorsed or supported
by HP. We don't want to give the idea that this is a new rom by HP.
>
> The inclusion of the full HPGCC 3.0 support
> is THAT important to this ARM based calc
Let me throw a few more bones to the dogs... :-)
1) Vastly improved launch speed: A userRPL loop calling a do-nothing C
program runs a loop every 12 ms (including launch time + userRPL loop)
2) "Hello world" is now... 144 bytes! (versus 9kb or 12 kb in hpgcc2,
depending on the version of printf() used)
These numbers may change (up or down) in the final version, but that's
where we stand right now.
Claudio
Veli-Pekka Nousiainen
news:1169924083.0...@q2g2000cwa.googlegroups.com...
X
> No, I would call that: "HPxx rom with HPGCC3 patch". That way we are
> clear that this will NOT be an official rom, not endorsed or supported
> by HP. We don't want to give the idea that this is a new rom by HP.
ok, fair enough
>> The inclusion of the full HPGCC 3.0 support
>> is THAT important to this ARM based calc
>
> Let me throw a few more bones to the dogs... :-)
>
> 1) Vastly improved launch speed: A userRPL loop calling a do-nothing C
> program runs a loop every 12 ms (including launch time + userRPL loop)
Rousk!
> 2) "Hello world" is now... 144 bytes! (versus 9kb or 12 kb in hpgcc2,
> depending on the version of printf() used)
Impossible!
> These numbers may change (up or down) in the final version, but that's
> where we stand right now.
You cheating, Claudio!
The lib can not run XIP - it will eat up RAM....
I don't believe you...tricksters of bit twisting...!!
You're hexing the code - you - you Warped Warlocks & Wimpy Wizards
--
Veli-Pekka
PS: I add the smileys later...