MSX bios interrupthandler

Pagina 1/6
| 2 | 3 | 4 | 5 | 6

Door Daemos

Paragon (1964)

afbeelding van Daemos

11-03-2014, 12:11

No big plans with it but rather a deep curiosity: Does anyone know what the interrupthandler of the MSX bios does.

Does it just acknowledge Vblank or does it do more things? Does it write values to system ram etc.

Aangemeld of registreer om reacties te plaatsen

Van anonymous

incognito ergo sum (116)

afbeelding van anonymous

11-03-2014, 12:20

lol dude... one word: #msxdev

Van Daemos

Paragon (1964)

afbeelding van Daemos

11-03-2014, 12:23

Smile Smile omg. good one. Ok you got me guyver. I will check MSXdev when I find a good free spot in the weekend.

Van Grauw

Ascended (10582)

afbeelding van Grauw

11-03-2014, 12:35

You can look for yourself at the disassembled BIOS here. Look for KEYINT, then J0C3C in base200/bios.mac (that’s for MSX2). It’s not too much, pretty easy to understand. Cross-reference with the MSX2 technical handbook if you need information on what the memory addresses are for.

For me in Synthesix, I am not using the BIOS to read key input and found I could reduce the time spent in the BIOS interrupt handler fairly significantly by setting SCNCNT to 255 every interrupt.


Enlighted (6845)

afbeelding van ARTRAG

11-03-2014, 18:25

On a barebone msx it calls the hooks 0xFD9A and 0xFD9F, reads the vdp status register and updates the keyboard tables by reading the PPI. It also executes the "play" queues updating the psg in case of need.

Form the msx red book:

    Address ... 0C3CH (from 0038H)
    Name ...... KEYINT (Keyboard Interruption handler)
    Input ..... None
    Exit ...... None
    Modifies .. EI
    Standard routine to process Z80 interrupts, these are generated by the VDP once every 1/60 s (20 ms on a UK machine). The VDP Status Register is first read and bit 7 checked to ensure that this is a frame rate interrupt, if not the routine terminates with no action. The contents of the Status Register are saved in STATFL and bit 5 checked for sprite coincidence. If the Coincidence Flag is active then the relevant entry in TRPTBL is updated (0EF1H).

    INTCNT, the "INTERVAL" counter, is then decremented. If this has reached zero the relevant entry in TRPTBL is updated (0EF1H) and the counter reset with the contents of INTVAL.

    JIFFY, the "TIME" counter, is then incremented. This counter just wraps around to zero when it overflows.

    MUSICF is examined to determine whether any of the three music queues generated by the "PLAY" statement are active. For each active queue the dequeueing routine (113BH) is called to fetch the next music packet and write it to the PSG.

    SCNCNT is then decremented to determine if a joystick and keyboard scan is required, if not the interrupt handler terminates with no further action. This counter is used to increase throughput and to minimize keybounce problems by ensuring that a scan is only carried out every three interrupts. Assuming a scan is required joystick connector 1 is selected and the two Trigger bits read (120CH), followed by the two Trigger bits from joystick connector 2 (120CH) and the SPACE key from row 8 of the keyboard (1226H). These five inputs, which are all related to the "STRIG" statement, are combined into a single byte where 0=Pressed, 1=Not pressed:

       7     6     5     4     3     2     1     0
    |Joy 2|Joy 2|Joy 1|Joy 1|  0  |  0  |  0  |Space|
    |Trg.B|Trg.A|Trg.B|Trg.A|     |     |     |     |
Figure 35: "STRIG" Inputs.

    This reading is compared with the previous one, held in TRGFLG, to produce an active transition byte and TRGFLG is updated with the new reading. The active transition byte is normally zero but contains a 1 in each position where a transition from unpressed to pressed has occurred. This active transition byte is shifted out bit by bit and the relevant entry in TRPTBL updated (0EF1H) for each active device.

    A complete scan of the keyboard matrix is then performed to identify new key depressions, any found are translated into key codes and placed in KEYBUF (0D12H). If KEYBUF is found to be empty at the end of this process REPCNT is decremented to see whether the auto-repeat delay has expired, if not the routine terminates. If the delay period has expired REPCNT is reset with the fast repeat value (60 ms), the OLDKEY keyboard map is reinitialized and the keyboard scanned again (0D4EH). Any keys which are continuously pressed will show up as new transitions during this scan. Note that keys will only auto-repeat while an application program keeps KEYBUF empty by reading characters. The interrupt handler then terminates.

here more details, look for KEYINT

Van hit9918

Prophet (2923)

afbeelding van hit9918

11-03-2014, 19:57

a problem is that bios enables interrupts early.
I get problems when my code takes longer than a frame. maybe stack overrun.

I always wondered whether there is a way to have a modded bios interrupt.
only thing I cant do myself is keyboard translation. any official call for that?

"c3c" is not official address, is it.

Van hit9918

Prophet (2923)

afbeelding van hit9918

11-03-2014, 20:00

@grauw, I noticed bios takes much less once one pressed a key into keyboard buffer.
is that related to your poke, is value 255 maybe a different kind of empty keyboard buffer.

Van Daemos

Paragon (1964)

afbeelding van Daemos

11-03-2014, 20:11


I always wondered whether there is a way to have a modded bios interrupt.

yes there is. Copy the content of the BIOS somewhere in ram. Change whatever you like to change. Get rid of the BIOS on page0 and use the new data you have from the ram

Van hit9918

Prophet (2923)

afbeelding van hit9918

11-03-2014, 20:14

Well to do that I would have to know addresses and codes precisely.
And be sure no bios version changes that part.
Maybe those with modded keyboards start bitching "it no more works".

Van hit9918

Prophet (2923)

afbeelding van hit9918

11-03-2014, 20:19

and another hack would be to remove the H.TIMI where floppy takes lots time just to turn motor off, but remove that before anyone else hooks in there.

Van PingPong

Prophet (3889)

afbeelding van PingPong

11-03-2014, 20:30

A thing that always bugged me is: how much fast is the ROM code?
expecially the BIOS, and the MSX-BASIC interpreter.

calling the BIOS to perform some tasks like interacting with VDP or PSG how much impact in performances?

Anyone have tryed to write a BIOS replacement with speed in mind?

Pagina 1/6
| 2 | 3 | 4 | 5 | 6