C compiler for Intellivision

[Retro Rogue]

I second the vote for a C compiler. It'd have to be very optimized of course, but as a coder I think C would be the next best thing to assembly.

[+Gemintronic]

If something like BCX was whipped up we wouldn't have to choose between BASIC and C

http://bcx-basic.sourceforge.net/

[fsuinnc]

I'm not proud of it, but at my age I find it difficult to learn new stuff and unfortunately for me, I came along in the FORTRAN, Pascal era and was off working and raising kids when C, etc. became popular. I always thought I would pick up the new stuff but never have. So for me something similar to batari Basic would be great. I love playing with it and would love something similar for the Intellivision. I think it would open things up to a lot of people just like batari basic has for the A2600.

 

However, If a C compiler is created I think it would be great too. Maybe I could make the effort to learn some and if I don't it still allows many more people to program on the intellivision and that benefits me greatly since I get to play more games.

 

also, good luck to all in developing any or all and thanks much. (looking forward P-Machinery 2.0 too).

[+DZ-Jay]

I'm not proud of it, but at my age I find it difficult to learn new stuff and unfortunately for me, I came along in the FORTRAN, Pascal era and was off working and raising kids when C, etc. became popular. I always thought I would pick up the new stuff but never have. So for me something similar to batari Basic would be great. I love playing with it and would love something similar for the Intellivision. I think it would open things up to a lot of people just like batari basic has for the A2600.

 

However, If a C compiler is created I think it would be great too. Maybe I could make the effort to learn some and if I don't it still allows many more people to program on the intellivision and that benefits me greatly since I get to play more games.

 

also, good luck to all in developing any or all and thanks much. (looking forward P-Machinery 2.0 too).

 

 

I agree that something like Batari BASIC for the Intellivision would be great. My contention is that the magic in Batari BASIC is not in the BASIC part, but in the Batari framework and model. Providing built-in kernels and wrappers to do the heavy lifting is what makes it simpler to adopt and lowers the barriers to entry for many people.

 

When you consider that, then the language is actually not that important.

 

A C compiler will be a good thing, of course. However, I assert that it won't be the magic bullet that a lot of people are hoping it is. The hard part of making Intellivision games is not really that it is in Assembly language. Sure, that's part of it, albeit a small one. The truly hard part is in not having any abstractions on the most mundane and arcane idiosyncrasies of the hardware. It's having to re-invent the wheel from scratch... Every. Single. Time.

 

For instance, if you want to display a sprite, today you need to understand the VBLANK interrupt request and its timing, the STIC and its registers, the way that GRAM encodes MOB images, and the way all of this works together. It would be a hell of a lot easier if you could just do something like:

    REM In BASIC
    LET SPR1.X = 100
    LET SPR1.Y = 100
    LET SPR1.IMG = GRAM(1)
    SHOW_SPR(SPR1)

How much different is that from this?

    // in C
    spr1.x = 100;
    spri1.y = 100;
    spr1.img = gram(1);
    show_spr(spr1);

Or even from this?

    ; in Assembly (with macros)
    set_spr_pos(spr1, 100, 100)
    set_spr_gram(spr1, 1)
    show_spr(spr1)

Of course, this is just an oversimplified example, for illustration purposes.

-dZ.

Edited October 20, 2013 by DZ-Jay

[Mr SQL]

 

 

I agree that something like Batari BASIC for the Intellivision would be great. My contention is that the magic in Batari BASIC is not in the BASIC part, but in the Batari framework and model. Providing built-in kernels and wrappers to do the heavy lifting is what makes it simpler to adopt and lowers the barriers to entry for many people.

 

When you consider that, then the language is actually not that important.

 

A C compiler will be a good thing, of course. However, I assert that it won't be the magic bullet that a lot of people are hoping it is. The hard part of making Intellivision games is not really that it is in Assembly language. Sure, that's part of it, albeit a small one. The truly hard part is in not having any abstractions on the most mundane and arcane idiosyncrasies of the hardware. It's having to re-invent the wheel from scratch... Every. Single. Time.

 

