Jump to content
IGNORED

Colecovision recharged BASIC compiler: CVBasic v0.4.0 (now with compression and MSX support!)


Recommended Posts

I was looking at the color options for chars and sprites.   Chars (8x8) you can define a color for the each of the rows.  For sprites (16x16) if seems you can only define one color.   Is there a way to create a sprite with multiple colors (define each pixel color)?   

Link to comment
Share on other sites

3 minutes ago, OriginalJohn said:

I was looking at the color options for chars and sprites.   Chars (8x8) you can define a color for the each of the rows.  For sprites (16x16) if seems you can only define one color.   Is there a way to create a sprite with multiple colors (define each pixel color)?   

 

Not an expert answer.  But, the most common technique is layering single color sprites on top of eachother.

Link to comment
Share on other sites

My understanding is that you can have eight sprites active at once, but the first four take priority. So if there's a lot of activity in one line, those four sprites will be drawn first, and the last four will be most subject to flicker. It seems most logical to assign the extra color to one of the last four sprites, because they'll be the most expendable.

 

I'm noticing that BASIC files can be nested with INCLUDE, resulting in less mess and a more modular design. If you, say, wanted to create a custom font, you could do that inside another BASIC file, and reference that file in your main program. If you wanted to use the custom font in several games, you could reference that file in whatever program that needs it, saving you time and keeping the main program tidy.

 

My question is this: is there an ASCII table specifically for the ColecoVision? What addresses would I need to use to change the system's font? I'm not crazy about the ColecoVision font; it makes every game look like Space Invaders, even when it's not Space Invaders.

Link to comment
Share on other sites

4 hours ago, Jess Ragan said:

My understanding is that you can have eight sprites active at once, but the first four take priority. So if there's a lot of activity in one line, those four sprites will be drawn first, and the last four will be most subject to flicker. It seems most logical to assign the extra color to one of the last four sprites, because they'll be the most expendable.

 

I'm noticing that BASIC files can be nested with INCLUDE, resulting in less mess and a more modular design. If you, say, wanted to create a custom font, you could do that inside another BASIC file, and reference that file in your main program. If you wanted to use the custom font in several games, you could reference that file in whatever program that needs it, saving you time and keeping the main program tidy.

 

My question is this: is there an ASCII table specifically for the ColecoVision? What addresses would I need to use to change the system's font? I'm not crazy about the ColecoVision font; it makes every game look like Space Invaders, even when it's not Space Invaders.

You can have 32 sprites at the same time, but if you put more than 4 in a row the other sprites will disappear or there will be some flicker.

 

1 hour ago, Jess Ragan said:

Wait wait, there are 256 total 8x8 pixel characters, right? Are they part of the ASCII code? Could you technically just PRINT them on the screen with the appropriate ASCII code, as if they were text?

 

CVBasic starts in MODE 0. In this mode, it loads the ASCII letters and signs in the range 32-127. Given these characters are loaded in VRAM, nothing prevents you from redefining them or reusing the character space to draw graphics. In fact in the picture I show a few posts above, Monkey Moon draws the level using the lowercase letters redefined to ladders and girders.

 

Link to comment
Share on other sites

3 hours ago, nanochess said:

CVBasic starts in MODE 0. In this mode, it loads the ASCII letters and signs in the range 32-127.

... and those "default" letters and symbols are stored in the Coleco BIOS, by the way.  :)

 

  • Thanks 1
Link to comment
Share on other sites

I don't know if this is the appropriate place to ask, but here goes.

 

If I define two sprites each with their own label,

DEFINE SPRITE 0,1,sprite1
DEFINE SPRITE 1,1,sprite2

 

Executing the code and attempting to display one in the upper left and one in the middle of the screen.
SPRITE 0, 0, 0, 0, 2
SPRITE 1, 80, 120, 0, 2

 

Results in the same sprite appearing in each location instead of the one which is defined as sprite2.  What am I doing wrong?

Link to comment
Share on other sites

2 hours ago, OriginalJohn said:

I don't know if this is the appropriate place to ask, but here goes.

 

If I define two sprites each with their own label,

DEFINE SPRITE 0,1,sprite1
DEFINE SPRITE 1,1,sprite2

 

Executing the code and attempting to display one in the upper left and one in the middle of the screen.
SPRITE 0, 0, 0, 0, 2
SPRITE 1, 80, 120, 0, 2

 

Results in the same sprite appearing in each location instead of the one which is defined as sprite2.  What am I doing wrong?

The second statement should be:

 

SPRITE 1,80,120,4,2

 

Because the sprite definition number is multiplied by 4.

Link to comment
Share on other sites

In the words of Archimedes, HELL YEAH.

 

I was weary of the font on the ColecoVision, but this adds a touch of class to it. Now I know how to create a custom font on this system, and so do you... just replace the bitmaps with whatever you please. The colors on the bottom can likewise be adjusted, but I chose a grey edge for the tops and bottoms of each letter, to give them a more metallic look. It's a thing Compile used to do on the MSX, as I recall.

 

