Any interest in Catalina on Mac OS X?
RossH
Posts: 5,511
This one is for the Apple fans ...
Catalina is currently supported on Windows and Linux. Several people have reported porting it successfully to OS X but no-one has sent me details of what (if any) changes they had to make to get it working - so I thought I'd have a go myself.
The good news is that I now have both Catalina and Code::Blocks running under OS X - but the bad news is that I'm stumped on getting the #@$#%$ serial ports to work! I have no access to any genuine Apple hardware, so I run OS X under VirtualBox. But this is not really a supported configuration, and the serial port support seems to be broken.
Before I waste any more time on it, I thought I'd ask a few questions:
Ross.
Catalina is currently supported on Windows and Linux. Several people have reported porting it successfully to OS X but no-one has sent me details of what (if any) changes they had to make to get it working - so I thought I'd have a go myself.
The good news is that I now have both Catalina and Code::Blocks running under OS X - but the bad news is that I'm stumped on getting the #@$#%$ serial ports to work! I have no access to any genuine Apple hardware, so I run OS X under VirtualBox. But this is not really a supported configuration, and the serial port support seems to be broken.
Before I waste any more time on it, I thought I'd ask a few questions:
- Is there is any real interest in an OS X version of Catalina? There is not much point if no-one will ever use it.
- Is anyone with access to a real OS X platform interested in getting the Payload serial loader working?
Ross.
Comments
2) I don't have much experience in programming under the Mac OS. I would be happy to help test.
Count me in.
Kenny
It would be a bit hard to justify a separate OSX release on these numbers, but I will certainly include the patches required to get LCC working under OSX into the next official Catalina release. Catalina itself doesn't require any change, but I did spend some time eliminating various warnings generated when compiling under OSX.
I've also confirmed that Homespun runs fine on OSX (under mono), so building and running LCC and Catalina under OSX is really no more complex than it is under Linux (in fact the build procedure is identical). Building Code::Blocks is a little more challenging - even if I don't do a full distribution, I may end up providing my own binaries (as I do for Windows and Linux) since I think building this would be beyond most casual OS X users.
But what I really need to make it usable is someone who can get the serial port handling working. The serial library Catalina uses is readily available (here). This library works well under Windows and Linux, and should be able to be made to work under OSX - it is actually just a very thin shell around a bunch of standard Unix calls (tcsetattr/tcgetattr/open/close/read/write/ioctl - all of which are available on OSX). But while the package compiles ok, it doesn't work for me.
So far all I've done with it is replace __linux__ with __APPLE__, remove the non-supported baud rates, and change the names of the serial ports to match the OSX port names - this makes it compile, and I thought this would be enough to get a simple test programs working (there is one on the page linked above) but so far no luck - and I'm not sure whether the problem is with the library or with my dodgy "virtualbox" implementation of OSX (or perhaps both).
I plan to continue to mess about with Code:Blocks, but if someone can get that serial library working, then an OSX version of Catalina becomes a real possibility.
Ross.
Apple claims osx is 100% posix compliant, but I've seen other things that claim the same thing that don't compile/work on osx, so apparently, there's different levels of compliance.
Anyhow, count me in as one of the folks that would like to see a port, and I'll help where I can.
Unfortunately, my macbook went belly up a year or so ago, so all I have at the moment is a minimac running 10.4 (tiger) and no space to install 10.5 (leopard) so anything I make work may or may not work on newer versions of osx, but at least it will be a start. I know snowleopard seems to have changed a lot of the internals in it's bid to be 64-bit, but I'm thinking basic things will still work, though I suppose I could ask for some testers on a few mac-related lists I'm on, to see what (if anything) needs fixed if I can get it working here first.
As long as you don't need graphical stuff from me I'm fine.
hth.
Hi softcon,
Apart from the serial code used in the payload loader, I have a version of Catalina that runs on OSX. My only problem is that I don't have access to a real Mac of any description - only a virtual one (which uses a hacked version of OSX!). But the serial ports don't seem to work at all in my virtual version of OSX, so I need help from someone with real Mac hardware.
If you could get the serial library Catalina uses working under any version of OSX then it will probably work under all versions. So the place to start is with the original serial library (available here). It's quite small - it really is just a few wrapper functions around some supposedly POSIX compliant function calls.
Below is a slightly modified version of the example program given on that page - if you can get this working under your version of OSX, then we'd be 90% of the way there!
/************************************************** file: main.c purpose: simple demo that receives characters from the serial port and print them on the screen **************************************************/ #include <stdlib.h> #include <stdio.h> #include <unistd.h> #include "rs232.h" int main() { int i, n, cport_nr=0, /* /dev/ttyS0 - these names may need to change under OSX!!! */ bdrate=9600; /* 9600 baud */ unsigned char buf[4096]; if(OpenComport(cport_nr, bdrate)) { printf("Can not open comport\n"); return(0); } while(1) { n = PollComport(cport_nr, buf, 4095); if(n > 0) { buf[n] = 0; /* always put a "null" at the end of a string! */ for(i=0; i < n; i++) { if(buf[i] < 32) /* replace unreadable control-codes by dots */ { buf[i] = '.'; } } printf("received %i bytes: %s\n", n, (char *)buf); } usleep(100000); /* sleep for 100 milliSeconds */ } return(0); }Ross.
Because of the dynamic and parallel nature of a Mac OS X system, a device may receive a different device-file name every time the I/O Kit discovers it. For this reason, you must search the I/O Registry for the device you’re interested in to get the current device-file path before you attempt to access the device instead of hard-coding a device-file name, such as /dev/cu.modem or /dev/rdisk0, in your application. When you have the correct path to the device (including the device-file name), you then use either POSIX functions, such asopen andclose, to communicate with a storage device or the POSIX termios API for traditional UNIX serial port access to a serial device. For serial devices, data is also routed through PPP via the device file.
This would seem to indicate the approach used by your serial lib isn't going to behave as expected on osx.
Of course, what the docs say, and how things work in practice aren't always that clear cut.
I'm going to go grab the source to minicom, and see how it handles the serial ports under osx, and that should let us figure out if it's truly necessary to jump through such hoops. On the other hand, someone could ask the developer of BST (which I use for downloading programs to my stamp) to see how it was handled there.
I'm thinking it's not as difficult as the documentation makes it sound, but perhaaps it's at least partially responsible for the reason you couldn't get it working under your virtualized copy of osx.
Add to that the fact that apple takes a very dim view of developers putting ifdef statements in their code to identify apple osx versions. More than one developer has been not so gently reminded that osx is posix compliant, and thereby needs no such checks. I recall a discussion that took place a few years ago I participated in where apple downright refused to admit there was any such identifier, because folks were trying to write code for multiple systems, and were using __APPLE__ as an identifier, and were told by apple engineers that this is not standard behavior, and is likely to break in future osx versions. We were basically told to use posix compliant calls, and not try to identify apple machines directly. Though, I can't see how that would work in this case, since ports and data rates are rather important for the app to work.
Anyway, I'll write some code for testing, and see what works, and what doesn't, and we can work from there. Searching the apple mailing lists may turn up something as well, perhaps their stance has changed since that conversation took place, and a quick search can turn up the proper method for identification, and how to talk to the /dev devices without having to find the silly thing everytime.
Hi softcon,
Thanks for investigating this - Apple does indeed appear to have very strange support for serial devices. Just another of their many bizarre quirks, I guess. But regarding the __APPLE__ symbol, I understand that the combination of __APPLE__ and __MACH__ is the "recommended" way to conditionally code for OSX (I mean "recommended" by open source developers, not by Apple!).
As for the strange idea that the serial port names could change dynamically, on OSX we may have to add some code to enumerate the ports rather than simply hard-coding the names. Or we could use a simple configuration file that a user could edit appropriately to suit their machine. At the library API level either would be ok, since it always uses port numbers and not port name.
Ross.
Has there been any progress in porting Catalina C to the MAC OS X?
Thanks
rich
Not that I am aware of. The current version of Catalina and Code::Blocks compiles and runs fine under OS-X Lion, but the serial port stuff - e.g. the Payload serial loader - doesn't work (to be more correct, it may work - but non-one who owns a Mac has ever tested it and reported back).
As I understand it (not being a Mac-freak) the Mac does not come with any serial port support at all. You have to buy an external USB to serial adaptor (I am not sure if Apple even makes one of these, but I bet if they do it costs a zillion dollars + tax. Fortunately there are lots of "generic" ones available based on the PL-2303 chip). Then you need a suitable driver (again, I don't think Apple provides one, but fortunately there is an open source driver on SourceForge). Here is a "how to" that might help if you want to try it.
Earlier in this thread is a simple C program that should be able to be made to work via this method. If you can do so, let me know. That's all that's required to get Catalina fully supported on a Mac.
Ross.