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

cd-w

Members
 View Profile  See their activity

  • Content Count

    2,433

  • Joined

  • Last visited

  • Days Won

    2

Posts posted by cd-w

  5. Posted · Edited by cd-w

    If you want to add numbers that are longer than 8-bits it is very useful. A number larger than 8-bits is represented using multiple 8-bit values. To add them together, you clear the carry and start adding them together from the lowest pair. If the addition overflows, the carry-out becomes the carry-in for the next addition. The code below shows how to add two 16-bit numbers. Notice that there is no CLC after the first addition as the carry flag needs to be preserved:

    add16:
    clc				; clear carry
    lda num1lo
    adc num2lo                  ; add low numbers
    sta reslo			; store low sum
    lda num1hi
    adc num2hi		        ; add high numbers with carry
    sta reshi			; store high sum
    • Like 1

  6. Posted · Edited by cd-w

    I have to admit I don't understand your suggestion. I can have 256 possible values for PF1 and 256 possible values for the AND mask; how can I precompute something in that situation?

     

    Although the PF and MASK have 256 possible values each, it seems unlikely that you will need all possible combinations. If you could reduce the number of "building blocks" for your levels to 16 (e.g. by halving the horizontal resolution) then you could do the AND operation before the kernel (i.e precompute it) and pack 2 results into a byte as shown above. However, given that you are only performing this operation every 4 lines it does seem that you will not save all that many cycles.

     

     

    No extra RAM, no extra computing chip, only some more ROM (16K probably). See my stance on this issue here.

    To sum it up, if I'd use extra RAM and DPC+, I could simply use a C64 instead and play Space Taxi on that machine. icon_smile.gif

     

    An extra 128bytes is still a long way from 64KB icon_smile.gif

     

    Chris

  7. Posted · Edited by cd-w

    The mask operation during the kernel looks quite expensive - it appears you are doing something like this:

    lda    (LEFTPTR),Y  ; 5
and    LEFTMASK,X   ; 4
sta    PF2        ; 3 = 12

    I wonder if you could precompute the mask operations and store them in RAM. With a vertical resolution of 40, you would need 160 bytes, i.e. too much. But if you could find 16 patterns that covered all the needed PF values you could encode two positons in 1 byte, which would only need 80 bytes, i.e:

    ldx    LEFT,Y        ; 4
lda    Left0,X       ; 4
sta    PF2           ; 3
lda    Left1,X       ; 4
sta    PF1           ; 3 = 18

    LEFT would contain the PF2 pattern in bits 0-3 and the PF1 pattern in bits 4-7. It would waste a bit of ROM as you would need to fill two pages of possible values for Left0 and Left1 but it would save a lot of cycles.

     

    What are your constraints? With an extra 128-bytes of Superchip (SARA) memory, the RAM wouldn't be an issue. And with DPC+ you could simply read the data out of a fast fetcher?

     

    Chris

  9. Posted

    I'm happy to report that the homebrew I was the most curious about, Star Castle, works great on my unit. I'll post a pic. I just saw that it was marked as not compatible in the list.

     

    There are two Star Castle homebrews. It is "Star Castle Arcade" by me and Thomas Jentzsch that doesn't work. The earlier "Star Castle" homebrew by D. Scott Williamson is the one that is working.

     

    Chris

    • Like 1

  17. Posted · Edited by cd-w

    Wow. what a.. very good homebrew. any others worth checking out that are FB portable compatible?? (and anywhere I can donate to you for this work?)

     

    Thanks - no donation necessary! Homebrew games tend to push the limits of the original hardware, so many will not work on the flashback as the emulator is quite basic. There is a very long thread discussing game compatibility here:

    https://atariage.com/forums/topic/258970-atari-flashback-portable-compatibility-list/?hl=%20flashback%20%20compatibility

     

    Chris

  19. Posted · Edited by cd-w

    Here is a version of Juno First modified to work on the ATGames Atari Flashback Portable (FBP) device. The speech and savekey/highscore support have been removed as this will never work on the FBP. Please let me know if you find any issues.

    To get it working, unzip the attachment and copy the "Juno1.bin" file into the "Game" folder on your SD card.

    Chris

    Juno1_FBP_Alpha_01.zip

    • Like 10

  20. Posted

    After testing a few more permutations, the problem appears to be the detection of F4 bankswitching in the FBP rather than the code itself. It seems the FBP needs a lot of evidence of F4 bankswitching before it will select this method. The attached code is identical to the previous one, but with the blank space filled with bankswitching ("sta $FFF4, etc.") instructions.

     

    So far, I have found the following with the FBP:

    • TIA emulation is rather basic - early HMOVEs don't work, and sprite positioning is off by a few pixels.
    • Bankswitching detection could be better.
    • Some illegal opcodes appear to work, e.g. LAX, NOP variations

    Chris

     

    f4test_working.zip

     

    • Like 4

  21. Posted · Edited by cd-w

    I'm having some difficulty getting basic F4 bankswitching working on the Atari Flashback Portable (FBP). I was investigating why Juno First doesn't work on the FBP and immediately hit an issue with the bankswitching. I have written the simplest possible bankswitching test (see attached), but the FBP just hangs when I run it.

     

    I initially assumed that the FBP didn't support F4 bankswitching, but then I encountered this thread with some F4 bankswitch conversions: http://atariage.com/forums/topic/258970-atari-flashback-portable-compatibility-list/?p=3653305

    The F4 versions (e.g. Gyruss and Mr Do's castle) work fine on the FBP.

     

    Does anyone have any theories why my bankswitching code might be choking the FBP?

     

    Thanks,

    Chris

     

    f4test.zip

    • Like 2

  25. Posted · Edited by cd-w

    It is a bit of a waste of ROM, but the ARM really likes 32-bit values, so you could do the conversions at compile-time and define your sprite data as:

     

    data | color<<4 | PAL(color)<<8 | SECAM(color)<<16  // PAL & SECAM are C macros
    The fetcher code would then be:

     

    unsigned int sprite = spriteData[x++];
fetcher[data++] = sprite & 0xFF;
fetcher[color++] = (sprite >> TVshift) & 0xFF;
    Or something like that :)

     

    Chris

AtariAge
Forums
Store
General
Follow AtariAge

Copyright ©1998-2021 AtariAge

×
×
  • Create New...