ugBASIC est arrivé sur Olivetti Prodest PC128!

Cette catégorie traite de développements récents destinés à nos vieilles machines, applications, jeux ou démos... Amis programmeurs, c'est ici que vous pourrez enfin devenir célèbres!

Modérateurs : Papy.G, fneck, Carl

spotlessmind1975
Messages : 66
Inscription : 24 oct. 2021 15:47

Re: ugBASIC est arrivé sur Olivetti Prodest PC128!

Message par spotlessmind1975 »

__sam__ a écrit : 27 oct. 2021 10:28 Ah oui serait bien un fork de usim qui contienne vos modifications en effet, car il est important de pouvoir tester les non-régressions.
I created the repository as a fork, and added the "ugbasic" branch to identify the changes needed to build a version of usim that integrates with tests:
https://github.com/spotlessmind1975/usim

Be careful because this is not a code designed for the use of the end user, so it does not do many checks. Infact, I don't know if it works under Windows. You will clearly have to put the usim version in a path that the ugbasic program can reach. Finally, the tests for pc128op may not work and so the one for mo5 (at the moment there is no specific code for these two platforms). Since it is about testing the code generation for the CPU 6809, you can use the test suite for the Dragon 32, as well:

Code : Tout sélectionner

make target=d32 clean test
If you get this output, then you are ready to test:

Code : Tout sélectionner

--- START TEST ---
......................results = fffffff8 (-8) [expected -8]
...............................................
cpu_compare_memory : FAILED

cpu_compare_memory_size : FAILED

cpu_less_than_memory : FAILED

cpu_less_than_memory_size : FAILED

cpu_greater_than_memory : FAILED

cpu_greater_than_memory_size : FAILED
.....................
--- END TEST ---
__sam__
Messages : 7925
Inscription : 18 sept. 2010 12:08
Localisation : Brest et parfois les Flandres

Re: ugBASIC est arrivé sur Olivetti Prodest PC128!

Message par __sam__ »

Ok, I'll test that maybe later in the weekend.

Tonight I wanted to test the "TI" variable for the MO5 and compiled and ran contrib_timers.bas. Unfortunately it seem the timer remains at 0. Is there any reason for that ?

[EDIT] inspecting src/hw/mo5/startup.asm I found the answer

Code : Tout sélectionner

MO5STARTUP

    LDX $2061
    STX MO5IRQO
    LDX #MO5IRQ
    STX $2061
On the MO5 the "TIMEPT" is not only the address of the ISR (interrupt service routine), but also a flag to enable it at $2063. When 0 (default value) the TIMEPT is not enabled and the MO5IRQ routine is not called. Of course if you want to chain, you need to check this flag to be sure that the previous pointer in $2061 was enabled or not. At the end of the ISR, you should do a RTI to finish the interrupt and continue the normal execution flow.

Last, as these two are IRQ and not FIRQ (F standing for Fast), you don't need to protect the registers (there is no need to PSHS/PULS D,X). The mc6809 will save them all on the stack for you.

Here is a version of startup.asm that makes the timer work on the MO5 (and possibly on the pc128 as well)

Code : Tout sélectionner

MO5TIMER      fdb $0
MO5IRQO       fdb MO5IRQ3
MO5IRQN       fdb $0

; TIMER service routine
MO5IRQ
    LDD   MO5TIMER
    ADDD  #1
    STD   MO5TIMER
    LDX   MO5IRQN
    BEQ   MO5IRQ2
    JSR   ,X
MO5IRQ2
    JMP   [MO5IRQO]
MO5IRQ3
    RTI
    
MO5STARTUP
    LDX   #$2061
    LDA   2,X
    BEQ   MO5STARTUP2
    LDD   ,X
    STD   MO5IRQO
MO5STARTUP2    
    LDD   #MO5IRQ
    STD   ,X
;   LDA   #1   <== any non zero will do, but since $00xx point to video ram, we know for sure that A=highbyte(MO5IRQ) will never be 0 ;)
    STA   2,X

    LDA   #$20
    TFR   A,DP
    RTS
