Modern Development Tools and Workflow

[pixelmischief]

I would like to start a development project on the Atari Falcon and to that end I am looking for help gathering tools and adopting a workflow. The language is C, the library is SDL, and the target is an unmodified Falcon with 4MB RAM, TOS 4.04, and an IDE hard disk. Any recommendations on how to code, create content, and even cross-compile in Windows will be greatly appreciated. Where that's not an option, knowing the "usual suspects" on the Falcon side will be helpful.

[+Tillek]

Granted that this is mostly mint based, but it has a lot of links to a lot of other things and perhaps you may find them useful. I've been pondering some things myself now that I'm back in school and have a little extra time on my hands and I was just starting to look into this.

 

http://vincent.riviere.free.fr/soft/m68k-atari-mint/

[Christos]

I don't think sdl is a good option for a standard falcon. I would use something like pure c considering the costraints. If we are thinking game development on C then I guess the best option would be using the reservoir gods lib.

 

http://rg.atari.org/source.htm

[pixelmischief]

I don't think sdl is a good option for a standard falcon. I would use something like pure c considering the costraints. If we are thinking game development on C then I guess the best option would be using the reservoir gods lib.

 

http://rg.atari.org/source.htm

 

You are a motherf&*king rock star.

[ParanoidLittleMan]

Myself agrees that SDL on 4MB Falcon is not the best idea. Of course, I can not recommend anything C related - I never used it on Ataris.

Just one thing: should be no restriction on IDE disks when you use regular TOS file access - in other words, it must work on SCSI systems too.

[pixelmischief]

Myself agrees that SDL on 4MB Falcon is not the best idea. Of course, I can not recommend anything C related - I never used it on Ataris.

Just one thing: should be no restriction on IDE disks when you use regular TOS file access - in other words, it must work on SCSI systems too.

Good to know. I'll definitely make sure one of my QA configurations loads from SCSI. I'll be using Pure C and, if it's file system access library is like that of other C implementations I've worked in, it should abstract away the difference.

[sh3-rg]

If you want any help, hints or tips using GODLib, MrPink is still out there somewhere. He might even do a little Atari coding from time to time, just don't tell anyone I said so.

[pixelmischief]

Thanks. So far, all I've been able to do is get "Pure C" running, edited a "HELLO.C" and compiled it. Problem is, the resultant "HELLO.O" isn't executable. I tried renaming it to "HELLO.PRG", "HELLO.TOS", "HELLO.TTP". Nada. Figured I'd take a day off and re-engage tomorrow.

 

"Any help here would be hot." - Jar-Jar Binx

 

Damn. Is should kick my own ass for quoting Jar-Jar.

[ParanoidLittleMan]

O - object file. Need to link it with linker ..

[pixelmischief]

Thanks to Visual Studio, I am absolutely useless. In the early 90's, I used to code with vi and compile with cc. Now I can't find my own ass without 4gb worth of software.

[pixelmischief]

Any chance that I can get someone on a 5 minute JoinMe session to get started?

[joyfulcoder]

You may want to make a PRJ file. It will be easier to start with an existing PRJ file and edit it to fit your new project. Reservoir Gods have good examples using their libs. Select your project from the Project menu and then Make it. This will simplify the compiling and linking process.

[pixelmischief]

OK. I got AHCC to compile HELLO.C by copying in an old PRJ file, editing HELLO.C and running a MAKE on the project. A PRG was generated. Wonderful.

 

But AHCC felt really clunky and it was inconsistent in its language; sometimes speaking English, others, Swedish. So, I went to "Pure C". Got it up, copied in a default project, edited, saved, and ran make. An executable, nice.

 

Pure C, however, has its own problems. It's unstable. When I compile the HELLO sample, I sometimes get "Stack Overflow" messages spamming on the MultiTOS Alert accessory. Let me list out the details of my configuration and maybe you guys will have some recommendations for greater stability.

 

Platform: Aranym (No JIT or MMU)

RAM: 14MB Falcon, 64MB Fast

ROM: TOS 4.04

Storage: 200MB Image on Emulated IDE (C:), 200MB Image on Emulated IDE (D:)

Host Integration: /cygwin

OS: MultiTOS

Bootstrap: HDDRIVER 8.03

VDI: fVDI on ARANYM.SYS, screen mode [email protected]

DOS: BetaDOS loading Cookie and HostFS

 

