No particular reason, except perhaps the register names were set in stone by original documentation, but names for the bit fields were not necessarily so. Improvements/updates welcome. It's a good idea that would make code more readable.

The version of vcs.h that comes with DASM has constants representing various memory locations in the Atari 2600. I noticed that it doesn't have constants representing the values that you can store in those locations. For instance, vcs.h defines what CTRLPF is, but doesn't have a constant with a value of 1 for setting the playfield to reflected. I found an old version of a vcs.h by Nick Bensema at https://web.archive.org/web/20110423060216/http://www.io.com/~nickb/atari/doc/vcs.h. This has constants in it, such as PF_Reflect for reflected playfield, P_ThreeClose for three copies of a sprite close together, and J0_Right for first joystick moved to the right. I'm curious as to why these, or something similar, hasn't been adopted in the files that come with DASM. Or if there are constants that are widely used, what are they?

Thanks for the suggestions! I ended up creating a batch file named "d2600.bat" and am having the command in the batch file include the various command line parameters that I want. dasm "%1.asm" -o"%1.bin" -f3 -I"C:\Program Files\Dasm\machines\atari2600" So if I type d2600 foo to compile foo.asm I'll get an output of foo.bin in the proper format and using the include files packaged with DASM.

I don't think so. Reading thru the documentation I see 2 ways to add a directory to the search path for INCLUDE and INCBIN. In your source code: INCDIR directory Or as a parameter passed to DASM from command line: -Idirectory The documentation can be downloaded from this page, the second link in the section titled Code & Documentation. That said, there may be a way to do the same thing by creating an alias for dasm that includes -Idirectory. As an example on my Mac the ls command will list a directory without colorizing it. By creating an alias of ls that passes the -G parameter then issuing the command ls will result in ls -G being run as can be seen by the colorized output. The initial results of ls and ls VirtualBox\ VMs/ are monochrome. After defining the alias the directory names are now blue. Looks like doskey is the Windows equivalent of alias in Linux and macOS. On Mac I'd add the alias commands to a configuration file so they'd automatically be defined - How to Add an Alias in macOS with Terminal. Can do the same thing in Linux or Windows, though you'll need to track down instructions for those.

Does DASM have any support for environment variables? For instance, it would be nice to create an INCLUDE_PATH environment variable to point to where vcs.h resides, rather than having to put it in the same directory as the source or use the INCDIR directive, which might point to a different directory depending on the installation.

I reviewed/approved/merged a small one yesterday.

BTW: Who is checking the DASM pull requests at github?

This! I think M$ tried to do something like this. But in their usual, convoluted and totally proprietary way. To me the IX community always feels snobbish ("If you are no VI expert and no fan of command line, you do not deserve IX."). Which maybe partially explains why Windows is that successful.

Thanks, that's really useful information. I did not install that shell, because I avoid the UNIX world. But given the problems I faced, it most likely would have been the better option.

I'm not a regular Windows user either, but I have a Windows VM for testing. I usually use Cygwin when I'm on Windows,but that's because I actually want the pseudo UNIX environment. 🙂 Anyway, I downloaded MinGW and installed the dev tools, and used it to compile the latest DASM source from Git. I suspect that the issue @Thomas Jentzsch is having is because it wasn't run through the MSYS shell. On my system, the installer only created an icon for the setup utility itself, and not for MSYS. Here were my steps to compile DASM via MinGW on Windows 64-bit: 1) Launch the MSYS shell, located e.g. in c:\mingw\msys\1.0 2) Navigate to your DASM source directory using forward-slashes instead of back-slashes, and leading with the drive letter as if if were a directory. E.g. on my system I put: cd /c/Users/kgarr/Downloads/dasm-master 3) Set CC=gcc if that is not already part of your user environment (the new shell will inherit your existing environment): export CC=gcc 4) Type "make" from the root source directory to do the compile. Note that I didn't need to change my PATH or rename the make utility. That was handled by the MSYS shell.

For compiling DASM, I loaded it into Jetbrain's CLion IDE, added the files to the CMake (default build system) project file, and built it that way. I've never really understood why nobody's ever taken the time to create an "automatic + easy to use" build system for C/C++.

How to write software in 2023: Make it work on any target platform without quirks.

Complete instructions on how to configure machine properly. 1) buy a MacBook or Ubuntu machine 2) transfer files from Windows to your new machine 3) discard Windows machine

Then we need instructions how to configure it properly.

I get your point. On the other hand on ANY machine with a properly configured make.... you simply type make from the root directory. Any problems you are having are, IMHO, your machine is not properly configured.

