Jump to content

Question

Dear CX16 team ...

Don't know how to say this but ...

The team should consider to add 256K on the vera, in 4 memory banks!

 

Don't make the mistake to add too less memory.

The VERA should be able to show 640x480x8BPP bitmaps in 256 colors!

I know it will make the machine more expensive, but come on! How much does RAM cost these days!

Pls consider.

Sven

  • Confused 1

Share this post


Link to post
Share on other sites

Recommended Posts

  • 0
Dear CX16 team ... Don't know how to say this but ...

The team should consider to add 256K on the vera, in 4 memory banks!

 

Don't make the mistake to add too less memory.

The VERA should be able to show 640x480x8BPP bitmaps in 256 colors!

I know it will make the machine more expensive, but come on! How much does RAM cost these days!

Pls consider.

Sven

 

The RAM in the Vera is integral to the VERA. We did look at external RAM but it would require a complete overhaul due to timing. And it substantially increases the cost. The next FPGA that has more RAM puts us into a package we don’t want.

 

For the record they types of RAM that are compatible are quite expensive.

 

Not to sound rude, but as is we have way more video memory and color depth than any other 8 bit system and part of the point is for you to come up with workarounds to the limitations.

 

 

Sent from my iPhone using Tapatalk

  • Confused 1

Share this post


Link to post
Share on other sites
  • 0
Just now, Lorin Millsap said:


The RAM in the Vera is integral to the VERA. We did look at external RAM but it would require a complete overhaul due to timing. And it quadruples the cost.

For the record they types of RAM that are compatible are quite expensive.


Sent from my iPhone using Tapatalk

That's too bad (dissapointed). Maybe I should talk dutch to Mr. Van der Hoef ... (just kidding). Anyhow, it's a point that is rather important.

It seriously limits the bitmap capabilties, but yeah, on the other hand, we will then only have 320*200 bitmaps in 256 colors :-(.

But indeed, I must say it gives the machine an extra vintage flavour :-).

Sv.

Share this post


Link to post
Share on other sites
  • 0
That's too bad (dissapointed). Maybe I should talk dutch to Mr. Van der Hoef ... (just kidding). Anyhow, it's a point that is rather important.
It seriously limits the bitmap capabilties, but yeah, on the other hand, we will then only have 320*200 bitmaps in 256 colors :-(.
But indeed, I must say it gives the machine an extra vintage flavour :-).
Sv.

See, there are workarounds that you haven’t even thought of. Some of the demos exploit the limits.


Sent from my iPhone using Tapatalk
  • Like 1

Share this post


Link to post
Share on other sites
  • 0
1 minute ago, Lorin Millsap said:


See, there are workarounds that you haven’t even thought of. Some of the demos exploit the limits.


Sent from my iPhone using Tapatalk

Inspire me 🙂 ... Looking for the truth ...

Share this post


Link to post
Share on other sites
  • 0
42 minutes ago, svenvandevelde said:

we will then only have 320*200 bitmaps in 256 colors

Or 320*240 @ 256 colors. (76,800 bytes of the 129,472 available)

Or 640*480 @ 4 colors. (76,800 bytes of the 129,472 available)

Or double-buffered 640*480 @ 2 colors. (76,800 bytes of the 129,472 available)

Or 640*480 @ 4 colors plus a second layer 640*480 @ 2 colors. (115,200 bytes of the 129,472 available)

Clever image authoring and color cycling can animate displays without having to modify pixel data.

Or using the second layer as a tilemap for repeating 8x8 or 16x16 tiles at 256, 16, 4, or 2 colors.

Tilemaps can specify their palette offset on a per-tile basis, so you could have a 16-color tilemap with up to 16 palettes.

There are lots and lots of things the VERA can do.

Edit: And I almost forgot about parallax effects. With clever authoring of tilemaps, combined with layer scrolling, you can create parallax effects. With clever use of line IRQs you can fake multiple layers of parallax. With strategic use of sprites as well you can fake an almost arbitrary number of overlapping layers of parallax, as long as you don't go over the 801 work units of sprite data allowed per line (described elsewhere on the forums).

Edited by StephenHorn
  • Like 2
  • Thanks 1

Share this post


Link to post
Share on other sites
  • 0
2 hours ago, Lorin Millsap said:

The RAM in the Vera is integral to the VERA. We did look at external RAM but it would require a complete overhaul due to timing. And it substantially increases the cost. The next FPGA that has more RAM puts us into a package we don’t want.

is there any possibility of getting the full 128k for general purpose video ram, or do the registers at the end of the address space eat up that same ram?

Edited by lamb-duh

Share this post


Link to post
Share on other sites
  • 0
is there any possibility of getting the full 128k for general purpose video ram, or do the registers at the end of the address space eat up that same ram?

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


