Commander X16

18 hours ago, Lorin Millsap said:

Nope. VERA is complete. The spec is set. Only bug fixes if there are any here on out.

oh, I like that answer even more!

Well ... After careful consideration, I really think that the available VRAM in the VERA is underscaled, according its resolution and color depth capabilities. I'm sorry to say that.

I'm trying to load in a resolution of 640x480 screen 24 different sprites in 64 x 64 x 4BPP. I need 49.152 to store the data for these sprites.

No problem for the CX16 RAM banks, where there is 512KB of ram available, so this can easily fit in a RAM bank. But in the vera, this is an issue. That is 3/4 of a VRAM bank in vera.

So I have only 64KB left practically of VERA VRAM. If I need to add then other animated sprites, then the VRAM really becomes too small. 128Kb is not enough.

I know the answer: you can scale up the screen, or, you can reduce the sprite resolution. I know, I tried first to load 24 sprites of 64x64 resolution in 8BPP.

For that, you need 98.304 bytes. That is 2/3rd of the VERA VRAM!

 

The issue is that the VERA cannot do direct addressing in the RAM banks of the CX16 itself, but through "ports" ...

- One always need to copy the data into the VRAM. That drastically slows down speed in games!

- One cannot load a nice tile base of let's say 48 tiles in 32x32 + 64 animated sprites of 64x64 resolution.

Impossible in terms of memory, but also impossible to make games smooth. 

 

I know this message is a bit of a pain.

Sven

Well ... After careful consideration, I really think that the available VRAM in the VERA is underscaled, according its resolution and color depth capabilities. I'm sorry to say that. I'm trying to load in a resolution of 640x480 screen 24 different sprites in 64 x 64 x 4BPP. I need 49.152 to store the data for these sprites. No problem for the CX16 RAM banks, where there is 512KB of ram available, so this can easily fit in a RAM bank. But in the vera, this is an issue. That is 3/4 of a VRAM bank in vera. So I have only 64KB left practically of VERA VRAM. If I need to add then other animated sprites, then the VRAM really becomes too small. 128Kb is not enough. I know the answer: you can scale up the screen, or, you can reduce the sprite resolution. I know, I tried first to load 24 sprites of 64x64 resolution in 8BPP. For that, you need 98.304 bytes. That is 2/3rd of the VERA VRAM!   The issue is that the VERA cannot do direct addressing in the RAM banks of the CX16 itself, but through "ports" ... - One always need to copy the data into the VRAM. That drastically slows down speed in games! - One cannot load a nice tile base of let's say 48 tiles in 32x32 + 64 animated sprites of 64x64 resolution. Impossible in terms of memory, but also impossible to make games smooth.    I know this message is a bit of a pain. Sven

So figure out the workaround. Part of the charm is to figure out the solution. Drop your resolution, drop your color depth. Figure something out. You make it work. You aren’t getting more VRAM.   Sent from my iPhone using Tapatalk

1 minute ago, Lorin Millsap said:

So figure out the workaround. Part of the charm is to figure out the solution. Drop your resolution, drop your color depth. Figure something out. You make it work.





Sent from my iPhone using Tapatalk

Hello Lorin,

I'm afraid it will be a showstopper for many. And I do understand the issue, when the team is already moving foward into production with the third prototype, after the issues were fixed with the 2nd prototype.

The VERA made my blood go faster, having seen the modes and the 640x480 resolution, but once I started to really use it in the emulator, I noticed that memory availability and memory addressing is going to be really a limitation and it really locks down on the possibilities.

Check out the attached program. Please consider carefully the feedback of your users. 

Sven



Space.prg
Space.c

Hello Lorin,
I'm afraid it will be a showstopper for many. And I do understand the issue, when the team is already moving foward into production with the third prototype, after the issues were fixed with the 2nd prototype.
The VERA made my blood go faster, having seen the modes and the 640x480 resolution, but once I started to really use it in the emulator, I noticed that memory availability and memory addressing is going to be really a limitation and it really locks down on the possibilities.
Check out the attached program. Please consider carefully the feedback of your users. 
Sven



Space.prg
Space.c

To me the solutions are obvious. Firstly drop your resolution. Use 320x240. Secondly since your resolution is lower, drop the sprite size too. It is for you to work around the hardware limitations, not for the platform to move the goalposts for you.

