JAC!

Hello Jon, the behavior depends on if the assembler itself considers labels as case-senstive or not. There are no settings or influencing factors. Kind regards, Peter. I assume you indicate a semantic with the lower-case start character. And I know it's not really what you want, but maybe prefixing the lower-case label with an additional "_" (similar to local labels with "."/"?") is a solution.

Hi @mariuszw and @Wrathchild. Is the version posted above the latest version ?

Since Curt's page is down, here's a link to the archive: https://web.archive.org/web/20160618222211/https://www.atarimuseum.com/whatsnew/2010-JAN-25.html

Bugfix version https://sourceforge.net/projects/dis6502/files/dis6502/3.6.1/ released No new features Fixed bugs: - Saving listings without includes now generates correct output (bug #32) - Block numbers in SDX blocks are now output in hexadecimal if that option is active in the profile This is a "by-product" of my 4.0 developments, where I try to track down the reported issue. I keep the 3.6 version in a state where I can compile and use it for reference. I also found and fixed a bug in version 4.0 that prevented the correct usage of the scroll bar in the disassembly window. Note: Microsoft Defender incorrectly complains about the version. I've submitted https://www.microsoft.com/en-us/wdsi/submission/feb36ac1-91b6-449d-888d-c6f912fb3447 for that.

Yes, i fixed a bug that only appeared under Linux, and the compiler accepted an invalid sequence. I've uploaded the build for the abovementioned commit. It should work again now.

.car is a general container format and can contain different types of cartridges. No hardware will emulate all of them (new ones are created as you read this). So it depends on the Backbit specs which will work and which won't. https://github.com/atari800/atari800/blob/master/DOC/cart.txt

The!Cart Studio and it menu system only works for The!Cart. The options for Atarimax are intended for the direct conversion of binary to ".CAR" files in Atarimax format. They are not helpful for you.

That is the font for the player which is part of the 1st segment. The song is the .rmt file.

I am here preparing one of the pending SillyPacks for SV 2k22 SE. There is a song that has some issues while loading because the display list area ($BC00-$BFFF) is overwritten, and that causes garbage while loading. Since the readme said it was done with a beta of RMT 1.34, I thought a re-expoert with the released version could fix that. But when I try to export as LZSS/XEX I get this error message: I'm not sure; maybe something's wrong with the RMT file, as it was done with a beta with 1.34. I've attached it for your reference. Maybe you can find out what's wrong here. ATARIADV.txtATARIADV.rmtATARIADV.xex I also tried to build the latest RMT from the sources, but here I cannot even load .rmt ...

The ABBUC now provides a TNFS server for its members. So I tried to get my Atari stuff uploaded so you can mount it directly to your Atari computer. I do not have a Fujinet myself yet, so I'd be interested if the access that my Website now specifies works. https://www.wudsn.com/index.php/productions-atari800/tools

Correct, WUDSN uses the absolutes paths configured in the preferences because the system path is a shell property and cannot be used directly without opening a shell window. But in the latest versions of WUDSN, the installer also includes the standard assemblers/compilers in a default folder structure for the IDE. If no explicit paths are configured, they are found and used automatically. For the emulators, you can also choose to use "Operating System Default Application" then, it'll use the default for the file extension as defined in the registry. That also means less configuration but limits the parameters passing to the emulator to the executable file path.

As opposed to my other 8-bit platforms, Atari OS and Atari DOS have pretty good definitions of what is a proper way to write the software, so it will be compatible with all the different hardware/software configurations that exist (and there are many more different configurations in A8 than on C64 for example). So, instead of chasing this or that particular case in real vs. emulator, writing the software in a way that it runs everywhere is more sustainable. No matter the device, DOS, or OS version. Only this way you reach the maximum number of users.

It's really a tough choice to pick one, but I've defined my favorite now.

Is there a special reason form removing the "( )" in the V2? I would not expect it to have an impact on the speed.

Hmmm, there are 57 ATRs in the ZIP, not 24 as the title suggests. Some of them are multi-disk releases ("Cut and Paste _ side B.atr") which are not even boot disks. The!Cart can only emulate cartridges and boot ATRs. But Mega Cart Studio supports disk wrapping by patching the OS and providing hotkeys. So you can create a "Mega Cart" ROM with that and add the result to The!Cart Studio. From the documentation: "Archon (1984)(Ariolasoft)(GB[cr CM1.61].atr" and many others crash while loading on XL/Atari 800 (Altirra, booted directly). Some others boot up to a certain point when you set the base address for the ATR emulation to another area, e.g. $500 but then the boot loader comes with status requests, etc. as a kind of copy protection and that cannot work with The!Cart. To sum it up: "closest to the original programs, the way they load." will only be the case when you load them on a disk drive. Alternative cracks or ROM versions have to be user for The!Cart here. I recommend Homesoft's site for that.