WIP: Advanced DLI tutorial

[+playermissile]

Here's a work in progress, a tutorial on advanced DLIs that I've been working on for the last week or so.

 

http://playermissile.com/dli_tutorial/index.html

 

It's got a bunch of source code and examples, including one with the 4 players multiplexed 12 times each on screen.

 

I don't have all the examples written yet, but feedback appreciated on what's there!

 

 

[+Stephen]

Fantastic!  It will take a while to digest all of this, but an initial scan looks great, nice progression.

[abbotkinneydude]

Excellent! Thank you so much Rob for sharing this! Can't wait to dive into it! Also, I notice you used SPHINX to generate the layout of this page. This is a great tool (+ very small footprint for the end user).

[Preppie]

A quick scan shows I'll probably need to find a couple of hours to read and digest that article, so might be a couple of days before I post any comments other than tyvm

[+playermissile]

8 hours ago, abbotkinneydude said:

Excellent! Thank you so much Rob for sharing this! Can't wait to dive into it!

Great, will be looking forward to feedback on the examples.

8 hours ago, abbotkinneydude said:

Also, I notice you used SPHINX to generate the layout of this page. This is a great tool (+ very small footprint for the end user).

I love me some static site generators! And static websites. I haven't yet understood out how to write Sphinx extensions so here are some raw::html sections, but I do like the layout it generates.

[+playermissile]

8 hours ago, Preppie said:

A quick scan shows I'll probably need to find a couple of hours to read and digest that article, so might be a couple of days before I post any comments other than tyvm

You're welcome. I think this is something like we were looking for? ?

[Preppie]

I just read the article and it is, without doubt, the best piece on DLIs I've seen.

 

I knew the basics already, and I've firgured out some stuff over the past week with trial and error (but it's great to have it confirmed, and to have a good reference for the future), and I've learned some new stuff too.  I'm looking forward to you completing those last few points.

 

Some more details on mid screen changes would be nice.  Maybe I should do some 2600 coding, that would probably teach me what I need to know.

 

I can't thank you enough for the time and effort you've put into this.

 

[+playermissile]

Just now, Preppie said:

I just read the article and it is, without doubt, the best piece on DLIs I've seen.

Thank you. I'm glad it is helpful. I've certainly learned a lot writing it.

Just now, Preppie said:

Some more details on mid screen changes would be nice.  Maybe I should do some 2600 coding, that would probably teach me what I need to know.

Revision 2 is up now with a simple static demo on horizontal reuse of players. It's complicated by my use of ANTIC mode 4 as the playfield, but shows the basics for a static screen. Using it for realz would probably be limited to bitmap modes since ANTIC clobbers the first scan line of text modes so badly. I think someone with far, far better game programming chops than me is going to have to flesh out an example of dynamic repositioning of players on a line.

 

Maybe if someone can point me to an example of a game that uses that, I can dissect it on an upcoming episode of the podcast. The current episode (almost done editing!) is the game Quarxon which uses DLIs and is what prompted me to ask about DLIs and ultimately write this tutorial.

Just now, Preppie said:

I can't thank you enough for the time and effort you've put into this.

You're welcome. I'm only juuuuuust a bit too late to submit it to ANALOG for a four issue series like Kyle Peacock's tutorial on scrolling.

[777ismyname]

1 hour ago, playermissile said:

Thank you. I'm glad it is helpful. I've certainly learned a lot writing it.

Revision 2 is up now with a simple static demo on horizontal reuse of players. It's complicated by my use of ANTIC mode 4 as the playfield, but shows the basics for a static screen. Using it for realz would probably be limited to bitmap modes since ANTIC clobbers the first scan line of text modes so badly. I think someone with far, far better game programming chops than me is going to have to flesh out an example of dynamic repositioning of players on a line.

 

Maybe if someone can point me to an example of a game that uses that, I can dissect it on an upcoming episode of the podcast. The current episode (almost done editing!) is the game Quarxon which uses DLIs and is what prompted me to ask about DLIs and ultimately write this tutorial.

You're welcome. I'm only juuuuuust a bit too late to submit it to ANALOG for a four issue series like Kyle Peacock's tutorial on scrolling.

Only 30 years ? 

 

This is what I’ve been looking for. Thank you!!!

[rensoup]

3 hours ago, Preppie said:

I just read the article and it is, without doubt, the best piece on DLIs I've seen.

 

I agree great and comprehensive article!

 

(minor thing: I believe txa/pha pla/tax = 11 cycles  but  stx ZP ldx ZP = 6 cycles  )

[+playermissile]

Just now, rensoup said:

I agree great and comprehensive article!

Thanks!

Just now, rensoup said:

(minor thing: I believe txa/pha pla/tax = 11 cycles  but  stx ZP ldx ZP = 6 cycles  )

Although the code would might be hosed if the DLI ever got interrupted or the ZP location got used by something else. Still, given that you can guard against that pretty well, I wonder why more DLIs didn't do it that way? Every example I've run across in the wild so far uses the txa+pha/pla+tax combos. Too bad we don't have the 65c02 phx/plx.

