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

[+nanochess]

On 4/17/2024 at 6:16 PM, Jess Ragan said:

On a related note, can you check for tiles near or colliding with a sprite? I presume VPEEK would be the way to go for this.

Yes, the most common detection is in one direction, for example, for bullets.

 

	x = (sprite_x + 7) / 8	' Getting the center of the sprite
	y = (sprite_y + 7) / 8
	c = VPEEK($1800 + y * 32 + x)	' Read character.

 

[youki]

17 hours ago, nanochess said:

Yes, the most common detection is in one direction, for example, for bullets.

 

	x = (sprite_x + 7) / 8	' Getting the center of the sprite
	y = (sprite_y + 7) / 8
	c = VPEEK($1800 + sprite_y * 32 + sprite_x)	' Read character.

 

wouldn't it be rather :

 

VPEEK($1800+y*32+x)  here?

 

 

[+nanochess]

2 hours ago, youki said:

wouldn't it be rather :

 

VPEEK($1800+y*32+x)  here?

 

 

Woops! 😅

 

Gotcha! Thanks for the correction. I've updated it.

[+nanochess]

On 4/12/2024 at 1:43 AM, abeker said:

I want to do something like this:

	level = 1
	#pointer = #level_pointers(level)
	RESTORE #pointer
	READ BYTE size
	PRINT AT 0, size
STOP: GOTO STOP

level_pointers:
	DATA VARPTR #level1, VARPTR #level2
level1:
	DATA BYTE 4,0,1,2,3
level2:
	DATA BYTE 3,0,1,2

When compiling this, I get a warning variable #POINTER being assigned but never used. Looking at the generated assembly code, RESTORE treats the variable the same as a label.

 

Of course I can work around this by just using a lot of IF-statements, but to create more complex data structures it would be really useful to be able to use the contents of a variable to RESTORE from.

Sorry, I didn't see this post earlier.

 

The problem here is that your label definition says level_pointers instead of #level_pointers (the # makes it a different label), besides the VARPTR is wrong.

 

It should be:

 

#level_pointers:
	DATA VARPTR level1(0), VARPTR level2(0)

 

This is because your VARPTR is giving a pointer to a variable, instead of an array, and also the names were wrong.

 

[abeker]

22 hours ago, nanochess said:

The problem here is that your label definition says level_pointers instead of #level_pointers (the # makes it a different label), besides the VARPTR is wrong.

 

It should be:

 

#level_pointers:
	DATA VARPTR level1(0), VARPTR level2(0)

 

This is because your VARPTR is giving a pointer to a variable, instead of an array, and also the names were wrong.

Thanks, this fixes most of the problems but still the RESTORE doesn't do what I'd like it to do in this case. It does exactly what the manual says (Restores the READ pointer to start at the provided label.) but I'd like it to use the contents of the variable instead of it's address.

 

