I've recently developed a bit of curiosity about a 'C' compiler for the 6502. Has anyone had hands-on experience with a general purpose compiler for the 6502? Now, this is the 6502 and 65C02, not one of its more developed scions, so please limit discussion to the products that actually are designed for the 6502/65C02, and, if you like, include cross-compilers.

The only 6502 'C' compiler I've encountered was developed for the ATARI boxes. I've encountered suggestions that it's been modified for use on other 6502machines, but I've seen no work product from such a compiler.

I'll be interested in reading what experiences folks have had. If none exists, it's straightforward enough to get an effort based on Small-C going. THat would probably be adequate for most applications. What's desirable, of course, is to generate assembly language output rather than relocatable binaries.

regards,

Uli

Ulrich Von Bassewitz has made an excellent generic 6502 C compiler
that can be adapted VERY easily to work on a variety of 6502-based

platforms. The included assembler is good enough to be used alone

(which is what I'm doing right now and has great capabilities and
features, including "segmentation" (basically, being able to relocate
modules at linking time so that a program can easily be ported from
a machine to another without changing the code to account for the
different address maps).

URL: http://www.cc65.org

It's definitely worth a look.
Tennessee Carmel-Veilleux (veilleux@ameth.org)
"The guy who is, and who will be, until he is not anymore"

Well, there's something beyond fussy about the FTP server they use there, since i'm unable to log in with FTP Explorer, with which I've had no trouble with anonymous FTP, beyond specifying the right path. Clearly it doesn't want to let me in.

What do you know about this compiler? How complete is it? HOw completely does it support the Apple IIc? I'm looking to use either the IIc or a PC to support my 6502 development, but since my 6502 is part of a CPLD, it won't run an OS, consequently it can't be relied up on to support the intrinsics of 'C'.

I haven't even been able to find a recent cross-compiler for 'C' to the 6502 in the public domain. Has anybody generated one? I have a couple of 10-15-year-old cross-assemblers that run on the PC, and they do an adequate job, but I'd like to have a 'C' compiler.

Any suggestions, either on the FTP problem or on the general problem of a resident/cross compiler?

Uli

I am having the same trouble getting the latest version of this compiler from the FTP site.

I did find an older version at ftp//archive.umich.edu/atari/8bit/Cc65/

Haven't had a chance to do anything with it yet

- Ted D.

I finally got the file captured and decompressed. It has sat there since, but I'll soon get back to needing it, methinks.

I'll undoubtedly have to write a set of library routines to apply the compiler to my own requirements, but that's WAY better than having to write and debug a compiler.

My preference, hardware wise, is to have a full-up 64 KB of RAM with an EPROM sitting on top of whatever part of it is appropriate. I then vector interrupts through a priority encoder-driven hardware set so IRQ leads directly to the appropriate routine by means of an encoded scheme based on a right-shifted priority table created by setting the three outputs from a 74148-type encoder on bits 3..1 with its bit 0 grounded. It's gated on by detecting the address of the interrupt vector but superimposing it over the low byte of the interrupt vector, possibly another such circuit over the NMI vector so both NMI and IRQ suddenly become more useful. It's a takeoff on the Z-80 mode-2 interrupt. That's fast because the interrupt then is directed through a table directly to the appropriate routine. I also like simply to disable the memory whenever there's an I/O device selected. That's easily done with a single 16-pin device, provided, of course you have <13 devices to select.

It's also a decided advantage to have all the read-write memory contiguous, with no breaks for this I/O device or that. I like to map the EPROM on top of the RAM, then copy it to itself until a write to 0xFFFF is detected. Once that happens, the processor is switched to maximal speed, the EPROM is disabled, and off we go. This requires that the compiler have some information about such things as where and how to address standard I/O, file I/O, etc. It makes it easy to write code, though, because one then simply stacks the data to be passed to the I/O routine and calls the routine. Using a set of I/O routines provided in an external file makes it easy to change the definitions of labelled resources in the library without having to change their names.

Have you looked at the output from the compiler that you have at all?

How's it's code generation?

let me know, plz.

Dick

I haven't played with it enough to make any judgements on its code generation. You might ask the folks on the CC54 mailling list.

- Ted

Perhaps I'll do that. I'm not up for another mailing list, though. I get over 250 emails a day, and the one mailing list I'm already on seems to push about 100.

I'm off chasing a different rabbit at the moment, but I'll get back to this one soon enough.

I've undertaken to translate a popular OS for which I have accumulated much source code into 'C' from PL/M-80 in order to provide at least one useable OS for a generic 650x-based CPU.

Uli

Manx software developped the Aztec C for 6502 (apple Dos3.3 and Prodos) with some bugs (bits operations) in 1985/6 I don't remember

It's been a while, and I've lost track of the context. That CC65 is reputed to be a fair enough 'C' cross-compiler for the 6502.

I've been preoccupied with issues of keeping body and soul together, so I've not worried the issue much.

Have you used that Aztec 'C'? I have it for the Z80 under CP/M. In fact, since the sources for CP/M, both output from disassembly and the original PL/M source are available. I also have a PL/M-to-C translator, probably not terribly useful, but perhaps capable of outlining a translation. Once the C-code is done, there just might turn out to be a CP/M version for the 6502, who knows?

Uli

Yes I used it under Prodos and Apple II 15 years ago.
You can use it with an Apple II GS with hard drive (most comfortable)
No sources from Manx for Apple
If you need a copy (disk/doc) to examine functions it's not a pb

Though I have a IIc and a couple of II+ machines lying about (somewhere) not to mention a number of cards for the II+, I've never been an apple fan. I have a system that started out as a homebrew project and developed into a knock-off of the Digital Group architecture, though it was on a small card rather than the large boards DG prodouced.

My guess is that if I fire up any 6502 hardware it will be programmed using the cross-compiler (CC65) or one of the several cross-assemblers that run on the PC.

I say this because I've seen myself doing the same with other popular 8-bitters in recent years. For example, I found CP/M quite useful back in the late '70's and now occasionally fire it up on one of its native boxes when I'm trying to prove something works more than anything else, and, when I'm modifying code/drivers for that setup, I run a simulator on the PC, which is many times faster, and somewhat more convenient, than using the tools (compilers, compilers & assemblers) I already had back then.

Though there probably were some ppassable OS's for the various 6502 machines that were offered back in the '80's, I'm not sure any of them were particularly good, and certainly Apple DOS wasn't particularly good, being thoroughly wedded to Apple features, partiularly that FDC and memory map of theirs, but none is particularly general in nature, hence likely to be ported to another environment.

As I've said before, one of these days I may very well sit down with the PL/M sources to CP/M, the PLM2C translator, and a few weeks' time and attempt to translate the CP/M OS, which is quite general and, above all, widely understood, and see what pops out the other end. The main goal that would fall out of this, of course, is portability of both code and diskettes from one environment to another.

What makes me take this position is that I find the OS's for 6502 systems are almost always wedded in some awkward way to the concept of a demo or game environment around which nearly all 650x machines were originally designed. That's how they ended up with memory mapped peripherals stuck in the middle of their memory maps or scattered randomly and often redundantly (meaning they used more than the required minimum of memory space for a given peripheral in order to save decoding logic) scattered throughout the upper half of their memory map, e.g. JOLT, KIM, SYM, AIM, among others.

I've always believed that I/O ought to be mapped exclusively into the upper two pages of memory right along with, or on top of, the EPROM code, or, when needed for performance, right into page zero. That way one can use the rest of memory as a contiguous block, making it possible to run code written for nearly anything without having to worry about stepping on someone's video memory or VIA or whatever.

I'm not sure this will ever happen, i.e. I probably will not have time for it, but maybe, with some serendipitous coincidence of events, I may be stuck at home with the flu or some such (don't count on it, I haven't gotten a flu shot this year, and the only times in the past decade and a half that I've had the flu have been the two times I did get the flu innoculation.)

