Most up-to-date 48 emulator code (for command line)

[Orome]

I'm trying to locate the latest and greatest emulator code to build an RPL command line for (current) macOS. My naive approach is to just locate the current m48 code, cut the UI stuff, and wrap what's left for use interactively in Terminal. In theory that ought to be pretty simple, but I've got two problems:

1. it's hard to determine what instance of the code is "best", and
2. the code I have found is undocumented, especially with respect to sorting out how to pull out the RPL engine.

So I'd appreciate any opinions or thoughts about 1, especially if they lead to a version that solves 2.

[3298]

(04-26-2020 09:16 PM)Orome Wrote:  sorting out how to pull out the RPL engine

Are you looking just for any RPL, or some specific calculator's version wrapped in an emulation layer? Because the former sounds like you actually want a simulator instead of an emulator.
The RPL kernel (closest match for your "RPL engine") is of course part of the ROM (otherwise the real calculator couldn't run RPL), not part of the emulator. Emu48's debugger and other features admittedly hide this distinction from the user quite well, but the emulator runs RPL code only indirectly via the ROM's RPL implementation written in Saturn ASM and SysRPL.

I see two possible ways for your RPL-in-a-terminal quest:
1a. Use an emulator regardless, while just not showing the GUI. Emu48's debugging features can be used to send the input into the calculator's memory, then the emulation core is put to work running it, and afterwards you pull the results back out and print them. That's going to require quite a bit of hacking to get that working. I've seen a Mac port of Emu48 over at hpcalc.org, but I have no clue whether that one even works still. As for modifying the code to suit your needs, I can't help you as you've definitely more experience with it that I do, because unlike me you've actually looked at the code already.

1b. Same, but with x49gp as emulation core instead, which is at least proven to run fine on a Mac. I've worked with x49gp enough to know that ripping out the GUI ought to be quite simple, but getting data in and out in an automated fashion isn't. Maybe the calculator's remote control mode could be used; however, that requires a connection on the calculator's serial port, which is completely unimplemented in x49gp - someone would need to figure out how the serial or USB port's hardware works, and write emulation code for it (likely won't be easy). Also, you'd need your command-line application to talk to the calculator using the remote-control protocol. The code for that would need to be taken from yet another program or written from scratch.

2. Find a simulator, i.e. a reimplementation of RPL. I'm aware of just one, newRPL. As far as I can tell, that's much easier to adapt. In fact, a cursory look into its sources shows something in newrpl/main.cpp that looks an awful lot like a command-line application already, so I think you should just build that and give it a try. Of course, newRPL has some differences from traditional RPL (e.g. the meanings of + and ADD on lists are swapped, instead of 12-digit reals and infinite-precision integers you get configurable-precision reals up to ... was it 2000 digits?, etc), and it obviously isn't done yet, but this one appears to be the lowest-effort solution to your problem.

[Didier Lachieze]

(04-27-2020 12:04 AM)3298 Wrote:  2. Find a simulator, i.e. a reimplementation of RPL. I'm aware of just one, newRPL.

There is also RPL/2.

[SammysHP]

And if RPN is enough, you could try writing a command line shell for Free42 which has an abstraction between core and shell/GUI.

[Jonathan Busby]

3298's answer sums it up the best.

For a command line RPL environment, it would be easiest to use something like NewRPL or RPL/2, modified of course, as a basis for the command line.

If you want a more complicated programming project, then you can use the generalized RPL inner loop ( see here for more details ) and base your command line on that, along with all the basic RPL functions that you'll need to implement.

Regards,

Jonathan

[Orome]

(04-28-2020 05:29 PM)Jonathan Busby Wrote:  For a command line RPL environment, it would be easiest to use something like NewRPL or RPL/2, modified of course, as a basis for the command line.

Indeed, those look like the best place to start. I'll take a look at those and report back if I make any meaningful progress.

[Claudio L.]

If it helps, the newRPL command line project was resuscitated by our friend erazor, if you pull latest sources you can build it. Some things need to be updated, for example it uses standard input and output. there's currently no way to input the special Unicode characters that RPL typically needs.
It might work as-is in native utf8 environments like Linux, I don't know if Windows would handle that well. In any case, it's not hard to replace it with a better input routine that supports some keyboard assignments, etc.

[Orome]

(04-28-2020 07:02 PM)Claudio L. Wrote:  If it helps, the newRPL command line project was resuscitated by our friend erazor, if you pull latest sources you can build it.

That sounds perfect. Is there a specific link or file that you know of I should start with?

[ijabbott]

(04-28-2020 07:02 PM)Claudio L. Wrote:  If it helps, the newRPL command line project was resuscitated by our friend erazor, if you pull latest sources you can build it. Some things need to be updated, for example it uses standard input and output. there's currently no way to input the special Unicode characters that RPL typically needs.
It might work as-is in native utf8 environments like Linux, I don't know if Windows would handle that well. In any case, it's not hard to replace it with a better input routine that supports some keyboard assignments, etc.

I guess Windows would be awkward since it natively uses a UTF-16 based text I/O. Some clues from the "How to do text on Windows" section of UTF-8 Everywhere could be useful.

[Jonathan Busby]

(04-28-2020 10:41 PM)ijabbott Wrote:  I guess Windows would be awkward since it natively uses a UTF-16 based text I/O. Some clues from the "How to do text on Windows" section of UTF-8 Everywhere could be useful.

I use the ICU library when programming in C when I need to deal with Unicode, whether it be UTF-8, UTF-16 or UTF-32 ( the ICU library supports them all ).

I've found it to be very well designed, easy to use and comprehensive.

It's very widely supported and cross-platform and has been used in hundreds of different projects -- closed and open source.

EDIT #1 :

Quote:whether it be UTF-8, UTF-16 or UTF-32 ( the ICU library supports them all )

Note that the ICU library's default "UChar" datatype is UTF-16, but the ICU library supports conversion to and from all other Unicode formats.

Regards,

Jonathan

[Claudio L.]

I guess my point didn't come out as clear as I wanted. The console input code uses the standard sscanf which likely produces UTF8 directly on systems like Linux, but still there's no convenient keyboard shortcuts to the symbols that RPL needs to use. Still, if you use external keyboard macros it would work as-is.
On Windows you can use wscanf, but then you'll need to loop through the string and convert back to utf8. The ICU library uses 1.5 mb when I tried it, it's huge. NewRPL already includes a basic library to handle everything you need for utf8 conversion, so there's no need for external libraries but you still have to code that loop.
It's nearly trivial to code but still you don't get the macros with the proper symbols.
The idea would be to write a loop based on a getc() or similar keyboard input so you can assign the most commonly used RPL symbols to some keys.
I think that's the closest thing to what the OP wanted.

[Claudio L.]

(04-28-2020 07:20 PM)Orome Wrote:  

(04-28-2020 07:02 PM)Claudio L. Wrote:  If it helps, the newRPL command line project was resuscitated by our friend erazor, if you pull latest sources you can build it.

That sounds perfect. Is there a specific link or file that you know of I should start with?

The wiki has everything you need to build it.