21 replies to this topic

[Pixelboy]

This thread is devoted to the BasicVision programming language, which is aimed at the development of new homebrew ColecoVision games. I have created a small web site which contains information about the language and its general objectives. This information is far from complete, but I think it gives a pretty good idea of what the language syntax is like.

http://teampixelboy.com/basicvision

I've decided that now is a good time to get this project started, mostly because I'm at a point where I need to determine what programming tools I'm going to use to realize my own personal CV game projects. On one hand, I could go with SDCC and the Coleco library, which is already generally well-supported, but on the other hand, I've always wanted to create my own parser/compiler from scratch, and this seems like the perfect opportunity to do just that.  

What I want to do, in essence, is to create an application that can parse and translate BasicVision source code into Z80 assembly source code, which can then be compiled with well-known compilers like TASM. That seems the logical way to do it, in terms of debugging and also to properly monitor the evolution of the BasicVision language over time.

I'm hoping to get some help from the CV homebrew community to guide me along. I'm confident I can do the BasicVision language parser myself (I'll probably do it in Java) but to implement the other part of the core application, which generates ASM source code, I'll need to learn Z80 assembly programming. I believe this project is actually a cool way to learn the Z80's assembly language, because I will be able to learn it in a gradual manner, by devising code snippets in the BasicVision language, and then studying how to translate such snippets in assembly language. At this point, I'm hoping to find a "Z80 mentor" to explain the basics (as well as the not-so-basic stuff) to me.

Once I have the core compiler running (which will likely take several months) the next phase of the project will be to design a proper IDE, with integrated graphic and sound editors. But right now, I want to concentrate on the BasicVision language itself, and the parser/compiler.

You are all more than welcome to post comments and questions in this forum thread, as well as to discuss programming issues. As I said, I'm barely starting with this, and I'm sure the BasicVision language will need to be modified and improved over time, especially in the short term.

[yuppicide]

Sounds great! I do bAtari Basic to make 2600 games (and very little 5200 basic too), so I'd definitely jump in and try something ColecoVision if it were just as easy for me.

[Pixelboy]

yuppicide, on Sun Feb 21, 2010 3:07 PM, said:

Sounds great! I do bAtari Basic to make 2600 games (and very little 5200 basic too), so I'd definitely jump in and try something ColecoVision if it were just as easy for me.

Well, for now, perhaps you could have a quick look at the design text file (found on the web site linked above) and tell me if it looks easy enough to learn.  

[GroovyBee]

How about something like a BasicVision to "C" converter and then use SDCC to compile natively? That way if BASIC was too slow for parts of your game you could code them in "C" and if that was too slow you could write hand crafted assembly language. Its the best of all worlds then.

[youki]

i had in mind something like that but not specialy dedicated to the colecovision.

My Idea was to make a kind of language very easy to create video game for old console/computer.

The language (that could be BASIC) would have very generic primitive to manage input, sprite, display  that are not dependent of the target machine.

Then from the IDE , once your program done you could generate your game for the plateform you want.

The generation would "compile" your code according to the machine of your choice.

The goal being to do a very simple language that allow to make easly simple game.  Not something too ambitious that would push the target machines to their limit. But just basics functions :
display images.
define and move "sprite" (hardware or software depending of target machine possibilites).
Manage input.
Play sounds.

[Inky]

What kind of "syntax" so to speak, are you going to use? Visual Basic like OO structure, or bring it "old school" and be more like Coleco's own "SmartBASIC" for the ADAM (with line numbers and so on)

[Pixelboy]

Inky, on Mon Feb 22, 2010 9:13 AM, said:

What kind of "syntax" so to speak, are you going to use? Visual Basic like OO structure, or bring it "old school" and be more like Coleco's own "SmartBASIC" for the ADAM (with line numbers and so on)

There's a downloadable text file with general explainations about the BV language on the official web site. It's something like Basic, but without line numbers. Definately old-school.  

[Jess Ragan]

Just promise us you'll give us more than the Vectrex BASIC guy did.  What a maddening cocktease that was!  He gave us a command list but no actual software... not even an alpha!

[Bill Loguidice]

I truly hope this evolves. Stuff like this is the perfect way to get even more new software developed if it's at least in the range of power of something like Batari Basic.

[Pixelboy]

Jess Ragan, on Mon Feb 22, 2010 2:47 PM, said:

Just promise us you'll give us more than the Vectrex BASIC guy did.  What a maddening cocktease that was!  He gave us a command list but no actual software... not even an alpha!

One thing I need to do is to try to convert my Sudoku homebrew game from C language to BasicVision. I'm sure this simple exercise will show certain things that need to be added or adjusted in the proposed language. Beyond that, the first real step will be to create a language parser application. Probably a simple command-line prototype, no GUI or anything fancy like that. The difficult (yet still kinda fun) part will be to make the parser catch syntax and logic errors correctly. Once the parser is done and works properly, I guess the next phase will be to start studying Z80 assembly (reading books, coding simple programs, etc.). Definately a long-term project, but oh so promising.  

Bill_Loguidice, on Mon Feb 22, 2010 3:22 PM, said:

I truly hope this evolves. Stuff like this is the perfect way to get even more new software developed if it's at least in the range of power of something like Batari Basic.

With my current trio of upcoming Team Pixelboy ColecoVision releases, you can be sure this BV project is going to start off slowly, but once sales of those new CV games are mostly behind me, I'll be in a good position to really get into this project.

[GroovyBee]

You might want to use FLEX/LEX and BISON/YACC as a first pass at providing a solution.

[GroovyBee]

I had a look at your language specification. I thing strings should be null terminated by the compiler like they are in "C". If the language is for beginners I don't think they want extra headaches like that.

[Pixelboy]

GroovyBee, on Tue Feb 23, 2010 1:17 PM, said:

I had a look at your language specification. I thing strings should be null terminated by the compiler like they are in "C". If the language is for beginners I don't think they want extra headaches like that.

I made a note of this in section 4.9 (PRINT statement):

Quote

Any string constant used with PRINT does not need to have a null character ("\0") at the end,
because the compiler will add this null character at compile time. However, string variables
(in the string expression given to PRINT) need to have the terminating null character included.

However, I forgot to fix this in other parts of the documents. I'll do that on the next update. Thanks for bringing this to my attention.  

[batari]

GroovyBee, on Sun Feb 21, 2010 3:20 PM, said:

How about something like a BasicVision to "C" converter and then use SDCC to compile natively? That way if BASIC was too slow for parts of your game you could code them in "C" and if that was too slow you could write hand crafted assembly language. Its the best of all worlds then.

I was going to say that it would be hard to convert BASIC to C, but then I read the specifications, and it's already more like C than any classic BASIC I've seen.

If it were up to me, I'd do something more like a classic BASIC.  Maybe it won't be as powerful but I'd expect it will be easier to learn and more fun to use.

[newcoleco]

I like the idea, and I hope it'll works. It'll brings some new programmers in the colecovision homebrew scene, even if it's just for testing what they can do with it.

My only question is about how you'll deal with the fact that we can't update the video anytime we want without causing glitches and bugs... or you'll leave the joy to the new programmers to figure out that they should update the vram only at some conditions of timing and video settings.

[Pixelboy]

newcoleco, on Mon Mar 1, 2010 2:17 AM, said:

My only question is about how you'll deal with the fact that we can't update the video anytime we want without causing glitches and bugs... or you'll leave the joy to the new programmers to figure out that they should update the vram only at some conditions of timing and video settings.

I'll just tell them what you told me about programming in C on the CV: Do the VRAM updates first upon the start of each "game loop". Of course, since the BV code will be translated directly into assembly source code, I'm hoping there will be an improvement in performance so more VRAM I/Os will be possible.

Although I have to say that I consider the BV language to be a work-in-progress at this point. If there are "conditions of timing and video settings" that need to be considered, perhaps if I better understood that these conditions are, I could modify the language to better take them into account...

[Pixelboy]

I've been working on the BasicVision language during my lunch breaks this past week. Mostly, I've been translating my Sudoku game from C language to BasicVision, and this exercise allowed me to notice some annoyances and various other issues which I managed to fix without changing the syntax all that much. I'm about 70% done with the Sudoku translation, and once it's completed, I will post this "theoretical" source code on the BV web site, along with a new version of the language definition document. This should happen sometime next week.

Right now, I need some advice on a specific issue. Consider the following:

• 65000 (a UINT value) - 10000 (another UINT value) = 55000 (a UINT value)
  
• 60000 (a UINT value) - 65000 (another UINT value) = -5000 (a regular INT value)

So in one case, a UINT (unsigned integer) is needed to store the result of the substraction, and in the other, a regular INT (signed integer) is needed to store a negative result. Obviously, an arithmetic operator should have a result with a consistent datatype, so I'm not exactly sure what to do here.

I took some time to read about the ADD and SUB instructions in Z80 assembly, and how substractions can be done by adding using two's complement. Interesting stuff.    At one point, I'm going to have to write some test programs in Z80 assembly, and probably the first tests I will do will be ADD and SUB tests, just to see what results I get. With issues such as the one described above, I may have to do these tests earlier than I had anticipated.  

[newcoleco]

I'm probably rambling here but I'm not for the usage of dynamic datatype, changing a variable from one type to another on the fly can cause troubles because you'll have to consider each possible types before doing the appropriate set of instructions, adding a bunch of IF statements in your logic while encoding into assembly codes. Like you said, an unsigned type can't store a negative value... well it may store the value but the logic will interpret it as not a negative value. For example, for an unsigned byte (8 bit) equals to -1 will be interpreted as 255 ( 0xFF ). If you want to execute a special code when a certain value is less than zero, and the value is stored in an unsigned integer type variable, the condition makes then no sense and it will never executes the special code... and this kind of situation gives generally a WARNING message from the compiler part.

[Pixelboy]

newcoleco, on Sat Mar 6, 2010 6:12 PM, said:

I'm probably rambling here but I'm not for the usage of dynamic datatype, changing a variable from one type to another on the fly can cause troubles because you'll have to consider each possible types before doing the appropriate set of instructions, adding a bunch of IF statements in your logic while encoding into assembly codes. Like you said, an unsigned type can't store a negative value... well it may store the value but the logic will interpret it as not a negative value. For example, for an unsigned byte (8 bit) equals to -1 will be interpreted as 255 ( 0xFF ). If you want to execute a special code when a certain value is less than zero, and the value is stored in an unsigned integer type variable, the condition makes then no sense and it will never executes the special code... and this kind of situation gives generally a WARNING message from the compiler part.

I agree with what you said, but as it is defined now, BasicVision doesn't have any dynamic datatypes, so...  

Wait, I think I see where you're going with this: If I substract two UINTs, the result should be a UINT. If the result of the substraction ever turns out to be logically negative at run-time, then it's the programmer's fault for using UINTs when regular INTs are clearly needed.

Okay, so if I develop the logic a little:

• UINT - UINT = UINT
  
• INT - INT = INT
  
• UINT - INT = UINT
  
• INT - UINT = INT

(UINT - INT) should necessarily give a UINT, because the largest positive INT is 32767 and the whole point of using UINTs is to have values above 32767, so a substraction from a large UINT with a positive INT will necessarily be a positive INT (so UINT is okay). Substraction with a negative INT is actually an addition, so again, the end result is a UINT. And in the end, if (UINT - INT) gives a negative value (in the case where the UINT is smaller than the positive INT), then again, it's the programmer's fault for using UINTs when regular INTs are clearly needed.

(INT - UINT) should give an INT, because the calculation starts in the realm of "possibly negative" values anyway.

So that means the datatype of the result of a substraction should always be the datatype of the left-side value. Okay, that clarifies things.

Thanks Daniel!  

[Pixelboy]

I updated the BasicVision web site with a new version of the language design document (now 1.1). Among the changes I introduced, there's the new concept of local variables (which are technically no different from global variables defined in RAM, except that they are visible only within the blocks where they are defined). I also added a few nice features to the PRINT statement, and I added a way to pass parameters via GOSUB (and also via the new POPSUB statement).

I also added to the web site my Sudoku game source, recoded in BasicVision (from C language). You can consider it as a sort of work-in-progress demo code, because I'm sure there will be changes and additions to the BasicVision language in the future that will influence this Sudoku source code.

There's still plenty of stuff to work out, like operators, memory address processing, etc., etc., but I have to take a break from this project to concentrate on my upcoming Team Pixelboy releases. I'll probably get back to work on BasicVision some time in April. In the mean time, comments and suggestions are welcome.  

[Animan]

Anything happen over these 3 months? I've been getting into Colecovision programming, and I want to see this happen.

[Pixelboy]

Animan, on Fri Jun 25, 2010 5:09 PM, said:

Anything happen over these 3 months? I've been getting into Colecovision programming, and I want to see this happen.

The BasicVision project is on ice right now. I have to complete the new box templates of Gulkave, Girl's Garden, Peek-a-boo and Pitfall II Arcade, and get them printed in time for the planned October 2010 release. And there's also the manual of Pitfall II Arcade that I haven't begun working on yet. I'm not sure if "Space Shuttle - A Journey Into Space" will be ready in time for the final NASA shuttle launch next November, but I'll do my best to make it happen.

All this to say that I can't imagine finding the time to work on BasicVision before next January.