I'll just insert the following assembly code manually for now:

	ASM LD HL,(cvb_#POINTER)
	ASM LD (read_pointer),HL

 

I found one little bug: If there's an error in an included file, the compiler doesn't report the name of the include file but the filename that was specified on the command line.

 

Anyways, I created a little puzzle game called Boxy. Still work in progress (needs some real graphics instead of programmer art, some more levels and maybe music/sound effects).

Moving boxes are tiles at the moment but I want to use sprites for smoother animations and a nice bounce effect once the box hits a wall or other box.

boxy.bas boxy_gfx.bas boxy_levels.bas

[+nanochess]

1 hour ago, abeker said:

Thanks, this fixes most of the problems but still the RESTORE doesn't do what I'd like it to do in this case. It does exactly what the manual says (Restores the READ pointer to start at the provided label.) but I'd like it to use the contents of the variable instead of it's address.

 

I'll just insert the following assembly code manually for now:

	ASM LD HL,(cvb_#POINTER)
	ASM LD (read_pointer),HL

 

I found one little bug: If there's an error in an included file, the compiler doesn't report the name of the include file but the filename that was specified on the command line.

 

Anyways, I created a little puzzle game called Boxy. Still work in progress (needs some real graphics instead of programmer art, some more levels and maybe music/sound effects).

Moving boxes are tiles at the moment but I want to use sprites for smoother animations and a nice bounce effect once the box hits a wall or other box.

boxy.bas 7.07 kB · 0 downloads boxy_gfx.bas 5.42 kB · 0 downloads boxy_levels.bas 2.09 kB · 0 downloads

I see what you required. RESTORE currently doesn't allow for variable pointers.

 

Another option is using: size = PEEK(#pointer) : #pointer = #pointer + 1

 

That's a very nice game! Kudos!

 

[Jess Ragan]

Did I ask this? I was meaning to.

 

Say you want to change the colors for text or whatever, but you don't want to change it in the character set, but rather on the screen itself. Is there a span of addresses for this? Say, you printed something on the top row, but you wanted it red (indicating a mistake by the player) rather than its default white and grey color. Can you do that? How would you do that? It'd be really helpful to know this for color strobing and the like.

[ZippyOasys]

How well can it perform smooth horizontal scrolling?

[+nanochess]

10 hours ago, Jess Ragan said:

Did I ask this? I was meaning to.

 

Say you want to change the colors for text or whatever, but you don't want to change it in the character set, but rather on the screen itself. Is there a span of addresses for this? Say, you printed something on the top row, but you wanted it red (indicating a mistake by the player) rather than its default white and grey color. Can you do that? How would you do that? It'd be really helpful to know this for color strobing and the like.

If you want to change only a single text, you need to copy the letters for this text into another part of the character set and change their color.

 

In this case, I define the letter A as character 1 (the portion 0-31 is unused in the default mode 0). You could copy the whole alphabet if required.

 

	DEFINE CHAR 1,1,letter_a_bitmap
	DEFINE COLOR 1,1,letter_a_color

	VPOKE $1800+72,65	' Normal A letter
	VPOKE $1800+104,1	' Colored A letter

	WHILE 1: WEND

letter_a_bitmap:
	BITMAP "..X....."
	BITMAP ".X.X...."
	BITMAP "X...X..."
	BITMAP "X...X..."
	BITMAP "XXXXX..."
	BITMAP "X...X..."
	BITMAP "X...X..."
	BITMAP "........"

letter_a_color:
	DATA BYTE $90,$90,$90,$90,$90,$90,$90,$90

 

10 hours ago, ZippyOasys said:

How well can it perform smooth horizontal scrolling?

It depends on your approach to horizontal scrolling.

 

For my next book, I'll show how to make fast horizontal scrolling with platforms and obstacles. The design eases scrolling as only two characters need to be updated per item (two floors and two obstacles). Also, it isn't noticeable that the scrolling is in tiles because it scrolls at 30 frames per second and that's enough to look like smooth scroll.

 

If you want to make a full-screen scrolling with graphics you can use a map in memory that you could copy with SCREEN, and switch hidden pages like I proposed here.

 

[Jess Ragan]

Hm. Not the answer I was hoping to hear, but knowing that 0-31 is free for the user to access and change is useful information indeed. Aren't they ordinarily computer commands, like backspace and return and communications with other systems?

[+nanochess]

1 minute ago, Jess Ragan said:

Hm. Not the answer I was hoping to hear, but knowing that 0-31 is free for the user to access and change is useful information indeed. Aren't they ordinarily computer commands, like backspace and return and communications with other systems?

These were never displayed on any computer, except if you POKE'ed directly on video screen, or you used CHR$(1) (not available in CVBasic because there exists VPOKE)

 

 

[artrag]

Smooth horizontal scrolling needs a little bit of work offline, using your own tools, to precompute tiles and maps. There is no HW support, so all the magic comes from your software and data.

CV basic starts in "bitmap" mode (graphic 2 mode). Here the "general" solution is to precompute the tiles in all the in the intermediate positions and store them in ROM (say 4 positions if you move 2 pixels at time). At each step, you need to load the shifted definitions in VRAM on a set of hidden tiles (say e.g. 0-127), while showing on the screen tiles 128-255.

When done, during VBLANK, you have to update the PNT by showing the tiles you have updated (0-127).

Then you start loading the new tile definitions on the other tiles you do not display (128-255).

Note that you need 4 set of tiles (up to 128), one for each "step", and 4 maps from where you need to copy the PNT on the screen, one for each step, corresponding to a given set of tiles.

If your level is, say 128x24, you should store in rom 4 times, one for each phase of the scrolling.

Naturally there are strategies to compact these data in one single map of "metatiles", but with CV basic the easiest thing is to deal with 4 level maps.

If you try Magellan (available on this site, currently maintained by Rasmus Moustgaard) it should able to produce the data needed for smooth scrolling, but IIRC only in ASM and for TI99/A

Actually, if you use screen 1 (graphic1 mode) instead of the "bitmap" mode (graphic2 mode), you have room in VRAM to store 4 (or more) complete tilesets that can be commuted by accessing to VDP(4). In this way your "only" task is to update the PNT during VBLANK.

The side effect is that you can choose only two colors (foreground and background) each 8 tiles. So you can have a very light code but low color details.

 

 

 

 

Edited April 24 by artrag

[artrag]

PS

As Oscar says in the post at his link, if you stay with only two offsets (steps of 4 pixels), you can keep the two tilesets in place, (one in 0-127, the other in 128-255), and just update the PNT.

With two tilesets you need only two maps from where to copy the PNT using the SCREEN command during VBLANK.

 

[OriginalJohn]

I was curious of anyone had success in importing the saved .asm file from the MSX/Coleco sprite editor?   I was trying different settings and using the ASM INCLUDE statement, the DEFINE ... PLETTER statement can't find the label.   Thanks!

[+nanochess]

1 hour ago, OriginalJohn said:

I was curious of anyone had success in importing the saved .asm file from the MSX/Coleco sprite editor?   I was trying different settings and using the ASM INCLUDE statement, the DEFINE ... PLETTER statement can't find the label.   Thanks!

If you use a label inside CVBasic it is added the prefix cvb_*

 

For example, game_bitmaps becomes cvb_GAME_BITMAPS. CVBasic turns all names into uppercase. So maybe you need to provide these to your editor.

 

I don't know about compatibility with the MSX/Coleco sprite editor. Maybe @Tony Cruise can test a little with CVBasic.

 

[OriginalJohn]

1 hour ago, nanochess said:

If you use a label inside CVBasic it is added the prefix cvb_*

 

For example, game_bitmaps becomes cvb_GAME_BITMAPS. CVBasic turns all names into uppercase. So maybe you need to provide these to your editor.

 

I don't know about compatibility with the MSX/Coleco sprite editor. Maybe @Tony Cruise can test a little with CVBasic.

 

Thanks for the suggestion, what's odd, is that if I add CVB in front of SPRITE_PATTERNS_DEFAULT_PL, It adds an extra CVB, the error will read CVB_CVB_SPRITE_PATTERNS_DEFAULT_PL.   If I add it to the ASM label in the file, it does the same thing.   If added to both, same error appears.

 

It would be really cool to have CVBasic specific support in the Sprite Editor with an ASM save option along with a CVBasic format option.   If anyone gets this to work, please share!

[SiRioKD]

Hi mate. I found a bug in the prologue for SG-1000. This machine doesn't use M1 wait states, so the instructions are faster. The following routine should be patched:

 

LDIRVM:
        EX DE,HL
        CALL SETWRT
        EX DE,HL
        DEC BC
        INC C
        LD A,B
        LD B,C
        INC A
        LD C,VDP
.1:     NOP        ; 4 t-states (this is required to wait 29 t-states minimum)

         OUTI        ; 16 t-states (18 on MSX/Coleco)
        JP NZ,.1.  ; 10 t-states (11 on MSX/Coleco)
        DEC A
        JP NZ,.1
        RET

 

 

Saverio Russo 

Edited April 25 by SiRioKD

[+nanochess]

19 hours ago, SiRioKD said:

Hi mate. I found a bug in the prologue for SG-1000. This machine doesn't use M1 wait states, so the instructions are faster. The following routine should be patched:

Thanks for the info!

 

I'll be patched in the next version. In the meanwhile it can be done as you posted, or with this conditional definition to make it portable:

 

.1:

    if SG1000

        NOP        ; 4 t-states (this is required to wait 29 t-states minimum)

    endif

         OUTI        ; 16 t-states (18 on MSX/Coleco)
        JP NZ,.1  ; 10 t-states (11 on MSX/Coleco)

[Jess Ragan]

Yo yo, I've got some truth to throw down for you intermediate programmers out there. If your program is getting complex enough that the performance is starting to sag, cut down on redundancies! For instance, say you've got a score. Instead of PRINTing that score every time the game loops, update it only when your score changes! The graphic data will stay on the screen, and you don't have to waste the CPU's time having it update on every cycle. It'll give the ColecoVision plenty of time to work on other features.

 

Kind of had to learn that lesson myself with the Byron game, the hard way. Free knowledge for anyone who wants it.

[aotta]

9 hours ago, nanochess said:

Thanks for the info!

 

I'll be patched in the next version. In the meanwhile it can be done as you posted, or with this conditional definition to make it portable:

 

.1:

    if SG1000

        NOP        ; 4 t-states (this is required to wait 29 t-states minimum)

    endif

         OUTI        ; 16 t-states (18 on MSX/Coleco)
        JP NZ,.1.  ; 10 t-states (11 on MSX/Coleco)

Is it correct the "JP NZ,.1." or the final dot is a typo? i got an error in case...

 

p.s.: maybe O.T., but just to thank @nanochess for his work, i used CVBasic for menu and file management in my Sega SD-1000 multicart ( https://github.com/aotta/SD-1000 )

Edited April 26 by aotta
p.s. added

[Révo]

Forgot to tell you that since v0.4.4 I've a bad glitch sound for half a sec at the start of my game for SG-1000 (Fullsex (US) - The Game).

[+nanochess]

6 hours ago, aotta said:

Is it correct the "JP NZ,.1." or the final dot is a typo? i got an error in case...

 

p.s.: maybe O.T., but just to thank @nanochess for his work, i used CVBasic for menu and file management in my Sega SD-1000 multicart ( https://github.com/aotta/SD-1000 )

Autocorrector guilty!

 

I never noticed when the computer added automatically the extra period.

 

I've removed it.

 

6 hours ago, Révo said:

Forgot to tell you that since v0.4.4 I've a bad glitch sound for half a sec at the start of my game for SG-1000 (Fullsex (US) - The Game).

I've cleaned the code a lot in v0.4.4 so the interrupts are enabled early.

 

Because the interrupt handler runs early, your song auto-start fails because #vgm_song is zero.

 

I've made this patch at the start of vgm_play and now it works just fine:

 

	IF #vgm_pointer = 0 THEN
		IF #vgm_song <> 0 THEN GOSUB vgm_start
		RETURN
	END IF

 

[+nanochess]

The latest version of CVBasic is now v0.5.0

 

Available here https://forums.atariage.com/topic/365682-colecovision-wonder-tastic-basic-compiler-cvbasic-v050-now-with-bank-switching-support/

 

[Révo]

On 4/26/2024 at 5:40 PM, nanochess said:

Autocorrector guilty!

 

I never noticed when the computer added automatically the extra period.

 

I've removed it.

 

I've cleaned the code a lot in v0.4.4 so the interrupts are enabled early.

 

Because the interrupt handler runs early, your song auto-start fails because #vgm_song is zero.

 

I've made this patch at the start of vgm_play and now it works just fine:

 

	IF #vgm_pointer = 0 THEN
		IF #vgm_song <> 0 THEN GOSUB vgm_start
		RETURN
	END IF

 

No more glitch thank you!

[Tony Cruise]

On 4/25/2024 at 4:22 AM, nanochess said:

If you use a label inside CVBasic it is added the prefix cvb_*

 

For example, game_bitmaps becomes cvb_GAME_BITMAPS. CVBasic turns all names into uppercase. So maybe you need to provide these to your editor.

 

I don't know about compatibility with the MSX/Coleco sprite editor. Maybe @Tony Cruise can test a little with CVBasic.

 

You can change the format that tool outputs the data in, but saying that a "Output to CVBasic" option with the formatting done would be good, I will add that in the next update