Is it worth of an effort? I think yes. Let's try.

As found, WDC tools will at least run under linux with wine.

Installing wine is easy by using your distro's package manager.

Then, get the WDC Tools file downloaded from the WDC site and decompress it to a folder. Go terminal, change directory to that folder and type wine WDCTOOLS.exe. It will open an installation window. Follow the process by clicking on next to the end. It will exit the installation.

Now you have to append the paths to your linux system paths. Wine will get the paths from the linux environment variables. You would have to append manually this...



...to the path variable setting in your profile file. (note the double back slashes)

After having the variable set, you could open a terminal, and run directly wine wdcdb.exe.

It will ask for creating a WDCDB.INI file if not found in the folder your are running wdcdb.exe from. Place a mark in the Simulator enabled option in the first setup window and you will have the debugger running. This will work as a test of the tools running.

Or you can run wine WDC816CC.exe for the same test.

TESTING:

The process to obtain binaries seems to be this one (taken from the Easy6502F/SLD documents)



Well. I did this (timed all the commands for your reference):



The output files are attached for you experts please study them (please remove the .txt extension).

You could also make a simple shell script.

Makefiles are tricky creatures that require a lot of maintenance. In the end you have to put the names of each file (and remember to add new ones as you create them) or have it guess, and either way it sucks. A script is deterministic; a make file is full of magic. I've spent many hours debugging problems and realizing that somehow some file did not compile, then trying to figure out why the makefile failed. There w̶a̶s̶ ̶o̶n̶e̶ ̶t̶i̶m̶e̶ were many times I had to touch every file to get make to work.

The only reason to use a Makefile is to avoid recompiling code that was not modified, based on the file timestamp. If your compiler is fast enough, just recompile everything. It mattered on the old VAX with a tape drive running at 100 kilohertz, but you have a machine running a few gigacycles/sec, gigs of RAM and terabytes of storage. If your compiler can't compile a 64k binary in the blink of an eye, throw it out.

So, make a file called 'build', and make it executable with 'chmod +x build'. Edit it, and type in:



Now just type 'build' to rebuild it. Add anything else you want done, like any utilities to convert the resultant binary or sending it to the target using xmodem. That's all.

Seems more appropriate to use a 'batch' file with winders, don't you think?

_________________
In theory, there is no difference between theory and practice. In practice, there is. ...Jan van de Snepscheut

Thanks for your answer. So aren't Makefiles the gentleman's way to compile?

Yes, a batch file should then be modified to get input variables to get the tools use them as the input files or sources.

As I've seen, a Makefile is a sort of a batch file itself.

I mean, there's not that much mystery to it.

The different tools deal with what are called "relocatable binaries". These contain the machine code that will ultimately run on your W65C02-based system, but references to specific memory locations are left as sort of blanks to be filled in later.

WDC02AS, the Assembler, takes an assembly file and outputs a relocatable binary.

WDC02CC, the Compiler, takes your C code and outputs a relocatable binary. It actually does this by generating assembly code and then handing it over to WDC02AS in the background, but it doesn't save the generated assembly to a file unless you ask it to.

WDCLN, the Linker, takes these relocatable binaries and stitches them together into a binary that'll actually execute, replacing the placeholder memory locations with real ones.

My batch file for building looks like this currently:


ASSETS.ASM is a file I created to import a precompiled zlib binary as well as a compressed file storing sprite graphics.

Usually a batch file should be enough to automate a handful compilation steps. I switch to a makefile when I have many different steps to a build process, such as scripts to convert images and MIDI files, a ROM flashing tool, or an emulator I want to run after the build.

No, make is an inference engine, much like prolog.

You specify dependencies (object files depend on source files and .h files used; binaries depend on object files, etc), and it checks to see which files changed, and rebuilds only the files dependent on them, then those dependent on the newly rebuilt files, etc. It works if you specify very carefully all the dependencies. But if you forget that you added a .h file in some .c file, then change that .h file, bam! It looks like it is compiling, but it is not. Then you spend hours figuring out that you are debugging the wrong code, and it is not changing, even if you put a printf into it!

