Commander X16

Thanks for the info.

A square is determined by four values.
what are these values for copying the rectangle?

Thanks.

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

hstubbs3 wrote: ↑Sun Mar 24, 2024 4:39 am
But like my personal project I am working on needs to extend the sprite capability... Organizing the sprites into up to 255 Z layers and doing more then 128 sprites by efficient copying in software...

At least this copying sprites around should work.. the blitter is still theoretical since I got distracted playing around with color quantization and dithering stuff... In Python... So can prep files on another machine to import into x16 code...

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

BTW - does anyone reading this happen to know if it is a hardware quirk OR is it just a bug in the x16 emulator that copying from VRAM into the Sprite Attribute table doesn't result in any changes in the sprites that are being drawn?? EVEN if the copy is during V-blank...

and I am working with 16 color / 160x120 screen.... maybe will switch to 215x161 if there's enough clock cycles for the blitter to do more stuff after game logic like enemies and the water simulation ... probably the fairly standard-ish cellular automata style that most people would start with augmented by "Wave Particles " http://www.cemyuksel.com/research/waveparticles/

https://github.com/hstubbs3/CommanderX1 ... ites/hex.s

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.

Nothing at all wrong with copying VRAM to VRAM if its already there.

funkheld wrote: ↑Sun Mar 24, 2024 12:49 pm Thanks for the info.

A square is determined by four values.
what are these values for copying the rectangle?

Thanks.

Function Name: GRAPH_draw_image Signature: void GRAPH_draw_image(word x: r0, word y: r1, word ptr: r2, word width: r3, word height: r4); Purpose: Draw a rectangular image from data in memory Description: This function copies pixel data from memory onto the screen. The representation of the data in memory has to have one byte per pixel, with the pixels organized line by line top to bottom, and within the line left to right.

X,Y are where to put it on screen. Ptr is the address of the Image Data. width & height are the width and height of the image in Pixels. They are passed to the routine by populating r0-r4 with the appropriate values before Calling GRAPH_draw_image

ahenry3068 wrote: ↑Sun Mar 24, 2024 1:11 pm Nothing at all wrong with copying VRAM to VRAM if its already there.

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

but switch the debugger screen on in the emulator and check VRAM contents at $1:FC00 and my sprite attributes would be just sitting there mocking me..

I spent far too long stressing over it last weekend, only to patch around it and just use LDA DATA0 / STA DATA1 to make sure I hadn't mucked up something else

the particular bit of assembler I patched around is here -
https://github.com/hstubbs3/CommanderX1 ... hex.s#L473

hstubbs3 wrote: ↑Sun Mar 24, 2024 1:27 pm

ahenry3068 wrote: ↑Sun Mar 24, 2024 1:11 pm Nothing at all wrong with copying VRAM to VRAM if its already there.

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

but switch the debugger screen on in the emulator and check VRAM contents at $1:FC00 and my sprite attributes would be just sitting there mocking me..

I spent far too long stressing over it last weekend, only to patch around it and just use LDA DATA0 / STA DATA1 to make sure I hadn't mucked up something else

the particular bit of assembler I patched around is here -
https://github.com/hstubbs3/CommanderX1 ... hex.s#L473

Take this with a grain of salt... I haven't done ANYTHING with VERA FX yet myself.
I might try reinitializing the sprite attributes after doing the copy.

Oops... no.. buffer was at $1EC00 ... because I left the PETSCII tileset alone so I could use it for debug text..

( and this is why one uses comments and global variables / definitions ) the code just references VRAM_SPRITE_BUF ( as LDA #>VRAM_SPRITE_BUF+1 as I was reserving 32 sprites for some debug outputs at that point.. so only 96 sprites to copy.. )

if anyone cares to give it a go... here's just the bit doing the cache writes into sprite attribute table -

Take this with a grain of salt... I haven't done ANYTHING with VERA FX yet myself.
I might try reinitializing the sprite attributes after doing the copy.

I did try disabling / re-enabling video, but only as a very quick thing _after_ the copy... maybe disable sprites, do the copy / re-enable sprites??

Or... potentially it is really just a hardware quirk, as I haven't tried it on hardware yet... I haven't taken time to clear off my desk and setup my X16 devkit .. >_>

But, I am aware of a quirk like that with the Sega Mega Drive's VDP ... Which had you configure where the sprite attribute table was in VRAM ... but if you altered the sprite table address register during active display, the sprite attribute CACHE wouldn't update, so some of the info like X or Y coordinates would still use the old values... unless you poked them directly ... as writing to the underlying addresses forced a cache update for that address ...

can't find the youtube video I saw about that ... but sprite reuse/multiplexing was a fun trick on that platform to make effect like the rain in some stages of Streets of Rage (2 or 3? can't recall/didn't play it ) or the mirrored/underwater bits in that Castlevania game on the Mega Drive...

egad I do love me some good Video Chip (ab)use ?

Peep what the tile map looks like in the VRAM debugger view vs what is displayed on-screen here ...

https://www.youtube.com/watch?v=AUc1aNj ... 143&t=43s




now why can't the VERA have per-line scroll tables ?

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.