Wrathchild

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. 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

You can't do that as (presumably) they occupy the same address this approach would satisfy that but then this is limiting the size to half of the available memory.

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.

Can DLI x be used within another DLI to chain them? If so I think you'll need a similar VBI statement within which you'd use a DLI statement to reset the 1st interrupt routine?

@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.

But you can make an AtariMax workbook version that loads the 800 OS if an XL/XE is detected and so should resolve the issue Galahad and the Holy Grail (AtariMax).car

Sadly that doesn't seem to work either as during the 'explosion' as the player dies, the missile area sets a value at GINTLK and so the lockup occurs.

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

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

@Wilheim yes, a lot clearer. The hope is to spark some discussion of what realistically makes sense for producers to put on new labels Same principle (with xex for those wanting it on a multicart) Galahad and the Holy Grail XEGS.rom Galahad and the Holy Grail (1982)(APX)(US)[no intro - low load].xex

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

<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>

Steve/@Classics at AtariMax also sells 5200 carts

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?

Yes, the cassette version

I think you're referring to a modified version of the original?

Odd choice, AFAIK its one of the least available boards if you wanted to do a production run? Better to go with AtariMax or XEGS from the outset.

I'd recommend using the stdint.h for variable types, e.g. uint16_t etc to be clear on the bit sizes used.

Similar with XTEA

AtariMania: Shoot-em-up - Space Invaders Deluxe Invaders often gets good mentions

Here are some labels I threw together back then but seeing as the AtariMax dimensions are smaller than most, someone with better scans can easily make a better job.

And The Eidolon

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.

Aside from ensuring your RMT/SAP memory is not conflicting with the G2F picture's memory the thread on non-50/60Hz also highlights you would have to be very careful with having sound playback routines running into areas where DLIs occur.

If you are emulating in Altirra then set this on here: Don't we know it! But it depends what you were used to before on other micros. C'est la vie. Wait until you see Graphics 1 & 2, inverse is not inverse Try this (caps lock to toggle case and 'End' key to toggle inverse): and you get: So that's colours 0, 1, 2 & 3, e.g. "SETCOLOR 0,0,14" will turn the orange white.