Jump to content
IGNORED

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


jmccorm

Recommended Posts

How are most people setting up a 6502 assembler programming environment these days? Is there a best practice?

 

I'm assuming that most people are using a PC (typically running Windows or Linux) for their editor and compiler, and then running against an emulated Atari 8-bit for testing and debugging? (As opposed to doing it all inside of the Atari itself.) What specific tools are you using (editor, compiler) , and how are you setting it up?

 

Or are most people doing it on the machine itself (real or emulated) with something like MAC/65?

 

Is there a good environment somewhere to jumpstart a development effort from?

 

Thanks much, all.

  • Like 3
Link to comment
Share on other sites

I was thinking about some of this recently, The incredible releases of the last 10 years... it would be nice to know exactly what was used and for what purposes to create these masterpieces as well as best programming practices and the alchemy that made it possible.... a how we did it and how you can do it too if you will... ;)

  • Like 1
Link to comment
Share on other sites

I have an SIO2USB device linking my Atari to a windows machine, and I'm running the APE for Windows software.

 

D2 is set to a mirror drive, that mirrors a share on my Samba server, which itself is mounted as a symlink in c:\Atari on my two windows dev machines.

 

On my dev machines I have cc65 and a text editor, which I use for development & cross compiling. Because I have the drives set up in this manner, I can code and build in a windows environment, but my executable shows up automatically on the Atari side of things. Which is kinda slick. Someday I'll bring Altirra into the mix.

 

My current project is to write a REALLY pared down version of emacs, I'm calling FemtoEmacs. But I kind of abandoned that project several months ago, so I should pick it up again. I got hung up trying to implement a really, really minimal version of curses.

  • Like 1
Link to comment
Share on other sites

For coding, I use Eclipse with the WUDSN plugin, MADS as the assembler. Altirra is the emulator of choice. I am finally using GitHub (locally) for my source control. When coding PC based utilities, I use Visual Studio 2017 as I am a .NET coder for my day job.

 

I have two full-time Atari setups. Both are 100% of the time connected to PCs running a registered version of APE. I have several working floppy drives, but I tend to save them for archiving old collections.

  • Like 3
Link to comment
Share on other sites

My wish for APE is 16 drive support 0-15... and a reworking of the PC mirror... while there is a realdos and sdx driver that sort of does the job... it's cumbersome.... with all that Aspeqt and Respeqt has pulled from APE maybe it's time the reverse should also occur..

  • Like 2
Link to comment
Share on other sites

As Stephen describes for the programming enviro is probably "state of the art".

 

There's less complete/complex ways to go like using a lesser text editor which has launch macro key ability. Generally there you have to save the file then launch macro which will use generated variables for filepath etc to execute the assembler on PC (MADS, AtAsm, whatever). The decent text editors can also capture output from the run or at least auto-open a file which contains it.

  • Like 2
Link to comment
Share on other sites

I use mads and PSPad environment. It's very simple, but it can call the compiler and highlight errors, all I need. Eclipse ? Too bulky for my taste.

And of course Altirra. Altirra is the thing. Debugging, profiling, anything. I run stuff on real hardware like once per week on local Atari club meetings. I don't have real machine at home.

  • Like 1
Link to comment
Share on other sites

Wudsn (Eclipse+Mads+Altirra).

Gimp for creating gfx.

Python for converting gfx to Atari binary.

 

Have 800xl next to my desktop pc linked with cable, Aspeqt running on pc.

1. Compile in Eclipse

2. load on Atari.

3. Enjoy :)

 

Never been easier and more fun than now. And it's only getting better :)

  • Like 5
Link to comment
Share on other sites

