Wrathchild

tbf, memorize the 6502 hex code and mnemonics, then when staring a hex dump / file you've spot the the patterns such as A9 XX 8D YY XX and distinguish runs of instructions from data. like anything, practice, practice, practice. but there are many different coding styles you'll come across. you'll see lots of inline reserving of data bytes between functions but then you'll also see data defined separately in, say, contiguously across a specific page or more of memory.

Maybe uses something like the 'move' command given in this example: #NotAFanOfPeekPokeOutsideOfBasic (but I get it)

To expand upon this, it makes sense to explain that if you intend to make use of DOS functions then do not utilise that memory area either along with ZP, page 3 locations used by the DOS/OS in relation to I/O. It is OK to use DOS to load and run from $2000 (and above) but then discard and overwrite lower memory so long as you don't intend to return cleanly.

In the latest help file is: /distance=Color distance function Default: yuv, other options: euclid, ciede However I can still use cie94?

Can you clarify here if you mean SIO2PC-USB cable version as SIO2USB is a specific device permitting a USB pen/flash drive to be plugged into the unit and files selected from it and read over SIO.

DOS friendly version With downloads, Chrome is blocking but seems to simply leave the file in the download folder as something like "Unconfirmed 198598.crdownload" and so you rename that back to the download name then it is fine. Or use a browser such as "Brave" alongside and copy the download link across to that. mazeam_exomizer.xex

Spy Hunter (2nd player uses 2nd joysticks fire?)

Does it fail if loaded from, say, an SIO2SD device rather than the A8PicoCart? The Pico would be responsible for loading the game but once control is passed to it, the Pico isn't involved. The game itself is doing some fun stuff with the scroll registers via the Display List interrupts: - NMI interrupt (DLI) 7016: 69: 99 | A=05 X=F4 Y=FF ( I ) | 41A2: 8D 04 D4 STA HSCROL - NMI interrupt (DLI) 7016: 79:100 | A=0A X=F4 Y=FF ( I ) | 41A2: 8D 04 D4 STA HSCROL - NMI interrupt (DLI) 7016:104: 99 | A=0F X=F4 Y=FF ( I ) | 41A2: 8D 04 D4 STA HSCROL - NMI interrupt (DLI) 7016:114: 99 | A=05 X=F4 Y=FF ( I C) | 41A2: 8D 04 D4 STA HSCROL - NMI interrupt (DLI) 7016:124:100 | A=0A X=F4 Y=FF ( I ) | 41A2: 8D 04 D4 STA HSCROL - NMI interrupt (DLI) 7016:149: 99 | A=0F X=F4 Y=FF ( I ) | 41A2: 8D 04 D4 STA HSCROL - NMI interrupt (DLI) 7016:159: 99 | A=05 X=F4 Y=FF ( I C) | 41A2: 8D 04 D4 STA HSCROL - NMI interrupt (DLI) 7016:169:100 | A=0A X=F4 Y=FF ( I ) | 41A2: 8D 04 D4 STA HSCROL - NMI interrupt (DLI) 7016:194: 99 | A=0F X=F4 Y=FF ( I ) | 41A2: 8D 04 D4 STA HSCROL - NMI interrupt (DLI) 7016:204: 99 | A=05 X=F4 Y=FF ( I C) | 41A2: 8D 04 D4 STA HSCROL - NMI interrupt (DLI) 7016:214:100 | A=0A X=F4 Y=FF ( I ) | 41A2: 8D 04 D4 STA HSCROL - NMI interrupt (VBI) 7016:248: 81 | A=05 X=F4 Y=FF ( V I ) | 41CD: 8D 04 D4 STA HSCROL - NMI interrupt (DLI) 7017: 69:100 | A=0A X=F4 Y=FF ( I ) | 41A2: 8D 04 D4 STA HSCROL - NMI interrupt (DLI) 7017: 79:101 | A=0F X=F4 Y=FF ( I ) | 41A2: 8D 04 D4 STA HSCROL - NMI interrupt (DLI) 7017:104: 99 | A=05 X=F4 Y=FF ( I C) | 41A2: 8D 04 D4 STA HSCROL - NMI interrupt (DLI) 7017:114:100 | A=0A X=F4 Y=FF ( I ) | 41A2: 8D 04 D4 STA HSCROL - NMI interrupt (DLI) 7017:124:101 | A=0F X=F4 Y=FF ( I ) | 41A2: 8D 04 D4 STA HSCROL - NMI interrupt (DLI) 7017:149: 99 | A=05 X=F4 Y=FF ( I C) | 41A2: 8D 04 D4 STA HSCROL - NMI interrupt (DLI) 7017:159:100 | A=0A X=F4 Y=FF ( I ) | 41A2: 8D 04 D4 STA HSCROL - NMI interrupt (DLI) 7017:169:101 | A=0F X=F4 Y=FF ( I ) | 41A2: 8D 04 D4 STA HSCROL - NMI interrupt (DLI) 7017:194: 99 | A=05 X=F4 Y=FF ( I C) | 41A2: 8D 04 D4 STA HSCROL - NMI interrupt (DLI) 7017:204:100 | A=0A X=F4 Y=FF ( I ) | 41A2: 8D 04 D4 STA HSCROL - NMI interrupt (DLI) 7017:214:101 | A=0F X=F4 Y=FF ( I ) | 41A2: 8D 04 D4 STA HSCROL And the actual Display List is a little unconventional: 4068: x3 blank 8 406B: mode 2 @ 0780 406E: mode 2 406F: blank.i 1 4070: mode C @ 4CF5 4073: mode 4 @ 2004 4076: mode C @ 4D01 4079: mode C 407A: mode.h 4 @ 2020 407D: mode C @ 4D1C 4080: mode.i C 4081: mode.h 4 @ 2040 4084: mode C @ 4D37 4087: mode.i C 4088: mode.h 4 @ 2060 408B: mode C @ 4D51 408E: mode C 408F: blank 4 4090: mode C @ 4CF5 4093: mode 4 @ 2084 4096: mode C @ 4D01 4099: mode.i C 409A: mode.h 4 @ 20A0 409D: mode C @ 4D1C 40A0: mode.i C 40A1: mode.h 4 @ 20C0 40A4: mode C @ 4D37 40A7: mode.i C 40A8: mode.h 4 @ 20E0 40AB: mode C @ 4D51 40AE: mode C 40AF: blank 4 40B0: mode C @ 4CF5 40B3: mode 4 @ 2104 40B6: mode C @ 4D01 40B9: mode.i C 40BA: mode.h 4 @ 2120 40BD: mode C @ 4D1C 40C0: mode.i C 40C1: mode.h 4 @ 2140 40C4: mode C @ 4D37 40C7: mode.i C 40C8: mode.h 4 @ 2160 40CB: mode C @ 4D51 40CE: mode C 40CF: blank 4 40D0: mode C @ 4CF5 40D3: mode 4 @ 2184 40D6: mode C @ 4D01 40D9: mode.i C 40DA: mode.h 4 @ 21A0 40DD: mode C @ 4D1C 40E0: mode.i C 40E1: mode.h 4 @ 21C0 40E4: mode C @ 4D37 40E7: mode.i C 40E8: mode.h 4 @ 21E0 40EB: mode C @ 4D51 40EE: mode C 40EF: waitvbl 4068 So I would think timing is pretty critical here and potentially there is a slight glitch when the game starts before the correct display is rendered. This can be seen in Altirra by setting a breakpoint at the launch address (3FD3) and then using 'gv' to step a frame at a time. I see this, or variants of, or sometimes no problem (due to using Altirra's "Randomize program load timing" setting): These generally pass quickly and the user barely notices them, however I was looking at the launching of the Kangeroo prototype recently on Incognito and experienced different results in different profiles, so wonder if something locks up instead. I don't know (or think he doesn't) if @phaeron has an 800 with Incognito or any idea what might be happening here? Or if anyone else with one is able to better diagnose things, e.g. with a scope.

