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

Wrathchild

Members
 View Profile  See their activity

  • Content Count

    2,924

  • Joined

  • Last visited

Posts posted by Wrathchild

  1. Posted · Edited by Wrathchild
    Elaboration on COLRSH use

    6 hours ago, dmsc said:

    No, but you don't need that, as the DLI takes values from arrays you simply write different values on each call.

    That makes it quite a restrictive model and a not too-realistic use-case of DLIs, i.e. you'll potentially need to limit the number of changes due to time criticality. 

     

    6 hours ago, dmsc said:

    The DLi counter is already reset on the VBI.

     

    The 'DLi counter' you are exploiting is the COLRSH register ($4F).

    Once the attract mode is triggered this is given a value from middle clock register ($13) during the VBI. (e.g. "bx db(COLRSH)>4")
    Whilst in most cases just colours or sprite positions are being set and so at most will then to stop being animated and give them different colours, this is dangerous as it means that access to DATA BYTE arrays are potentially out of bounds.

     

    As the DLI vector isn't refresh by the OS during the Vblank (e.g. checked with "bx write=$200") this means that the last DLI is responsible for setting the first DLIs address.

    During development this often can cause the effect of 'rolling' when the number of interrupts in the Dlist don't match the number in your chain.

    Hence setting the first DLI in the VBlank is a good help towards helping to rectify that.

     

    I've experimented and demonstrate what I mean in the attached modified example.


    From this I would say it would be nice if DATA WORD support could be added, e.g. 

    ' Dli addresses
DATA dli_adr() WORD = 0,0,0

' Our DLI writes the position and
' colors to Player 1 and Player 2
DLI SET d3a = pos INTO $D000, pos INTO $D001,
DLI        = $28 INTO $D012, $2E INTO $D013,
DLI        = dli_adr INTO $200

DLI SET d3b = pos INTO $D000, pos INTO $D001,
DLI        = $88 INTO $D012,
DLI        = dli_adr INTO $200

DLI SET d3c = pos INTO $D000, pos INTO $D001,
DLI        = $CE INTO $D013,
DLI        = dli_adr INTO $200

dli_adr(0) = ADR(d3b)
dli_adr(1) = ADR(d3c)
dli_adr(2) = ADR(d3a)

     

    So initially I'd thought that the last line of a dli could be: 

    DLI = DLI d3b

    but this isn't possible and so considering if the above was working then the dli_adr could be eliminated by using: 

    DLI = d3b INTO $200

    but as I understand it the lack of forward reference inhibits writing it that way and so the array is suffices.

    Which means that actually it is reusable between different screens such as a title page and game screen by applying the addresses of different DLI definitions.

     

    Keep up the good work!

     

    altdli.bas altdli.xex

  2. Posted

    5 minutes ago, tane said:

    One should be loaded in a NTSC system, and the other in a PAL system, automatically.

    You can't do that as (presumably) they occupy the same address

     

    15 hours ago, Wrathchild said:

    in a MADS built xex you could then use a 'ini' section to load the second to another address, decide if it is needed, copy over the first if it is, then continue the load.

    this approach would satisfy that but then this is limiting the size to half of the available memory.

  3. Posted

    Not sure what you are trying here, 'ins' includes the binary in the resulting object and so you are copying both into the result binary but without wrapping them with any labels to later relocate them?

     

    Going back to a hack of an existing binary, the result is having the two files. But that can be seen as 'being lazy' and can be taken a stage further and a diff of the files produces a delta which can be translated into a form (e.g. table of addresses and values) that can be turned into a small binary that runs through the table and applies the values. That is then injected back into the original binary instead of the 'run' block. Voila, you have a single binary that caters for both platforms.

     

  5. Posted

    @tane, that would be overkill as 99% of the code and data is going to be the same 

     

    To the most part I've found the simple PAL register check to be fine but would agree that the scanline check is better due to machines that can handle switchable customer chips and clocks.

     

    Where needed you can set variables appropriately, e.g. for the Doom-Fire demo I used this: (DETECT = $D014)

      

        .proc SetColours
    LDA DETECT ; reads PAL/NTSC
    AND #2
    BEQ @+
    LDA #$10