Oh, and the intermittent locking of my CTRL key inside the emulated Atari is driving me insane.

[Christos]

It's not pure c that's unstable. It's multitos. I'd go with a more recent version of MiNT if I were you. Multitos, especially on aranym, not a good idea.

[lp060]

I use PureC on aranym and its fine, building large projects. MiNT + NAES + Thing Desktop + NVDI. I kicked fVDI to the trash and run aranym in videl mode. Yes its slower, but far less problems.

Edited January 16, 2015 by lp060

[pixelmischief]

I kicked fVDI to the trash and run aranym in videl mode. Yes its slower, but far less problems.

 

Oh! This is a good idea, actually. I think I'll do the same, just to minimize.I can get the same resolutions from Blowup030. And let's face it. "Slower" in this context is indiscernible to the user.

Edited January 16, 2015 by pixelmischief

[lp060]

Certain resource objects where rendered weird in NAES with fVDI. Getting rid of it solved that. To me compatibility is far more important than the tricks used to speed it up. I'm using Blowup030 as well. I also don't use the JIT version, if stuff starts acting wonky, you don't know if it's you or a JIT issue. Even in videl mode it feels slightly faster than my Hades060, but then it's a quad-core i7.

[pixelmischief]

Certain resource objects where rendered weird in NAES with fVDI. Getting rid of it solved that. To me compatibility is far more important than the tricks used to speed it up. I'm using Blowup030 as well. I also don't use the JIT version, if stuff starts acting wonky, you don't know if it's you or a JIT issue. Even in videl mode it feels slightly faster than my Hades060, but then it's a quad-core i7.

 

I'm back to Aranym in Videl mode and the stability is really good. Many of the oddities of Pure C are no more. My challenge now is to get Speedo GDOS 5 working. It seems to install OK, but Works complains that there are no fonts. Then, at some point, the machine started crashing on boot. I'd really rather not use NVDI, if I can avoid it.

[STuck]

I would still vote for AHCC - it's in active development. Pure C is long dead. If you've got a problem, Henk Robbers can still help you out.

 

I've got a couple of projects on the go in C for the Falcon at the moment (one of which is a text adventure. Parsers in C, sheesh).

 

I tend to write my stuff in strict ANSI C using Clang as the compiler, then port it over to the ST after. I find it's much quicker and if you use #defines at compile time to select the arch you're running on, then you can use Atari specific GEM calls or use C libs on your more modern arch.

 

I use MagiC when I'm developing as multitasking can be pretty useful.

[lp060]

I would still vote for AHCC - it's in active development. Pure C is long dead. If you've got a problem, Henk Robbers can still help you out.

 

I use MagiC when I'm developing as multitasking can be pretty useful.

 

I find that somewhat ironic, as magic has not seen an update for over a decade either, where as MiNT and related add-ons are activity maintained and more advanced. Just saying.

[Christos]

Otoh, if you are running a standard falcon with 4MB's of RAM, Magic is a much better choice than mint. It all comes down to hardware

[lp060]

I would think just MiNT + XaAES + Thing would fit on 4mb machine. You don't need all the extra unix nonsense if you just want a tasking setup. I do agree magic would be a smaller footprint, but MiNT is much better at handing a crash. If I coded under magic I'd be rebooting every half hour or more. lol

 

PureC, even if it's old as dirt, has been around so long, and so many still use it, that all the quirks are for the most part well known by now. If you have the English help files, it's actually a pretty ok dev package. I think firetos is patched to run purec binaries as well.

[Christos]

MiNT+XaAES+Teradesk is about 2.5 MB's. Adding NVDI and two or more auto programs and you have very little RAM left.

[STuck]

 

ironic

 

I don't think that word means what you think it means.

 

Mint is heee-uge, and MagiC rarely crashes - at least on my machine. I just use it so I can test-run my programs without leaving AHCC. Each to their own, I guess.

[pixelmischief]

I find it's much quicker and if you use #defines at compile time to select the arch you're running on, then you can use Atari specific GEM calls or use C libs on your more modern arch.

 

I'm EXTREMELY interested in this. Are you saying I can write my code on my PC, using an IDE with all the modern coolness, and then run it on the Falcon? It sounds like you're saying I can even cross-compile on the PC side. Can you explain this more? Maybe even describe the components of a setup and a workflow to accomplish this.