Wrathchild

Quick example seems ok: ca65 test.s ar65 r test.lib test.o cl65 -Oi -t atari main.c test.lib test.zip

no Harry... Usage: ar65 <operation ...> lib file|module ... Operations are some of: r Add modules d Delete modules t List library table v Increase verbosity (put before other operation) x Extract modules V Print the archiver version

What's in the .s file (who's .o file get put in your .lib)? How are the exports defined?

Each cartridge model sits in its own loop, so your particular model's code would have to detect and act on the button press. An interrupt on the pin could be employed but could quite easily throw other things out (e.g. if accidentally pressed) i.e. would need code to be running outside of the cart window

I don't understand, what has that got to do with Pico, which would use an image of the cart's binary data... not the original? Or do you want to do away with the PicoCart firmware/menu and have it run your image?

So the model for the cartridge doesn't have control of the RD4/5 lines itself and so could then disabled then via a software command. If not there are a couple of options I see: 1) move them to a cart model that permits s/w disable of the cart banking and patch the "turn off cartridge" s/w to do that instead of displaying. 2) assuming there are already versions of that s/w in other formats... use them.

This is why I'd always advise not use peek/poke macros in C code 😄

Something like these? MyPicoDOS Disks1-4.zip

There may well be some issues with the 5200 port as never released to testers, and from what I've seen with the interrupt nesting (VBI in an overunning VBI) could lead to stack problems. If anyone can grab/screenshot emulator cpu history traces then that could help me pinpoint things.

PM'd

I'd made my own IDA Pro disassembly from the xex supplied in 2014. In 2017 I'd received the sources but the compiled binary from that is identical.

Following up on this thread: I had made a 5200 port of this title back in May 2017 but obviously sat on it until permission to share given. Having revisited this, there is an issue where the key-presses are not responded to due to a nesting of vertical-blank interrupts blocking the key interrupt. However this doesn't really detract as you can launch a single player game using the fire-button. Enjoy, Mark psyclotron_5200.car psyclotron_5200.rom

Don't forget to check out all the New Year Disc compilations to date

In addition to the public post, around May 2017 I'd completed a 5200 port of this and a stepping stone to that was to make a version that would run in 16K RAM from cartridge on the A8 series. psyclotron_a8_16k.car

By 'stock' do you mean 16K? Probably none, many of the XE carts seem to be done as 'dump stuff to RAM as needed' rather than employ a bank switching mechanism. So the titles require the RAM they needed when loaded from cassette/disk.

A few variants: http://www.atarimania.com/game-atari-400-800-xl-xe-dodge_20032.html http://www.atarimania.com/game-atari-400-800-xl-xe-dodge-racer_1655.html http://www.atarimania.com/game-atari-400-800-xl-xe-head-on_19080.html http://www.atarimania.com/game-atari-400-800-xl-xe-race-trap_18660.html

You'd be much better off cross-assembling it with MADS/ca65 etc. Check out tools like dis6502

You are able to access a device directly but its probably better to use the image. I'm guessing access depends on whether the partitioning details on the card are readable by the s/w used. E.g. attach a SIDE cart with the CF image mounted, or any MyIDE device and the associated soft/hard OS.

By DOS I think the OP means Atari DOS

I use something like this for reading a CF card https://amzn.eu/d/85RXZgP For copying I've used HDD Raw Copy Tool

If you have an android device then that can be used as a bluetooth host using the AspeQt software in the same room, had worked fine for me.

I've found that to be impacted if travelling through walls/ceiling/floor too.

RMT uses DLLs to provide the 6502 and Pokey implementation and they, for example, use the code from Atari800 or Altirra and so worrying about Pokey support isn't overly a concern. One would hope the tracker involved is doing something similar.

Not mentioned yet (I think), but @phaeron also has the Altirra Extended Basic which, if you have the smaller AtariMax cart (or can emulate it, e.g. UNO/AVG etc), is very good too.

I think once you start thinking in asm and can visualise the equivalent construct of BASIC keywords then you fell off using BASIC, except for prototyping