IM 2

[na_th_an]

Any special considerations to take in account? I set up my IM 2 ISR routine the same way I do from pure assembly and everything crashes beautifully :lol: (I know the code posted below will crash with hardware attached, this is just a quick test) (and no, no hardware is attached. The floating bus should read $ff).

Code:

Sub activateIsr ()
    Asm
        ld  hl, isr_code
        di
        ld  ($feff), hl
        ld  a, $fe
        ld  i, a
        im  2
        ei
    End Asm
End Sub

Sub allPurposeContainer
    Asm
        isr_code:
        push ix
        push hl
        push af
        ; random shyte
        ld a, r
        out (254), a
        ;
        pop af
        pop hl
        pop ix
        ei
        reti
    End Asm
End Sub

activateIsr ()

While (1): Wend

The "random shyte" section is in fact a bigger routine. Do I have to save all the registers or something like that?

[na_th_an]

Aw, the code posted above doesn't crash, so I must be doing something in the real code which is making somebody upset. I still can't show the real code - I want to have it 100% working before unleashing it.

Anyways, anything to take in account when doing IM 2 from ZX Basic? Has anybody done it before?

[na_th_an]

Forget everything I said. I was just being stupid.

But be prepared for a nice release

[slenkar]

i like nice releases

[na_th_an]

Yup but I'm having problems. For some reason text output gets messed up, like if the font was corrupted, after I run my code.

Is there any way to set up where the stack is located? Maybe, as I'm paging, I'm messing up stuff.

[na_th_an]

Well, I wanted to do a proper release when this was ready to go, but it seems I can't get this to work for some strange reason. Long story short, if you visit WOS you know what is this: a way to display full colour blocky graphics (4x4 pixel "blocks") using the dual display in 128K models. Complete with converter and stuff. Could be nice for text adventures and stuff.

The finished product will have a way to specify the height of the graphics windows and its vertical position. But right away I'm struggling with odd behaviour. Look at this picture:



The top 16 lines are multi-colour (8x4 attributes). This is done by interrrupts: there's an ISR which just switches the visible screen each 228x4 T-states, that is, 4 pixel lines on a 128. Of course this takes quite a lot of frame time.

The strange stuff in the bottom part is supposed to be a bouncing "O". This program usually works:

Code:

Dim x, y, cx, cy, mx, my as Byte

cx = 16: cy = 20: mx = -1: my = -1: x = 16: y = 20

While (1)
    x = x + mx : If x = 0 Or x = 31 Then mx = -mx: End If
    y = y + my : If y = 16 Or y = 23 Then my = -my: End If
    
    Print At y, x; "o"; At cy, cx; " ";
    cx = x: cy = y
Wend

But if I run it alongside my ISR, the odd pattern shown above is produced. The O is not an O, and the SPACE doesn't delete. It's like an OVER 1 with some strange symbols, so something is getting QUITE messed up. Maybe PRINT needs the BASIC ISR running to work properly?

Here is the test project -> <!-- m --><a class="postlink" href="http://www.mojontwins.com/warehouse/blocky-convert-v0.2.zip">http://www.mojontwins.com/warehouse/blo ... t-v0.2.zip</a><!-- m -->
Compile with zxb.exe -t -B -a test_fb.bas
Run in a 128K model.

[LCD]

Has anybody done it before?

Most of my games use externaly linked binary code for interrupts and soundtracker music. Still working on Binary Manager for BorIDE to make this job easier.
Stack location is always below CLEARed address. Or did you mean "Heap"?

[na_th_an]

In fact, both.

I don't know why, but something I do likes to mess up the PRINT routine. I think it's the aplib decompressor. In some game I was coding, text would become bold just because after decompressing a string.

This kind of issues are quite a bummer. I just don't know how to overcome them. I'm trying to write my own PRINTing rountines but I keep crashing the compiler and I don't know why (see my other thread)

[na_th_an]

Nope, it's not the aplib compressor, as the issue happens even if I don't call it. It has to be in my ISR. So, the question is, anything to take care of when ISR'ing with ZX Basic? What could be breaking the PRINT routine so bad?

[LCD]

How about trying one or two print routines from here?
<!-- m --><a class="postlink" href="http://www.worldofspectrum.org/forums/showthread.php?t=24618">http://www.worldofspectrum.org/forums/s ... hp?t=24618</a><!-- m -->
And about interrupts: I wish it would be so easy as:

