C'est quoi le "mode exam" ?Gege34 a écrit : ↑28 avr. 2021 09:08 Sur un ordi ou un téléphone il n'y a pas de mode éxam qui bride les antisèches ou programmes accessibles, sans parler du fait qu'un téléphone tu peux communiquer avec quelqu'un pour avoir les réponses.
Alors qu'une calculatrice en modem éxam c'est un environnement "maitrisé".
2063 résultats trouvés
- 28 avr. 2021 09:47
- Forum : Tous les Pockets
- Sujet : HPCC 2021 - Cyrille de Brébisson
- Réponses : 28
- Vues : 14944
Re: HPCC 2021 - Cyrille de Brébisson
- 28 avr. 2021 08:55
- Forum : Tous les Pockets
- Sujet : HPCC 2021 - Cyrille de Brébisson
- Réponses : 28
- Vues : 14944
Re: HPCC 2021 - Cyrille de Brébisson
Concernat l'avenir des calculatrices chez HP, TI, Casio et les autres, on peut aussi se poser la question de l'interet de calculatrices alors que les enfants vont a l'ecole avec des PC portables et des smartphones…
Une calculatrice, c'est un objet de plus a acheter (et c'est souvent cher), a mettre a jour, a charger,...
Un bon petit emu48 ou free42 sur un Android, et hop…
Bon, c'est vrai que la PRIME est plus puissante que les émulateurs/simulateurs, mais pourquoi pas une app HPPRIME sur les stores ?
Une calculatrice, c'est un objet de plus a acheter (et c'est souvent cher), a mettre a jour, a charger,...
Un bon petit emu48 ou free42 sur un Android, et hop…
Bon, c'est vrai que la PRIME est plus puissante que les émulateurs/simulateurs, mais pourquoi pas une app HPPRIME sur les stores ?
- 22 avr. 2021 08:35
- Forum : Silicium in English
- Sujet : Experience with lhTools for PC-1500
- Réponses : 19
- Vues : 20477
Re: Experience with lhTools for PC-1500
The "obscure" evaluatorkuzja a écrit : ↑20 avr. 2021 21:40Actually, this requirement is documented in the manual, so what is surprising is the fact that it is not required in an expression like [+3].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.
No, in fact, when a value is written [opval], the val is read directly. The evaluator does not call itself in this case. The feature to call the evalutaor using the quote sign ' was introduced later, due to my needs for a software I was developing at this time...
I am fully agree with your description about backward compatibility and this is what I expect when I will start the rebuild of the lhTools. At this time, I do not know if I will provide a translation tool or support a "backward" option to legacy syntax.
May the PC1500 be with you.
- 19 avr. 2021 20:41
- Forum : Silicium in English
- Sujet : Experience with lhTools for PC-1500
- Réponses : 19
- Vues : 20477
Re: Experience with lhTools for PC-1500
Thanks a lot for all the tests and the reports here
In fact, you pointed what is the is badest and most obscure "part" of lhasm: its evaluator !
The development in "way to stay compatible" with older versions of lhdump (and also my sources) and the perpetual enhancements have built a monster that is ambigous and somewhat confusing. This is clearly the part that I need to fully rework. And all choices made were not always good...
I won't change it now, as I expect to release the ultimate and last release 0.8.0 soon.... hmmm... this year... I hope !
The evaluator has inherited from the ancestor of lhasm, named lhbin and provided with the earliest versions. As lhasm is still able to deal with lhbin sources, I keep the current evaluator. Sorry. lhasm was introduced in the 0.4.0 (2014) and has replaced the old lhbin.
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. In your example, if JR +3 is rejected, JR +03 is accepted. By the way, the following source is correct and produce the expected code:
As you underlined it, it depends of the context. But this is not the evalutor which is context dependant, but the directives or instructions. So, this why some directives (.ORIGIN, .EQU) and some instructions may accept or reject some contructions that look valid for others.
I will try to describe this by an example of the instruction LDA. There are several syntaxes valid:
As lhasm and lhdump share the same table for the description of the instructions (see lh5801.c), the assembler fetches the closest instruction matching the arguments. if you write LDA B, nothing is possible except the load to A with a high 8 bits register (1). If you write LDA 00, nothing is possible except a load to A of the immediate 8 value 00 (6). If you write LDA BC, this more complicated: BC matches a 16-bits register but no instruction is fetchable. So BC is expected to be a 8 bits value and the assembler choses LDA &BC (6). To prevent any ambiguity, I have introduced the values markers: &<hexa>, #<decimal>, @<octal>, $<ascii-char>.
The directive .ORIGIN: is specific as it does not call the evaluator. So it accept only symbols, <hexa 2 or 4 characters length>, &<hexa>, \x<hexa>, #<decimal> and \u<decimal>. I discover that I did a mistake for octal that are read as decimal... The usage of \x, \u and \o is wrong and must be \X, \U and \O; I never see that because but I don't use this syntax...
The evaluator is not called by all directives because some (like .ORIGIN: .ALIGN:) require to have an immediate and non ambigous value that must not change between the passes 1 and 2.
Really great thanks to kuzja for his time spent in testing lhasm
In fact, you pointed what is the is badest and most obscure "part" of lhasm: its evaluator !
The development in "way to stay compatible" with older versions of lhdump (and also my sources) and the perpetual enhancements have built a monster that is ambigous and somewhat confusing. This is clearly the part that I need to fully rework. And all choices made were not always good...
I won't change it now, as I expect to release the ultimate and last release 0.8.0 soon.... hmmm... this year... I hope !
The evaluator has inherited from the ancestor of lhasm, named lhbin and provided with the earliest versions. As lhasm is still able to deal with lhbin sources, I keep the current evaluator. Sorry. lhasm was introduced in the 0.4.0 (2014) and has replaced the old lhbin.
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. In your example, if JR +3 is rejected, JR +03 is accepted. By the way, the following source is correct and produce the expected code:
Code : Tout sélectionner
3 .EQU 03
JR +3
I will try to describe this by an example of the instruction LDA. There are several syntaxes valid:
Code : Tout sélectionner
LDA rH : High 8 bits register: B, D, or H (1)
LDA rL : Low 8 bits register: C, E or L (2)
(3) LDA (R) : 16-bits register indirection (BD), (DE) or (HL) (3)
(4) LDA F : Status flags register (4)
LDA (mn) : 16-bits address indirection (5)
LDA n : 8 bits immediate value (6)
The directive .ORIGIN: is specific as it does not call the evaluator. So it accept only symbols, <hexa 2 or 4 characters length>, &<hexa>, \x<hexa>, #<decimal> and \u<decimal>. I discover that I did a mistake for octal that are read as decimal... The usage of \x, \u and \o is wrong and must be \X, \U and \O; I never see that because but I don't use this syntax...
The evaluator is not called by all directives because some (like .ORIGIN: .ALIGN:) require to have an immediate and non ambigous value that must not change between the passes 1 and 2.
Really great thanks to kuzja for his time spent in testing lhasm
- 17 avr. 2021 08:49
- Forum : Tous les Pockets
- Sujet : Nouvelle version du logiciel pour HP Prime
- Réponses : 20
- Vues : 10784
- 15 avr. 2021 09:28
- Forum : Silicium in English
- Sujet : Experience with lhTools for PC-1500
- Réponses : 19
- Vues : 20477
- 12 avr. 2021 20:21
- Forum : Silicium in English
- Sujet : Experience with lhTools for PC-1500
- Réponses : 19
- Vues : 20477
Re: Experience with lhTools for PC-1500
The lhTools 0.7.8 are now available on the site of repaire.
This version corrects all issues reported by kuzja except these about the documentation (The macros and supported ROM entry points). A dedicated manual will be published later.
Thank you for using the lhTools !
May the PC1500 be with you
This version corrects all issues reported by kuzja except these about the documentation (The macros and supported ROM entry points). A dedicated manual will be published later.
Thank you for using the lhTools !
May the PC1500 be with you
- 12 avr. 2021 20:18
- Forum : Tous les Pockets
- Sujet : LhTools - Cross-Assembler/Desassembleur pour PC-1500
- Réponses : 88
- Vues : 70056
Re: LhTools - Cross-Assembler/Desassembleur pour PC-1500
Hello amis des poquettes et collegues sharpistes,
Une mise a jour des lhTools en 0.7.8 avec la correction de toutes les issues remontees par kuzja (sauf celles concernant la documention)
Que le PC1500 soit avec vous !
Une mise a jour des lhTools en 0.7.8 avec la correction de toutes les issues remontees par kuzja (sauf celles concernant la documention)
Que le PC1500 soit avec vous !
- 10 avr. 2021 20:15
- Forum : Silicium in English
- Sujet : Experience with lhTools for PC-1500
- Réponses : 19
- Vues : 20477
Re: Experience with lhTools for PC-1500
Yes ! It is corrected. This was difficult, but it works !
The lhTools-0.7.8 are almost ready. I need now to pass all the tests suites. And the documentation to update with issues reported
Code : Tout sélectionner
cgh@varvotier:~/work/pc1500/REBUID_JUN2018/lhTools-0.7.8$ cat vnok.s
.ORIGIN: 40C5
.CODE
VAR1 .EQU &1234
VAR2 .EQU VAR1
VAR4 .EQU [+10]VAR1
CALL VAR2
CALL VAR4
LD PC,[+06]VAR2
LDA ([+06]VAR4)
RET
.END
cgh@varvotier:~/work/pc1500/REBUID_JUN2018/lhTools-0.7.8$ ./lhasm -T vnok2.s
. . .
; lhTools Version 0.7.8 #0
;
; Source file: vnok2.s
; lhasm options:
; -T \
; vnok2.s
1
.ORIGIN: 40C5
2 .CODE 40C5
3 40C5 VAR1: .EQU 1234
4 40C5 VAR2: .EQU 1234
5 40C5 VAR4: .EQU 1244
6 40C5 BE 12 34 CALL VAR2
7 40C8 BE 12 44 CALL VAR4
8 40CB BA 12 3A LD PC [+06]VAR2
9 40CE A5 12 4A LDA ([+06]VAR4)
10 40D1 9A RET
11 40D2 .END
;; 40C5 vnok2.s$$._start
;; 40D2 vnok2.s$$._end
;; 000D vnok2.s$$._length
.SYMBOLS:
1234 VAR1
1234 VAR2
1244 VAR4
Written 13 bytes (40C5:40D2) to vnok2.bin Checksum 0972
- 10 avr. 2021 19:10
- Forum : Silicium in English
- Sujet : Experience with lhTools for PC-1500
- Réponses : 19
- Vues : 20477
Re: Experience with lhTools for PC-1500
Here, you must use a variable to have the code assembled. The code below does not assemble:kuzja a écrit : ↑09 avr. 2021 22:35 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 writeetc., but notCode : Tout sélectionner
SEPAR .EQU $: OFFSET .EQU [+10]&4455
However, the symbols can be used for immediate values like inCode : Tout sélectionner
VAR2 .EQU VAR1 ADR2 .EQU [+0100]BASE
Code : Tout sélectionner
.ORIGIN: 40C5
.CODE
VAR1 .EQU &1234
VAR2 .EQU VAR1
VAR4 .EQU [+10]VAR1
CALL VAR2
CALL VAR4
LD PC,[+06]VAR2
LDA ([+06]VAR4)
RET
.END
Code : Tout sélectionner
.ORIGIN: 40C5
.CODE
VAR1 .EQU &1234
VAR2 .EQU VAR1
%04v .EQU VAR1
VAR4 .EQU [+10]%04v
CALL VAR2
CALL VAR4
LD PC,[+06]VAR2
LDA ([+06]VAR4)
RET
.END
- 10 avr. 2021 18:54
- Forum : Tous les Pockets
- Sujet : LhTools - Cross-Assembler/Desassembleur pour PC-1500
- Réponses : 88
- Vues : 70056
Re: LhTools - Cross-Assembler/Desassembleur pour PC-1500
Yo amis des poquettes et collegues sharpistes,
Une petite mise a jour des lhTools en 0.7.7 avec la correction de l'inversion des code ML entre SPV et RPV.
Il y aura bientot une mise a jour suite aux differentes issues reportees par kuzja: see the thread here. Merci a kuzja pour tous ses retours
Que le PC1500 soit avec vous !
Une petite mise a jour des lhTools en 0.7.7 avec la correction de l'inversion des code ML entre SPV et RPV.
Il y aura bientot une mise a jour suite aux differentes issues reportees par kuzja: see the thread here. Merci a kuzja pour tous ses retours
Que le PC1500 soit avec vous !
- 10 avr. 2021 18:43
- Forum : Silicium in English
- Sujet : Experience with lhTools for PC-1500
- Réponses : 19
- Vues : 20477
Re: Experience with lhTools for PC-1500
The lhTools 0.7.7 are now available on the site of repaire.
This version corrects the switch of the ML code between SPV and RPV.
A new version 0.7.8 is expected soon when all issues reported by kuzja will be corrected and the lhTools will succesfsully complete their tests suite
Thank you for using the lhTools !
May the PC1500 be with you
This version corrects the switch of the ML code between SPV and RPV.
A new version 0.7.8 is expected soon when all issues reported by kuzja will be corrected and the lhTools will succesfsully complete their tests suite
Thank you for using the lhTools !
May the PC1500 be with you
- 10 avr. 2021 12:35
- Forum : Silicium in English
- Sujet : Experience with lhTools for PC-1500
- Réponses : 19
- Vues : 20477
Re: Experience with lhTools for PC-1500
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. Sokuzja a écrit : ↑09 avr. 2021 22:35 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 writeetc., but notCode : Tout sélectionner
SEPAR .EQU $: OFFSET .EQU [+10]&4455
However, the symbols can be used for immediate values like inCode : Tout sélectionner
VAR2 .EQU VAR1 ADR2 .EQU [+0100]BASE
and the compiler correctly understands even an expression likeCode : Tout sélectionner
LDA (VAR1) LD H,[+10]<VAR1
Code : Tout sélectionner
LDA (2+ADR) ; (but not ADR+2)
The following works:
Code : Tout sélectionner
.ORIGIN: 40C5
.CODE
VAR1 .EQU &1234
VAR2 .EQU VAR1
CALL VAR2
RET
.END
Code : Tout sélectionner
.ORIGIN: 40C5
.CODE
VAR2 .EQU VAR1
VAR1 .EQU &1234
CALL VAR2
RET
.END
But it looks like defining a symbol with an expression containing a symbol is not working correctly and the value is wrong... I need to have a look deeply inside the evaluator
- 10 avr. 2021 11:38
- Forum : Silicium in English
- Sujet : Experience with lhTools for PC-1500
- Réponses : 19
- Vues : 20477
Re: Experience with lhTools for PC-1500
This is a regression due to introduction of the .ARRAY directive, that remove the error if the define is followed by something else than a comment.
The fact that a symbol definition cannot be followied by an instruction is to prevent against recursion when defining a symbol inside a macro. This is a limitation and should be documented.
Waiting for a delivery, here is the patch:
Code : Tout sélectionner
--- lhTools-0.7.7/lhasm.c 2019-03-24 21:22:39.000000000 +0100
+++ lhTools-0.7.8/lhasm.c 2021-04-10 11:36:13.657475367 +0200
@@ -5244,6 +5247,8 @@
LHASM_ERR( "Unknown array base address %s\n", arg[4+export] );
v = ((t < b) ? (b - t) : (t - b)) / sz;
}
+ else if( arg[1+export] && *arg[1+export] != ';' )
+ LHASM_ERR( "Unexpected arguments \"%s\"\n", arg[1+export]);
else
v = lhAsmGetPC();
if( asmpass == 1 )
- 10 avr. 2021 10:22
- Forum : Silicium in English
- Sujet : Experience with lhTools for PC-1500
- Réponses : 19
- Vues : 20477
Re: Experience with lhTools for PC-1500
This is a very insteresting bug !kuzja a écrit : ↑09 avr. 2021 22:35 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.
In fact, AND (R) ; was taken as AND (R),n like the , is not mandatory (due to backward compatibility...). Like the pass 1 of the assembler has tolerance about bad values or symbols not defined, the assembler believes that ; is a symbol and so prepare the code 49 n which is AND (BC),n.
But the pass 2, which expects NO tolerance about bad or undefined values, set the code to AND (BC) that is 09.
Finally, the assembler checks for pointers when assembling the code, it detects that a mnemonic request for 2 bytes (pass 1) and the same mnemonic for 1 byte (pass 2), and so, like this differs, it raises the fatal error about pointer confusion:
Code : Tout sélectionner
a.a line 13: !!!FATAL!!! Assembler confused. END from a.a differs between passes
The patch below:
Code : Tout sélectionner
--- lhTools-0.7.6p1/lhasm.c 2019-03-24 21:22:39.000000000 +0100
+++ lhTools-0.7.8/lhasm.c 2021-04-10 10:13:59.964344066 +0200
@@ -1399,6 +1399,9 @@
LHU16 max = 0xFFFF, vs, vv, rel = 0xFFFF, opval = 0, is = 0;
char symna[80];
+ if( !str || (str && *str == ';') )
+ return 0;
+
if( asmrunmacro && (str && 0 == strncmp( str, "__#", 3 )) )
{
if( 1 == sscanf( str + 3, "%hu", &vs ) )