And if the memory footprint is an issue (in my experience, it is), we can use a technique that I (ab)use in most all of 1kb intro: use immediate values as variables. This reduces the memory footprint a lot and makes the program faster as well (but somehow is not ROMable (not an issue here), and difficult to analyze for a beginner, hence considered as bad programming by academics). In that case that would give:

Code : Tout sélectionner

; TIMER service routine
MO5IRQ
    LDD   #1          ; increment 
    ADDD  #0          ; add value of TI variable
MO5TIMER  set *-2     ; (variable within code)
    STD   MO5TIMER    ; write result to TI variable
    LDX   #0          ; get next ISR
MO5IRQN   set *-2     ; (variable within code)
    BEQ   MO5IRQ2     ; any defined ?
    JSR   ,X          ; yes ==> call it
MO5IRQ2
    JMP   >MO5IRQEND  ; no ==> jmp to the old one
MO5IRQO   set *-2     ; (variable within code)
MO5IRQEND
    RTI               ;  by defaut do RTI
    
MO5STARTUP
    LDX   #$2061
    LDA   2,X         ; Is previous TIMERPT enable ?
    BEQ   MO5STARTUP2 ; no ==> keep default return code (RTI)
    LDD   ,X          ; yes ==> backup previous ISR
    STD   MO5IRQO     ;         and chain it at the end of our own
MO5STARTUP2    
    LDD   #MO5IRQ     ; install our own ISR
    STD   ,X
    LDA   #$20        ; any non-zero value will do, let's use the one that'll go to DP
    STA   2,X         ; enable the ISR

    TFR   A,DP       
    RTS
Note this ISR is running at 50hz, and it seem a 60hz interrupt is assumed (TI/60 in the basic source). It is possible to emulate this by incrementing MO5TIMER by 1.2 instead of 1 (*), but may be you plan to introduce some kind of global system-constant (say TI_HZ) indicating the frequency of change of the TI variable on the machine ?

sam.
_____
(*) this will require a bit of extra code to deal with the fractional part. The idea is to make the increment = 2 one time out of 4, and 1 otherwise, resulting in a 1.2 increment value on average.

Code : Tout sélectionner

MO5IRQ
    LDD   #$0501      ; A=fractionnal part increment, B=increment
MO5TIMERFRAC SET *-2  ; (internal variable within code)
    DECA
    BNE   MO5IRQ0
    ADDD  #$0501      ; reset A to 5, and sets B to 2
MO5IRQ0
    STA   MO5TIMERFRAC
    CLRA              ; make increment 16 bit. 
    ADDD  #0          ; adds the TI variable
MO5TIMER  set *-2     ; (variable within code)
    STD   MO5TIMER    ; write result back to TI variable
    LDX   #0          ; get next ISR
MO5IRQN   set *-2     ; (variable within code)
(... remaining code unchanged...)
Dernière modification par __sam__ le 30 oct. 2021 13:11, modifié 1 fois.
Samuel.
A500 Vampire V2+ ^8^, A1200 (030@50mhz/fpu/64mb/cf 8go),
A500 GVP530(MMU/FPU) h.s., R-Pi, TO9, TO8D, TO8.Démos
spotlessmind1975
Messages : 66
Inscription : 24 oct. 2021 15:47

Re: ugBASIC est arrivé sur Olivetti Prodest PC128!

Message par spotlessmind1975 »

Thank you again for the support, and for the analysis.
They are always precise and clear.

I added the report to the list of bugs to fix, suggesting to follow your excellent guidelines:
https://github.com/spotlessmind1975/ugbasic/issues/183

Merci encore!!
__sam__
Messages : 7925
Inscription : 18 sept. 2010 12:08
Localisation : Brest et parfois les Flandres

Re: ugBASIC est arrivé sur Olivetti Prodest PC128!

Message par __sam__ »

