Page 2 of 2

Posted: Tue Mar 04, 2008 10:24 am
by Nemesis
Wow, I took awhile to write that. Your post wasn't there when I started.
If you read further:

....

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...
Hmm. Well, it does seem to suggest that, and if I hadn't just found out otherwise from my tests, I'd be inclined to agree with you. I can't speak for other processors personally, since I don't really have any experience coding to the metal on any other systems.
VDP requests automatic vectoring, that means that the VDP set /VPA and wait for acknowledge trough /VMA from the 68000.
Actually, VMA isn't used for interrupt processing, and isn't connected in the Mega Drive. Interrupts are acknowledged through the normal signal lines. Section 5.1.4 in the M68000 Users Manual shows an interrupt acknowledge cycle.

EDIT: From looking more closely, it looks like it's really the chip which signalled the interrupt which terminates the interrupt acknowledge cycle, either by asserting VPA or DTACK. Once the external chip signals either VPA or DTACK, it doesn't get another signal, so technically, there is no "INTAK" line normally. In the Mega Drive, they created an INTAK because the VDP doesn't directly assert VPA. The Bus Arbiter is the only chip which connects to the FC lines (to detect when an interrupt acknowledge cycle is running), and the VPA line (to autovector an interrupt). It then has an INTAK line running to the VDP, which the bus arbiter asserts to tell the VDP when it has completed the interrupt acknowledge cycle. It probably asserts this line in tandem with VPA.
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...
Well I guess that explains my problems with Lemmings then.

Posted: Tue Mar 04, 2008 11:06 am
by Eke
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.
this is interesting, maybe this is the Bus Arbitrer which acknowledge VINT immediately regardless of 68k interrupt mask by driving INTACK to the VDP...
ANyway, that means that there is NO pending VINT, have you tested the same signals (IPLx, INTACK, VPA) with HINT only, i.e VINT disabled through VDP register ?

If this is the case for both interrupts, I can't understand how the VDP know to keep the INT4 level pending ?


About the problem with HINT and VINT on the same line, I think we had the same explanation. Have you been able to manage signals in this particular case ?
Actually, VMA isn't used for interrupt processing, and isn't connected in the Mega Drive. Interrupts are acknowledged through the normal signal lines. Section 5.1.4 in the M68000 Users Manual shows an interrupt acknowledge cycle.
you're right, my mistake :oops:
so, in your test, have you traced FC0-FC1 state in parallel with IPL1-IPL2 after setting the SR to $27xx ? It seems so weird to me that the 68000 acknowledges a masked interrupt...

Posted: Mon Mar 10, 2008 1:04 am
by Nemesis
Just wanted to let you know, I was doing some much more thorough testing on this matter, and I got some results which contradicted tests I'd done previously. This was about 4 days ago now. I've been trying to get the time to go back and complete my testing, but I don't have a lot of free time right now, and it can be difficult to sample some of these lines. I wouldn't put a lot of stock in anything I've said so far until I or someone else can re-test and compile some definitive information. Hopefully I'll be able to get back to this quite soon, and publish a full description of how the VDP interrupts are signalled, with full timing information.

Posted: Mon Mar 10, 2008 1:10 pm
by Eke
I bet you didn't disabled interrupt correctly the first time ;)

anyway, I'm waiting for your results with lot of interest, I just wish one day I could do tests myself also :oops:

Posted: Mon Mar 10, 2008 9:04 pm
by Nemesis
If you're interested, the oscilloscope I'm using is the Hantek DSO 2150. You can view the product on their website at http://www.hantek.com.cn/english/produc ... sp?unid=63

It's a dual-channel Digitial Storage Oscilloscope, with completely PC-based controls. It has a pretty high sampling rate, and a reasonable sized buffer. It runs entirely off USB power, and you control it with a simple program.

I picked it up direct from Hantek (the manufacturers) through ebay last year, for around $300 IIRC. That includes two probes. I did quite a bit of research before I bought this, and there's nothing close to it from anywhere else for under $800. I won't lie, it's not the best oscilloscope in the world. Their software could be better for example. Unless you want to pay $1000+ however, you won't find anything better, and it's certainly been more than enough for all the samples I've taken on the Mega Drive. If you're looking for an oscilloscope for hobbyist work, I highly recommend it.

Posted: Tue Mar 11, 2008 5:45 pm
by Chilly Willy
I got my scope at St. Vincent DePaul (Catholic charity that handles donations and reselling used goods) for $5. If you don't mind used and/or old stuff, you can find some incredible deals at a place like that. Pentium systems for $20, monitors for $10, and old systems you won't find anywhere else. I picked up a portable C64 for $5. 8)

