The not so famous /YS signal

Jorge Nuno · Post by **Jorge Nuno** » Tue Jun 19, 2007 1:49 pm

Since I got the megadrive schematics this always bothered me... a wire that just connects the VDP to the cartridge port...

So I took my Supa Megadrive with S&K to college to plug YS to a osciloscope and got this:

http://img393.imageshack.us/my.php?image=parte1gg1.png

http://img361.imageshack.us/my.php?image=parte2oe5.png

#1 -> /YS
#2 -> composite video at the DIN jack
#3 -> /CSYNC

the signals are triggered at the negative edge of VSYNC

what could be the use of this YS? is it conected in VirtuaRacing? or 32X?

also I checked the EDclock (tough no picture)... ughhh what a crap... its a 13MHz triangle wave floating around... no wonder it locks my CPU when i used to clock it with that, but then I connected to the cpu trough a NOT@74LS04 and it runs perfectly with sound and the sonic2 SS runs at insane speeds!!!

Mask of Destiny · Post by **Mask of Destiny** » Tue Jun 19, 2007 6:47 pm

I might be misremembering, but doesn't /YS have something to do with the priority flag? Basically, if the current pixel is a high priority pixel it's high, and if it's a low priority pixel it's low (or vice versa).

I believe the 32X uses this to properly overlay it's video with the output of the Genesis.

Jorge Nuno · Post by **Jorge Nuno** » Tue Jun 19, 2007 11:42 pm

Well I do't think so because the MD RGB always comes to the 32X and there it is decided based on a priority bit if the output is from MD or from 32X and YS was present on the cartridge port problably before 32X existed ever in paper, so how could they knew?

And since I was running sonic&knukcles in that moment why isn't the signal always low or always high?

It certainly has something to do with composite sync...

Fonzie · Post by **Fonzie** » Wed Jun 20, 2007 12:13 am

Devster said (ond day ^^):

YS is a wierd one. When I was experimenting with the 32x, I disconnected this line, and the vdp on the 32x couldn't render its graphics. I guess this indicated when the backdrop color is being drawn. The hacker's doc says its a video signal, but its not, its some kind of control signal.

The backdrop color!
Like MOD, I think the 32x VDP may use it to know if the current MD VDP pixel is empty (background color) or not...
So it can still decide to display a low priority 32x pixel if the hi priority MD pixel is transparent.

Some signals are also wired to the EXT port of the megadrive, maybe a YS signal and I wouln't be surprised if a "Composite IN" is also available ^^ If its the case, too bad sega never put "Composite IN" on the cartridge port too, would have saved us some wires ;P

evildragon · Post by **evildragon** » Wed Jun 20, 2007 12:22 am

Ahh, so THATS how the MASKING works! I was trying to document the masking feature on the 32X, but couldn't figure out how it read the priority bit from an RGB signal...

evildragon · Post by **evildragon** » Wed Jun 20, 2007 12:24 am

Fonzie wrote:Devster said (ond day ^^):
YS is a wierd one. When I was experimenting with the 32x, I disconnected this line, and the vdp on the 32x couldn't render its graphics. I guess this indicated when the backdrop color is being drawn. The hacker's doc says its a video signal, but its not, its some kind of control signal.
The backdrop color!
Like MOD, I think the 32x VDP may use it to know if the current MD VDP pixel is empty (background color) or not...
So it can still decide to display a low priority 32x pixel if the hi priority MD pixel is transparent.

Some signals are also wired to the EXT port of the megadrive, maybe a YS signal and I wouln't be surprised if a "Composite IN" is also available ^^ If its the case, too bad sega never put "Composite IN" on the cartridge port too, would have saved us some wires ;P

Composite In would damage the RGB market.

Are you talking about EXT as in the DB-9 connector on the back? I thought that was essentially a 3rd joystick port. The Expansion port for the Sega CD only has Audio In (and Audio Out on Model 2 Genny)..

YS isn't on the expansion port, but cool enough, 5v IN is

The Sega CD in theory could power the Genesis.. sadly this was never used (and would have saved us electrical wires, LOL)

Jorge Nuno · Post by **Jorge Nuno** » Wed Jun 20, 2007 12:38 am

Yup YS gets out the VDP directly to the cartridge slot and yes I see it now it is the backround, thanks Fonzie it fits perfectly with the pictures i posted: the VDP draws the Background color when YS is low

