test is  a "test" command I use to check things out. It has no parameters and no error checking. At the moment it returns the state of the noaudio setting when you run MMBasic

  matherp said  

test is  a "test" command I use to check things out. It has no parameters and no error checking. At the moment it returns the state of the noaudio setting when you run MMBasic

OK, thanks Peter, just like me to stumble across it .

Best wishes,

Tom

Puzzled by need to set first line printed with TEXT at other than 1 in order not to have top lines scrolled off.

For Paul_L's display using PC graphics drawing characters, when using scale to make the display as large as he wants, I have to set the first line at 7 when scale is 2, or at 13 when scale is 1. The program sets mode 16 and font 4.

Display with scale=2, first line is 7 (this is the way Paul wants it to look):



Display with scale=1, first line is 13:



Here's what it looks like with scale=2, first line = 1 (it's similarly off the screen with scale=1 and first line = 1):



Here's the code:


Here's the file I'm reading zipped:
g9_display.zip

Here's the result of OPTION LIST:



If it's significant, my display resolution is 1600x900.

The issue is similar if I use mode 15 and font 1.

I don't see what I'm doing wrong.

~
Edited 2022-07-05 00:48 by lizby

This is a known issue and happens when the mode size is >= to the actual physical display size.
Try setting the mode to a minus value to use full screen mode or chose a mode smaller than your physical screen

Is PLAY TTS supposed to work in MMBasic for Windows? Everything I try gets the error "Syntax", for instance PLAY TTS "1" or PLAY TTS "one".

  Quote  

Is PLAY TTS supposed to work in MMBasic for Windows?

No

One of the Challenge '22 programs written for the CMM2 didn't display properly in MMBasic for Windows. It wrote some invisible text, then read it back pixel by pixel, and if the pixel was non-black (<>0) wrote it in another place as a sprite at maybe 8 times the size.

Under MMBasic for Windows, it wrote sprites for all pixels, whether blank or not. When I looked at what it was reading as PIXEL(x,y) for what was expected to be a blank pixel, I got 4278190080. I tried writing a pixel as RGB(BLACK) and reading it back and got the same value.

I got the program to display correctly by checking pixel value <> RGB(BLACK) instead of <>0.

My question is, what is the reason for RGB(BLACK) not being equal to 0 under MMBasic for Windows?

  Quote  

My question is, what is the reason for RGB(BLACK) not being equal to 0 under MMBasic for Windows?

Because that would have a transparency of 0 and wouldn't show as the windows is always ARGB8888

Ah, I see. Thanks.

If I print ? hex$(rgb(black)) I get FF000000. That makes more sense than printing it as decimal.

I realise MMB4W is dormant at the moment, but bug?



But on the PicoMiteVGA:



Best wishes,

Tom
Edited 2022-10-04 19:10 by thwill

Try this b11


MMBasic.zip

  matherp said  

Try this b11

MMBasic.zip

Thank you Peter, you've fixed that, but a recent addition to the MMB4L firmware test-suite has revealed another issue:



Running this will immediately crash-out MMB4W, note that it is crashing out whilst loading the program into the program memory not whilst it is interpreting it.

I believe it should instead be generating the error "Name too long" during interpretation.

You might want to check the PicoMite too, I haven't got my test framework running on that yet ... I will need to customize the firmware.

Best wishes,

Tom
Edited 2022-10-05 01:06 by thwill

  matherp said  

Try this b11


MMBasic.zip

Crash after:
>load "grain.bas"[ENTER]
>run [ENTER]

b10 works fine

Michal

Please opening grain in the editor and then f2 to exit and run - let me know what happens

>load "grain.bas"[ENTER]
F4
F2 working
but after:
>run [ENTER] crash

Michal

I am having trouble with any program I load , after I type run , crash back to windows.p

Try typing any command and then RUN fname$

e.g.
font 1
run "grain"

>font 1[ENTER]
>run "grain"[ENTER] - working
>run "grain"[ENTER] - working
>run[ENTER] - crash
====================
>run "grain"[ENTER] - crash

Michal
Edited 2022-10-05 03:50 by Michal

The problem is in some code I added to try and solve a bunch of issues Tom had passing parameters to MM.CMDLINE$ as documented in the previous page of this thread. I can back these changes out but that leaves the issues there. For the moment stick to b10 - almost no other changes of note

Tom: if you want to help solve the issues let me know.

  matherp said  

The problem is in some code I added to try and solve a bunch of issues Tom had passing parameters to MM.CMDLINE$ as documented in the previous page of this thread. I can back these changes out but that leaves the issues there. For the moment stick to b10 - almost no other changes of note

Tom: if you want to help solve the issues let me know.

I was confused for a minute, but I now see that you never issued a beta with those command-line flag fixes until today in response to my latest (but one) bug report.

Are you requesting that I do some testing and diagnosis for you ? or for me to try and fix the problems myself ?

If the latter then I need access to the b11 source-code. I'd ask you to push it to a new branch in your MMB4W github but I know how git adverse you are . Can you suggest an alternative ?

Also note there will be a delay as (a) my only Windoze machine has an earlier Visual Studio tool-chain and (b) I'm not very familiar with the Visual Studio tool-chain in the first place. No, I can't upgrade as this is a day-job machine and needs to be using the same tool-chain versions as my colleagues.

Best wishes,

Tom
Edited 2022-10-05 04:30 by thwill