Wrathchild

assuming you've navigated to folder where your source is in (*) and its in, say, a single C file, then use: cl65 -t atari -O -o <filename>.xex <filename>.c The '-t' tell us the system we are targeting, '-O' is optional but good to have, it tells the toolset to use the optimzer. We can specify the output filename with '-o', useful to have the xex extension so it can be opened in Altirra by association. Finally the files to build from are listed, so in this case just "<filename>.c" (*) A useful tip for windows command boxes is to type "CD" then a space and if you have your source folder opened in an explorer window, you can drag-drop the folder into the command box and it will paste the path onto the command line. Hit 'Enter/Return' to effect the change of directory. Note, if your source is on a different drive you'll need to change to that before/after the CD. Do that by, for example, typing "D:" and return.

Take a look at Yaron's tutorials he has posted here and here, that should be enough to get you started

Philsan's Cookie Monster maybe? [Edit] sorry, that was for the VCS controller, not the keyboard

All I see here is an attempt to rephrase what I have said as your own when at the same time employ some one-upmanship to assert your knowledge but in the process have ended up spreading more mis-information. You really need to resist the temptation to keep on doing that. When we talk here about a 'kernel' it refers to a 'display kernel' (as opposed to an OS kernel). Yes, for a 2600 its architecture is such that the code is locked into servicing the full screen and so game state is then handled in the non-drawing/v-blank area. For an A8, a (display) 'kernel' merely refers to code dedicated to affecting the display about to be rendered further on in the current frame, so like Heaven states, a 'snippet' suffices here. It's not "to do things at 1 frame every time" - blimey, a VBI satisfies that definition!

That should read "has the disadvantage of not knowing where you are"

If the processor is executing instructions in a DLI or not, then it's affected by Antic DMA. The HALT by Antic from a WSYNC stops the processor but the DMA will steal cycles, not stop reading/writing from/to RAM, just delay. By not using DLIs, this saves on the overhead of stack push/pulls but has advantage of knowing where you are. A kernel type approach seems therefore better and actually you could use them within a fewer number of DLIs to keep better control of where you are and in the case where your code ends earlier. But then you'd have to examine what the mainline code is doing in this case... mostly you'd be waiting for the 'out of display' areas to update gamestate / prepare the next frames graphics etc. But I'd say this is only necessary where you aiming for a 50/60Hz framerate. If halving that then these considerations (mostly) go out of the window and your mainline code deals with things.

If I come cross something like this I typically find it OK to pump it through a compression tool, e.g. exomizer, and get it to produce a self-extracting binary with a higher load base.

If you think after 40 years us coders are going to have our noses put out by someone ignoring our advice I'd have to laugh, don't sweat the small stuff

Yes, but please credit those developers on this thread that they possess the intelligence to know that, and though it might be demonstrated "I can get X s/w sprites working with this", they understand that's not going to be final figure. I, for one, have been very impressed with rensoup's approach at coming to a new platform as he demonstrates the 'savvy' to comprehend and re-purpose the advice being offered.

That point is redundant as it is no different from saying that the proof-of-concepts (*) supplied in this thread might not be used 'as-is' but drawn upon in any final works and so hence are equally 'upgrade-able' ideas. (*) i.e. they are not an unfinished (or able) demo nor intended to be a game.

Here seems a prime example of why people tend not to associate you with any credibility with regard to this topic. Sprites in that video seem designed to not overlap and with no background graphics do not have to worry about masking.

That's the long and short of it Background to this can be read from here

Hi Peter, So long as the debugger is open, when you load afresh the .lst/.lab get imported too. Mark

Atarionline.pl collates releases: 2010 2011 2012 2013 2014 2015 2016 2017 2018 - not there? 2019 Many nuggets in there!

MADS team will be better place to guide as most things I try tend to be a fudge as I'm more familiar doing carts with CC65. The issue arise from wanting to compile multiple blocks to the same area, but MADS will error for different reasons depending on which way you try to get around it. An example would be an XEGS cart where there is a fixed 8K bank at $A000 and a selectable 8K bank at $8000. Maybe take a look at how phaeron approaches it in the Altirra Extended Basic sources on this thread. If your dependencies are such, you can build a section and export it's labels & addresses mads my_data.asm -l:my_data.lst -o:my_data.bin -c -hm:my_data.inc You can then include just the 'inc' file with the next section's sources to resolve those labels and do this across a number of individual blocks. Then the final source then brings this all together in one binary: mads -l:final.lst -final.lbl -o:final.rom my_rom.asm e.g. with my_rom.asm being along the lines of: OPT h - OPT f + ORG 0 ins "my_data.bin" ORG $2000 ins "my_code_1.bin" ORG $4000 ins "my_code_2.bin" ORG $6000 ins "my_music.bin" remembering that the final block will contain your Cart Vectors, e.g. ORG $BFF9 CartInit: RTS .WORD CartRun .BYTE 0 ; .BYTE 4 ; .WORD CartInit

MADS tend to take care of that for you as it tends to force you to work in continually ascending order. This can become a bit of a pain when you are using multiple banks and want to include blocks that you want relocate to RAM. A way around that though is to compile those first to individual binary files and then 'ins' those in a final source that builds the rom file.

I had asked on Tuesday evening about this "I'm assuming this is using a tool such as HDDRawCopy (i.e. raw copy to sectors not file copied to FAT?)" and was told "have tried different utils win32 disk manager and HxD" so should have twigged you were actually doing this wrong 🙂 For volume, when converting the original video to the A8 avi there are some audio options you can add in to boost the volume (Audio/Volume... menu) but do that with care not to distort. You may also be able to edit the outputted RAW audio file within Audacity and process it within that.

But that is handled within the mux program! fseek(fo, 16*512, SEEK_SET);

This all seems strange, I've never had to pad a resulting image file?

2 titles I converted to work from a 16K cart in 16K of RAM RainbowWalker.rom JetBootJack.rom

OK, looks like it is to the bottom right of the other port

where is the cut made on 800 board, can you highlight that on the picture with the wire?

Just checked some listings and looks like you'd use the address, not that you would like to align to the next page, e.g. opt h - NO_QUOTE = 1 org $4000 icl 'charset40.s' icl 'mem4400.s' icl 'GameOver.s' .align $5000,0 icl 'charset50.s' icl 'logos.s' A alternative way to align to a page: :(((*+$FF)&$FF00)-*) dta 0

On the A8 most people would be going for an SIO2SD or SIO2PC (serial or USB) type device and so can play larger sized disk (ATR) images meaning an 'all-in-one' Z file can be used rather than splitting this across disks. Also most of the newer cartridges that support mounting ATR images from an SD or CF card. On all of these sector access times are good and so would make playing a game acceptable.

That's one of the cool things about the Atari binary loader format as there is scope for injecting code to patch original code/data before it gets run or used (as an alternative to modifying it directly)