look at the 1st picture: it draws background right before and after HSYNC pulses and fills the display during vertical sync

to confirm this I only need to see YS in Sonic2 competition mode where YS should go low at the middle of the screen (lasting 5 lines aprox.)

TmEE co.(TM) · Post by **TmEE co.(TM)** » Wed Jun 20, 2007 10:48 am

And the mistery of !YS is solved, I was wondering what is it for quite some time.

Jorge Nuno · Post by **Jorge Nuno** » Mon Feb 25, 2008 8:49 pm

Jorge Nuno wrote: Bla Bla Bla...
...to confirm this I only need to see YS in Sonic2 competition mode where YS should go low at the middle of the screen (lasting 5 lines aprox.)

The lines in the middle are drawn in BG color, because Sonic2 in VS mode disables the display to to DMA freely to update the player 2 field, which means YS should go low (active).

And there you have it:

/YS level clear! (LOL

)

Eke · Post by **Eke** » Tue Feb 26, 2008 10:16 am

hey, since you got some materials, could I ask you to test something I always was wondering about:

- run a test program that do nothing else than setting 68000 SR to 27xx (all interrupts disabled) and write $64 into VDP register #1 (to enable VINT)
- trace IPL1/IPL2 pins activity from the VDP side

This would test how much time VINT remains pending when not acknowledged

Nemesis · Post by **Nemesis** » Mon Mar 03, 2008 6:21 am

I'm pretty sure the M68000 acknowledges all interrupts immediately. If the interrupt is masked, it's simply discarded, but the interrupt is acknowledged by the M68000 after the current bus cycle completes, whether the interrupt is taken or not.

Eke · Post by **Eke** » Mon Mar 03, 2008 10:10 am

I am not so sure about that: the 68000 manual explicitely say that if the priority of the pending interrupt is lower than the current processor priority (masked interrupt), the interrupt processing is postponed until it becomes greater. And the acknowledge cycle is described as one of the first steps of this interrupt processing.

You can also read in Addendum 3 from Sega Tech Bulletins that:

1/HINT remain pending as long it has not been acknowledged.
2/VINT is missed if HINT is programmed and accepted on line 224, which was the point of my question: how long does VINT remain pending ?

here are the tech bulletins:

Nemesis · Post by **Nemesis** » Mon Mar 03, 2008 10:50 pm

I am not so sure about that: the 68000 manual explicitely say that if the priority of the pending interrupt is lower than the current processor priority (masked interrupt), the interrupt processing is postponed until it becomes greater. And the acknowledge cycle is described as one of the first steps of this interrupt processing.

Well that's one bug to fix in my M68000 core then.

I've found the section you're talking about in the users manual under section 6.3.2. It states:

"If the priority of the pending interrupt is lower than or equal to the current processor priority, execution continues with the next instruction, and the interrupt exception processing is postponed until the priority of the pending interrupt becomes greater than the current processor priority."

My personal reading on that at face value is the processor still acknowledges the interrupt ASAP, and reads the vector number or autovectors, but that it stores this information internally, and checks the interrupt mask before each instruction to determine whether it should start processing the exception. I'd be surprised if the M68000 left the external chipset hanging until it got around to actually executing the interrupt, but it could be done this way. I can't find anything in the docs which convinces me one way or the other.

I've got an Oscilloscope at home, so I can take those measurements for you. It'll help me to solve my query as well. I'll do some tests this evening. Still, I'm going to need to study those tech notes and the users manual more carefully, because something funny is clearly going on for a level 4 interrupt to cause a level 6 interrupt to be discarded.

Eke · Post by **Eke** » Tue Mar 04, 2008 8:57 am

My personal reading on that at face value is the processor still acknowledges the interrupt ASAP, and reads the vector number or autovectors, but that it stores this information internally, and checks the interrupt mask before each instruction to determine whether it should start processing the exception. I'd be surprised if the M68000 left the external chipset hanging until it got around to actually executing the interrupt, but it could be done this way. I can't find anything in the docs which convinces me one way or the other.

If you read further:

if the priority of the pending interrupt is greater than the current processor priority, the exception processing sequence is started: A copy of the status register is saved; the privilege mode is set to supervisor mode; tracing is suppressed; and the processor priority level is set to the level of interrupt being acknowledged. The processor fetches the vector number from the interrupting device by executing an interrupt acknowledge cycle which displays the level number of the interrupt being acknowledged on the address bus. If external logic requests an automatic vector, the processor internally generates a vector number corresponding to the interrupt level number...

