Proper VDP Vblank interrupt handling when there are others source of interrupt active

Page 2/2
1 |

By gdx

Prophet (2701)

gdx's picture

12-06-2019, 12:59

If this bug exists, it should not happen with a little space between each reading.

By Grauw

Enlighted (8012)

Grauw's picture

12-06-2019, 14:26

PingPong wrote:

I wondering what happens if an int from another source of VDP VBLANK appears and while the bios int routine is running a VDP interrupts kick in. Sequence:
1) Device A request an int: H.KEYI execute but at this pojnt no VDP int is requested.
2) H.TIMI execute but in the exact time the BIOS check if int is coming by VDP by reading S#0 the VDP request an interrupt.
3) because reading S#0 reset the int bit this will be read as inactive so no further processing occours.

Am i wrong or In this way the VDP int is lost?

I think you’re right, but it’s still unlikely to miss an interrupt because the timing is so precise. It is easy to hit when polling, but in this situation the VDP status is sampled much less frequently. So it’s a matter of small chances.

Indeed seems best to first detect other interrupts and skip the VDP one if so, but that’s not how the BIOS works.

RetroTechie wrote:

"Citation needed". This would be a VDP hardware bug, and I'm unable to find any references in documentation or online. Just a single line from the Wiki on this site? Not enough imho. Therefore, it would be appreciated if someone has a better reference. Or better yet: example code to demonstrate this issue (if it exists at all).

It’s real, I’ve encountered it as well and it can be a pitfall for those who implement polling on an emulator (it isn’t emulated), only to discover that it doesn’t work on real hardware. There have been several forum posts about this in the past, you can search for them. It is easy to reproduce, e.g. di, poll for F, change the background colour to red for a few ms, repeat. You will notice that the background colour is not stable, but flickers.

RetroTechie wrote:

Only on TMS9918, or also applies to V9938 or V9958?

I ran into this polling for splits on V9938.

gdx wrote:

If this bug exists, it should not happen with a little space between each reading.

The problem is that the VDP does not know when exactly the CPU samples the bus. It clears F when /RD goes inactive, however the CPU samples the bus a little before that, so if the interrupt occurs between those moments then the CPU will not see the flag.

So a little space between each read won’t fix things.

By PingPong

Prophet (3278)

PingPong's picture

12-06-2019, 19:08

Bleah, would be a lot better a manual ack. They didn't miss any single chance to make things working in a wrong way :-(
I can imagine Karl Guttag: "Manual ack?, no oh my GOD! it require an extra port or register write, what a waste of transistors".
Bleah! ;-(
we in italy call this kind of people a "Rabbino"

By hit9918

Prophet (2853)

hit9918's picture

12-06-2019, 20:14

Grauw wrote:

I ran into this polling for splits on V9938

this means the bit of the line interrupt?

By PingPong

Prophet (3278)

PingPong's picture

12-06-2019, 20:52

Probably there is the same problem.
I'm wondering if there is a reliable way to detect interrupt of both vertical and horizontal retrace. maybe there is a similar problem, to discriminate between V.interrupt and H.interrupt without the risk of loosing interupts.

By Grauw

Enlighted (8012)

Grauw's picture

12-06-2019, 23:36

hit9918 wrote:

this means the bit of the line interrupt?

Yes.

PingPong wrote:

I'm wondering if there is a reliable way to detect interrupt of both vertical and horizontal retrace. maybe there is a similar problem, to discriminate between V.interrupt and H.interrupt without the risk of loosing interupts.

Well they are temporally related, the vertical interrupt would not occur exactly when your horizontal interrupt handler returns from the hook unless you use a line close to 212.

I never heard anyone complain about this so I don’t think it’s an issue in practice. I’ve only ever heard about this in the context of people polling the interrupt flags.

By NYYRIKKI

Enlighted (5268)

NYYRIKKI's picture

13-06-2019, 05:00

IIRC on V9958 I've seen this problem happening on Vblank interrupt, but not ever on line interrupt... Though when I poll line "interrupt" in reality I newer have those interrupts enabled from VDP. I don't know if that affects the issue... If it does then maybe disabling Vblank interrupt before polling could help as well(?)

By thegeps

Master (207)

thegeps's picture

13-06-2019, 10:06

LoL PingPomg, I'm italian too but in my zone we don't use "Rabbino"

By PingPong

Prophet (3278)

PingPong's picture

13-06-2019, 13:25

[OT] Rabbino means stingy. Normally it does refer to a people that try to keep its economical status without spending money.
When referred to the Project Engineer that designed the VDP it means : a person that does not want at all to use one transistor more than strictly necessary, even if the resulting design would result in a bad design without weighting the pro and cons.

For Karl Guttat there was only one objective: keep the transistor count to less possible, it does not matter if the resulting chip is so bad or limited that sacrifice usability or utility. the only thing that matters is to save transistors, no matter if the resulting chip is a crappy one.

TMS VDP is full of tricks and quirks that have the rationale in keep low the transistor count.

For example: if you try to set a value for a register, you suddently are modifying the low byte of VRAM PTR.
This is a crappy design. but doing things in the right way would have to create a temporary 8 bit latch so more transistors.

the same apply to 1 bit for all sprite size. the VDP already is able to zoom in X or Y sprites, a good enhancement would be to being able to specify zoom for each plane. but this require additional 32s bit of write only registers, or if you want to have independent X or Y zoom even 64 bits!

I think Karl preferred a suicide instead of adding 64 bits of storage.
;-)

By thegeps

Master (207)

thegeps's picture

13-06-2019, 13:36

LoL I was sure that was the meaning. We use 'ebreo" instead (it sounds a bit racist but it's a radicated commonplace)

Page 2/2
1 |