Jump to content
Posted Sun Feb 21, 2010 2:42 PM
Posted Sun Feb 21, 2010 3:07 PM
Posted Sun Feb 21, 2010 3:18 PM
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.
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.
Posted Sun Feb 21, 2010 3:20 PM
Posted Sun Feb 21, 2010 5:23 PM
Posted Mon Feb 22, 2010 9:13 AM
Posted Mon Feb 22, 2010 9:17 AM
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.
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)
Posted Mon Feb 22, 2010 2:47 PM
Posted Mon Feb 22, 2010 3:22 PM
Posted Tue Feb 23, 2010 12:45 PM
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.
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!
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.
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.
Posted Tue Feb 23, 2010 1:14 PM
Posted Tue Feb 23, 2010 1:17 PM
Posted Tue Feb 23, 2010 3:56 PM
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.
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.
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.
Posted Wed Feb 24, 2010 9:15 PM
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.
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.
Posted Mon Mar 1, 2010 2:17 AM
Posted Mon Mar 1, 2010 5:44 AM
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.
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.
Posted Sat Mar 6, 2010 9:39 AM
Posted Sat Mar 6, 2010 6:12 PM
Posted Sun Mar 7, 2010 5:57 AM
I agree with what you said, but as it is defined now, BasicVision doesn't have any dynamic datatypes, so...
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.
Posted Mon Mar 15, 2010 5:55 PM
Posted Fri Jun 25, 2010 5:09 PM
Posted Fri Jun 25, 2010 5:52 PM
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.
Anything happen over these 3 months? I've been getting into Colecovision programming, and I want to see this happen.
0 members, 0 guests, 0 anonymous users