May be if you prefer, and in order not to saturate this thread with (lots of) thomson-specific technical details, I can directly report these as issues on the github myself, since I'm pretty sure there are numerous places for improvements in the ASM support library or simply filling unimplemented code.

For instance I've spotted that the cursor is blinking, but not right after the "PRINT" location. This is because you don't use the official ROM call and prefer a more versatile routine in text_at.asm. May be we should then also disable the cursor blink for the MO5 (and possibly the pc128op which shares most of the stuff of the MO5) in the startup.asm code.
Samuel.
A500 Vampire V2+ ^8^, A1200 (030@50mhz/fpu/64mb/cf 8go),
A500 GVP530(MMU/FPU) h.s., R-Pi, TO9, TO8D, TO8.Démos
__sam__
Messages : 7925
Inscription : 18 sept. 2010 12:08
Localisation : Brest et parfois les Flandres

Re: ugBASIC est arrivé sur Olivetti Prodest PC128!

Message par __sam__ »

spotlessmind1975 a écrit : 29 oct. 2021 09:24 I created the repository as a fork, and added the "ugbasic" branch to identify the changes needed to build a version of usim that integrates with tests:
https://github.com/spotlessmind1975/usim
So I cloned it and change the branch to ugbasic, see:

Code : Tout sélectionner

$ git branch
  master
* ugbasic
But when I do "make" I get this:

Code : Tout sélectionner

$ make
g++ --std=c++14 -Wall -Wextra -Werror -flto -D_POSIX_SOURCE -g -c main.cpp
main.cpp: In function ‘int doLabels(int, char**)’:
main.cpp:63:31: error: ‘strdup’ was not declared in this scope; did you mean ‘strcmp’?
   63 |     label_name[label_count] = strdup( label );
      |                               ^~~~~~
      |                               strcmp
main.cpp: In function ‘int doLabels2(int, char**)’:
main.cpp:82:31: error: ‘strdup’ was not declared in this scope; did you mean ‘strcmp’?
   82 |     label_name[label_count] = strdup( label );
      |                               ^~~~~~
      |                               strcmp
main.cpp: In function ‘int doInspections(int, char**)’:
main.cpp:105:41: error: ‘strdup’ was not declared in this scope; did you mean ‘strcmp’?
  105 |     inspection_name[inspection_count] = strdup( label );
      |                                         ^~~~~~
      |                                         strcmp
main.cpp: In function ‘int doListing(int, char**)’:
main.cpp:148:32: error: ‘strdup’ was not declared in this scope; did you mean ‘strcmp’?
  148 |     listing_instructions[pc] = strdup( instructions );
      |                                ^~~~~~
      |                                strcmp
main.cpp: In function ‘int main(int, char**)’:
main.cpp:177:69: error: ‘strdup’ was not declared in this scope; did you mean ‘strcmp’?
  177 |                 else if (!strcmp(*argv, "-O"))  { output_filename = strdup( *(argv+1) ); n = 1; }
      |                                                                     ^~~~~~
      |                                                                     strcmp
main.cpp:184:42: error: ‘strdup’ was not declared in this scope; did you mean ‘strcmp’?
  184 |                         input_filename = strdup(*argv);
      |                                          ^~~~~~
      |                                          strcmp
make: *** [Makefile:21: main.o] Error 1
But if I modify the makefile to add -D_GNU_SOURCE to CPPFLAGS, it compiles ok up to the link stage where gcc complains about multiple definitions. This is a classic issue that can be fixed by adding -Wl,-allow-multiple-definition to LDFLAGS:

Code : Tout sélectionner

CPPFLAGS	= -D_POSIX_SOURCE -D_GNU_SOURCE
LDFLAGS		= -flto -Wl,-allow-multiple-definition
Then with all those changes I cound compile and install usim successfully and when running "make target=d32 clean test", get:

Code : Tout sélectionner

--- START TEST ---
....................
cpu_math_mul_8bit_to_16bit : FAILED

cpu_math_mul_16bit_to_32bit A : FAILED
results = 00000000 (0) [expected -8]

