UMDK manufacturing, part 2: Software

Hosted forum for UMDK related questions

Moderators: BigEvilCorporation, prophet36

prophet36
Very interested
Posts: 234
Joined: Sat Dec 13, 2008 6:58 pm
Location: London, UK
Contact:

Re: UMDK manufacturing, part 2: Software

Post by prophet36 » Wed Jan 06, 2016 7:53 pm

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.

Mask of Destiny
Very interested
Posts: 615
Joined: Thu Nov 30, 2006 6:30 am

Re: UMDK manufacturing, part 2: Software

Post by Mask of Destiny » Thu Jan 07, 2016 12:01 am

prophet36 wrote:
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.
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.
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.

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).

HardWareMan
Very interested
Posts: 745
Joined: Sat Dec 15, 2007 7:49 am
Location: Kazakhstan, Pavlodar

Re: UMDK manufacturing, part 2: Software

Post by HardWareMan » Thu Jan 07, 2016 6:18 am

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:
Image

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
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).

prophet36
Very interested
Posts: 234
Joined: Sat Dec 13, 2008 6:58 pm
Location: London, UK
Contact:

Re: UMDK manufacturing, part 2: Software

Post by prophet36 » Thu Jan 07, 2016 6:56 pm

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
Ooops, you're right. Apologies for doubting you!

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?

Montserrat
Very interested
Posts: 115
Joined: Fri Sep 18, 2015 2:56 pm

Re: UMDK manufacturing, part 2: Software

Post by Montserrat » Thu Jan 07, 2016 7:58 pm

prophet36 wrote:
Montserrat wrote:Is there any other way to make that check?
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):
ill do it tomorrow, im exausted today.
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?
Sure, original carts works fine.
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:
Tried it, but illegar error on sega's logo persisted. Here you have the trace:

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...

Image

prophet36
Very interested
Posts: 234
Joined: Sat Dec 13, 2008 6:58 pm
Location: London, UK
Contact:

Re: UMDK manufacturing, part 2: Software

Post by prophet36 » Thu Jan 07, 2016 8:58 pm

Montserrat wrote:Tried it, but illegar error on sega's logo persisted
Shit. If it isn't one thing, it's another:

Image

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.
Montserrat wrote:Masami ishikawa, was in charge, ask him lol...
Haha excellent. There's an interview with him here, where he talks about the challenges of the memory bus design.

MintyTheCat
Very interested
Posts: 484
Joined: Sat Mar 05, 2011 11:11 pm
Location: Berlin, Germany

Re: UMDK manufacturing, part 2: Software

Post by MintyTheCat » Thu Jan 07, 2016 10:52 pm

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...

Image
I have some notes and interviews - please check your mail, Chris.
UMDK Fanboy

Montserrat
Very interested
Posts: 115
Joined: Fri Sep 18, 2015 2:56 pm

Re: UMDK manufacturing, part 2: Software

Post by Montserrat » Thu Jan 07, 2016 11:00 pm

prophet36 wrote:
Montserrat wrote:Masami ishikawa, was in charge, ask him lol...
Haha excellent. There's an interview with him here, where he talks about the challenges of the memory bus design.
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.

http://readonlymemory.vg/shop/book/sega ... ted-works/

Montserrat
Very interested
Posts: 115
Joined: Fri Sep 18, 2015 2:56 pm

Re: UMDK manufacturing, part 2: Software

Post by Montserrat » Thu Jan 07, 2016 11:00 pm

double posting edit.
Last edited by Montserrat on Thu Jan 07, 2016 11:01 pm, edited 2 times in total.

MintyTheCat
Very interested
Posts: 484
Joined: Sat Mar 05, 2011 11:11 pm
Location: Berlin, Germany

Re: UMDK manufacturing, part 2: Software

Post by MintyTheCat » Thu Jan 07, 2016 11:05 pm

Montserrat wrote:double posting edit.
Make that a triple :D
UMDK Fanboy

Mask of Destiny
Very interested
Posts: 615
Joined: Thu Nov 30, 2006 6:30 am

Re: UMDK manufacturing, part 2: Software

Post by Mask of Destiny » Fri Jan 08, 2016 12:21 am

HardWareMan wrote:You just must not forget about propagation delay.
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:I pretty interested about this chip
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.
prophet36 wrote:Ooops, you're right. Apologies for doubting you!
Not a problem.
prophet36 wrote: I assume the Z80 accesses on the 68000 bus are synchronous to VCLK?
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:This means that the address was still changing at the point when /OE asserts.
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:There's an interview with him here, where he talks about the challenges of the memory bus design.
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
Very interested
Posts: 234
Joined: Sat Dec 13, 2008 6:58 pm
Location: London, UK
Contact:

Re: UMDK manufacturing, part 2: Software

Post by prophet36 » Fri Jan 08, 2016 9:53 pm

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.
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.
HardWareMan wrote:Arbiter's CE0 is so weak pin that very frequently fried up, causing MD malfunction.
I wonder if the arbiter's /BR and /BGACK are similarly weak? This could explain it.

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:
Dr. MefistO wrote:But who will spend the money only for the chance of good testing results?
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.

Montserrat
Very interested
Posts: 115
Joined: Fri Sep 18, 2015 2:56 pm

Re: UMDK manufacturing, part 2: Software

Post by Montserrat » Sun Jan 17, 2016 10:01 am

Ok then shall i share the manufacturer to public, including a big warning about the compatibility?

prophet36
Very interested
Posts: 234
Joined: Sat Dec 13, 2008 6:58 pm
Location: London, UK
Contact:

Re: UMDK manufacturing, part 2: Software

Post by prophet36 » Sun Jan 17, 2016 11:02 am

Montserrat wrote:Ok then shall i share the manufacturer to public, including a big warning about the compatibility?
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.

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.

Burbruee
Interested
Posts: 29
Joined: Sun Oct 11, 2015 12:30 am

Re: UMDK manufacturing, part 2: Software

Post by Burbruee » Sun Jan 17, 2016 7:23 pm

prophet36 wrote:I think it would be good to wait until Burbruee has tested the 20160105 fix.
Alright, it's finally done.
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.

Post Reply