Jump to content
IGNORED

WIP: Advanced DLI tutorial


Recommended Posts

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!

 

 

multiplex.gif

  • Like 17
Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

 

  • Thanks 1
Link to comment
Share on other sites

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.

  • Like 1
Link to comment
Share on other sites

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

  • Like 1
Link to comment
Share on other sites

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 by playermissile
Link to comment
Share on other sites

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.

 

  • Thanks 1
Link to comment
Share on other sites

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 by rensoup
more work
Link to comment
Share on other sites

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.

  • Like 1
Link to comment
Share on other sites

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!

Link to comment
Share on other sites

  • 2 weeks later...

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