Optmising compressed Plus sprites

[TFM]

I remember you've got a 6Mhz CPC?
Has anyone tried making a 6Mhz Plus yet?

Not me, it's more complicated in the Plus. This crystal oszillator is different.

In the good old 6128 you basically have only to switch the Crystal (24 MHz instead of 16 MHz) and the Z80 (B or H instead of A). BTW: The crystals should be switchable (switches for all three connections (but one wire can also be ok, even not in every CPC though)).

Edit: Here (just from my memories) some try of a page:
http://www.cpcwiki.eu/index.php/6_MHz_CPC

Why not skip straight to a 16MHz Z80 CPU? I think the CPC used a 16MHz base clock, divided by four for the Z80 so you'd want to bypass that bit of logic.
Wonder if anyone has a Minimig compatible CPC FPGA implementation yet.

Right. It's a 16 MHz crystal. You can use 6 MHz for the whole system (I did only test few boards!) but not 8 MHz. 8 definitely doesn't work. If the Z80 shall run more quick than 6 MHz then you have to use an own crystal for the Z80 and one for the rest of the system.

The overclocking of the _WHOLE_ system has the following features:
- Faster CPU
- Better Graphics resolution
- Faster Floppy with formats holding 50% more data
- Sound is also better.

Disadvantages:
- Not all expansions can work with the increased bus speed
  (Eprom Boards do, ROM-RAM-Boxes don't do).

[Executioner]

Another possible routine:

Code Select Expand


ld b,xlatcs / 256
repeat 128
  ld c,(hl)   ;2
  ldi           ;7
  ld a,(bc)  ;9
  ld (de),a  ;11
  inc e        ;12
endr

align 256
.xlatcs
repeat 256
  db $ / 16 and 15
endr


[Sykobee (Briggsy)]

Shame the CPC 6128 didn't come at 6MHz by default, I think the Z80B was out by then. Extra costs were a no-no though for Amstrad.

[TFM]

Shame the CPC 6128 didn't come at 6MHz by default, I think the Z80B was out by then. Extra costs were a no-no though for Amstrad.

Why not use 16 MHz? Look at Anne (the PCW Plus , it had a 16 MHz Z80. But even using a good old Z80H with 8 MHz would be nice.

However, if the Plus would have a multiple of 4 MHz if wouldn't be a problem to switch it back to 4 MHz for games (for example, or whenever needed). Amstrad just saved money. To make the ASIC faster could be one problem...

Did ever somebody try to replace the crystal of the CPC Plus?

[Executioner]

You can update all hardware sprites (16) in 16 ms, a frame has 20 ms, just use a LDI:LDI:LDi... construction 

As Grim said, you can't do that, but you can do it with compiled sprites:

Code Select Expand


ld hl,#0304  ;3
push hl         ;8


And sometimes you can get away with 8 bit loads or pushing the same value. Even if you set every pixel individually this way, it's 8 * 128 * 16 = 16384 us plus a bit of overhead for storing the stack pointer.

[TFM]

Well.... and whats about ....



LD HL,&XXXX:PUSH HL
LD HL,&XXXX:PUSH HL
LD HL,&XXXX:PUSH HL
LD HL,&XXXX:PUSH HL ;already 8 bytes transferred.... and counting 
...
..
.
... and so on an on and on...... ok, it uses a lot of memory but, it's damn quick... Now recalculate, but keep in mind folks that the PUSH writes two bytes 


EDIT: To explain this more in detail, the interrupts are off, the SP is saved and at the start of that "load all 16 sprites"-routine the SP points to the upper end of the sprite area (memory mapped I/O activated!) ... And you see you can do it all in one FRAME. TFM frames again...

BTW: I use similar techniques, but way more advanced, for FilmeMacher / MovieMaker

[Grim]

Code Select Expand


ld b,xlatcs / 256
repeat 128
  ld c,(hl)   ;2
  ldi           ;7
  ld a,(bc)  ;9
  ld (de),a  ;11
  inc e        ;12
endr


If the byte fetched by the ld c,(hl) is &00, the following LDI will decrement B. This will screw up the LUT pointer and half of the remaining pixels in the sprite (those fetched from the lookup table pointed by BC). Also, when C=&x0, the LDI will decrement x (which is used for the lookup) and corrupt another pixel. Unless the sprite graphics are not using transparency at all, it seems you're running into some problems with that.

Compiled hardware sprites are fast, but that's quite a big, heavy and sad machinery for a handful of pixels imo. Thank you Amstrad! (should have bought an Amiga sooner... :)

[Executioner]

Well.... and whats about ....
 

LD HL,&XXXX:PUSH HL
LD HL,&XXXX:PUSH HL

Isn't that exactly what I had in my post?

[Executioner]

If the byte fetched by the ld c,(hl) is &00, the following LDI will decrement B. This will screw up the LUT pointer ...

Yes, that's a slight problem, but you can overcome it by restricting it to 15 colours in every second pixel which should be enough in 99.99% of cases. (ie. for pixels A (0..14) and B(0..14), the value stored is (A + 1) * 16 + B and the lookup table translates it back but storing (C / 16) - 1.

The compressed version of the PUSH mechanism can actually be nearly as memory efficient as compressed sprites for less complex sprites. A lot of the time you can simply do something like:

LD H,L
PUSH HL
PUSH HL
PUSH HL
PUSH HL
PUSH HL
PUSH HL
PUSH HL
PUSH HL

for a whole row of one solid colour.

I'm writing something with 3 colour (plus transparent) sprites (like Frogger has) and it just moves values around between registers HL, DE, BC and A and pushes whichever register it needs.

[TFM]

Isn't that exactly what I had in my post?

I don't know... which one was it? Ok... I start reading this looooong thread from the beginning.

But I'm glad that I'm not the only one with such ideas 

[Longshot]

And sometimes you can get away with 8 bit loads or pushing the same value. Even if you set every pixel individually this way, it's 8 * 128 * 16 = 16384 us plus a bit of overhead for storing the stack pointer.

Little error :
LD HL,xxxx = 3 us
PUSH HL = 4 us
7 x 128 x 16 = 14.336 ms

[TFM]

Hey Longshot, good to see you here  Right, push takes longer than pop if I remember right

[Executioner]

PUSH HL = 4 us

Yeah, for some reason I had it in mind it took 5us. So it's even faster than I thought