"VERA" Prototype (From David Murray on FB)

May 22, 2019
229
108
43
This is a copy of David's post on Facebook. I am occasionally bringing you news from the Facebook group, as big things are announced. What follows is David's announcement, not mine.

---


First working prototype of the “Vera” video daughter board, which is currently rigged up on a cartridge board for the Commodore 64 for testing. This is a custom video chip that connects to the data bus so it is very fast! The picture is beautiful on a VGA monitor. Default text mode is 80x60, but has several other modes such as 40x30 and 20x15. Bitmap graphics and sprites aren’t fully implemented yet, there will be more on this later. We hope to make this card (or a slightly more elegant version of it) available for developers with the C64 being the host for now.

154
 
Last edited:

Panda

New Member
Not having much luck finding information about the VERA graphics chip.

Does it go my another name? model?

I would love to know more about the specifications of the chip,

- How to activate various graphics modes
- Information about the memory map
- How to implement scrolling and sprite capabilities.

If any details exist, please let me know but I am happy to wait if this is something still being prepared.

Just eager to start programming.

On a side note:
So far my searches have revealed

- There's a British TV crime series called "Vera"
- A German graphic designer by the name of Vera Kuesgen.
- David Murray's posts of Facebook about the VERA
- an apparent US government conspiracy to implant citizens with RFID chips.

All make for interesting reading :)
 
May 22, 2019
229
108
43
This is a custom GPU, probably built into an FPGA. I don't think you're going to find documentation on it anywhere, since the person who built it for David invented it.
 
  • Like
Reactions: Panda
May 22, 2019
229
108
43
This is a good starting point
The team has also released the prototype emulator and Peogrammer’s Reference guide.


 
  • Like
Reactions: Mike

Funnybones

New Member
Sep 12, 2019
10
5
3
Anyone else having a problem with the emulator where using disk operations return "?ILLEGAL DEVICE NUMBER ERROR"?

Strangely the command DOS"$" seems to work but returns an empty directory.

I'm on Windows 10

EDIT* Oh .. nevermind. LOAD"$",8 works.. I thought the video said only ,1 (Default) had been implemented...
 
Last edited:

zhulien

New Member
Sep 13, 2019
1
0
1
Awesome... What is the chance you can make generic boards available for fitting to other computers also... Such as Amstrad CPC?
 

Panda

New Member
Anyone else having a problem with the emulator where using disk operations return "?ILLEGAL DEVICE NUMBER ERROR"?

Strangely the command DOS"$" seems to work but returns an empty directory.

I'm on Windows 10

EDIT* Oh .. nevermind. LOAD"$",8 works.. I thought the video said only ,1 (Default) had been implemented...
The default device is device 1. You can type LOAD"$" for a directory listing of the folder on your local drive.

DOS"$" only works for the disk drive devices 8,9,etc
 

Funnybones

New Member
Sep 12, 2019
10
5
3
The default device is device 1. You can type LOAD"$" for a directory listing of the folder on your local drive.

DOS"$" only works for the disk drive devices 8,9,etc
Yeah.. ,1 wasnt working.

It was a bug :


Which has been subsequently fixed.
 

Wertyloo

New Member
Sep 15, 2019
23
1
3
i really hope that,as its have its own mem, would not hog the cpu as to transfer like a max resolution pic from mem to vidmem in "lda mem,x:sta vmem,x" style
as in the c64 you simply poke 56576,150: poke 53272,21 and the VIC would atomatically generate the screen from that memory part[16384:8k bitmap],hence no need to copy all the data to a specific mem-location, you set the VIC registers to the right mem-address
 

Wertyloo

New Member
Sep 15, 2019
23
1
3
really would be a good thing if the vidchip can acces/copy from on its own from the 2M ram,while the cpu can run in its own dedicated 64k space
i mention that, the switchable 8k-space can be used to be directly-mapped to the vidmem[it can be done by dedicate 1bit to it on the vidchip registers]
by set the bit then the 8k part not the ext.2M map in,but the vid mem directly[means you write the 8k part then you write into the vmem diretly]
it would be awesome from a demo or a game point of view
 

Wertyloo

New Member
Sep 15, 2019
23
1
3
consider to not just 8k switchable but more like 8k/16k as you got a really big screenres. compared to the cpu addr.space or the cpu-speed-compared-to-movable-data
as the cpu dont have spec. data-chunks moving instructions or a spec hw like blitter or dma
 

Wertyloo

New Member
Sep 15, 2019
23
1
3
8bitguy mentioned that in the vid, in the half-loaded screen,that not abble to load a full res pics in 1 go, if you want still a high res -not to mention a interlace pic- one,then add a function in the vidchip -as you already would manufacture it- a load from pheripherial to memory function
no need direct file-load just like add a counter that can be set by the user,then load a byte from the bus put on the addres, address++, counter--,while counter>0 repeat
like the bytes from the bus put directly on the set address
the user can read on the counter if its still not zero then wait,or you can add a register bit,or most preferably a IRQ like the irq-mask-register on c64[you can read the approp bit to know nmi,vid,rasterirq,timeirq event]
the cpu got the irq when the data transfer is complete,it makes a programmers life most easy
more easy to program->more prgs->more users->more popularity
 

Wertyloo

New Member
Sep 15, 2019
23
1
3
from a pov of games and demos:
how many sprites?
how the sprite animation data transferred into the vmem?
animdata in the vmem on in the 2M space or in a directly-mapped-in 8k/16k/32k memchunk?
the sprite registers number and function?
would be some atomic[frequently used functions] implemented on HW level?[linedraw would be so much aprrec.ed: imagine from a software implemtation, every point calculated by the cpu,then for every point the data transfrerred into the vmem,wait for complete,calc next point,
while in hw: commandcode+beginpoint+endpoint,wait for commandregister say ok,next]
 

Wertyloo

New Member
Sep 15, 2019
23
1
3
how would the cpu and the vidchip connceted/controlled?
will be here like rasterirq? to know what part of the screen been already drawn to do nice demo-y tricks
can be used any nice hw-tricks like fli on c64?
i already can see tricks with the hw-line-draw: overwrite registers in the right moment to draw a circle instead a line... :)
 

knapik

New Member
Sep 13, 2019
3
3
3
Hope I'm not hijacking a thread here. Has there been any thought behind having a 15kHz horizontal sync option from the VERA so that original commodore monitors can be used?
 

Wertyloo

New Member
Sep 15, 2019
23
1
3
at it seems, the graphics data moving by the cpu[see the youtube vid. at the half-loaded pic] is simple too much for the cpu[and clearly dont fit in the cpu-accessible mem],maybe a solution can be integrated into the fpga vidchip like:
 
May 22, 2019
229
108
43
I think the problem was a bit... constructed.

An 8 bit CPU can decode a GIF just fine; the problem is that there's not enough main memory on that system to fully buffer the image to RAM before pushing it to the GPU.

However, there is up to 2 megabytes of banked memory, and the decoder could certainly decode directly to VERA. I'll go out on a limb here and suggest that a GIF viewer actually designed for the Commander will have no problem with anything that's sized appropriately for the Commander's display.
 
  • Like
Reactions: MonstersGoBoom