Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
IM 2
#31
I think, the ROM0 was still paged in after you return to "normal" because of the incomplete value, and so it interfer with other routines of compiled program, not with PRINT. And if the interrupt points to ROM (Updating system variables, Timer, etc.) it will not work correctly.
I always use complete RAM+ROM bank decoding to avoid these problems.
------------------------------------------------------------
http://lcd-one.da.ru redirector is dead
Visit my http://members.inode.at/838331/index.html home page!
Reply
#32
@Boriel: Cool, I'll post it tomorrow (the apack.exe compressor is also needed, but all I can provide is a link).

@LCD: It has to do with what you mention, somehow. Anyways, my ISR doesn't even call the BASIC ISR (FRAMES is not updated at all, for example). That's something I need to change as I'll be using INKEY$ and I guess that uses LAST_K, unless I'm wrong (haven't tried). Anyways, complete bank decoding is good practice. Always.
Reply
#33
na_th_an Wrote:@Boriel: Cool, I'll post it tomorrow (the apack.exe compressor is also needed, but all I can provide is a link).

@LCD: It has to do with what you mention, somehow. Anyways, my ISR doesn't even call the BASIC ISR (FRAMES is not updated at all, for example). That's something I need to change as I'll be using INKEY$ and I guess that uses LAST_K, unless I'm wrong (haven't tried). Anyways, complete bank decoding is good practice. Always.

Hmmm. Check what @LCD says. Use:
Code:
Asm
DI
End Asm
At the beginning of your program (otherwise, I will check when I have time).
Maybe with DI (interruptions disabled) the ROM switching does not affect ZX BASIC??? (Just guessing)
Note: Inkeys$ use both the HEAP (String) and the ROM.
Also: *ANY* Floating point operation uses the ROM FP Calculator...
Reply
#34
I think we are mixing up things.

The main problem has been solved: several ZX Basic commands and functions need the original 48 BASIC ROM (the one with the BASIC interpreter, which is ROM1) and I wasn't paging it back after I did my paging chores. So when paging, doing whatever you need to do, just ensure that BIT 4 is set. That's all.

My concerns right now are if the BASIC ISR (rst 38) is NEEDED at all for some ZX Basic commands to work so, in case it is, just call rst 38 at the end of my ISR. It hasn't to do with paging at all. It's just that I have my own ISR and I don't know if functions such as INKEY$ need the BASIC ISR. So some testing is due...

And the results are positive. INKEY$ doesn't neeed the BASIC ISR. So, unless I need to use the FRAMES system variable, I can skip calling the BASIC ISR from my own ISR.

Code:
'' BASIC ISR TEST
'' Just to check if the BASIC ISR
'' is needed at all.

Asm
    Di
End Asm

'' Now the BASIC ISR is not running.
'' Does INKEY$ work?

While Inkey$ <> "q"
    If Inkey$ <> "" Then
        Print Code (Inkey$);" ";
    End If
Wend
Reply
#35
na_th_an Wrote:I think we are mixing up things.

The main problem has been solved: several ZX Basic commands and functions need the original 48 BASIC ROM (the one with the BASIC interpreter, which is ROM1) and I wasn't paging it back after I did my paging chores. So when paging, doing whatever you need to do, just ensure that BIT 4 is set. That's all.
Right. And I would like to track which ones (ej. Floating point operations do use ROM 0).

na_th_an Wrote:My concerns right now are if the BASIC ISR (rst 38) is NEEDED at all for some ZX Basic commands to work so, in case it is, just call rst 38 at the end of my ISR. It hasn't to do with paging at all. It's just that I have my own ISR and I don't know if functions such as INKEY$ need the BASIC ISR. So some testing is due...

And the results are positive. INKEY$ doesn't neeed the BASIC ISR. So, unless I need to use the FRAMES system variable, I can skip calling the BASIC ISR from my own ISR.
That's right.
You can use DI with ZX BASIC. It will go faster, but Frames won't work, and RANDOMIZE will always get the same value (from frames).
Reply
#36
na_th_an Wrote:And the results are positive. INKEY$ doesn't neeed the BASIC ISR. So, unless I need to use the FRAMES system variable, I can skip calling the BASIC ISR from my own ISR.

You could do it faster yourself. Berksman does this itself. When playing a sound, it goes to IM2, which updates FRAMES and nothing else, as quickly as I could This lets the clock stay in sync in the middle of a sound and doesn't affect the sound too badly. (I can barely hear it)..

Code:
isr:
asm
;This is the interrupt Service Routune
; First thing, save those registers.

PUSH AF
PUSH HL

;Kick the clock forward because we lost at least a frame.
LD HL,23672
INC (HL)
JR NZ, ISREnd
INC HL
INC (HL)
JR NZ, ISREnd
INC HL
INC (HL)

ISREnd:

POP HL
POP AF

reti
end asm
Reply
#37
Oh, nice snippet, I'll take it in acount :-)
Reply
#38
na_th_an Wrote:I do: the ISR saves all the register pairs. Check the code and see Wink

But that's not the problem. The problem occurs with bank switching. Just with bank switching, even if I don't enable my ISR or even don't enable IM2, any bank switching messes subsequent PRINT calls. Minimal case scenario:

Code:
' Test

Asm

    ; Permorm some dummy paging
    
    di
    ld  a, 5
    ld  bc, $7ffd
    out (c), a
    
    ; now RAM 5 is in.
    
    xor a
    ld  bc, $7ffd
    out (c), a  
    ld  ($5b5c), a
    ei
    
    ; back to normal
    
End Asm

Print "HOLA";
Compile and run this in either 128 BASIC or USR 0 mode. You won't see "HOLA" on screen, but a bunch of trash.
After thinking it twice I've just realized print uses ROM Font, as pointed in PEEK(Uinteger, 23606) + 256. This default value should be 15360 + 256, which is the default FONT Charset which lays in ROM. Put this font in another location and update this variable accordingly, and the print routine will work OK ;-)
Reply
#39
Lol - my face is funny now. It's some kind of "OF COURSE IT'S THAT", but I wouldn't have realized in a million of years :lol:

Thanks Big Grin Now I feel incredibly stupid.
Reply
#40
If it's any consolation, na_th_an, I saw Boriel's post, and thought "why did I NOT see that????"

It's not just you.

:-)
Reply
#41
:lol: :lol: Most of the time, the most obvious reason is the hardest to find. It looks that our minds are completely twisted Tongue
Reply


Forum Jump:


Users browsing this thread: 2 Guest(s)