Were some Atari 2600 games written in C?
Multi tool use
I thought all Atari 2600 games had been programmed in 6502/6507 assembly language (plus whatever activated the Stella sound system), but at a party recently, a friend indicated that some 2600 programmers had actually cross-compiled C code for the 6502. If this is so, which of the 2600 games were in fact written in C, and which compilers were used?
software-development c atari-2600
|
show 1 more comment
I thought all Atari 2600 games had been programmed in 6502/6507 assembly language (plus whatever activated the Stella sound system), but at a party recently, a friend indicated that some 2600 programmers had actually cross-compiled C code for the 6502. If this is so, which of the 2600 games were in fact written in C, and which compilers were used?
software-development c atari-2600
1
I'm willing to wager that this is not so; 6502 is ill-suited for C because of its limited-range hardware stack, and the 2600 even more so because its memory limit restricts the stack even further than that. But I've no evidence whatsoever. And bataribasic.com seems to run and run.
– Tommy
Jan 2 at 18:17
Not C, but some Atari 2600 homebrew is written in another high-level language called Batari BASIC. Maybe this is what your friend was thinking of?
– traal
Jan 2 at 18:46
5
@Tommy You don't need a call stack if you program in a sufficiently limited subset of "C". Keil C51 is not exactly "C", but it's pretty darned close, and it is capable of targeting systems that have only 128 bytes of RAM. It has an option to use activation records that are statically allocated at compile time instead of allocating them from a stack at run-time.
– Solomon Slow
Jan 2 at 19:38
@SolomonSlow the only potential issue (other than recursion, obviously) being that static allocation of activation records may even be a worse thing with only 128 bytes total, as it presumably makes the RAM footprint proportional to the number of functions you've written rather than the complexity of your call chain?
– Tommy
Jan 2 at 22:30
@Tommy: "Static allocation" may involve overlapping the activation records of functions that can not be executing at the same time, given the call graph.
– Henning Makholm
Jan 3 at 0:30
|
show 1 more comment
I thought all Atari 2600 games had been programmed in 6502/6507 assembly language (plus whatever activated the Stella sound system), but at a party recently, a friend indicated that some 2600 programmers had actually cross-compiled C code for the 6502. If this is so, which of the 2600 games were in fact written in C, and which compilers were used?
software-development c atari-2600
I thought all Atari 2600 games had been programmed in 6502/6507 assembly language (plus whatever activated the Stella sound system), but at a party recently, a friend indicated that some 2600 programmers had actually cross-compiled C code for the 6502. If this is so, which of the 2600 games were in fact written in C, and which compilers were used?
software-development c atari-2600
software-development c atari-2600
edited Jan 3 at 0:05
Aaron Brick
asked Jan 2 at 18:13
Aaron BrickAaron Brick
1534
1534
1
I'm willing to wager that this is not so; 6502 is ill-suited for C because of its limited-range hardware stack, and the 2600 even more so because its memory limit restricts the stack even further than that. But I've no evidence whatsoever. And bataribasic.com seems to run and run.
– Tommy
Jan 2 at 18:17
Not C, but some Atari 2600 homebrew is written in another high-level language called Batari BASIC. Maybe this is what your friend was thinking of?
– traal
Jan 2 at 18:46
5
@Tommy You don't need a call stack if you program in a sufficiently limited subset of "C". Keil C51 is not exactly "C", but it's pretty darned close, and it is capable of targeting systems that have only 128 bytes of RAM. It has an option to use activation records that are statically allocated at compile time instead of allocating them from a stack at run-time.
– Solomon Slow
Jan 2 at 19:38
@SolomonSlow the only potential issue (other than recursion, obviously) being that static allocation of activation records may even be a worse thing with only 128 bytes total, as it presumably makes the RAM footprint proportional to the number of functions you've written rather than the complexity of your call chain?
– Tommy
Jan 2 at 22:30
@Tommy: "Static allocation" may involve overlapping the activation records of functions that can not be executing at the same time, given the call graph.
– Henning Makholm
Jan 3 at 0:30
|
show 1 more comment
1
I'm willing to wager that this is not so; 6502 is ill-suited for C because of its limited-range hardware stack, and the 2600 even more so because its memory limit restricts the stack even further than that. But I've no evidence whatsoever. And bataribasic.com seems to run and run.
– Tommy
Jan 2 at 18:17
Not C, but some Atari 2600 homebrew is written in another high-level language called Batari BASIC. Maybe this is what your friend was thinking of?
– traal
Jan 2 at 18:46
5
@Tommy You don't need a call stack if you program in a sufficiently limited subset of "C". Keil C51 is not exactly "C", but it's pretty darned close, and it is capable of targeting systems that have only 128 bytes of RAM. It has an option to use activation records that are statically allocated at compile time instead of allocating them from a stack at run-time.
– Solomon Slow
Jan 2 at 19:38
@SolomonSlow the only potential issue (other than recursion, obviously) being that static allocation of activation records may even be a worse thing with only 128 bytes total, as it presumably makes the RAM footprint proportional to the number of functions you've written rather than the complexity of your call chain?
– Tommy
Jan 2 at 22:30
@Tommy: "Static allocation" may involve overlapping the activation records of functions that can not be executing at the same time, given the call graph.
– Henning Makholm
Jan 3 at 0:30
1
1
I'm willing to wager that this is not so; 6502 is ill-suited for C because of its limited-range hardware stack, and the 2600 even more so because its memory limit restricts the stack even further than that. But I've no evidence whatsoever. And bataribasic.com seems to run and run.
– Tommy
Jan 2 at 18:17
I'm willing to wager that this is not so; 6502 is ill-suited for C because of its limited-range hardware stack, and the 2600 even more so because its memory limit restricts the stack even further than that. But I've no evidence whatsoever. And bataribasic.com seems to run and run.
– Tommy
Jan 2 at 18:17
Not C, but some Atari 2600 homebrew is written in another high-level language called Batari BASIC. Maybe this is what your friend was thinking of?
– traal
Jan 2 at 18:46
Not C, but some Atari 2600 homebrew is written in another high-level language called Batari BASIC. Maybe this is what your friend was thinking of?
– traal
Jan 2 at 18:46
5
5
@Tommy You don't need a call stack if you program in a sufficiently limited subset of "C". Keil C51 is not exactly "C", but it's pretty darned close, and it is capable of targeting systems that have only 128 bytes of RAM. It has an option to use activation records that are statically allocated at compile time instead of allocating them from a stack at run-time.
– Solomon Slow
Jan 2 at 19:38
@Tommy You don't need a call stack if you program in a sufficiently limited subset of "C". Keil C51 is not exactly "C", but it's pretty darned close, and it is capable of targeting systems that have only 128 bytes of RAM. It has an option to use activation records that are statically allocated at compile time instead of allocating them from a stack at run-time.
– Solomon Slow
Jan 2 at 19:38
@SolomonSlow the only potential issue (other than recursion, obviously) being that static allocation of activation records may even be a worse thing with only 128 bytes total, as it presumably makes the RAM footprint proportional to the number of functions you've written rather than the complexity of your call chain?
– Tommy
Jan 2 at 22:30
@SolomonSlow the only potential issue (other than recursion, obviously) being that static allocation of activation records may even be a worse thing with only 128 bytes total, as it presumably makes the RAM footprint proportional to the number of functions you've written rather than the complexity of your call chain?
– Tommy
Jan 2 at 22:30
@Tommy: "Static allocation" may involve overlapping the activation records of functions that can not be executing at the same time, given the call graph.
– Henning Makholm
Jan 3 at 0:30
@Tommy: "Static allocation" may involve overlapping the activation records of functions that can not be executing at the same time, given the call graph.
– Henning Makholm
Jan 3 at 0:30
|
show 1 more comment
3 Answers
3
active
oldest
votes
Moste likely your friend was referring to modern time developments, not contemporary games. While today CC65 does deliver acceptable results for every day jobs, the 6502 isn't exactly C-friendly. C does require a certain memory handling - and quite some RAM as well. To program the 2600 with its bare bone 128 Bytes of RAM is already a tough job in Assembly and much less feasible in C.
If at all, I can only see some usage in the area of demo-programming, where next to no RAM data is needed, as such code is not driven by variable and interactive data, but runs straight and unmodified ahead.
So go ahead and call out your friend to give you evidence for his assumption - and what it was exactly about.
BTW: Stella is the code name for the whole 2600 system. The (only) custom chip was called TIA and did not only sound but display as well - under direct CPU control that is.
1
Wouldn't the 6507 be considered a custom chip? I don't think it was mass produced for anyone other than Atari. But I could be wrong on this. Even though it was a stripped down 6502, I would call that custom. The RIOT, for example, could be considered a common "off the shelf" part as it was made for the purpose of multiple systems.
– cbmeeks
Jan 2 at 20:21
2
The 6507 was a standard of the shelf chip. The 6503..07 are 28 pin variations of the 6502 with reduced address pins (A0..11) plus depending on the version a combination of two signals out of A12, RDY, IRQ, NMI, Phi1-Out. The 6507 it an A12+RDY version. While it is true that the very first family manual only listed 6503..05, 06 and 07 where added soon. They where also not only supplied by MOS, but as well standard products of Rockwell and others as a standard product, "off the shelf". It's further true that use in other systems was limited due the missing interrupt capability.
– Raffzahn
Jan 2 at 20:41
IIRC the 6507 was as well used in the Atari 810 Floppy drive, as well as the serial interface. But I may need to check.
– Raffzahn
Jan 2 at 20:42
hmm, @cbmeeks, thinking of it, you might be onto something here. It could well have been that the 6507 was defined as a result to Atari's requirements for the VCS. The console was extreme price sensitive, and a 28 pin CPU does save on all accounts: Lower CPU cost due smaller packageing, as well as on the PCB due less drilling. It is known that there where intense meetings about cost lowerign between Atari and MOS, so it could well be that they added he 6507 especially for Atari. Still, after that it was available to everyone else as standard component.
– Raffzahn
Jan 2 at 21:17
Well, @Raffzahn, a more interesting conversation would be how would Atari have been different if they sprang for a couple more address pins? Imagine easy 16K games with no additional glue logic. Sure, would have been too expensive in the 70's but by mid-80's, a simple inverter and two 16K chips would have made for interesting games for not that much money.
– cbmeeks
Jan 3 at 16:11
|
show 6 more comments
Only people who worked for Atari or third-party game developers could say for sure.
For early development, the history of the 2600 and C don't align very well. Atari began design for the first prototypes of the 2600 began in late 1975, shortly after the 6502 was introduced. C made its first appearance anywhere in 1972 and Kernighan and Ritchie wouldn't publish The C Programming Language until 1978, the year after the 2600 was introduced. Compilers in those days were almost always written to be run on their target platforms, and cross-compilation was a rarity if it existed at all. The first known C compiler that isolated code generation enough to make porting it to other platforms was PCC, which didn't make it out of Bell Labs until 1979 as part of Unix V7.
Later development in C would have been a very remote possibility. In 1983, Manx released Aztec C65, a compiler for the Apple II which produced object code that could, in theory be run on the 2600. Manx warns about the trade-offs of trying to run C on a 6502 in its mini-manual (see section 1.6). It's difficult to imagine that compiled C would be a good choice on a target with such limited memory and no frame buffer. The latter required that video be generated in real time by the processor, leaving fewer cycles available for game play and a hard, 33-millisecond deadline to start generating the next frame of video. If you ever saw black bars at the edges of the screen on a 2600, that was a symptom of the deadline being missed.
Recommended reading: Racing the Beam by Montfort and Bogost.
Thanks for the tip, the book was great.
– Aaron Brick
Jan 18 at 18:53
add a comment |
C didn't have anywhere near the popularity and ubiquity that it does today. As has been mentioned elsewhere, the 6502 is a crummy target for a C compiler, notably with it's sparse, 8 bit register set.
Recall the sparse architecture of the machine: 128 bytes of RAM and 4K of ROM. A 4K assembly language program, with several 8-bit, and a few 16-bit counters or pointers, is not an arduous amount of code for an assembly language programmer. (Yes, there were banked cartridges later, but most of it was for data rather than actual code.)
One of the key values of a language like C is also portability, something that was simply not a concern here.
Finally, games on systems like the Atari were notorious for their optimizations, and other shenanigans and contortions the developers went through to get their titles crammed in to these creaky, slow boxes. Leveraging the underlying CPU to their full potential required 100% access to it, something that C did not offer. C does not offer access to things like the status registers of the CPU. The coders needed exact cycle timings for certain tasks. Direct access to timers and interrupt handlers, some which may change from scene to scene or even frame to frame. The assembly language developer can write code that "knew" exactly what state it was in at all times, and was coded appropriately.
Any high level value that C could have offered was lost not just in lack of access to the CPU, but also just in terms of longer turn arounds and development cycles. C is expensive to compile compared to assembly, and back then, yes, this mattered. A good macro assembler readily takes the sting of using assembly by letting the developer add in higher level constructs (working with structures, working with collections, looping, branching, etc.) or even small DSLs written in macros.
So, in the end, the cost of C wouldn't have brought enough value to the table for a professional game developer on such limited systems back then.
C is compiled by a compiler. Assembly languages are not compiled, they are assembled by an assembler. The difference is that assembly mnemonics map one-to-one with binary opcodes, whereas a compiler has much more work to do than just substituting opcodes for mnemonics.
– LawrenceC
Jan 18 at 19:33
Even without "a good macro assembler", a program that's a few thousand instructions long isn't too bad for working on manually at the CPU instruction level. You can easily get to that point with just a thousand or so lines of reasonably sparse (as opposed to compact) C. The hard part is likely going to be cramming whatever actual logic you need into the available memory anyway, whether one uses C or assembler.
– a CVn
Jan 22 at 10:06
add a comment |
Your Answer
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "648"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
noCode: true, onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fretrocomputing.stackexchange.com%2fquestions%2f8640%2fwere-some-atari-2600-games-written-in-c%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
3 Answers
3
active
oldest
votes
3 Answers
3
active
oldest
votes
active
oldest
votes
active
oldest
votes
Moste likely your friend was referring to modern time developments, not contemporary games. While today CC65 does deliver acceptable results for every day jobs, the 6502 isn't exactly C-friendly. C does require a certain memory handling - and quite some RAM as well. To program the 2600 with its bare bone 128 Bytes of RAM is already a tough job in Assembly and much less feasible in C.
If at all, I can only see some usage in the area of demo-programming, where next to no RAM data is needed, as such code is not driven by variable and interactive data, but runs straight and unmodified ahead.
So go ahead and call out your friend to give you evidence for his assumption - and what it was exactly about.
BTW: Stella is the code name for the whole 2600 system. The (only) custom chip was called TIA and did not only sound but display as well - under direct CPU control that is.
1
Wouldn't the 6507 be considered a custom chip? I don't think it was mass produced for anyone other than Atari. But I could be wrong on this. Even though it was a stripped down 6502, I would call that custom. The RIOT, for example, could be considered a common "off the shelf" part as it was made for the purpose of multiple systems.
– cbmeeks
Jan 2 at 20:21
2
The 6507 was a standard of the shelf chip. The 6503..07 are 28 pin variations of the 6502 with reduced address pins (A0..11) plus depending on the version a combination of two signals out of A12, RDY, IRQ, NMI, Phi1-Out. The 6507 it an A12+RDY version. While it is true that the very first family manual only listed 6503..05, 06 and 07 where added soon. They where also not only supplied by MOS, but as well standard products of Rockwell and others as a standard product, "off the shelf". It's further true that use in other systems was limited due the missing interrupt capability.
– Raffzahn
Jan 2 at 20:41
IIRC the 6507 was as well used in the Atari 810 Floppy drive, as well as the serial interface. But I may need to check.
– Raffzahn
Jan 2 at 20:42
hmm, @cbmeeks, thinking of it, you might be onto something here. It could well have been that the 6507 was defined as a result to Atari's requirements for the VCS. The console was extreme price sensitive, and a 28 pin CPU does save on all accounts: Lower CPU cost due smaller packageing, as well as on the PCB due less drilling. It is known that there where intense meetings about cost lowerign between Atari and MOS, so it could well be that they added he 6507 especially for Atari. Still, after that it was available to everyone else as standard component.
– Raffzahn
Jan 2 at 21:17
Well, @Raffzahn, a more interesting conversation would be how would Atari have been different if they sprang for a couple more address pins? Imagine easy 16K games with no additional glue logic. Sure, would have been too expensive in the 70's but by mid-80's, a simple inverter and two 16K chips would have made for interesting games for not that much money.
– cbmeeks
Jan 3 at 16:11
|
show 6 more comments
Moste likely your friend was referring to modern time developments, not contemporary games. While today CC65 does deliver acceptable results for every day jobs, the 6502 isn't exactly C-friendly. C does require a certain memory handling - and quite some RAM as well. To program the 2600 with its bare bone 128 Bytes of RAM is already a tough job in Assembly and much less feasible in C.
If at all, I can only see some usage in the area of demo-programming, where next to no RAM data is needed, as such code is not driven by variable and interactive data, but runs straight and unmodified ahead.
So go ahead and call out your friend to give you evidence for his assumption - and what it was exactly about.
BTW: Stella is the code name for the whole 2600 system. The (only) custom chip was called TIA and did not only sound but display as well - under direct CPU control that is.
1
Wouldn't the 6507 be considered a custom chip? I don't think it was mass produced for anyone other than Atari. But I could be wrong on this. Even though it was a stripped down 6502, I would call that custom. The RIOT, for example, could be considered a common "off the shelf" part as it was made for the purpose of multiple systems.
– cbmeeks
Jan 2 at 20:21
2
The 6507 was a standard of the shelf chip. The 6503..07 are 28 pin variations of the 6502 with reduced address pins (A0..11) plus depending on the version a combination of two signals out of A12, RDY, IRQ, NMI, Phi1-Out. The 6507 it an A12+RDY version. While it is true that the very first family manual only listed 6503..05, 06 and 07 where added soon. They where also not only supplied by MOS, but as well standard products of Rockwell and others as a standard product, "off the shelf". It's further true that use in other systems was limited due the missing interrupt capability.
– Raffzahn
Jan 2 at 20:41
IIRC the 6507 was as well used in the Atari 810 Floppy drive, as well as the serial interface. But I may need to check.
– Raffzahn
Jan 2 at 20:42
hmm, @cbmeeks, thinking of it, you might be onto something here. It could well have been that the 6507 was defined as a result to Atari's requirements for the VCS. The console was extreme price sensitive, and a 28 pin CPU does save on all accounts: Lower CPU cost due smaller packageing, as well as on the PCB due less drilling. It is known that there where intense meetings about cost lowerign between Atari and MOS, so it could well be that they added he 6507 especially for Atari. Still, after that it was available to everyone else as standard component.
– Raffzahn
Jan 2 at 21:17
Well, @Raffzahn, a more interesting conversation would be how would Atari have been different if they sprang for a couple more address pins? Imagine easy 16K games with no additional glue logic. Sure, would have been too expensive in the 70's but by mid-80's, a simple inverter and two 16K chips would have made for interesting games for not that much money.
– cbmeeks
Jan 3 at 16:11
|
show 6 more comments
Moste likely your friend was referring to modern time developments, not contemporary games. While today CC65 does deliver acceptable results for every day jobs, the 6502 isn't exactly C-friendly. C does require a certain memory handling - and quite some RAM as well. To program the 2600 with its bare bone 128 Bytes of RAM is already a tough job in Assembly and much less feasible in C.
If at all, I can only see some usage in the area of demo-programming, where next to no RAM data is needed, as such code is not driven by variable and interactive data, but runs straight and unmodified ahead.
So go ahead and call out your friend to give you evidence for his assumption - and what it was exactly about.
BTW: Stella is the code name for the whole 2600 system. The (only) custom chip was called TIA and did not only sound but display as well - under direct CPU control that is.
Moste likely your friend was referring to modern time developments, not contemporary games. While today CC65 does deliver acceptable results for every day jobs, the 6502 isn't exactly C-friendly. C does require a certain memory handling - and quite some RAM as well. To program the 2600 with its bare bone 128 Bytes of RAM is already a tough job in Assembly and much less feasible in C.
If at all, I can only see some usage in the area of demo-programming, where next to no RAM data is needed, as such code is not driven by variable and interactive data, but runs straight and unmodified ahead.
So go ahead and call out your friend to give you evidence for his assumption - and what it was exactly about.
BTW: Stella is the code name for the whole 2600 system. The (only) custom chip was called TIA and did not only sound but display as well - under direct CPU control that is.
edited Jan 2 at 18:33
answered Jan 2 at 18:24
RaffzahnRaffzahn
52.7k6124213
52.7k6124213
1
Wouldn't the 6507 be considered a custom chip? I don't think it was mass produced for anyone other than Atari. But I could be wrong on this. Even though it was a stripped down 6502, I would call that custom. The RIOT, for example, could be considered a common "off the shelf" part as it was made for the purpose of multiple systems.
– cbmeeks
Jan 2 at 20:21
2
The 6507 was a standard of the shelf chip. The 6503..07 are 28 pin variations of the 6502 with reduced address pins (A0..11) plus depending on the version a combination of two signals out of A12, RDY, IRQ, NMI, Phi1-Out. The 6507 it an A12+RDY version. While it is true that the very first family manual only listed 6503..05, 06 and 07 where added soon. They where also not only supplied by MOS, but as well standard products of Rockwell and others as a standard product, "off the shelf". It's further true that use in other systems was limited due the missing interrupt capability.
– Raffzahn
Jan 2 at 20:41
IIRC the 6507 was as well used in the Atari 810 Floppy drive, as well as the serial interface. But I may need to check.
– Raffzahn
Jan 2 at 20:42
hmm, @cbmeeks, thinking of it, you might be onto something here. It could well have been that the 6507 was defined as a result to Atari's requirements for the VCS. The console was extreme price sensitive, and a 28 pin CPU does save on all accounts: Lower CPU cost due smaller packageing, as well as on the PCB due less drilling. It is known that there where intense meetings about cost lowerign between Atari and MOS, so it could well be that they added he 6507 especially for Atari. Still, after that it was available to everyone else as standard component.
– Raffzahn
Jan 2 at 21:17
Well, @Raffzahn, a more interesting conversation would be how would Atari have been different if they sprang for a couple more address pins? Imagine easy 16K games with no additional glue logic. Sure, would have been too expensive in the 70's but by mid-80's, a simple inverter and two 16K chips would have made for interesting games for not that much money.
– cbmeeks
Jan 3 at 16:11
|
show 6 more comments
1
Wouldn't the 6507 be considered a custom chip? I don't think it was mass produced for anyone other than Atari. But I could be wrong on this. Even though it was a stripped down 6502, I would call that custom. The RIOT, for example, could be considered a common "off the shelf" part as it was made for the purpose of multiple systems.
– cbmeeks
Jan 2 at 20:21
2
The 6507 was a standard of the shelf chip. The 6503..07 are 28 pin variations of the 6502 with reduced address pins (A0..11) plus depending on the version a combination of two signals out of A12, RDY, IRQ, NMI, Phi1-Out. The 6507 it an A12+RDY version. While it is true that the very first family manual only listed 6503..05, 06 and 07 where added soon. They where also not only supplied by MOS, but as well standard products of Rockwell and others as a standard product, "off the shelf". It's further true that use in other systems was limited due the missing interrupt capability.
– Raffzahn
Jan 2 at 20:41
IIRC the 6507 was as well used in the Atari 810 Floppy drive, as well as the serial interface. But I may need to check.
– Raffzahn
Jan 2 at 20:42
hmm, @cbmeeks, thinking of it, you might be onto something here. It could well have been that the 6507 was defined as a result to Atari's requirements for the VCS. The console was extreme price sensitive, and a 28 pin CPU does save on all accounts: Lower CPU cost due smaller packageing, as well as on the PCB due less drilling. It is known that there where intense meetings about cost lowerign between Atari and MOS, so it could well be that they added he 6507 especially for Atari. Still, after that it was available to everyone else as standard component.
– Raffzahn
Jan 2 at 21:17
Well, @Raffzahn, a more interesting conversation would be how would Atari have been different if they sprang for a couple more address pins? Imagine easy 16K games with no additional glue logic. Sure, would have been too expensive in the 70's but by mid-80's, a simple inverter and two 16K chips would have made for interesting games for not that much money.
– cbmeeks
Jan 3 at 16:11
1
1
Wouldn't the 6507 be considered a custom chip? I don't think it was mass produced for anyone other than Atari. But I could be wrong on this. Even though it was a stripped down 6502, I would call that custom. The RIOT, for example, could be considered a common "off the shelf" part as it was made for the purpose of multiple systems.
– cbmeeks
Jan 2 at 20:21
Wouldn't the 6507 be considered a custom chip? I don't think it was mass produced for anyone other than Atari. But I could be wrong on this. Even though it was a stripped down 6502, I would call that custom. The RIOT, for example, could be considered a common "off the shelf" part as it was made for the purpose of multiple systems.
– cbmeeks
Jan 2 at 20:21
2
2
The 6507 was a standard of the shelf chip. The 6503..07 are 28 pin variations of the 6502 with reduced address pins (A0..11) plus depending on the version a combination of two signals out of A12, RDY, IRQ, NMI, Phi1-Out. The 6507 it an A12+RDY version. While it is true that the very first family manual only listed 6503..05, 06 and 07 where added soon. They where also not only supplied by MOS, but as well standard products of Rockwell and others as a standard product, "off the shelf". It's further true that use in other systems was limited due the missing interrupt capability.
– Raffzahn
Jan 2 at 20:41
The 6507 was a standard of the shelf chip. The 6503..07 are 28 pin variations of the 6502 with reduced address pins (A0..11) plus depending on the version a combination of two signals out of A12, RDY, IRQ, NMI, Phi1-Out. The 6507 it an A12+RDY version. While it is true that the very first family manual only listed 6503..05, 06 and 07 where added soon. They where also not only supplied by MOS, but as well standard products of Rockwell and others as a standard product, "off the shelf". It's further true that use in other systems was limited due the missing interrupt capability.
– Raffzahn
Jan 2 at 20:41
IIRC the 6507 was as well used in the Atari 810 Floppy drive, as well as the serial interface. But I may need to check.
– Raffzahn
Jan 2 at 20:42
IIRC the 6507 was as well used in the Atari 810 Floppy drive, as well as the serial interface. But I may need to check.
– Raffzahn
Jan 2 at 20:42
hmm, @cbmeeks, thinking of it, you might be onto something here. It could well have been that the 6507 was defined as a result to Atari's requirements for the VCS. The console was extreme price sensitive, and a 28 pin CPU does save on all accounts: Lower CPU cost due smaller packageing, as well as on the PCB due less drilling. It is known that there where intense meetings about cost lowerign between Atari and MOS, so it could well be that they added he 6507 especially for Atari. Still, after that it was available to everyone else as standard component.
– Raffzahn
Jan 2 at 21:17
hmm, @cbmeeks, thinking of it, you might be onto something here. It could well have been that the 6507 was defined as a result to Atari's requirements for the VCS. The console was extreme price sensitive, and a 28 pin CPU does save on all accounts: Lower CPU cost due smaller packageing, as well as on the PCB due less drilling. It is known that there where intense meetings about cost lowerign between Atari and MOS, so it could well be that they added he 6507 especially for Atari. Still, after that it was available to everyone else as standard component.
– Raffzahn
Jan 2 at 21:17
Well, @Raffzahn, a more interesting conversation would be how would Atari have been different if they sprang for a couple more address pins? Imagine easy 16K games with no additional glue logic. Sure, would have been too expensive in the 70's but by mid-80's, a simple inverter and two 16K chips would have made for interesting games for not that much money.
– cbmeeks
Jan 3 at 16:11
Well, @Raffzahn, a more interesting conversation would be how would Atari have been different if they sprang for a couple more address pins? Imagine easy 16K games with no additional glue logic. Sure, would have been too expensive in the 70's but by mid-80's, a simple inverter and two 16K chips would have made for interesting games for not that much money.
– cbmeeks
Jan 3 at 16:11
|
show 6 more comments
Only people who worked for Atari or third-party game developers could say for sure.
For early development, the history of the 2600 and C don't align very well. Atari began design for the first prototypes of the 2600 began in late 1975, shortly after the 6502 was introduced. C made its first appearance anywhere in 1972 and Kernighan and Ritchie wouldn't publish The C Programming Language until 1978, the year after the 2600 was introduced. Compilers in those days were almost always written to be run on their target platforms, and cross-compilation was a rarity if it existed at all. The first known C compiler that isolated code generation enough to make porting it to other platforms was PCC, which didn't make it out of Bell Labs until 1979 as part of Unix V7.
Later development in C would have been a very remote possibility. In 1983, Manx released Aztec C65, a compiler for the Apple II which produced object code that could, in theory be run on the 2600. Manx warns about the trade-offs of trying to run C on a 6502 in its mini-manual (see section 1.6). It's difficult to imagine that compiled C would be a good choice on a target with such limited memory and no frame buffer. The latter required that video be generated in real time by the processor, leaving fewer cycles available for game play and a hard, 33-millisecond deadline to start generating the next frame of video. If you ever saw black bars at the edges of the screen on a 2600, that was a symptom of the deadline being missed.
Recommended reading: Racing the Beam by Montfort and Bogost.
Thanks for the tip, the book was great.
– Aaron Brick
Jan 18 at 18:53
add a comment |
Only people who worked for Atari or third-party game developers could say for sure.
For early development, the history of the 2600 and C don't align very well. Atari began design for the first prototypes of the 2600 began in late 1975, shortly after the 6502 was introduced. C made its first appearance anywhere in 1972 and Kernighan and Ritchie wouldn't publish The C Programming Language until 1978, the year after the 2600 was introduced. Compilers in those days were almost always written to be run on their target platforms, and cross-compilation was a rarity if it existed at all. The first known C compiler that isolated code generation enough to make porting it to other platforms was PCC, which didn't make it out of Bell Labs until 1979 as part of Unix V7.
Later development in C would have been a very remote possibility. In 1983, Manx released Aztec C65, a compiler for the Apple II which produced object code that could, in theory be run on the 2600. Manx warns about the trade-offs of trying to run C on a 6502 in its mini-manual (see section 1.6). It's difficult to imagine that compiled C would be a good choice on a target with such limited memory and no frame buffer. The latter required that video be generated in real time by the processor, leaving fewer cycles available for game play and a hard, 33-millisecond deadline to start generating the next frame of video. If you ever saw black bars at the edges of the screen on a 2600, that was a symptom of the deadline being missed.
Recommended reading: Racing the Beam by Montfort and Bogost.
Thanks for the tip, the book was great.
– Aaron Brick
Jan 18 at 18:53
add a comment |
Only people who worked for Atari or third-party game developers could say for sure.
For early development, the history of the 2600 and C don't align very well. Atari began design for the first prototypes of the 2600 began in late 1975, shortly after the 6502 was introduced. C made its first appearance anywhere in 1972 and Kernighan and Ritchie wouldn't publish The C Programming Language until 1978, the year after the 2600 was introduced. Compilers in those days were almost always written to be run on their target platforms, and cross-compilation was a rarity if it existed at all. The first known C compiler that isolated code generation enough to make porting it to other platforms was PCC, which didn't make it out of Bell Labs until 1979 as part of Unix V7.
Later development in C would have been a very remote possibility. In 1983, Manx released Aztec C65, a compiler for the Apple II which produced object code that could, in theory be run on the 2600. Manx warns about the trade-offs of trying to run C on a 6502 in its mini-manual (see section 1.6). It's difficult to imagine that compiled C would be a good choice on a target with such limited memory and no frame buffer. The latter required that video be generated in real time by the processor, leaving fewer cycles available for game play and a hard, 33-millisecond deadline to start generating the next frame of video. If you ever saw black bars at the edges of the screen on a 2600, that was a symptom of the deadline being missed.
Recommended reading: Racing the Beam by Montfort and Bogost.
Only people who worked for Atari or third-party game developers could say for sure.
For early development, the history of the 2600 and C don't align very well. Atari began design for the first prototypes of the 2600 began in late 1975, shortly after the 6502 was introduced. C made its first appearance anywhere in 1972 and Kernighan and Ritchie wouldn't publish The C Programming Language until 1978, the year after the 2600 was introduced. Compilers in those days were almost always written to be run on their target platforms, and cross-compilation was a rarity if it existed at all. The first known C compiler that isolated code generation enough to make porting it to other platforms was PCC, which didn't make it out of Bell Labs until 1979 as part of Unix V7.
Later development in C would have been a very remote possibility. In 1983, Manx released Aztec C65, a compiler for the Apple II which produced object code that could, in theory be run on the 2600. Manx warns about the trade-offs of trying to run C on a 6502 in its mini-manual (see section 1.6). It's difficult to imagine that compiled C would be a good choice on a target with such limited memory and no frame buffer. The latter required that video be generated in real time by the processor, leaving fewer cycles available for game play and a hard, 33-millisecond deadline to start generating the next frame of video. If you ever saw black bars at the edges of the screen on a 2600, that was a symptom of the deadline being missed.
Recommended reading: Racing the Beam by Montfort and Bogost.
edited Jan 4 at 3:40
answered Jan 3 at 4:48
BlrflBlrfl
60147
60147
Thanks for the tip, the book was great.
– Aaron Brick
Jan 18 at 18:53
add a comment |
Thanks for the tip, the book was great.
– Aaron Brick
Jan 18 at 18:53
Thanks for the tip, the book was great.
– Aaron Brick
Jan 18 at 18:53
Thanks for the tip, the book was great.
– Aaron Brick
Jan 18 at 18:53
add a comment |
C didn't have anywhere near the popularity and ubiquity that it does today. As has been mentioned elsewhere, the 6502 is a crummy target for a C compiler, notably with it's sparse, 8 bit register set.
Recall the sparse architecture of the machine: 128 bytes of RAM and 4K of ROM. A 4K assembly language program, with several 8-bit, and a few 16-bit counters or pointers, is not an arduous amount of code for an assembly language programmer. (Yes, there were banked cartridges later, but most of it was for data rather than actual code.)
One of the key values of a language like C is also portability, something that was simply not a concern here.
Finally, games on systems like the Atari were notorious for their optimizations, and other shenanigans and contortions the developers went through to get their titles crammed in to these creaky, slow boxes. Leveraging the underlying CPU to their full potential required 100% access to it, something that C did not offer. C does not offer access to things like the status registers of the CPU. The coders needed exact cycle timings for certain tasks. Direct access to timers and interrupt handlers, some which may change from scene to scene or even frame to frame. The assembly language developer can write code that "knew" exactly what state it was in at all times, and was coded appropriately.
Any high level value that C could have offered was lost not just in lack of access to the CPU, but also just in terms of longer turn arounds and development cycles. C is expensive to compile compared to assembly, and back then, yes, this mattered. A good macro assembler readily takes the sting of using assembly by letting the developer add in higher level constructs (working with structures, working with collections, looping, branching, etc.) or even small DSLs written in macros.
So, in the end, the cost of C wouldn't have brought enough value to the table for a professional game developer on such limited systems back then.
C is compiled by a compiler. Assembly languages are not compiled, they are assembled by an assembler. The difference is that assembly mnemonics map one-to-one with binary opcodes, whereas a compiler has much more work to do than just substituting opcodes for mnemonics.
– LawrenceC
Jan 18 at 19:33
Even without "a good macro assembler", a program that's a few thousand instructions long isn't too bad for working on manually at the CPU instruction level. You can easily get to that point with just a thousand or so lines of reasonably sparse (as opposed to compact) C. The hard part is likely going to be cramming whatever actual logic you need into the available memory anyway, whether one uses C or assembler.
– a CVn
Jan 22 at 10:06
add a comment |
C didn't have anywhere near the popularity and ubiquity that it does today. As has been mentioned elsewhere, the 6502 is a crummy target for a C compiler, notably with it's sparse, 8 bit register set.
Recall the sparse architecture of the machine: 128 bytes of RAM and 4K of ROM. A 4K assembly language program, with several 8-bit, and a few 16-bit counters or pointers, is not an arduous amount of code for an assembly language programmer. (Yes, there were banked cartridges later, but most of it was for data rather than actual code.)
One of the key values of a language like C is also portability, something that was simply not a concern here.
Finally, games on systems like the Atari were notorious for their optimizations, and other shenanigans and contortions the developers went through to get their titles crammed in to these creaky, slow boxes. Leveraging the underlying CPU to their full potential required 100% access to it, something that C did not offer. C does not offer access to things like the status registers of the CPU. The coders needed exact cycle timings for certain tasks. Direct access to timers and interrupt handlers, some which may change from scene to scene or even frame to frame. The assembly language developer can write code that "knew" exactly what state it was in at all times, and was coded appropriately.
Any high level value that C could have offered was lost not just in lack of access to the CPU, but also just in terms of longer turn arounds and development cycles. C is expensive to compile compared to assembly, and back then, yes, this mattered. A good macro assembler readily takes the sting of using assembly by letting the developer add in higher level constructs (working with structures, working with collections, looping, branching, etc.) or even small DSLs written in macros.
So, in the end, the cost of C wouldn't have brought enough value to the table for a professional game developer on such limited systems back then.
C is compiled by a compiler. Assembly languages are not compiled, they are assembled by an assembler. The difference is that assembly mnemonics map one-to-one with binary opcodes, whereas a compiler has much more work to do than just substituting opcodes for mnemonics.
– LawrenceC
Jan 18 at 19:33
Even without "a good macro assembler", a program that's a few thousand instructions long isn't too bad for working on manually at the CPU instruction level. You can easily get to that point with just a thousand or so lines of reasonably sparse (as opposed to compact) C. The hard part is likely going to be cramming whatever actual logic you need into the available memory anyway, whether one uses C or assembler.
– a CVn
Jan 22 at 10:06
add a comment |
C didn't have anywhere near the popularity and ubiquity that it does today. As has been mentioned elsewhere, the 6502 is a crummy target for a C compiler, notably with it's sparse, 8 bit register set.
Recall the sparse architecture of the machine: 128 bytes of RAM and 4K of ROM. A 4K assembly language program, with several 8-bit, and a few 16-bit counters or pointers, is not an arduous amount of code for an assembly language programmer. (Yes, there were banked cartridges later, but most of it was for data rather than actual code.)
One of the key values of a language like C is also portability, something that was simply not a concern here.
Finally, games on systems like the Atari were notorious for their optimizations, and other shenanigans and contortions the developers went through to get their titles crammed in to these creaky, slow boxes. Leveraging the underlying CPU to their full potential required 100% access to it, something that C did not offer. C does not offer access to things like the status registers of the CPU. The coders needed exact cycle timings for certain tasks. Direct access to timers and interrupt handlers, some which may change from scene to scene or even frame to frame. The assembly language developer can write code that "knew" exactly what state it was in at all times, and was coded appropriately.
Any high level value that C could have offered was lost not just in lack of access to the CPU, but also just in terms of longer turn arounds and development cycles. C is expensive to compile compared to assembly, and back then, yes, this mattered. A good macro assembler readily takes the sting of using assembly by letting the developer add in higher level constructs (working with structures, working with collections, looping, branching, etc.) or even small DSLs written in macros.
So, in the end, the cost of C wouldn't have brought enough value to the table for a professional game developer on such limited systems back then.
C didn't have anywhere near the popularity and ubiquity that it does today. As has been mentioned elsewhere, the 6502 is a crummy target for a C compiler, notably with it's sparse, 8 bit register set.
Recall the sparse architecture of the machine: 128 bytes of RAM and 4K of ROM. A 4K assembly language program, with several 8-bit, and a few 16-bit counters or pointers, is not an arduous amount of code for an assembly language programmer. (Yes, there were banked cartridges later, but most of it was for data rather than actual code.)
One of the key values of a language like C is also portability, something that was simply not a concern here.
Finally, games on systems like the Atari were notorious for their optimizations, and other shenanigans and contortions the developers went through to get their titles crammed in to these creaky, slow boxes. Leveraging the underlying CPU to their full potential required 100% access to it, something that C did not offer. C does not offer access to things like the status registers of the CPU. The coders needed exact cycle timings for certain tasks. Direct access to timers and interrupt handlers, some which may change from scene to scene or even frame to frame. The assembly language developer can write code that "knew" exactly what state it was in at all times, and was coded appropriately.
Any high level value that C could have offered was lost not just in lack of access to the CPU, but also just in terms of longer turn arounds and development cycles. C is expensive to compile compared to assembly, and back then, yes, this mattered. A good macro assembler readily takes the sting of using assembly by letting the developer add in higher level constructs (working with structures, working with collections, looping, branching, etc.) or even small DSLs written in macros.
So, in the end, the cost of C wouldn't have brought enough value to the table for a professional game developer on such limited systems back then.
answered Jan 3 at 4:35
Will HartungWill Hartung
3,9361022
3,9361022
C is compiled by a compiler. Assembly languages are not compiled, they are assembled by an assembler. The difference is that assembly mnemonics map one-to-one with binary opcodes, whereas a compiler has much more work to do than just substituting opcodes for mnemonics.
– LawrenceC
Jan 18 at 19:33
Even without "a good macro assembler", a program that's a few thousand instructions long isn't too bad for working on manually at the CPU instruction level. You can easily get to that point with just a thousand or so lines of reasonably sparse (as opposed to compact) C. The hard part is likely going to be cramming whatever actual logic you need into the available memory anyway, whether one uses C or assembler.
– a CVn
Jan 22 at 10:06
add a comment |
C is compiled by a compiler. Assembly languages are not compiled, they are assembled by an assembler. The difference is that assembly mnemonics map one-to-one with binary opcodes, whereas a compiler has much more work to do than just substituting opcodes for mnemonics.
– LawrenceC
Jan 18 at 19:33
Even without "a good macro assembler", a program that's a few thousand instructions long isn't too bad for working on manually at the CPU instruction level. You can easily get to that point with just a thousand or so lines of reasonably sparse (as opposed to compact) C. The hard part is likely going to be cramming whatever actual logic you need into the available memory anyway, whether one uses C or assembler.
– a CVn
Jan 22 at 10:06
C is compiled by a compiler. Assembly languages are not compiled, they are assembled by an assembler. The difference is that assembly mnemonics map one-to-one with binary opcodes, whereas a compiler has much more work to do than just substituting opcodes for mnemonics.
– LawrenceC
Jan 18 at 19:33
C is compiled by a compiler. Assembly languages are not compiled, they are assembled by an assembler. The difference is that assembly mnemonics map one-to-one with binary opcodes, whereas a compiler has much more work to do than just substituting opcodes for mnemonics.
– LawrenceC
Jan 18 at 19:33
Even without "a good macro assembler", a program that's a few thousand instructions long isn't too bad for working on manually at the CPU instruction level. You can easily get to that point with just a thousand or so lines of reasonably sparse (as opposed to compact) C. The hard part is likely going to be cramming whatever actual logic you need into the available memory anyway, whether one uses C or assembler.
– a CVn
Jan 22 at 10:06
Even without "a good macro assembler", a program that's a few thousand instructions long isn't too bad for working on manually at the CPU instruction level. You can easily get to that point with just a thousand or so lines of reasonably sparse (as opposed to compact) C. The hard part is likely going to be cramming whatever actual logic you need into the available memory anyway, whether one uses C or assembler.
– a CVn
Jan 22 at 10:06
add a comment |
Thanks for contributing an answer to Retrocomputing Stack Exchange!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fretrocomputing.stackexchange.com%2fquestions%2f8640%2fwere-some-atari-2600-games-written-in-c%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
VcSsCcrb6SH,ZC,GkqQ9oBD8nqNFNAAe,EPSzHZPJxeM,nXPc,CzBrhvFnJd2K5wB
1
I'm willing to wager that this is not so; 6502 is ill-suited for C because of its limited-range hardware stack, and the 2600 even more so because its memory limit restricts the stack even further than that. But I've no evidence whatsoever. And bataribasic.com seems to run and run.
– Tommy
Jan 2 at 18:17
Not C, but some Atari 2600 homebrew is written in another high-level language called Batari BASIC. Maybe this is what your friend was thinking of?
– traal
Jan 2 at 18:46
5
@Tommy You don't need a call stack if you program in a sufficiently limited subset of "C". Keil C51 is not exactly "C", but it's pretty darned close, and it is capable of targeting systems that have only 128 bytes of RAM. It has an option to use activation records that are statically allocated at compile time instead of allocating them from a stack at run-time.
– Solomon Slow
Jan 2 at 19:38
@SolomonSlow the only potential issue (other than recursion, obviously) being that static allocation of activation records may even be a worse thing with only 128 bytes total, as it presumably makes the RAM footprint proportional to the number of functions you've written rather than the complexity of your call chain?
– Tommy
Jan 2 at 22:30
@Tommy: "Static allocation" may involve overlapping the activation records of functions that can not be executing at the same time, given the call graph.
– Henning Makholm
Jan 3 at 0:30