Jump to content


  • Content Count

  • Joined

  • Last visited

Posts posted by jum

  1. OK here's the cc65 code and ASM output for comparison. Note I used the cc65 "-Or" optimisation flag to enable register variables:


    cc65 code:


    void main()
        uchar i;
        i = 31;
        do {
            MIKEY.palette[i] = work_palette[i];    
            i -= 1;
        } while ( i >= 0 );
        for (i = 0; i < 32; i++)
            MIKEY.palette[i] = work_palette[i];    


    Assembler output (.s file):

    ; ---------------------------------------------------------------
    ; void __near__ main (void)
    ; ---------------------------------------------------------------
    .segment    "CODE"
    .proc    _main: near
    .segment    "CODE"
        jsr     decsp1
        lda     #$1F
    L0060:    sta     (sp)
        ldx     #$FD
        lda     #$A0
        adc     (sp)
        bcc     L0044
    L0044:    jsr     pushax
        ldy     #$02
        lda     (sp),y
        lda     _work_palette,y
        ldy     #$00
        jsr     staspidx
        lda     (sp)
        sbc     #$01
        bra     L0060
    L005F:    lda     (sp)
        cmp     #$20
        bcs     L004E
        ldx     #$FD
        lda     #$A0
        adc     (sp)
        bcc     L0058
    L0058:    jsr     pushax
        ldy     #$02
        lda     (sp),y
        lda     _work_palette,y
        ldy     #$00
        jsr     staspidx
        lda     (sp)
        sta     (sp)
        bra     L005F
    L004E:    nop
        jmp     incsp1

    Way longer/slower (for this example), and very hard to follow! 

    • Thanks 2

  2. Would be nice to see a comparison with cc65 generated ASM. If I get a chance tonight I will do same code in cc65 and upload the asm generated.


    Also would need to expand the lynx lib/module for Millfork.

  3. Hi Karri, actually I just now found the cause of the crashes (after a LOT of SD card swapping :{ 😞


    If I disable collisions, the game does not crash. I'm using the default TGI config with 2 draw buffers and collision buffer like so:


    // tgi locations of collision buffer (using -C lynx-coll.cfg in linker)
    #define COLLBUF 0xA058
    #define BUFFER1 0xC038
    #define BUFFER2 0xE018


    So possibly the stack is getting overwritten (underwritten?)? IDK, maybe something else?


  4. My game "Sky Raider" is almost finished, but as usual the last 10% takes more time than the first 90% :)


    I also need to compose a very short tune for the title / start. Something "stirring" similar to Apocalyse Now / Voyage of the Valkyries, or Star Wars, but shorter and simpler.


    Also still need to test/fix on real hardware, and do some optimisation/tweaking/polishing...


    Don't know if I will get it to 100% done before submitting. But I know if I submit it now, I will stop working on it... :)


    Here's the title screen sprite:



    • Like 3

  5. The "Apple IIc Reference Manual Vol 2" has a section on the differences between a 6502 and a 65C02 (see "Appendix A"), that I came across today.


    A few instructions take 1 less cycle, and one instruction (JMP abs) takes 1 more cycle.


    The BIT instr affects status register bits differently, and JMP indirect can differ.




  6. On 11/4/2018 at 2:54 AM, Nop90 said:

    Managed to fix palette output in sprpck. The code assumes the use of windows bmp v1, that has a fixed header size, but since the time sprpck was originally coded micosoft evolved the bmp format adding other bmp versions with variable header size and optional data after the header.


    To fix the code I read the some data from the header itself to locate the starting point of the palette. Didn't tested it with every possible bmp format, but at least with the files generated from GIMP it now works fine.


    If someone is interested in using sprpck instead of SP65 i can upload the fixed code on my github.

    Thank you Nop90. I have also had this "bad palette" problem with sprpck and BMP files (generated using GIMP).


    Please add a link to your github with fixed sprpck. Thanks.


  7. On 6/20/2019 at 12:34 PM, Nop90 said:

    The drawback of your struct is that it expects to chain always sprites of the same type (in this case a full sprite with scale info, palette and collision data) while having a field with a pointer to a generic char array allow you to chain different sprites types, that in the end can make you save memory.


    Hope to not seem rude, I don't want criticize  you code. Often I wrote ugly code if it works at first try. I'm only giving my 2 cents to encourage the discussion.


    No offense taken :)  It's just an alternative way to set up simple SCB chain. You could also save 8 bytes per sprite by leaving the palette mapping out of your SCB struct, and manually setting the palette mapping before drawing the sprite chain. Depends on what you are doing, how many sprites you have, etc.


  8. This is how I have my SCB struct defined:


    // Lynx Sprite Control Block structure
    typedef struct SCB {
        uchar sprctl0;
        uchar sprctl1;
        uchar sprcoll;            // spr collision number
        struct SCB *next;
        uchar *data;
        signed int hpos;
        signed int vpos; 
        uint hscale;
        uint vscale;
        uchar palmap[8];
        uint collResult;        // collision result data (offset = 23)
    } TSCB;


    Note "struct SCB *next;". This allows us to reference the next SCB without casting, like so:


    struct SCB clearSCB =    {    0xc0,            // 4bpp / bg_no_collision
                                0x10,            // compressed, hsize/vsize
                                0x00,            // 0 to clear coll buffer 
                                &playerSCB, sprclr,
                                0x100, 0x100, 0xa000, 0x6600,
                                { 0x01, 0x23, 0x45, 0x67, 0x89, 0xab, 0xcd, 0xef },
                                0 };





  9. Yes, I've read the full tutorial on how to set up and compile the dev environment (thanks for writing them).

    To be honest, as it looked like quite complicated with a lot of stuff to install, I was hoping that there was some precompiled windows builds floating around, even if they are not up to date, so I could go through a simplified / easier process :).


    Do you confirm me that they're isn't any compiled release available?


    I am using a precompiled Windows version of CC65 (on Windows 7).


    Just looked up where I got it from: https://sourceforge.net/projects/cc65/


    It seems to be 4 years old now.


    I followed the link from the CC65 main page: https://cc65.github.io/


    Not sure if there is something better now, but this version is much better than the "old" cc65.


    Edit: Looking at the https://github.com/cc65/cc65 src files, it seems there is some recent activity. May be possible to build cc65 using Visual Studio?


    - Jum


    PS: I anyone has any ideas on how to do a fast vertically scrolling playfield on the Lynx, please let me know. At the moment I am experimenting with using 2 80 x 102 sprites, stretched 4x horizontally.

  10. I'm a gonna register (as soon as I decide what I want to do).


    Haven't entered a console programming contest since 2005! (Chopper X in PDRoms 3.33 competition).


    May pull out an old unfinished demo/proto and finish it off, or maybe do a very simple new game, probably involving dachshunds...


    Alternatively, I can be a judge if you need one.

    • Like 1

  11. Bug report on real hardware:


    - The ghosting of the walls is pretty bad.


    - Sometimes when there is a robot above me I try

    to shoot up, but nothing happens. Even if I move

    up a little, it still does not work.



    Thanks Chris. Not sure what causes the "ghosting" of the vertical walls, I just assumed it was my Lynx' old and crappy screen :)

    I think the "jamming" of the gun may be caused by the bullets going off-screen without hitting anything, and since the player has 2 bullets that are recycled, he can't fire until they time out. I will check and fix this.

    (You can maybe try to avoid this problem by not firing out a doorway?).


    Edit: Seems ghosting may be caused by bad capacitor(s) in the Lynx.

  • Create New...