This has changed the version to b22 so you can be sure


MMBasic.zip

Minor: adapt copyright date to 2023 -or- 2024

Volhout

Sorry Peter, This what I see. I am running it from MMEdit but I don't see how that could affect anything.



Same program with MMBasic DOS



This program still crashes MMB4W.



Bill

What is the zero when you start up? Have you got something running - try deleting .options

The zero comes from running the program at startup, MMEdit runs the program when it starts MMB4W. It's the same zero that you see after I type RUN. I have no strange OPTIONS set I believe.

One thing though, the program being run is not in my default directory it is in a subdirectory of /micros > /micros/MMB4W but I can't see how that can have any bearing. But...



Sorry off to bed now.

Bill

Not seeing a problem. Sending "hello" at 10mS intervals from a PicoVGA MMB4W receives ok.
Pico

MMB4W


Edit
Down loaded the latest 5.070322 .exe and same result.
Output from another program.

Edited 2023-12-21 22:29 by phil99

  Quote  

Not seeing a problem.

Sorry, but I still can't get it to work.
Works OK from the command line as per Phil but not in a program.



Running in a program does send to the cmm2 and the receive buffer gets the data returned but unable to retrieve from the rx buffer.



Jim

Edit:
If you use
INPUT #8, test$
it works OK so the problem is with the INPUT$(nn,#x) command.
Edited 2023-12-22 06:40 by TassyJim

I wonder if the print test$ could be fooling you...

What is len(test$)?

How about getting each char out of test$ and printing its asc() value in case there's ... I don't know, something in there?

INPUT and INPUT$() are somewhat different. E.g. they stop reading for different reasons and so don't return the same chars.

John
Edited 2023-12-22 07:01 by JohnS

INPUT$() seems to work ok at the command line.

I don't want to use this in a command line I need to use it in a program. The very same program works in MMBasic DOS. Same port, same program and the same input source.

For my tests the MM2 is sending "Hello from the MM2" continuously with a 10mS gap. This not a real test of what I want to do, I only want to send a few characters at a time spasmodically, say from a joystick.

Perhaps, because the MM2 is sending this repeatedly at a rapid rate, is it filling up the coms buffer before I run the MMB4W program and this is causing MMB4W problems. So perhaps a more "real world" type test would be more appropriate. But it works with MMBasic DOS.

I'm not sure how much more I can go with this until after Christmas. My MM2 device has no I/O so maybe I can try a CMM2 with a joystick sending a message only when the joystick is operated.

Bill

PS I know that calling "MMBasic DOS" just that is not really correct because it is really running in Windows but I'll continue calling it that to differentiate between it and MMB4W.

The following works fine for me - note I am running MMB4W under wine on Mint Cinnamon. For this, com ports come up as COM33, COM34 etc (equates to ttyACM0 and ttyACM1 respectively under linux). I have the two ports connected back to back in 2 microbridges (COM33/ttyACM0 Tx to COM34/ttyACM1 Rx).


... so, nothing wrong that I can see?
Doug.

  Turbo46 said  

For my tests the MM2 is sending "Hello from the MM2" continuously with a 10mS gap.

Is it sending CR and/or LF as well?

You PRINT in the MMB4W listing without ";" (semi-colon) - is that confusing maybe?

John

Thanks Fellas.

John, I don't know whether MMBasic terminates a PRINT with <CR> or <LF> or <CR><LF>. I think from memory it is just <CR>. I did use a hex editor on a file written to by MMBasic but I don't remember what I found now. I would expect that one version of MMBasic would be compatible with another. I don't think the semi-colon is an issue.

Doug, Thanks for your test but if it does do anything for me it strengthens my suspicion that, for my test, the com buffer is being filled before MMB4W even gets to it and that is causing MMB4W problems. I need to try a more real world test when time permits.

But it works with MMBasic DOS.

Bill

I think I have gone as far as I can with this.

works



fails

The only difference is the second code uses test$ as the variable name.

Baa Humbug...
Jim

This works quite well. Sending Bin$ to make it easier to see what is happening. Change to Hex$ for practical use, adjusting receive end to match.


Edit.

Edited 2023-12-22 13:00 by phil99

Hmmm. The plot thickens. Maybe the variable name TEST is part of some internal debugging code:


The first zero is because the program is run immediately it is loaded.

It does work on MMBasic DOS.

Bill

So I changed the name from test$ to a$ and ran it again.



As you can see it doesn't print zero now but prints nothing. Again it does work on MMBasic DOS.

I wonder if MMBasic DOS empties the com buffer as it opens the port while MMB4W doesn't?

From that and TassyJim's test it does seem the TEST is some kind of internal variable that overrides it's use in a program.

Bill

"test" is used as a variable name in the source code in commands.ccp and one of the json files.
Perhaps it has escaped it's local status and become global.

  Quote  

I wonder if MMBasic DOS empties the com buffer as it opens the port while MMB4W doesn't?

I wondered about that. If I stop and restart my MMB4W program (a few posts above) sometimes the lower characters remain static while the higher characters count up at the rate that the lower characters should, suggesting there are already a few in the receive buffer.
It's also possible the program started mid-transmission, it has no means of getting back in step. Discarding the first input$ might be a solution.

Adding CLEAR to the start of the program seems to fix it, though might be just luck.

Edit
So far this seems ok,

Edited 2023-12-22 15:01 by phil99