Selling 'Homebrew' games in Rom form?

[+Gemintronic]

No forced brackets { }

 

How do you propose to handle conditional multi-line statements? Appending something like ':' on each line is possible but in my mind its just easier to open a pair of curly brackets, put in what you need and then close them.

 

I always assumed one statement ends in a carriage return.

IF .. THEN .. ELSE on the same line or tab/white space delimited multi-lines.

 

It's a convenience expected in most 4GLs. FoxPro, Visual Basic, etc..

 

The programmer should not be used to help parse things for the language - quite the opposite.

Edited June 29, 2012 by theloon

[GroovyBee]

revolutionika: You are da man! This is another one of your threads that has been taken over by the programmers .

[GroovyBee]

I always assumed one statement ends in a carriage return.

IF .. THEN .. ELSE on the same line or tab/white space delimited multi-lines.

 

But you need an "endif" construct if you don't use a multi-line terminator. In which case just replace "THEN" with a "{" and "ENDIF" with a "}". Short and sweet .

[+Gemintronic]

I'll have to differ to your wisdom GroovyBee. I might not understand it now but I'll cache it for processing later!

 

I guess what I meant earlier is that if C were available for the INTV one could use your own libraries that can target both PC and INTV. Both targets would have the same constraints/capabilities then. Compile the iOS app or compile the INTV binary. Test the mass market first then go for the gold.

[GroovyBee]

I'll have to differ to your wisdom GroovyBee. I might not understand it now but I'll cache it for processing later!

 

Lets say you had an alien in a game on a fixed trajectory and you wanted him to move if the player wasn't dead your language syntax choices could be :-

 

if playerDead!=0 then alienX=alienX+1: alienY=alienY+1

 

or

 

if playerDead!=0 then

alienX=alienX+1

alienY=alienY+1

endif

 

where != is your language equivalent of the inequality operator.

 

In my mind the "if then endif" construct could easily be replaced with "if {}".

[catsfolly]

The Z80 and 6502 processors were used in millions of home computers, so there was a great interest in developing software for them. So, C compilers were developed.

 

The CP1610 processor was used only in the Intellivision (and one other game machine?), so there are no C or Basic compilers, just one assembler.

 

Mathematically speaking, it looks like the set of people who

 

1. Have compiler writing skills, and

2. Have the time and inclination to write compilers in their spare time for fun, and

3. Are interested in Intellivision development

 

appears to be zero. :-)

 

I think a high level language for the Intellivision would lead to more development, and more people getting involved in Intellivision programming.

 

 

Catsfolly

 

Actually, that number rounds up to 2, not zero.

 

I started some time ago working on a higher-level language for the Intellivision called SPLINT (Simple Programming Language for INTellivision), that was C-like in syntax. It would depend on a run-time engine, like the EXEC but on steroids, that would provide facilities for sound and sprite. Combined with a flexible development framework, it would simplify game programming for the Intellivision. (The run-time engine would be called SPLINTer, for SPLINT execution run-time).

 

Joe and I started working on it almost two years ago, and he went some way into building pieces of the compiler, based on an old project of his. The project was frozen when Christmas Carol came along and took over my life, but I intend to continue on it.

 

Eventually, most of the ideas for SPLINT filtered down to P-Machinery 2.0, which is still in development--slowly but surely.

 

That's one. Then there's Tim in the INTV-Prog list that started working on a C compiler for the Intellivision. Joe and I were hoping to work that compiler into SPLINT.

 

It is at a slow pace, but these things will happen. It is my goal to provide some sort of platform to make the Intellivision more attractive and accessible to the casual programmer. I may not succeed, but I'm sure others will come that will do.

 

-dZ.

I had no idea these activities were going on. Good news.

 

I've toyed around with writing some C libraries to allow Intellivision game prototyping in C on the PC.

 

Essentially, the libraries would contain arrays called something like gram[] and grom[] and stic[] and backtab[].

The C program could fill up these arrays with the appropriate values, and then call a magic "generate_intv_display()" routine, which would

read all the arrays and update a PC window (using SDL) with a picture that would match what the Intellivision would do.

(This is about 1/1000th of an emulator).

 

The result would be, code could be written in C to prototype Intellivision games, and the games could be viewed on the PC.

 

Of course, there is no mechanism in the scheme to prevent the programmer from writing code that takes advantage of the 1000x processing speed of the PC to do things that would never work on the Intellivision. But I thought it would be a useful tool to try out ideas to see what they would look like without writing a lot of cp1610 code.

 

Maybe such a tool could also help us investigate what C-language Intellivision programming could/should be like....

 

Catsfolly

[+Gemintronic]

If {} is an artificial construct that trades natural language for easier parsing. Coming from a BASIC background I appreciate natural language more than constructs to make code look structured.

 

This is just my view and it may admittedly be a narrow one

Edited June 29, 2012 by theloon

[GroovyBee]

If {} is an artificial construct that trades natural language for easier parsing. Coming from a BASIC background I appreciate natural language more than constructs to make code look structured.

 

I'm only saying that "if {}" is better short hand in my opinion than writing "if ... then <statement 1> : <statement 2>" because once you get to say 4 or 5 statements on a single you start needing to introduce an artificial line break character so that you can lay things out in a text editor in your own style.

[+DZ-Jay]

If {} is an artificial construct that trades natural language for easier parsing. Coming from a BASIC background I appreciate natural language more than constructs to make code look structured.

 