Edited December 6, 2019 by playermissile

[phaeron]

At least some of the executables are missing init/run addresses, so they don't run in RespeQt (computer just restarts).

 

The part about interlaced video is, I think, a bit misleading and unnecessary. The Atari doesn't produce even/odd fields because it has no half scanline or half color clock per scanline, so there is no field polarity; on displays that force the Atari's output into an interlaced image, it's a crapshoot which polarity you get. As for why the frame rate and machine clock don't agree, it's the other way around: the non-standard video timing causes a non-standard frame rate of 59.92Hz/49.87Hz. You can actually hear this difference if you simultaneously play the same VBI-based music on a real Atari and an emulator, where they will stay in sync with the accurate frame rate and diverge very quickly with the broadcast frame rate.

 

Typo in a couple of places: VDLSLT instead of VDSLST.

 

Typo in rainbow example (EXE is OK):

        adc #$11        ; change color value, luminance remains the same

DLI-interrupting-DLI -- this is a bug in Altirra. It is allowing one too many instructions to execute because it is not distinguishing between HALT and RDY cycles when checking the NMI length.

 

[Yaron Nir]

I see you have referred to my CC65 tutorial . Kudos ?

[Yaron Nir]

And may I add, good work!

[Preppie]

9 hours ago, rensoup said:

(minor thing: I believe txa/pha pla/tax = 11 cycles  but  stx ZP ldx ZP = 6 cycles  )

Both of these are 4 bytes when assembled, how do you figure out that one is 11 cycles and the other 6 cycles?

[shanti77]

Pha/txa/pha and pla/tax/pla = 18 cycles

 

Sta rejA/stx rejX and ldx rejX/lda rejA = 12 cycles

[Rybags]

Self-modifying code version of the above also 12 cycles.  Or 10 if the DLI code is on z-page.

[rensoup]

13 hours ago, playermissile said:

Although the code would might be hosed if the DLI ever got interrupted or the ZP location got used by something else. Still, given that you can guard against that pretty well, I wonder why more DLIs didn't do it that way? Every example I've run across in the wild so far uses the txa+pha/pla+tax combos. Too bad we don't have the 65c02 phx/plx.

yes I hadn't thought about DLis interrupting DLis but to be fair I doubt there's any real use case for it.

 

like Rybags mentioned

 

stx selfmod+1

 

selfmod:

 ldx #$ff

 

6 cycles if you want to avoid using the ZP. I'm pretty sure this is a common trick.

 

edit: if you need to do as much work as possible before WSYNC, it's a must (preloading registers, WSYNC, store into HW registers)

 

Edited December 6, 2019 by rensoup
more work

[rensoup]

5 hours ago, Preppie said:

Both of these are 4 bytes when assembled, how do you figure out that one is 11 cycles and the other 6 cycles?

code size and execution times aren't especially linked, you have to take into account addressing mode.

[Preppie]

51 minutes ago, rensoup said:

code size and execution times aren't especially linked, you have to take into account addressing mode.

I had the answer to my question right in front of me

 

I use this for quick assemble/dissassemble of short routines https://www.masswerk.at/6502/disassembler.html

 

There's a full explanation of the instruction set and number of cycles used in the link from that page (https://www.masswerk.at/6502/6502_instruction_set.html), so if I'd opened my eyes I wouldn't have asked.

[ivop]

Shameless plug of my own table

http://ivop.free.fr/atari/opcodes.html

You can sort by clicking the headers. I use it all the time.

 

 

[+playermissile]

Just now, phaeron said:

At least some of the executables are missing init/run addresses, so they don't run in RespeQt (computer just restarts).

I thought ATasm was populating $2e0 automatically, but that's a big nope so they were all missing. They're all updated now, and I hope to finish my SDrive-Max soon so I can test on real hardware. I fixed all the other typos you mentioned, thank you.

Just now, phaeron said:

As for why the frame rate and machine clock don't agree, it's the other way around: the non-standard video timing causes a non-standard frame rate of 59.92Hz/49.87Hz.

Ah, ok, so ... I'm not sure which frequency the actual hardware crystal oscillator was (NTSC colorburst timing of 3.579545 MHz, or 4x at 14.31818 MHz), but that result was divided down either by 2 or 8 to get to the 1.7897725 MHz at which the processor ran. So, then, 262 scan lines at 114 cpu cycles = 29868 cpu cycles per frame and 1789772.5 cpu cycles per second means 1789772.5/29868 = 59.9227 frames per second.

 

Reading this now pretty much just restates what you've written in the Altirra hardware reference manual, but now the cloud in my brain has lifted. Thanks!

[+playermissile]

Just added a simple example of parallax scrolling.

 

[Chilly Willy]

Nice! Combine that with multiplexed sprites and you have a good base for many games. Excellent work there. I like how you're just using letters and numbers for graphics. It helps point out the different parts of the example very easily.

[ascrnet]

Hi playermissile,

 

Error 404 ?

https://raw.githubusercontent.com/playermissile/dli_tutorial/master/xex/dli_interrupting_vbi.xex

Greetings