Jump to content

RevEng

Members
  • Posts

    7,607
  • Joined

  • Last visited

  • Days Won

    12

Posts posted by RevEng

  1. I'd like to submit a feature request for the Img2Code utility.

     

    Right now if you load a picture with 256 lines and hit the "Create Image" button, the number of lines gets changed to 192, and indeed only 192 lines of data are generated per slice.

     

    The soon-to-be released version of the titlescreen kernel uses images up to 265 lines tall for scrolled pictures or animation frames. It would be cool if Img2Code could work with these larger images!

    • Like 2
  2. Here's a minimal program that triggers the "less than 312 scanlines" problem...

     

    set tv pal
    set kernel_options player1colors
    
    dim frame=a
    scorecolor=$0f
    
    gameloop
    frame=frame+1
    frame=frame&31
    rem ** burn a variable amount of time
    for t=0 to frame
     z=z
    next
    drawscreen
    goto gameloop
    

    ...the player1colors kernel option is key. Without it, the scanlines are stable.

  3. Thanks for the comments on my contribution, guys!

     

    Very nice, RevEng!

    Can you attach .spr files?

    Can you design a matching standing front sprite?

     

    Unfortunately I don't use vbb, so I can't generate a .spr. I've attached sprite sheets, which hopefully should help with any import.

     

    The standing guy front view is less interesting than the walking side view, but the same thing applies in real life. Click on the images to see the gif animation...

     

    post-23476-128500618269_thumb.gif post-23476-12850064999_thumb.gif

    post-23476-128500651083_thumb.gif post-23476-128500649033_thumb.gif

     

    ...the neck could be filled in for a more realistic (less representational) look, but if the animation stays on that frame for a while your brain starts to see it like the blob of pixels it is.

     

    The sprite sheets...

     

    post-23476-128500629305_thumb.gif post-23476-128500631608_thumb.gif

  4. In most cases you can consider the time between "drawscreen" commands to be 1/60th of a second in NTSC.

     

    Its actually slightly less than 1/60 and I'm assuming you didn't overun the allotted cycles in bB, but assuming that each tick of your timer is 1/60th of a second will work unless you're implementing a "clock program" that needs to accurately display the time for months.

     

    You should be aware that your frame counter will reach 255 and start over at zero again. If you need more time you'll need another variable for minutes. (or 256*seconds)

     

    Yes, this is the best method. The 2600 has a hardware timer, but its only useful for shorter intervals, and its already used by bB.

  5. IMO the "format-shift" precedence and also the right to use a backup of copyrighted software by the purchaser would satisfy the intent of the law unless it specifically states "One cannot download ROMS". It doesn't really seem like a grey area at all

    There will never be such a clarifying statement; copyright law starts off by saying that you have no right at all to copy someone else's work, and then adds exemptions. Anything not stated is forbidden. (aka "all rights reserved")

     

    Judges don't usually ignore case law when making rulings, in favour of weighing the intent of the law. And maybe the judge will decide that the intent of copyright law is to protect the copyright holder, and you should license a rom from them instead.

     

    There are 2 cases I cited in which the final rulings said:

     

    1) ROM backups aren't legal.

    2) The source of the copy must be from the user's copy on their own equipment; Otherwise the copy is illegal, even if the end-user's use is non-infringing.

     

    Like it or not, software is handled differently in copyright law. That's why it gets its own set of exemptions.

     

    Applying a format shifting precedent on audio files to rom files is tenuous, though I'd love to see it tested.

  6. Format shifting has never been applied to software in a copyright court case, so Nukey is right that it's a grey area. The closest judgement for software that I know of would be in Micro-Sparc, Inc. v. Amtype Corp., and the court ruled that third party copies were illegitimate since they weren't made from the user's purchased media and equipment.

     

    And to head off someone bringing up the software backup exemptions, software backups of cartridge games is not an exemption according to Atari v. JS&A, due to the longevity of cartridges.

     

    But its all academic, since nobody is going to go to court over Atari 2600 roms.

  7. I took a quick look, and I think atari2600land is missing the part that actually displays the high score.

     

    One way to do that is to set the score variables to the saved high score while displaying the titlepage. Or you can get more fancy and swap the saved high score with the current high score every few seconds.

  8. Not useless, just niche.

     

    It's a great place to store your sound fx or music routines, as they will be called every 60th of a second, no matter how many drawscreen commands you've scattered throughout your code.

     

    There are other similar uses - if you're cycling a color, doing an animation to a sprite that should happen every 60th, etc.

     

    That said, if the routines should only happen in certain phases of the game then you'll need a variable to track that and skip the routines if the game is in a phase they shouldn't run in.

    • Like 2
  9. What's the point of hooking it up to my PC monitor? I can already play Atari 2600 games on my PC through emulation. Is there an option for TV out?

     

    I don't want to use Sega Genesis controllers to play Atari 2600 games. Will this machine support 2600 controllers?

    They've hooked it up to an LCD TV using composite video. Its not a computer monitor.

     

    The Sega Genesis pads work on the Atari 2600 pretty much the same as a CX-40. I'm pretty sure he's just using them because he prefers them or they're all he has on hand.

  10. That's true, and I wasn't trying to find fault with your method and results. But the title of your thread is "cycles used by bB operations," so I thought you were trying to determine the cycles used by specific bB instructions, as opposed to a section of more complex code.

    True enough that's how it started, but even then certain bB instructions that look atomic do switch banks and jump into subroutines without the user necessarily being aware of it. (a=b/3, the pf* commands, ...).

     

    In truth the thread wasn't meant to be a definitive cycle-accurate list - just a stab at how relatively expensive certain common instructions actually were. Everybody talks about how bad non-power-of-2 divisions are, for example, but it was interesting to see the scale of the issue.

     

    Totally agreed that a definitive cycle-chart would be great, but problematic to create. You'd need at least 2 values for each operation in non-bankswitched and bankswitched binaries, then you'd need asterix exceptions for stuff like pfscroll, and all the other issues you noted.

     

    It might be better to just create a graph of relative cycle times, without a scale. or with a scale but without scale dividers. The point being it's relative expense that's being displayed. Certain operations that are highly variable (like non-power-of-2 divisions) might show a fuzzy/transparent area from the minimum cycle to maximum cycle time.

     

    My 2 cents anyway.

  11. These numbers are wrong, because of the way you tested them. The easiest way to test them is as follows

    There's nothing wrong with the way I tested them, if you don't mind working with a margin of error.

     

    The stella method you outline is good for simple short code, but often it's more complex code you're interested in measuring. With my method, even when there are subroutines and bankswitching involved, I can get a "good enough" answer literally in a few seconds. Then I can tweak and re-time the code without having to step into subroutines and add up dozens or hundreds of opcode timings.

     

    These are the cases where our answers disagree... (the other were in my stated margin of error)

     

    RevEng: a.d=b.b+c.f : 11.52 cycles (+-1.3 cycles)

    SeaGtGruff: a.d=b.b+c.f : 105 cycles

    Comment: The discrepancy is due to a bB bug, reported in this thread and acknowledged by batari. A 8.8=4.4+8.8 should have called the library (with a bankswitch in a bankswitched binary) but it didn't.

     

    RevEng: a.d=b.e+c.c : 160.0 cycles (+-6.4 cycles) **

    SeaGtGruff: a.d=b.e+c.c : 105 cycles

    Comment: Mine was for a bankswitched binary, so there's bank switching overhead. It was mentioned later in the thread that changing to a 4k binary changed the time to "106.6 cycles (+-4.2 cycles)".

     

    RevEng: a=b/3 : 460.8 cycles (+-12.8 cycles)

    SeaGtGruff: a=b/3 : 38 cycles

    Comment: I used a non-zero value for b to get more of a typical case, since dividing in bB is iterative, and dividing 0 by 3 is an unusually fast corner-case. Also I was bankswitching. If I use b=0 and then the non-banked answer would be 38.66 +-1.33 cycles, which agrees with your result. What does using b=128 (the value I used, IIRC) and using bankswitching add up to with your method?

  12. If some of the arrays would be used for generating repeatable but unpredictable data, like unique scenery or enemy placement, you could probably instead use a LFSR seeded with the player position.

     

    Pitfall used this to great effect on the Atari 2600, to generate 255 unique screens with a small amount of rom. A 16-bit LFSR can produce 65535 unique values.

×
×
  • Create New...