This is just my view and it may admittedly be a narrow one

 

Actually, {} are a more natural fit as an enclosure symbol, leveraging their cognitive familiarity in their use in natural language. This is the same reason that parentheses are used in mathematics.

 

They are also more concise than, say, typing or reading "begin/end."

 

Programming is the symbolic manipulation of logic, and making a programming language too verbose, limits or impairs its understanding. I say this as a long time Pascal and Delphi programmer. I have a special place in my heart for Pascal, and I love it to death, but damn! I hate having to deal with BEGIN and END on almost every single construct. It is not as visually distinctive as enclosing brackets are.

 

dZ.

[+Gemintronic]

I think I'm convinced. I'll just go back to playing my new homebrew..

http://www.atariage.com/forums/index.php?app=core&module=attach&section=attach&attach_id=249938

Edited June 29, 2012 by theloon

[intvnut]

Oy, language syntax bikeshedding. The whole "curly" vs. "no-curly" could be papered over with a preprocessor! That's scarcely the hard part...

 

I've programmed in a dozen different BASIC dialects (from TI BASIC thru QBASIC thru ECS BASIC), Pascal, C, C++, Perl, Bourne Shell and can at least read a little Python and FORTRAN. That's on top of knowing about 15 different assembly languages.

 

Innovating on the spelling of if/then/else is... well... not really the place to innovate. It's debating whether you want the red two-door with the spoiler vs. the blue four-door with the hood scoop in a car, but totally forgetting about the engine and transmission, let alone whether it'll get you from point A to point B. :-)

 

And if you hate the curly brackets in C's if statement so much, don't use them. This is perfectly valid C, extracted and lightly modified from jzIntv:

   /* -------------------------------------------------------------------- */
   /*  Sanity checks:                                                      */
   /* -------------------------------------------------------------------- */
   if (!rom)                   return -1;  /* Valid ROM pointer?           */
   if (addr + len > 0x10000)   return -1;  /* addr + len doesn't wrap?     */

   /* -------------------------------------------------------------------- */
   /*  Next, if any actual data was provided, memcpy() it into the ICart   */
   /* -------------------------------------------------------------------- */
   if (data)
       set_attr |=  ICARTROM_PRELOAD, /* Force these pages to be preloaded */
       clr_attr &= ~ICARTROM_PRELOAD, /* Force these pages to be preloaded */
       memcpy(rom->image + addr, data, len * sizeof(uint_16));

 

Yep, if you want to continue a statement, the good ol' oft-forgotten comma operator works just fine in most cases. You only need the braces if you want to put another control construct in there (such as another if statement or a for loop or the like...) But, since you're channeling BASIC, you could just use GOTOs and avoid nested control constructs. ;-)

 

Or, read up on Bournegol.

[intvnut]

And besides, once there's a C compiler, you can use any one of these fascinating language translators to open up entire new worlds of Inty retroprogramming. Or if you prefer something more modern... ;-)

[GroovyBee]

I've programmed in a dozen different BASIC dialects (from TI BASIC thru QBASIC thru ECS BASIC), Pascal, C, C++, Perl, Bourne Shell and can at least read a little Python and FORTRAN. That's on top of knowing about 15 different assembly languages.

 

I see your BASICs and Bourne Shell and I'll raise you COBOL, FORTH, PHP and JavaScript .

[+DZ-Jay]

Oy, language syntax bikeshedding. The whole "curly" vs. "no-curly" could be papered over with a preprocessor! That's scarcely the hard part...

 

Aww... why do the programmers always need to come into these threads and ruin all the fun?

 

LOL!

Edited June 30, 2012 by DZ-Jay

[Rev]

What about Moe and Shemp?

[catsfolly]

What about Moe and Shemp?

And Larry!!!!

[intvnut]

I see your BASICs and Bourne Shell and I'll raise you COBOL, FORTH, PHP and JavaScript .

 

I wasn't going to mention MS-DOS batch, but since you brought up PHP, I see we're stretching the definition of programming language. ;-)

[atarilovesyou]

One of the problems that i have run into getting the boxes printed for Elektronite, is that the smaller printers consider the job to be too big and complicated, and the larger printers consider the job too small and unimportant.

 

I have been fortunate to find a printing company that takes me seriously and values my business. They are working with another printing company, who is actually doing the printing, who has been just as great. The president of the second printing company, actually met with me to answer my questions and find out exactly what I was looking for. And, this is on a small fry order.....nevertheless, it involves money in the thousands.....

 

I don't expect to get rich, but there is nothing wrong with serving the market in a professional way. I don't think that making games for classic systems is strictly for the hobbyists. Sure, there are classic video game authors who are just chuffed to be able to have their game played, but there are others who want to be able to fulfill their dream of making a living doing what they love.

 

I like your attitude and wish you luck! If there were a group of dedicated programmers looking to do what you're doing for the VCS or NES, I'd fully support them. I have no problem with buying physical carts. This is a hobby, but the effort required to put out a game is immense...at least for the good ones (and even the not so good ones!). I don't really care about ROMs; I want to buy a game and enjoy it the way I did way back when. From what I've read in these posts, it seems like the developers sell out of their physical copies. They don't get rich, but perhaps the small margin they do make goes into the next titles and maybe a little on the side. Definitely not enough to quit your day job, but not too shabby.