Best practice on a programming environment for Atari 8-bit?

[thorfdbg]

emacs as editor, ca65 as assembler, GNU utilities for building, and atari++ for testing.

[TMR]

Some types of register splits have a one-cycle variance between computers or even the same computer depending on whether it is warm or cold... so even just testing on a real computer isn't enough, if you're doing something that tight you need to test on multiple computers. ANTIC is generally well behaved and deterministic, POKEY and GTIA less so.

Ouch, that's something i don't remember reading about previously and i've done a few colour split based routines which worked without issue too now i think about it... how does something like Rasta deal with that?!

 

Looks like i'll have to get some of the other 800XLs out of storage...

 

TMR, was it one cycle early or late on the real pal 800XL?

The status bar on Blok Copy has one colour vertically split from the main play area and (if memory serves, i've slept since then) the high score was starting a cycle late on real hardware. i nudged it a cycle left so the emulators are showing the split happening early and the real machine lines up.

[_The Doctor__]

That was the expected behavior. Perfect.

Edited January 6, 2018 by _The Doctor__

[Sheddy]

Rastaconverter only does register writes on 2 cycle boundaries from looking at the code it generates. Not sure if that completely explains why it doesn't suffer glitches - It might play things even safer internally?

[Sheddy]

Oh, and notepad++, ATasm and some .bat files.

[phaeron]

Rastaconverter only does register writes on 2 cycle boundaries from looking at the code it generates. Not sure if that completely explains why it doesn't suffer glitches - It might play things even safer internally?

 

It primarily only does color and PMG splits, which as far as I know is well behaved across the board. Well, except for VBXE and certain PMG bugs, but RC doesn't handle those correctly either. I can't explain Blok Copy and its COLPF2 split issues, but it seems to run fine for me both in emulation and bare metal. GTIA mode splits are dangerous, OTOH, I have seen a lot of cases where two computers differ by a cycle on those.

 

The usual practice you want to follow for when to test on the real hardware is pretty much what you'd use for any other software project: do early testing to make sure your testing environment works, prioritize bare metal testing for aggressive/risky items, ramp to full testing as you get close to ship. You don't want to get all the way to the end only to discover your program loads too low to start on any normal DOS and suddenly need to cut 8 pages to get it to run. Conversely, plain 6502 logic is pretty safe and generally doesn't need to be tested on bare metal until you're ready to do significant play testing.

 

Another point I would consider critical: for any reasonable-sized project, try to get your build-run cycle as close as you can to one-click. If you've got multiple build steps to compile assets, compress the executable, and assemble a disk image, script the whole thing. This is well worth the time to do as it will speed up iteration and avoid stupid mistakes at ship. Also, when testing with an emulator, including the emulator in the testing script too -- all major emulators can launch a program or disk image from the command line.

[Heaven/TQA]

I can tell a lot of story and follow the advice of Avery...

 

A lot of pain of mine could be less when I used to had build scripts etc in the past while developing eg Arsantica or Arsantica 2. Part 3 was better and on Lynx it got better neverless the issues to get familiar with Lynx Emu and dev tools there.

 

I am not a pro soft developer so I am not familiar with professional dev environment.

 

But as I am in regular contact with Wratchild or Axis of Oxyron I learned a lot. Jac helped a lot in setting up better build scripts, too.

 

Tests things early. If you prototype on PC use as much same data you use on A8. Use Altirras extensive debug features. if you think they are bad... try eg Handy Emu or Vice .

 

Another advice. If you dont like something in your setup simply change it... since I am using batch files or start to learn make your live gets easy.

[_The Doctor__]

You will find the 'professional' environment is pretty much the same as the everything mentioned here... in fact a good deal of the people here today are light years better than the 'Pro' of the past.... If it was good enough people donated money, traded goods, or gave you a thing... You've made something of value... you are 'Pro'

[VladR]

While on Atari Jaguar I use Notepad++, makefile, batch scripts, from long and painful experience with this set-up on Jaguar, I decided I had enough of "debugging" via screen printing, and for 6502, created a simple Virtual Machine/emulator in C++:

- it took only 3 mornings (2-3 hrs each) to emulate the 6502 instruction set with its addressing modes (it's just 3 registers and couple flags after all) via macros - so basically one full work day

- but now I can work on 6502 from within Visual Studio, use Breakpoints ad most importantly Debug&Continue feature, which I quite literally use to develop the code, not just to debug

- the built-in cycle counting (simple counter, really) makes performance profiling so much more faster - no need to create flags, recompile, and especially keep all those codepaths valid after numerous stages of refactoring - you profile the cycle count literally during the debugging (stepping through the code via F10/F11)

 

- since it's C++, I can intermix C code with 6502 ASM statements, so for prototyping my 3D flatshader, this proved incredibly productive, as you gradually port the code, function by function, depending on how much time you have at that moment

- countless times, it proved very handy when I botched things up in ASM, by running the C code, and comparing generated data from C versus those from ASM (takes seconds from VS, not minutes or hours (like on Jag))

 

- the Antic portion is currently very simple (just 2 gfx modes), so that'd be the primary limit (but that can be easily fixed by implementing more Antic features, when needed)

[Heaven/TQA]

While on Atari Jaguar I use Notepad++, makefile, batch scripts, from long and painful experience with this set-up on Jaguar, I decided I had enough of "debugging" via screen printing, and for 6502, created a simple Virtual Machine/emulator in C++:

- it took only 3 mornings (2-3 hrs each) to emulate the 6502 instruction set with its addressing modes (it's just 3 registers and couple flags after all) via macros - so basically one full work day

- but now I can work on 6502 from within Visual Studio, use Breakpoints ad most importantly Debug&Continue feature, which I quite literally use to develop the code, not just to debug

- the built-in cycle counting (simple counter, really) makes performance profiling so much more faster - no need to create flags, recompile, and especially keep all those codepaths valid after numerous stages of refactoring - you profile the cycle count literally during the debugging (stepping through the code via F10/F11)

 

- since it's C++, I can intermix C code with 6502 ASM statements, so for prototyping my 3D flatshader, this proved incredibly productive, as you gradually port the code, function by function, depending on how much time you have at that moment

- countless times, it proved very handy when I botched things up in ASM, by running the C code, and comparing generated data from C versus those from ASM (takes seconds from VS, not minutes or hours (like on Jag))

 

- the Antic portion is currently very simple (just 2 gfx modes), so that'd be the primary limit (but that can be easily fixed by implementing more Antic features, when needed)

Would you mind sharing your VS setup and proto engine?

[VladR]

Would you mind sharing your VS setup and proto engine?

Not at all. It just needs more work, till it's of some proper public use (especially more Antic modes).

 

Obviously, this is not meant as a replacement for Altirra or anything, but for initial algorithm/engine prototyping (before it gets to stage where further progress needs to happen under Altirra), it's pretty darn productive. Last time I was able to intermix ASM with a higher language like that was with TurboPascal 6 and I never could forget, how awesome that was.

 

If anything, I wanna now do the same thing for Jaguar, and create the VM for both 68000 and GPU in C. I could have saved so much time, if I did just that in past...

 

 

My first A800 coding spree (I have several waves like that each year, usually) was only about 3 weeks (unfortunately interrupted by my out-of-state move, as that was a pretty big disruptor), but I'm getting warmed up to it again, just need to finish few things that are currently in progress on Jag...

 

You just gave me an idea though - Perhaps I could try to work a little bit on both platforms at the same time, I mean I switch between 2 different assemblers on jag all the time anyway (68000 vs RISC), so adding a third assembler syntax of 6502 shouldn't probably be a big context switch, I think ...

 

And I can't say anymore that ABBUC is next year

[baktra]

Another point I would consider critical: for any reasonable-sized project, try to get your build-run cycle as close as you can to one-click. If you've got multiple build steps to compile assets, compress the executable, and assemble a disk image, script the whole thing. This is well worth the time to do as it will speed up iteration and avoid stupid mistakes at ship. Also, when testing with an emulator, including the emulator in the testing script too -- all major emulators can launch a program or disk image from the command line.

By all means. Even the simple means things such as makefiles, shell scripts, or batch files do wonders when it comes to increased productivity and simplified deployment. E.g. I have a script that creates all three distribution packages of Turgen System. This script even runs Inno Setup under wine to create the Windows installer.

 

As I typically develop for Atari using combination of C and ASM and running Microsoft Windows (declining from GNU/Linux more and more), my favorite combination is the NetBeans IDE (for comfort), MSYS2-based MinGW (for tools like sh, make and fooling NetBeans), the CC65 development system (compiler, assembler, and linker), and dir2atr (for games distributed as disk images).

 

The only imperfection is that NetBeans has no support for syntax highlighting of CA65. Code completion for C works nicely when set-up.

I only wish the LD65 linker wouldn't have such a steep learning curve, but I mastered it. Inconspicuous, but wonderful tool.

[R0ger]

Which reminds me .. I prototype most things in good old Visual Basic 6. My 3D engine was done in that completely, to test numerical resolution decisions, or to test different approaches. Beats debugging vector math in asm. But it's good for games and such too. I can have moving sprites in VB6 in like an hour. I see if the sprite works, if the control method works. Also most of the time you need to convert GFX, even animations, from some bitmap format, and you need to generate some tables. Again, VB6 is very good for that. Well I wouldn't recommend it to anyone who hasn't been using it yet, it for sure has it quirks, and it's all but discontinued .. but it's very powerful for this small stuff, and it has very strong edit & continue debugger.

[Martin72]

I have Ubuntu 20.04 OS and try to use Eclipse with WUSDN and compiling works fine. But when Eclipse try to call Altirra with the outputfile (.xex) then I got the error in Altirra: Unknown commandline switch: /home. I use Wine to run Altirra and as standalone application, Altirra works fine.

Also when I copy the outputfile to the Altirra folder and run Altirra from that folder with only the outputfilename : ./Altirra64 test.xex works perfect.

In Eclipse, I've configured Altirra in Eclipse as application to open output file with commandline: ${runnerExecutablePath} ${outputFilePath}.

I think the problem is that the linux filepath is not recognized by the Windows program Altirra. Does someone know a solution for this?