i'm using Crimson Editor which in turn calls Xasm from a hotkey combination (it's set up for ACME and Pasmo on other keys) before dragging the assenbled code to an emulator (A800Win for everyday use, Altirra when i'm worried about cycle accuracy) for testing. Close-to-final code gets a batch file which calls Xasm then Exomizer for crunching and the results are occasionally tested on an 800XL with SIO2SD just to be sure.

 

Graphics are usually done with Pro Motion or using what are usually C64-centric tools like Char Pad, then pushing the output through bespoke conversion tools usually written in BlitzMax - these are usually so "user hostile" that i don't give them out, even internally amongst other members of Cosine. =-)

  • Like 2
Link to comment
Share on other sites

I used WUDSN for patching Shamus and enjoyed the really instantaneous assembly times, immediate launch in Altirra and extensive debugging capability. I sometimes used Altirra and Atari800MacX simultaneously to look at different versions and compare their behaviour. IMHO debugging is where PC-based development beats what is available on real machines, even if you don't care for the much faster assembly times. (My on-machine experience is limited to MAE and MAC/65.)

 

For Action! programming I found it convenient to use an emulator although there's probably not much difference between using a real machine and an emulator if you use a modern storage solution, probably even easier as you don't have to think about which key is mapped to what.

 

What's the best setup for you is very much a matter of personal preference, I'd say. Some people enjoy the quickness and convenience of a PC/Mac-based solution while other prefer to keep it retro all through.

  • Like 1
Link to comment
Share on other sites

My main environment is Windows 10 + Cygwin + vim + make + xasm + Perl + Altirra.

Occasionally I've used TMC2 for music and sound effects (X-8), Tiled for map editing (X-8), graph2font for screen editing (X-8, Ransack, Bomber) and gcc for custom C++ utilities (X-8). Other useful tools include franny for ATR manipulation, mads for assembling graph2font-generated sources, exomizer for compression, and many others I'm forgetting. For my various hacks of existing software (e.g. NTSC-fixing, bug fixing, cracking, enhancements) I use my disassembler dis. For BASIC competitions I use dmsc's basicParser.

Of course there is a wealth of great documentation and code to draw inspiration from on the web. It goes without saying that Google is one of the most essential development tools. And sharing ideas on AtariAge is a fundamental source of knowledge and inspiration.

Edited by Xuel
  • Like 3
Link to comment
Share on other sites

1) plug in OSS 5-in-1 cart. by santosp into 800XL

(with switch set to MAC65)

2) power on Atari 800XL and tv

3) see "Edit" or something similar on the tv screen

4) make a strange face, since I am no programmer

5) power off Atari and unplug cart.

6) power off tv

 

And thats my programming environment!

  • Like 2
Link to comment
Share on other sites

Incredibly good answers, all.

I think I've selected my own starting point.

 

To begin my own efforts, I've gone with:

1. MADS 6502 cross-assembler

2. Altirra Atari 8-bit emulator

3. Eclipse IDE as the development environment

4. WUDSN for integration, following these instructions

 

post-18231-0-76786800-1515106271_thumb.png

 

One initial issue: Inside Eclipse, Shift-Control-0 would not compile and run the code (but the Assembler -> Compile and Run option worked just fine). As it turns out, the problem was deep inside the bowels of the Windows 10 language selection configuration options. Control Panel -> Clock, Language, and Region -> Language -> Advanced settings -> Change Language Bar Hot Keys -> Change Key Sequence. I set both to "Not Assigned", and it released control of the Shift-Control-0 key so that Eclipse could use it.

 

So many great alternatives have been listed, and so many great additional tools to keep advantage of.

Keep them coming!

 

EDIT: I'm already starting to see how valuable it would be to see what the real hardware does...

scurvy.xex

Edited by jmccorm
  • Like 4
Link to comment
Share on other sites

EDIT: I'm already starting to see how valuable it would be to see what the real hardware does...

Oh absolutely, always test before releasing. My game Blok Copy uses some cycle-accurate timing for colour splits which both Altirra and A8Win said it was all lined up... but the 800XL disagreed by one cycle!

Link to comment
Share on other sites

Oh absolutely, always test before releasing. My game Blok Copy uses some cycle-accurate timing for colour splits which both Altirra and A8Win said it was all lined up... but the 800XL disagreed by one cycle!

 

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.

Link to comment
Share on other sites

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.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...