(The Z is funky. I'm not sure why.)

 

Okay, so question. If I put this as an include in another BASIC program, it's not going to take up 12K of my total allotted space, is it? I presume it's just going to apply my custom graphics, terminate, and come back to the program itself with no significant loss in available storage. All that's just going straight to the VRAM, and it was already used by the BIOS in the first place.

bellafonte_0000.png

bellafonte.bas bellafonte.rom

  • Like 1
Link to comment
Share on other sites

1 hour ago, Jess Ragan said:

In the words of Archimedes, HELL YEAH.

 

I was weary of the font on the ColecoVision, but this adds a touch of class to it. Now I know how to create a custom font on this system, and so do you... just replace the bitmaps with whatever you please. The colors on the bottom can likewise be adjusted, but I chose a grey edge for the tops and bottoms of each letter, to give them a more metallic look. It's a thing Compile used to do on the MSX, as I recall.

 

(The Z is funky. I'm not sure why.)

 

Okay, so question. If I put this as an include in another BASIC program, it's not going to take up 12K of my total allotted space, is it? I presume it's just going to apply my custom graphics, terminate, and come back to the program itself with no significant loss in available storage. All that's just going straight to the VRAM, and it was already used by the BIOS in the first place.

If you include this in your main program, the size of the final ROM will only grow by 2K, more or less the size of the ROM you are generating now.

 

Another option is to draw your font in BMP format, including color, and process this with TMSColor using the tiles option and the Pletter compression. You can probably get it down to 800 bytes or so.

Link to comment
Share on other sites

4 hours ago, Révo said:

Hey, I'm looking for a way to clean text (in some area not all), as you can see I'm using space after text to clean the text before but this is taking lot of space in the ROM. Cheers.

text.png

You could make a little subroutine to clear that area of the screen before doing any printing.

Also, I think the money logic needs a bit of cleaning up. For instance, if Alf costs 9, then <9 is not enough money, but >8 is enough (you've got >9, which means you'd need 10).

Link to comment
Share on other sites

Oh lol, thanks to the code above I just realized that I don't use the PROCEDURE statement at all even though according to the manual it's required to create routines that can be called with GOSUB. I wonder if it's really required to guarantee RETURN'ing works correctly, or maybe I'm just lucky :P

Link to comment
Share on other sites

10 hours ago, Révo said:

Hey, I'm looking for a way to clean text (in some area not all), as you can see I'm using space after text to clean the text before but this is taking lot of space in the ROM. Cheers.

text.png

Use this code for cleaning parts of the screen:

FOR #c = $1800 + 128 TO $1800 + 191
	VPOKE #c,32
NEXT #c

 

I used separated constants so you can see the starting and ending positions on the screen. And yep, it will save you a lot of bytes!

 

Link to comment
Share on other sites

2 hours ago, abeker said:

Oh lol, thanks to the code above I just realized that I don't use the PROCEDURE statement at all even though according to the manual it's required to create routines that can be called with GOSUB. I wonder if it's really required to guarantee RETURN'ing works correctly, or maybe I'm just lucky :P

I don't have yet added warnings for this. Unlike Intellivision, in Z80 there's no required stack frame so it doesn't crash. But for syntax and maybe future optimization I'll require GOSUB to go to a PROCEDURE.

 

Link to comment
Share on other sites

I just updated to v0.4.3, some of the new changes are:

 

* DATA statements can now use constant expressions and VARPTR (for addresses).

* Optimized access to arrays when using constant index (so fast as variables).

* Implemented USR and CALL to simplify calling assembler language.

* Added support for formatted PRINT with leading zeros or spaces, for example, PRINT AT 5,"Score:",<5>#score

* Super Game Module support added (using --sgm option on compilation).

* It includes the CVBasic source code in the ASM output so you can see how things are compiled.

 

Available in the first post.

  • Like 2
  • Thanks 1
Link to comment
Share on other sites

1 hour ago, Jess Ragan said:

Hot damn! Super Game Module support, too? What's that going to give developers? 128K of RAM and the extra sound channels of the MSX?

24K of RAM to get you also ADAM compatibility and SOUND 5-9 gets you the SGM sound channels.

 

I forgot to initialize the SGM, so in the meanwhile, you should start your SGM programs with:

 

SOUND 5,,0
SOUND 6,,0
SOUND 7,,0
SOUND 9,,$B8

 

Or use this updated cvbasic_epilogue.asm

 

 

cvbasic_epilogue.asm

  • Like 1
Link to comment
Share on other sites

1 hour ago, Jess Ragan said:

TMScolor is a real time saver, I'll tell you h'what.

 

So! I just made a thing. It's not a game, but there's animation, so that's a step in the right direction. The ROM should run in anything that can play ColecoVision games. (Also, phew. Even with TMScolor, this took some time.)

antiqueovision.rom 3.16 kB · 1 download

Awesome animation!

 

👏👏👏

Link to comment
Share on other sites

A new update of CVbasic ? You're the man Oscar! ;) And the animation of Jess, really great! ;)

 

Well i have done a small slideshow of 5 pictures and this is the second version as the first one there was a different color screen in between the pictures but now that's corrected.

It's not much but it's a start, hope some of you will like it. :)

 

 

slideshow02.rom

  • Like 1
Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...