ugBASIC forum

Hello there,

I am new to ugBasic as it is best things I have found and give a try as managed got 2 Sprites on screen(I am using C64 Compile to run program) so quick compare to doing Assembler!

I know C64 Ram is like 44k for Games and 20k for C64 OS. What I would like to know is if I was making Sprites on screen or tilemap on Screen as I would like how many Memory K left.

Another things i seem think Tilemap is good things to have to save memory as like R Type(I dont know if they did tilemap back in 80's)

1) I dont know everythings about ugBasic and C64 Memory. Please can you help me on C64 Memory that knowing how many is memory K left.
2) I seem think C64 can only display 8 Sprites on screen at once......is that Correct?
3) Tilemap is good things to have Scrolling like R Type but dunno how much memory take in thought.

Please reply and I would be interesting reading Answers and learning from ugBasic people.

Hi Apidya, and welcome on the forum!

Apidya wrote: ↑Tue Aug 19, 2025 8:18 pm I know C64 Ram is like 44k for Games and 20k for C64 OS. What I would like to know is if I was making Sprites on screen or tilemap on Screen as I would like how many Memory K left.

Apidya wrote: ↑Tue Aug 19, 2025 8:18 pm 1) I dont know everythings about ugBasic and C64 Memory. Please can you help me on C64 Memory that knowing how many is memory K left.

This is a very interesting question, and deserves a thorough answer. First, the ugBASIC compiler for the Commodore 64 uses all of the available RAM, without relying on ROM. This means that, theoretically, about 55 KB is available. However, this does not include the areas dedicated to the VIC-II.

The compiler ensures that all the memory needed for VIC-II is placed in bank #2 ($8000-$BFFF), both in graphical mode and in timemap (text) mode. So, regardless of how much graphics you load, 30,718 bytes of low memory ($0801-$7fff) and 4,096 bytes of high memory ($c000-$cfff) are available. The last is an area where both graphical resources and game variables can be stored, but not executable code.

Since ugBASIC uses the system loader to load the program, before disabling ROM, this latter area was removed a few releases ago to reduce the size of the executables (PRG files). It would, however, be possible to re-enable it, and I'm considering doing so with a directive.

Apidya wrote: ↑Tue Aug 19, 2025 8:18 pm Another things i seem think Tilemap is good things to have to save memory as like R Type(I dont know if they did tilemap back in 80's)

Yes, absolutely. Tilemap mode allows you to reduce the memory footprint of graphic elements because they are reused. However, it is a much more useful mode for reducing the amount of graphic resources you need to move for certain effects, such as scrolling. In fact, to scroll a full screen 8 pixels to the left, for example, in text mode you only need to move about 2 KB, while in bitmap mode you need to move no less than 9 KB (I'm going from memory with the dimensions, but the order of magnitude is that).

Apidya wrote: ↑Tue Aug 19, 2025 8:18 pm 2) I seem think C64 can only display 8 Sprites on screen at once......is that Correct?

The video chipset (VIC-II) can handle up to 8 hardware sprites (24x21 pixels for monochrome, 12x21 pixels for multicolor). This limitation, however, can be overcome in software with the use of "multiplexing": essentially, there are 8 hardware sprites but they are "reused" as the video raster scrolls across the screen. There is, of course, a limit of 8 sprites per vertical "slot" of the video, so you can't, for example, have 10 staggered sprites, because since a sprite is 21 pixels high, that "slot" can hold no more than 8 sprites.

The ugBASIC language contains instructions that allow you to use multiplexed sprites directly from the program, without having to implement this feature manually. In this case, you have 32 monochrome sprites available, which ugBASIC can also handle in "overlapping" mode, to create very large, multi-colored sprites. To learn more, click here, or download the ugBASIC USER MANUAL and see chapter 8.

Apidya wrote: ↑Tue Aug 19, 2025 8:18 pm 3) Tilemap is good things to have Scrolling like R Type but dunno how much memory take in thought.

The memory occupied by a tilemap is 6 KB: 4 KB for the complete 256-tile charset, 1 KB for the color attributes, and 1 KB for the tilemap itself. All of this memory falls within the VIC-II's area of responsibility, so it doesn't take up program space. Specifically, everything could be loaded by the system loader at startup, as could the tilemap and color attributes.

I used the conditional because, currently, it doesn't do so because I haven't implemented it.
So you're forced to load the data into the program, which will then have to copy it into the VIC-II's RAM.

I should add that using bank #2 allows us to have the system tileset (PETSCII charset) without performing any loading, but this results in 4 KB less memory to store our tileset. Therefore, a different memory layout mechanism will need to be implemented if automatic loading is desired.

I hope my answers were helpful, and feel free to write more.

Hello again,

Thank you for making me welcome.

Thank you for great answers. There is lots to take all that information's in. I think going useful for me and everyone as well because they will be reading this too.

55 KB is available? That is nice and would be nice to have commands like MemoryAvailable as then you make somethings on screen and it would you tell you how many Memory kb you got left.

Another things I would like to ask is how many screen that ugBasic can do in Commodore 64 emulator(that somethings I dont know about it.)

I would like to ask you about The Shadow of beast with tile layers. I seem think what they did back then was copy one tile layer to offset tile layer then you get loopy scroller tile effect.

I did that in blitzbasic pc years ago of doing for next loop and it work and I did like try that ugBasic.

First I have wait for your answer.

Hi Apidya!

Apidya wrote: ↑Wed Aug 20, 2025 10:42 pm 55 KB is available? That is nice and would be nice to have commands like MemoryAvailable as then you make somethings on screen and it would you tell you how many Memory kb you got left.

If you are using the UGBASIC-IDE, you can obtain already this information by selecting the "additional info" option under the Build > Options.... You will find out the size of the executable under the "bytes" column of "Assembly" tab.

Apidya wrote: ↑Wed Aug 20, 2025 10:42 pm Another things I would like to ask is how many screen that ugBasic can do in Commodore 64 emulator(that somethings I dont know about it.)

I'm not entirely clear on the question. The Commodore 64 has only one frame buffer, which is interpreted in text or graphics mode. In text mode, you can change the starting address of the character component in 1KB increments, so we're talking about a maximum of 16 screens (actually, there are 12 screens, due to the 4KB occupied by the character set), although the color component must remain at the same address, which makes this feature of little use. In graphics mode (bitmap), there are two alternatives, and at least one of them is useless with bank 2, again due to the character set.

The ugBASIC language provides instructions for this, but for the Commodore 64 they are not very useful, due to the fact that for performance reasons the addresses are precomputed at compile time -- and therefore changing them at run time can lead to unexpected results.

Apidya wrote: ↑Wed Aug 20, 2025 10:42 pm I would like to ask you about The Shadow of beast with tile layers. I seem think what they did back then was copy one tile layer to offset tile layer then you get loopy scroller tile effect.
I did that in blitzbasic pc years ago of doing for next loop and it work and I did like try that ugBasic.

If you refer to this video, I don't think the parallax effect is achieved with multiple screens, as was the case on the Amiga with Blitz BASIC, for example. In this case, I get the impression that the character set has been calibrated to ensure that any scrolling produces this effect. And, indeed, if you watch the video, you can see that the parallax is limited. If you want to know more, on this page the topic is deepened more.

Have a nice day!