Posted: Wed Mar 12, 2008 6:46 pm
by Eke
well, there is a Tektronix oscillo at my work place taht I could discretly use but I definitively have to buy a genesis cart before I can do anything... it's just so expensive (i think) :roll:

Posted: Sun Jun 08, 2008 12:18 pm
by Eke
Charles McDonald has updated a doc fully describing (and more) the VDP pinout

interesting read: http://cgfm2.emuviews.com/txt/vdppin.txt

Posted: Tue Jun 10, 2008 5:54 pm
by Jorge Nuno
Awesome stuff, in that doc, but the SPA/B pin and the color bus need to be activated in a register beforehand, else they only output internal noise (color bus)

Methinks that they are enabled in bit4 in reg 0x0C and bit7 in reg 0x0B, respectively :wink:

Posted: Sat Jul 19, 2008 1:42 am
by Charles MacDonald
Jorge Nuno wrote:Awesome stuff, in that doc, but the SPA/B pin and the color bus need to be activated in a register beforehand, else they only output internal noise (color bus)

Methinks that they are enabled in bit4 in reg 0x0C and bit7 in reg 0x0B, respectively :wink:
Bit 7 of $8B "connects" the external 68000 address bus to the color bus, so that the 68000 can access color RAM without needing external logic to multiplex the color RAM address bus between the 68000 address bus and color bus. Think of it being a 'pass-through' enabling bit.

You could still multiplex it normally, I think Sega just figured as the VDP gets all the address pins anyway, this would simplify things.

I didn't mention this, but I should have - bit 4 controls SPA/B, it's like an enable gate that forces the pin low or allows the sprite indicator bit to be output. On System C-2, if bit 4 is reset then the sprites use the same palettes as the background.

Or maybe the polarity is reversed, I can't find my notes right now.

Posted: Tue Nov 03, 2009 4:43 pm
by Eke
VRAM interface signals

SD7-0 : Serial data bus
AD7-0 : Parallel address/data bus
/SE_0 : Serial data bus /OE
SC : Serial clock
/RAS_1 : Row address strobe
/CAS_1 : Column address strobe
/WE_1 : Common write strobe
/OE_1 : Common read strobe
By any chance, did anyone measured (if measurable), the Serial Clock frequency ? Does it changes with the horizontal resolution mode ?
This would help me figuring the number of VRAM access shared between CPU and VDP, among other things.

For the record, there have been some interesting findings about TMS9918 timings recently (source) and I would like to try to extrapolate them to the Genesis VDP.

What I know is that TMS9918 and SMS VDP VRAM clocks are the same but that the SMS one uses a 16-bits bus to get twice the sprite ability and background features.
The Genesis VDP uses an 8-bit bus for VRAM but since it has more abilities than the SMS VDP (and requires at least 4x more VRAM access per line), it would seems logical they simply multiplicated the VRAM clock.


EDIT: hum,now that I understand how VRAM (and SAM) works, it seems like my question did not make much sense. Since the VDP probably uses both parallel (for CPU access and for reading the name tables I guess) and serial (for pixel color data) ports, the total number of VRAM accesses per line is not so easy to guess.

The question would be to know how much time does serial AND parallel 8-bits access take (I imagine serial is faster) ?

Posted: Mon Jan 04, 2010 1:20 pm
by Oliver_A
The DRAM used by the Mega Drive VDP is a dual port design, which means that a read and read/write operation can occur at the same time. The VDP probably uses it for reading 16 bits of data on one cycle, writes however can occur only in 8 bit cycles.

Posted: Mon Jan 04, 2010 2:38 pm
by Eke
How does it technically works (and what signals/timings are used) ? Do you mean that parallel and serial access can be done in the same cycle ?

I've read the datasheet of the VRAM used by the VDP but it's not very clear in my mind.

Thanks

Posted: Mon Jan 04, 2010 4:59 pm
by Chilly Willy
VRAMs has a serial register in them as wide as the memory row. With a normal DRAM, when you access the ram, you supply a row address, then a column address, and that bit(s) are put on the bus. With VRAM, you do the row address, but instead of supplying a column, the entire row is written to a BIG serial register. After the memory cycle is done, the register is loaded and you can clock the data out a different port serially. The initial access is on the same bus, so you do need at least one cycle on the regular bus to load the serial register.

That works for writing, too. You can clock data in serially into the register, then write an entire row all at once in a single cycle.