cpu_math_mul_16bit_to_32bit B : FAILED
.
cpu_math_div_16bit_to_16bit A : FAILED

cpu_math_div_16bit_to_16bit B : FAILED

cpu_math_div_16bit_to_16bit C : FAILED

cpu_math_div_16bit_to_16bit D : FAILED
......
cpu_number_to_string_payloadD : FAILED
..................................
cpu_compare_memory : FAILED

cpu_compare_memory_size : FAILED

cpu_less_than_memory : FAILED

cpu_less_than_memory_size : FAILED

cpu_greater_than_memory : FAILED

cpu_greater_than_memory_size : FAILED
.....................
--- END TEST ---
All tests failed. What does this mean ?
Samuel.
A500 Vampire V2+ ^8^, A1200 (030@50mhz/fpu/64mb/cf 8go),
A500 GVP530(MMU/FPU) h.s., R-Pi, TO9, TO8D, TO8.Démos
spotlessmind1975
Messages : 66
Inscription : 24 oct. 2021 15:47

Re: ugBASIC est arrivé sur Olivetti Prodest PC128!

Message par spotlessmind1975 »

__sam__ a écrit : 30 oct. 2021 13:24 May be if you prefer [...]
It would be the best thing, both for a matter of "saturation" (as you have rightly pointed out) and because in this way I do not risk missing something.
__sam__ a écrit : 30 oct. 2021 13:24 For instance I've spotted that the cursor is blinking, but not right after the "PRINT" location. This is because you don't use the official ROM call and prefer a more versatile routine in text_at.asm.
The reason I use the text_at routine is because it is possible (or rather, it should be possible) to control the cursor position, text color and other characteristics by storing the commands in a string. This mechanism, available on all platforms, allows to create very efficient programs because, instead of executing a series of separate commands, it is sufficient to send a single string to the PRINT. It is a much more efficient method. Anyway, be very careful because what you indicate is the routine for the Dragon 32, while there is a similar routine for PC128 and MO5.
__sam__ a écrit : 30 oct. 2021 13:24May be we should then also disable the cursor blink for the MO5 (and possibly the pc128op which shares most of the stuff of the MO5) in the startup.asm code.
It seems a very good idea!
But when I do "make" I get this:
Weird, really weird. It seems like if the development environment you are using is not compatible with the usim build specification. Please note that it does not give me any kind of warning or error -- and I have a very standard installation of Ubuntu 20.10.

This is my version:

Code : Tout sélectionner

gcc (Ubuntu 10.3.0-1ubuntu1~20.10) 10.3.
g++ (Ubuntu 10.3.0-1ubuntu1 ~ 20.10) 10.3.0
This is my output:

Code : Tout sélectionner

$ make clean
rm -f -f machdep.h machdep.o machdep usim usim.o mc6809.o mc6809in.o memory.o mc6850.o term.o main.o
asimov@orville:/usr/src/usim$ make
gcc --std=c9x -Wall -Werror  -D_POSIX_SOURCE  -c -o machdep.o machdep.c
gcc --std=c9x -Wall -Werror -o machdep -g -flto machdep.o
./machdep machdep.h
g++ --std=c++14 -Wall -Wextra -Werror -flto -D_POSIX_SOURCE -g -c usim.cpp
g++ --std=c++14 -Wall -Wextra -Werror -flto -D_POSIX_SOURCE -g -c mc6809.cpp
g++ --std=c++14 -Wall -Wextra -Werror -flto -D_POSIX_SOURCE -g -c mc6809in.cpp
g++ --std=c++14 -Wall -Wextra -Werror -flto -D_POSIX_SOURCE -g -c memory.cpp
g++ --std=c++14 -Wall -Wextra -Werror -flto -D_POSIX_SOURCE -g -c mc6850.cpp
g++ --std=c++14 -Wall -Wextra -Werror -flto -D_POSIX_SOURCE -g -c term.cpp
g++ --std=c++14 -Wall -Wextra -Werror -flto -D_POSIX_SOURCE -g -c main.cpp
g++ --std=c++14 -Wall -Wextra -Werror -flto -o usim -g -flto usim.o mc6809.o mc6809in.o memory.o mc6850.o term.o main.o
So it seems that the compilation of machdep.c is missing.
Am I right?
__sam__
Messages : 7925
Inscription : 18 sept. 2010 12:08
Localisation : Brest et parfois les Flandres

