News:

Printed Amstrad Addict magazine announced, check it out here!

Main Menu

BIOS call SCR_SET_INK and interrupts

Started by santi.ontanon, 18:31, 25 February 18

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

santi.ontanon

Hi! first of all, sorry if this is an obvious question, since I've just started coding in CPC a few days ago (I come from an MSX background).


I was doing some tests, and noticed that the default interrupt of the CPC was messing with my program, so I deactivated it (by just setting "ei, ret" in #0038). But I have some questions:
1) Where can I find information about what the default interrupt in the CPC does? (I googled around, but could not find the answer). I just want to know why would that interrupt mess with my code.
2) After deactivating the interrupt, I noticed that calling the BIOS function "SCR_SET_INK" had no effect. After testing a few things blindly, I noticed that if after calling SCR_SET_INK, then I call SCR_MODE_CLEAR, then the changes done by SCR_SET_INK actually took effect. So, is this the right procedure? call SCR_SET_INK and then SCR_MODE_CLEAR to make the changes happen? or is there a better way?


Sorry if these are stupid questions, but I'm just getting started, and the differences between the BIOS and interrupts from MSX to the CPC are confusing me quite a lot :)


Thanks a lot for any pointers I can get!!

Gryzor

Hello and welcome! Not many users from the US here (in fact I was about to delete your account because they're 99% scammer accounts from US IPs, but I googled your name and found your github contribs)


Rule #1: there are NO stupid questions; fire away :) You'll find we're a friendly bunch :)


Can you tell us more about what you're coding?

Urusergi

#2
Hi!

SCR_SET_INK needs the interrupts to be on cause the intermittency mechanism of 2 inks but, apparently, also when there is no intermittency  ::)

Perhaps applying the color codes directly in the firmware reserved memory? i don't know  :-[

EDIT:
By the way, it's possible that your code uses the alternative registers? In this case you must save BC' in the stack and disable interrupts before modifying them, to later recover BC' before reactivating the interruptions

andycadley


The interrupt in the CPC basically runs the Sound Queues, Frame Flyback Event queue and "Tickers", a series of programmable events that fire off at periodic points to carry out background tasks. The firmware itself sets up a bunch of these events, such as the one which flashes the inks periodically (which is why calling SCR_SET_INK appears to have no effect once you disable interrupts, the system normally manages the changes as part of a ticker block because it needs to know when to flash colours). You can add your own events either in BASIC with the AFTER/EVERY commands or in M/Code with KL_NEW_FRAME_FLY (for an event that fires on frame flyback), KL_NEW_FAST_TICKER (every 300th second) or KL_ADD_TICKER (every 50th second). I'm not sure if there is actual documentation on the events that get set up by default.


Normally I wouldn't expect the firmware interrupts to interfere with a program unless it's trying to directly manipulate the hardware, because the system may well reset something you weren't expecting. Another likely cause is that the system reserves all of the alternate register set for it's own purpose, so doing an EX AF,AF' or EXX will cause you all sorts of issues unless you don't use the firmware at all.

Urusergi

@andycadley Very well expressed. I feel so bad with my english  :'(

santi.ontanon

@Gryzor: Thanks!  I live in the US, but I am actually from Spain, so that explains it  :)  it's very hard to find any Amstrad/MSX/Spectrum users here. It was all dominated by consoles and the Commodore 64...


I am planning on doing a simple platformer game. And for now I was just doing a very simple program that just did this:
1) set screen mode 0
2) change the color palette
3) decompress an image (which I previously compressed using the Pletter compressor, so that it uses less space in the tape/disk)
4) draw the image to video memory


The pletter decompressor indeed uses the alternate registers, so, that could be it! I'll play around and see if that's the problem! And I see, so maybe ink is only changed by the blinking feature of the interrupt! Ok, in that case I'll follow your pointers to see how to change the INK without relying on the interrupt!!

Thanks a lot! :)

Urusergi

Hola!
Quote from: santi.ontanon on 20:08, 25 February 18The pletter decompressor indeed uses the alternate registers, so, that could be it! I'll play around and see if that's the problem! And I see, so maybe ink is only changed by the blinking feature of the interrupt! Ok, in that case I'll follow your pointers to see how to change the INK without relying on the interrupt!!

Thanks a lot! :)

Entonces seguro que es eso  ;D

DI
EXX
PUSH BC
EXX
...
YOUR CODE HERE
...
EXX
POP BC
EXX
EI

andycadley

Yes, if you're writing a game it's often better to just shove the system out of the way and do everything by accessing the hardware directly. It's generally faster and avoids limitations on things like the alternate registers which can give you a lot more flexibility in your code.

santi.ontanon

ok, so, it's indeed what you guys said, by wrapping my call to the decompresor like this, I don't need to disable interrupts:



    di
    exx
    push bc
    exx


    call pletter_unpack


    exx
    pop bc
    exx
    ei


But I see that it's going to be better to remove the firmware the interrupt altogether, so I don't need to worry about not using the ghost registers (which are very handy to save memory accesses in inner loops). So, is there a standard way to change the color palette that does not rely on the blinking feature of the interrupt?

andycadley


santi.ontanon


santi.ontanon

Just to conclude the thread, indeed the gate array was the way to go! I can now change screen mode, border color and pen colors without requiring any BIOS calls! Thanks a lot for your help guys!!

Powered by SMFPacks Menu Editor Mod