Hello! smf wrote: > It's not emiting code that is not compatible, it's linking libraries > that aren't compatible. You don't need to link against those libraries, > you can write your own. You're right. It was a kind of thinking shortcut I made. I have never created C libraries before, so... there always must be a first time ;-) Another alternative would be to write a MS-DOS 2.x function wrapper for MS-DOS 1.25. Basically it would have to translate filehandle API to the FCB API, and possibly some other stuff as well. I have no idea how feasible it would be. > I doubt there is a C compiler that targets DOS 1.25 out of the box. I haven't found anything like that either. So far I made Microsoft BASIC compiler 1.0 to work on the machine, by hacking a crude INT 10h and INT 16h implementation :-) > But > I also doubt it would be that hard to hack together a runtime library > that would allow you to run cbmbasic at least in interactive mode > (without access to files). Which will at least give you an idea whether > it's worth finishing. But then, how about using something like Turbo C? If the I/O library is using only INT 21h to handle console input/output, then it could be possible to make it work. Accessing files would of course not be possible. > If you can get an emulator for it then I'd be happy to help out. I suppose we could run it in a DOSBox with a kind of interrupt overlay which would catch all interrupt calls that are not present in the Commodore MS-DOS? Regards, Michau. Message was sent through the cbm-hackers mailing listReceived on 2017-10-09 13:00:02
Archive generated by hypermail 2.2.0.