Re: ugBASIC est arrivé sur Olivetti Prodest PC128!

Message par __sam__ »

The reason I use the text_at routine is because it is possible (or rather, it should be possible) to control the cursor position, text color and other characteristics by storing the commands in a string. This mechanism, available on all platforms, allows to create very efficient programs because, instead of executing a series of separate commands, it is sufficient to send a single string to the PRINT. It is a much more efficient method.
The ROM routine also has this feature on Thomson machines (via ANSI espace sequences), but it doesn"t work with the 160x200 graphic mode.
Anyway, be very careful because what you indicate is the routine for the Dragon 32, while there is a similar routine for PC128 and MO5.
oops :oops:
So it seems that the compilation of machdep.c is missing.
Am I right?
No, after adding -D_GNU_SOURCE and -Wl,<stuff> to the makefile I do get a working usim:

Code : Tout sélectionner

$ make
gcc --std=c9x -Wall -Werror  -D_POSIX_SOURCE -D_GNU_SOURCE  -c -o machdep.o machdep.c
gcc --std=c9x -Wall -Werror -o machdep -g -flto -Wl,-allow-multiple-definition machdep.o
./machdep machdep.h
g++ --std=c++14 -Wall -Wextra -Werror -flto -D_POSIX_SOURCE -D_GNU_SOURCE -g -c usim.cpp
g++ --std=c++14 -Wall -Wextra -Werror -flto -D_POSIX_SOURCE -D_GNU_SOURCE -g -c mc6809.cpp
g++ --std=c++14 -Wall -Wextra -Werror -flto -D_POSIX_SOURCE -D_GNU_SOURCE -g -c mc6809in.cpp
g++ --std=c++14 -Wall -Wextra -Werror -flto -D_POSIX_SOURCE -D_GNU_SOURCE -g -c memory.cpp
g++ --std=c++14 -Wall -Wextra -Werror -flto -D_POSIX_SOURCE -D_GNU_SOURCE -g -c mc6850.cpp
g++ --std=c++14 -Wall -Wextra -Werror -flto -D_POSIX_SOURCE -D_GNU_SOURCE -g -c term.cpp
g++ --std=c++14 -Wall -Wextra -Werror -flto -D_POSIX_SOURCE -D_GNU_SOURCE -g -c main.cpp
g++ --std=c++14 -Wall -Wextra -Werror -flto -o usim -g -flto -Wl,-allow-multiple-definition usim.o mc6809.o mc6809in.o memory.o mc6850.o term.o main.o

$ ./usim
usage: usim [option ...] <hexfile>
  -h                -- help (print this message)
  -l addr file      -- load file at addr
  -R addr           -- run from this address
  -X addr           -- terminate emulation if PC reaches addr
I just wanted to notice that for some reason my GCC (11.2.0, cygwin) is picky about strdup/strcmp.

Anyway my last question was on the interpretation of the "make target=d32 test" results. All tests "FAILED", which seem odd at first sight.
Samuel.
A500 Vampire V2+ ^8^, A1200 (030@50mhz/fpu/64mb/cf 8go),
A500 GVP530(MMU/FPU) h.s., R-Pi, TO9, TO8D, TO8.Démos
spotlessmind1975
Messages : 66
Inscription : 24 oct. 2021 15:47

Re: ugBASIC est arrivé sur Olivetti Prodest PC128!

Message par spotlessmind1975 »

