DM15L programming

Forum for discussion of the DM10, DM11, DM12, DM15, DM16 and DM41 units
User avatar
Walter
Posts: 3070
Joined: Tue May 02, 2017 11:13 am
Location: On a mission close to DRS, Germany

Re: DM15L programming

Post by Walter »

DE GVSTIBVS NON EST DISPVTANDVM.

Feel free to prefer what you prefer - I just wanted to point out what could be done to satisfy the OP.

BTW, the 43S will display function names instead of keycodes since I think the latter paradigm is simply outdated. YMMV, of course.
WP43 SN00000, 34S, and 31S for obvious reasons; HP-35, 45, ..., 35S, 15CE, DM16L S/N# 00093, DM42β SN:00041
michel_b
Posts: 34
Joined: Wed Jan 30, 2019 10:07 pm

Re: DM15L programming

Post by michel_b »

Hi,

What the 43s will display is completely out of the topic, being a completely different calculator with a program (currently being) written from scratch.

The 43s will not be an *exact* replica of an existing HP model, and will not run an original HP firmware - such as the DM42 is running the “free42” program and not an original HP-42s firmware. It is for this very reason that the DM42 can have a larger and richer display compared to a genuine HP-42s.

You seem not to realize that the DM-1x series are on the other hand running an *ORIGINAL* HP-1x firmware that the SwissMicros team has dumped from original HP calculators. Which means that they most probably don't have any source code for it, which means that any modification would require quite a lot of reverse engineering, which is definitely not trivial.

SwissMicro wrote the code for the hardware emulator (the virtualization layer if you prefer) but didn't write the code for the virtual machine inside, which is the original HP code.

It seems to me that you are still completely missing the point, which is not if it would be “better” in the absolute that the DM-15 would display operation names rather than key codes, but the point is articulated on 3 facts :

- The DM-1x series intent is to EXACTLY replicate a given HP-model which is 35 years old. “Exactly” means... Uh. Exactly.
- The DM-1x series run original HP model's firmware (embedded in a hardware emulation layer) and this original firmware shouldn't be modified and couldn't without extreme efforts (reverse engineering, risk of introducing new bugs...) and nothing such is in the original project.

Kind regards.
Boub65
Posts: 231
Joined: Tue Sep 12, 2017 4:34 pm
Location: Rabat, Morocco

Re: DM15L programming

Post by Boub65 »

I'm sorry but it's not exaclty a replica...
- we have bugs corrected
- we have extended memory (do we?)
- we have rtc
- we have USB computer exchange
- and we even have multi fonts!!!

So why would mutli fonts (aka display improvments) be accepted and welcomed and translation of num codes to op code (aka display improvments also) refused.

This would not change the rom/emulator but just the display firmware.
One can always keep the num code mode and let us use an opcode mode. One mode for each one of us.

My 0.02c also..

PS: I'm sure that a opcode display in DM1x would increase sales...
Sincèrement, Sincerely, 73,
Boubker

DM15L, DM41L, DM42 #00855 (domes upgraded), DM41X #00707
HP48SX (with dark screen), HP42s, HP32SII (1990 with fraction bug), HP41C/CV
TI-89 titanium, CASIO fx-cg50 and Numworks (to play with micropython)
User avatar
Walter
Posts: 3070
Joined: Tue May 02, 2017 11:13 am
Location: On a mission close to DRS, Germany

Re: DM15L programming

Post by Walter »

Michel,

Merci pour votre response. Please note by remark about the 43S was just "BTW". Regarding the DM1xL, I concur with Boub65. In each DM1xL, AFAICS we have an HP-1xC "kernel" and at least one layer above dealing with the (completely different) display. As the kernel 'outputs' numeric results and the layer transforms them to patterns displayed in the dot matrix, the "kernel" also sends keycodes to be displayed - and instead of showing them as keycodes on the dot matrix you could translate them to something more user friendly (more readable), e.g. a function mnemonic. But this was meant just as food for thoughts as mentioned above already - nobody forces you to think this way if you want to stay with keycodes for these models.

My last statement in this matter. YMMV. Best regards.
WP43 SN00000, 34S, and 31S for obvious reasons; HP-35, 45, ..., 35S, 15CE, DM16L S/N# 00093, DM42β SN:00041
michel_b
Posts: 34
Joined: Wed Jan 30, 2019 10:07 pm

Re: DM15L programming

Post by michel_b »

Again,

