Jump to content

Photo

Why the ripple upward?


32 replies to this topic

#26 Andrew Davie OFFLINE  

Andrew Davie

    Stargunner

  • 1,782 posts
  • Dr.Boo
  • Location:Tasmania

Posted Sat Sep 10, 2016 4:15 AM

Pretty cool! :)

 

That 168 scanline block is most of the screen, where else do you find time for the task queue besides the top and bottom vertical blanks?

 

Anywhere we're waiting for a timer to complete. Just the top and bottom areas of the screen, I seem to recall.

But there are a number of different tasks done with different priorities/orders. Some tasks rather big could only be done in some places in the frame. Some were 'filler' tasks that took very little processing time so they could fill in the gaps left over after the big tasks had run, and so be sure to use every single drip of processing time that was available.



#27 Mr SQL OFFLINE  

Mr SQL

    Stargunner

  • 1,746 posts

Posted Sat Sep 10, 2016 11:35 AM

 

Anywhere we're waiting for a timer to complete. Just the top and bottom areas of the screen, I seem to recall.

But there are a number of different tasks done with different priorities/orders. Some tasks rather big could only be done in some places in the frame. Some were 'filler' tasks that took very little processing time so they could fill in the gaps left over after the big tasks had run, and so be sure to use every single drip of processing time that was available.

Most excellent design - a tile mapped mario world style game without extra hardware requires all the available time in both blanks and careful load balancing/queueing.

 

This is one feature I think could be improved in bB, unless I am mistaken only one of the vertical blanks is available for the game loop.

 

Virtual World BASIC (inspired by bB and BD) sports two game loops to allow BASIC to run in both vertical blanks, giving the programmer instant access to granular load balancing.

 

It was initially designed to step down to 30 HZ to use an entire frame for repositioning the full screen playfield camera and sprites which kept programming in BASIC very simple like bitd by minimizing the need for the programmer to worry about load balancing.

 

It's now evolved with DLI's like the Atari home computers that give the programmer fine grain load balancing control to update a region of the screen  from either of the blanks with more time left over for additional tasks the programmer can load balance on a per frame basis, but the architecture is more complex as you've described.

 

I think your analogy about a few weeks to write a great game in BASIC compared to six months in asm is spot on, but without finding a way to alleviate the load (like the first method stealing a frame, or using a 32-bit co-processor to update the framebuffer) then the architecture and concept for load balancing/queueing becomes just as important for the BASIC programmer as for the Assembly programmer.

 

As I was working with ANTIC I realized DLI's gave Atari BASIC programmers the ability to organize regions of the screen to exert fine grain load balancing control - another great influence for making this design architecture accessible to the BASIC programmer. I also tried to simplify it so it's easier to use in Virtual World BASIC - DLI's are fairly complicated to use in Atari BASIC.

 

I think much of the speed improvement in BASIC over asm on the VCS comes from being isolated from kernel load balancing - this architecture the BASIC programmer (thankfully) never has to worry about.

 

I see the BD 168 scanline kernel without WSYNC is yielding 500 extra cycles of processing power to draw that display, that's a fantastic optimization - your kernel tree must be perfectly balanced with no  branches taking even a single extra cycle for that to work! :)
 



#28 Andrew Davie OFFLINE  

Andrew Davie

    Stargunner

  • 1,782 posts
  • Dr.Boo
  • Location:Tasmania

Posted Sun Sep 11, 2016 6:01 AM

 

I see the BD 168 scanline kernel without WSYNC is yielding 500 extra cycles of processing power to draw that display, that's a fantastic optimization - your kernel tree must be perfectly balanced with no  branches taking even a single extra cycle for that to work! :)
 

 

Think of 8 banks all containing IDENTICAL code (the code I posted).  When a bank-switch happens inside that code, it's actually switching to one of the 8 banks to draw the particular 'character' line (21 scanlines).  That bank ALSO contains the data/visuals for the character line.  So where you se the bankswitch, it's actually switching OUT the code that is actually running. The next instruction is a completely different bank's instruction which just HAPPENS to be exactly the same as the next instruction in the bank the bankswitch was executing in. The very LAST bank just has a 'rts' instead of continuation of the code - so it does the looping/branching for 8 lines without a single cycle of cost.  It's essentially inline code, spread over 8 banks, every single cycle catered for.



#29 gauauu OFFLINE  

gauauu

    Moonsweeper

  • 316 posts
  • Location:Illinois

Posted Mon Sep 12, 2016 7:45 AM

The very LAST bank just has a 'rts' instead of continuation of the code - so it does the looping/branching for 8 lines without a single cycle of cost.  It's essentially inline code, spread over 8 banks, every single cycle catered for.

 

You, sir, are a genius.



#30 Thomas Jentzsch OFFLINE  

Thomas Jentzsch

    Thrust, Jammed, SWOOPS!, Boulder Dash, THREE·S, Star Castle

  • 22,721 posts
  • Always left from right here!
  • Location:Düsseldorf, Germany, Europe, Earth

Posted Wed Sep 14, 2016 11:27 AM

Note that in complex kernels you might not use WSYNC at all (Probably only Boulder Dash does that)...

Too many credits for us. icon_smile.gif

I am sure there are quite lot of kernels not using WSYNC (or only very rarely) and even well before Boulder Dash. But probably a bit less complex.

BTW: I just searched my mails. That kernel was done in May 2005.

#31 tschak909 OFFLINE  

tschak909

    Stargunner

  • Topic Starter
  • 1,824 posts
  • Location:USA

Posted Wed Sep 14, 2016 11:12 PM

The Xevious kernel...

 

-Thom



#32 Andrew Davie OFFLINE  

Andrew Davie

    Stargunner

  • 1,782 posts
  • Dr.Boo
  • Location:Tasmania

Posted Thu Sep 15, 2016 7:32 AM

 

You, sir, are a genius.

 

As always, anything BD related is pretty much a joint effort between Thomas and myself. I contributed some, he contributed lots.

I'm only half a genius. Thomas is the other half + more :)



#33 Thomas Jentzsch OFFLINE  

Thomas Jentzsch

    Thrust, Jammed, SWOOPS!, Boulder Dash, THREE·S, Star Castle

  • 22,721 posts
  • Always left from right here!
  • Location:Düsseldorf, Germany, Europe, Earth

Posted Thu Sep 15, 2016 8:17 AM

Thomas is the other half + more icon_smile.gif

Maybe 1% genius on my side + 99% HardWorkTM icon_smile.gif






0 user(s) are browsing this forum

0 members, 0 guests, 0 anonymous users