Code:

SetInterrupt (@ProcName)

By the way: block graphics is fine, but how about allowing to use Hires graphics with 8x4 attribute resolution?

[na_th_an]

Well, right away the bitmap zone is full of 00001111 patterns, but nothing stops you from putting whatever you need :-) The routines just set two sets of ATTR files and then the ISR just pages the screens alternatively each 4 pixel lines :-) So... It's pretty straghtforward.

I'll try those print routines, but the main problem is still there. The amount of time I spend trying to overcome this kind of problems is a bit overwhelming. Anyways, I just wish all this hassle is worth something and it helps making the compiler better / better documented :-)

[na_th_an]

Ok, I'm testing some stuff and I've noticed that:

1.- Using the aplib depacker makes subsequent PRINTs to print the text BOLD. A simple Print Bold 0; At y, x; "o"; At cy, cx; " "; solves this issue.

2.- When I fiddle with paging (i.e. run this code)

Code:

Sub mt64x32ShowBuffers ()
    Asm
        di
        ld  a, 5
        ld  bc, $7ffd
        out (c), a
        ld  hl, mt64x32_buffer
        ld  de, $d800
        ld  bc, 512
        ldir
        ld  a, 7
        ld  bc, $7ffd
        out (c), a
        ld  hl, mt64x32_buffer + 512
        ld  de, $d800
        ld  bc, 512
        ldir
        xor a
        ld  bc, $7ffd
        out (c), a  
        ld  ($5b5c), a
        ei
    End Asm
End Sub

The PRINT output gets completely corrupted, as shown in the previous screenshot. So it's not the IM2 code, it's a joint effort between aplib and paging stuff :lol:

The SUB above just pages in RAM 5 to write to screen 0, then pages in RAM 7 to write to screen 1, then pages in RAM 0 so everything is back to normal. How could that mess the PRINT routine so badly?

EDIT: Not just paging, but writing any value to port $7ffd messes up everything (for example, showing screen 1 writing a 1 to bit 3 also messes up things).

[LCD]

Do you use the 128K BASIC mode or USR 0 mode?
As for 128K BASIC mode, you must also POKE 23388 the same value as sent to Port 32765, or the interrupts mode 1 used in 128K BASIC will mess anything up if you re-enable interrupts with a value in 23388 that do not match the currently active page.

Off Topic: Do you have a version of "Nanako in classic japanese monster castle" without custom loader? The custom loader does not work in ZX Spin emulator if flashload is enabled. I noticed that no source was released...

[na_th_an]

The POKE you mention is the "ld ($5b5c), a" at the end of the code :-) Just before reenabling interrupts, page 0 is paged back in and a 0 is written to $5b5c (23388).

The behaviour is exactly the same in 128 BASIC and USR 0 mode.

About Nanako - yup, that's a pitty, the guys at CEZGS favoured fancy loades which didn't work in some emulators :-P As for the source code, sadly I lost it completely when the pendrive I used to store my speccy stuff stopped working completely. All I keep is the latest version I posted in the dev forums at CEZGS (in compiled form), before the loader was added.

I've uploaded such version here: <!-- m --><a class="postlink" href="http://www.mojontwins.com/warehouse/20061213a--classic-japanese-monster-castle.tzx">http://www.mojontwins.com/warehouse/200 ... castle.tzx</a><!-- m -->

Maybe it's time to update our website with that version which actually works everywhere.

This game was created in Sinclair BASIC then compiled with Hisoft BASIC :-)

[LCD]

I did some experiments with bank switching, and it was working here, but I used OUT and POKE from ZX BASIC, not in Assembler yet.
As for Interrupts, I usualy preserve all registers that are used by my interrupt called routine. Switching bank at least destroys the BC register pair, and I'm sure DE is used too somewhere.

Thank you very much for the Nanako version.
I wonder why CEGZ favorited these custom loaders, as they are not suitable for DivIDE or Discs. Baron Ashler even used Alcatraz protection system. My opinion is: if there is a custom loader, then a standard loader must be provided too.
Hey, you used HiSoft Basic? I used it too for all my pre-2008 games until I moved to ZXBC. Excellent work!