For instance, if you want to display a sprite, today you need to understand the VBLANK interrupt request and its timing, the STIC and its registers, the way that GRAM encodes MOB images, and the way all of this works together. It would be a hell of a lot easier if you could just do something like:

    REM In BASIC
    LET SPR1.X = 100
    LET SPR1.Y = 100
    LET SPR1.IMG = GRAM(1)
    SHOW_SPR(SPR1)

How much different is that from this?

    // in C
    spr1.x = 100;
    spri1.y = 100;
    spr1.img = gram(1);
    show_spr(spr1);

Or even from this?

    ; in Assembly (with macros)
    set_spr_pos(spr1, 100, 100)
    set_spr_gram(spr1, 1)
    show_spr(spr1)

Of course, this is just an oversimplified example, for illustration purposes.

-dZ.

Excellent points dZ! The Framework is more important than the language choice - weather coding in asm or BASIC, the bB Framework provides high level objects.

 

If the P-Machinery Framework exposes similar high level objects the next step might be to write a BASIC compiler to allow Developers to work with those high level objects and translate BASIC programming logic into asm.

 

I've found the bB compiler can be made to work with the additional (undefined to bB) high level objects in my ASDK Assembly Framework, perhaps there is a Tiny BASIC compiler for the Intellivisions processor that could be utilised in similar fashion instead of writing one from scratch.

[First Spear]

I am looking to get into Intellivision development myself. I hunted through the stuff on this forum last night and the grandson-of-the-wiki, and finally got "hello world" to work. That was a great feeling!

 

I now want to go to the next level, but getting hip-deep into 1600 ASM is going to be a real time-suck (ie, barrier) for me.

 

It would be super-cool if there was a compiler or assembler or wrappers that would let someone developers use Eclipse and have their work distill into a .rom that would run on an emulator (hey let Eclipse contain/launch jzIntv also the same way it does for Tomcat, etc). I think that a set of cross-assembly/compilations for Eclipse or Visual Studio would be a *huge* benefit for those of us that want to get into this.

 

Take a look at

http://forum.6502.org/viewtopic.php?f=1&t=2218

the barrier to entry there is really low.

 

 

It is in no way fair to expect the current Intv leaders and mavericks to stop what they are doing and start to write a development framework for the rest of us. However, if you guys that actually know what you're doing can "package" your successful stuff for the rest of us, doors will open....

Edited November 24, 2013 by Tinty

[+DZ-Jay]

One step at a time. One step at a time.

[LidLikesIntellivision]

I have a question!

 

Is it possible to mod an Intellivision to replace the original exec for new libraries (maybe including all or some of p-machinery in such a way you:

1) can call the new library functions in the same way you would call the original exec? and if afirmative

2) you will have some benefits of new libraries (fast input response!) working in old games which used the original exec routines?

[catsfolly]

I have a question!

 

Is it possible to mod an Intellivision to replace the original exec for new libraries (maybe including all or some of p-machinery in such a way you:

1) can call the new library functions in the same way you would call the original exec? and if afirmative

2) you will have some benefits of new libraries (fast input response!) working in old games which used the original exec routines?

Good questions. 100 bonus points for thinking outside the box!

 

Physically - modding an Intellivision to replace the exec would be a pain, because the exec is stored in some custom GI chip that is probably soldered into the motherboard - so someone would have to reverse engineer this chip and make a replacement circuit, and much soldering would be involved.

Fortunately, I think all the memory in the Intellivision is bank-switchable, so in theory a multicart could be set up to use an exec image stored in the multicart instead of the one in the Intellivision. No mod required.

 

Software-wise. Hmmm. The good thing about the exec was that it saved memory in the cartridge.

If a 2600 programmer wanted his (or her) game to play music, or display "GAME OVER" on the screen, they had to include the code to do these things in the cartridge (including the images for the letters in "GAME OVER".) So this took space away from the game code in their 4k (or 2k) game cartridge.

On the Intellivision, the exec provided these services, so the programmers had more room for sophisticated gameplay in the cartridge.

 

But to take full advantage of the exec a game had to use the exec game structure. This structure was designed to accommodate every type of game - from chess to baseball to Astrosmash. So it did a little of everything. It did so many things that it took 3 video frames to complete one loop. On a NTSC system, the video updated 60 times a second, but a game using the exec updated the game 20 times a second. This is why some of the old games seemed sluggish.

 

