Colecovision wonder-tastic BASIC compiler: CVBasic v0.5.0 (now with bank-switching support!)

[artrag]

1 hour ago, Jess Ragan said:

 

I've noticed that SG-1000 games can be slightly larger than ColecoVision games, up to 48K. How does CV Basic handle games for that system and the MSX? Same hard limit on cart size?

You can generate roms of any size but to use the data and code over 32Kb you need to use banks (both on msx and ColecoVision).

 

[SiRioKD]

2 hours ago, Jess Ragan said:

Heh, I think I've been talking to you on another forum!

 

For the record, I don't know if I can compress the graphics in the game without losing visual quality. (Which would be a shame, as graphics are a highlight in WESEB.) I know Nanochess mentioned something called "pletter" in the instructions, but I don't know how that works. I'm pretty sure I don't want the code to get so complicated that I can't keep track of it, though.

 

I've noticed that SG-1000 games can be slightly larger than ColecoVision games, up to 48K. How does CV Basic handle games for that system and the MSX? Same hard limit on cart size?

SG-1000 doesn't have any BIOS. All service/system routines are in the game ROM.

However, 81 games of official SG-1000 games are equal or smaller than 32KB.

 

Colecovision has 8KB of BIOS routines, not present in game ROM.

MSX has 16KB BIOS routines, not present in game ROM.

 

 

[+nanochess]

7 hours ago, SiRioKD said:

Hi, 

here's my modified prologue:

https://github.com/siriokds/SC-3000-Keyboard-support/blob/main/cvbasic_prologue.asm

 

* Inserted the initial VDP initialization delay needed with these machines with no bios.

* Added the SC-3000/SG-1000 player-1 keys from keyboard if present.

 

 

I don't officially support Sega SC-3000, but I think I could add a link somewhere in the CVBasic documentation.

 

In fact, I appreciate your help with the SG1000 testing, because I don't have yet my own Sega SG-1000 console.

 

2 hours ago, Jess Ragan said:

Heh, I think I've been talking to you on another forum!

 

For the record, I don't know if I can compress the graphics in the game without losing visual quality. (Which would be a shame, as graphics are a highlight in WESEB.) I know Nanochess mentioned something called "pletter" in the instructions, but I don't know how that works. I'm pretty sure I don't want the code to get so complicated that I can't keep track of it, though.

 

I've noticed that SG-1000 games can be slightly larger than ColecoVision games, up to 48K. How does CV Basic handle games for that system and the MSX? Same hard limit on cart size?

The SG-1000 games can be larger because the cartridge area is $0000-$bfff (48K), same as Sega Master System.

 

Instead in Colecovision the cartridge area is $8000-$ffff (32K), and you cannot expand unless you use bank switching.

 

In MSX technically the 64K could be cartridge but is preferred bank-switching using a 32K base area for the cartridge $4000-$bfff, leaving the BIOS routines at $0000-$3fff and 16K RAM at $c000-$ffff.

 

Simply by passing the option -z to TMSColor all your graphics are compressed automatically, and the only thing you should have to do is add the PLETTER keyword in DEFINE CHAR, DEFINE_COLOR and DEFINE SPRITE.

 

The screen pattern isn't compressed because the SCREEN statement to copy the tiles needs to be fast.

 

1 hour ago, carlsson said:

When you generate graphics through tmscolor -z, your data will be compressed with the Pletter algorithm. Once you insert it into your program, you load as characters or sprites by adding the PLETTER keyword so the compiler knows this data actually is compressed. That is a non-destructive compression, think ZIP in order to save ROM space. While the manual doesn't say, I suppose it might take a little longer to load such data than if it was uncompressed straight from ROM.

 

Since you can DEFINE VRAM at any address with compressed data, I suppose it could be a use case if you keep e.g. changeable level data in a part of VRAM that you VPEEK and VPOKE against all the time. In that case, you would have compressed your levels manually using a Pletter compressor, which is not what you asked for.

Exactly! Thanks!

 

[Jess Ragan]

Okay, I'll keep this in mind. It's probably good practice to keep things compact, but I don't feel much pressure to squeeze the SG-1000 version of the game into 32K.

 

Maybe I'll experiment with Pletter in the future, though. You said it doesn't compromise the visuals at all? That's encouraging. How much ROM space can I save using compression? How much time does it take to decompress the visuals?

 

