Ironman Atari: A compilation of advanced Atari 8-bit programming techniques

[gauntman]

A few years ago, I started collecting interesting information and low-level programming information on "Lesser-documented" Atari features. Based on some recent threads (for instance, then HIP/TIP pages disappearing, etc.), it sounds like some of the newly won Atari information is in danger of being lost. I have decided it is time to release the current document version of my "Ironman Atari" document.

 

This document is by no means finished -- or even up-to-date. The bulk of this was written back in 2003-2004 over Christmas. Some of the document has aged well, other parts less so. For instance, I have a place-holder in there for MCS techniques, and only a footnote for G2F. I have, over time, double checked the http links, and updated them as necessary, but other than that the bulk of the document has remained unchanged for almost three years.

 

Putting together a document like this should be a community effort. I have considered hosting this in a wiki. but would like to have a more formal (and printable/bindable) product at the end. If you would like to correct items, write working source code examples, add new articles, please do so! Don't worry too much about grammar or spelling, I can clean that up as necessary. (Ideally, source code should compile with ATasm, but this is not truly necessary).

 

If you are submitting an article for consideration, I would prefer it be in either OpenOffice format, RTF or raw ASCII, just to increase the speed with which I can incorporate the articles. Just add them to this thread, or PM me. I would like to restrict topics to items that are not covered elsewhere (i.e. I don't consider this a replacement for something like De Re Atari).

 

Note: there are several places where there are "notes to self" in the text, these will someday be expanded into real articles, be updated or removed.

 

In any case, if I wait until it is "done", this probably will never get released. So, here it is in a (very) rough state.

 

I would like to have version 1.0.0 of Ironman Atari out by the end of the year. In the meantime, consider this a preview, and enjoy.

age.pdf

[Heaven/TQA]

that doc kicks ass! finally... i will go through and see what is lying on my hard disc to contribute.

 

btw. page 6 - split modes vertically...does unity not split horizontal???

[Allas]

Great document!, I always dream something like this.

I stay alert about new progress on this edition. Easily could be the white book of Atari 8bit computers.

[Heaven/TQA]

we should search this forums for some more inside info:

 

- 40x40 gr.0 screen (my prg is somewhere here)

- emkay & analmux' doing "ear bleeding"

- DMA timing screen captures (who did them?)

- ...

 

then we might get a nice doc and sometime we even get things like codebase64.org

[twh/f2]

Really good stuff!!!! I'm honestly excited. There is a big potential in this document. But I wonder if is maybe simplier to think about the approach like Carsten Strotmann is following up with his Atari Programmers Wiki (APG) at http://atariwiki.strotmann.de/

 

The main differences seems to be Document vs. Wiki. However, having a new "Bible of Atari" is a very good idea. I think about what I could possibly contribute from my source code collection which hasn't been placed in your document with an example.

 

grtx,

\twh::taos

[Gury]

Great collection, thank you very much!

[atariksi]

...

Putting together a document like this should be a community effort. I have considered hosting this in a wiki. but would like to have a more formal (and printable/bindable) product at the end. If you would like to correct items, write working source code examples, add new articles, please do so! Don't worry too much about grammar or spelling, I can clean that up as necessary. (Ideally, source code should compile with ATasm, but this is not truly necessary).

...

 

I don't use ATasm, so if you want to include the irq timer example I posted in the "GTIA mode animation" for avoiding a WSYNC in a DLI, you are welcome. I am sure you can convert it to ATasm; it compiles into a bootable image disk. Also, you can play around with the NOPs in that interrupt routine if you want to change the ISR to do something else.

 

I am sure the audio section can be enhanced further for playback of higher sampling rates, higher quality, and/or other methods of playback...

[Heaven/TQA]

I personally prefer a doc as you can simply browse through or have print out easily next to your PC...

 

another suggestion would be to add the programer's reference card (2 pages) of the de re atari book... maybe adapted like the cribsheets of GBA... http://www.otakunozoku.com/2003/02/26/nint...eboy-cribsheet/

[Heaven/TQA]

here is the 40x40 thread:

 

http://www.atariage.com/forums/index.php?s...57&hl=40x40

[MaPa]

Player/missile graphics and playfield graphics can be made to mix. Set the lower nibble

of GPRIOR to 0, and playfield 0,1 and players 0,1 combine their colors by “or'ing” the

colors together. Playfield 2,3 and players 2,3 are also “or'd.”. Used in combination with

soft-sprites above, this can be used to create modern looking avatars.

Did I miss something or is this info incorrect (something like the overlapping players will be black if not ORing set)? What will setting the lower nibble of GPRIOR do? In memory map od Mapping the Atari there is only written what will each bit set do, but if noone is set? And about ORing the colors of playefield and players I never heard.. players 0,1 and 2,3 sure (bit 5 of GPRIOR), but playefield vs. player?

 

EDIT: ups.. just finally get my test running and it really works .. WOW, never heard of it and probably never saw use of it .. tested in emu only.

Edited April 9, 2008 by MaPa

[Rybags]

If you have conflicting priorities, e.g. a bit set which has a playfield element over a player, but the reverse applies with the other bit/s, then you get black. Regardless of what colour registers say.

 

If you don't have any lower bits set, then players/playfield have their colour registers ORed together - although with hires modes, the luminence value of a pixel will always take precedence.

[MaPa]

If you have conflicting priorities, e.g. a bit set which has a playfield element over a player, but the reverse applies with the other bit/s, then you get black. Regardless of what colour registers say.

 

If you don't have any lower bits set, then players/playfield have their colour registers ORed together - although with hires modes, the luminence value of a pixel will always take precedence.

 

So playfield 0 ORed with player 0, 1 with 1 etc. ? What if player 5 is set? Will it be ORed with something or not? Maybe 5th color in multicolor char mode?

[cas]

I personally prefer a doc as you can simply browse through or have print out easily next to your PC...

 

Me too, that is why I was using XWiki for the AtariWiki, as it has the PDF Export feature. The PDF export Feature is currently broken for long documents, but I have the new version already running on my Laptop and there the PDF Export is working also for long documents.

 

My goal for the final Atari Wiki is that the users can mark interesting articles from the wiki and export these articles to one PDF "book" complete with Table of Content and Index, so that everyone can build "personalized" editions of the "ultimate Atari Programmers Reference Manual".

 

It will be a long way ..., but one need to have golas and dreams

 

Carsten

[cas]

Putting together a document like this should be a community effort. I have considered hosting this in a wiki. but would like to have a more formal (and printable/bindable) product at the end. If you would like to correct items, write working source code examples, add new articles, please do so! Don't worry too much about grammar or spelling, I can clean that up as necessary. (Ideally, source code should compile with ATasm, but this is not truly necessary).

 

If you are submitting an article for consideration, I would prefer it be in either OpenOffice format, RTF or raw ASCII, just to increase the speed with which I can incorporate the articles. Just add them to this thread, or PM me. I would like to restrict topics to items that are not covered elsewhere (i.e. I don't consider this a replacement for something like De Re Atari).

 

Note: there are several places where there are "notes to self" in the text, these will someday be expanded into real articles, be updated or removed.

 

In any case, if I wait until it is "done", this probably will never get released. So, here it is in a (very) rough state.

 

I would like to have version 1.0.0 of Ironman Atari out by the end of the year. In the meantime, consider this a preview, and enjoy.

 

Hello Mark,

 

(see my reply about the AtariWiki above)

 

is it "ok" if I put some of the content of this document in the AtariWiki? Of course you're welcome to take any content from the AtariWiki into the Ironman Atari document if it fits. So both, the Wiki and the Document can be updated.

 

Carsten

[Rybags]

If you have conflicting priorities, e.g. a bit set which has a playfield element over a player, but the reverse applies with the other bit/s, then you get black. Regardless of what colour registers say.

 

If you don't have any lower bits set, then players/playfield have their colour registers ORed together - although with hires modes, the luminence value of a pixel will always take precedence.

 

So playfield 0 ORed with player 0, 1 with 1 etc. ? What if player 5 is set? Will it be ORed with something or not? Maybe 5th color in multicolor char mode?

 

That would be Player 4 actually, getting it's normal colour from PF3.

 

Remember that these ORs only occur if objects overlap.

 

Also, ORing of colour registers doesn't necessarily produce a new colour (but in most cases will).

 

e.g. 02 or 36 = 36, AA or 22 = AA

[MaPa]

If you have conflicting priorities, e.g. a bit set which has a playfield element over a player, but the reverse applies with the other bit/s, then you get black. Regardless of what colour registers say.

 

If you don't have any lower bits set, then players/playfield have their colour registers ORed together - although with hires modes, the luminence value of a pixel will always take precedence.

 

So playfield 0 ORed with player 0, 1 with 1 etc. ? What if player 5 is set? Will it be ORed with something or not? Maybe 5th color in multicolor char mode?

 

That would be Player 4 actually, getting it's normal colour from PF3.

 

Remember that these ORs only occur if objects overlap.

 

Also, ORing of colour registers doesn't necessarily produce a new colour (but in most cases will).

 

e.g. 02 or 36 = 36, AA or 22 = AA

 

I did some tests and it looks like pl0&1 are ORed with pf0&1 and are over pf2 and background (tested in gr.7). Players 2&3 are under pf0&1, over background and ORed only with pf2. Can you explain please if you know what with what is ored, what display priorities are? 4 players, 5th player mode.. etc.

[Heaven/TQA]

what did you write into 623 priority register?

[Rybags]

OK, I probably wasn't quite 100% on that.

 

It's easy to test - just do it in BASIC.

 

Easiest way to get some players is just POKE the PM graphics registers and position registers.

 

e.g. POKE 53248,160 : POKE 53248+13,255 - put player 0 onscreen and set all it's pixels.

 

Then open a graphics mode like GR. 5 (nice big pixels). To test overlap of PF3 stuff you'd need to use mode 12 or 13 (multicolour text).

 

To make things simple, use colours where only one or two bits are set e.g. set Player 0 colour to 34 ($22), Playfield 0 to 132 ($84)

[MaPa]

what did you write into 623 priority register?

 

0 in the lower nibble of that register, as stated in PDF in first post. Or just put 0 there, the upper bits doesn't matter and works as always, 5th player, overlap player colors and gtia modes....

 

OK, I probably wasn't quite 100% on that.

 

It's easy to test - just do it in BASIC.

 

Easiest way to get some players is just POKE the PM graphics registers and position registers.

 

e.g. POKE 53248,160 : POKE 53248+13,255 - put player 0 onscreen and set all it's pixels.

 

Then open a graphics mode like GR. 5 (nice big pixels). To test overlap of PF3 stuff you'd need to use mode 12 or 13 (multicolour text).

 

To make things simple, use colours where only one or two bits are set e.g. set Player 0 colour to 34 ($22), Playfield 0 to 132 ($84)

 

I'm lazy and incompetent... I hoped you will nicely summarize it to me in nice colorfull table

 

BTW. this feature was uknown to me and others like PG, Raster... I thought that there is nothing more you can pull from ATARI and I think this can push it towards more colorfull graphics. I wonder how many of you and other programmers did know about it? Of course it's not totally unknown feature if it exists in emulator

Edited April 9, 2008 by MaPa

[Rybags]

It wasn't really considered "useful" in the old days.

 

But, I guess now it becomes much more relevant, especially with the trend to incorporating PMGs into static pictures, and the move to better sprites utilising both PM and Playfield graphics.

 

The priority "conflict" feature is also something that I don't think has been used very much at all.

 

It's getting late here now, but I might whip up a little BASIC program tomorrow that can show the effects.

[carmel_andrews]

Perhaps an idea would be to have something online like commodore 64/128 users do with the CSDB website,,,and perhaps us non codehead types like me my be incentivised to got down to some 6502'ng

 

Share your thoughts, as well as your knowledge...Don't keep it to yourselves

[Heaven/TQA]

www.codebase64.org

 

but thank god for atari... i spend yesterday 4 hours chatting with top coder from Oxyron having a damned 4x4 chunky mode in place... c64 really is a pain when coming to "undocumented" features based on cycle exact treating the VIC... which all things are build in in Antic (FLD, FLI, 4X4, Hardware scrolling, display list effects etc...)

 

the only things I would like to have... the c64 sprites.... and colour ram...nothing more... no...even not the SID...

Edited April 9, 2008 by Heaven/TQA

[+Philsan]

the only things I would like to have... the c64 sprites.... and colour ram...nothing more... no...even not the SID...

+1

[Heaven/TQA]

Rybags... is your description already build in in g2f and atari800win?

[gauntman]

Putting together a document like this should be a community effort. I have considered hosting this in a wiki. but would like to have a more formal (and printable/bindable) product at the end. If you would like to correct items, write working source code examples, add new articles, please do so! Don't worry too much about grammar or spelling, I can clean that up as necessary. (Ideally, source code should compile with ATasm, but this is not truly necessary).

 

If you are submitting an article for consideration, I would prefer it be in either OpenOffice format, RTF or raw ASCII, just to increase the speed with which I can incorporate the articles. Just add them to this thread, or PM me. I would like to restrict topics to items that are not covered elsewhere (i.e. I don't consider this a replacement for something like De Re Atari).

 

Note: there are several places where there are "notes to self" in the text, these will someday be expanded into real articles, be updated or removed.

 

In any case, if I wait until it is "done", this probably will never get released. So, here it is in a (very) rough state.

 

I would like to have version 1.0.0 of Ironman Atari out by the end of the year. In the meantime, consider this a preview, and enjoy.

 

 

(see my reply about the AtariWiki above)

 

is it "ok" if I put some of the content of this document in the AtariWiki? Of course you're welcome to take any content from the AtariWiki into the Ironman Atari document if it fits. So both, the Wiki and the Document can be updated.

 

Carsten

 

Hi Carsten,

 

Posting content from Ironman on AtariWiki is fine. I was thinking about setting up a wiki myself, but there is no need for competing sites diluting the information. The wiki site could serve as an excellent place for the community to submit and refine articles between IronMan updates.

 

There has been a lot of good feedback from this thread so far, and I am incorporating a lot of it into the next revision. I expect to have another revision by end of May.

 

Rybags, have you confirmed on real hardware that when there is conflicting priority with PM/PF the overlap area will turn black (even against a PF0 of a different color)?

 

...Embarrassingly enough, my 130XE is in storage at the moment!