"VERA" Prototype (From David Murray on FB)

May 22, 2019
491
251
63
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?
I believe there is a plan for composite video and S-Video. This would certainly cover the 1702 and similar monitors.
 
  • Like
Reactions: knapik

Wertyloo

Member
Sep 15, 2019
72
7
8
ahem,still the huge-amount-of-data-moving-among-different-memory-parts is still stands
coz' the vidchip can acces only its dedicated ram for build the actual screen, the data NEEDS to MOVED THERE 1st
even if the cpu can run in its 64k part,the data copy still be need to done from ext.2M->screen128k
how its done? spec. DMAcircuit? BLITTER? and if data in 2M IS graphics,why dont load DIRECTLY into the screenram the graphics data?
ehhh...
what about integrate a 6502-like core into the vidchip-fpga: it access directly the screenram,can run programs from here(GPU on a 8bit!),can programmed do primitives [line,circle,etc],move the sprites/bckrd data,read from IEC bus to directly screenram
you programming it what to do,no external horde of registers,the local cpu can acces internally from the fpga
no need to put many registers into the normal cpu 64k space
just load the approp. prg into the screenram,start localcpu[gpu]
just a few registers needs to controll on the cpu side
and needs fever hw-lines on the actual manufatured board
 

Wertyloo

Member
Sep 15, 2019
72
7
8
if you integrate cpu into the vidchip you can syncronize its running to the vidcip screenbuild
i do not need to say how awesome is that,do i? [espec. from a programmer's view]
demos and games can get a huge advantage from that,ask just the8bitguy,or any how write a bigger game with non-static graphics
 
May 22, 2019
491
251
63
If you look at how the MSX computer did graphics, this is the same basic design.

VERA is connected through an 8-byte data channel, with 3 bytes used to set the current address, two bytes for data transfer, a general control channel, and two channels for reading the scan information.

Raw data transfer through this channel can theoretically be 1 byte per clock cycle. However, the system does not currently have a DMA controller (this is planned, if I recall), and so transfer speed is going to be more like 1 byte every 20 CPU cycles. However, due to maximum 15-byte stagger, those speeds are only obtainable on horizontal fills. You would still need to set the address (at least one extra CPU write) when moving the address pointer by more than 15 positions.

While hardware-accelerated drawing are certainly possible, it's also a bit "modern" for the design David originally proposed, and I doubt they will add features like that. I'd certainly welcome them, but I don't expect them to happen.

I don't know if blitter is in the works or not, but that would be a nice feature to have. (Blitter, or bit-blit, is a generic term for hardware-accelerated memory transfer. Pretty much all modern graphics chips move data around internally at hardware speeds, rather than making the CPU do that work, so it's much faster.)

As to integrating a CPU into VERA.... I'm pretty confident that won't happen.
 
  • Like
Reactions: MonstersGoBoom

Wertyloo