@:  STA c0
    CLC
    LDA #0
    STA PCOLR0
    LDA #$30
    ADC c0
    STA PCOLR1
    LDA #$32
    ADC c0
    STA PCOLR2
    LDA #$22
    ADC c0
    STA PCOLR3
    LDA #$24
    ADC c0
    STA COLOR0
    LDA #$26
    ADC c0
    STA COLOR1
    LDA #$28
    ADC c0
    STA COLOR2
    LDA #$EA
    ADC c0
    STA COLOR3
    LDA #$EC
    ADC c0
    STA COLOR4
    ;
    LDA #$80
    STA GPRIOR
    RTS
    .endp

     

    For music though this is more tricky, so for a more professional production both a NTSC and a PAL version could be built to same address.

    For example, in a MADS built xex you could then use a 'ini' section to load the second to another address, decide if it is needed, copy over the first if it is, then continue the load.

    • Like 1

  8. Posted

    1 hour ago, Philsan said:

    Wrathchild SLB_XEX-load_AtariMax.car: 2.4 seconds

    This wouldn't be for loading via a multicart as it is an image for loading to an physical AtariMax cart.

     

    The Homesoft XEX / Wilheim CAR difference seen would be because both need to be loaded from SD card into the cart's own memory and then the CAR is switched to which then simply copied 3 and a bit 8K blocks to RAM and then runs it.

    With the XEX, a small loader is placed in RAM which then, in assistance with the multicart's firmware, typically transfers the XEX to its load address(es) 80 bytes at a time and so this would explain the 0.2s overhead.

     

    The "Wrathchild Star League Baseball (low load).xex" I'd think should load in somewhere between the 1.8 and 2.0 seconds, so at a guess 1.9s due to not having to relocate the game code/data. I think the UNOCart loader is @ $700 so anticipate this wouldn't work with that either :( 

  9. Posted · Edited by Wrathchild
    Added SW/XEGS cart

    As GatHG loads at $900 and SLB at $500 is presume the AVGCart bootstrap is running in that area and hence being trashed.

     

    With the GatHG this seems to be an XL thing (maybe timing of screen flip) as OK on 800 settings so I'll do some checks to see where it needs XL patching as the XEX itself runs OK.

     

    [Edit] Indeed, the game is zero for the PMBASE and so the missle area at $300 is being cleared and hence the TRIG3/GINTLK check thinks the cart has been pulled and so goes into the infinite loop.
    [Edit2] Can be resolved by using the Switchable model and disabling the cart once the data is transferred.

     

    Galahad and the Holy Grail SW-XEGS.rom Galahad and the Holy Grail SW-XEGS.car

  11. Posted · Edited by Wrathchild

    The CAR over XEX loading time was only quicker because the latter was designed to be loaded from DOS and so loads as one block from $2500 to $8B7F and hence loses time relocating this down to $0500 and as a by-product has now made the title no-longer run on a 32K machine. But if the XEX is hacked to load direct to $500 then this works pretty instantly from any multicart because they are not using DOS but a custom XEX loader.

    SLB_XEX-load_AtariMax.car Star League Baseball (low load).xex

    • Like 3
    • Thanks 1

  12. Posted

    <grumpy hat on>

     

    As with the labels added from February to the other thread, I have to say I'm not impressed with the arbitrary text being placed at the bottom of labels and a better convention should be agreed and used by all.

     

    1) State the publisher correctly. Taking the above example, its just misleading - historically what did Atari Crop. have to do with that release. According to AtariMania, this title is from Gamestar in 1983.

    2) 'All rights reserved' - really? based on the time elapsed and possible change of ownership of these, can this be verified. (Best left of in my mind)

    3) 'PROTOTYPE' / 'REPRO' - they are mostly neither of these. It could be a repro of a prototype (Blaster / Commando) or just a repro (Atari U.S.A's Ballblazer) but most of these are released/complete tape/disk titles converted to run from cartridge?

    4) Stamping with an arbitrary 'RXnnnn' or 'CA' number - I can't see what purpose this serves? Who's maintaining them?

    5) Random 'Printed in' locations - 'USA', 'U.S.A', 'UK', 'Taiwan', 'Hong Kong' - how's that determined? (Again, best left of in my mind)

     

    Whilst I appreciate the idea of trying to match the format of the day, I'm seeing little effort going into reflecting the title on the cartridge.

    So something like Nir's early labels would seem to suffice, e.g. 'Green Beret' - 'Copyright 1987 Imagine Software Limited' with maybe a second line of 'Cartridge conversion by Nir Dary 19xx'?

     

    My other concern is now a new (readily available?) case is available and people have PCBs are we going to see a glut of these labelled versions available for sale? Bearing in mind the availability of multi-carts, titles like this are can be easily setup from an xex or atr and even made to autoboot to satisfy any need for an 'instant boot', so the 'benefit' of a standalone XEGS version seems beyond me but I accept each to their own and if they are made (freely available / for sale) customers will be there.

     

    Has anyone else picked up on this?

     

    </grumpy hat on>

  14. Posted

    This title would still run in the 16KB of RAM the 5200 has and Jon was at an advantage as he was using his own sources used for the A8 version as his base.

     

    Other conversions are really done on a case-by-case basis as the RAM usage of the title needs to be determined to know that it will fit and then code has to be reworked accordingly.

    This is a similar question to the one on this thread and so can discussion be kept there and this thread for Berks 4?  

    • Thanks 1

  23. Posted · Edited by Wrathchild

    Surely it would need to be well under that of an AVGCart as that seems to provide more features?

     

    [Edit] that's not to say it is redundant as of course they can be used for commercial production runs etc.

  25. Posted

    51 minutes ago, eugenetswong said:

    Unfortunately, the artifacting doesn't seem to show up on my laptop. Maybe the laptop's screen doesn't artifact?

     

    If you are emulating in Altirra then set this on here:

     

    image.thumb.png.57f8b95b1e4dd6d2ccc7fee1fa9becb9.png

     

    51 minutes ago, eugenetswong said:

    It's too bad that the 1 luma does the back ground, while the other does the foreground. It would have been nice to get a bit more out of Atari, before resorting to PM graphics, DLs, and DL IRQs.

     

    Don't we know it! But it depends what you were used to before on other micros. C'est la vie.

     

    52 minutes ago, eugenetswong said:

    I appreciate knowing all of this, though. I feel like I can finally move forward.

     

    Wait until you see Graphics 1 & 2, inverse is not inverse :)

     

    Try this (caps lock to toggle case and 'End' key to toggle inverse):

     

    image.thumb.png.a1aad99fe085e3156d2b8b6843a08a9b.png

     

    and you get:

     

    image.png.36385271a0503a5a002f2367213802c4.png

     

    So that's colours 0, 1, 2 & 3, e.g. "SETCOLOR 0,0,14" will turn the orange white.

     

AtariAge
Forums
Store
General
Follow AtariAge

Copyright ©1998-2021 AtariAge

×
×
  • Create New...