Yes, making it compile "somehow" was the only thing I tried to achieve. And that works now. 👍 I still think there should be some details given how to compile DASM. Not everyone is an expert in C compilers originating from the ux world. Especially when being used to Visual Studio and Windows. And for the former the learning curve seems to be steep with a lot of bumps. At least that is my (repeated) experience.

For reference, as I don't know how much you know about makefiles, but basically you type make followed by a "target". The default target is "all" When I say "make clean", I am saying make the target named "clean" When make runs, it looks for your target in the Makefile. The default is a line starting with "all:" The make clean command will look for a line starting with "clean:" And after the colon on each of those targets in the makefile is a list of dependencies (optional). Those dependencies can ALSO be other targets. So if we had a line line like this... all : clean That would mean that every time you typed make, it would first try to process the all target, and to process that it would see there's a dependency on clean, so it would process the clean. After the target line (with the : ) the following lines (indented) are what to DO to make that target so when we put the echo in, we put it after the dasm: target, and that meant that every time the dasm: target was "processed" we got an echo output of the path. On that dasm target we see... dasm: $(OBS) What that's doing is exactly the same as described before. The target is dasm, and it depends on $(OBJS) What is $(OBJS)? It's the .o files listed earlier in the makefile... OBJS= main.o ops.o globals.o exp.o symbols.o \ mne6303.o mne6502.o mne65c02.o mne68705.o mne6811.o mnef8.o mne68908.o So $(OBJS) is just a macro subsitution with the contents of the OBS variable it would be exactly the same to have the target say... dasm: main.o ops.o globals.o exp.o ...etc So when building target dasm, it first says "hey, I have to build main.o" So how does it do that? Well, in this case it looks to see if the main.o file exists... and if it doesn't, then it executes the following indented lines of code. So they are... $(CC) $(CFLAGS) $(OBJS) -o dasm $(LDFLAGS) Basically that's doing a build of the dasm file (and as a byproduct the .o files) Next dependency will already have been made (that is, ops.o exists) so it ends there. The $(CC) $(CFLAGS) $(OBJS) are replaced with the earlier definitions of these things. There's a whole bunch of extra stuff you can have - like 'rules' which tell make how to create different sorts of files. It's powerful. But the above is the essence. In short, you make a "target". The target is listed in the makefile with all the dependencies it has. All of those dependencies are built/met before the target itself is built. Each of those dependencies may have other dependencies. You can for example have a .asm file dependent on a .h file. So anytime the timestamp on the .h file is newer, the .asm file is automatically assembled. Set up right, you touch any of your source code and all (but only) the required dependent files are assembled. You split your code into many many source files (if you want) and only build/assemble those ones that absolutely need to be built. And it's all worked out automatically from the rules in the Makefile. And yes, you can automatically scan source code and generate these dependencies for make to use. Anyway, back to your problem. Still am sure it's a path error but not having my skills on Windows suitable or a machine to even try to test on... can't do much more to assist sorry. At least you have a build going, from src.

I did put make.exe in the root and the src directory and tried to run make from root. Same old error. Even after doing a "set cc= gcc" before. BTW: make clean doesn't work in both dirs.

We put the path output on the part where it builds each of the multiple source files. So we see many paths output. That's ok. Just wanted to put it somewhere where it was likely to be printed. BTW. to force a rebuild at any time, you type 'make clean'

OK, well we are making progress. Definitely a path issue, but this way of diagnosing it isn't going to help. Basically if you put make.exe in source directory, then do the same experiment as I asked before.... this time I think it will find make.exe and run the second test. If the way windows works is to look in current dir first. I dunno. Give that a test, see if we get two paths. if we do, are they different. If they are - guess confirmed.

That (echo $(PATH)) works from src, but from the root it doesn't get that far. BTW: The path is output twice!

try echo $(PATH) or echo %PATH%

That doesn't echo the PATH variable, just %%PATH%% and %PATH%.

Have had a closer look, sorry. OK, in src/Makefile ... dasm: $(OBJS) echo %%PATH%% $(CC) $(CFLAGS) $(OBJS) -o dasm $(LDFLAGS) add the one line in the middle - the echo -- about line 72 This should now print the path when you do a make. Two tests. 1) make from root directory. It will fail but print the path too 2) make from src directory. It will succeed and also print the path. Are the paths different? If so, look at the path in 1) and tell me how it is finding the location of cc.exe using that path.

I inserted echo "Thomas" at line 30 of the src/Makefile and then tried make from the root. The echo doesn't show. Or did you mean the root Makefile (after all: build echo "Build complete, use 'make test' to run tests.")? There is no output too.