Commander X16

It's a bit too much code to follow along but the problem seems related to something the mandelbrot() function is doing.
When I remove the "if history < 31 history++" line, the behavior changes

Tip: perform the process of elimination. Remove stuff from your program that's not related to the mouse control, and see if you can find the thing that causes the interference this way.

It doesn't seem to be a prog8 issue perse, but some interaction in your program logic or interference in variables

desertfish wrote: ↑Wed Nov 01, 2023 6:56 pm It's a bit too much code to follow along but the problem seems related to something the mandelbrot() function is doing.
When I remove the "if history < 31 history++" line, the behavior changes

Tip: perform the process of elimination. Remove stuff from your program that's not related to the mouse control, and see if you can find the thing that causes the interference this way.

It doesn't seem to be a prog8 issue perse, but some interaction in your program logic or interference in variables

Interesting, okay, I'll take a look!

yock1960 wrote: ↑Wed Nov 01, 2023 9:42 pm

desertfish wrote: ↑Wed Nov 01, 2023 6:56 pm It's a bit too much code to follow along but the problem seems related to something the mandelbrot() function is doing.
When I remove the "if history < 31 history++" line, the behavior changes

Tip: perform the process of elimination. Remove stuff from your program that's not related to the mouse control, and see if you can find the thing that causes the interference this way.

It doesn't seem to be a prog8 issue perse, but some interaction in your program logic or interference in variables

Interesting, okay, I'll take a look!

Yeah, although I don't quite understand why, the history/status() subroutine was the problem. It was a problem getting it working originally...logic issues...I have gotten rid of it in my latest incarnation, where I use the GUI interface. This older version I used to get the code size down, in order to get it to run from the shell, a bit more easily.

Speaking of the shell. I can see that you have more plans for it, since you set $4000 as the start for external 'commands', leaving a fair gap between the end of 'shell' space and $4000. It's hard for me to judge without having the actual hardware (sometime 1st quarter next year!), but code loads so fast now...in the emulator, but any thoughts about making all commands external, to maximize code space? Personally, I like the shell environment much better than BASIC. It would be really cool to have such a thing in ROM...as an alternative...

Here is some unexpected behavior, that I haven't been able to code around. Works as expected using version 9.4.2, but not with 9.5.1 (nor I think with 9.5). Zeropage options are set to basicsafe.

The Prog8 source line:

cx16.GRAPH_set_colors(object.opt1[n] as ubyte,object.opt1[n] as ubyte,0)

object.opt1[n] is declared as a uword.

The 9.5.1 assembly code generated:

ldy #0
lda p8_n
asl a
tay
lda p8_object.p8_opt1,y
ldx p8_object.p8_opt1+1,y
stx P8ZP_SCRATCH_REG
ldy P8ZP_SCRATCH_REG
tax
lda p8_n
asl a
tay
lda p8_object.p8_opt1,y
ldx p8_object.p8_opt1+1,y
stx P8ZP_SCRATCH_REG
ldy P8ZP_SCRATCH_REG
jsr cx16.GRAPH_set_colors

Here is the assembly generated by 9.4.2:

ldy #0
lda p8_n
asl a
tay
lda p8_object.p8_opt1,y
tax
lda p8_object.p8_opt1+1,y
tay
txa
tax
lda p8_n
asl a
tay
lda p8_object.p8_opt1,y
tax
lda p8_object.p8_opt1+1,y
tay
txa
jsr cx16.GRAPH_set_colors

I think this is fixed in the upcoming new release version of the compiler.
You can already try it yourself by downloading the latest build artefact from Github https://github.com/irmen/prog8/actions? ... h%3Amaster

Prog8 version 9.6 has been released https://github.com/irmen/prog8/releases/tag/v9.6

desertfish wrote: ↑Sun Nov 12, 2023 10:57 pm Prog8 version 9.6 has been released https://github.com/irmen/prog8/releases/tag/v9.6

No joy.

The three recent projects that I have tried, using this have all failed to run and one failed to compile. They all use my GUI library code, they all work using 9.4.2, but not 9.5.x for reasons stated above. When using 9.4.2 and possibly earlier versions, I have noticed a few times when I do my simple debugging by adding %asm{{stp}}, that this fixed a crash, so I would add a %asm{{nop}}. I don't know what causes this and am not much more knowledgeable about why the extra byte fixes it! Maybe it would ring a bell for you? Anyway, my latest project required this (9.4.2), in 9.6.0, it makes no difference either way.

I will see if I can figure anything useful out tomorrow. Here is the error that was generated when the compiler choked. That program is the largest of the three.

Some better news. The program that I posted about above, now works correctly using 9.6.0. It also uses the GUI code. So, it's something new....tomorrow...

Non-functioning apps appear to be related to the gfx2 library. Programs that I have compiled using gfx2, all do not initialize graphics successfully, ones using the graphics library or the frame buffer routines through syslib work okay. Why is beyond me.

Now to see if I can find what is causing the v9.6.0 compiler to generate the internal error that is generated by one specific source file.

In 9.5 the gfx2 library had its screen mode numbering changed. I think I forgot to mention this in the release notes, sorry for that. This is the current list:

; SCREEN MODE LIST:
; mode 0 = reset back to default text mode
; mode 1 = bitmap 320 x 240 x 256c (8 bpp)
; mode 2 = bitmap 640 x 480 x 4c (2 bpp)
; mode 3 = bitmap 320 x 240 x 4c (not yet implemented: just use 256c, there's enough vram for that)
; mode 4 = bitmap 320 x 240 x 16c (not yet implemented: just use 256c, there's enough vram for that)
; mode 5 = bitmap 640 x 400 x 16c (not yet implemented)

This is likely the problem for older code no longer working with gfx2.

The compiler crash is pretty weird, I am quite sure I fixed the problem you had before in the 9.6 release. Ofcourse, there might be another new or different case. Do show some code that reproduces the problem so I can make a fix for it