- I'm not aware of “bugs fixed” in the DM-15 compared to the original HP-15c. Maybe you have examples ?
- Extended memory may probably be a couple of bytes flipped in the firmware to set the memory boundaries. Not a big change on what the FW actually does.
- The RTC is outside of the calculator's knowledge (it's part of the emulator and the emulated calculator doesn't see it at all). To the point that the RTC hardware is broken on current DM-15 boards and the calculator doesn't give a damn. You can''t do anything with it except for displaying time... in a mode where the calculator isn't running.
- Same for USB. It can load or dump the calculator's memory from the emulator, at a time when the calculator's code is *not* running.
- About multi-fonts, again, it's an emulation feature : the emulator translates a 7 segment numerical output into a matrix display. It's done at the emulators' level and the calculator's FW is unaware of it. And it's a one-to-one translation : One 7-segment char translates to its corresponding pixmap according to the selected fond. That's a purely mechanical translation : the emulator doesn't need to know anything about the characters meaning. A 6 translates to another form of 6, thar's all.

For what you want, supposed you don't want to touch the calculator's HP FW, the emulator would have to know in which mode the calculator is (P/R) and interpret the meaning of the output for translating it. That's far, far beyond a 1-to-1 character translation. That would take many cycles, seriously slow down the damn thing, and be very bug-prone.

Basically SwissMicros could produce the complete Voyager Series - DM-10, 11, 12, 15, 16 - because they all use the same hardware and surely the same emulator. So to give one "model" or another, they just need a different keyboard labels printout, and the same emulator firmware loaded with the original HP calculator firmware - slightly modified for RAM size for example.

What you ask for is completely different. It would involve developing a very specific firmware emulator for the DM-15, which would be a bad idea as it would break the emulation layers model, OR seriously modifying the original HP FW, which is surely out of the question.

Now, I'm not part of SwissMicros team and unaware of their projects - event though it is blatant that they are surely now concentrating more on the new DM4x product line. So I don't have any specific information from them, but I can only tell you the technical and engineering reasons why what you ask for will most probably never happen.

Then, you can keep asking for it as much as you want, but I'm pretty sure it's a damn loss of time.

My last 2¢ ;)
Boub65
Posts: 231
Joined: Tue Sep 12, 2017 4:34 pm
Location: Rabat, Morocco

Re: DM15L programming

Post by Boub65 »

michel_b wrote:
Sun Feb 03, 2019 5:01 pm
Then, you can keep asking for it as much as you want, but I'm pretty sure it's a damn loss of time.
When I started my career in software developement in 1989 (developping CADCAM software using fortran77 on MVS mainframe) we didn't have online forums but what we called "Users Groups Meetings" where the customers physically met, exchanged and asked for enhancements to the software companies (and bug corrections also) And we, software companies, took into account our customers requests. We even had a formal process to reply (yes, no, maybe) to ANY request from our customers.

I hope that we didn't loose something going from these "User Groups Meetings" to an online forum...

Or did we?

It will be also my last statement on this matter...
Sincèrement, Sincerely, 73,
Boubker

DM15L, DM41L, DM42 #00855 (domes upgraded), DM41X #00707
HP48SX (with dark screen), HP42s, HP32SII (1990 with fraction bug), HP41C/CV
TI-89 titanium, CASIO fx-cg50 and Numworks (to play with micropython)
Dave Britten
Posts: 137
Joined: Wed Jun 14, 2017 9:27 pm

Re: DM15L programming

Post by Dave Britten »

It doesn't strike me as a feature that would be super difficult to add. Simply modify the simulator's display routine to snoop on whatever flag/register/memory address is used internally by the calculator to indicate that it's in program mode (or that SST is being held), and use an alternative display routine that parses the display contents and shows instruction mnemonics instead. It could be an optional feature, toggled with an On-key combination, like the CPU speed or font.
michaelzinn
Posts: 41
Joined: Tue Apr 10, 2018 11:34 pm

Re: DM15L programming

Post by michaelzinn »

Personally, I don't need this, but you could detect program mode by checking that the display shows three digits followed by a hyphen.
Probably not worth it, though, given that people who want readable calculator code can just buy a better calculator instead.
dlachieze
Posts: 613
Joined: Thu May 04, 2017 12:20 pm
Location: France

Re: DM15L programming

Post by dlachieze »

Dave Britten wrote:
Wed Feb 13, 2019 5:01 pm
It doesn't strike me as a feature that would be super difficult to add. Simply modify the simulator's display routine to snoop on whatever flag/register/memory address is used internally by the calculator to indicate that it's in program mode (or that SST is being held), and use an alternative display routine that parses the display contents and shows instruction mnemonics instead. It could be an optional feature, toggled with an On-key combination, like the CPU speed or font.
This is exactly what's done by go15c on Android when the Prog Helper option is turned on.

Image
DM42: 00425 - DM41X: β00066 - WP43: 00042
Post Reply