Commander X16

Yazwho wrote: ↑Sun Mar 24, 2024 4:33 pm The cache doesn't work with VERAs registers ($1:F9C0+), only 'normal' VRAM.

Does that mean the 32-bit cache is a way to write to the underlying VRAM at those addresses, without disturbing the registers there?

DragWx wrote: ↑Sun Mar 24, 2024 7:02 pm

Yazwho wrote: ↑Sun Mar 24, 2024 4:33 pm The cache doesn't work with VERAs registers ($1:F9C0+), only 'normal' VRAM.

Does that mean the 32-bit cache is a way to write to the underlying VRAM at those addresses, without disturbing the registers there?

Sadly not, its limited in code. Would be fun though, opens up the last 1600 bytes.

https://github.com/X16Community/vera-mo ... ata.v#L690

Yazwho wrote: ↑Sun Mar 24, 2024 4:33 pm

hstubbs3 wrote: ↑Sun Mar 24, 2024 1:27 pm Using the 32-bit cache??
The issue I hit into was... I staged sprite attributes at $1:F600 ... and then in V-sync interrupt switch on the FX stuff, read starting at $1:F600 into cache... do cache writes starting at $1:FC00 ... and never see the sprites on-screen...

The cache doesn't work with VERAs registers ($1:F9C0+), only 'normal' VRAM.

Figures but is that _documented_ somewhere and I just missed it?
oh.. right.. someone linked to the FPGA source... because of course it's not mentioned anywhere else??

Its not a blocker of an issue, its only 1KB max to copy, being on the VERA is nice for the copy still due to auto-increment ...

ahenry3068 wrote: ↑Sun Mar 24, 2024 1:03 pm

hstubbs3 wrote: ↑Sun Mar 24, 2024 12:55 pm

ahenry3068 wrote: ↑Sun Mar 24, 2024 8:48 am

Just a suggestion: I'm looking at copying Sprites around myself. Take a look at memory_copy ($FEE7)


On the Graphics layer side I have also found GRAPH_draw_image ($FF38)useful (It's basically bit_blt or Put_Image).

The current GRAPH_draw_image is not "BANK Aware" thus when blitting from BRAM you are limited to 8192 bytes (Practical limit a 90x90 or 100 x 81 image). That's still a bigger image than a 64 x 64 Sprite. In the Newest ROM build MooingLemur has extended the routine to be "BANK Aware" So it can blit up to a full Screen 320x240 image. It takes about 14 Jiffies to Blit a Full Screen Image to the Graphics Layer if it is preloaded in Banked RAM. With a 100x75 image I'm blitting >15 fps. https://cx16forum.com/forum/viewtopic.php?t=7191


At the risk of Blatant self promotion. GRAPH_draw_image is used in HANGMAN when showing the Body Parts I'm loading from BitMap. It's also used in the 'FLAWLESS VICTORY" Animation. I don't use any Sprites in HANGMAN at all.

Like there are proficient developers in the community,

I actually don't have a lot of familiarity with BASIC for this system... or Prog8... or even C ... or anything higher-level... than assembler..

how many clock cycles is a "jiffy" ?

my intention was copying VRAM to VRAM using the 32-bit cache, as what I am copying is sprite graphics that are already in VRAM ...

I haven't had a chance to implement it yet but I was planning on caching the sprite image data in Banked Ram and copying from there to VRAM. A jiffie is around 130000 cycles I believe it's very close to 1/60th of a Second. In assembly you can get the "Jiffie" count by calling RDTIM. In BASIC it's available in the system variable TI. The count returns Jiffies since system start. (Any heavy disc I/O and anytime you do SEI/CLI blocks will affect the accuracy of this.) The routines I indicated above are in System ROM and easily called from assembly.

~14/60th of a second to blit a full screen at _what_ resolution and with any sort of loop unrolling or other optimizations??


btw initial blitting >128 16x16 16 color sprites from VRAM to buffer apparently puts me right at 30 fps.. 60fps with the hardware sprites enabled? ( definitely need to double-check the timing code to be sure.. )

https://www.youtube.com/watch?v=dMr8j1CRTt8

the code calculating addresses is pretty horribad right now too.. but is interesting that without the hardware sprites is likely a lot of things would be aspiring to steady 30fps ..

The timing is at 320x240 Mode $80 graphics layer. So it's a 76,800 byte Blit. It's definitely not 30 fps but remember this is from BRAM to VRAM. It's pretty useful for Graphics Backgrounds. 1/4 second load is still pretty quick and faster then if you loaded Direct from Disc (though you probably have to load from Disc to put it in BRAM to begin with) ...


I don't know about any optimizations. It's a routine already in ROM. And you can't do that big a blit except with the latest Build. Originally GRAPH_draw_image was NOT Bank Aware so it wouldn't wrap. MooingLemur did the modifications just a very few weeks ago. It will be Bank Aware on the next official release.

BTW: I'm doing all this from BASIC. The numbers are a lot more impressive when you consider that I've got the overhead of a SYS call from BASIC that Preloads the Registers from BASIC Ram then does the JSR then Caches all the Register Values on Return.

GRAPH_draw_image only works with 8 bit data to the 256 color Graphics Layer.