OPL Challenge

Feel free to discuss any Organiser II related topic here
hawsey
Posts: 42
Joined: Fri Jul 02, 2021 12:34 am

Re: OPL Challenge

Post by hawsey »

So considering the above, is it possible to make a selection which will stay in place until the next time you want to change.
Typically you might operate on 2 Meters at 25W on FM for a number of contacts before you wish to change mode of operation to say 20 Meters at 50W on SSB.
So everything might be the same for say 20 contacts.
The call sign and signal strength will change on every contact.
User avatar
MartinReid
Posts: 97
Joined: Wed Jan 27, 2021 3:44 pm

FromLst:() in HamLog

Post by MartinReid »

Good stuff...

Yes once chosen a value becomes the default and can be kept until you choose something different.. I'll need you to give me the 'categories' that can be 'predicted' and what 'choices' would be on the list?

Code: Select all

Frequency       Mode		etc...
3.525		CW
3.800		RTTY
7.025		Data
7,175		etc..
etc..
then yes I'll need to put it on a pack...

Martin

PS if you have any more thoughts or requests don't hesitate to ask... I can only say no..
hawsey
Posts: 42
Joined: Fri Jul 02, 2021 12:34 am

Re: OPL Challenge

Post by hawsey »

Hi Martin,
Are choices required or could those values just be added by the user?
For modes there are multitudes and if the user just input their own it would be easier examples SSB, FM, DV, DMR, PSK 31, RTTY, FT8, AM, FT8 CW
Also similar for power, you could input anything from 100mw to 500 Watts.
The above two fields would generally stay the same for a few contacts before wishing to change.
Thanks
User avatar
MartinReid
Posts: 97
Joined: Wed Jan 27, 2021 3:44 pm

HamLog FromLst:() function lists

Post by MartinReid »

Gary..

Yes choices can be added by the user and will be preserved as the 'default' until a new value is chosen. These choices are not automatically added to the file, but if they are 'popular' they can be added by the user in xfiles. I've created these three lists as a starting point but would appreciate your thoughts.

Code: Select all

Frequency		Mode		Power
HLhtxLst.odb		HLmdeLst.odb	HLpwrLst.odb	
135kHz LF		CW		1   W
472kHz LF		SSB		10  W
1.8MHz MF		eSSB		32  W
3.5MHz HF		PSK31		40  W
5  MHz HF		AM		50  W
7  MHz HF		FM		100 W
10 MHz HF		RTTY		160 W
14 MHz HF		PSK		400 W
18 MHz HF		MT63			
21 MHz HF		LSB			
24 MHz HF		USB			
28 MHz HF		MGM			
50 MHz VHF		AMTOR			
70 MHz VHF						
144MHz VHF	
432MHz VHF	
I'll adjust these 'lists' after your comments and then I'm ready to send you an updated pack.
Martin
User avatar
Lostgallifreyan
Posts: 27
Joined: Fri Jun 11, 2021 2:52 pm

Re: OPL Challenge

Post by Lostgallifreyan »

Martin, instead of PRINT, it may work better if the system service ED$EPOS allows it. Jaap's machine code reference says this: "In single-line editing, the up and down keys move the cursor to the start and end of the line (unless otherwise specified on the LZ organiser)."

I'm not sure if that means the Up/Down arrow keys can be set to leave an edit and select a new string or field to edit, but if it does, then the service will make a better access to list strings longer than 14 chars, and also ease the method of accepting user edits to list entries (always accept input, compare with existing, if same, it's a choice, if different, it's a new entry to be chosen and stored). This service also lets you put the cursor where you want it at the start of an edit.

