News:

Printed Amstrad Addict magazine announced, check it out here!

Main Menu
avatar_ComSoft6128

Locomotive BASIC - Pixel-Scroll-Routine by Olaf Sandmann

Started by ComSoft6128, 13:12, 17 November 22

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

ComSoft6128

Type-ins from the September 1986 issue of the German 'Happy Computer' magazine. The programs are Listed in the video.


Links:
https://www.cpc-power.com/index.php?page=detail&num=14406
https://www.cpc-power.com/index.php?page=detail&onglet=notices&num=14406
https://www.cpcwiki.eu/index.php/Happy_Computer

Not emulated - original hardware and software.
Please note that  the aspect ratio for this YouTube video is 16:9 but the CPC monitor
has an aspect ratio of 4:3 so you may wish to adjust your viewing device accordingly.

Animalgril987

That's really rather good, particularly considering that it's a magazine type-in. :D

asertus

These old "BASIC" programs that were basically assembler in DATA lines...  ;D

Urusergi

Two improvements ;D

ORG #8000
DI
LD A,25
LD DE,#C000
LD HL,#C800

L8009: LD BC,#0050
PUSH HL
LDIR
POP DE
LD HL,&0800
ADD HL,DE
JR NC,L8009

LD BC,#C050
ADD HL,BC
DEC A
JR NZ,L8009

LD B,C

L801E: LD (DE),A
INC DE
DJNZ L801E
EI
RET
ORG #8000
DI
LD A,25
LD DE,#C000
LD HL,#C800

L8009: LD BC,#0050

L800C: PUSH HL
LDIR
POP DE
LD C,#50
LD HL,&0800
ADD HL,DE
JR NC,L800C

LD B,#C0
ADD HL,BC
DEC A
JR NZ,L8009

LD B,C

L801F: LD (DE),A
INC DE
DJNZ L801F
EI
RET

Prodatron

And this :D

ORG #8000
DI
LD A,25
LD DE,#C000
LD HL,#C800
L8009: PUSH HL
        REPEAT 80
LDI
        REND
POP DE
LD HL,#0800
ADD HL,DE
JP NC,L8009
LD BC,#C050
ADD HL,BC
DEC A
JP NZ,L8009
        LD L,E
        LD H,D
        INC DE
        LD (HL),A
        REPEAT 79
        LDI
        REND
EI
RET

GRAPHICAL Z80 MULTITASKING OPERATING SYSTEM

ComSoft6128

Thanks for the replies @Urusergi & @Prodatron.

So how exactly do these improve on the original?

Prodatron

Original: 100.508 microseconds/pixelscroll (~ 5 frames)
Urusergi: 99.826 microseconds/pixelscroll  (~ 5 frames)
Prodatron: 83.444 microseconds/pixelscroll (~ 4 frames)

...but my one uses about 350bytes vs. about 35bytes (original/Urusergi) ;)

GRAPHICAL Z80 MULTITASKING OPERATING SYSTEM

Urusergi

@Prodatron A little faster 8) (~346 bytes - 83361us)
ORG #8000
DI
LD A,25
LD DE,#C000
LD HL,#C800
L8009: PUSH HL
        REPEAT 80
LDI
        REND
POP DE
LD HL,#0800
ADD HL,DE
JP NC,L8009
LD BC,#C050
ADD HL,BC
DEC A
JP NZ,L8009
        REPEAT 79
        LD (DE),A
        INC DE
        REND
LD (DE),A
EI
RET

TotO

"You make one mistake in your life and the internet will never let you live it down" (Keith Goodyer)

Axelay

Quote from: ComSoft6128 on 11:29, 18 November 22So how exactly do these improve on the original?

I've read this as 'what code changes' rather than 'how is it better', so I'll describe some of the optimisations in case that is what you meant.  The alternate code presented is uncommented anyway, so maybe someone will benefit from a brief explanation of a couple of things.

The biggest single speed increase comes from using a string of 80 LDI instructions rather than LDIR (Prodatron example).  LDIR is 6 microseconds per iteration, except the last one which is 5 because it doesn't repeat on the final iteration.  LDI does the same thing without the repeat so is also only 5 microseconds.  So a list of LDIs will do the same thing as LDIR, 1/6 faster but at the cost of extra memory.

In the examples by Urusergi, it has replaced a couple of 'beginner' things from the original code.  The original source used
PUSH HL
...
POP HL
LD D,H
LD E,L
This has been replaced by
 
PUSH HL
...
POP DE
with a small change to the following maths to make that work.

Similarly, the original source used
LD BC,#3FB0
AND A
SBC HL,BC
when the line calculation overflowed beyond the end of screen memory.  The AND A is required to clear carry because you can only do a 16bit subtraction with carry, and you don't want carry in the calc.  But it is 1 microsecond faster to use
LD BC,#C050
ADD HL,BC
which achieves the same result, because #10000 (all 64k of memory) minus #3FB0 is #C050.  Although, because the last instruction before the original code was a JR NC, you know carry is always set, so I think you could have also just adjusted the value you put in to BC and removed the AND A to still use SBC.

The last example from Urusergi has optimised the last section of Prodatron's example, where the bottom line of pixels is cleared.  Instead of using another LDI string after loading the first byte with 0, it uses a string of 79 repeats of
LD (DE),A
INC DE

which is 1 microsecond faster than LDI.  The last line starts at #F780 though, so the next 80 bytes are in the same 'page' (all #F7xx), so I think you could get away with an INC E would be a further 1 microsecond faster again with the same result.

Axelay


GUNHED

And all that only works if the screen hasn't been scrolled before.  :P
http://futureos.de --> Get the revolutionary FutureOS (Update: 2023.11.30)
http://futureos.cpc-live.com/files/LambdaSpeak_RSX_by_TFM.zip --> Get the RSX-ROM for LambdaSpeak :-) (Updated: 2021.12.26)

Urusergi

Quote from: Axelay on 01:14, 19 November 22I think you could have also just adjusted the value you put in to BC and removed the AND A to still use SBC.
Yes, I also thought about that possibility but ADD is 1 us faster and takes up one byte less than SBC

Quote from: Axelay on 01:14, 19 November 22The last line starts at #F780 though, so the next 80 bytes are in the same 'page' (all #F7xx), so I think you could get away with an INC E would be a further 1 microsecond faster again with the same result.

You're right! the last line really starts at #FFB0 and It's only necessary to decrease E. I didn't find that optimization :doh:
Now the routine runs in 83282 us. Thanks :)

Axelay

Quote from: Urusergi on 20:51, 19 November 22
Quote from: Axelay on 01:14, 19 November 22I think you could have also just adjusted the value you put in to BC and removed the AND A to still use SBC.
Yes, I also thought about that possibility but ADD is 1 us faster and takes up one byte less than SBC


Gah!  You're right.  I was thinking of the 8 bit ones being the same time.  :doh:

Powered by SMFPacks Menu Editor Mod