Atari 2600 Compiler

[SkyRender]

Hi everyone!

 

I’m just about to complete my bachelor’s degree in Computer Science, and my friends and I are working together in a Senior Project course to create a compiler. We’ve decided to target the Atari 2600.

 

Now I’ve never done any ROM hacking for the 2600, but it is my understanding that there are quite a few intricacies involved in programming for it. Would it be feasible to create a compiler for the 2600? What obstacles would we run into? Would it be easier to target another video game platform? There are 3 of us and we have 10 weeks to complete the project. Thanks!

[+batari]

There's already a compiler of sorts - a 6502 assembler called dasm together with the vcs.h file essentially makes this a "2600 compiler."

 

What exactly are you suggesting, then? A C compiler? If so, it's a really lofty goal. Merely trying to support some of the most basic C constructs (printf, structs, floats) is practically impossible.

 

Frankly, I'd at least try to support something that has more than 128 bytes of RAM. Also, it would help if the platform had screen memory, an operating system and a real character set, all of which the 2600 lacks. Maybe the Atari 8-bit or C-64?

[Nukey Shay]

Yup...about the only way to produce anything worthwhile on the 2600 is just to use straight assembly. The platform is short on resources for even the most simple games that could be done on a full computer...so a Gamemaker or higher-level programming interpreter-type idea wouldn't work so well.

[Paul Slocum]

There are 6502 C compilers. Somebody got a very simple kernal running with a C compiler a while back, but it's not practical for doing any real work on the 2600. There's been talk about doing some sort of GameMaker system for the 2600 (using pre-designed kernels) but it would probably be pretty limited.

 

-paul

[SkyRender]

Thanks for your input thus far.

 

Right now our plan is to create a compiler for a video game system. Ideally it would include high-level commands specific to building games, such as CreateSprite, or PlaySoundEffect. However, the main goal would be to get at least SOMETHING to compile and run (with the most impressive results possible, of course :-) ) .

 

My idea was to target the 2600. I figured that since it is so much simpler than more modern systems, that it would easier to write a compiler for it. Do you guys have an idea for a system which would be a more ideal target? The NES perhaps? Thanks once again.

[+batari]

There are 6502 C compilers.  Somebody got a very simple kernal running with a C compiler a while back, but it's not practical for doing any real work on the 2600.  There's been talk about doing some sort of GameMaker system for the 2600 (using pre-designed kernels) but it would probably be pretty limited.

It's just a generic 6502 C compiler, then? I imagine that certain constructs must be just be stubs that do nothing without additional libraries, like printfs, scanf, etc.

 

