UMDK manufacturing, part 2: Software

Hosted forum for UMDK related questions

Moderators: BigEvilCorporation, prophet36

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

Re: UMDK manufacturing, part 2: Software

Post by HardWareMan » Mon Jan 04, 2016 5:37 pm

prophet36: Since UMDK is a slave on M68K bus, I think you should allow only one access cycle from AS assertion. Any other "request" must be discarded till next AS assertion.

User avatar
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 » Mon Jan 04, 2016 7:03 pm

HardWareMan wrote:prophet36: Since UMDK is a slave on M68K bus, I think you should allow only one access cycle from AS assertion. Any other "request" must be discarded till next AS assertion.
I'm fairly sure that won't work, since VDP DMA doesn't assert /AS, only /C_OE, which is the signal with the glitch above. Besides, if /C_OE is glitchy on some hardware revisions, can we expect any better from /AS?

User avatar
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 » Mon Jan 04, 2016 7:09 pm

prophet36 wrote:
HardWareMan wrote:prophet36: Since UMDK is a slave on M68K bus, I think you should allow only one access cycle from AS assertion. Any other "request" must be discarded till next AS assertion.
I'm fairly sure that won't work, since VDP DMA doesn't assert /AS, only /C_OE, which is the signal with the glitch above. Besides, if /C_OE is glitchy on some hardware revisions, can we expect any better from /AS?
Yes, VDP DMA 'robs' the bus and as such /AS is not to be relied on.

I think we need to have a set of MD versions to test all our ideas out upon. I know that me and Montserrat have provided some but some lists and volunteers would be a step forward. I will check which versions and revs I have then list them and yes, I can continue being a tester.
UMDK Fanboy

User avatar
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 » Mon Jan 04, 2016 9:57 pm

Hi Montserrat!

I looked at your PAL-I trace, and it's a complete mystery. The 68000 just seems to stop executing in the middle of an innocuous bit of code (ooh, déjà vu...):

Image

For comparison, here's what it should look like (this is from your PAL-G trace, actually):

Image

(click the images to expand)

Notice:
  • The /OE signal is clean, no glitches.
  • There are no writes (/LDSW and /UDSW stay high), so the CPU didn't crash (illegal instruction, address error, etc).
  • The /OE signal goes high (deasserted) in the middle, and stays high thereafter, so it's not waiting for /DTACK.