The ROM routine also has this feature on Thomson machines (via ANSI espace sequences), but it doesn"t work with the 160x200 graphic mode.
The isomorphic paradigm does not allow (except in cases where it is not possible to do otherwise) the use of system libraries, for obvious reasons. For example, in the case of the Thomson MO5 / MO6, not having clear information on how to use the keyboard, I was forced to call the system library (by SWI instruction) - but it's an exception, not a rule. On the other hand, the text_at module guarantees homogeneous behavior on all resolutions and platforms, even on the Commodore 64 and on the Sinclair. And it is about 50% more space efficient than ANSI escape sequences (this is an important issue, in my humble opinion).
No, after adding -D_GNU_SOURCE and -Wl,<stuff> to the makefile I do get a working usim:
It seems to me that you are using a newer compiler than mine, which may complain about using a call that is perhaps not quite standard. Actually the option you have chosen seems to me to just turn off the warning, but we are not sure if the warning makes sense or not. This only worries me because, if we don't have the same compile-time behavior, we can't have it at runtime.
All tests "FAILED", which seem odd at first sight
That's exactly what I was saying before. We should be sure that usim is working before debugging it.

At this point you could do this:
  • comment out all tests in ugbc/src-test/suites/cpu.c but one (line 4700)
  • enable printf for that test (lines 504-507)
  • enable tracing on usim by adding -t option to ugbc/src-test/tester_d32.c (line 81)
  • call make target=d32 clean test 2>/tmp/out.log
If you see this output:

Code : Tout sélectionner

and00 = 00 (0) [expected 0x00]
and01 = 00 (0) [expected 0x00]
and10 = 00 (0) [expected 0x00]
and11 = 00 (0) [expected 0xff]
then you shoud take a look at /tmp/out.log, to check if there is a "dump" of the execution of a program or if it full of strange instructions. In any case, the usim is not working correctly so tests fail for this reason.
__sam__
Messages : 7925
Inscription : 18 sept. 2010 12:08
Localisation : Brest et parfois les Flandres

Re: ugBASIC est arrivé sur Olivetti Prodest PC128!

Message par __sam__ »

spotlessmind1975 a écrit : 31 oct. 2021 09:47 For example, in the case of the Thomson MO5 / MO6, not having clear information on how to use the keyboard, I was forced to call the system library (by SWI instruction) - but it's an exception, not a rule.
Oh I see. Presumably this also why color_border() is empty. There is no real uniform way to change this hardware-banging on the Thomson machine. To change the color of the border of the screen we have to revert to the PUTC rom call which provide standardization across the range of MO5/MO6/PC128 machines (but is slower than hardware banging).
On the other hand, the text_at module guarantees homogeneous behavior on all resolutions and platforms, even on the Commodore 64 and on the Sinclair. And it is about 50% more space efficient than ANSI escape sequences (this is an important issue, in my humble opinion).
Right.
Anyway my last question was on the interpretation of the "make target=d32 test" results. All tests "FAILED", which seem odd at first sight
That's exactly what I was saying before. We should be sure that usim is working before debugging it.

At this point you could do this:
  • comment out all tests in ugbc/src-test/suites/cpu.c but one (line 4700)
(..)
If you see this output:
(..)
then you shoud take a look at /tmp/out.log, to check if there is a "dump" of the execution of a program or if it full of strange instructions. In any case, the usim is not working correctly so tests fail for this reason.
Yeah, you are right, this is becoming complex. Definitely a topic for ugbasic expert(s) :)