By the way, I ordered a MIDI cable on Amazon, and plan to dink around with that and my Rock Band keytar when it arrives. I was hoping to have someone else work on the music and sound effects, but it won't hurt for me to experiment a little, and see what I can do myself. People are telling me, "Well, you should try making music yourself!," and I'm just thinking, "Yeah, while I'm at it, I'll solve a quadratic equation and crack the human genome. Sheesh." It's not a talent I possess, is my point. You might as well ask a trout to run a marathon.

Edited May 2 by Jess Ragan

[+nanochess]

35 minutes ago, Jess Ragan said:

Okay, I'll keep this in mind. It's probably good practice to keep things compact, but I don't feel much pressure to squeeze the SG-1000 version of the game into 32K.

 

Maybe I'll experiment with Pletter in the future, though. You said it doesn't compromise the visuals at all? That's encouraging. How much ROM space can I save using compression? How much time does it take to decompress the visuals?

 

By the way, I ordered a MIDI cable on Amazon, and plan to dink around with that and my Rock Band keytar when it arrives. I was hoping to have someone else work on the music and sound effects, but it won't hurt for me to experiment a little, and see what I can do myself. People are telling me, "Well, you should try making music yourself!," and I'm just thinking, "Yeah, while I'm at it, I'll solve a quadratic equation and crack the human genome. Sheesh." It's not a talent I possess, is my point. You might as well ask a trout to run a marathon.

Typically you can save 70% of space, for example, a 2048 bytes pattern can be reduced to 800 bytes or so. Just by using the -z argument in TMSColor, and adding the PLETTER keyword in CVBasic.

 

[Jess Ragan]

By Grabthar's hammer, what a savings. Of cartridge space.

 

A seventy percent reduction in size is a pretty big deal, especially on the ColecoVision where storage is tight. Now I'm thinking of actually doing this.

 

(When? Pfft. Who knows?)

[Jess Ragan]

By the way, I'm experimenting with a logo for CV Basic; something that's clear in its design but could be reproduced on an actual ColecoVision without compromise.

 

[Jess Ragan]

Starting the switch to compressed graphics. The title screen takes two seconds to come up now, buuuuut it's still better than the thirteen damn seconds the ColecoVision takes to start its first party games. For no reason! Apparently that design was for the sake of brand recognition, but I find it incredibly annoying. I know I'm playing a ColecoVision! I don't need a reminder!

[Tony Cruise]

15 hours ago, SiRioKD said:

Hi, 

I put the essential code for SG-1000/SC-3000 used in Sega games. 

 

I added the correct initialization code and the keyboard (SC-3000 and external SK-1100 for SG-1000) support for joystick (only player 1 so far).

 

https://github.com/siriokds/SC-3000-Keyboard-support/blob/main/SG-1000_SC-3000_essentials.asm

 

Enjoy.

 

 

 

mmm, might have to do a SG-1000/SC-3000 release of EA 70's Arcade Classics now

[Kiwi]

4 hours ago, nanochess said:

The screen pattern isn't compressed because the SCREEN statement to copy the tiles needs to be fast.

Maybe a slow version of the Screen routine would be viable if it is only for static element nametable like title screens, flipscreen levels. One full name table is 768 bytes, Only can store about 40 of those in 32 KB.  If it has a lot of repeative data that can be RLE compress, it would save a lot of cartridge space. 

Alternate way is metatiles.  I use 16x16 metatiles, which only need 192 bytes to hold the screen data. A lot of NES and SNES games uses metatiles to save space like Blaster Master have 64x64 metatiles, Earthbound SNES 32x32 metatiles. 

Here are the metatiles routine I did for Depth of Nitemare for the Intellivision that uses similar syntax as CVbasic.

 

TilesMetaCard:

data $0800,$0808
data $0828,$0830'0 wall
data $0868,$0870
data $08A8,$08B0'1 lock
data $0810,$0810
data $0810,$0810'2 floor
data $0948,$0950
data $0978,$0980'3 trap

data $0810,$0810
data $0838,$0840'4 ez enemy
data $0878,$0880
data $08B8,$08C0'5 hardEnemy
data $08E8,$08F0
data $0918,$0920'6 gold chest
data $0958,$0960
data $0988,$0990'7 Shop