It seems a little surprising, though, that one would even try to get a 2600 kernel working at all with one without using inline assembly. It seems so pointless. I think that once you use "volatile char*" (as you'd probably need to) you might as well just use assembly.

 

Also, I sort of hope that nobody tries to make a gamemaker for the 2600. It would probably just lead to a flood of low quality games in the already limited homebrew market. I could be wrong, though.

[+batari]

I figured that since it is so much simpler than more modern systems, that it would easier to write a compiler for it.

 

In this case, simpler is not easier. Maybe a good target would be the NES. I don't know much about them, but I do know that it uses the 6502 and has some sound and graphics hardware that are well-documented.

[Tom]

It's just a generic 6502 C compiler, then?  I imagine that certain constructs must be just be stubs that do nothing without additional libraries, like printfs, scanf, etc.

 

You know, a C runtime library itself can be generic too. Modern libs are mostly written in C itself, and you simply compile them with the very same C compiler you're going to use to write your C program with.

 

cc65 is a C compiler for the 6502. Its C runtime is written in assembly, but even that can be pretty generic: It runs on a wide range of 6502 based systems, all you have to do is to provide a few interface functions to the underlying OS (such as functions to allocate memory or to do file I/O)

 

I used cc65 to port robotfindskitten to the 7800. I didn't even bother to compile a special runtime library for the 7800. I just took the C64 library. As long as I don't do things that would pull in C64 specific stuff (such as calling printf), the program compiles and runs fine. Of course I had to write a linker script and startup code tailored to the 7800.

 

Anyway, cc65 is totally unsuitable for 2600 development, since it's too resource hungry for the 2600. For instance, it requires quite a bit of zpage RAM, which it uses as additional "registers".

 

It seems a little surprising, though, that one would even try to get a 2600 kernel working at all with one without using inline assembly.  It seems so pointless.  I think that once you use "volatile char*" (as you'd probably need to) you might as well just use assembly.

 

You use volatile to force the compiler not to buffer reads/writes on certain variables. For instance, if you poll a memory location that's actually a hardware register which might change, you don't want a compiler to optimize away repeated reads because it thinks the data can't have changed since the last read.

 

Trying to write a kernel in C is totally futile for another reason: A halfways advanced kernel requires operations to happen at specific clock cycles relative to the beginning of the scanline. With a high level language you have absolutely no control over that.

[+batari]

About declaring volatile char *, I found this all over the place last summer when porting a serial driver from one embedded platform to another. They were both ARM-based and used similar UART chips, and the serial driver was written entierly in C. I thought that porting an existing driver would be easier because the UARTs used interrupt-driven FIFO's and I didn't want to reinvent that wheel.

 

Anyway, all of the memory-mapped hardware registers were declared as such. The use of these constructs along with various other data structured turned a few hundred lines of simple assembly into two thousand lines of convoluted C across several files. As it turned out, it all wasn't that easy to follow.

 

What I ended up doing is I pulled the disassembly of said C code, and I found this infinitely easier to understand how it worked. Then I wrote the new driver based on this dissasembly.

 

So maybe volatile char * has other uses, but in my case it just made my job harder since the only reason it was used was to force C to get at the hardware registers.

 

Anyway, thanks for the link to cc65. There might be some limited use in this even for a 2600, possibly for complicated AI algorithms outside of the kernel, but only if you used it only so you could adapt the disassembly to work on the 2600.[/i]

[Tom]

Seems to me more a like problem of badly written code than like a problem of C itself. C is usually very suitable for hardware bashing. The follwing is taken from HAM, a development kit for the GBA:

 

#define R_VCNT  	*(volatile u16 *)(MEM_IO + 0x06)

 

MEM_IO is the base address of the hardware registers. Now you can access the GBA's VCOUNT register like this:

 

while (VCOUNT != 160);

 

volatile ensures that the compiler generates code that reads VCOUNT every loop iteration.

[Tom]

That should be R_VCNT and not VCOUNT in the second code sample above

[Paul Slocum]

yeah, NES or maybe the 7800 would be much better choices.

[Cybergoth]

Hi there!

 

yeah, NES or maybe the 7800 would be much better choices.

 

No clue about the NES, but the 7800 definitely not. MARIA is the most ugly chip to work with I've ever seen

 

Hm... I thought there's libraries out to programm the Colecovision in turbo-c, so maybe that was a nice environment for such a project. It has simple character mode backgrounds, real sprites, a neat soundchip, a well documented CPU - my suggestion!

 

Greetings,

Manuel

[Tom]

C works fine on the 7800, and constructing display lists with the help of arrays containing structures (for the headers) is kind of convenient.

 

You'll run into problems if you need to update large parts of the display list during vblank, though. The time you have is already limited enough, and cc65's code isn't exactly fast.

 

But you can always code non-time critical code (like setting up a display list skeleton) in C and do the time critical stuff (like updating the display list during vblank) in assembler.

 

Has anybody ever tried out or used at work the 6502 C compiler from Avocet ?

[Bruce Tomlin]

One problem you'll have with all these old systems is address space requirements. For instance, if you want 7800 graphic data to be used from ROM, it basically requires a whole aligned 4K block, with every 256 byte page holding one scan line worth of graphics. And the NES uses a separate ROM for the video chip to generate character block data.

 

But once you get past that, the 7800 and the NES have nice open address spaces that you can use.

 

Other good choices would be the Colecovision (Z-80, 32K of ROM space) and the Vectrex (6809, 32K of ROM space). The 6502 is really primitive, and not such a great choice as a compiler target, especially C, since the 6502 is bad at using pointers. The 6809 was designed to be a good compiler target, but the Vectrex display isn't easy to program for. It's also possible to write position-independent code, which runs from ANY address in memory.

 

Another good choice might be the Color Computer 2. 6809 CPU, ROM can be switched out for an almost full 64K address space, display has nice bitmap modes... and it's even got a cartridge slot! I think the cartridge space is normally 16K, but the slot is actually a full expansion bus.

[SkyRender]

Thanks for everyone's input. The NES sounds like a good choice. I'll look into targeting that.

[Shawn Jefferson]

You use volatile to force the compiler not to buffer reads/writes on certain variables. For instance, if you poll a memory location that's actually a hardware register which might change, you don't want a compiler to optimize away repeated reads because it thinks the data can't have changed since the last read.

 

It's my understanding that in cc65 volatile doesn't do anything. It's ignored by the compiler. ???

 

Trying to write a kernel in C is totally futile for another reason: A halfways advanced kernel requires operations to happen at specific clock cycles relative to the beginning of the scanline. With a high level language you have absolutely no control over that.

 

With cc65, you also don't want to write any interrupts in C either, since there are zero-page variables used as extra registers. Your interrupt will overwrite them if you use any non-trivial code. Well, I guess you could save them first like is being done with the six "register" variables.

[Bruce Tomlin]

It's my understanding that in cc65 volatile doesn't do anything.  It's ignored by the compiler. ???

Volatile is generally ignored if the CPU doesn't have enough registers. Same with the register keyword. At that point it's only important if you want to write portable code.

[Tom]

It's my understanding that in cc65 volatile doesn't do anything.  It's ignored by the compiler. ???

 

Yes it does. I wasn't talking about cc65 only. My main point was why volatile exists in the first place, and that just because one uses it doesn't mean one could by writting everything in assembly aswell.

[Curt Vendel]

Thanks for your input thus far.

 

Right now our plan is to create a compiler for a video game system.  Ideally it would include high-level commands specific to building games, such as CreateSprite, or PlaySoundEffect.  However, the main goal would be to get at least SOMETHING to compile and run (with the most impressive results possible, of course :-) ) .  

 

My idea was to target the 2600.  I figured that since it is so much simpler than more modern systems, that it would easier to write a compiler for it.  Do you guys have an idea for a system which would be a more ideal target?  The NES perhaps?  Thanks once again.

 

 

Perhaps something for the Atari 7800 or the 5200 system (though there are a lot for the 5200 already since its 400/800 hardware, just a different memory map)

 

Something for the 7800 certainly would be good, there are not enough people doing 7800 coding work and the system could do some amazing things if more people took the plunge.

 

 

 

Curt

[+Andrew Davie]

Thanks for your input thus far.

 

Right now our plan is to create a compiler for a video game system.  Ideally it would include high-level commands specific to building games, such as CreateSprite, or PlaySoundEffect.  However, the main goal would be to get at least SOMETHING to compile and run (with the most impressive results possible, of course :-) ) .  

 

My idea was to target the 2600.  I figured that since it is so much simpler than more modern systems, that it would easier to write a compiler for it.  Do you guys have an idea for a system which would be a more ideal target?  The NES perhaps?  Thanks once again.

 

Having programmed all these systems -- 2600, NES, C64, I would strongly advise to target the C64. Flat memory model. No bankswitching. Simple hardware interface. Strong sprite capability. You can make games which work well without having to delve into tricks (such as sprite multiplexing). I think choosing NES or 2600 would be a mistake.

 

Cheers

A

[djmips]

I'd suggest the SEGA Genesis. It uses the 68000. Many commercial games released using C compiler.