If you are interested I can provide "profiling" data that I collected using a tool of mine that that analyzes DCMOTO traces on some examples/*.bas file. For instance here is what I get on contrib_timers.bas. Using the hotspot, one can see that most of the time is spent in "TEXTAT", and more precisely in TEXTATBMSP0L1. This might help finding place where optimisation will help.

For instance if I replace TEXTATBMSP0L1 with this version:

Code : Tout sélectionner

TEXTATBMSP00
TEXTATBMSP01
TEXTATBMSP04
    LDA $a7c0
    ORA #$01
    STA $a7c0
    LDU <MATHPTR5
    LDB CURRENTSL
    LDA #8
    STA ,-S

TEXTATBMSP0L1
    LDA ,Y+
    STA ,X
    DEC $a7c0
    LDA <MATHPTR5
    STA ,X
    INC $A7c0
    BRA TEXTATBMSP0L1M2

TEXTATBMSP0L1M
    LDA ,Y
    LSRA
    LSRA
    LSRA
    LSRA
    LDA A,U
    STA ,X+
    LDA ,Y+
    ANDA #$0F
    LDA A,U
    STA ,X

TEXTATBMSP0L1M2
    ABX
    DEC ,S
    BNE TEXTATBMSP0L1
    LEAS 1,S

TEXTATBMSP0L1X
    LDA #1
    JMP TEXTATBMSP0E
we speed from 6506 calls to TEXTAT in 32 secs up to 7605 calls in 32 secs (+16% speedup).
Samuel.
A500 Vampire V2+ ^8^, A1200 (030@50mhz/fpu/64mb/cf 8go),
A500 GVP530(MMU/FPU) h.s., R-Pi, TO9, TO8D, TO8.Démos
spotlessmind1975
Messages : 66
Inscription : 24 oct. 2021 15:47

Re: ugBASIC est arrivé sur Olivetti Prodest PC128!

Message par spotlessmind1975 »

Thank your for the suggestion.

The profiling tool is very interesting. I would be very tempted to use it, and to share the results with you. At the moment I am following the developments to allow the creation of "frame by frame" animations, and therefore it would be ideal to apply in that case.
There is no real uniform way to change this hardware-banging on the Thomson machine. To change the color of the border of the screen we have to revert to the PUTC rom call which provide standardization across the range of MO5/MO6/PC128 machines (but is slower than hardware banging).
In my humble opinion, the only thing that is really missing is the documentation, which is a real disappointment because the Thomson hardware seems quite advanced to me. Honestly, it seems rather strange to me that it takes a call to the operating system to change a detail of this type with advanced hardware like the one that Thomson computers have. To give an example, the Motorola 6847 chip does not physically have this possibility to change the border color, since the border color depends on the selected palette (and there are only two of them). In any case, since we have segmented the assembly code emission to accompany the generated one by hardware, I do not see the problem of differentiating this operation.
Yeah, you are right, this is becoming complex. Definitely a topic for ugbasic expert(s) :)
More than anything else, I think that I should update my development environment to bring it to version 11 of the gcc, in order to give you an "out of the box" testing suite. However, I would like to understand first if the fact that yours is cygwin could or not give further problems.

Anyway, in the next few days I will be taking care of implementing the optimization tips you so kindly provided me.
__sam__
Messages : 7925
Inscription : 18 sept. 2010 12:08
Localisation : Brest et parfois les Flandres

Re: ugBASIC est arrivé sur Olivetti Prodest PC128!

Message par __sam__ »

spotlessmind1975 a écrit : 31 oct. 2021 12:22 In my humble opinion, the only thing that is really missing is the documentation, which is a real disappointment because the Thomson hardware seems quite advanced to me.
It has some innovative features like the 40906 color palette, but also has it drawbacks like a complicate way to access adjacent columns in 160x200, no hardware sprite, not even a simple PSG. So the CPU has to do everything.
Honestly, it seems rather strange to me that it takes a call to the operating system to change a detail of this type with advanced hardware like the one that Thomson computers have.
This because the MO6 (and the Olivetti-Prodest) appeared very late, nearly by the end of the 8bit era. But you are lucky, Daniel has just put on his site a scan of the unpublished MO6 assembly-langage manual. Per se this is not very interesting (this is just the same as the TO8/9/9+ assembly-language), but the good bit is that this document also contains the documentation for the Monitor ROM (SWI or SWI2.)

Reading this I found that there is an API (page 212) to get the status for the CRTL or SHIFT (and even BASIC) keys. I think this should answer one or your questions you asked some time ago (but I couldn't find it atm.. may be I'm just projecting my own wishes. :roll: )
Samuel.
A500 Vampire V2+ ^8^, A1200 (030@50mhz/fpu/64mb/cf 8go),
A500 GVP530(MMU/FPU) h.s., R-Pi, TO9, TO8D, TO8.Démos
spotlessmind1975
Messages : 66
Inscription : 24 oct. 2021 15:47

Re: ugBASIC est arrivé sur Olivetti Prodest PC128!

Message par spotlessmind1975 »

It has some innovative features like the 40906 color palette, but also has it drawbacks like a complicate way to access adjacent columns in 160x200, no hardware sprite, not even a simple PSG. So the CPU has to do everything.
If you think the way to access 160x200 mode is complicated, you have to see that they came up with the ZX Sinclair. :roll:
Daniel has just put on his site a scan of the unpublished MO6 assembly-langage manual. Per se this is not very interesting (this is just the same as the TO8/9/9+ assembly-language), but the good bit is that this document also contains the documentation for the Monitor ROM (SWI or SWI2.)
Very interesting! Just a curiosity: is there a reason why the "djvu" format is used and not the "pdf" format? I searched the forum and it seems to me to be linked to a question of space occupied with the same quality. Is that so?
Reading this I found that there is an API (page 212) to get the status for the CRTL or SHIFT (and even BASIC) keys. I think this should answer one or your questions you asked some time ago (but I couldn't find it atm.. may be I'm just projecting my own wishes. :roll: )
It would be nice to have the time to reverse engineer the routines contained in the ROM, document them and maybe "extract" them, to make them recompilable directly, without using SWI. I think this is my projection of a wish. 8)
__sam__
Messages : 7925
Inscription : 18 sept. 2010 12:08
Localisation : Brest et parfois les Flandres

Re: ugBASIC est arrivé sur Olivetti Prodest PC128!

Message par __sam__ »

Yeah, DJvu has better compression factor. If I "print the djvu" to a PDF document the size increase from 1mb to 150mb.

The commented source code for the MO5 rom is available there (in french). For instance here is the source-code to read the keyboard: http://dcmoto.free.fr/documentation/mon ... ch_src.txt
Dernière modification par __sam__ le 01 nov. 2021 10:40, modifié 1 fois.
Samuel.
A500 Vampire V2+ ^8^, A1200 (030@50mhz/fpu/64mb/cf 8go),
A500 GVP530(MMU/FPU) h.s., R-Pi, TO9, TO8D, TO8.Démos
Daniel
Messages : 17320
Inscription : 01 mai 2007 18:30
Localisation : Vaucluse
Contact :

Re: ugBASIC est arrivé sur Olivetti Prodest PC128!

Message par Daniel »

[Out of scope] A new tool is available to browse DjVu files online : https://djvu.js.org/
This is a workaround for the incompatibility of old plugins with modern browsers.
It is available as an extension for Firefox or Google Chrome : https://djvu.js.org/extension
Daniel
L'obstacle augmente mon ardeur.
spotlessmind1975
Messages : 66
Inscription : 24 oct. 2021 15:47

Re: ugBASIC est arrivé sur Olivetti Prodest PC128!

Message par spotlessmind1975 »

Thanks to everyone for the advice and directions.
I am seeing on github your interesting suggestions, and I will certainly read those books shortly.

Today I finished support for "image arrays" integrating it with multitasking support.
I am happy to tell you that the mo6 target was one of the first that I tested, to verify that everything worked.

I hope you like the result!

(it is a small tutorial to explain better, Olivetti Prodest 128 is the first target seen, then the Commodore 64 and the Dragon 32)

Edit:
About TI support under MO5:
Note this ISR is running at 50hz, and it seem a 60hz interrupt is assumed (TI/60 in the basic source). It is possible to emulate this by incrementing MO5TIMER by 1.2 instead of 1 (*), but may be you plan to introduce some kind of global system-constant (say TI_HZ) indicating the frequency of change of the TI variable on the machine ?
I added this ticket to track the (very important) question, which actually arises from dealing, for the first time, with the NTSC vs PAL problem:
https://github.com/spotlessmind1975/ugbasic/issues/191
Répondre