So, it's not true that the exec was badly written and a rewrite would speed things up. The general purpose nature of the exec makes it slow, and it would be hard to change it and "improve" it and still make it compatible with the old games.

 

Newer Mattel games (and all modern games) ignore the exec and include routines that run at 60 frames a second and do only the operations needed for that particular game.

 

Because memory is cheap now, it is no big deal to include p-machinery and Joe's utilities and other code in every rom cartridge.

 

Does this help?

 

Catsfolly

[+Gemintronic]

..damn! I got all excited and thought the next post would be a link to the toolchain ^_^

[+DZ-Jay]

Good questions. 100 bonus points for thinking outside the box!

 

Physically - modding an Intellivision to replace the exec would be a pain, because the exec is stored in some custom GI chip that is probably soldered into the motherboard - so someone would have to reverse engineer this chip and make a replacement circuit, and much soldering would be involved.

Fortunately, I think all the memory in the Intellivision is bank-switchable, so in theory a multicart could be set up to use an exec image stored in the multicart instead of the one in the Intellivision. No mod required.

 

Software-wise. Hmmm. The good thing about the exec was that it saved memory in the cartridge.

If a 2600 programmer wanted his (or her) game to play music, or display "GAME OVER" on the screen, they had to include the code to do these things in the cartridge (including the images for the letters in "GAME OVER".) So this took space away from the game code in their 4k (or 2k) game cartridge.

On the Intellivision, the exec provided these services, so the programmers had more room for sophisticated gameplay in the cartridge.

 

But to take full advantage of the exec a game had to use the exec game structure. This structure was designed to accommodate every type of game - from chess to baseball to Astrosmash. So it did a little of everything. It did so many things that it took 3 video frames to complete one loop. On a NTSC system, the video updated 60 times a second, but a game using the exec updated the game 20 times a second. This is why some of the old games seemed sluggish.

 

So, it's not true that the exec was badly written and a rewrite would speed things up. The general purpose nature of the exec makes it slow, and it would be hard to change it and "improve" it and still make it compatible with the old games.

 

Newer Mattel games (and all modern games) ignore the exec and include routines that run at 60 frames a second and do only the operations needed for that particular game.

 

Because memory is cheap now, it is no big deal to include p-machinery and Joe's utilities and other code in every rom cartridge.

 

Does this help?

 

Catsfolly

 

 

Catsfolly, I respectfully disagree with part of your last point. I agree that the EXEC was not "badly written": it was written to fit the known constraints, and it was written simultaneously as the very first game that would use it. This means that not only was the programmer, David Rolf, tasked with writing a generalized operating system for his game (Major League Baseball, if I recall), he had to also dream up all the fancy stuff that other future games may want to do. To compound this inscrutable problem was the fact that the video game industry was nascent, and certain game-play patterns and technologies had not even been invented yet! This means that along with all the complexities mentioned already, the EXEC needed to define a game programming framework, when such a thing was still alien to most.

 

That is a huge task, and the EXEC was a fantastically appropriate and fitting solution to that problem. Although as a modern-day home-brewer it's easy to take cheap shots at the primitive or seemingly crude functionality provided by the EXEC, I admire immensely the work that Mr. Rolf put in it, precisely because I appreciate the almost insurmountable task he had at hand.

 

So, my disagreement with you is that a rewrite would not speed things up. Today we have 30 years of accumulated experience and technology improvements (both in hardware and software techniques), not to mention an entire family of genres and game-play concepts developed throughout the past few decades; that can allow an operating system similar to the EXEC be generalized for most games AND simultaneously be faster and efficient.

 

This is one of the things I am trying to accomplish with the new version of P-Machinery. This is not to say that P-Machinery or such things would be superior to the EXEC. They would just have the grace and privilege of 30 years of research and development that Mr. Rolf and the rest of the original engineers had not. So, if in fact I ever complete P-Machinery, and if in fact it ever proves useful, I would never claim it as a replacement to the EXEC, or a "better version" of it, since in a sense I cheated with the hind-sight and field of vision provided by standing on the shoulders of giants.

 

