Jump to content

8bit-Dude

Members
  • Content Count

    181
  • Joined

  • Last visited

  • Days Won

    1

Posts posted by 8bit-Dude


  1. On 3/6/2019 at 6:08 AM, CharlieChaplin said:

    I want to say THANK YOU for sharing all these Sector COPY programs.

    I have a 130 XE, XF551, and SIO2SD and wanted to duplicate double density floppies from ATRs (which use XBOOT/XBIOS).

    I tried several popular copiers like MyCopyR and Copy2000, but was getting nowhere (sometimes they would not read data from SIO2SD, sometimes formatting floppies would not work, and so on....).

    I then tried various versions of the programs you shared until FINALLY, DISKCOPY.ATR (option C) gave me perfectly working duplicates!! I am surprised how hard it was to find a compatible sector copiers, but I am CHUFFED!! 🙂

    • Like 1

  2. I recently got a XF551 and tried using it daisy chained to the Fujinet.

    I loaded MyDOS 4.50 from Fujinet D1, and configured XF551 as D2.

    No matter what I tried, drive would not format floppies or copy data to them.

    The drive moved, but I got various errors (mainly 163, which I think is a communication error).

     

    Next I tried to connect XF551 directly as D1, and daisy chained SIO2SD to it as D2.

    That worked fine, and the drive was able to format floppies, copy data...

     

    I wonder if anyone else got similar issues with the XF551/Fujinet combo?


  3. 7 hours ago, ivop said:

    It could be nice to also create an Android/Linux or iOS version ;)

    It is possible to use the emulator Argon on these platforms. But the devs need to add 8bit-Hub support (I have already offered to share the necessary code with them).

    • Like 1

  4. 2 hours ago, MrTrust said:

    Is the 8-bit Hub doing coprocessing on this or could you play it on a stock machine offline?  I get that would be largely missing the point, but just out of curiosity.

    Presently the 8bit-Hub only handles the network communication. But I plan to use the on-board SD-card for storage a game maps (as the number increases), while co-processing is considered further down the line.
    Also, the game has no "offline" mode (at least for now). The game logics and assets run on the server (Python script). This makes the make very easy to "mod" (new maps, new weapons, different game settings...).

    • Like 2
    • Thanks 1

  5. Thanks for sharing that Bill, the idea of swapping the charset every other line is a pretty good idea! In fact, I am already using a tileset in the dungeon demo (2x2). It would be fairly easy to make row 1 is in range 0-127, and row 2 in range 128-255 of charset.

     

    In 8bit-Unity, I have to use the lowest common denominator always (which in this case means 128 chars because of Atari), while trying to avoid over-complicating things. I will keep your suggestion in mind, and see if I can come up with something elegant...

     


  6. Thanks for sharing the links Chris!

     

    There are 3 banks of 4 sprites, used as follows:

      Bank 1: Player (color1), Player (color2), Sword, Enemy
      Bank 2: Enemy, Enemy, Enemy, Enemy

      Bank 3: Enemy, Enemy, Enemy, Enemy

     

    So as soon as you have more than 1 enemy on screen, it may start flickering if one of the enemies is on the same DLI line as the player. There are tricks for recycling PMs on same DLI line, but going to that level of detail (with cylce counting) would slow down the system too much...

     

    Regarding the demo, I hope to turn it into a fuller game later this year.

    • Like 6

  7. Sweet! It worked after commenting out a few lines in /libsrc/atari/irq.s:

     

    .segment        "LOWCODE"
    
    IRQStub:
            cld                             ; Just to be sure
    .ifdef __ATARIXL__
    .ifdef CHARGEN_RELOC
            ;lda     CHBAS
            ;pha
    .endif
    .endif
            lda     PORTB
            pha
    .ifdef __ATARIXL__
            and     #$FE                    ; disable ROM
    .endif
            ora     #$10                    ; map main memory into $4000..$7FFF area
            sta     PORTB
    .ifdef __ATARIXL__
            ;set_chbase >__CHARGEN_START__
    .endif
            jsr     callirq                 ; Call the functions
            pla
            sta     PORTB                   ; restore old memory settings
    .ifdef __ATARIXL__
    .ifdef CHARGEN_RELOC
            ;pla
            ;sta     CHBAS
            ;sta     CHBASE
    .endif
    .endif
            jmp     IRQInd                  ; Jump to the saved IRQ vector

    I will also take into account your advice about saving A and X. It is probably safer to use PHA/PLA than store in non ZP location.


  8. Hey Guyz!

     

    I have been implementing sprite multiplexing, taking inspiration from https://playermissile.com/dli_tutorial/

     

    I got it working very nicely when the screen DLIST uses 0x0e. The DLIST consists of the screen address followed by groups of 1 x DLI (0x8e) followed by 7 x Hires lines (0x0e).
    (see screenshots of racing stadium below)

     

    hires.thumb.PNG.07159697bd0e78f15c7b058cc6674e6c.PNGhires-DLI.thumb.PNG.6e518bde4bf8809969e81ebb4c0b5461.PNG

     

    Next, I tried to get something similar when the screen DLIST uses 0x04. DLIST now consists of the screen address followed by (0x84) lines. But for some strange reason, turning 0x80 ON immediately shuffles colors on that line. The CHARs are correct, but the colors applied to them looks like some kind of repeating pattern. I have attached an example showing what it looks like when only 5 lines with DLI are enabled in the middle of screen (see screenshots of dungeon below)

     

    dungeon.thumb.PNG.3c6322d43431ea5a9b4f99e998c0f49d.PNGdungeon-DLI.thumb.PNG.5213aed01ba8e22cc7a64d6a5a82253c.PNG

    I wonder why mode 0x04 produces this strange bug... If I try to setup a DLIST with 0x02, then I have no such problem....

     

    I would be super grateful if someone could take a look at the attached ATR, to see if anything obvious is wrong. The DLIST starts at $0900, and Charset is located at $A000. I have also attached a copy of the DLI code (even using an empty DLI produces the exact same problem anyway...).

     

    Cheers,
    Tony

     

    DLI.s demos-atari.atr


  9. 1 hour ago, 42bs said:

    I'd say the most of the files in "utils" aren't your work so you should add a huge credits file.

    All the Python files in the Scripts/ folder are my work. I guess you are talking about the rest: CC65, emulators, trackers and various .exe files not yet converted to Python scripts... I will improve the credits in the installer, but it is hard to track down everyone's name. So sometimes generic credits like "cc65 team" are used.


  10. On 1/27/2021 at 7:59 PM, 42bs said:

    BTW, it is a pity that you use a lot of other peoples stuff but do not credit them.

    I have been adding credits in source files over past year or so, including to Karri. Please let me know the offending files you spotted, I will add credit accordingly.

    • Thanks 1

  11. 1 hour ago, Fadest said:

    Is the flag in the LNX header set up ?

    Is that a compilation flag for building the CC65 Lynx Lib? (the eeprom functions seems to get included by default in the makefile)
    You must mean something else, but I can't figure out what.

    1 hour ago, Fadest said:

    Also, you may need an EEProm file created before to run the ROM, IIRC.

    I cannot understand what this means. Do you mean some kind of .incbin in CC65, or something relating to Handy?


  12. Sorry to revive an old thread, but I need some advice on the EEPROM code in CC65.

    First-of-all, while there are codes for 93C46, 93C66, 93C86, the only available function seems to be a modified version of the 93C46 code.

    When trying to call lynx_eeprom_write(0, 1), the program just hangs in Handy (the SAGE fixed version). Am I supposed to initialize something before calling this function?

×
×
  • Create New...