data $0818,$0820
data $0848,$0850'8 INN
data $0888,$0890
data $08C8,$08D0'9 mystery
data $08F8,$0900
data $0928,$0930'10Meat
data $0810,$0810
data $0998,$09A0'11Scroll
 
data $0810,$0810
data $0858,$0860'12key
data $0898,$08A0
data $08D8,$08E0'13Bag
data $0908,$0910
data $0938,$0940'14boss
data $0968,$0970
data $09A8,$09B0'15stairs
	
WriteMap:procedure
y=0:c=0:x=0 'starting position
for i=0 to 39 'do this 40 tiles
c=MapData(i+Mapy)'grab tile info from RAM, MapData, and put it into C. 
c=c*4 'multiply by 4 to get the correct metatile,0-15, above
screen TilesMetaCard,c,x+y*20,2,2,2 'print metatile to the screen
x=x+2 'move x cursor over by 2
if x>=16 then x=0:y=y+2 'if cursor is equal or over 16, then advance y cursor by 2, return x to 0 like a typewriter.
next i 'i++
return
end	

You can change the x>=16 to x>=32 to fill the entire screen.  I translated from my original routine to use for the Colecovision project.
 

void WriteScreen() {
y=0;c=0;x=0;
for(i=0;i!=192;i++){
c=Data[i];
//if(c>=52){err=1;}
c=c*4;
put_frame(BlankTile+c,x,y,2,2);
x+=2;
if(x>=32){x=0;y+=2;}
}
}

 

[thegeps]

Nope, VRAM addresses are (almost) entirely used by the vdp so you can't keep your compressed data there (at least on graphic2 mode, you have free space in graphic1 mode).

Probably DEFINE VRAM is used to decompress data from ROM (or RAM) to VRAM

Edit: Sorry, forgot to quote the post I was answering 

Edited May 3 by thegeps
Forgot to quote

[SiRioKD]

14 hours ago, nanochess said:

I don't officially support Sega SC-3000, but I think I could add a link somewhere in the CVBasic documentation.

 

In fact, I appreciate your help with the SG1000 testing, because I don't have yet my own Sega SG-1000 console.

 

The SG-1000 games can be larger because the cartridge area is $0000-$bfff (48K), same as Sega Master System.

 

Instead in Colecovision the cartridge area is $8000-$ffff (32K), and you cannot expand unless you use bank switching.

 

In MSX technically the 64K could be cartridge but is preferred bank-switching using a 32K base area for the cartridge $4000-$bfff, leaving the BIOS routines at $0000-$3fff and 16K RAM at $c000-$ffff.

 

Simply by passing the option -z to TMSColor all your graphics are compressed automatically, and the only thing you should have to do is add the PLETTER keyword in DEFINE CHAR, DEFINE_COLOR and DEFINE SPRITE.

 

The screen pattern isn't compressed because the SCREEN statement to copy the tiles needs to be fast.

 

Exactly! Thanks!

 

 

 

The code I linked in my github is the official Sega initialization routine for both SG-1000/SC-3000.

They didn't make any difference since the code for the SG-1000 external keyboard is inserted despite you have it attached or not.

 

Every SG-1000 game has the similar initialization routine used basically due to the average reset circuit present on SG-1000 Mark I/II.

 

 

[ZippyOasys]

Got bored. Made this unofficial CVBasic logo based on the actual Colecovision logo within about a half hour or so

Feel free to use it.

 

 

P.S. It's my birthday today.

[+nanochess]

19 minutes ago, ZippyOasys said:

Got bored. Made this unofficial CVBasic logo based on the actual Colecovision logo within about a half hour or so

Feel free to use it.

 

 

P.S. It's my birthday today.

Wow! This looks pretty cool actually.

 

Thanks! And happy birthday! 🥳🥳🥳🥳

[drfloyd]

Hi,

There are no bidimentionnal DIM in CVBasic ? DIM (x,y) ?

[drfloyd]

Will it be easy for Oscar to port CVBasic to SG-3000 / SEGA Master System (in the future) ? It will be so incredible to code in basic using features of this great console.

Edited May 8 by drfloyd

[drfloyd]

Hi again,

 

As there is no RANDOMSEED command in CVBasic....

I would like a create a pseudo random generator with a SEED. Who can I do it ?

 

