Opening a TTY device in MacOS
Can Matrix Brandy successfully open a TTY device (e.g. a USB virtual serial port) in MacOS? When I try to do that in my BASIC(s) it hangs in the OPENUP function, which is bad (not to say, I thought, impossible)!
0
Comments
-
From my point of view, I have never tried; I don't own a USB to Serial dongle, and would need to faff quite heavily with my VM host to try to pipe the thing into a VM to test the virtual Mac.0
-
-
No, it's compile from source. Which version are you running, I'll build you a binary.
Edit: It'll just be the "brandy" binary, from what I see a dmg file is, is a disc image. Producing an image of my disc would be pretty massive, my disc allocation is 100GB...0 -
A .dmg file is the usual means of distributing a Mac application if it needs more than a single executable - which the GUI version of Matrix Brandy presumably does because of its dependence on SDL 1.2 (I'm guessing it would need to come with libSDL.dylib or something similar).It'll just be the "brandy" binary, from what I see a dmg file is, is a disc image. Producing an image of my disc would be pretty massive, my disc allocation is 100GB...
A .dmg file is compressed, so typically not very big (although the compression is less efficient than .zip). For comparison the Windows edition of BBCSDL is about 20 Mbytes as a .zip and the MacOS edition about 24 Mbytes as a .dmg.
If what you're proposing to supply is the Console version of Brandy (sbrandy?), with no dependencies, then a single binary executable should be fine. I've never known the OS version to matter as far as application compatibility is concerned (so long as it's post MacOS becoming 64-bits only).
0 -
I tried building a static-for-SDL build, but then the linker couldn't pull in any of the Cocoa stuff (if that's what it's called) for the GUI, and I've drawn a blank trying to manually reference it on the clang command line.
Still, for device opening, you might be able to get some mileage with a text build, so I've put one up at http://brandy.matrixnetwork.co.uk/testing/MatrixBrandy-1_22_15.dmg0 -
Might something similar to this magic from my Mac build help, which as I understand it tells the loader to pull libraries in from a different place:I tried building a static-for-SDL build, but then the linker couldn't pull in any of the Cocoa stuffinstall_name_tool -change @rpath/SDL2.framework/Versions/A/SDL2 "@executable_path/../Frameworks/SDL2.framework/Versions/A/SDL2"
1 -
That seems to have done it! Thank you. I've replaced the DMG at the link in my previous post.0
-
Yes, that seems to run fine on my 'Apple Silicon' (M1 CPU) Mac Mini, with Rosetta 2 doing its usual excellent job of emulating an x86-64. And, yes, it hangs in OPENUP just the same as mine, which I'm rather pleased about!That seems to have done it! Thank you. I've replaced the DMG at the link in my previous post.
It's a Raspberry Pi Pico that I'm trying to connect to (works fine on Windows, x86 Linux and PiOS) and I notice that the LED on the Pico stops flashing at the same time as OPENUP hangs, so it may be some incompatibility at the USB level.
I might try with a more conventional USB serial interface to see if that works any differently.
I assume that, generally, Brandy communicates with a serial-type device without any particular problems?0 -
It's not something I've tried.
Does a basic terminal emulator (if such a thing exists in the Mac world) work to talk to your Pico?0 -
Does a basic terminal emulator (if such a thing exists in the Mac world) work to talk to your Pico?
I don't know any more about Macs than you (probably less) but Google finds that, not surprisingly, there are serial terminal emulators. Trying one, it does successfully connect to the Pico, so the plot thickens. Hanging in fopen() is definitely not normal.
0 -
This explanation here sounds like what you're encountering...
https://forums.livecode.com/viewtopic.php?t=32133#p176272
And the post immediately below it goes into more detail.
Have you tried the instance of the port starting /dev/cu.<whatever> ?0 -
-
I can open the port, seemingly for both read and write, by replacing tty with cu, as suggested there, and it doesn't hang! So that's certainly progress.Richard_Russell wrote: »I'll try asserting DTR as suggested there
However whilst I can then successfully read data from the Pico I don't seem to be able to write it. That is, I can use BPUT# and it appears to work (and it doesn't hang) but I never get a response from the Pico to what I've attempted to send, so most likely it's stuck in a buffer.
I've tried using ioctl to set various modem control signals, and whilst the call succeeds it doesn't seem to make any difference (even once I'd bypassed the gotcha that TIOCMSET, which is defined as 0x8004746C, is a positive value so mustn't be sign-extended to 64 bits).0 -
Can you fflush() your channel?0
-
That would probably fix it, but it was a silly mistake. I was testing on my M1 (Apple Silicon) Mac, because it's so much faster than the x86 machine, but I'd forgotten to update BBC BASIC for SDL 2.0 to the latest release, which uses unbuffered I/O.Can you fflush() your channel?
Having now updated it, everything works (without calling fflush()). It doesn't even seem to need the modem control lines to be written, although I've left that code in the program (REMmed out) in case that ever is necessary.
So now I have BBC BASIC code to upload files to the Pico, using the *yupload (Ymodem) command added to the Pico edition of BBC BASIC by Memotech-Bill, which works on every desktop platform (using either BBCSDL or the Console Mode editions).
1 -
Nice one, well done getting it working!0