It is a complex tool that requires a lot of discipline to use. In practice, you need to add dependencies into some other file if you use a makefile or a script anyway, and you are screwed if you don't. So save yourself the trouble and use a script - at least it's deterministic.

Unless your compiles are really slow. In which case, learn Forth - it is about as much effort as learning to use Make correctly.

_________________
In theory, there is no difference between theory and practice. In practice, there is. ...Jan van de Snepscheut

This is a nice thread, thanks!

For some versions of make, "make -B" will act as if everything is new.

It's possible that single forward slashes will work instead of all those double backslashes - might be worth a try.

We usually refer to the output of compilers as object files. When fed into the linker (which deals with relocation and resolving symbols among other things), an executable or binary file is produced.

_________________
In theory, there is no difference between theory and practice. In practice, there is. ...Jan van de Snepscheut

Now with the Makefile



Please when copy-paste'ing, replace <TAB> with an actual tabulation in your text editor.

I think I managed to get a Makefile to compile the PRIME example of the Easy6502F/PLD development tools by using WDC compiler under linux with wine.

But I need confirmation from the experts.

Why not try it yourself? Then consider: what would it take to regression test it for all likely changes? Compare with the 5 line script. Which is easier to maintain? Can you tell at a glance what each one will do at any random point in time? How much are you being paid to maintain a build environment suitable for hundreds of source files? Do your projects contain hundreds of source files?

If you find that you truly need to learn make, go for it, learn it, and I and others will help. As it looks like misguided curiosity or a misunderstanding of what so called professional tools are (so complicated that someone better be paying me to use them), I personally will not look at your makefile. No disrespect, my desire to help is genuine, as evidenced by me spending time to post here.

PS There are tons of tutorials, and it really has nothing to do with the 6502...

_________________
In theory, there is no difference between theory and practice. In practice, there is. ...Jan van de Snepscheut

Instead, I will show you a Makefile I use to automate assembly of simple test code with 64TASS with 'make'. The resultant binary (a.out) can be sent to Daryl's SBC4 over the serial port with 'make send'. Finally, I can run it with 'make run'.

Note that I use screen to establish a terminal session with the target and enter the monitor. 'make send' transfers the file using XModem. 'make run' uses the G command to execute from $500. Screen is extremely useful as it allows me to maintain an interactive terminal session with the target, while another terminal window can be used to run the makefile, which connects to the interactive screen session (called 'sbc' here), and inject files with xmodem and keystrokes with 'stuff'!

Screen is extremely useful, and I know about 5% of what it can do.

The Makefile is rather primitive, but quite useful, and shows how you can create targets to do things other than invoke the compiler. I hope this helps you.



Note that I don't give a rat's ass about make's dependency monitoring capabilities. It is a convenient way to keep multiple labeled scripts.

_________________
In theory, there is no difference between theory and practice. In practice, there is. ...Jan van de Snepscheut

Thanks. That's why I said earlier that a Makefile is a sort of batch script.

The fact that things like automake, autoconf and things like that exists is because there is a need for it. I'm sure that maybe its real use would be focused on big projects with hundreds of small source code files that would need to be precisely managed. But that's only how I think it is.

Anyway, all of this comes from the thread about the WDC02CC compiler that got invaded with a subject that came from the WDC myths thread: Drogon mentioned that he would take a look at WDC compiler if someone could make it work with linux and a Makefile and I took the challenge.

This Makefile simply replicates what the Easy6502F development examples do with its own .bat file in Windows. Of course that there could be a simple batch file that would get the same, and that could be prepared to be used in different projects.

My petition for experts to review the code that the Makefile spits out is just to be sure that it's producing something instead of garbage. I think I got the Makefile to work but that doesn't actually means that the file it produces is anything.