The EditFile procedure in my EVENT posting has some code to help with context for using the service (but it uses ED$EDIT, which is a simpler form that calls the other one, and ED$EDIT doesn't let us set cursor position). The calling method and setup will be very similar.

If it is possible to disable the Up/Down keys then it may be possible to handle them with TRAP or some other error catcher so you can handle them directly, in which case it may be possible to make a 'listbox' type control that is equally compatible with the XP organisers as well as the LZ. The trick is to explore how many existing subsystems will help, so you don't have to either reinvent them all, or be limited only to what OPL gives.

EDIT:
Assuming the above will work, then given that exit can be ON,ON with first ON clearing the edit field, then you can use ON,EXE to commit an empty string for a selected choice, so you can interpret that as 'delete' and handle it appropriately. Not required, but it's a neat way to do it, and a good alternative to using a dedicated key choice added to the loop of existing choices. It's fairly safe because ON,EXE is sufficiently difficult to press by accident so you don't need an annoying confirmation prompt.
Last edited by Lostgallifreyan on Wed Oct 20, 2021 7:40 am, edited 3 times in total.
User avatar
Lostgallifreyan
Posts: 27
Joined: Fri Jun 11, 2021 2:52 pm

Re: OPL Challenge

Post by Lostgallifreyan »

Extra:

"ED$EDIT / ED$EPOS
If bit 1 of A register is set, then the edit will exit if an UP or DOWN arrow key is pressed."

(From an LZ-specific bit in Jaap's documentation for system services.)

That means calling the service in a key-test loop is ideal for a 'listbox' type control, and may have been an early prototype of that same method.

The problem is it's no good for the XP. In that case it may be impossible without raw machine coding unless the Up/Down keys can be coerced (or remapped) to have values that the XP service construes as an error, in which case you may then handle the error to get the result you want.

EDIT:
Not tried this, but suppose you map both UP and DOWN to ON, then you get your exit. Now, if you examine the actual last keypress as raw code, you can know which arrow it was and act accordingly. I can't remember which of the 'zero-page' addresses stores those details but it's there somewhere.
User avatar
MartinReid
Posts: 97
Joined: Wed Jan 27, 2021 3:44 pm

System Service - SORTING

Post by MartinReid »

Lostgallifreyan

There is a lot to digest in this and in your other posts, so thank you for your time and I'll take my time to work through what you have put..

in the mean time..

(1) ON EXE when Entering or Editing a string ... Yes I agree I've got this as a choice for...
If the default is a null string "" then Enter new string :ELSE (move cursor to end) and TRAP EDIT default string..

ON ON returns the default
EXE ditto
ON EXE returns null string
ON (clears the screen) Enter a new string ... EXE

(2) Making 'FromLst$:()' compatible with XP OPL!
I gave up on this, I did consider MartinP's suggestion of using MENUN. By creating a string from the list of choices and then passing this list to m%=MENU which is machine independent. This would give me the horizontal scrolling 'list' that would work on all variants... I gave up... and took the easy option of using some LZ specific screen handling and the up down list as demonstrated.... At the moment there is only me using it and if anyone else wants to try something then I can return to it another day...

I have found that to keep it 'quick' the routine FromLst$:() and the database 'lists' want to be the first things on the pack (after the boot code), HamLog is full of all kinds of stuff now .... Morse Code Tutor, ITU Callsign checking, Help notepads etc..

(3) I can't use ED$EDIT or ED$EPOS... I don't have the knowledge (or skill)

(4) SORTING.... All my databases have the first field as a No% or No$ (like an index) sort field. I got it early on in the 1980's that the safest way to 'edit' a database on the organiser when the record order is important was to create a field with a unique (uneditable - I think I've just invented a word) sequential list so the records can be automatically resorted after an edit. I have a bubble sort that I've used since then but it is rather slow on a 'large' file. That's why I though of a system call because if I use SORT on XFILES it is quicker but I can't write this into my programme. So with this 'indexed' No% or No$ first field in mind.. what are your thoughts on calling the XF$SORT to sort the file! Could you show me some sample code I can try to get my head around.

Anyway thanks again for your thoughts
Always sincere
Martin
User avatar
Lostgallifreyan
Posts: 27
Joined: Fri Jun 11, 2021 2:52 pm

Re: OPL Challenge

Post by Lostgallifreyan »

The fastest way to get at machine code calls to system services is by example so my EVENT post's procedure called EditFile is one example. Looking at Jaap's TSR programs for keys and Y2K fix are also good to see how OPL and machine code can link easily by use of arrays.

It's worth stopping to play with these notions because the time spent will easily be saved later. When I write C programs I have to stop to explore MIDI, or making bitmap fonts, even having to make dedicated tools just to accelerate production and tests of new resources. It bothers me at times but I learned to just get into it because I always come out the other side better off for that. I usually end up thinking I should have done whatever-it-was years ago!

There's no doubt that basic OPL often works just as well in many cases, but knowing a bit of machine code and service calls can help even if just to make a decision about that.

About ON and EXE, it can get confusing, so I try to think of ON and EXE in these situations as like ESC and OK on a messagebox in Windows. It helps make program flow and user operation easier, less need for confirmation prompts.. If I find some use conflicting with this basic notion I try to work out a way for it not to do that.

Re XP compatibility, I understand. I try to work with the oldest decent precedent to get widest compatibility (ORG-Link will work on any system from quarter of a century of computer development) but it's a big decision to stay with the kinds of systems that make that approach universal. Sometimes it's more practical to use a late system if it offers enough that early ones don't, and the loss of compatibility is worth it.

EDIT:
I like your note about speed and things being on the start end of large packs. When I code realtime audio and MIDI and comms code, I check for performance a lot. No fancy benchmarks, no 'profilers'. I just use the thing, see if it works as well as I know it ought. The proof of the pudding.....
User avatar
Lostgallifreyan
Posts: 27
Joined: Fri Jun 11, 2021 2:52 pm

Re: OPL Challenge

Post by Lostgallifreyan »

Martin, I found some notes I made on machine code and service calls, and the first part of those is posted below in the 'code' block. It's no substitute for a proper guide but it's what I wrote when in the same position you're in now, when I needed a condensed form that told me the most vital stuff.

The two examples don't do much but they're safe to use, and the form they take will be similar for any service the system offers, as is the way that OPL sets them up and calls them. More useful will be the preamble that describes registers. There is no mention of the stack though, but these two examples will be good enough to start with.

Reading Jaap's pages on machine code reference will cover most if not all you'll need to know. I found those notes more useful than a long guide, because they make it easy to pick something that looks useful and try it. The stuff here, below, will help you make them work with OPL.

Code: Select all

Operating system services are machine code programs stored in ROM. Many are accessed by OPL commands and functions, but many of the best ones are not.
All system service calls begin with instruction SWI, 'software interrupt', hex byte $3F, immediately followed by a byte indexing the required service.
The next byte is where the program resumes when the system service has finished. This is usually RTS, 'return from subroutine', hex byte $39, in this
case return to OPL because an OPL function USR (or USR$) is used to call the machine code that calls the service. (Note that these are functions, they
pass data back to the program, but commands do not, they only direct a specific action).

Most services need parameters to define the context for their use. There are registers called A, B and X which are usually enough to pass information
to a service, with six 'scratch registers' UTW_S0 to UTW_S5, at address range $41-$4C as extra locations. Larger data can be placed in the 'runtime
buffer' RTT_BF, a 'leading byte-count string' at address range $2188-$2287 with length byte RTT_BL at $2187. System services may use these locations
to pass data out as well as in. A register should be assumed destroyed unless the service specifically uses it to pass back data.

An error sets its code in register B and sets the 'carry' flag, which may hold a previous state, so test it only after a service that uses it.

The OPL function USR calls machine code at the address given in the first of two arguments, and passes an integer into the D register with the other.
The D register is a word, and the A and B byte registers are passed as D, in the form A*256+B. The service context determines which scheme is valid.
The X register is also a word, and must contain the output to be passed back to OPL from the USR function. (USR$ passes the address to a string.)

==========================================================================================================================================================

013 0D  BZ$ALRM
INPUT:  None.
OUTPUT: None.
        D,X=trashed
        UTW_Sx=preserved
DESCRIPTION
        Gives the noise used by ALARM. Note that keyboard interrupts are disabled temporarily.
EXAMPLE:
        SWI     BZ$ALRM
ERRORS: None.

ALARM:
LOCAL C%(2)
C%(1)=$3F0D :rem  SWI BZ$ALRM
C%(2)=$3900 :rem  RTS (back to OPL)
USR(ADDR(C%),0)

==========================================================================================================================================================

118 76  UT$SMUL
INPUT:  D=Signed integer
        X=Signed integer
OUTPUT: D=High bytes of 4-byte signed product.
        X=Low bytes of 4-byte signed product.
DESCRIPTION:
        2-byte by 2-byte signed integer multiply routine.  Multiplies  D  by  X
        putting  the  product  back into D and X.  The more significant word of
        the product goes into D.
EXAMPLE:
        LDX     SIGNED_MULTIPLIER
        LDD     SIGNED_MULTIPLICAND
        SWI     UT$SMUL
        TST     A               ; test the most significant byte
        BMI     NEGATIVE_PRODUCT
ERRORS: None.

MULTIPLY:
LOCAL C%(5)
C%(1)=$0000 :rem  Input for D register
C%(2)=$01CE :rem  NOP,LDX
C%(3)=$0000 :rem  Input for X register
C%(4)=$3F76 :rem  SWI UT$SMUL
C%(5)=$3900 :rem  RTS (back to OPL)
INPUT C%(1)
INPUT C%(3)
PRINT USR(ADDR(C%())+2,C%(1))
GET

------------------------------------------------------------------------------

Note: Don't confuse UT$SMUL (or UT$UMUL or MT$FMUL) with the basic instruction MUL, as used below.

MULTIPLY:
LOCAL C%(2),M%,N%
C%(1)=$3D18
C%(2)=$3900
INPUT M%
INPUT N%
PRINT USR(ADDR(C%()),M%*256+N%)
GET

==========================================================================================================================================================
hawsey
Posts: 42
Joined: Fri Jul 02, 2021 12:34 am

Re: HamLog FromLst:() function lists

Post by hawsey »

MartinReid wrote: Sun Oct 17, 2021 12:48 pm Gary..

Yes choices can be added by the user and will be preserved as the 'default' until a new value is chosen. These choices are not automatically added to the file, but if they are 'popular' they can be added by the user in xfiles. I've created these three lists as a starting point but would appreciate your thoughts.

Code: Select all

Frequency		Mode		Power
HLhtxLst.odb		HLmdeLst.odb	HLpwrLst.odb	
135kHz LF		CW		1   W
472kHz LF		SSB		10  W
1.8MHz MF		eSSB		32  W
3.5MHz HF		PSK31		40  W
5  MHz HF		AM		50  W
7  MHz HF		FM		100 W
10 MHz HF		RTTY		160 W
14 MHz HF		PSK		400 W
18 MHz HF		MT63			
21 MHz HF		LSB			
24 MHz HF		USB			
28 MHz HF		MGM			
50 MHz VHF		AMTOR			
70 MHz VHF						
144MHz VHF	
432MHz VHF	
I'll adjust these 'lists' after your comments and then I'm ready to send you an updated pack.
Martin
Martin

Apologies for the delay would each field be able to be set permanent until changed by the user? Also Is there a need to have set values for the power, could it not just be set until changed?
Different Modes are always being released so that would be best, so you would just input your desired mode, your frequency and your power and that would be set until you changed it, the value just set by the user and could be anything.

Regards

Gary
Post Reply