What does make the Aztec 'C' compiler interesting for the 6502 is that it's a dialect, (if it really is a version of the "real" Aztec 'C' rather than something they bought from some struggling company that needed money desperately, of a very popular compiler for CP/M. That could make for code that's portable from one CPU to another, and I like that.

I've tinkered with a disk controller design that would make it possible to read/write standard (FM/MFM) formats using an Apple controller, and, conversely, read/write Apple and other odd formats on a more or less standard controller. It's not trivial, and, probably would be limited to a fairly modern PC. Nonetheless, it would be useful for writing diskettes readable by nearly any machine of yesteryear. Having Apple diskettes to translate to another format would provide a motivation to complete that work. This will have to be accompanied with a bunch of code for the PC that will provide the ability to generate a proper and clock-coherent bitwise format for whatever medium is being aliased.

It would be interesting to see the doc's for that Apple version of Aztec 'C' to compare the dialect with the popular CP/M version. I'm told that it was ultimately sold to Lattice Software at the starting point for their PC-targeted 'C' compiler. Perhaps that's the case, which would make the Apple compiler even more interesting.

Thanks for clearing up the question of whether there actually ever was a complete 'C' compiler for the 6502 itself. The next question will be whether there ever was a "real" OS for the 6502. What do you know about that?

Uli

