include pokew and peekw in basic?

[funkheld]

Hi good afternoon.

can you developers please:
include pokew and peekw in basic?

If you always have to calculate it yourself, a lot of time is consumed.

Thanks

[ahenry3068]

Hi good afternoon.

can you developers please:
include pokew and peekw in basic?

If you always have to calculate it yourself, a lot of time is consumed.

Thanks

pokew is not so Bad. Here's a couple of functions to Use. They don't speed up the code per se. But they do Make your code cleaner.

REM MAKE THE WORD VALUE SIGNED.
DEF FN SW(W)=W + 65536 * (W > 32767)

DEF FN PEEKW(W) = PEEK(W) + (PEEK(W+1)*256)

REM POKES X (WHERE X <= 65535 AND X >= -32768 (Outside this range will give an ERROR)
REM POKES IT TO ADDRESS A

POKEW:
POKE A, FN SW(X) AND $00FF
POKE A+1, INT(X/256)
RETURN

[funkheld]

Thanks for the info.

That takes up too much time for me in basic.
If I had 300 pokew/peekw now, the program would be too slow.

in rom as asm it would be faster.

greeting

[ahenry3068]

This code is faster but it will only work properly with a BASIC Integer variable. It won't work with a Float.

GET A 16 BIT VALUE FROM ADDR
RETURNS IN W% THE VALUE RETURNED WILL BE SIGNED AND MAY BE NEGATIVE.
(Range -32768 - 32767)

BASIC INTEGERS ARE STORED Big Endian, Most significant byte first. I am swapping a Little Endian variable in Memory (which is what 6502 uses for addresses) to Big Endian in the BASIC variable here.

PEEKINT:
P=POINTER(W%)
POKE P+1, PEEK(ADDR)
POKE P, PEEK(ADDR+1)
RETURN

POKEINT:
P=POINTER(W%)
POKE ADDR, PEEK(P+1)
POKE ADDR+1, PEEK(P)
RETURN.

[JimmyDansbo]

can you developers please:
include pokew and peekw in basic?

If you really want those commands added to the ROM, I suggest opening an issue
https://github.com/X16Community/x16-rom/issues

In the meantime, one of the great things about the X16 is that it is limited and it forces you to think differently. I would suggest you try and work around your need for pokew and peekw ?
Take it as a challenge to improve your own coding skills

[Edmond D]

DEF FN PEEKW(W) = PEEK(W) + (PEEK(W+1)*256)

Be wary that this type of coding may be prone to inconsistent data issues. If the value of the word changes between the first Peek and the second one, you might get an incorrect value.

Imaging reading a counter that increments with every CPU cycle. If each Peek takes several CPU cycles to run, then there would be a difference between when you read the high byte and the low byte. This "lag" might not show as a problem.

However imaging reading the counter when the value is 255. if you read the low byte you get the correct value of 255 in the word. Then the code goes read the high byte of the word which was 0 when the read started, but has now been incremented by 1 since the low byte has rolled over. The read of the high byte gets 1 so the PeekW code calculates the value as 255+(1*256)= 511, but in fact the value of the free running counter is only 256.

This type of issue is important in real-time industrial control systems, on BASIC in an X16 I imaging it isn't such a big deal.

[TomXP411]

Again, there's a way to cheat. It's still slower than pokew/peekw, but you can use POINTER with an integer variable to read/write a 16-bit word, just like you can use POINTER to read/write a 5 byte float.

So you could do something like...

A%=1
AH=POINTER(A%)
AL=AH+1

Now, when you need to get two bytes from an int, you can:

A%=1234
PRINT PEEK(AH)
PRINT PEEK(AL)

So if you were poking values into the SYS register variables at $30C-$30E, you could:
POKE $30D,PEEK(AH)
POKE $30E,PEEK(AL)

[ahenry3068]

Again, there's a way to cheat. It's still slower than pokew/peekw, but you can use POINTER with an integer variable to read/write a 16-bit word, just like you can use POINTER to read/write a 5 byte float.

So you could do something like...

A%=1
AH=POINTER(A%)
AL=AH+1

Now, when you need to get two bytes from an int, you can:

A%=1234
PRINT PEEK(AH)
PRINT PEEK(AL)

So if you were poking values into the SYS register variables at $30C-$30E, you could:
POKE $30D,PEEK(AH)
POKE $30E,PEEK(AL)

What I said viewtopic.php?p=32938#p32938

AH & AL make me think of x86 assembler

[Edmond D]

AH & AL make me think of x86 assembler

Be gone heretic!!!

After 8 bits, computing just went all down hill!

Having written X86 assembly and getting back to the 6502 I feel much better now.

[ahenry3068]

AH & AL make me think of x86 assembler

Be gone heretic!!!

After 8 bits, computing just went all down hill!

Having written X86 assembly and getting back to the 6502 I feel much better now.

I heartily agree.......