holly@tut.cis.ohio-state.edu (Joe Hollingsworth) (08/26/88)
I need to port some C code from IBMPC to Apple II.
The only C compiler that I've found for Apple II is by Manx Software
Systems, called Aztec C. Has anybody had experience with
Manx Software systems and Aztec C? Thanks for any comments.
Joe Hollingsworth Computer and Information Science @ OSU
holly@cis.ohio-state.edu or ...!{att,pyramid,killer}!cis.ohio-state.edu!hollybill@carpet.WLK.COM (Bill Kennedy) (08/26/88)
In article <20752@tut.cis.ohio-state.edu> holly@tut.cis.ohio-state.edu (Joe Hollingsworth) writes: > >I need to port some C code from IBMPC to Apple II. >The only C compiler that I've found for Apple II is by Manx Software >Systems, called Aztec C. Has anybody had experience with >Manx Software systems and Aztec C? Thanks for any comments. I do this routinely with the Manx tools. I first got Aztec for the ???86 because it appeared to be the only development set for generating ROM code. I had had terrible experience with Computer Innovations (it was clear that they had done A ROM, but not even SOME ROM's) and Microsoft. Manx probably isn't the fastest compiler for the PC and it's certainly not the most popular, but it has been the most portable for me. I have found a lot of usenet code that would go straight into Aztec (with the expected mods for pointers and integers) and Aztec code that went straight into UNIX. Their system is very good about that. I can not say the same for other more popular compilers. I also do a lot of Z80 development with Aztec. I prototype the application using the PC version and tools, then make a minor change to the makefile and I'm in the target system. If your PC code is developed and fully functional on a PC, in Aztec, then you have an excellent chance of seeing it just drop into the Apple and work (If you can figure out how to electrically get the code *into* the Apple). I have had no trouble with stdio between MS-DOS and PRO-DOS or CP/M for that matter. There are nicer and prettier packages available but I've found none more reliable. One down check on Manx though. Their tech support can waste a lot of your time. There is one particular technician who is a menace. You describe your problem and they indicate that they understand and they sound like they really do. You get a proposed solution, try it, it doesn't work and call back. You can get through about four (time consuming and unsuccessful) iterations before you realize that they are guessing. You can avoid that by insisting on speaking with the author or the software engineer responsible for that function but you'll get a lot of resistance from the first line "experts" who answer the phone (when it isn't busy). Also, check and make sure that you get everything that they say you should have and check each program for the desired/expected results. I have gotten defective pieces that were screwed up by manufacturing. It's a frustrating chore to write your own binary to hex converter because they can't figure out why theirs doesn't work. If you want snappy, cutesy, color, windowed stuff then Aztec is not for you, forget the Apple and get Microsoft or Turbo. If you need reliable, portable, repeatable code, then you can't do much better than Manx. Sorry for the length, but there are some deep holes out there that we should avoid when possible. My footprints are in several of them. -- Bill Kennedy Internet: bill@ssbn.WLK.COM Usenet: { killer | att | rutgers | uunet!bigtex }!ssbn!bill
cramer@optilink.UUCP (Clayton Cramer) (08/30/88)
In article <20752@tut.cis.ohio-state.edu>, holly@tut.cis.ohio-state.edu (Joe Hollingsworth) writes: > > I need to port some C code from IBMPC to Apple II. > The only C compiler that I've found for Apple II is by Manx Software > Systems, called Aztec C. Has anybody had experience with > Manx Software systems and Aztec C? Thanks for any comments. > > Joe Hollingsworth Computer and Information Science @ OSU I've used the Aztec C compiler for the PC several years ago, and my impression was not favorable. The PC keyboard has a number of keys that generate two characters (00 xx) for a key code. Typically these are arrows, function keys, etc. When I read a keystroke with getchar, it returned only one character -- the second one. There was no way to distinguish what I received from the normal ASCII character with the same code. It struck me as a problem of someone porting over the getchar function to the PC hardware and not looking carefully enough at the funny codes generated by that keyboard. It was hard to get much enthusiasm for trusting the rest of the compiler after such an obvious screwup. Clayton E. Cramer