ANTIC architecture; as flexible as the VCS?

[Mr SQL]

Been looking at ANTIC; how flexible is it - can you race the beam and run code in the vertical blanks?

 

looks like with NTSC the entire screen is refreshed 60 times per second like a 240p signal.

 

Looking at how feasible it would be to port the Virtual World BASIC runtime; I could write something specific to the 8-bit (maybe next) but it would be really cool to be able to cross-compile BASIC games for both systems, and cross-assemble assembly games that use the runtime.

 

EDIT: Is it possible to load a 200 WSYNC loop into a single DLI routine and just draw the screen?

 

Been doing some reading ... http://www.atariarchives.org/dere/chapt05.php

 

Where can I get the source to BasketBall for the 400/800? Preferrably if someone has commented it so I can follow it; this program uses a kernel like the VCS, I will use it as a template.

Edited February 29, 2016 by Mr SQL

[kenjennings]

There's nothing to prevent a DLI routine from acting across multiple scan lines... or even the entire screen.

 

If you have an ANTIC display list running a text or map mode realize that there's DMA supporting that display for the display list, fetching screen memory, and for text modes fetching the character set graphics. All these have bus priority over the race-the-beam 6502 code. Even the blank line instructions take time for ANTIC to fetch for DMA which can throw off the timing where they occur.

 

The point of all the bells and whistles in the Atari 8-bit computers (that is, ANTIC playfields, and the player/missile DMA) is to make the coding easier so a continuous display kernel is not needed to maintain the display.

[Mr SQL]

There's nothing to prevent a DLI routine from acting across multiple scan lines... or even the entire screen.

 

If you have an ANTIC display list running a text or map mode realize that there's DMA supporting that display for the display list, fetching screen memory, and for text modes fetching the character set graphics. All these have bus priority over the race-the-beam 6502 code. Even the blank line instructions take time for ANTIC to fetch for DMA which can throw off the timing where they occur.

 

The point of all the bells and whistles in the Atari 8-bit computers (that is, ANTIC playfields, and the player/missile DMA) is to make the coding easier so a continuous display kernel is not needed to maintain the display.

Interesting, I gotcha on the cool things ANTIC can do but I think building a raw kernel with CTIA may give me the flexibility to host the runtime for Virtual World BASIC. The VCS is the lowest common denominator in this equation because I want the runtime to compile the games nearly the same across platforms. My runtime is SuperCharger based so it pushes the VCS, how cool would it be to be able to automatically port the games just by using a CTIA runtime instead of a TIA runtime?

 

Probably also easier for me to port my TIA runtime to CTIA having never programmed Atari's beyond the VCS before

 

I do want to learn about using display lists though, they're really cool.

 

Know any dasm templates I can compile and test in Altirra?

[Rybags]

Doing screen stuff on the computer is very different to 2600, and porting games across is usually not straightforward.

 

Part reason for Antic's existence is so you don't need to do that kernal based stuff though of course it still applies for doing lots of colour changing or PM repositioning.

I imagine your virtual worlds are represented somewhere as bitmaps or otherwise procedurally generated.

The trick with porting such things is to replace the middle-man (kernal) with code that simply renders the graphics in a way the computer can easily display them.

 

Realistically, the only thing similar on both systems is player/missiles and the method of dealing with them is very different. But for the purpose of porting, it's way easier to go from 2600 to computer vs the other way around.

[phaeron]

Took a look at Virtual World BASIC's capabilities, and I don't think a kernel is the way to go here. The virtual playfield is tiny in 800 terms -- 20x10 window with 4cclk x 9 pixels mapped onto a 96x20 virtual field -- and could be mapped to a hardware-scrolled mode 8 (GR.3) display with expansion during setpixel/getpixel calls from 1-bit to byte-per-pixel and some trickery to make the mode lines 9 scans tall instead of 8. The sprites are the problem. vwBASIC allows direct access to the TIA's sprite registers and that means repeating and reflection are possible, two capabilities that the TIA has that CTIA/GTIA doesn't. GTIA can only render 40 sprite bits per scanline (4 x 8-bit players + 4 x 2-bit missiles), and with repeating TIA effectively does 55 (6 x 8-bit players + 2 x 1-bit missiles + 1-bit ball). Also, unlike TIA which has its registers mapped in page zero, GTIA's registers require absolute addressing to access, and its functions are spread out over more registers. That negates a lot of the clock speed advantage that the 800 has over the 2600 for a display kernel.

 