Member
Sep 15, 2019
72
7
8
omg,you still transfer all gfx-related data[be it char,sprite-anim,640x480x8bit gfx,etc] byte-by-byte trough a SINGLE 8bit databus[that needs extra sync on the vidchip part,coz' its write that into its own memoryspace]
there will be dragons... ehem,laggs... serious laggs on the cpu as it simply tansfer lda-sta style huge amount datas
there just not enough of any speed in the world to do it, and not to feel its impact on the users side:
huge lags on any time gfx moved, imagine on bitmap windows moving: the cpu do it trough 1 byte!
or on contrarary: a locally integrated cpu IN the vgamem where from the vidchip gets the screendata
no need to be the vga-cpu be any full-fledged 6502,just enough funcionality to be useful
i dont need to say why are full-fleged-gpus on any vga-card novadays,and why busmater+dma any sound/video card
you literally can get enough mhz for the cpu, if you want to do these with it
and these are 64bit 1.6Ghz or upper speeds with mmx,avx,etc spec. commands
in commanderx16 a 8bit cpu 8bit databus no bulk transfers or matrix-cpu-opcodes or 4channel 4pumped datalines with relatively huge gfx-data[640x480!],you NEED to build integrated spec circuits to do data transfers, NEED tricks that lower the amount data-to-transfer, or it WILL feel like a c64 from speed perspective when run any real-life app
i done it,when i was a part of a group that did the same with a hand-held highly embeded hardware:
it got ~200Mhz cpu and was incredibly slow until we made the data-transfer partially independent from the cpu,then was quite ok, i still using it for around 6years now
it is a oscilloscope-like electronic test handheld instrument with integrated display 256mb mem,etc
so lots of data and computed gfx
so like, if you can write the data directly into the vgamem, write here, not to a 64k/2m space then transer that again into vgamem,etc
end
thnx for the attention
 
May 22, 2019
491
251
63
I'm going to be honest... I'm not really sure what all you're trying to say, because your messages are nigh-unreadable. So i'm not going to try to address them point by point.

This is a 1985 computer, with 1985 technology. Think about that for a minute before reading on.

1985.

What was the state of the art then? The term "GPU" had not yet been invented. The IBM AT had just been released, and the Apple Macintosh and Commodore Amiga were just barely hitting double-digit clock speeds.

And the MSX2 computer actually HAD just been released, with a whopping 3.58 MHz. Since this computer is supposed to run at 8MHz, and the 6502 is already 2.4x as fast as a Z80 at any given clock speed, this computer will perform more like a 19MHz MSX and probably faster than a 12MHz AT.

And the MSX was just fine for gaming. In fact, the AT was also just fine for gaming - without any of the things you're proposing. (Or I think you're proposing, since I can't actually read most of your post.)
 
  • Like
Reactions: MonstersGoBoom

Wertyloo

Member
Sep 15, 2019
72
7
8
greetings!
what i'm proposing is that, given the cpu-speed and the amount of needed gfx data to be transferred, and the WAY its transferred into the video-ram, currently will hog the central cpu greatly
cpu to video data transfer always a bottleneck
and because the video hw will be designed and not a from-the-self [not already manufactured fix design] chip with some clever pre-planning we can off-load lot of unnecessary work from the cpu to the vid-chip
whitin reason we can add newer functions to the hw from the programmers/gamedesigners/democoders point of view to avoid pitfalls[like drop what will be unused and add instead some atomic frequently used functions]
atomic operation: like moving mem blocks inside the vid mem[like dragging a window across the screen: lots of mem-copy operands], now imagine that amount of data moved trough the current method with the central cpu!
 

Wertyloo

Member
Sep 15, 2019
72
7
8
i dont know how many sprites will be,but more means more number of registers,thats currently will be accessed in the 64k cpu area: needs hardwired from the chip to the destination
raster registers 16bit [640x480] and many more controll-registers
the integrated cpucore into the vidchip that can manipulate these registers is a solution: fewer pins , no additional layer on the board
plus you can program it to fit the given task, like switch into bitmap mode inside of a window while around the window is text mode
the code run from inside the video memory to not use the central data bus unnecess.ly
a small simple core is fine,synchronised to the video chip can add many more benefits too
 
May 22, 2019
491
251
63
i dont know how many sprites will be,but more means more number of registers,thats currently will be accessed in the 64k cpu area: needs hardwired from the chip to the destination
raster registers 16bit [640x480] and many more controll-registers
the integrated cpucore into the vidchip that can manipulate these registers is a solution: fewer pins , no additional layer on the board
plus you can program it to fit the given task, like switch into bitmap mode inside of a window while around the window is text mode
the code run from inside the video memory to not use the central data bus unnecess.ly
a small simple core is fine,synchronised to the video chip can add many more benefits too
Ah. You might want to wait and see what happens. There are two graphics layers and a ton of sprites... lots of what you're asking for can be done with the hardware as designed.
 
  • Like
Reactions: MonstersGoBoom

Wertyloo

Member
Sep 15, 2019
72
7
8
I obviously will wait

And already a prg-code running video-processing unit here,as the fpga IS one

I dont say per se to integrate hardware cpu core here, you just program the fpga's logical gates to behave as one[the fpga can be reprogrammed as many times as you want on the fly,its already load a program from a firmware when turned on automatically by hw design,sometimes the firmware integrated into the fpga,and crypted as well]

The8bitguy wanted a highly integrated small board, you can only do that on a custom designed board,if you put something highly integrated custom cirtcuit-or something that can behave as one- here
all the registers accesible this cpu is also inside this chip: no external dips/hw-elements,physical wires on the PCB->lots of additional element-savings

I proposed a 6502-compatible core ,because,then dont need to learn another cpu-style-mnemonicks[assembly instructions]
wire all the peripherial databus through the fpga as well,then with the vera, can transfer directly from the SD card samples to the soundchips or video data into the 128k vidram or track-load-the-GCR-codes into the unused videoram[fastload from 1541disk] a full disk-track or use as a cooproc WHILE the central cpu can have all its cycles and 64k ram to do something

its like what commodre did with its intelligent discdrives[like 1541/II], 6502cpu+2k_ram+cia
just its now this cpu's workingspace in the videoram.
use videoram unused regions to do things[run code,cache data,directly decompress data to videomemory,draw a line/circle/box,etc. ],access directly ALL the video proc inner registers do do neat tricks,write/read to/from a compressed data format/track/drivepart without hogging the central cpu

beacuse its a cpu-like circuit with its own opcodes,memoryspace, you program it as you want,manipulate registers cleverly,use ram efficiently

Wire a irq line to the cpu to get attention when finished doing its work
A spec. inner register, when its writed then syncronize this cpu freq/running to the videochip -the clock cycles ere the same source- ,to do time-critical video register/memory manipulations

Does the dev team read this forum? i would like tho share some of this[as a fellow programmer,game dev.er,demomaker] with them,maybe they fancy some of the ideas... where can i contact with 'em?
 
Last edited: