hey,

with the usual nestorBASIC i made a little something that dropped 50 little things. i used pset but it was awfully slow. i tried translating x,y to the vram adres and it goes 20 times faster! incredible!!!!

but when i use pset and vpoke for testing, i found out that in some occasions the byte has to be swapped. nibble 1 with nibble 2. when does it have to be changes? how do i change it?

***EDIT***
bah, i looked 100 times faster, but somehow openMSX went mad and turned up the speed itself (taking cpu% with him)

Well, if you know the analogy of MSX's VDP and how she builds her screen, you'd know why.

in screen5 for example one pixel is 4 bits long (the 4 bits correspond to the color nr. 0-15). Since 1 byte has 8 bits, it can therefor store 2x4bits=2 pixels (2 nibbles if you like)

the lower bits (LSB: 0-3, or low nibble) are the RIGHT pixel while the higher bits (MSB: 4-7, or high nibble) are for the LEFT pixel.

so poking (for example) 0xF0 in vram pos 0x0000 you get a WHITE pixel (let's assume color 15 is white in this case) on X=0,Y=0 (the left pixel) and a Black/Transparant on x=1, y=0 (the Right)...
poking 0x4F on 0x0001 will put a BLUE (if color 4=blue eh) on x=2, y=0 and a White one on x=3, y=0

Why this is faster? well the PSET has to READ the byte, calculate which nibble to use, save the other nibble and do some logical operations on it befor putting the byte back again.
Also to initialise the PSET command takes a load of time (setting up the 15 bytes VDP command table and execute it....)

how to calculate byte to x,y ? you figured it out didn't ya??

vram_adr EQU X_RES/TOTAL_PIXELS_PER_BYTE x YPOS + XPOS/TOTAL_PIXELS_PER_BYTE

for screen 6 total_pixexls_per_byte=4 (4 colors remember: 2 bits):
for screen 5 and 7: 2 pix per byte
for screen 8: 1 bix per byte (256 colors=8 bits)

good luck

Quote:

how to calculate byte to x,y ? you figured it out didn't ya?? vram_adr EQU X_RES/TOTAL_PIXELS_PER_BYTE x YPOS + XPOS/TOTAL_PIXELS_PER_BYTE for screen 6 total_pixexls_per_byte=4 (4 colors remember: 2 bits): for screen 5 and 7: 2 pix per byte for screen 8: 1 bix per byte (256 colors=8 bits)

hmm, my calc is the same.
but i still have the same problem.

i have:
vpoke yy*128+xx/2,&Hf0
but, when i do :
pset (xx+1,yy),13

i see that the purple dot is not always x+1 relative to the vpoke.
there are occasions where i need to use &h0f instead of &hf0.
that's the problem now.

Quote:

>> i have: vpoke yy*128+xx/2,&Hf0 but, when i do : pset (xx+1,yy),13 i see that the purple dot is not always x+1 relative to the vpoke. there are occasions where i need to use &h0f instead of &hf0. that's the problem now.

Seems like you know the answer!
It's the &HF0 and &H0F that make the difference..
&HF0 puts a pixel on offset+0
&H0F puts a pixel on offset+1

remember with vpoke you will address 2(!) positions at once
that's why you've gotta READ the original value first to keep save one of them
pixels. you need to check the X position for which nibble to use
(if X=even, vpoke &HF0 else if X=odd, vpoke &H0F)

example: to put a pixel on position (10,10) using the vpoke trick in pseudo code
<TABLE BORDER=0 ALIGN=CENTER WIDTH=85%><TR><TD><font class="mrc-small">Code:</font><HR></TD></TR><TR><TD><FONT class="mrc-small"><PRE>
x=10
y=10
adr = 128xY+ x/2
org = vpeek (adr) ; here you read the original value
if (X AND 1)=0 -> vpoke (adr), (org AND &H0F) OR &HF0 ; even
else
if (X AND 1)=1 -> vpoke (adr), (org AND &HF0) or &H0F ; odd
</PRE></FONT></TD></TR><TR><TD><HR></TD></TR></TABLE>

with the (X AND 1) you can check if it's even or odd (using bit 0 of the X pos)

hope you get it. good luck

great! thnx for the info. i already knew not to implement that before reading this post. since snow has the charateristic of falling weird anyway leaving it saves a few cycles too. by restoring the thing, i can simply
vpoke an entire byte over the old position, it does not matter in the end. for snow, that is!