Directly from WDC themselves, after a exchange of emails with them I've been allowed to share these with you:
Quote:
Note the csamp.zip was meant to run on an old dev board (no longer in production or supported as it worked through the parallel port) or the simulator.
I hope this to be useful to anyone willing to give WDC Tools a (re)try.
Yes there is this issue of Windows, emulation, Wine and whatever else. Only the real coding experts will be able to judge if what they get by using WDC Tools is worth of just ignoring those mentioned issues.
(*)Includes some custom startup.asm files for the C samples
Thanks for reaching out and for sharing the results.
It's good that WDC are happy to work with those forum members who are open to the possibility, and not put off by anything said by other forum members.
As ever, we should conduct ourselves here as if we were in public, and the targets of our criticisms were reading our posts, as well they might be.
It seems like this routine has been thought as one for code already present when thw CPU has been reset.
But if I wanted to code something to be loaded from dynamic storage (disk or flash drive) then I wouldn't need to copy anythimg from ROM to RAM... Would I?
I've been using WDC Tools for over 8 years now. Is it perfect? No... then again, what set of development tools are? I bought the WDC Tools back in 2013 when they dropped the price to $49... and you needed a license file to run them. In short, I'm still using it for all of my own 65C02 development. I'm also using it to assemble/link code that others have written, which implies I end up modifying the source to run with WDC Tools. Examples are: Symon-III, Enhanced Basic, Commodore 1581 Disk drive firmware, some tools from DOS/65 and probably a few others.
For simplicity (in a way), I have a licensed copy of Windows 7 Pro 64-bit (OEM license). It was installed as a virtual machine under VMware Fusion. I've upgraded and moved this VM multiple times over the years, as I've built new machines, updated to newer versions of OSX and Fusion, but have never had to rebuild the VM itself, just enlarged the disk partition once, as space was getting tight. The same VM is also used for running the Dataman 40Pro programmer, WinCUPL, Express PCB and some other Windows-only software. Everyone has their own development process and configuration. I've opted to run OSX... but my VM could just as easily be used on a Linux workstation using VMware Workstation. I think I also managed to get it running in a Wine environment some years ago (as a test, not actual usage)... but disk mapping and such does require some additional attention.
As for needing to copy ROM and RAM... that depends on what you're building (hardware) or what you're writing software for. For my own hardware design, I clear out page zero on a coldstart and copy some vectors and hardware config data from ROM to RAM, then initialize hardware and enter a Monitor program. Loading from a storage device implies the same... however, you would probably need to initialize the (storage) device before loading data from it, unless you implement some other microcontroller to frontend the boot process before releasing the 65(C)02 from a hardware reset.
The WDC samples are intended for their SBC boards... I've got both their 65C02 and 65C816 SXBs, but really haven't done anything with them yet. In any case, not being a C programmer, I doubt I'll ever use the C compiler.
Thanks. Well, as instructions for using wine with the tools are in the other thread, could you please try to compile a program of yours with WDC tools under wine?
No problem running code from ROM. The problem is storing variables in RAM. Startup.asm is needed to copy those initial values to RAM and do the other housekeeping things that happen before main runs.
Thanks. Well, as instructions for using wine with the tools are in the other thread, could you please try to compile a program of yours with WDC tools under wine?
Thanks, again.
Well, I don't need instructions.... I've done this before....
So, I had an older Ubuntu 18.04.02 build installed in a VM. I did the latest updates, then installed Wine and PlayOnLinux from the Ubuntu Applications app. I've never seen or used the PlayOnLinux app before, but it's a slick front end for Wine. Within a few minutes, I navigated thru it and had WDCTools installed. Note that POL sets up a virtual drive for the app... so I also copied my CO2 dev folder from OSX to the virtual drive (which is drive C: to WDC Tools). All I had to do was edit the *.wdc files (which Tide uses) to the correct drive/path and was able to launch Tide from POL, open up any of the *.wdc files and assemble/link as usual. Seems to work fine.
The WDC samples are intended for their SBC boards... I've got both their 65C02 and 65C816 SXBs, but really haven't done anything with them yet. In any case, not being a C programmer, I doubt I'll ever use the C compiler.
The problem is not getting the assembler to work. The problem is the C compiler doesn't work without an assembly file mentioned in the documentation but missing from the install that tokafondo seems to have found for us.
So, I had an older Ubuntu 18.04.02 build installed in a VM. I did the latest updates, then installed Wine and PlayOnLinux from the Ubuntu Applications app. I've never seen or used the PlayOnLinux app before, but it's a slick front end for Wine. Within a few minutes, I navigated thru it and had WDCTools installed. Note that POL sets up a virtual drive for the app... so I also copied my CO2 dev folder from OSX to the virtual drive (which is drive C: to WDC Tools). All I had to do was edit the *.wdc files (which Tide uses) to the correct drive/path and was able to launch Tide from POL, open up any of the *.wdc files and assemble/link as usual. Seems to work fine.
I just apt-get'd wine and the rest of the process was done by command line. PlayOnLinux seems to be targeted to games, but it works anyway.
Yes, the apps seems to work, or do work as you said. Can be said that the compilers generate the same code under Wine than under a VM?
I was able to get mine running without modifying them. (Btw, why in the world is there a project-specific cfg file in the bin directory??? Are we supposed to overwrite it every time we compile?) The linker was complaining about mismatched PAGE0 types and I noticed page.inc doesn't define it unless either USING_02 or the equivalent for the 134 is defined.
The next task is removing the hard coded data section addresses from startup.asm so it will use the address passed to the linker. Garth's term "mickeymouseity" is starting to grow on me.
