VERA 128K

[svenvandevelde]

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

[Lorin Millsap]

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

[svenvandevelde]

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.

[Lorin Millsap]

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

[svenvandevelde]

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

[StephenHorn]

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

[lamb-duh]

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?

[Lorin Millsap]

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

[AndyMt]

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.

[StephenHorn]

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.