Poking Values through an RSX to somewhere in Memory

[AMSDOS]

I was just thinking it would be quite useful if I could pass a bunch of values through an RSX so they could go somewhere in memory, a bunch of Ink Values for example. Obviously there's no point doing this in BASIC because there's DATA statements, Turbo Pascal has CONSTant Array's which is equivalent to DATA statements, in Hisoft Pascal you need to load that DATA in, which is fine for large chunks of DATA, though a bit fiddly if you're dealing with small amounts of data. I was wondering if something like that were possible and if someone has made something like that already?


I kind of picture the RSX looking like this:


|apoke,<val>,<val>,<val>,<val>,<val>,<start_addr>,<size>


<val> could be any value (0-255), though depending on the Size the number of <val> could change, for example if size were 2 then you may have 2 <val>, and I just thought that for the loop the IX register could increase on each pass and poke the value into the following Address.


Could that work?

[Grim]

The following program will define two RSXs:

• |poke.b,<address>,<value>[,<value>, ...]
• |poke.w,<address>,<value>[,<value>, ...]

As the names suggest (?), they will poke byte or word values at a given address.

The <size> argument was actually not needed because the Firmware already counts how many parameters are passed to a CALL or RSX command. Also, I defined that the <address> parameter should be first so that the two commands will be consistent with the original POKE command of the BASIC Locomotive.

Code Select Expand


org &4000

_KL_LOG_EXT equ &BCD1
 
; BC hold the RSX object pointer
; HL hold a 4 bytes buffer reserved to the firmware
ld bc,_poke_rsx_list
ld hl,_poke_rsx_kbuf
jp _KL_LOG_EXT

_poke_rsx_kbuf ds 4,0

; Address of the RSXs names table
_poke_rsx_list dw _poke_rsx_names
; RSX jumps table
jp _poke_byte
jp _poke_word

; RSX names table
_poke_rsx_names db "POKE.","B"+&80
db "POKE.","W"+&80
db 0

;; Poke byte values
;; Input:
;;   A contains the number of parameters.
;;  IX contains the address of the parameters.
_poke_byte:
; Exit if wrong number of arguments given
sub 2
ret c
inc a
; Init pointers
call _poke_getPointers
_poke_byte_loop ; Poke all remaining parameter values
dec ix
call _poke_copyByte
dec c
jr nz,_poke_byte_loop
ret

;; Poke word values
;; Input:
;;   A contains the number of parameters.
;;  IX contains the address of the parameters.
_poke_word:
; Exit if wrong number of arguments given
sub 2
ret c
inc a
; Init pointers
call _poke_getPointers
_poke_word_loop ; Poke all remaining parameter values
call _poke_copyByte
call _poke_copyByte
dec c
jr nz,_poke_word_loop
ret

_poke_getPointers:
; Get pointer to the first parameter
ld b,0
ld c,a
add ix,bc
add ix,bc
; Read poke address (first parameter)
ld h,(ix+1)
ld l,(ix+0)
ret
_poke_copyByte:
dec ix
ld a,(ix+0)
ld (hl),a
inc hl
ret


Usage from BASIC interpreter:

Code Select Expand


' Init POKE RSXs
call &4000

'Poke some bytes into VRAM
|poke.b,&c000,1,2,3,4,5,6,7,8,9

'Poke some words into VRAM
|poke.w,&C800,1000,2000,3000,4000,5000


Please, note that the poke.w command actually stores the words in big-endian. Changing it to the usual CPC little-endianness is left as an exercise to the reader :)

[AMSDOS]

Looks Great, thanks for that.


Wasn't quite sure how it would of worked having the address before all the bytes, though it looks like you've got it covered by working out all the bytes and obtaining the position of Address that way?

[Grim]

Yep, that's what the sub-routine _poke_getPointers does first, adjusting IX to point to the first argument so that we can process them more conveniently from first to last. (when calling an external command, CALL or RSX, the Firmware sets IX to point to the last argument and A holds the number of argument)