(10-06-2019 08:55 PM)hth Wrote: [ -> ]Regarding this lower and special characters in ED.
I have added support for it, but I also rearranged the code a bit to make it shorter. However, I am not sure everything works as expected. Lower case and many obvious special characters works, I can enter them and ARCLREC then PRA it to the printer. Then there are some that I do not understand what they are supposed to be. Pi is a star burst and basically a checkered square when printed?
How to test it properly?
Because of this, I also added the lowercase patch to [MASK] - so it's all coordinated and that's a much more convenient way to test it. Also it all runs on V41, which shows the lower case on the LCD quite nicely - so no need to print them (which as you say has some quirks)...
Using your alternate OS on V41 should be possible, just replace the NUCXT.MOD with your new set of ROMs... I can prepare a new MOD file if you want, but I know you don't use windoze (with good criteria) - so can you emulate it on your system?
ÁM
(10-07-2019 05:05 AM)Ángel Martin Wrote: [ -> ]Because of this, I also added the lowercase patch to [MASK] - so it's all coordinated and that's a much more convenient way to test it. Also it all runs on V41, which shows the lower case on the LCD quite nicely - so no need to print them (which as you say has some quirks)...
Using your alternate OS on V41 should be possible, just replace the NUCXT.MOD with your new set of ROMs... I can prepare a new MOD file if you want, but I know you don't use windoze (with good criteria) - so can you emulate it on your system?
ÁM
Yes, but it does not correspond to any actual hardware, so why test it that way, wishful thinking or do I miss something?
I can certainly fix my debugger/emulator to support Halfnut characters if needed, and looking at the source indicates that it probably already does. However, I cannot change the ROMs in my Halfnuts, and I do not have any Halfnut LCD on my 41CL (and it is unlikely, if at all possible, that people have such calculators).
Maybe it is a matter of different use-cases, my interest is in using real HP-41 hardware. I am open to re-evaluating this, if the situation changes or if I am proven wrong.
It is good to know that it has "issues" when printed, as that was what I experienced. Then probably it just works as expected.
Finally, about Windows. I do not use it and I did not like it at all in the past. From Windows 8 I think they really got their act together. These days I think it looks cool and I like the user experience. The main issue for me is that I am so used to having Unix at the bottom, that it really cripples me not having it. Having Windows on top of a real Unix (much like Apple did) and I could very well consider using it. However, it costs money, and for me it provides no real value for that money.
Speaking of Microsoft, I have just switched from Emacs to VS Code (a Microsoft product) for my HP-41 debugging sessions. Neither is perfect, but VS Code annoys me a lot less these days as a debugger front-end.
(10-07-2019 04:56 PM)hth Wrote: [ -> ]Yes, but it does not correspond to any actual hardware, so why test it that way, wishful thinking or do I miss something?
I can certainly fix my debugger/emulator to support Halfnut characters if needed, and looking at the source indicates that it probably already does.
However, I cannot change the ROMs in my Halfnuts, and I do not have any Halfnut LCD on my 41CL (and it is unlikely, if at all possible, that people have such calculators).
I can use my 41CLv2 board and transfer it to a custom build machine if you want (FN-41 with a HN-LCD).
(10-07-2019 04:56 PM)hth Wrote: [ -> ]Finally, about Windows. I do not use it and I did not like it at all in the past. From Windows 8 I think they really got their act together.
I used Windows a lot professionally and personally until I got tired of spending more time managing the platform than using it.
Since then, 2005, I refused all jobs that was forcing me to use Windows, converted all existing home machines to Linux/BSD and when buying new machines, it was either Linux/BSD-on-PC or macOS-on-MacBookPro.
On rare times that I have no choice to use Windows in a VM, I always uses Windows 7, I just cannot stand the UI craziness of Windows 8.X and Windows 10, strange how perception works
Sylvain
(10-07-2019 08:10 PM)Sylvain Cote Wrote: [ -> ]I can use my 41CLv2 board and transfer it to a custom build machine if you want (FN-41 with a HN-LCD).
So it is possible to do that. Hmm, then I should probably sense if it the hardware has a Halfnut display and apply the lower-case display patch for such machines.
Quote:On rare times that I have no choice to use Windows in a VM, I always uses Windows 7, I just cannot stand the UI craziness of Windows 8.X and Windows 10, strange how perception works
Yes, I know that my perception of Windows is totally the opposite of most Windows users.
(10-07-2019 09:13 PM)hth Wrote: [ -> ] (10-07-2019 08:10 PM)Sylvain Cote Wrote: [ -> ]I can use my 41CLv2 board and transfer it to a custom build machine if you want (FN-41 with a HN-LCD).
So it is possible to do that. Hmm, then I should probably sense if it the hardware has a Halfnut display and apply the lower-case display patch for such machines.
Well, I never tried it but I can surely try!
I will not be able to have enough free time for this test until next weekend, I will update this thread after my franken-nut has been created.
Sylvain
(10-07-2019 04:56 PM)hth Wrote: [ -> ] (10-07-2019 05:05 AM)Ángel Martin Wrote: [ -> ]Because of this, I also added the lowercase patch to [MASK] - so it's all coordinated and that's a much more convenient way to test it. Also it all runs on V41, which shows the lower case on the LCD quite nicely - so no need to print them (which as you say has some quirks)...
Yes, but it does not correspond to any actual hardware, so why test it that way, wishful thinking or do I miss something?
Maybe it is a matter of different use-cases, my interest is in using real HP-41 hardware. I am open to re-evaluating this, if the situation changes or if I am proven wrong.
Well, testing on V41with patched [MASK] confirms that the [ED] patch is correct. That has a ton of value in my mind. And who knows, there may be other/new machines cappable of displaying the lower case chars soon available... time will tell.
(10-07-2019 08:10 PM)Sylvain Cote Wrote: [ -> ]On rare times that I have no choice to use Windows in a VM, I always uses Windows 7, I just cannot stand the UI craziness of Windows 8.X and Windows 10, strange how perception works
Same here. If windoze was bad before they really lost their marbles with the craziness of Win-8 and Win-10, sorry to say that for me (IMHO) they are complete trash... - maybe I'm just too old to start linking the touch-screen like U/I's and all the other "fancy" stuff, but all that constant, piece-meal updating every other day on W-10 is insufferable!
Turns out that it was not so easy to sense the Halfnut and fix the lower case characters.
The code itself is some 30 words, but there is no room for it other than in bank 5.2, and that will not work. It is a bit hard to explain, but I ran into this before. The problem is that a pushed return address is just an address, there are no bank bits being pushed. If the called routine fiddles with the bank bits (to call the 30-word slice in bank 2), it loses track of which bank it was originally called from. The result is that it may return to the wrong bank.
There are four alternatives as I see it.
1. Restructure code to make room somewhere else for it (in practise it means page 3).
2. Make two different builds, one with and one without the fix the MASK for lower case characters.
3. Assume there is a halfnut display, even though only franken-nut and emulators can make use of it, no ordinary 41CL can.
4. Forget it, at least for now.
I do not want to do (3) at least. I rather keep the star-burst character behavior we are used to when not using Halfnuts.
Sorry but I'm not sure I follow you - are these options for the [MASK] patch?
If so, it simply replaces the current code (no need for additional room), and it works for both full-nuts and half-nuts.
Therefore I see no need for two different builds.
I'd leave the starburst chars alone in Full-nuts, that's a hardware limitation.
(10-08-2019 08:51 AM)Ángel Martin Wrote: [ -> ]Sorry but I'm not sure I follow you - are these options for the [MASK] patch?
If so, it simply replaces the current code (no need for additional room), and it works for both full-nuts and half-nuts.
Therefore I see no need for two different builds.
I'd leave the starburst chars alone in Full-nuts, that's a hardware limitation.
I am under the impression that it is the MASK routine that introduces the starburst characters when there is no suitable alternative:
Code:
MASK20: cxisa ; load 1 char from table
?a#c x ; match a special char ?
gonc MASK30 ; yes
c=c+1 pt ; point to next word
gonc MASK20 ; go on !
ldi 0x3a ; all segment if not found
goto MASKRT
I tried to change it as suggested on my 41CL, but it does work so well. The existing lower case characters (a-e) stop working in alpha register and all lower case characters are replaced by a space.
To anyone that are beta testing, here is a link to an XFUNS5 image that contains a patch for entering lower-case and special characters in ED:
https://drive.google.com/open?id=1oqVfFL...wfavjaqfBy
Checksum: ff4c5c2a
(Lower-case characters apart from a-e are still displayed as boxed stars)
How is the beta test going? I have an hp41 coming in a few weeks which will be converted to a CL and am interested in trying this. I plan on setting this one up for surveying calculations (and GPS when Monte gets that module sorted). I love the idea of so much extended memory to store points in. I will have to check if the software which stores to Xmemory is compatible with this but am sure I can make one of the programs work with this.
(10-19-2019 01:53 AM)Ken S Wrote: [ -> ]How is the beta test going? I have an hp41 coming in a few weeks which will be converted to a CL and am interested in trying this. I plan on setting this one up for surveying calculations (and GPS when Monte gets that module sorted). I love the idea of so much extended memory to store points in. I will have to check if the software which stores to Xmemory is compatible with this but am sure I can make one of the programs work with this.
I have not heard so much. I think it is known by now that it will not work with CCD and modules that borrow code from it for accessing extended memory. I have also seen some issues with running from RAM, which is why I flashed it as soon as I trusted it. Meaning, when my automated tests worked and I could use the calculator normally with no noticeable issues.
I have not done any particular X-memory tests recently, but I do use the beta ROMs. It is mostly for testing other coming modules (doing normal things and playing with other half broken code).
In any case, it sounds like you could be a good beta tester of it?
Sounds good, once I get the donor calculator in and build the 41CL I will give it a try. Any idea if this will work on the upcoming DM41X?
(10-22-2019 02:53 AM)Ken S Wrote: [ -> ]Sounds good, once I get the donor calculator in and build the 41CL I will give it a try. Any idea if this will work on the upcoming DM41X?
Let me know when you are ready.
I have no idea if it will work on the DM41X. It depends on whether it has RAM in the address range 400-EFF (the upper page limit is configurable at build time), and without the gaps that exist in RAM page 2 and 3.
Long time and no update to this. I just found a very minor problem with corrected XROM XKD mechanism that will warrant a correction.
I also fixed the "FOO IND L" bug where FOO is an XROM, as mentioned here
https://www.hpmuseum.org/forum/thread-13...#pid123124
which means two issues.
Anyone has comments on the larger extended memory?
(12-24-2019 06:05 AM)hth Wrote: [ -> ]Long time and no update to this. I just found a very minor problem with corrected XROM XKD mechanism that will warrant a correction.
I also fixed the "FOO IND L" bug where FOO is an XROM, as mentioned here https://www.hpmuseum.org/forum/thread-13...#pid123124
which means two issues.
Anyone has comments on the larger extended memory?
Do I have this yet? I'm getting ready to do a monthly update.
(12-24-2019 06:05 AM)hth Wrote: [ -> ]Anyone has comments on the larger extended memory?
Finally some free time to test this.
Test machine is a 41CLv2 and I have not updated to the latest OS ROMs yet.
AUTOSTART module is mapped and the following program is executed at each power on
Code:
LBL "RECOVER"
MAPEN
END
I have successfully executed the following program that creates a data file using all extended memory available, then sequentially write and read from that file.
Program logic:
Code:
A: Initialisation
B: Deleting data file
C: Creating data file
D: Writing to data file
E: Reading from data file and do data validation
F: More data validation
G: Status: show progress (subroutine)
H: Error: data read is not equal to data written (error exit point)
I: Error: no registers left to create data file (error exit point)
J: Exit: display message and do some cleanup (gobal exit point)
Program listing:
Code:
01◆LBL "TSEM" // Test Super-Extended Memory
02 RCLFLAG // A:
03 STO 03 // A: get flags 00 to 43 and store it to REG 03
04 FIX 0 // A: display setting: no decimal digits
05 CF 29 // A: display setting: no decimal point
06 "TSEM" // A:
07 ASTO 02 // A: store data file name to REG 02
08 SF 25 // B: handle missing file error, deactivate error report
09 PURFL // B: purge file, clesr flag 25 if it does not exist
10 CF 25 // B: reeactivate error report
11 EMROOM // C: get how much memory is left to work with for this test
12 2 // C: file header size
13 - // C: get number of data records by substracting file header
14 X<=0? // C: do we have some data records memory left ?
15 GTO 13 // C: no we do not, display error message
16 STO 00 // C: store number of data records to REG 00
17 CRFLD // C: create file data "TSEM"
18 "WRITING" // D:
19 AVIEW // D: display upcoming action
20 SF 25 // D: setup ignore error for when the file will be full
21 . // D: init counter
22◆LBL 00 // D: write loop
23 1 // D:
24 + // D: counter = counter + 1
25 SAVEX // D: write value to data file
26 "W:" // D:
27 XEQ 11 // D: show progress
28 FS? 25 // D: have we reached the end of file ?
29 GTO 00 // D: no we have not, go write another number
30 1 // D:
31 - // D: counter = counter - 1, because last SAVEX failed
32 STO 01 // D: store biggest number saved to REG 01
33 "W:" // D:
34 ARCL X // D:
35 AVIEW // D: show last number written
36 PSE // D: give user time to see it
37 "READING" // E:
38 AVIEW // E: display upcoming action
39 CLA // E: recall data file name from REG 02
40 ARCL 02 // E:
41 . // E: data file index value & init counter
42 SEEKPTA // E: reset data pointer to the file beginning
43 SF 25 // E: setup ignore error for when we reached the end of file
44◆LBL 01 // E: read back loop
45 1 // E:
46 + // E: counter = counter + 1
47 GETX // E: read value from data file
48 FC? 25 // E: have we reached the end of file ?
49 GTO 02 // E: yes we did, go to next step
50 X≠Y? // E: is value read back is equal to what was stored ?
51 GTO 12 // E: no, display error message
52 RDN // E: restore stack
53 "R:" // E:
54 XEQ 11 // E: show progress
55 GTO 01 // E: go read another number
56◆LBL 02 // E: all data has been read
57 RDN // E: restore stack
58 "R:" // E:
59 ARCL X // E:
60 AVIEW // E: show last number read
61 PSE // E:
62 RCL 00 // F: recall number of data records
63 X≠Y? // F: is total number of values match ?
64 GTO 12 // F: no, display error message
65 RDN // F: restore stack
66 RCL 01 // F: recall biggest number saved
67 X≠Y? // F: is both number match ?
68 GTO 12 // F: no, display error message
69 "SUCCES" // F: success message
70 GTO 14 // F: goto global exit point
71◆LBL 11 // G: display X at each hundred number
72 ENTER↑ // G: copy X in Y
73 ENTER↑ // G: copy X, Y & Z
74 100 // G: overwrite X with 100
75 MOD // G: Y modulo 100
76 X=0? // G: do we have a number to show ?
77 ARCL Y // G: yes we do
78 X=0? // G: do we have a number to show ?
79 AVIEW // G: yes we do
80 RDN // G: clean up stack, or whats left of it
81 RTN // G: return to caller routine
82◆LBL 12 // H: data read error handler
83 "DATA NOT EQ" // H: error message
84 GTO 14 // H: goto exit point
85◆LBL 13 // I: error handler
86 "X-MEM FULL" // I: data file space error message
87 GTO 14 // I: goto exit point
88◆LBL 14 // J: exit point
89 AVIEW // J: show message
90 RCL 03 // J: recall original flags (00 to 43)
91 STOFLAG // J: restore flags
92 END // J: program end
Note 1: no optimisation has been done in the above program, clarity was chosen over compactness or speed.
Note 2: turbo 50 was set before running the program.
Program output:
Code:
WRITING
W:100
W:200
...
W:3300
W:3400
W:3403
READING
R:100
R:200
...
R:3300
R:3400
R:3403
SUCCESS
Messages:
Code:
SUCCESS // all tests were successfully passed
X-MEM FULL // if there is less than 3 extended memory registers left
DATA NOT EQ // if data read is different than data written
CAT 4
(12-27-2019 02:04 AM)Monte Dalrymple Wrote: [ -> ] (12-24-2019 06:05 AM)hth Wrote: [ -> ]Long time and no update to this. I just found a very minor problem with corrected XROM XKD mechanism that will warrant a correction.
I also fixed the "FOO IND L" bug where FOO is an XROM, as mentioned here https://www.hpmuseum.org/forum/thread-13...#pid123124
which means two issues.
Anyone has comments on the larger extended memory?
Do I have this yet? I'm getting ready to do a monthly update.
I need to update it and make new images, fixing the two issues I have already. I think you can include it in some future update, but not this one.