the way the spectrum arranges the screen

[777]

im trying to write a program in basic that fills the screen from top to bottom. unfortunately ive got a bit lost in the maths of it.

here is what i have so far but i cant seem to think how to go any further with it.

[Bubu]

Hi, [mention]777[/mention], try this:

[777]

ty, wicked.. it works!

slow though aint it?

[Bubu]

Yes, slow as hell, but it's BASIC, man. That's why I program in assembler, and not in BASIC. BASIC is "tile (8x8)" based, not "pixel" based.
Anyway you can make your BASIC program and then compile to assembler, that's "compiled BASIC" called, and it will go fast that way.

[Bubu]

You can try this:




That's perhaps the fastest way in BASIC, but here you're only drawing horizontal lines, not filling each video memory address...

[PeterJ]

Run these two programs [mention]777[/mention]:

Code: Select all

10 FOR X = 16384 TO 22527
20 POKE X,255
30 NEXT X

Code: Select all

1 CLEAR 31999
10 FOR X=32000 TO 32014
20 READ A: POKE X,A
30 NEXT A
35 RANDOMIZE USR 32000
40 DATA 33,0,64,1,0,24,54,255,35,11,120,177,32,248,201

Program from 'Cracking The Code'

It's crucial to learn about the screen layout before you do anything more that very simplistic assembler. There is a great thread here with links to explanations of the layout:

viewtopic.php?p=55

[+3code]

im trying to write a program in basic that fills the screen from top to bottom. unfortunately ive got a bit lost in the maths of it.

You can fill the attributes area, that will be faster, something as

Code: Select all

10 FOR X = 22528 TO I_cant_remember_it_now
20 POKE X,0
30 NEXT X

[Bubu]

I_cant_remember_it_now = 22395

[Bubu]

Run these two programs @777:

Code: Select all

10 FOR X = 16384 TO 22527
20 POKE X,255
30 NEXT X

But [mention]777[/mention] asked for filling the screen from top to bottom, and with that program it will not do so.

Code: Select all

1 CLEAR 31999
10 FOR X=32000 TO 32014
20 READ A: POKE X,A
30 NEXT A
35 RANDOMIZE USR 32000
40 DATA 33,0,64,1,0,24,54,255,35,11,120,177,32,248,201

And that's not BASIC, that is assembler, and I can guess that there's a LDIR

[PeterJ]

Hi [mention]Bubu[/mention],

I was just giving an example of the speed difference as he was saying how slow BASIC was.

Your example BASIC is very good. Be good to run it in Boriel BASIC and see the speed increases.

[Bubu]

Aaaaah, OK Yes, BASIC is 1000 times slower than assembler

[MatGubbins]

I_cant_remember_it_now = 22395

23295 is your friend (or 23296-1 for the rest of us)

[p13z]

If you really want to do it quickly in BASIC, use PRINT, it's a fast command. Just print a line of solid UDG 30 times.
If you want to be addressing screen memory directly, and getting quick results, use MC / assembly.
BASIC can be surprisingly quick - but only when you play to it's strengths, think laterally and learn to avoid slow commands. PRINT is quick, all of the drawing commands are slow. Generally worth filling up UDGs, fonts and strings and sacrificing a bit of memory if you don't want painful slowness.

[Bubu]

Yes, you're right!!! I wrote from my poor memory (less than 1K )

The thing is this:

The start address is 163884. There are 32 columns and 192 lines, so:

16384 + 32*192 = 22528

And now, for colors, there are 32 columns and 24 rows, so:

22528 + 32*24 = 23296

[777]

xxx

[777]

Code: Select all

1 CLEAR 31999
10 FOR X=32000 TO 32014
20 READ A: POKE X,A
30 NEXT A
35 RANDOMIZE USR 32000
40 DATA 33,0,64,1,0,24,54,255,35,11,120,177,32,248,201

ok, thank you...

ive looked at the assembly listing of this and it doesnt really do what i want it to do. i want it to draw line by line from the top to the bottom of the screen. i slowed it down using the halt instruction and its just drawing the way that the screen memory is laid out...

i know that this will be much more complex to do...

[Cosmium]

ok, thank you...

ive looked at the assembly listing of this and it doesnt really do what i want it to do. i want it to draw line by line from the top to the bottom of the screen. i slowed it down using the halt instruction and its just drawing the way that the screen memory is laid out...

i know that this will be much more complex to do...

You're right, it's more complicated because you have to calculate the address of the next line down if you want to fill it "line by line" rather than sequentially POKEing screen memory, which fills it the way it's laid out.

This modified program calls a "next line down" subroutine at the end of every line to work out the start address of the next line, and should do what you want.

Code: Select all

1 CLEAR 31999
10 FOR X=32000 TO 32035
20 READ A: POKE X,A
30 NEXT X
35 RANDOMIZE USR 32000
40 DATA 33,0,64,14,192,6,32,229,54,255,35,16,251,225,205,21,125,13,32,241,201,36,124,230,7,192,125,198,32,111,216,124,214,8,103,201

Oh, and here's the disassembly

Code: Select all

	ld hl,16384
	ld c,192
l2:
	ld b,32
	push hl
l1:	ld (hl),255
	inc hl
	djnz l1
	pop hl
	call next_line_down
	dec c
	jr nz,l2
	ret

next_line_down:
        inc h
        ld a,h
        and 7
        ret nz
        ld a,l
        add a,32
        ld l,a
        ret c
        ld a,h
        sub 8
        ld h,a
        ret	

[PeterJ]

Nice work [mention]Cosmium[/mention]!

[Morkin]

Code: Select all

next_line_down:
 inc h
 ld a,h
 and 7
 ret nz
 ld a,l
 add a,32
 ld l,a
 ret c
 ld a,h
 sub 8
 ld h,a
 ret	

This is one of those eternal routines that most assembly programmers will use (or a variant of). It'll probably be CALLed thousands upon thousands of times during a program for any drawing of graphics.

What I like about it is for a beginner you don't really have to worry about how it works or what it's doing... You just CALL it, with HL pointing at the current screen display position, and trust it that it'll correctly update your pointer to be pointing at the next pixel line down.

[777]

beautiful... ty

Post edited by PJ

[jorgegv]

I_cant_remember_it_now = 22395

Well, it is 23295 in fact. You misplaced a couple of figures

[Miktor]

The ZX Spectrum screen layout makes my tiny little brain hurt.

[SNG]

The ZX Spectrum screen layout makes my tiny little brain hurt.

It’s done that way to save 5.25K of attribute memory - without it, the 16K Spectrum would’ve had less than 4K free for BASIC.

[+3code]

I readed that blog entry long time ago: http://oldmachinery.blogspot.com/2014/0 ... s.html?m=1

I find it very instructive, the BASIC examples are nice.

[Hedge1970]

Just having my third shot at machine code and figuring out the screen is very hard (or seemingly very unintuitive) indeed especially moving between Hex and Dec. I look forward to working through that blog post once the festivities are over.