Page 1 of 1
WDCTool suite for free
Posted: Fri Dec 19, 2014 9:52 am
by cyc
This Download includes our WDCTool suite with an integrated project simulator/debugger. This environment was developed for the optimization of product development, but can also be enjoyed as some standalone 65xxCoding fun with it’s flexibility in coding options using either Assembly or C language code.
The WDCTools are NOT for resale or reverse engineering of our technology in any form and is NOT provided for development of commercial products that use non–WDC 65xx processors in Core or Chip form.
All tools current work on Windows Platforms (XP/Vista/7/8). For Mac OSX user 65xxTools have been successfully tested on VMware Fusion
Re: WDCTool suite for free
Posted: Fri Dec 19, 2014 11:05 am
by tepples
"NOT provided for development of commercial products that use non–WDC 65xx processors "
I wonder to what extent the C library uses the SED instruction, which would discourage use with mask-ripped 6502/APU combo chips made by Ricoh. Use with the Super NES should be safe because of its presumably legitimately second-sourced 65816 core.
Re: WDCTool suite for free
Posted: Fri Dec 19, 2014 12:08 pm
by Bregalad
I'd really doubt it'd set the D flag, considering decimal mode and BCD are not supported by the C language (that is, without implenting them manually of course, but I don't see a compiler "detecting" that in any way).
However it very likely uses phx/plx phy/ply and other 65C02 extensions that makes it incompatible with the 6502. I remember trying the trial version once and it was outputing code close to CC65, using variables on a terrible "software stack" addressed with the "lda ($xx),y" adressing mode, that kill any chance to get any code that would somehow look not too far away from handwritten assembly.
For the 65C816 it'd be another story, it's likely efficient and great for SNES development for instance.
Re: WDCTool suite for free
Posted: Fri Dec 19, 2014 4:23 pm
by tepples
Bregalad wrote:I'd really doubt it'd set the D flag, considering decimal mode and BCD are not supported by the C language (that is, without implenting them manually of course, but I don't see a compiler "detecting" that in any way).
If the implementation of
printf() and friends uses decimal mode, as in many of the published binary to decimal routines for 6502, running it on an NES will produce Undefined Behavior™.
I remember trying the trial version once and it was outputing code close to CC65
Which is a known quantity thanks in part to Shiru.
using variables on a terrible "software stack" addressed with the "lda ($xx),y" adressing mode
That's really the only way to make automatic local variables for a recursive function. An extension to C to disallow recursive use of a particular function, checked at link time, would allow for more efficient pseudo-static local variable allocation. But I haven't seen this implemented anywhere.
Re: WDCTool suite for free
Posted: Sun Dec 21, 2014 9:51 am
by mikejmoffitt
Fortunately, except maybe for sprintf, I don't think many of us expect much from the other printf variants on the NES!
Re: WDCTool suite for free
Posted: Sun Dec 21, 2014 11:34 am
by Bregalad
That's really the only way to make automatic local variables for a recursive function.
What about using the normal, hardware stack that the 6502 offers at $100-$1ff ? This one can be addressed efficiently thanks to the pha, pla and tsx instructions, and the x register doesn't have to be monopolized for that, as tsx can be used again any time you need the stack-variables-which-are-not-the-top-byte again.
If the implementation of printf() and friends uses decimal mode
I don't really see how the decimal mode helps converting from binary to decimal. Even if it did, a printf() implementation would probably take at least half of a NROM-256 PRG-ROM's size, just because everything it offers is so complicated. Since there is no command line nor a file system or RS-232 implementations on the NES I don't see any uses for the prinf() family of functions.
Re: WDCTool suite for free
Posted: Sun Dec 21, 2014 12:47 pm
by tepples
Bregalad wrote:That's really the only way to make automatic local variables for a recursive function.
What about using the normal, hardware stack that the 6502 offers at $100-$1ff ?
Stack Overflow. I guess the hardware stack is not big enough for any nontrivial C program.
I don't really see how the decimal mode helps converting from binary to decimal.
Google 6502 binary to decimal and the
first result uses
sed in both routines. The
third result likewise uses
sed.
Even if it did, a printf() implementation would probably take at least half of a NROM-256 PRG-ROM's size, just because everything it offers is so complicated. Since there is no command line nor a file system or RS-232 implementations on the NES I don't see any uses for the prinf() family of functions.
Yet NovaSquirrel discovered plenty of
sprintf format strings in Koei's NES games.
Re: WDCTool suite for free
Posted: Sun Dec 21, 2014 5:21 pm
by mikejmoffitt
tepples wrote:Bregalad wrote:That's really the only way to make automatic local variables for a recursive function.
What about using the normal, hardware stack that the 6502 offers at $100-$1ff ?
Stack Overflow. I guess the hardware stack is not big enough for any nontrivial C program.
I don't really see how the decimal mode helps converting from binary to decimal.
Google 6502 binary to decimal and the
first result uses
sed in both routines. The
third result likewise uses
sed.
Even if it did, a printf() implementation would probably take at least half of a NROM-256 PRG-ROM's size, just because everything it offers is so complicated. Since there is no command line nor a file system or RS-232 implementations on the NES I don't see any uses for the prinf() family of functions.
Yet NovaSquirrel discovered plenty of
sprintf format strings in Koei's NES games.
It's possible Koei implemented their own substantially feature-reduced libc, or simply liked the printf-style formatting and preferred to use it even with their own printing routines.
Re: WDCTool suite for free
Posted: Mon Dec 22, 2014 1:48 am
by Bregalad
Google 6502 binary to decimal and the first result uses sed in both routines. The third result likewise uses sed.
Ok, I admit my error. So decimal mode is useful for converting, and a prinf() implementation, which can be used in games in the form of sprintf() which "prints" to memory instead of the more common "file" print, as well as the itoa() function, are likely to use it.
Stack Overflow. I guess the hardware stack is not big enough for any nontrivial C program.
I just figured that for me "stack overflow" was a website before being a potential bug related to the stack
How many variables really needs to be on the stack in a embedded C program ? Unless the author of the source code is one of those functional programming guy who can't code without making re-entrant code, the answer is almost zero. So the ideal would be to put auto variables as "static" normally, but put them on the stack only when recursivity is detected. This causes many problems with separate compilation and function pointers unfortunately. Thus the "C" programming language is originally not designed for processor that does not have efficient access to a large stack.
The only hack that would work would be to compile to an intermediate representation for object files and compile for 6502 only at linking, or to use a C dialect who does not allow recursivity, deviating from the ANSI and other standards.
Re: WDCTool suite for free
Posted: Mon Dec 22, 2014 3:34 pm
by NovaSquirrel
mikejmoffitt wrote:It's possible Koei implemented their own substantially feature-reduced libc, or simply liked the printf-style formatting and preferred to use it even with their own printing routines.
In at least Genghis Khan, format strings don't go beyond %s, plain %d, and right justified %d, so it could very easily be a cut-down version.
The fact that it reads and writes actual ASCII (when the game's font is very different, and converts when writing the resulting strings) makes it seem plausible to me that at the very least the routine's from a generic source, but since there's no cc65-style software stack, and while the code doesn't look too optimized (lots of JSR followed by RTS, for example) it doesn't look
too bad, I wouldn't immediately assume that the game's actually in C.