It is clearly stated that acknowledge cycle only occur when the interrupt is not masked, and this seems logical to me, it is how most processors are working...

The 68000 simply checks IPL1-IPL2 lines (IPL0 is not connected in the genesis) after each completed instruction and if the level is !=0 and greater than his interrupt mask level, it processes the interrupt.

VDP requests automatic vectoring, that means that the VDP set /VPA and wait for acknowledge trough /VMA from the 68000. Depending on the type of interrupt (HINT or VINT), the VDP seems to act differently. What is sure is that HINT (Level 4) remains pending as long as it is not acknowledged and enabled through VDP register, some games (Lemmings, and maybe Wiz 'n Liz for example) won't work properly without this being emulated...

I've got an Oscilloscope at home, so I can take those measurements for you. It'll help me to solve my query as well. I'll do some tests this evening. Still, I'm going to need to study those tech notes and the users manual more carefully, because something funny is clearly going on for a level 4 interrupt to cause a level 6 interrupt to be discarded.

thank you

Well, my initial idea was that interrupt processing takes some time. So, if the VINT occurence period is limited in time, it can be missed.
Another thing is described in the 2nd picture I linked above: as you can see, if the VINT occurs at the same time than the cpu starts previous HINT processing, the acknowledge generated by 68000 for HINT will be mistaken by the VDP as VINT acknowledge. Logically, the VDP reset the interrupt level on IPL1-IPL2 (those lines seem to be inverted in the docs) and INT6 will never be detected by the cpu, which will even process HINT a second time (because INT4 was still pending)

Nemesis · Post by **Nemesis** » Tue Mar 04, 2008 10:09 am

Ok, I've run a series of tests on the system. From what I can tell, I was correct in that the interrupt is acknowledged immediately after it is raised, even when it is masked.

I started by measuring the IPL lines when interrupts were masked by the M68000, and found that the IPL lines were only asserted for on average around 7 microseconds. They certainly weren't being held for an extended period of time. I then tested when interrupts were being taken, and found the timing was unchanged.

When monitoring INTAK between the VDP and the Bus Arbiter, and VPA between the arbiter and the M68000, I verified they are both being triggered at VINT on every frame. This happened regardless of whether the interrupt was being masked or not. So it seems, all interrupts are in fact acknowledged ASAP by the M68000 after they are raised.

Regarding the line 224 HINT causing the VINT to be missed, from what I can tell from the documentation, the problem is a quirk with how the VDP is communicating the interrupts to the M68000. When a HINT is triggered on line 224, the VDP asserts IPL1, and waits for the acknowledgement from the M68000 that the interrupt has been taken. Due to the extremely short period of time however between a HINT triggered near the end of line 224, and the VINT triggered at the beginning of the next line, the VDP may be ready to trigger a VINT before the M68000 has finished processing the line 224 HINT. What should happen in this situation for things to operate correctly, is that the VDP should wait for the line 224 HINT to be acknowledged before signalling the VINT. What it does instead however is immediately elevate the currently signalled interrupt from level 4 to level 6 by asserting IPL2 once the VINT is triggered.

What ends up happening in this situation is that the M68000 samples the IPL lines as priority 4 for the HINT, processes the interrupt, and sends an INTAK, but between the time when the M68000 samples the IPL lines, the VDP changes their state to priority 6 for the VINT. The M68000 is now ready to send an INTAK for the line 224 HINT, but in the VDP, the VINT has jumped to the foreground, and the VDP is now waiting for an INTAK for the VINT, not the HINT. When INTAK is received by the VDP, it thinks the INTAK is for the VINT, but it's actually for the line 224 HINT. Having received an INTAK for what it thinks is the VINT, it sets the IPL lines back to priority 4 and waits for an INTAK for the line 224 HINT. The M68000 then samples the IPL lines again next cycle, and sees them sitting at priority 4, processes it as another interrupt, and sends INTAK. Having received the second INTAK, the VDP then believes the line 224 HINT has been acknowledged, and negates all the IPL lines.

So, the VDP thinks both the line 224 HINT and the VINT has been received, but in fact the M68000 has taken the line 224 HINT twice, and missed the VINT completely. This happens because the VDP incorrectly changes the IPL lines during the interrupt acknowledge cycle, before INTAK has been received.