UMDK manufacturing, part 2: Software
Moderators: BigEvilCorporation, prophet36
Re: UMDK manufacturing, part 2: Software
As well as the "extract the original VCLK timing" thing, I'd also like to augment the trace log with an instruction disassembly column, like in Eke's logic analyzer trace. I reckon I could do that using a 68000 emulator running over the raw trace data.
-
- Very interested
- Posts: 624
- Joined: Thu Nov 30, 2006 6:30 am
Re: UMDK manufacturing, part 2: Software
The weird pattern you see in HardWareMan's trace is due to VRAM only being byte-wide (not due to rendering, there would be much bigger delays in that case). Words are read full speed (one word every 4 VDP clocks) until the FIFO is full and then effectively half that speed afterwards. The second fast section is due to a refresh cycle. You'll see the first access in that group of 4 is normal and the next 2 have CAS2 before CAS0 (for some reason there are 2 refresh cycles on the 68K side. The fourth one follows immediately because there is only one refresh cycle on the VDP side so it was able to get a 2nd write in while the input side was still busy with refresh.prophet36 wrote:It's pretty obvious from the beating effects in your trace that whilst the DMA FIFO's output end is indeed in some other clock domain (presumably MCLK/4 or MCLK/5), the input end is definitely in the VCLK clock-domain.Mask of Destiny wrote:DMA is definitely not synchronous to VCLK as it's synchronous to the current VDP clock which is either MCLK/4 or MCLK/5 depending on the horizontal resolution and scanline position. So this wouldn't be a general purpose modification, but for what Nemesis is trying to do DMA isn't relevant.
If you zoom in on the "closeup" trace it's clear that CAS0 and CAS2 are not synchronous to VCLK in the DMA section. The first falling edge of CAS0 is halfway between the rising and falling edge of VCLK whereas the second one is shortly after the falling edge of VCLK. Each memory access takes a bit more than 2 cycles of VCLK which is what you would expect in H40 mode (16/7 ~ 2.29).
-
- Very interested
- Posts: 750
- Joined: Sat Dec 15, 2007 7:49 am
- Location: Kazakhstan, Pavlodar
Re: UMDK manufacturing, part 2: Software
You just must not forget about propagation delay. Also as EDCLK is VDP core clock its logical that DMA run on it. Yes, VDP eat MCLK but VDP chip also contain M68K bus state machine to sync the M68K.
I sure I can capture all bus activity relative to MCLK (single edge or even both edges), but I think it will be overkill.
Anyway, I already paid for decaping process and send this board as original. Also, I have this board and I pretty interested about this chip:
Please notice that arbiter is 80 QFP not 100 QFP. I hope this time there will be much clear DIE shots (include redo YM2612 DIE shots).
I sure I can capture all bus activity relative to MCLK (single edge or even both edges), but I think it will be overkill.
Anyway, I already paid for decaping process and send this board as original. Also, I have this board and I pretty interested about this chip:
Code: Select all
1 - GND 16 - +5V
2 - VDP#43 (HSYNC) 15 - +5V
3 - GND 14 - +5V
4 - VDP#84 VA11 13 - +5V
5 - VDP#45 M3 12 - N.C.
6 - VDP#117 OEO 11 - RAM LCS (IA14)
7 - VDP#52 MCLK 10 - RAM HOE (EOE)
8 - GND 9 - VDP#53 EDCLK
Re: UMDK manufacturing, part 2: Software
Ooops, you're right. Apologies for doubting you!Mask of Destiny wrote:If you zoom in on the "closeup" trace it's clear that CAS0 and CAS2 are not synchronous to VCLK in the DMA section
I don't envy the guy at SEGA whose job it was to design that bus arbitration logic, using only 1980s technology!
I could probably still do the software PLL thing to match a VCLK period to the UMDK trace timestamps though; I'd just have to make sure I only feed the timestamps of CPU cycles into the PLL logic (i.e throw away DMA timestamps). I assume the Z80 accesses on the 68000 bus are synchronous to VCLK?
-
- Very interested
- Posts: 115
- Joined: Fri Sep 18, 2015 2:56 pm
Re: UMDK manufacturing, part 2: Software
ill do it tomorrow, im exausted today.prophet36 wrote:Actually, you could use your multimeter. Be sure to put it in voltage mode, then get the PAL-i machine to do the black-screen thing and then carefully measure the voltage on these pins of the 68000 (use this pic for reference if necessary):Montserrat wrote:Is there any other way to make that check?
Sure, original carts works fine.prophet36 wrote: Out of interest do you have an original Sonic 1 cart? Or a flash-cart you can load the .bin file on? Can you try that on the PAL-i machine, just as a sanity-check?
Tried it, but illegar error on sega's logo persisted. Here you have the trace:prophet36 wrote: Also, I have implemented the logic to clean up the /OE signal a bit. I don't expect this to fix your PAL-i machine, but I'm hoping it will fix yours and Burbruee's PAL-G machines:
https://mega.nz/#!mEFVkDCK!X0rJkRJ-j0nD ... QUcroLsAJE
prophet36 wrote: I don't envy the guy at SEGA whose job it was to design that bus arbitration logic, using only 1980s technology!
Masami ishikawa, was in charge, ask him lol...
Re: UMDK manufacturing, part 2: Software
Shit. If it isn't one thing, it's another:Montserrat wrote:Tried it, but illegar error on sega's logo persisted
This means that the address was still changing at the point when /OE asserts. I suppose I could just hack it by increasing the delay before each read begins. I'd have to gather a lot of data from soak-testing games, and distill that into statistics to tell me whether it would be safe. It might work, but it hardly feels like an elegant solution. To debug this properly we'd need someone with more experience with fault-finding electronics, and better testgear than you or I possess (e.g a digital storage oscilloscope capable of being triggered on the output of a logic analyzer). Unfortunately, pretty much all of UMDK's design is built on the fundamental assumption that the address will be stable at the point when /OE asserts, which is not the case in your trace. Anyway, let's see if the 20160105 FPGA binary works any better on Burbruee's PAL-G machines.
Haha excellent. There's an interview with him here, where he talks about the challenges of the memory bus design.Montserrat wrote:Masami ishikawa, was in charge, ask him lol...
-
- Very interested
- Posts: 484
- Joined: Sat Mar 05, 2011 11:11 pm
- Location: Berlin, Germany
Re: UMDK manufacturing, part 2: Software
I have some notes and interviews - please check your mail, Chris.Montserrat wrote:prophet36 wrote:
prophet36 wrote: I don't envy the guy at SEGA whose job it was to design that bus arbitration logic, using only 1980s technology!
Masami ishikawa, was in charge, ask him lol...
UMDK Fanboy
-
- Very interested
- Posts: 115
- Joined: Fri Sep 18, 2015 2:56 pm
Re: UMDK manufacturing, part 2: Software
I've read that interview at the collected works megadrive book, its a 350 page book of awesome. 60 pages for interviews with designers of hardware, software and marketing of the era, i really enjoyed the book.prophet36 wrote:Haha excellent. There's an interview with him here, where he talks about the challenges of the memory bus design.Montserrat wrote:Masami ishikawa, was in charge, ask him lol...
http://readonlymemory.vg/shop/book/sega ... ted-works/
-
- Very interested
- Posts: 115
- Joined: Fri Sep 18, 2015 2:56 pm
Re: UMDK manufacturing, part 2: Software
double posting edit.
Last edited by Montserrat on Thu Jan 07, 2016 11:01 pm, edited 2 times in total.
-
- Very interested
- Posts: 484
- Joined: Sat Mar 05, 2011 11:11 pm
- Location: Berlin, Germany
Re: UMDK manufacturing, part 2: Software
Make that a tripleMontserrat wrote:double posting edit.
UMDK Fanboy
-
- Very interested
- Posts: 624
- Joined: Thu Nov 30, 2006 6:30 am
Re: UMDK manufacturing, part 2: Software
Propagation delay would cause the signals to be out of phase by a more or less fixed amount. That is very clearly not the case here.HardWareMan wrote:You just must not forget about propagation delay.
Based on what it's connected to, I imagine it's responsible for generating EDCLK. I get the impression that Sega originally hoped to get away with just using MCLK/4 for H40 (such a mode is still available), but it was too out of spec for some TVs and so as a last minute change, an external circuit was added for generating a clock signal that switches between MCLK/4 and MCLK/5 during Hsync to get the pulse and overall line length correct. Just a guess though.HardWareMan wrote:I pretty interested about this chip
Not a problem.prophet36 wrote:Ooops, you're right. Apologies for doubting you!
Unfortunately, the captures I've done of such accesses didn't contain most of the 68K bus control signals. !BR appears to be asserted synchronous to VCLK, but re-examining my DMA captures suggest that's also true for DMA.prophet36 wrote: I assume the Z80 accesses on the 68000 bus are synchronous to VCLK?
This is probably obvious, but that shouldn't happen. Makes me think there's a bad connection or noise on one or more of the address lines.prophet36 wrote:This means that the address was still changing at the point when /OE asserts.
It's possible I'm mistaken, but I think he's talking about the challenge of fully taking advantage of the dual port VRAM used by the VDP, not the 68k memory bus. The VRAM used in the genesis seems to be mostly intended for use in a bitmapped display. Using it optimally for a tile-based display requires a bit of cleverness. Essentially all accesses are organized to read 4 bytes at a time via the serial port and it sets up the address for the next 4-byte read concurrent with reading out the current 4 bytes. One disadvantage to this setup is that the parallel port is nearly useless as the address lines are shared between the two ports.prophet36 wrote:There's an interview with him here, where he talks about the challenges of the memory bus design.
Re: UMDK manufacturing, part 2: Software
Here's where it gets interesting. This problem only seems to affect EU PAL-G MD1 consoles. The 68000 wouldn't crash on the Sonic 1 intro if the Z80 happened to read junk PCM data; for the 68000 to get an exception, a 68000 instruction fetch must have been misread. But in other tests, vanilla 68000 code (i.e code that does no VDP DMA or Z80 cart reads) executes flawlessly, so the problem must be somewhere in the bus arbitration on this model of console. It's as though the 68000 and the bus-arbiter sometimes overlap and both try to drive the bus. It wouldn't affect regular game-carts since the mask ROMs are asynchronous. But it will play hell with a synchronous design like UMDK.Mask of Destiny wrote:This is probably obvious, but that shouldn't happen. Makes me think there's a bad connection or noise on one or more of the address lines.
I wonder if the arbiter's /BR and /BGACK are similarly weak? This could explain it.HardWareMan wrote:Arbiter's CE0 is so weak pin that very frequently fried up, causing MD malfunction.
I'd really like to be able to say that if there are no manufacturing faults, the UMDK design will work on 100% of consoles, otherwise people will (quite understandably) say things like:
Unfortunately, if there are cases where the address bus is not stable when /OE (/CAS0) asserts, there's not much I can do. I will just have to add a warning saying something like "may not work on older model consoles". In fact, a quick googling reveals stability problems with older model consoles on other SDRAM-based carts, like the Mega Everdrive.Dr. MefistO wrote:But who will spend the money only for the chance of good testing results?
-
- Very interested
- Posts: 115
- Joined: Fri Sep 18, 2015 2:56 pm
Re: UMDK manufacturing, part 2: Software
Ok then shall i share the manufacturer to public, including a big warning about the compatibility?
Re: UMDK manufacturing, part 2: Software
I think it would be good to wait until Burbruee has tested the 20160105 fix. Right now we just don't know how to categorise the compatibility warning; all we know is that some early-model consoles have a lot of internal noise, which UMDK is unable to cope with. We don't know why some old consoles end up being noisy and others clean.Montserrat wrote:Ok then shall i share the manufacturer to public, including a big warning about the compatibility?
That said, I think the response to your second-batch offer speaks volumes. I'm glad you were able to prove that it *is* possible to get UMDK carts built by a professional manufacturer, and I'm glad we were able to develop all the tools to help pinpoint problems if and when they do occur, but I honestly don't expect too many other people to be interested.
Re: UMDK manufacturing, part 2: Software
Alright, it's finally done.prophet36 wrote:I think it would be good to wait until Burbruee has tested the 20160105 fix.
https://www.dropbox.com/s/mhuit8moxv0qn ... g.bz2?dl=0
Sonic1 SEGA screen trace with line 111 emulator $00071FCA
The machine was set to 60 Hz.