IM2 on a 128k Spectrum

edited August 5 in Development
Hello:

I have found another article on IM2 found in Personal Computer News, Issue 90. In the article "Face up to the Time", I typed up the code (which works great on a 48k).

I then did some adjustments to run on a 128k machine for adjust the range to fall from #bd4c to #bec1.

The code and compiling files can be found at
https://1drv.ms/u/s!Atc34t6eCvqj1wpuZoLBWPSNyM1D?e=GnwR5h

Here's the issue. When I run it in 48 mode, all is well. When I run it in 128k mode, even with an endless loop, I get odd results. On a Sinclair 128k/+2 and Pentagon, I see text mixed with some garbled data that flickers. On a +2a/+3, I see some of the same, but still a flickering mess.

As far as I can tell, I am below the paging system by staying below #C000, but I don't understand why I am seeing the flicker or garbled text.

I am just using this to learn about IM2 on the 128k.

If y'all need me to post the code directly, I can do that as well.

Thanks
Andy

Post edited by andydansby on

Comments

  • edited August 5
    Just had a quick scan, but my guess is that you are missing the 257 byte interrupt table.

    EDIT: But it's also possible that you're interrupting while ROM1 is in place, and there's no font stored in ROM0. (another guess)

    EDIT2: I've just paused the emulator when the corruption takes place, and I found ROM0 in there instead. :D

    EDIT3: I mean ROM0 instead of ROM1.
    Post edited by Timmy on
  • Is this an inherent problem using IM2 and 128k machines with BASIC? I already lose ramtop because I lower it to $B000 so that it doesn’t page out, so losing out on RAM.

    I intend on using it with compiled C eventually, any other pitfalls I should be aware of?

    I’m sure after studying it a little longer it will click and I’ll get that aha moment. Right now I’m having to deal with a lot of real life problems to deal with to let thing click.
  • edited August 6
    andydansby wrote: »
    Is this an inherent problem using IM2 and 128k machines with BASIC? I already lose ramtop because I lower it to $B000 so that it doesn’t page out, so losing out on RAM.

    Since it's 2AM over here, I'll post the link to some other* site instead going to cut and paste sections of it: https://worldofspectrum.org/faq/reference/128kreference.htm

    In short, you need to keep the page number somewhere. And you cannot expect any memory is where it should be on a +3.
    I intend on using it with compiled C eventually, any other pitfalls I should be aware of?

    Nothing special, other than you will have to ask the people of that specific C compiler how you should write an IM2 for the Spectrum. Ask them for step-by-step instructions. In other words, the theory is the same, everything else is different.
    I’m sure after studying it a little longer it will click and I’ll get that aha moment. Right now I’m having to deal with a lot of real life problems to deal with to let thing click.

    Don't worry, I have even more real life problems to deal with, it's almost 3AM over here.

    The most important thing to remember about IM2 is that it can happen any time. That means it can happen just after memory banks have been switched, during a screen update, halfway while a note is being played, or basically anywhere. Unless interrupt is being disabled, of course.

    Good luck.

    *) Well, maybe not 'other' site.
    Post edited by Timmy on
  • edited August 6
    If you check Bordertron or rotatrix you will find some nice asm
    My own attempt is www.cborn.nl/zxfiles/sflp0115e.zip
    It still needs a lot off fine-tuning. another raft-project
    Post edited by Crisis on
    my old website http://home.hccnet.nl/c.born/ has changed to http://www.cborn.nl/zxfiles/ so just click it and select a file
  • edited August 6
    There’s nothing inherently different with IM2 interrupts on a 128K machine. The addresses that contain your 257 byte vector table and the address the table points to must always be paged in at the time the interrupt occurs.

    This isn’t a problem with regular VBI interrupts (one per video frame, right near the start), as you’re in complete control of the program you’re writing. You control what’s paged in at a given moment, and you control whether interrupts are enabled.

    External hardware (addons plugged into the expansion bus) can theoretically also generate maskable interrupts, and you’re not in control of those the same way. But in practice that tends not to happen much on Spectrums. The AMX mouse does it, I think.
    Post edited by colonel32 on
    Robin Verhagen-Guest
    SevenFFF / Threetwosevensixseven / colonel32
    NXtel NXTP ESP Update ESP Reset CSpect Plugins
  • edited August 6
    There are some model-Specific hardware quirks though. 48K/toastrack/+2 grey Spectrums show screen 'snow' if you put the interrupt vector in contended memory ($4000..7FFF or banks 1/3/5/7). It's usually called snow for 48K and rain for the 128K machines.

    It can be fixed on all of them (adding two AND gates on 48K, replacement unrainer GAL for 128Ks), but the safest thing to do is assume it hasn't been fixed and never write code which puts the interrupt vector there. Contended banks are different on +2A/+3 machines (4/5/6/7), but those models don't have rain or snow so you don't need to care.
    Post edited by colonel32 on
    Robin Verhagen-Guest
    SevenFFF / Threetwosevensixseven / colonel32
    NXtel NXTP ESP Update ESP Reset CSpect Plugins
Sign In or Register to comment.