I have a copy of Aztec C.
I would love to see a CP/M or DOS like command processor to run on top of Apple's ProDOS, instead of their horrible menu based utilities disk.
The problem with a 65/OS as you have mentioned is that most of the 6502 based hardware has the problems that you mentioned hardwired, and such an OS wouldn't work with them. Now, if you were to start from the ground up making a 6502 CP/M with a 6502 based clone of, say, a Kaypro II, then you might have something there.
Exegete AKA Roy Miller
Faith Orthodox Presbyterian Church
Apple ][ forever!

RE: AZTEC 'C' is quite good is based on their other products for pc dos, cp/m-86 cp/m-80, trsdos, apple 3.3 commodore 64, ProDos and the MAC *** It is K & R 'C'. It has the sources for all libraries, editor and the shell; plus graphics library. I think that DeSmet 'C' is better but was only available for 8086 and mac ( I bought the Mac version in 86 and used it since), I have AZTEC for mac but have never used it.

I'm not sure it is in any sense warranted to do anything "serious" with the 650x series in view of the fact that one can simulate the CPU faster on a current-generation PC than a 6502 will run. I frequently see references to really fast 65C02 parts being available, but, though I've had applications for upwards of 10K parts, I've never found anyone willing to sell the fast parts, hence have used a different device in each case. Oddly enough, that, alone, is a strong indicator that the device is "dead" as far as the market is concerned.

The 650x systems I have are not at all like the various video toys, etc, e.g. Commodore toys, etc, that have used the 6502 in that they present a monolithic memory space from 0x0000 to 0xFFC0, with the EPPROM located at 0xF800. The default I/O space is mapped into the EPROM space. The EPROM goes away once it's copied into the corresponding RAM location, and, once the EPROM's gone the CPU speed switches up to what the RAM allows, rather than the slow pace required by most EPROMs. That leaves a few items open. I use a decoding scheme which allows I/O to live more or less anywhere, but the default block is right below the interrupt and reset vectors. The reason for this is that I set the vectors as I/O, as they're from jumpers on the CPU board. That way I don't have to reprogram an EPROM while I'm fiddling with interrupt routines. Once the decisions are made with respect to where the interrupt handlers live, the hardware can be disabled and the vectors committed to EPROM. This is an outgrowth of a time when I felt the need for hardware-prioritized interrupts.

Since the 6502 and, in fact, other microprocessors have been abandoned in favor of single-chip microcontrollers, if you do things they way they should have been done, you're just plowing up new ground for nothing.

Uli

What puzzles me about a multi-os-capable 'C' compiler for the 6502 is which OS's it supports, and how well. I've used the Aztec product for CP/M, but that was on an OS intended for serious use rather than "Oh, by the way, you can use this GREAT game machine as a computer too ..." and there was a well-specified interface to the OS that every software vendor used. That wasn't the sort of thing that was available for most OS' for the 6502.

How would you adapt the Aztec product to a newly defined hardware environment with an indeterminate OS?

Uli