Jump to content
IGNORED

High speed structured programming - best tools?


Recommended Posts

Quick request for advice:

 

I'm looking to dabble a bit in graphics/arcade game programming and find there's now a plethora of well-developed tools for high-speed structured programming for the Atari.

 

I've had a peek so far at MADS Assembler, MADS Pascal, cc65, ACTION! and Fast Basic.

 

Anyone who's had more than a peek at these or similar tools care to offer comparisons, insight or recommendations?  I'm going to be working primarily on a PC, so cross-programming tools or emulator-based tools are both fine.

 

Most of my past programming has been in various flavours of BASIC, but I've dabbled in Python, Java, C, C++ and 6502 Assembly.

 

Many thanks in advance

 

Peter

Link to comment
Share on other sites

Of those you mentioned I have experience in Action! & Mad Pascal. Conclusion: compared to Mad Pascal Action! is slow and outdated. 

 

 

I used to compare the speed of all the programming languages you mentioned and Fast Basic was the slowest, although it is still much faster than Atari Basic and much more convenient.

 

If I knew C as you do, I would choose KickC ;)

 

If I wanted to program in machine language I would choose K65 :D 

 

 

Worth to mention is: 

 

Edited by zbyti
Millfork
  • Like 1
Link to comment
Share on other sites

CC65 if you like fully featured C. Has only limited set of atari-specific libraries, but integrating asm code is almost seamless. Good linker tool makes it easy to generate complex binary files or simple cartridge images. Symbols and structs for Atari OS and custom chips are shipped.

 

KickC is a decent subset of C and performs well. Support for Atari is rudimentary at best, but improving. Originally it was meant for C64. A black horse, I would say.

 

Mad Pascal is a decent Pascal dialect and includes Atari-specific libraries. Integrating asm code is almost seamless.

 

So, the question is if you like Pascal or C style.

 

Link to comment
Share on other sites

2 hours ago, baktra said:

So, the question is if you like Pascal or C style.

 

Still trying to work that out- have done a little bit of C in the past, but never looked at Pascal before.

 

From an Atari 8-bit perspective, I get the impression that MADS Pascal is perhaps more developed as a fully-featured language (e.g. I understand that CC65 does not support floating-point data types?) but, on the other hand, the CC65 linker does for example look very impressive.

 

Are there any other not so obvious 'gotchas', like missing floating-point support, when comparing these packages?

Link to comment
Share on other sites

as a person who recently faced this question (and not as a person with years of experience, because I don't have that)....here is how I ended up answering this question for myself.

 

1) program on a PC or Mac, because you can instantly compile your code and see results.  You can easily manage art assets. It's just way faster than on the Atari.

 

2) Having examples means a lot.   The two environments I found to be absolutely "swimming" in examples are Atari Basic and Assembler, that's because they were well documented back in the day, and people have posted literally thousands of examples on the internet which are easily found by google search.  I find myself referencing De Re Atari all the time.   So, this means, Assembler, since basic doesn't cut it.

 

3) I don't find assembly especially tedious, because what I use it for, is for the inherently tedious tasks anyway.  By this I mean, for example, Display lists are just a list of bytes, C has a display list struct, but even if that looks like a clean implementation to a seasoned programmer, it doesn't help save time.  Similarly, programming a VBI or DLI, may as well as do it in assembly, because you are basically filling hardware registers anyway....it isn't a task that somehow becomes easier in a high level language.

 

But assembly for the entire program is tedious, and that's where a dab of C really helps.

To toss out some pseudo code, I would organize in C with something like this:

game_loop() {

read_joystick()

move_players()

check_collisions()

update_score()

}

 

and then each of the functions I probably called out to assembler, because lets say I need to update a score.

Well the score is located in the screen memory at a very specific location of my choosing, using a characterset that may be custom.

I"m not going to printf() the score.  I'm just going to write the new correct, characters to the correct location.  So what's the point in hoping a library knew how my game was written.   

 

Anyway, so that's what works for me....organize in C...mostly in assembler.

 

Truth is I'm not as organized as some or I'd have probably fallen in love with MADS, but I'm too lazy to learn all that, haha

Link to comment
Share on other sites

20 hours ago, drpeter said:

Or is it more a case of someone's project, 'because they can'?