However, to LidLikesIntellivision's original question, P-Machinery wouldn't fulfill that role, as it is not intended to be compatible with the EXEC. Moreover, although it may be technically possible to replace the exec--in-cartridge ROM--with a compatible but re-written version, in my opinion this would be a waste of resources. It would be better to concentrate on making new tools without having to constraint yourself artificially to limitations and design decisions made 30 years ago. Also in my opinion, it would be more productive to make a new operating system and re-develop the games or enhance them with new capabilities available today. Or better yet--produce entirely new titles!

 

-dZ.

Edited December 19, 2013 by DZ-Jay

[LidLikesIntellivision]

Does this help?

 

Catsfolly

Thanks for answering.

 

@DZ-Jay, hm maybe not 'better' taking history in account. I understand your point.

But... If p-machinery could ever evolve into a full modern substitute for exec (and including compatibility with old games either in a mod or in a multicart), then it would be certainly a better general purpose for Intellivison.

Putting in a multicar has the advantage of preserving old games as they are!

 

BTW, thinking out of the box is much easier when you're really out of the programming world!

Today, I've done my very first step. Not only in Intellivision programming but also in assembly.

[+DZ-Jay]

Liduario,

 

I can tell you categorically that P-Machinery won't be compatible with older games. That's never been its purpose and it is outside its scope.

 

I also assert that there is little interest in making a plug-in replacement of the EXEC for older games. Like Catsfolly mentioned, the EXEC is more than just a library of routines, but an entire philosophy and approach at making games, and using it necessarily forces the programmer to design his game within its paradigm.

 

One of the liberties we can take in modern home-brews is that we do not have to adhere to a programming model designed at the dawn of video games, when "game programming model" wasn't even a thing. Like I said, it wasn't a bad design or model, just very primitive.

 

I find it odd that we're discussing sticking to those techniques in a thread about developing a C compiler. The thread is a tacit admission that the low-level and primitive tools we gave today are inadequate--and these have been created 30 years after the fact!

 

dZ.

[catsfolly]

dZ -

 

When I said a "rewrite would not speed things up" - I meant a rewrite as Liduario described it - a rewrite that was 100% compatible with the old exec and could thus speed up the old programs.

 

Certainly a new exec could be written that would be faster and more efficient than the old exec, especially if it was allowed to take up more than 4k of memory. But this new exec would have different calls and functions and structures from the old exec...

 

Catsfolly

Edited December 19, 2013 by catsfolly

[LidLikesIntellivision]

Dz, I understand. I didn't see your last paragraph in your first post before.

 

Anyway, I like to ask some different things when learning.

As in the IntyOs as an interface for a multicart. That IntyOs caught my eyes!

Many times I don't know the implications of what Im thinking. But I like to search for new possibilities.

[+DZ-Jay]

dZ -

 

When I said a "rewrite would not speed things up" - I meant a rewrite as Liduario described it - a rewrite that was 100% compatible with the old exec and could thus speed up the old programs.

 

Certainly a new exec could be written that would be faster and more efficient than the old exec, especially if it was allowed to take up more than 4k of memory. But this new exec would have different calls and functions and structures from the old exec...

 

Catsfolly

Catsfolly,

 

I understand. I missed the last part of your post at first, which prompted me to update mine with the last paragraph; essentially agreeing with you.

 

That said, my overarching point and theme throughout this thread (not necessarily related to Liduario's question), is that the EXEC is not slow and limited because it was generalized; it is so because of the constraints in experience, knowledge, and technology imposed on the designers and engineers at the time. We don't have many of those any more.

 

dZ.

[+Gemintronic]

Instead of a new EXEC one could develop a runtime engine that reads bytecode-like data appended to the end of the ROM. Something between chip-8 and, say, GameMaker for the PC.

[+DZ-Jay]

Instead of a new EXEC one could develop a runtime engine that reads bytecode-like data appended to the end of the ROM. Something between chip-8 and, say, GameMaker for the PC.

Go for it!

 

dZ.

[+Gemintronic]

I wish Since C and BASIC is as low as I currently go the first prototype would be on the Atari 2600. Still, if I can do it there then the INTY should be no problem!