Chimera had a nice clam shell too

Can you attach a single example of a failing xex?

Don't rule out using an 8K ROM, any self-modifying code and DATA / SCREEN RAM can be located in low memory but most code will happily run from ROM. The vast majority of users these days will have a device that can run a ROM image

This is also true of XEX loaders used in most cart devices, SIDE Loader etc. These tend to load the XEX loader bootstrap to $700 and so writing over that area during the loading is going to crash things.

Have a go with running it through exomizer to produce a single part loader @ $2000 which is fine for most DOS's. e.g. exomizer sfx $600 -n -t 168 -Di_table_addr=$500 -Di_load_addr=$2000 -o mazeam_exomizer.xex mazezam.xex mazeam_exomizer.xex

Harry, I think the OP has moved the discussion on a bit from memory considerations to specifics about scroll memory management

plus the available test is a quick OR of the lo/hi bytes being zero

Rather than the tag being a yes/no, could be a count that is inc'd / dec'd but then the problem simply becomes "you can't have it appearing more than 255 times" 😄 (but seeing at there are only 128 characters you you put hi/lo counter bytes into a single page)

Syntax isn't that far away from MADS so was easy to manipulate. I built using: mads -l:sr.lst -o:StarRaiders.rom StarRaiders.asm StarRaiders_MADS.zip

There were a couple @CharlieChaplin mentioned (a "Q-Bert" and "Satarn Saturn") here that weren't addressed?

I've re-packed this with exomizer, give this one a go. I think the issue with existing binaries is that there is a short period where the dlist is 'random' and so crashing could depend on timings as to whether or it muscles through. Kangeroo-exomizer.xex

take a look at this post

from https://atarionline.pl/v01/index.php?ct=katalog&sub=K&tg=Kangaroo#Kangaroo Kangaroo (1983)(Atari)(US)(proto)[a].xex

For me, really depends on what you're familiar with and prefer to code. That being equal you're then looking at the type of game you're coding, e.g. slow moving turn based RPG, fast moving S'em'UP, both can mix asm code and so interfacing with such fairly straightforward. CC65 suite is a lot older and multi-platform from early 2000's so I haven't kept up on developments but would think it not needing a high turnover of changes and updates not posted here, whereas MP has been and continues evolve and the developer resident here. I feel due to its MADS connection there is more focused A8 h/w support (e.g. VBXE) than with CC65 but even then VBXE is not so much of an Out-of-the-Box target unless using console drivers.

I'm on the fence with this having done a proof-of-concept type with a 3D engine which is handled in C on the Arm STM32 chip. There is certainly still some juggling to be had targeting (or even supplying) the display list and the screen data from the micro's memory. However to the extent the (possibly stock) Atari becomes a dumb-terminal passing on the joystick / keyboard input and taking the video / sound output is the question. But if it brings us fun from a) coding such a thing and b) yourself and others playing it - then I'm all for it.

Superman III

From the instructions: