Author Topic: Optmising compressed Plus sprites  (Read 8596 times)

0 Members and 1 Guest are viewing this topic.

Offline TFM

  • Visit the mysteries of the CPC at www.futureos.de
  • Supporter
  • 6128 Plus
  • *
  • Posts: 9.899
  • Country: aq
  • Space Chicken for FutureOS is free!
    • index.php?action=treasury
    • FutureOS - The revolution on CPC!
  • Liked: 1985
  • Likes Given: 4650
Re: Optmising compressed Plus sprites
« Reply #25 on: 19:51, 07 October 10 »
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).
 
 
« Last Edit: 21:32, 13 October 10 by TFM/FS »
TFM of FutureSoft
Also visit the CPC and Plus users favorite OS: FutureOS - The Revolution on CPC6128 and 6128Plus

Offline Executioner

  • Supporter
  • 6128 Plus
  • *
  • Posts: 785
  • Country: au
  • WinAPE Developer
    • WinAPE
  • Liked: 394
  • Likes Given: 60
Re: Optmising compressed Plus sprites
« Reply #26 on: 03:57, 13 October 10 »
Another possible routine:

Code: [Select]
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

Offline Sykobee (Briggsy)

  • 6128 Plus
  • ******
  • Posts: 841
  • Country: gb
  • Liked: 317
  • Likes Given: 505
Re: Optmising compressed Plus sprites
« Reply #27 on: 16:46, 13 October 10 »
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.

Offline TFM

  • Visit the mysteries of the CPC at www.futureos.de
  • Supporter
  • 6128 Plus
  • *
  • Posts: 9.899
  • Country: aq
  • Space Chicken for FutureOS is free!
    • index.php?action=treasury
    • FutureOS - The revolution on CPC!
  • Liked: 1985
  • Likes Given: 4650
Re: Optmising compressed Plus sprites
« Reply #28 on: 21:37, 13 October 10 »
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?
 
TFM of FutureSoft
Also visit the CPC and Plus users favorite OS: FutureOS - The Revolution on CPC6128 and 6128Plus

Offline Executioner

  • Supporter
  • 6128 Plus
  • *
  • Posts: 785
  • Country: au
  • WinAPE Developer
    • WinAPE
  • Liked: 394
  • Likes Given: 60
Re: Optmising compressed Plus sprites
« Reply #29 on: 05:54, 14 October 10 »
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]
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.

Offline TFM

  • Visit the mysteries of the CPC at www.futureos.de
  • Supporter
  • 6128 Plus
  • *
  • Posts: 9.899
  • Country: aq
  • Space Chicken for FutureOS is free!
    • index.php?action=treasury
    • FutureOS - The revolution on CPC!
  • Liked: 1985
  • Likes Given: 4650
Re: Optmising compressed Plus sprites
« Reply #30 on: 08:06, 14 October 10 »
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  ;D
...
..
.
... 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  ;D :laugh: ;)
 
 
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
« Last Edit: 08:09, 14 October 10 by TFM/FS »
TFM of FutureSoft
Also visit the CPC and Plus users favorite OS: FutureOS - The Revolution on CPC6128 and 6128Plus

Offline Grim

  • CPC6128
  • ****
  • Posts: 202
  • Country: gp
  • La pak ba, bèf ka pasé
    • THERE IS NO GAME
  • Liked: 134
  • Likes Given: 67
Re: Optmising compressed Plus sprites
« Reply #31 on: 09:28, 14 October 10 »
Code: [Select]
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... :)
« Last Edit: 09:42, 14 October 10 by Grim »

Offline Executioner

  • Supporter
  • 6128 Plus
  • *
  • Posts: 785
  • Country: au
  • WinAPE Developer
    • WinAPE
  • Liked: 394
  • Likes Given: 60
Re: Optmising compressed Plus sprites
« Reply #32 on: 14:57, 14 October 10 »
Well.... and whats about ....
 
 
LD HL,&XXXX:PUSH HL
LD HL,&XXXX:PUSH HL

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

Offline Executioner

  • Supporter
  • 6128 Plus
  • *
  • Posts: 785
  • Country: au
  • WinAPE Developer
    • WinAPE
  • Liked: 394
  • Likes Given: 60
Re: Optmising compressed Plus sprites
« Reply #33 on: 15:09, 14 October 10 »
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.

Offline TFM

  • Visit the mysteries of the CPC at www.futureos.de
  • Supporter
  • 6128 Plus
  • *
  • Posts: 9.899
  • Country: aq
  • Space Chicken for FutureOS is free!
    • index.php?action=treasury
    • FutureOS - The revolution on CPC!
  • Liked: 1985
  • Likes Given: 4650
Re: Optmising compressed Plus sprites
« Reply #34 on: 19:37, 14 October 10 »
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  ;D
TFM of FutureSoft
Also visit the CPC and Plus users favorite OS: FutureOS - The Revolution on CPC6128 and 6128Plus

Offline Longshot

  • Supporter
  • CPC664
  • *
  • Posts: 109
  • Country: fr
    • Logon System Web Site
  • Liked: 114
  • Likes Given: 25
Re: Optmising compressed Plus sprites
« Reply #35 on: 17:05, 29 October 10 »
Quote
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
Rhaaaaaa

Offline TFM

  • Visit the mysteries of the CPC at www.futureos.de
  • Supporter
  • 6128 Plus
  • *
  • Posts: 9.899
  • Country: aq
  • Space Chicken for FutureOS is free!
    • index.php?action=treasury
    • FutureOS - The revolution on CPC!
  • Liked: 1985
  • Likes Given: 4650
Re: Optmising compressed Plus sprites
« Reply #36 on: 23:29, 29 October 10 »
Hey Longshot, good to see you here  :) Right, push takes longer than pop if I remember right ;)
TFM of FutureSoft
Also visit the CPC and Plus users favorite OS: FutureOS - The Revolution on CPC6128 and 6128Plus

Offline Executioner

  • Supporter
  • 6128 Plus
  • *
  • Posts: 785
  • Country: au
  • WinAPE Developer
    • WinAPE
  • Liked: 394
  • Likes Given: 60
Re: Optmising compressed Plus sprites
« Reply #37 on: 01:32, 03 November 10 »
PUSH HL = 4 us

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