You keep wanting more VRAM. I’m telling you that it can’t be done in this iteration and isn’t going to happen. You say you understand why. I don’t think you do. Say we wanted external VRAM. Ok. Doing that requires more pins than we have. How would you connect it? We don’t have the pins. Even if we did have the pins now you have to deal with timing, which means you cant just use any RAM. You either need very fast SRAM which is expensive, or DRAM with the refresh circuitry. Now all the sudden the VERA costs more than the original goals for the whole project. Now you start to understand why similar projects are in the $500-$1000 price range. I think dealing with a few hardware limitations is better than dealing with an expensive but obscure hardware platform.


Sent from my iPhone using Tapatalk

18 minutes ago, Lorin Millsap said:

To me the solutions are obvious. Firstly drop your resolution. Use 320x240. Secondly since your resolution is lower, drop the sprite size too. It is for you to work around the hardware limitations, not for the platform to move the goalposts for you.



You keep wanting more VRAM. I’m telling you that it can’t be done in this iteration and isn’t going to happen. You say you understand why. I don’t think you do. Say we wanted external VRAM. Ok. Doing that requires more pins than we have. How would you connect it? We don’t have the pins. Even if we did have the pins now you have to deal with timing, which means you cant just use any RAM. You either need very fast SRAM which is expensive, or DRAM with the refresh circuitry. Now all the sudden the VERA costs more than the original goals for the whole project. Now you start to understand why similar projects are in the $500-$1000 price range. I think dealing with a few hardware limitations is better than dealing with an expensive but obscure hardware platform.





Sent from my iPhone using Tapatalk

I see. So we are really facing the limits of the era of the technology of 8 bit. I'll follow up your advice and see what that brings us. Thanks for explaining, so it's not just about the memory, it's about the way the hardware was designed in early days.

Didn't mean to be arrogant or upset you. We are programming here, and using the machine, learning it. I hope you understand that also we need to get used to this a bit.

After your explanation I start to understand now better. So downsizing is the message ... Thank you. You can close down this post.

Check out the vera resolution demo I've posted if not done already. ...

This demo may not seem like a big deal, however, in the background a framework is in the make to control the vera in a user friendly C-code way.

Vera Modes - Demo - Graphics Apps - Commander X16™ Community

Kind regards,

From a big fan

 

Guys, thanks you very much for this conversation. Very enlightening.

I didn't play (yet) on the graphics side of the beast. So pretty informative, your exchange.

And I do understand now why I read on another thread a complaint about the intf with the VERA being serial.

I saw some systems with a fast and efficient serial intf. No problem. So I was a little surprised by the comment.

But I missed something of importance.... if you don't have the aperture, you should have the storage.

Hence, I understood now, the wish for more RAM on the VERA.

That means we will have ways of improvements for the future next versions ?

And that is a good news.

 

@svenvandevelde I would just like to say that even the Amiga and Atari ST games were 320*200 or something similar. So were most the PC games well into the 90's. Commander X16 is an 8-bit computer, and those were 16 or even 32-bit.

Use the 320*240 mode for games (or software in general) with loads of colors and sprites.

Use the 640*480 mode for GUI applications or  with 2 or 4-bit color.

If you want more memory, fork the emulator, it should only be a couple of changes.

2 minutes ago, Guybrush said:

@svenvandevelde I would just like to say that even the Amiga and Atari ST games were 320*200 or something similar. So were most the PC games well into the 90's. Commander X16 is an 8-bit computer, and those were 16 or even 32-bit.



Use the 320*240 mode for games (or software in general) with loads of colors and sprites.



Use the 640*480 mode for GUI applications or  with 2 or 4-bit color.



If you want more memory, fork the emulator, it should only be a couple of changes.

@GuybrushYes, but the thing is, in lower resolutions the stuff looks ... well ... yeah ... vintage ...

I'm listening though ... I think it has been a while since I've been working at 320x200. It's getting back used to the resolution I guess ...

I'll post something once i have it working (close).

It hasn't been mentioned yet but the other option if you're really wanting a 16-bit machine, is the C256. It's quite the machine in its own right but it is VERY different from the X16 and certainly a lot more complex. The two projects have fairly different goals it would appear but it may be more up your alley as it does have up to 4MB of VRAM (2MB in the more affordable iterations).