To do a fully accurate emulation of the exposed TIA capabilities it would probably be necessary to invert usage, rendering TIA's playfield with GTIA's sprites and TIA's sprites as soft sprites on the playfield. There's not enough time to do that while racing the beam, but there should be enough to do it over the entire frame. It looks like vwBASIC sprites are fairly short (8 scans), which means that the soft sprites don't need to be that big. If you don't care about replication, it's a lot easier as the playfield and sprites can be mapped with just a bit of translation and table lookup.

 

TIA's audio capabilities also don't map 1:1 to POKEY's, particularly the polynomial modes. However, it's much easier to get a good-enough mapping with a set of tables and a fairly small VBI routine.

 

[Mr SQL]

Great posts and insight!

 

Yes the virtual world and sprites are bitmaps and the sprites are small at 8x8, fit right inside one of the big tiles. Those are 4 cclk x 10 scanlines, but the last one is always 4 cclk x 6.

 

Haven't thought about reflection and replication but none of the games use it yet; that would be an option that wouldn't port - I'd like to make all 4 sprite and missile graphics available on the A8 version too which also wouldn't port. But games that don't use those features on both sides could still compile for either platform.

 

What does the A8 have for playfield graphics? That's the big one; I need to be able to scroll the virtual world around that 20x10 window for 30 FPS of full screen animation. That and the tile mapping (rendering sprites bound to the virtual world and not the screen) are the big features I need to be able to implement for this to be feasible.

[Rybags]

There's multiple playfield modes in bitmap and text and software tricks can expand on that even further.

 

There's no direct equivalent to TIA playfield 40x192 @ 1bpp.

As Avery mentioned there's Graphics 3 which is 40x24 @ 2bpp. Tricks can be employed to turn it into 40x192 but at great cost in CPU cycles.

Probably easier would be to just use one of the GTIA modes which allows 80x192 @ 4bpp.

 

The thing is you don't necessarily have a direct equivalent so it's either throw together some sort of emulation layer, change the intermediate processing or just change the individual game's programming.

[Mr SQL]

There's multiple playfield modes in bitmap and text and software tricks can expand on that even further.

 

There's no direct equivalent to TIA playfield 40x192 @ 1bpp.

As Avery mentioned there's Graphics 3 which is 40x24 @ 2bpp. Tricks can be employed to turn it into 40x192 but at great cost in CPU cycles.

Probably easier would be to just use one of the GTIA modes which allows 80x192 @ 4bpp.

 

The thing is you don't necessarily have a direct equivalent so it's either throw together some sort of emulation layer, change the intermediate processing or just change the individual game's programming.

Very cool; the 40x24 processor intense mode looks like my target; I can turn this into 20x10; already turning the 40 horizontal pf pixels on the VCS into 20 tile pixels and use a software blitter to slide the playfield CAM window around the virtual world.

 

I don't want to change the individual game level as the games don't know what system they are running on, they access phantom hardware and manipulate high level objects presented by the runtime for nearly everything; the Assembly games only know they are 6502 asm, the BASIC games don't even know that.

 

Well mostly, at least if things like sprite mirroring and duplicating aren't used to manipulate the hardware outside the runtime.

[+JAC!]

In fact with ANTIC and the DL you can have a n-times the screen playfield and scroll it with close 0% CPU. Including you can even soft-scroll it in X & Y direction. The "Playfield camera view to pan about the virtual world" is basically built in.

 

This here works completely by changing LMS pointers in the DL (plus moving the 4 players around).

 

[Mr SQL]

In fact with ANTIC and the DL you can have a n-times the screen playfield and scroll it with close 0% CPU. Including you can even soft-scroll it in X & Y direction. The "Playfield camera view to pan about the virtual world" is basically built in.

 

This here works completely by changing LMS pointers in the DL (plus moving the 4 players around).

 

Wow that is cool, ANTIC is powerful that bitmap is detailed!

 

I wonder why the Basketball programmers choose to write a kernel instead of using the DL, perhaps they had been programming the VCS and weren't familiar with ANTIC.

 

I want to get started with some examples. Your IDE WUDSN has several assemblers included and a lot of interesting development tools - does it have the 8-bit equivelent to the vcs.h include for the VCS (saw it listed as "equates" on another thread but cannot find it) and the utility to transform the .bin to an 8-bit executable format?

