Forum

Hello,
after a break, I came back to the PC-1500 assembler, and I encountered a problem with the .CHECKSUM directive.
For the tests, I used lhasm version 0.7.8.

In my program, the .CHECKSUM directive works fine with no argument.
Now I'd like to change it so that it starts the calculation from a certain label, e.g.: But the label is interpreted as "code", i.e. the first optional argument, and I am not able to convince the compiler it should handle it as the start address. I also tried to use a variable (like %00s) instead of the label name, but there was no difference.

If I put a dummy code as an argument, the directive works fine: There is nothing wrong with this workaround, but I wonder, is there a way to do it without the dummy code...?
Thanks for any ideas.

According to the Technical Reference Manual, there are two ways how a number can be stored in R0 (or other arithmetic register). First, there is the "standard" floating point BCD representation, and second, there is the binary representation (which uses just part of the register - 1 Byte flag and 2 Bytes value).

However, the binary representation cannot be used with the arithmetic ROM routines (like SBR(F0) - addition).
What is the easiest way to convert the number in R0 from binary format to FP BCD format? Is there a subroutine for this purpose?

I tried to normalize the binary number by SBR (E8), but it does not perform the conversion.
Thanks for help.

I have one more observation to the behaviour of the .EQU directive.
As mentioned in an earlier post, in lhasm ver. 0.7.8, this works correctly: (There shall be no prefixes like &, #, @, but it is another issue, not relevant to this post.)
However, just changing the name of the symbol, the evaluation fails: Very likely it is related to the fact the symbol name begins with a letter that can be interpreted as a hexadecimal digit...

I understand it is not worth to change this in 0.7.x, but I thought I'd rather post this problem so that it can be checked if it persists in the oncoming version 0.8.0.

Thanks for an interesting background information!

Backwards compatibility is always a difficult thing to handle and usually there is no flawless solution. But I agree it is important to keep it so that older source codes can be compiled. There are several ways how to cope with it, but they have their disadvantages too. Looking at the other projects I've seen, I can think of two "workarounds":
- The program uses some kind of parameter (a "compiler directive") that allows to switch between "old" and "new" rules. In fact, there have to be two programs in one.
- The program is no more compatible with older input data, but there is a separate tool (a "pre-processor") that allows conversion of the old data into the new format. Then the program as such is simplified, but extra effort to develop the tool is needed.

But these are just my thoughts on the "backward compatibility" topic; it's clear that for a project like this, the least demanding solution has to be chosen and all the "nice to have" things have to go aside.

In the first time of the evaluator, only hexadecimal values, symbols and variables were allowed. Hexadecimal value must have a length that must be a multiple of 2, that is: 3, and 003 are invalid but 03 and 0003 are valid.

Actually, this requirement is documented in the manual, so what is surprising is the fact that it is not required in an expression like [+3].

You call the evaluator the most obscure part of lhasm, but it still does a great job!

I did some testing of the new version of lhasm (ver. 0.7.8 ) and I can confirm it corrects the issues I reported in my first post, namely the points 2, 3, 4 and 7. Thanks a lot for a good job!

I am a bit in doubts as to if I should go into more detail with my observations. It's because while the corrected issues could have some practical impact and are improving the comfort for the programmer, the others are rather nitpicking and won't probably bring much effect even if improved...

Well, I give the basic idea, but really, this is nothing that limits the work with lhasm. I don't want to be ungrateful, lhTools are wonderful utilities and these small things cannot spoil the good impression about them.

The matter is there are several contexts in which the assembler expects a value. I've identified these different cases (there can be even more):

1. .ORIGIN directive
2. .EQU directive
3. 8-bit immediate value like in LDA n
4. 16-bit immediate value like in LD SP,mn
5. displacement like in JR d
6. absolute address in JP ab

These values could be (theoretically) formed by a numeric constant, expression, symbol, variable or by a combination of these. Of course, there can be intentional limitations (e.g. .ORIGIN could accept only a numeric constant), but somehow I would expect that the evaluation of the "value" (in any form) would be the same all the time.

However it seems the assembler uses different routines to evaluate the value in different contexts. As a result, the same expression is accepted in one context, but refused in another.
Below are several examples.

Example 1: Using decimal value in expression Example 2: Using (not) leading zero(s) A special case are the values accepted for .ORIGIN directive: ...which differs from other use cases.

I can do more testing if required, but again, I want to stress this is nothing important, and I would not come across these things if it wouldn't be for the previous discussion and the new version's testing. I suppose the observed behaviour has historical reasons and it would be probably difficult - and very likely not worth - to unify it for various context cases...

So thanks again for your work!

Thanks a lot! I've downloaded the new version and will give it a try.

Concerning the .EQU topic:

This depends of your context. A symbol must be defined witth a non ambigous immediate value during the pass 1, and must not differ between the two passes. So
The following works:

Code : Tout sélectionner

	.ORIGIN: 40C5
	.CODE
VAR1	.EQU &1234
VAR2	.EQU VAR1
	CALL VAR2
	RET
	.END

You are right, it was my mistake during the tests.

But it looks like defining a symbol with an expression containing a symbol is not working correctly and the value is wrong...

That's what probably caused confusion during my tests. I tried and because the third line caused an error "Badly formed parameter", I didn't notice the line 2 compiled correctly in this case.

Here, you must use a variable to have the code assembled.

It is an interesting idea. I am afraid I've underestimated the difference between a symbol and a variable. I'll have a closer look at that.

cgh a écrit : ↑10 avr. 2021 20:15 Yes ! It is corrected. This was difficult, but it works !

Thumbs up!!! Thanks for all patches and corrections!

Thanks for a prompt response and explanation.
What I didn't stress enough in my first post is that out of my 7 comments, just one can be considered a bug (and only a minor one). That proves how wonderful piece of software the lhTools are. Many thanks to the author!

Others (like "CALL BC10") are inherited from the old - old - old (too old) versions and so, are kept for backward compatibility; perhaps and certainly not a very good choice...

I fully understand that breaking the compatibility is undesirable and would do more harm than good. Perhaps a compromise might be that the compiler issues a non-critical warning if a label could be misinterpreted as a hex number...? But it's just an idea.

About the undocumented mnemonics, like CLA, these use the register MN. I will add a specific part for this register.

Well, I can see there are even more secrets about the LH8150 ML than I expected.

For the entry points and the macros SBR, in fact, I take the fact that people using the lhTools, already have some knowledge about ML and PC1500 internals. But, adding appendices describing some of them is, I think, a very good option. I will so update the documentation.

I think there are two separate things: First, what mnemonics is understood by the lhasm, and second, what the subroutines actually do.
The former is covered for the selected SBR() calls by the manual, but other names (like GETKEY or HEXDEC) are not listed.
The latter would be a nice bonus, but I agree it is rather out of scope of the lhTools manual.

This thread is aimed at the experience with lhTools, and especially the LH5801 cross-assembler lhasm. The software is available at http://www.pc1500.com/.
It could happen I missed some of the information that was already posted in the French forums; if it is the case, please post a link to it here.

I am running lhTools under Linux Manjaro and they are running fine without any problems. Nevertheless there are some small issues that can cause a slight inconvenience, though they are not really limiting and once you get used to them, you perhaps don't even realize their existence. So they are most visible to a new user like me.

The list is not long, and there might be a misunderstanding from my side, so please correct me where I am wrong.

Part I. - lhasm
Tested version: 0.7.6p1

1. To tell the compiler whether a number is decimal, octal, or hexadecimal, prefixes like &, #, \X, \o etc. are used. However, if you use no prefix, hexadecimal is presumed. This can lead to ambiguities, as a number can have the same format as a symbol (e.g. label). So in the instruction "BC10" can be understood either as an address, or as a label (which could mean e.g. "multiply BC by 10"). The compiler seems to interpret it as a label, if such label exists, but a human reader might be confused.

2. The prefixes cannot be used with the .ORIGIN: directive. It requires hexadecimal number with no prefix.

3. .EQU directive accepts most of (perhaps all?) specifiers and operators listed in chapters 2.2 and 2.3 of the manual. But an error is raised if the expression contains a symbol. So you can write etc., but not However, the symbols can be used for immediate values like in and the compiler correctly understands even an expression like 4. The compiler requires a label to be on a separate line. This is no serious limitation, but if there is an instruction after the label, the compiler silently ignores it, without any warning!

5. Except for the ML instructions, the compiler has a number of predefined symbols and mnemonics for the use with PC-1500. In chapter 2.1 of the manual, mnemonics for selected SBR() calls are listed. But besides this, there are apparently other named addresses for some useful ROM routines and system variables, but these are not documented.

6. The compiler understands the instruction CLA, which is compiled as &34. But such ML code is not listed in the LH5801 Assembly Language documentation. What does it do...?

7. The indirect instructions AND (R), AND (mn), OR (R), OR (mn) (and perhaps some other?) should not be followed by a comment, otherwise a warning is raised
--WARNING-- Argument 4; Trailing garbage not processed!
followed by a fatal error "Assembler confused" etc. If there is no comment, these instructions compile correctly.

The list will be extended if I come across other irregularities.
For the time being I have no (or very small) experience with the other tools (lhdump, lhcom, lhpoke).

Thanks for the very useful and detailed description.
I'll give the macros a try and I'll come back if there are some more questions.

Merci pour l'information!
Le nouveau fil est exactement ce que je recherche.

Thanks for the information!
The new thread is exactly what I am looking for.

J'ai un Sharp PC-1500A et j'ai commencé à programmer en ML récemment. Je recherche des informations sur les subroutines ROM utilisables. Je ne suis malheureusement pas en mesure de communiquer en français, donc si vous pensez pouvoir m'aider sur ce sujet, merci bien de consulter le forum en anglais. Vous y trouverez plus de détails.
Merci!

I am a proud owner of Sharp PC-1500A and I decided to have some fun with the ML programming. Of course, as any other programmer, I'd like to save my work and re-use as much code as possible. So I tried to find information on the available ROM subroutines.

A great help were the pc1500.com webpages. There I found many useful links, and above all, the lhTools. I've found a couple of subroutines documented in the Technical Reference Manual, but apparently there were more subroutines, unfortunately undocumented.

I did a lot of googling but all the results lead more or less to the same places (pc1500.com, pc-1500.info, old computer magazines), and I wasn't able to find the necessary information. The best I could find was a series of unofficial (but valuable) articles published by the PCN (Pocket Computer Newsletter) in 1984, describing the internal structure of PC-1500 and also some of its ROM subroutines.

The information I have NOT found concerns the pre-defined SBR (aka VEJ or VMJ) instructions. These subroutines are used in several ML programming examples (like e.g. the ML code in the Sharpentiers No.5, pg.6), but I could not find any detailed explanation of what they do and how to use them.

You can find information on how the parameters are passed to the subroutines etc., but it seems to me as if it was assumed that the reader already knows what the subs do, what parameter they take etc...

At the same time, the lhTools assembler has a dedicated mnemonic to call (some of) these subroutines, so apparently these subroutines are used by those "who know".

So my question is, where can one find comprehensive information concerning the SBR() calls (or ROM subroutines in general) for PC-1500(A), if such information is available at all?

Thanks in advance.

badaze a écrit : ↑01 avr. 2021 20:36 Benvenuto !

I’ve been to Prague on vacation and it’s a lovely city. I also worked near Brno years ago. I learned a few words in Czech but I remember less than 10 I guess (Dobri den, Dobri vecer, Dobro nots, prosim..... and Pivo).

Well done Pivo is of course the most important word.