Jump to content
IGNORED

Programming Experiences


Recommended Posts

As a kid I used to write my own strategy games in Atari Basic, however these days I want to try something a little more graphical. I have been playing around initially with Turbobasic but now Fastbasic and I am quite impressed. However, I wonder what people here would recommend for more graphically intensive games? I saw an earlier discussion on the speed of the various tools. Right now I am looking at CC65, and Fastbasic, I would consider Mads Pascal (no experience as yet) and unless really needed I would rather stay away from assembler... but will give it a go if needed. Any views on performance, feature set and general ease of programming etc are welcome. I would like to pick the right method before starting! In terms of more recent tech I have worked a bit with Unity for AR/VR so am not averse to programming.

 

I have an 800XL but for developing I have a PC with Mads Studio and Altirra.  WUSDN although it is for assembler seemed quite good as well, but as I said I'd rather avoid that unless really needed.

Link to comment
Share on other sites

For Graphically intensive applications, your probably going to have to dip into assembler, although

any language that is compiled down to assembler will be quicker than any of the BASIC's.

Bear in mind compiled languages do generate slower and bigger code than assembler.

 

Personally I use cc65, which is good to get lots of things done quickly, part of cc65 is ca65 which

allows assembler routines to interact with the C modules.

 

I can't speak for any of the other languages like Mad Pascal, but I'm sure someone will advise.

Link to comment
Share on other sites

3 hours ago, atarilux said:

Right now I am looking at CC65, and Fastbasic, I would consider Mads Pascal (no experience as yet) and unless really needed I would rather stay away from assembler... but will give it a go if needed.

My 50 cents: When you program the Atari in something similar than Basic, you'll get just what you got back then. If you want it to be as fast as professional games back then, and you still want to use the Atari, you'd still have to do, what programmers did back then: Diving deep the Atari's graphics system (ANTIC, display lists, GTIA, Player/Missile Graphics) and memory addresses.

It's not much easier doing that in Pascal or C than doing it in assembler. It's still very low level programming. And you still have the limitation of just 64K (or maybe 128K) RAM.

 

After struggling for a while, I decided to take a different approach, leaving the Atari's system to its history, learning Python/Pygame, and then creating games (on the modern PC), that look (pretty much exactly) like on the Atari. I'm getting quite good results at the moment. Still have to take a look at how the Atari did things, but not in so much detail as for C or assembler programming. It seems, not many people are interested in my approach though. :)

 

 

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

Pygame is cool, I used it quite a bit a few years ago. I had planned to get back into that later.

 

As for the ATARI, I had some success with playing around with DLI and PMGs recently, mainly in Fastbasic. I did some assembler stuff on DLIs in WUSDN, which also worked quite well. But I am not sure if I have the time for learning assembler... that is the main constraint.

 

 

Link to comment
Share on other sites

11 minutes ago, atarilux said:

But I am not sure if I have the time for learning assembler... that is the main constraint.

Well, this would be what I wrote to get started with CC65 and compile a "Hello World" program with it. You'd probably use "printf();", that is available, but not original Atari I/O:

------------------------------------------

#!/bin/bash
export CC65_HOME="/usr/local/share/cc65" # Set environment
cl65 -O -t atari hello.c -o hello.obj

You can then use a small utility program called "franny", to write the file "hello.obj" to an Atari ".atr" disk-file containing AtariDos 2.5 with:

franny -A dos_2_5.atr -i hello.obj -o HELLO.OBJ

Then you can launch an Atari emulator with "dos_2_5.atr", select "L", type in "HELLO.OBJ" and run your program. With

export CC65_HOME="/usr/local/share/cc65" cc65 -O -t atari hello.c

you get a file called "hello.s", that contains a listing of the generated assembly code.

------------------------------------------

 

Here I asked the others how to plot and draw (use the arrow to the right to get to the relevant posting):

 

 

Edited by Pokeypy
Link to comment
Share on other sites

44 minutes ago, Pokeypy said:

You can then use a small utility program called "franny", to write the file "hello.obj" to an Atari ".atr" disk-file containing AtariDos 2.5 with:

Even simpler than that with Altirra, just mount a folder as a DOS 2.0 drive (I use D3 then after compiling, just copy the binary into

that folder and run it from there in Altirra.

I can compile new code and have it running in 30 seconds using that method.

If you want it in an .ATR, then simply have that mounted as another drive and use DOS to copy the file from D3: to the .ATR.

Edited by TGB1718
Link to comment
Share on other sites

When the C code is written correctly, CC65 is a very powerful platform that also allows really good integration with assembly and control over memory layout. By 'correctly' I mean 'not like a usual C program'. See ilmenit's tutorials on this site. You do get some benefits from being 1 step up from bare assembler, but as mentioned it's still going to be pretty technical. It has to be.

 

 

 

 

Edited by danwinslow
Link to comment
Share on other sites

I am not too scared of C to be honest, more assembler :) Although I did recently partially defected to Go.

 