[Bryan]

A good use of A8 kernels is RastaConverter.

[tschak909]

If you look closely at the Basketball code, you'll see that they used a kernel only as a means of changing colors by watching VCOUNT. -Thom

[Rybags]

Rally Speedway is character mode - it's probably the case that charmode would be more suited to your needs. Additionally you can add detail at little extra cost if you're just dealing with maze type game worlds where movement boundaries are constricted and snap to certain pixel boundaries.

 

Basketball - they could have done it various ways but similar techniques have been employed in later games. Jungle Hunt is a good example, it keeps a colour map of the hero's colours per scanline. Pole Position changes fine H-Scrolling values on the fly as well as doing colour and positional change for PM objects.

[Mr SQL]

I downloaded WUDSN, has great examples but only ATASM supports the 8-bit, does anyone use dasm?

 

My compiler formats the asm for dasm so there's less for me to change if I can find a dasm template to use; I'm porting the runtime first, but I eventually want to port the compiler to run on the 800 too. Have to look at what assemblers are available for the 800 as well and can't use ones that run on the FPGA of the MyIDE II which I know has some great tools on it.

[MEtalGuy66]

How flexible is ANTIC?

 

Check this out:

 

http://atariage.com/forums/topic/211689-60-fps-video-using-side-2/

[Mr SQL]

How flexible is ANTIC?

 

Check this out:

 

http://atariage.com/forums/topic/211689-60-fps-video-using-side-2/

60 FPS and with color and resolution - incredible!

 

On the VCS My BASIC runtime can render 30 FPS of full screen animation with the playfield graphics which I'm looking to port transparently to the 8-bit, when I'm done with this project I'll definitely look into pushing the 8-bit; I like what I see!

 

Can anyone point me to a list of equates in lieu of an include file? These are all over the place for the VCS (the lookups for COLUPF, TIM1T, etc), no doubt I'll come across one presently looking through code examples. So far coding examples indicate that RUNAD maps to 02E0 in the absence of an include file, which is a start(ing address).

 

Edit: I found the dasm examples I was looking for with more hard coded equates from DanB: http://www.atarihq.com/danb/files/52pm.txt

 

They're for the 5200 but I think I can get started with these (same hardware so easy to change to 8-bit?) since I wanted to include the 5200 as well as the 400, and it doesn't matter which order for this phase.

 

I've been playing around with WUDSN too which is awesome, and has a ton of features and cool tools I am just learning about.

Edited March 2, 2016 by Mr SQL

[+JAC!]

does it have the 8-bit equivelent to the vcs.h include for the VCS (saw it listed as "equates" on another thread but cannot find it) and the utility to transform the .bin to an 8-bit executable format?

There is "C:\jac\wudsn\Workspace\Atari2600\VCS.asm" for using the IDE with MADS & VCS in the standard distribution.

This and the Atari-8 counterpart can be downloaded from http://www.wudsn.com/index.php/ide/installation .

- http://www.wudsn.com/productions/atari2600/ide/VCS.asm

- http://www.wudsn.com/productions/atari800/ide/SystemEquates.asm

[Mr SQL]

There is "C:\jac\wudsn\Workspace\Atari2600\VCS.asm" for using the IDE with MADS & VCS in the standard distribution.

This and the Atari-8 counterpart can be downloaded from http://www.wudsn.com/index.php/ide/installation .

- http://www.wudsn.com/productions/atari2600/ide/VCS.asm

- http://www.wudsn.com/productions/atari800/ide/SystemEquates.asm

Thanks JAC! Can the systemequates.asm for the 800 also be used with the dasm Assembler?

[Rybags]

Using equates from other sources comes down to expected syntax.

With assemblers there's generally a few common differences that you might find, the first 3 here especially relevant to equates files.

 

1. Assigning labels is usually done by = but some assemblers use EQU. Some allow both.

2. Comments are usually started by ; in rare cases it'll be different. In most cases, anything coming after a parsed instruction and operands will be treated as comments regardless of leading character.

3. Some only allow and expect upper case, others ignore case, some are case sensitive, e.g. WSync different than WSYNC or wsync.

4. Controlling location counter usually by *= in some cases by ORG. * on it's own usually in any to allow location counter to be used for calculations and assignments.

5. Some difference in expression of instructions, usually types with multiple addressing modes which can also act on Accumulator, e.g. LSR. Some expect LSR A, some just LSR, some allow both.