+bhall408 Posted May 22, 2021 Share Posted May 22, 2021 I struck gold last weekend and found a 3.5" floppy disk containing the sources for all the Atari ST projects I had done back in the day. Earlier in the month, I thought the disk had gone bad, as my newly acquired 1040ST wouldn't read it, but then I popped in in a Mac -- lo and behold, it was Mac formatted. I must have made it as a backup when I transitioned from working on the 1040ST to going to a Mac Plus. A few projects were missing the .RSC files, but I have the app binaries, so worst case I could re-create them. The big kahuna/find is the Atari ST version of BBS software I'd worked on in the 80s called Plexus (myself and the other auther have also been working on getting the 8-bit version to compile). All the other projects were various MIDI utilities I'd written for myself, as I was in a band at the time, and we used the ST in live performance. Coming back to today... I currently use a Mac as my desktop/development machine. I converted all my old Atari 8-bit projects to ca65 and cc65 and have been *really* happy with that method. While I could try and run Laser C under Hatari, if there is an equivalent to cc65 for ST/68K projects that will run command line on Mac OS, I'd prefer that. I've seen some references to the 80 easy steps to use GCC for Jaguar development. I'm hoping it doesn't come down to that. Or if so, maybe I will try running Laser C under Hatari. Thoughts? Quote Link to comment Share on other sites More sharing options...
IGS GUY Posted July 13, 2021 Share Posted July 13, 2021 I have Laser C 1.1 running under Hatari on Windows 10. I was able to compile IG217A.ACC on it and it worked fine. I had a lot of trouble getting it set up. Old disks, USB floppy not very reliable to write or read good files. Once I knew what was the problem I made the images on a older WIN XP system that has a floppy drive in it using MSA.EXE http://msaconverter.free.fr/index-uk.html It still made on bad file that I know of gembind.h I got that fixed and it worked. You might find this useful also... https://breakintochat.com/blog/2020/09/03/tutorial-telnet-to-a-bbs-using-a-terminal-program-in-the-hatari-emulator In a couple of years or so when I retire I'll have more time for projects, working 50 hours a week I'm just spent when I get home. I have my original 1040STf and a old working hard drive that I wrote Instant Graphics on originally. The ST when I run it with TOS 1.04 it flakes out after it warms up probably solder joint or bad eprom, but it's solid in TOS 1.0 The hard drive is so ancient I'm amazed it's still going had many others that failed. Still have a working Atari monochrome monitor, the color one died long ago. My programming skills are rusty for sure but I could come up to speed pretty fast if and when I get serious about it and have time. Quote Link to comment Share on other sites More sharing options...
+bhall408 Posted July 13, 2021 Author Share Posted July 13, 2021 An update/answering my own question... I managed to get mint on my Mac, which is a 68K cross compiler that can be used from linux (or Mac OS X in my case) command line. I am able to compile (with errors) some of my old projects, but not at the point of them successfully compiling and linking. However this does seem the way to go, is very much like what I do for my 6502 projects with ca65/cc65, and that I'll eventually get there Quote Link to comment Share on other sites More sharing options...
+DarkLord Posted March 17 Share Posted March 17 Resurrecting an old thread - just curious, did you ever get the ST version up and running? Thanks. Quote Link to comment Share on other sites More sharing options...
ggn Posted March 17 Share Posted March 17 (edited) I've never seen this thread before, but better late than ever: There are a few 68k cross gcc packages out there, here's mine: https://github.com/ggnkua/bigbrownbuild-git. It works on Windows, Linux and Mac natively. Edited March 17 by ggn Quote Link to comment Share on other sites More sharing options...
+bhall408 Posted March 17 Author Share Posted March 17 11 hours ago, DarkLord said: Resurrecting an old thread - just curious, did you ever get the ST version up and running? Thanks. Sadly, no. However I like that @ggn chimed in. I'll have to see if that is a viable option for me. Part of the work is updating the C code to the C-89/ANSI standard (which I happen to like/prefer, but the code is a mix of pre-89 and post 89). Quote Link to comment Share on other sites More sharing options...
ijor Posted March 17 Share Posted March 17 If you have older, non-ANSI, code, it might be just easier to run the original compiler under emulation. Emulators can map host folders to emulated hard disks. So you don't even need to bother copying your source files between the host and the emulator. Quote Link to comment Share on other sites More sharing options...
+bhall408 Posted March 17 Author Share Posted March 17 1 hour ago, ijor said: If you have older, non-ANSI, code, it might be just easier to run the original compiler under emulation. Emulators can map host folders to emulated hard disks. So you don't even need to bother copying your source files between the host and the emulator. I took that approach with the first old 8-bit assembler project I had resurrected from source. I was glad I didi it, but then after that I moved to updating/modernizing and getting it to assemble with ca65. For a one-off (just to get it to compile, not planning to do more) I think emulating the tool chain could make sense, but I have the feeling I'd be investing a similar amount of time in bringing up/re-familiarizing myself with the tool chain as I would in moving to a new tool chain, and that once I had it compiling, I'd then want to start making the app better Quote Link to comment Share on other sites More sharing options...
mikro Posted March 19 Share Posted March 19 8-bit tools (and their modern counterparts) have far less gotchas than 16-bit ones. For starters, C compilers used to be really stupid and allowed unthinkable things to write (and to work!). Throwing a source code from the 80s at the latest gcc and trying to fix it may be harder than basically just reading the code and rewriting it from scratch. Typical traps: 16-bit ints, different function bindings, different struct members, assuming order of instructions, ignoring the need of volatile and so on and so on. Way easier just to acquire the original compiler and one by one to update the code to at least ANSI C. Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.