Seriously though, thanks for the tips above. I tried Fastbasic to Altirra via Mads studio and so far that worked quite nicely. 

 

 

Edited by atarilux
Link to comment
Share on other sites

19 hours ago, TGB1718 said:

Even simpler than that with Altirra

I forgot to tell, that I'm developing on Linux. (Altirra seems to be Windows only.)

On Linux, I'm using atari++ as an emulator and are quite happy with it. To compile and run new code, I just use some bash scripts, so I don't write the mentioned commands by hand every time. franny is quite a nice utility. Good to have that one.

Edited by Pokeypy
Link to comment
Share on other sites

Thanks, to everyone for your tips. I will probably go down the path of CC65 or Fastbasic to do some early prototyping and concept development, then if needed move to doing some some or all of it in assembler. I now have an early game concept, I will work on that to see if it is feasible before committing to it or indeed doing it in assembler.

 

As for Pygame and other tools, I may look at them to do more retro-looking games in future. I have some experience of Unity and in the past Pygame. These however are often much easier to develop with than on an Atari :) How people managed back in the 80s is a real credit to the programmers involved.

  • Like 1
Link to comment
Share on other sites

On 4/16/2021 at 9:33 AM, Pokeypy said:

After struggling for a while, I decided to take a different approach, leaving the Atari's system to its history, learning Python/Pygame, and then creating games (on the modern PC), that look (pretty much exactly) like on the Atari. I'm getting quite good results at the moment. Still have to take a look at how the Atari did things, but not in so much detail as for C or assembler programming. It seems, not many people are interested in my approach though.

 

How funny. Recently, when I realized I didn't have a clear enough game design in my mind while working in assembler, I started too playing around with pygame on PC so I could more quickly iterate on designs. But my goal is to then implement that in Atari with assembler. I haven't gone far enough this route to see how well this approach will work, but I'm hoping to get good results if I can put in the time.

  • Like 1
Link to comment
Share on other sites

Just a quick update on the above, I started implementing the prototype in Fastbasic. It is a relatively simple platform game, so far it works quite well in FB. No real graphics slow down, although I have not really done anything too taxing so far. It's like going back in time to the 80s, just spent the last couple of evenings experimenting with different graphics mode, character set graphics and player/missile graphics. I will see how far I can go with it before looking to adding ML with FB or moving to CC65 or full blown assembler. Using FB has been a very good way to get my head around the way things are done on the Atari e.g. PMG etc. 

 

I have to say; I am really impressed with FB so far, so my thanks to the author.

Link to comment
Share on other sites

On 4/17/2021 at 6:26 AM, Pokeypy said:

I forgot to tell, that I'm developing on Linux. (Altirra seems to be Windows only.)

On Linux, I'm using atari++ as an emulator and are quite happy with it. To compile and run new code, I just use some bash scripts, so I don't write the mentioned commands by hand every time. franny is quite a nice utility. Good to have that one.

Doesn't Altirra run on Linux using Wine?

Link to comment
Share on other sites

48 minutes ago, RSA said:

Doesn't Altirra run on Linux using Wine?

Yeah, but wine sucks. :)

Sorry to say that, but that kind of emulation just drains too much performance for my taste.

And often, it's just not stable enough. Whenever I have the choice, I use system native applications. And atari++ actually is pretty good.

When I want to run Windows applications, I just use Windows.

Edited by Pokeypy
  • Sad 1
Link to comment
Share on other sites

I'm a little late to the party, but I highly recommend a language called "Quick" from Raindorf Software, now available from DGS.

 

Basic-like syntax, compiles to fast machine code, gives you access to DLI, VBI, fine scrolling, etc.

 

(Still a work in progress, but this game is written in Quick) ZombieAttack RC3.xex

 

 

This DLI example makes the top part of the display appear to fade in by incrementally increasing the brightness of the first 8 scan lines

INTER DLI1 ;pfield0 A
LOCAL
 BYTE
 [
  V0,V1,V2,V3
 ]
BEGIN
 PUSH
 SYNC(1)
 CHBAS=168  ;alt1 charset
 VSCROL=VFS  ;set fs values for top

 *set starting colours
 V0=32    ;40   red-orange
 V1=160   ;168  blue grey
 V2=112   ;120  ultramarine
 V3=64    ;72   red

 *fade in
 REPEAT
  PFCOL0=V0
  PFCOL1=V1
  PFCOL2=V2
  PFCOL3=V3
  V0+
  V1+
  V2+
  V3+
  SYNC(1)
 UNTIL V0>=40

 DLI(DLIFOUT)  ;make next DLI active
 PULL
ENDDLI

 

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