I thought about it a bit and I think that the reason (for example creating Millfork, K65) is that: very good and experienced programmer have his ideas about how certain things can be done better :) 

Edited by zbyti
typo
Link to comment
Share on other sites

As @Dmitry said use your PC/Mac, also remember using C will always produce larger code, so if memory

is tight for your project then maybe Assembler is the best option, or a mix of the 2.

 

I use cc65 with ca65 modules and find a mix of the 2 is a good way to proceed, in-line assembler in cc65 is

a bit tedious but is ok for something short, having a .s module is much better once you get the syntax

for importing and exporting variables between the C and Assembler modules.

 

Kickc seems to get good reviews here, but remember it's still under development and I believe has some

non-C constructs and does not yet fully support the Atari. (someone correct me if I'm wrong)

Link to comment
Share on other sites

7 hours ago, zbyti said:

very good and experienced programmer have his ideas about how certain things can be done better

? We all have those...   but although all progress requires change, not all change turns out to be progress...

 

e.g. Modern PC- obviously progress in so many ways- but more fun to get into programming than an Atari?  Not so sure...

Link to comment
Share on other sites

Hi!

On 12/8/2020 at 10:30 PM, drpeter said:

Quick request for advice:

 

I'm looking to dabble a bit in graphics/arcade game programming and find there's now a plethora of well-developed tools for high-speed structured programming for the Atari.

 

I've had a peek so far at MADS Assembler, MADS Pascal, cc65, ACTION! and Fast Basic.

 

Anyone who's had more than a peek at these or similar tools care to offer comparisons, insight or recommendations?  I'm going to be working primarily on a PC, so cross-programming tools or emulator-based tools are both fine.

 

Well, FastBasic is a lot slower than cc65 and Mad Pascal, because it is an interpreter, not a compiler, and it is designed to run in the Atari.

 

On 12/8/2020 at 10:30 PM, drpeter said:

Most of my past programming has been in various flavours of BASIC, but I've dabbled in Python, Java, C, C++ and 6502 Assembly.

 

IMHO, once you learn about the hardware, the selected programming language will not make a huge difference. You can begin in BASIC and then move to a compiled language later when you need the speed. In my experience, people that obsess with which language is better never get to finish their project or game.

 

Have Fun!

 

Link to comment
Share on other sites

  • 7 months later...
Quote

High speed structured programming - best tools?

Note that you don't need to go to an HLL to get structured programming.  Macros in assembly language can go much further than most people realize, even forming program flow-control structures.  It's what my article is about, at http://wilsonminesco.com/StructureMacros/ .  There are a couple of more-extended examples in the last 40% of the page on multitasking, at http://wilsonminesco.com/multitask/, showing nested IF...ELSE...END_IF's, BEGIN...UNTIL, CASE, etc..  In most cases, the macros will assemble exactly the same thing you would by hand, meaning there's no penalty in run speed or memory taken; it's just that now you don't have to look at the ugly internal details every time, and your code becomes much more readable, maintainable, and bug-free, and the programmer becomes much more productive.  There's more description of how the macros figure out where to branch to and how they keep from confusing the various targets, in the related chapter of the 6502 stacks treatise, at http://wilsonminesco.com/stacks/pgmstruc.html .  Near the end of the page, you can mouse over the various words in the CASE structure code example, and a box will come up telling what the macro does there, and what's on the assembler's own stack at that point (not the target 6502's stack, which is not involved).

  • Like 1
Link to comment
Share on other sites

The "high speed" part...do you mean speed of execution or speed of coding? If you mean speed of execution, then an assembler toolchain. Assuming you mean speed of coding, then a C or Pascal toolchain; you can write quickly to set up and test your code, and then go back and optimize parts you need by dropping in assembler where needed. I'd recommend either CC65 or Mad Pascal. If you are writing anything that will need most of the resources of the machine, you might as well bite the bullet and use assembler. 

Link to comment
Share on other sites

If you go the assembler route, on real hardware MAC/65 is probably the best to use, using a PC

then ATASM using your favourite IDE, I use Sublime Text 3, ATASM is almost MAC/65 compatible

but no need for line numbers, it just ignores them if they exist.

 

I can assemble code and have it running in Altirra in a few seconds :)

 

I also use cc65 in the same IDE, works a treat

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...