Again, not really. It is a dependency tracking system that, upon discovering a change to a dependent file, can invoke some processes. You can disable the dependency tracking by not specifying any, which implies that it will always execute stuff. You can label these. It is kind of a stupid way to use make, but what do I know. To quote a Star Trek character, "I am only an egg". Also, I like humiliating make like that.

Actually, these exist because creating and maintaining makefiles is a nightmare! These are attempts to automatically discover dependent files, because otherwise, you have to keep track of these yourself, and remember to add files to the makefile as you include them etc. And on the large scale, make is not good at configuring and discovering what libraries are available on the system, etc. Another way to say it, make is a disaster, and only became popular because compiling on a VAX took hours, so you really needed something to avoid recompiling unchanged files.


Well, it is not a myth. WDC compilers work only on windows, and not linux. You can run a windows 'mulator to try to run them, but that is adding insult to injury - why would anyone use tools that are specifically made to not work on your OS, without source code or a reasonable license? It would be easy enough to make a Posix version that would compile on both windows and linux.

In other words, it's like saying that you can run native arcade games or 6502 code on linux. You can't. You can run MAME or some other 'mulator, but it's not really the same thing as it adds another intermediary into the equation. When developing code, the last thing I want is to run into a Wine bug or configuration issue. No thanks.

Finally, if you can't tell if your makefile works or not, you probably should not use make, much less take on the challenge of creating a makefile for someone who is happily implementing languages and operating systems using tools they are comfortable with. I don't consider myself qualified to develop tools to tempt Drogon. Do you really think you are?

_________________
In theory, there is no difference between theory and practice. In practice, there is. ...Jan van de Snepscheut

I'm not qualified on anything!!!

The worst thing it would happen by trying is this not working, and the best is me actually learning something, that could be worthwile of the effort or not.

I can't tell if running a compiler designed for another OS under emulation on linux could introduce bugs in the generated code. Many development has been done under emulation since the dawn of computers programming, so some reliability should be taken for granted.

Experts would be welcome to answer questions like

• Is it really useful to use autoconf, automake, configure and make themselves to manage 65xx code?
• Are bugs introduced by using a compiler under emulation, beacuse the compiler is not running under its native environment?

And again, this all started just by the curiosity of test if WDC's compiler is actually that bad or just an unknown gem.

Fair enough. There is no reason not to use makefiles to run a windows-only compiler under wine in Linux, if you so desire. Sure, why not! Worthwhile? Only you can tell, by actually trying your makefile and not asking others to do it for you.

I can guarantee 100% that it could introduce bugs. Taking anything for granted, especially something as large as an emulation of a proprietary operating system is bound to bite you in the ass.

Yes, it is really useful to use tools that fit the job. If your makefile is so complicated that you can't take it anymore and you need a metalanguage in which you can specify your makefile, and have autoconf generate a makefile for you, it is the right tool. Whether the project contains 6502 code or not is irrelevant. And so on.

Yes, bugs are introduced under emulation. When running on real hardware, it is not uncommon to discover hardware issues. When developing in an emulator, it is likely that you will discover an emulator bug.


I would not say that it is bad, and it is hardly unknown to us. Some of us avoid using windows because it is bad in oh so many different ways. Others don't like using tools without source code or a decent license. Many of us just don't care about C compilers.

Finally, when a makefile fails, it will not create garbage. Most likely it will be a silent failure, and you will spend the rest of the day trying to figure out why something that worked before stopped working. You will then slap your forehead, because you had an extra space in your makefile - it looked fine but failed to compile some file.

Make is a program that lets your build process to selectively fail to compile certain files. When it works the way you wanted, by failing to compile files that didn't need to be compiled, you save milliseconds or seconds. When you accidentally fail to compile files, you are in for hours of trouble. It is a tool guaranteed to cause grief at some point in your life if you choose to use it. Choose wisely.

_________________
In theory, there is no difference between theory and practice. In practice, there is. ...Jan van de Snepscheut