USR function (*solved*)

[britlion]

We seem to have a regression with the latest version:

print USR "A" falls over:

Traceback (most recent call last):
File "zxb.py", line 312, in <module>
File "zxb.py", line 246, in main
File "zxbtrad.pyc", line 316, in traverse
File "zxbtrad.pyc", line 1286, in traverse
File "zxbtrad.pyc", line 593, in traverse
UnboundLocalError: local variable 'suffix' referenced before assignment
Build Failed!

[boriel]

Yes, and strange :?:
It was just a typo (fixed).
Download the lastest version.

[britlion]

Testing the results of the USR function seems to come up with the right answers, but my "invert a graphic" sub seems to be breaking in strange ways.

Can't quite follow why:

Is it me doing something silly, or the compiler? It seems to miss a line off the top, and then write gibberish into the next one, before carrying on normally with the last six lines. Is it my emulator (spin)? or my program?

I just checked: Does the same thing in Spectaculator.
And "Print \b" seems to print a B missing the top before my sub even runs...

Code:

SUB fastcall hMirror (udg as uInteger)
ASM    
    
    ld b,8  
    hMirrorRotate:
      LD C,(HL)
      
      RR C
      RLA
      RR C
      RLA
      RR C
      RLA
      RR C
      RLA
      RR C
      RLA
      RR C
      RLA
      RR C
      RLA
      RR C
      RLA
    
      LD (HL),A
      
      INC HL
    DJNZ hMirrorRotate
      
END ASM
END SUB

CLS

PRINT "Address: ";USR "B"

PRINT "\b"
hMirror (USR"B")
PRINT "\b"

[boriel]

Probably because the default UDG address PEEK UINTEGER 23675) points to top of memory (ZX Default), which is now being used by the compiled code and the heap.

Try this at top of your code:

Code:

#include <alloc.bas>
POKE Uinteger 23675, allocate(20 * 8) ' 20 Chars * 8 bytes each

This points UDG Address to the a free reserved mem area, so It won't get corrupted.
Note: --spectrum parameter does this by default.

[britlion]

Hmm. If I believe that... Okay - what if I try

Code:

DIM UDG (7) => {%10000000,%01000000,%00100000,%00010000,%00001000,%00000100,%00000010,%00000001}
POKE UINTEGER 23675,@UDG

At the start of the code?
That should point it at a safe place, because it's variable space..

However, what it actually does is print a garbled UDG, followed by a mirror of it.

[britlion]

Note: --spectrum parameter does this by default.

--sinclair, you mean? Or are you adding in other machine specific options?

[boriel]

Note: --spectrum parameter does this by default.

--sinclair, you mean? Or are you adding in other machine specific options?

--sinclair, yes (sorry, I'm currently not at home).
Try your program with --sinclair. If it works, you can use either --sinclair or the above trick (remember --sinclair adds more compatibilty with Sinclair BASIC, but also more overhead).

[boriel]

Hmm. If I believe that... Okay - what if I try

Code:

DIM UDG (7) => {%10000000,%01000000,%00100000,%00010000,%00001000,%00000100,%00000010,%00000001}
POKE UINTEGER 23675,@UDG

At the start of the code?

Of course, this is preferred.
Well, using malloc, you can later free it and reuse it for other purposes.

However, what it actually does is print a garbled UDG, followed by a mirror of it.

Hmmm. :?: :?: :?:
Would need further investigation, I guess.