Sent from my iPhone using Tapatalk
  • Like 2

Share this post


Link to post
Share on other sites
  • 0
11 hours ago, lamb-duh said:

or do the registers at the end of the address space eat up that same ram?

I think they do.

Share this post


Link to post
Share on other sites
  • 0
5 hours ago, AndyMt said:

I think they do.

Based on the behavior of the "palette" portion of VRAM ($1FA00-$1FBFF), I think the registers at the end of the address space do map to VRAM that does technically exist but is unusable because it is shadowed to other components, so a write to this range goes to both VRAM and the component.

I don't know what the Verilog looked like to separate VRAM from the other components, but I assume it was necessary to remove in order to free up resources to support other VERA features, like sound. Even if I don't personally plan to take full advantage of the VERA's sound capabilities, I agree that the VERA was the right choice for adopting these features when suitable chips were not available on the market, as opposed to rolling a separate audio FPGA and daughterboard. It's no more or less "magical" than any other FPGA solution, but helps keep the cost of the X16p down.

  • Like 1

Share this post


Link to post
Share on other sites
  • 0
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!

Share this post


Link to post
Share on other sites
  • 0

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

Edited by svenvandevelde

Share this post


Link to post
Share on other sites
  • 0
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

Share this post


Link to post
Share on other sites
  • 0
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

2021-01-24.png

Space.prg Space.c

Share this post


Link to post
Share on other sites
  • 0
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

2021-01-24.png.ffbc9e81bb88b1fd6652cd8d970918d4.png

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
  • Like 4

Share this post


Link to post
Share on other sites
  • 0
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

 

  • Like 1

Share this post


Link to post
Share on other sites
  • 0

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.
 

Share this post


Link to post
Share on other sites
  • 0

@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.

Share this post


Link to post
Share on other sites
  • 0
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).

Share this post


Link to post
Share on other sites
  • 0

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).

  • Like 1
  • Thanks 1

Share this post


Link to post
Share on other sites
  • 0
1 hour ago, svenvandevelde said:

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

I don't know what you expected... there's (almost) nothing more vintage than 6502 😛

Edited by Guybrush
  • Haha 1

Share this post


Link to post
Share on other sites
  • 0

The key to all of this is that limitations breed creativity. Embrace the limits. Then find ways around them. Very often the end result is something greater than if you had done it the easy way.

  • Like 8

Share this post


Link to post
Share on other sites
  • 0

Hell, you could almost halve your sprite memory usage for that ship just by shading it so the light source is directly on the vertical axis. Then you could remove half of the axial roll frames and use the VERA's horizontal flipping to pretend the other half exists.

But I agree with others that, ultimately, the VERA is best suited for 320x240 graphics, which is appropriate for the 8-bit era.

The SNES was 256x224. Would you believe that was smaller than the NES's 256x240? The Genesis/Master System was 320x224. PC games as late as Wing Commander: Privateer and Descent (the latter being a fully 3D game with texture shading) were 320x240 resolution. The PS1 was technically a 640x480 platform, but you'll notice that the sprite work in games like Castlevania: Symphony of the Night were still 320x240.

Share this post


Link to post
Share on other sites
  • 0

Embracing it will be. Another day ... another challenge... One thing is a fact. I'm already having LOADS of fun with the CX16! Many funny days are coming. I have another question but I need to ask in another thread. Thanks all.

Share this post


Link to post
Share on other sites
  • 0
Posted (edited)

What I don't like is the lack of sufficient VRAM in the VERA. Even in 4bpp, memory runs out fast. Especially if you want to embed spritee animations. With the hardware capabilities of the VERA, memory is underscaled when using the high resolution 640x480 in tiled mode.

An example ... 12 sprites of 32x32 pixels in 4bpp requires $1800 bytes. But in high resolution 32x32 px is very little. 64x64 px quadruples the memory requirement... then you talk about $6000 bytes. And that is for just one "healthy" sprite animation ... beside that, you need explosions, damaged states, shadows, overlays like glowing effects, bullet types. So per enemy type you can easily consume $8000 to $A000 bytes (when in 64x64). And note that all this is in 4bpp. When using 8bpp that requires a multiple by 2. So 12 sprites in 8bpp 32x32 consumes about $3000 bytes. In 64x64 mode that would be $C000. That's 1/3 of the VERA VRAM, for one healthy enemy.

An interactive arcade game would easily have 6 to 8 different enemy types on the screen requiring animations, damage states, bullets, shields, glowing etc.

Noting that the VERA has 128 different sprites that can be shown simultaneously I really am afraid that memory upscaling is a requirement to use the full potential of the machine.

Edited by svenvandevelde

Share this post


Link to post
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.

Guest
Answer this question...

×   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.


×
×
  • Create New...

Important Information

Please review our Terms of Use