News for hackers. Stuff that matters.
Re:Atari 8-Bit Display List Interrupts: An Advanced Tutorial by keithnz on Thursday December 05, 2019 @12:02AM (#21710114)
13-14year old me was playing around with DLI, to get up to 16 colors on the screen at the time at HIGH resolution.

Towards the end of its popularity...well, it seems popular now.....but, one of the games that made use of multiple techniques, including DLIs to get what was, at the time, an amazing graphics game was ballblazer https://www.youtube.com/watch?v=qri5xavBdh4

Re:Atari 8-Bit Display List Interrupts: An Advanced Tutorial by ido on Thursday December 05, 2019 @11:07AM (#21713441)
Was 1985 really towards the end of its popularity? The 800XL (the most popular model) wasn't even widely available until 1984.

It was never as popular as the c64 but as far as I can tell its peak was after it became dirt cheap around that time (and the follow up XE series was the cheapest).

Re:Atari 8-Bit Display List Interrupts: An Advanced Tutorial by downerending on Thursday December 05, 2019 @12:50PM (#21714421)
Speaking as a poor kid of the day, there were a series of machines sold off for pennies in their decline, and that was the only computer hardware we ever had access to.

IIRC, for me it was the TI 99/4a first, and the 800XL second. Then later, a Xerox PC (which was actually just a re-badged Olivetti).

Bottom-feeding, FTW.

Re:Atari 8-Bit Display List Interrupts: An Advanced Tutorial by keithnz on Thursday December 05, 2019 @03:44PM (#21716275)
well, maybe more that the Amigas came out in 85/86, and all the buzz was around that :) the 8bits were still popular.
Re:Atari 8-Bit Display List Interrupts: An Advanced Tutorial by snvzz on Wednesday December 04, 2019 @11:40PM (#21710040)
Seems to precede Amiga copperlists. Common staff might have been involved.
Re:Atari 8-Bit Display List Interrupts: An Advanced Tutorial by emily-c on Wednesday December 04, 2019 @11:44PM (#21710049)
You can thank Jay Miner for that. The Atari is sort of like an Amiga-lite in a lot of respects.
Re:Atari 8-Bit Display List Interrupts: An Advanced Tutorial by atarimonkey on Thursday December 05, 2019 @01:15PM (#21714661)
Joe Decuir received an IEEE fellowship based largely on his work on the Atari and Amiga platforms. He gave excellent talks this year at the Vintage Computer Festival East and the VCF Pacific NW (both of which I attended), which are online.
Re:Atari 8-Bit Display List Interrupts: An Advanced Tutorial by w0utert on Thursday December 05, 2019 @08:24AM (#21712047)
Very interesting, thanks for posting! I'm working on-and-off on a fantasy console side-project that is based on the same ideas used for home computers from the 8-bit and 16-bit era, and the interaction between the CPU and video chip (in terms of clocks, memory access, interrupts, etc) is something I still haven't completely figured out in my head. This article does an excellent job explaining how these kinds of things worked, great stuff!
Re:Atari 8-Bit Display List Interrupts: An Advanced Tutorial by gmiller123456 on Thursday December 05, 2019 @01:20PM (#21714714)
Just FYI, this is for the Atari computers, not the 2600 console. The 2600 used the 6507 processor, basically a 6502, but it didn't have the interrupt pins (to save on cost). I imagine it made programming for the 2600 a lot more interesting.
Re:Atari 8-Bit Display List Interrupts: An Advanced Tutorial by boomlinde on Friday December 06, 2019 @07:18AM (#21721132)
Having tried at it after programming for platforms like the C64 and VIC20 for a while, I found it refreshingly simple. There's nothing that'll steal the bus from you at strange times (like badlines on the C64) and since there are no interrupts there's no interrupt jitter either. It makes it easier to keep track of how many cycles you're wasting and when exactly.

The 2600 doesn't even really synchronize video for you. It can pause the CPU until the next scanline (via a WSYNC register, like the computers) but it's up to the programmer to generate the correct number of lines and generate a vertical sync pulse. Because all the graphics registers are one dimensional, the CPU will most likely be occupied with reloading them during the visible portion of the screen to produce 2D graphics and handle game logic outside it, keeping track of when to prepare for drawing again by polling a timer register or keeping track of how many cycles were wasted exactly.

Another interesting limitation is that there is only a very crude way of absolutely positioning sprites horizontally. You do this by strobing a register that resets a horizontal sprite counter. This positions the sprite horizontally where the beam happens to be at the time, so you have to pace your positioning with the beam. After you have done that to position the sprite roughly where you want it, you can nudge it relatively to its current position -8 to 7 (or something like that) pixels at a time.

It became apparent to me while working with it and reading the documentation that this was designed to be the minimum viable product to support just a couple of types of games (e.g. Combat and Pong) which makes the variety of its game library much more impressive.

My game source is at https://github.com/boomlinde/jupitersumo if anyone is interested. It's a two player game with a simple graphics kernel (two player sprites, a playfield and two life counters).