There are only three scenarios that I know of where a 68000 will just stop: a double bus error, waiting for /DTACK, and a stopped clock. A double bus error would show some write activity (i.e I'd expect to see the 68000 trying to write its PC & SR to the supervisor stack), and waiting for /DTACK will only happen when /OE is asserted. Neither of those are true, so that leaves the third possibility: a stopped clock. Unfortunately I don't know enough about the MegaDrive's internals to confirm or deny that possibility. If you have an oscilloscope you could look at the /HALT and CLK signals on the 68000 when it's in this "blank screen" state, which would give us a bit more information.

One thing which springs to mind is this:
Montserrat wrote:This is the asian pal, here UMDK works perfect...some weird glitches, but im sure its due to old capacitors, nothing related to UMDK
Is this "old capacitor" problem common? Could it also be affecting the PAL-I machine? If the problem is power-related you could solder a big electrolytic capacitor on the UMDK's +5V rail and see if that helps. Just comparing the logic analyzer traces, your PAL-I machine looks like is has more noise on the address bus than the PAL-G machine, so perhaps it's a generally noisier environment. I guess it could be the PIC in the region mod causing some extra noise? Truthfully, I'm really just a software engineer; once a bit of digital electronics starts misbehaving for analog and/or power reasons I very quickly get out of my depth.

I'm fairly sure I can fix your PAL-G machine and Burbruee's MD1 with the FPGA fix I mentioned previously, but right now I have no idea how to make your UMDK cart work with your PAL-I machine.

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

Re: UMDK manufacturing, part 2: Software

Post by Montserrat » Tue Jan 05, 2016 12:43 am

prophet36 wrote: If you have an oscilloscope you could look at the /HALT and CLK signals on the 68000 when it's in this "blank screen" state, which would give us a bit more information.
I'm sorry i dont have a osciloscope, and unfortunately i got fired day 1 (Happy new year mr Montserrat, your whole team is fired! yaay :( ) so i cannot afford to expend a single euro. Is there any other way to make that check?
prophet36 wrote:
Is this "old capacitor" problem common? Could it also be affecting the PAL-I machine?
The old capacitor problem its in most megadrives, it produces color banding, bad audio quality an other glitches like some weird palletes or failed alpha-test pixels on some sprites, posibly due to some noise input to the RGB video encoder (im not sure), but its nothing that affects the 68k bus i think.

All my machines have the color banding problem btw, its very normal they have +25 years.

Nomad works 100% fine btw, no problems at all.

prophet36 wrote:
Just comparing the logic analyzer traces, your PAL-I machine looks like is has more noise on the address bus than the PAL-G machine, so perhaps it's a generally noisier environment. I guess it could be the PIC in the region mod causing some extra noise?

I'm fairly sure I can fix your PAL-G machine and Burbruee's MD1 with the FPGA fix I mentioned previously, but right now I have no idea how to make your UMDK cart work with your PAL-I machine.
Well it may be caused by the switchless mod, but this cannot be undone because it requires to cut some tracks. I have no problem if this pal-i megadrive does not work, i can use any of the others, i only asked this to make UMDK more compatible world-wide.

Pal-i versions are original from UK (also HK too), so may be you can find a cheap non-modded one in there. Or may be focus on the pal-g that is the most common in europe.

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

Re: UMDK manufacturing, part 2: Software

Post by HardWareMan » Tue Jan 05, 2016 12:19 pm

prophet36 wrote:I'm fairly sure that won't work, since VDP DMA doesn't assert /AS, only /C_OE, which is the signal with the glitch above. Besides, if /C_OE is glitchy on some hardware revisions, can we expect any better from /AS?
MintyTheCat wrote:Yes, VDP DMA 'robs' the bus and as such /AS is not to be relied on.

I think we need to have a set of MD versions to test all our ideas out upon. I know that me and Montserrat have provided some but some lists and volunteers would be a step forward. I will check which versions and revs I have then list them and yes, I can continue being a tester.
OK. What about DRAM signals? You should know that CAS2 is one clock early CAS0 and used for demultiplexing 8bit ROM. No problems with DMA.

And one more thing: CART signal must be controlled by open collector output directly, without any resistors. I had some troubles on VA4 board, and I had to short out that resistor. CART directly affected to CE0: with 33 Ohm resistor on CART I had strong noise on CE0. DTACK with same rules.
Image

User avatar
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 » Tue Jan 05, 2016 1:12 pm

Montserrat wrote: Well it may be caused by the switchless mod, but this cannot be undone because it requires to cut some tracks. I have no problem if this pal-i megadrive does not work, i can use any of the others, i only asked this to make UMDK more compatible world-wide.

Pal-i versions are original from UK (also HK too), so may be you can find a cheap non-modded one in there. Or may be focus on the pal-g that is the most common in europe.
Does anyone have a photo of the Pal-i MD version? Is there any other way besides looking at the MD PCB to work out if you have a Pal-i model?
We can look at having one sent to Chris McClelland for testing. I have many MDs at my house so perhaps I have one without realising it as I only actually use two machines for UMDK and both are MD1 machines that I bought in Germany.
UMDK Fanboy

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

Re: UMDK manufacturing, part 2: Software

Post by Montserrat » Tue Jan 05, 2016 2:56 pm

MintyTheCat wrote: Does anyone have a photo of the Pal-i MD version? Is there any other way besides looking at the MD PCB to work out if you have a Pal-i model?
We can look at having one sent to Chris McClelland for testing. I have many MDs at my house so perhaps I have one without realising it as I only actually use two machines for UMDK and both are MD1 machines that I bought in Germany.
You can check the version of the console in the ventral area. About the version of the board its another history, you have to id by comparing components.

Here is a nice link, but not all MD revisions are present:

http://segaretro.org/Mega_Drive_PCB_revisions

User avatar
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 » Tue Jan 05, 2016 4:23 pm

Montserrat wrote:
MintyTheCat wrote: Does anyone have a photo of the Pal-i MD version? Is there any other way besides looking at the MD PCB to work out if you have a Pal-i model?
We can look at having one sent to Chris McClelland for testing. I have many MDs at my house so perhaps I have one without realising it as I only actually use two machines for UMDK and both are MD1 machines that I bought in Germany.
You can check the version of the console in the ventral area. About the version of the board its another history, you have to id by comparing components.

Here is a nice link, but not all MD revisions are present:

http://segaretro.org/Mega_Drive_PCB_revisions
That is a useful resource but the photos need to be improved.

I have recently moved house but the three MD1 machines that I can find easily all have the same PAL VA4 Motherboard as:

Image

I know that I gave a few MDs away before I moved to Germany.

You can also see one of my machines set up with db's MD Cart Probe Adapter board (get one as they are handy to have) and UMDK hooked up to one of my LAs.

As I recall I have not ever owned a PAL HK, US or Japanese machine and have relied on 50/60Hz and region switches on all my machines. I am not at the stage where my game software has required to be tested on many versions of the MD either so I have not gotten around to getting the NTSC machines or the HK machines - I will sort that out this year.

I know a mate of mine who had dozens of MD machines and I know he has several NTSC and PAL machines so I will ask him if he can pass some along.
Let me ask around and see if we can come up with this version and revision to pass to one of us who own a Scope/LA.

(*) I will give you back your Zero Wing cart, Chris :lol:
UMDK Fanboy

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

Re: UMDK manufacturing, part 2: Software

Post by Burbruee » Tue Jan 05, 2016 5:23 pm

Both of my PAL-G Mega Drive MD1s (one with a region switch, and one stock unmodified) have the VA6 motherboard and have the freezing and crashing problem. Don't know if this information is worth anything, just thought I'd point it out.

Sorry about not posting and testing much lately, very busy at work this time of the year. But I still read and keep up with the thread and still interested in using the UMDK for development when I have more free time. :wink:

User avatar
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 » Tue Jan 05, 2016 6:09 pm

Burbruee wrote:Both of my PAL-G Mega Drive MD1s (one with a region switch, and one stock unmodified) have the VA6 motherboard and have the freezing and crashing problem. Don't know if this information is worth anything, just thought I'd point it out.:
Yes, that is useful information.

I think we need to get all the UMDK Testers to make a list of all the MD hardware that they have available for testing and then use that pool of hardware to test UMDK out on to iron out the compatability issues.

I have asked around and will be having some NTSC machines sent to me over the next few weeks so hopefully we will have some hardware that is not in our group to test UMDK out on.

I do recall there being issues that did not work on the MD2 that Chris used for development but they worked fine on my MD1 a while back.

Also, if anyone has a Genesis 3 (http://segaretro.org/Genesis_3) which was a US only release very late on in the MD's life then that is also a target worth adding to the group. Also, do not be too upset if somethings do not work on the Genesis 3 as even commercial titles fail on this too.

The more hardware that we have to test with the more sure we can all be that UMDK will run on the MD without issue.

Cheers,

Minty.
UMDK Fanboy

User avatar
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 » Tue Jan 05, 2016 7:57 pm

Montserrat wrote:unfortunately i got fired day 1
Shit, really sorry to hear that. Let me know if there's anything I can do (e.g proofread an English CV/Resume or whatever).
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):

Code: Select all

PIN  SIGNAL  VOLTAGE?
6    /AS     ?
10   /DTACK  ?
11   /BG     ?
12   /BGACK  ?
13   /BR     ?
15   CLK     ?
17   /HALT   ?
22   /BERR   ?
Montserrat wrote:I have no problem if this pal-i megadrive does not work, i can use any of the others
Thanks for your understanding. I was interested in this for academic reasons as much as anything. Also, of course, others less able and/or with poorer facilities than you may hit the same problem. 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?

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:

Code: Select all

$ cd ${HOME}
$ wget -q https://dl.dropboxusercontent.com/u/80983693/umdkv2/test-20160105.tar.gz
$ tar zxf test-20160105.tar.gz
$ cd test-20160105
$ flcli -v 1d50:602b -p J:A7A0A3A1:fpga.xsvf
Attempting to open connection to FPGALink device 1d50:602b...
Connected to FPGALink device 1d50:602b (firmwareID: 0xFFFF, firmwareVersion: 0x20140311)
Programming device...
$
$ ./loader -w ~/sonic1.bin:0 -x 2 -t trace.log:4096
UMDKv2 Loader Copyright (C) 2014 Chris McClelland

Putting MD in reset...
Writing SDRAM...
Releasing MD from reset...
Dumping logic analyzer trace to trace.log:4096
.........................................
Finished!
$ bzip2 trace.log
$
If Sonic 1 works OK, try some other games with this .xsvf file loaded into the FPGA. I don't need to see traces unless you get crashes.
Burbruee wrote:Both of my PAL-G Mega Drive MD1s (one with a region switch, and one stock unmodified) have the VA6 motherboard and have the freezing and crashing problem.
OK great, can you try the updated .xsvf file above, which includes a deglitcher which will hopefully fix the problems you've been seeing.
HardWareMan wrote:What about DRAM signals? You should know that CAS2 is one clock early CAS0 and used for demultiplexing 8bit ROM
I did not route CAS2 (I didn't know about it when I designed the bridge-board), but CAS0 is just another name for what I called /C_OE. I don't drive /DTACK at all (I just use the regions for which there is auto-DTACK generation). I don't use /CE0 at all (I do all my own address decoding), and I tie /CART directly to GND.

When you say CAS2 asserts one cycle earlier than CAS0, which clock are you referring to? The ~53MHz MCLK? Or the 68K clock? If you look at the logic analyzer traces I posted, the "newAddr" signal goes high when there's a new address on the address bus (i.e different from the address present during the previous 48MHz UMDK clock cycle). It seems like sometimes the address doesn't stabilize until only ~30ns or so before /OE (i.e CAS0) asserts, so there's not a lot of leeway. Does CAS2 only assert on reads like CAS0? Or does it also assert on writes?

Anyway, apart from the fact that since people already have hardware they've paid for so I don't want to make hardware changes, the bottom line is that if CAS0 is glitchy on these old-model consoles, surely it's quite likely that CAS2 will also be glitchy? In any case, hopefully my deglitch logic will work on Montserrat and Burbruee's PAL-G machines.
MintyTheCat wrote:As I recall I have not ever owned a PAL HK
According to Montserrat, the PAL-i machines sold in HK are the same as those sold in the UK. So if you have MD1 machines bought when you lived in the UK, they're probably PAL-i. Have you encountered any crashing games or corrupt sprites/backgrounds on any of your MegaDrives?
MintyTheCat wrote:I do recall there being issues that did not work on the MD2 that Chris used for development but they worked fine on my MD1
That was a genuine behavioural difference between hardware revisions, IIRC. Word-writes in the 0x000000-0x3FFFFF region get properly output on the bus on the MD1, but on the MD2 only the high (or low, I don't remember) byte gets driven on the bus. That's why the menu program has to use the SSF2 banking registers to load into the 0x000000-0x3FFFFF region.

User avatar
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 » Tue Jan 05, 2016 10:43 pm

prophet36 wrote:
MintyTheCat wrote:As I recall I have not ever owned a PAL HK
According to Montserrat, the PAL-i machines sold in HK are the same as those sold in the UK. So if you have MD1 machines bought when you lived in the UK, they're probably PAL-i. Have you encountered any crashing games or corrupt sprites/backgrounds on any of your MegaDrives?
I had to ask him as I was not sure what PAL-i actually was. HK was a bit of a mixed place in that they had both PAL and NTSC in parallel so it could have been that they were either NTSC or PAL.
prophet36 wrote:
MintyTheCat wrote:I do recall there being issues that did not work on the MD2 that Chris used for development but they worked fine on my MD1
That was a genuine behavioural difference between hardware revisions, IIRC. Word-writes in the 0x000000-0x3FFFFF region get properly output on the bus on the MD1, but on the MD2 only the high (or low, I don't remember) byte gets driven on the bus. That's why the menu program has to use the SSF2 banking registers to load into the 0x000000-0x3FFFFF region.
Yes, the issue arose in Universal-Soldier which worked under my PAL MD1 but did not work under your PAL MD2 and you fixed that.
UMDK Fanboy

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

Re: UMDK manufacturing, part 2: Software

Post by HardWareMan » Wed Jan 06, 2016 4:42 am

prophet36 wrote:
HardWareMan wrote:What about DRAM signals? You should know that CAS2 is one clock early CAS0 and used for demultiplexing 8bit ROM
I did not route CAS2 (I didn't know about it when I designed the bridge-board), but CAS0 is just another name for what I called /C_OE. I don't drive /DTACK at all (I just use the regions for which there is auto-DTACK generation). I don't use /CE0 at all (I do all my own address decoding), and I tie /CART directly to GND.
At 90s, I used only 2 diodes and one resistor for repair most MDs. Arbiter's CE0 is so weak pin that very frequently fried up, causing MD malfunction. But then we loose normal CART functional (anyway here was very small amount of MD CDs). So, it's seems to be OK to decode your own CE0.
prophet36 wrote:When you say CAS2 asserts one cycle earlier than CAS0, which clock are you referring to? The ~53MHz MCLK? Or the 68K clock? If you look at the logic analyzer traces I posted, the "newAddr" signal goes high when there's a new address on the address bus (i.e different from the address present during the previous 48MHz UMDK clock cycle). It seems like sometimes the address doesn't stabilize until only ~30ns or so before /OE (i.e CAS0) asserts, so there's not a lot of leeway. Does CAS2 only assert on reads like CAS0? Or does it also assert on writes?
There is only one clock domain at M68K bus: VCLK. I must correct myself with CAS0/CAS2 timing: CAS0 before CAS2. Sorry. Notice: CAS0 assert with AS simultaneously. But it must be OK while M68K is master: AS assert when address is steady. But your true: while DMA there is no AS.
Image
Notice that DMA has jitter caused by VDP FIFO filling while rendering. And little bit closer:
Image
prophet36 wrote:Anyway, apart from the fact that since people already have hardware they've paid for so I don't want to make hardware changes, the bottom line is that if CAS0 is glitchy on these old-model consoles, surely it's quite likely that CAS2 will also be glitchy? In any case, hopefully my deglitch logic will work on Montserrat and Burbruee's PAL-G machines.
I fully understand you because I hardware developer too and have some amount of clients. But I also believe that things should be done properly and not anyhow. Sometimes the cost of my time and money. Anyway, this is yours project. It is awesome and potentially useful. So, you're the boss. Thanks.

User avatar
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:32 pm

HardWareMan wrote:There is only one clock domain at M68K bus: VCLK. I must correct myself with CAS0/CAS2 timing: CAS0 before CAS2. Sorry. Notice: CAS0 assert with AS simultaneously. But it must be OK while M68K is master: AS assert when address is steady. But your true: while DMA there is no AS.
Ah, that makes more sense. And thanks for the logic-analyzer traces, they make things much clearer. The bit about the DMA FIFO filling up is particularly interesting. It gives me an idea for what Nemesis was asking about many months ago: since UMDK uses its own 48MHz clock and essentially treats the MD bus as fully asynchronous (it doesn't even look at VCLK), the timestamps in the instruction trace all reference that 48MHz clock. But it should be possible to write a kind of "software PLL" that can extract the original VCLK timings (assuming a long enough trace, which is not a problem) from the timestamps in the trace. I'll give that a go when I get time.

Your traces also contradict MoD's comment here:
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.
HardWareMan wrote:I fully understand you because I hardware developer too and have some amount of clients. But I also believe that things should be done properly and not anyhow. Sometimes the cost of my time and money. Anyway, this is yours project. It is awesome and potentially useful. So, you're the boss. Thanks.
100% agreed, things should be done properly. I think I can solve the few remaining hardware compatibility problems purely in the VHDL though, without needing to revise the PCBs. It's not my project though, and I don't think of myself as the boss: it's a community effort, and fully open-source. Professionally I'm a software engineer, so I'm pretty rubbish at designing and fault-finding electronics. But the great thing about open-source community efforts is there are many features that I personally don't care about (e.g game saves) that other people might want to implement. So they can download the C and VHDL source code and compile it using freely-available tools, or even download the KiCAD schematics and PCB layout and make changes there too. Unfortunately though that hasn't happened yet. I'd love to see more experienced people like you and Nemesis using and improving UMDK.

Post Reply

Who is online

Users browsing this forum: Google [Bot] and 4 guests