How ca i integrate a SEED for fixed resultats ?

 

Exemple :
 

' TEST
' does not work, the resultats changed each time

loop:

PRINT AT 40,"PSEUDO RANDOM TEST"

' would like to see always the same random results with this seed 1654
#seed = 1654

PRINT AT 76,RANDOM(999)
PRINT AT 76+32,RANDOM(999)
PRINT AT 76+64,RANDOM(999)
' fail


' would like to see always the same random results with this seed 4565
#seed = 4565

PRINT AT 76+128,RANDOM(999)
PRINT AT 76+160,RANDOM(999)
PRINT AT 76+192,RANDOM(999)
' fail

goto loop

 

So would like to see for exemple :

345

432

654

 

864

345

359

 

With no change at each loop

 

need that for a specific game

 

Don't know if you undestand my problem LOL

 

(I am french, sorry for my cow english)

 

Edited May 8 by drfloyd

[+Gemintronic]

I am used to other BASICs that let you seed by using "RAND = 207".  Also, using RAND like "EnemyX = RAND".  Something similar to QuickBASIC, SecondBASIC or batari BASIC.

 

Hopefully we can make our own CVBasic community library with a Microsoft BASIC style RAND.  Or, just politely ask Oscar for something like that

 

In the meantime I *think* I saw someone post a PRNG that could do something similar.  Unfortunately, my search skills are very poor at the moment.  Perhaps someone else can post a link.

 

[+nanochess]

You cannot use exactly that syntax, but you can use a separate subroutine.

 

	'
	' Example of fixed pseudo-random number generator
	'
	' by Oscar Toledo G.
	' https://nanochess.org/
	'
	' Creation date: May/08/2024.
	'

	#seed = 1654

	GOSUB get_random
	PRINT AT 76,#seed % 999
	GOSUB get_random
	PRINT AT 76+32, #seed % 999
	GOSUB get_random
	PRINT AT 76+64, #seed % 999

	#seed = 4565

	GOSUB get_random
	PRINT AT 76+128,#seed % 999
	GOSUB get_random
	PRINT AT 76+160,#seed % 999
	GOSUB get_random
	PRINT AT 76+192,#seed % 999

	WHILE 1: WEND

get_random:	PROCEDURE
	#seed = #seed * 3141 + 2923
	END

 

[drfloyd]

can(t believe, it works !

[drfloyd]

there are no negative numbers in CVBasic ?

[+nanochess]

31 minutes ago, drfloyd said:

there are no negative numbers in CVBasic ?

I suppose you mean for display. Currently, there is no direct support to display negative numbers.

 

But you can always do it the other way:

 

IF #value >= 32768 THEN 
    PRINT "-",-#value
ELSE
    PRINT #value
END IF

 

[drfloyd]

not only for display :

 

a=-1
print at  0,12+a

 

the result is 267 and not 11

 

 

[+nanochess]

4 hours ago, drfloyd said:

not only for display :

 

a=-1
print at  0,12+a

 

the result is 267 and not 11

 

 

 

The variables without # prefix are 8-bit variables, and the numbers by default are 16-bit unless you add a period as suffix.

 

You'll get the correct result with this (two's complement arithmetic with 8-bit):

 

a = -1
print at 0, 12.+a

 

Notice the period after the number.

 

Remember whenever you use a 16-bit variable or number, CVBasic will extend internally the processing to 16-bit. Any 8-bit value will be zero-extended to 16-bit. So for the first example, the right way to do the arithmetic is:

 

#a = -1
print at 0, 12 + #a

 

Normal BASIC language doesn't have types, but CVBasic actually enforces two types: 8-bit and 16-bit. This is in order to generate more optimized Z80 code.

 

[artrag]

Feature requests for V0.6

1) add on msx, keyboard decoding for keys 0-9 and "*" and "#". In this way Coleco and msx games can have the same input.

2) add in the sample directory one of my horizontal scrolling samples from  here 😄

3) add a way to impose the definition of all variables using DIM (OPTION EXPLICIT ON in intybasic)

4) add a way to support signed and unsigned variables (UNSIGNED and SIGNED in intybasic)

5) add simple macro support to the assembler, so you can replace with a macro the call to nmi_on/off

PS

Greetings ! V0.5 works like magic and the ASM generated is better than the one from SDCC

Edited May 14 by artrag