Graphic, Sound, & Coding Tips / Tricks / Effects / Etc. Tools for development

[touko]

@bonk:I use a custom huc, but i'am writing all my code in asm and all routines are custom/rewrited .
I let only huc managing the banks data .

@chris: No hblank timing, i'am only loading a simple background(no interrupt but vblank),i also tried with a simple Txx with SEI before,no code in my interrupt routines,same result .

[touko]

Hi, i did some tests on my SGX with the two methods for copying bytes between VRAM .
lda/sta and trb/tsb with 255 loops, on my sgx (with display off and on,same result)and trb/tsb is much faster,seems 2 raster lines less than lda/sta .

I don't know how take trb/tsb exactly compared to lda/sta , but less cycles for sure .

switching x-res to 512 pixels, has no effect,result is more or less the same, all two seem to be faster but not by a lot.
My tests confirm the ~15 cycles / instruction (trb/tsb $0002 and $0003),lda/sta are much slower .

lda/sta between the 2 vdc,is roughly the same, even if it is a little bit faster .

The question is, why TIA has the expected results(7 cycles/byte), when the others have not ??
My conclusion is ,reading VDC is much slower than writing .

[elmer]

My conclusion is ,reading VDC is much slower than writing .

Interesting results, thanks for doing the tests.

I wonder if Hudson put a 1-deep-write-buffer into the VDC chip so that the CPU wouldn't normally have to be delayed (beyond the single-cycle that we know about), and then the VDC could actually write the 16-bit value a few VDC cycles later when the next access-slot comes around.

It couldn't to that to a read request, and would (potentially) have to delay the processor until the next access-slot plus maybe an extra VDC cycle to handle delays within the chip itself.

I've got absolutely no proof, this is just an off-the-cuff theory to explain the results.

[touko]

interresting, but if you have a read/write buffer, isn't here for no delay(or at least the less as possible)

[elmer]

interresting, but if you have a read/write buffer, boring , but if you have a read / write buffer , isn't here for no delay(or at least the less as possible)

That's why I said "write-buffer", not "read-write-buffer" ... they're different things. 

IMHO, it wouldn't make a lot of sense to design the VDC to pre-read the read-pointer into a buffer because you've got limited bandwidth, and you're much-more-likely to be using it for writing to VRAM.

Wouldn't a pre-read also be a lot more complicated to implement in silicon, especially for a function that doesn't get used that much?

Don't the timings seem to show that we can write as-fast-as-possible (except for the added 1 cycle on all VDC accesses)?

[Bonknuts]

You know.. I don't remember if I tested just straight reading from the VDC during active display.

[touko]

But why reading the VDC is slower ??

[Bonknuts]

I don't think it's reading that's slower, but switching back and forth between reading and writing.

[touko]

I don't think it's reading that's slower, but switching back and forth between reading and writing.

I noticed the same thing for read/write between the two VDCs.

[Bonknuts]

TED mapping and register info updated on first post with links.

[Bonknuts]

Dynamic tiles:

 You figure a topic like this would have been talked/discussed to death, but there was something I thought was easy in approach, but helped rid the graphic look of short repetitive tile patterns.

 The idea is as follows: Have different dynamic images (sets of 8 frames), but make them all have a common shared tile on the left and the right. Then you could seem them all together for a long pattern that didn't look like it consistently repeats; it'd look closer to a tilemap layout rather than dynamic tiles.

 Depending on how you implement it, it does have its limitations and resource drag, but it can help break up shallow patterns with little resource overhead if done right.

[Bonknuts]

I find that macros are a nice way to do Case type scenarios (compare lists):

Code: [Select]

__DecodeMainFX:

        __CreateCase #$0c, __DirectVol
        __CreateCase #$0f, __SetSpeed
        __CreateCase #$0d, __PatternBreak
        __CreateCase #$e9, __NoteReTrigger
  rts

   
   
__DirectVol:
  rts
 
__SetSpeed:
  rts
 
__PatternBreak:
  rts

__NoteReTrigger
  rts

[Bonknuts]

This belongs here:

ccovell: How did I not know about this demo!?

I've asked myself that question, too.  :-|  Maybe people were preoccupied at the time.

Anyway, depending on the odd/even phase of the VCE at the time that you make it static, dithered patterns consistently give either a usable red (verging a tiny amount towards orange) channel over 15 shades, or a cyan (harder to wrangle because it is 2 RGB channels combined.)  So:


Another test demo: http://chrismcovell.com/data/OldIsBeaut-Test.zip

I didn't use any special tools; removing the R channel from 24-bit pictures is good enough, and the R can be remapped separately to greyscale, or some ramped red/grey; the remaining G&B can be remapped down to PCE BG palettes, since there are now 64 colours possible per tile that have to be reduced.

[elmer]

This belongs here:

Definitely! You guy are talking about really esoteric and fascinating stuff here ... way beyond my level as a "practical" programmer. It's a brilliant read! 

[Bonknuts]

Something for PCEAS:

Code: [Select]

AlignByte256  .macro
  .org ( (* + 255) & $ff00)
 
  .endm

Like this:

Code: [Select]

    AlignByte256
MyData: .incbin "mydata.dat"

 Just in case you anyone didn't know how to do alignment in PCEAS. Plus, the macro makes it look clean.

 Also, if you include your binary on the same line as your label, you can use sizeof() in PCEAS.