# Plotting a single dot on screen

Página 2/4
1 | | 3 | 4
Chilly Willy wrote:

Being tactful by saying that I asked how to plot a single point. I will expand on that formula and program later but to ask "why would I want to do that" instead of an answer like come on dude....

You totally misunderstood the reply ... He was trying to help you. As other have said, plotting just a single pixel on screen is not an easy job (see PingPong explanation). So maybe trying to see past that initial request and ask you exactly what your need was, was a good idea because it would probably lead to a different solution, maybe a simpler one, depending on your need.

OK, now, we know that you're writing a drawing program.

Technically whether it is 768 8x8 blocks it still adds up to 256x192

Being that was the early design of the chip.

My question should have been strait forward.
What is the formula to plot a single dot anywhere on that 256x192 grid.

I can set up all the rest of the routine such as color and what not.
I just need the working formula.

Sort of like HPLOT in Apple Basic.

Chilly Willy wrote:

Technically whether it is 768 8x8 blocks it still adds up to 256x192

Being that was the early design of the chip.

My question should have been strait forward.
What is the formula to plot a single dot anywhere on that 256x192 grid.

I can set up all the rest of the routine such as color and what not.
I just need the working formula.

Sort of like HPLOT in Apple Basic.

the formula was already given in this thread. If, as you stated, you've already done z80 asm, it should not a complex task to code. There are no complex operations to do only math perfectly doable with z80 asm.

Chilly Willy wrote:

Technically whether it is 768 8x8 blocks it still adds up to 256x192

In fact, it's 3x256 blocks of 8x8 in SCREEN2.

To trace a single dot on the screen, you can use the SETC routine (0120h) of the BIOS of the Main-ROM.

The BIOS has routines to do this, so you could track one of those with a debugger. Or just use the BIOS, because it's there and probably not much worse than something you could come up with yourself. It doesn't sound very difficult, but I doubt many people have laying such a routine around, because it's something you want to avoid if possible, just like divisions.

Something like this: (highly untested and unoptimized but give an idea)

on input h = y, l = x
on output
de: points to vram byte of pattern table

alterations: a, de, b

```ld h, 18 ; assume h = y
ld l, 15 ; assume l = x

; vramaddr = int(y/8) * 256 + int(x/8) * 8 + y and 7

; (x/8)*8 stored in e
ld a, l
and 248
ld e, a

; (y/8) * 256  stored in d
ld a, h
sra a
sra a
sra a
ld d, a

; y and 7
ld a, h
and 7

ld e, a

; DE= adress of byte in vram at (x,y), now get the bit mask.
ld a, l
and 7

or a
jr z, done

ld b, a
ld a, 128
loop:
srl a
djnz loop
done:
nop

```

obviously this is the easy part. Even if the formula works correctly you need to deal with the idiosyncrasies of the pattern attribute and color attribute tables in order to do the right thing based on the situation as i've described above

Just a suggestion: switch to v9938 and bitmap mode, just fill the correct registers and let the vdp do the work for you.
Considering the fact that you need to vram setup address to read/mask/write a byte for the pattern table and again the same for the color table + some logic to deal with the issues decribed above, the pset on screen 5 via vdp is way way waywaywaywaywaywaywaywaywayway faster than on screen2

most of spectrum users complain about slow vram access on msx. i think is not so slow on typical operations, unless you try to do this kind of things. What you are trying to do IS EXACTLY the kind of thing where the MSX suffers a lot in performances compared to systems where vram is electrically connected to z80 bus (ZX for example, but also CPC, or C64).

Btw, I could swear I saw another thread with this same question last month, but I can’t find it.

Edit: Ah, it was here: https://www.msx.org/forum/msx-talk/development/software-spri...

Grauw wrote:

The 256×192 pixels of screen 2 are organised as 8×8 patterns in a grid of 32×24. Each 8×8 pattern is made of 8 bytes. By default the name table is set up so that the patterns patterns follow each other in sequence from left to right top to bottom.

You need to first calculate the address of the byte in the pattern table: base address | ((y & 248) << 5) | (x & 248) | (y & 7). Then you read that byte from VRAM, set bit x & 7, and write it back.

Hopefully that provides enough of a starting point to get the grasp of it.

| = or
& = and
<< = left shift

Note that `add a,a` and `add hl,hl` are quick alternatives to `sla r`.

To be more precise, the C64 does not have vram connected to a Z80 bus but I get your point . Indeed when programming the MSX1 VDP like this it becomes slow and certainly is not making optimal use of it. If performance indeed is not an issue I would say solve it in the correct MSX way and use the BIOS

I have a ready routine in the book I read to learn msx asm coding. Never tried ot but it should work:

hl=coordinates(h=y l=x), a=color

```Setxy:
push af ;save color
ld a,191 ;a=y
sub h ;a=191-y
ld h,a ;y=191-y
push hl ;save coordinates
srl h
srl h
srl h ;y=y div8
ld d,h ;save it in d
pop hl ;restore x,y
ld a,h ;a=y
and 7 ;a=y mod 8
ld e,a ;save it in e
xor a ;reset carry flag
ld a,l ;a=x
ld e,a
ld a,0
ld d,a  ;now de=offset
ld b,l  ;save x for later
ld hl,coltab   ;coltab=color table
call 4ah  ;get actual color
ld c,a ;save it for later
pop af ;restore color we set at the baginning
sla a
sla a
sla a
sla a ;shift color to high nibble
call 4dh  ;write back color
ld a,7
and b
ld b,a
xor a
inc b
ccf
Mlp:
rra
djnz mlp
ld hl,ptgtab  ;ptgtab= pattern table