Jump to content
Have You Played Atari Today?
2600|5200|7800|Lynx|Jaguar|Forums|Store  

vidak

Members
 View Profile  See their activity

  • Content Count

    499

  • Joined

  • Last visited

Posts posted by vidak

  8. Posted

    I'm not sure if you can pin posts to the front of your blog on AtariAge, but that could be one way to share your collection.

     

    Making your own spreadsheets is fun!

     

    I do know people do it, and it can function sometimes like a "wishlist".

    • Like 2

  13. Posted

    Okay I think I know why.

     

    The graphics are being loaded from the bottom of the table. The padding of 15 lines pushes the graphics data far enough down to make it ready to be loaded on the first scanline it is called. say we have a band which is 40 lines long. 40-2 = 38 (see below). The height of the temporary GRP1 graphics is 23. So 38-23 =15. The graphics need to be padded to the height of the band, and the last line of the 38 byte long table is the first byte always loaded.

     

    I am also not drawing GRP1 on the first two scanlines of every band up and down the screen.

     

    The reason why the colours are wrong still evades me. Screen band 0 is more or less correct, but none of the others are.

     

    That leads me to believe I've messed up the code which copies over the pointers from Band 0's pointers.

     

    GRP0's shape changes on the RIGHT side of the screen. Perhaps this is a kernel timing issue... this is what I mean when I talk about artefacts.

    • Like 1

  17. Posted

    Okay I've finished my first attempt at the pointers for GRP1.

    But I need some help - could someone assist in some debugging?

     

    The masking for GRP0 works, and the graphics pointers for GRP0 work. The colour pointer for GRP0 is wayyyy off, though. It's pointing way too far down, right into the temporary GRP1 colour data table. When I compiled the code the first time, both the colour and graphics pointers for GRP0 worked, but after I fiddled with the GRP1 labels, the colour pointer stopped working. Confusing.

     

    The second problem I have is that the graphics and colour pointers for GRP1 don't work at all. I am attempting to statically and manually fix all 5 bands of GRP1 to a single couple of tables... maybe the tables are crossing a page boundary?

     

    The two black bands that comprise most of the glitchy GRP1 graphics is the value $2C. I think the location being loaded is $ED10 - Stella debug reports this as CXP1FB.

     

    ANOTHER problem I'm having is that the vertical controls appear to be flipped. Pushing down moves Che upwards and vice versa.

     

    BUT:

     

    There are no more real artifacts as Che, GRP0 moves between bands. This is a huge improvement over the last kernel version.

    Anyway, as always, help is always greatly appreciated.

     

    Thanks in advance.

     

    PS. One weird thing I'm noticing is that the Stella debugger formats my graphics data differently every time I compile a new version of the binary. Sometimes it recognises the graphics data as graphics, and sometimes it doesn't...

    coloured_guerrilla023.asm

    guerrilla23.zip

    post-61331-0-83069600-1517097882_thumb.png

  23. Posted

    I can't see HMOVE anywhere in this code!

     

    I use the linux text editor called "Kate", and it seems to be showing some strange varying quality of indentation in your code.

     

    1. Please fix the indentation in your code text so that it is uniform

     

    2. I don't think you've initialised your constants properly. For instance here:

    YPos    .byte

    What is the actual binary value Ypos is supposed to be holding?

     

    3. You have not formatted your program labels properly.

     

    This is incorrect:

    Start sei ; disable interrupts

    Do either of these:

    .Start
     sei

OR

Start:
     sei

    That's all I have time for right now, I'll come back soon.

    • Like 1

  24. Posted

    You should check out SpiceWare's Collect Tutorial HERE.

     

    The routine listed has a few variations - you can also fiddle with it.

     

    From my understanding, RESPX needs to be set at cycle 23.

     

    The way HMOVE works on the Atari 2600 is that it will automatically draw the Player Graphics at whatever horizontal location you set it.

     

    So after you do a HMOVE, and when you finally draw GRP0 or GRP1 at the right VERTICAL position, the 2600 will be waiting for you to STA GRP0 and will automatically draw GRP0 at the right horizontal position.

    It's a little bit like magic!

AtariAge
Forums
Store
General
Follow AtariAge

Copyright ©1998-2021 AtariAge

×
×
  • Create New...