Is there a minimal XB assembly subroutine implementation out there somewhere which just implements string writes to VDP memory?

[apersson850]

We can give you a crash course in Swedish.

I was a co-editor of that newsletter at that time. You can find my section, the challenge (see, now you already know how to translate Utmaningen) on page 15.

[Fredrik Öhrström]

On 12/22/2020 at 7:49 PM, RXB said:

Some way to translate this?

The linked VDP routine is just a blwp into the ROM routines. The actual code is:

LI R0,xxxx

LI R1,yyyy

LI R2,zzzz

BLWP >wwww

B *R11

 

Then each subroutine, patches this code! ?

With particular values for x,y,z and w suitable

for VMBW,VMBR,PEEKV and POOKV.

 

Then there is simple test case:

Line 30: fill screen memory with a pattern.

Line 40: Use VMBR to copy 768 VDP bytes into console expansion memory at 9478.

Line 60: fill screen with a different pattern.

Line 70: Use VMBW to copy the screen into offset 10246.

Loop 80-90: Copy the two saved screens into the VDP memory using vmbw, flipping back and forth.

 

The flip is quick, since the ROM routine is pretty quick, at least in comparison to the

basic CALL VMBW, which is sloooow, and of course the LOADS to patch the code takes

time as well as the actual LINK call.

 

But I have forgotten why I do a CALL POKEV(-30971,0)

maybe I set some color?

 

 

 

 

 

[speccery]

That's pretty interesting @Fredrik Öhrström. I remember buying an issue of Nittinian when I was on a language course in Visby as a kid. So brings back some memories.

As I looked at the program listing, it is interesting that you're directly injecting the REF entry by pokeing it to memory. It also reminds me of a couple of things I still find to this day surprising about the old BASICs:

• Why didn't they have the equivalent of POKE (LOAD) and PEEK for 16-bit values? Among my small collection of retrocomputers I have two Oric Atmos computers, and they had DOKE and DEEK commands for 16-bit values.
• By the same token it would have been useful to have functions such as LOBYTE(x) and HIBYTE(x) to extract high and low bytes of 16-bit values.
• Also support for conversion to hexadecimal (and perhaps other radix values) would have been welcome.

I find it interesting that so many BASICs of the day suffered from these limitations, despite them being super simple operations compared to the other things they supported. Perhaps everybody was just cloning the minimum set of functionality, instead of thinking about machine code integration.