UMDK manufacturing, part 2: Software
Moderators: BigEvilCorporation, prophet36
-
- Very interested
- Posts: 750
- Joined: Sat Dec 15, 2007 7:49 am
- Location: Kazakhstan, Pavlodar
Re: UMDK manufacturing, part 2: Software
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.
Re: UMDK manufacturing, part 2: Software
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?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.
-
- Very interested
- Posts: 484
- Joined: Sat Mar 05, 2011 11:11 pm
- Location: Berlin, Germany
Re: UMDK manufacturing, part 2: Software
Yes, VDP DMA 'robs' the bus and as such /AS is not to be relied on.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?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 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
Re: UMDK manufacturing, part 2: Software
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...):
For comparison, here's what it should look like (this is from your PAL-G trace, actually):
(click the images to expand)
Notice:
One thing which springs to mind is this:
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.
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...):
For comparison, here's what it should look like (this is from your PAL-G trace, actually):
(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.
One thing which springs to mind is this:
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.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
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.
-
- Very interested
- Posts: 115
- Joined: Fri Sep 18, 2015 2:56 pm
Re: UMDK manufacturing, part 2: Software
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: 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.
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.prophet36 wrote:
Is this "old capacitor" problem common? Could it also be affecting the PAL-I machine?
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.
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.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.
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.
-
- Very interested
- Posts: 750
- Joined: Sat Dec 15, 2007 7:49 am
- Location: Kazakhstan, Pavlodar
Re: UMDK manufacturing, part 2: Software
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?
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.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.
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.
-
- Very interested
- Posts: 484
- Joined: Sat Mar 05, 2011 11:11 pm
- Location: Berlin, Germany
Re: UMDK manufacturing, part 2: Software
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?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.
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
-
- Very interested
- Posts: 115
- Joined: Fri Sep 18, 2015 2:56 pm
Re: UMDK manufacturing, part 2: Software
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.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.
Here is a nice link, but not all MD revisions are present:
http://segaretro.org/Mega_Drive_PCB_revisions
-
- Very interested
- Posts: 484
- Joined: Sat Mar 05, 2011 11:11 pm
- Location: Berlin, Germany
Re: UMDK manufacturing, part 2: Software
That is a useful resource but the photos need to be improved.Montserrat wrote: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.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.
Here is a nice link, but not all MD revisions are present:
http://segaretro.org/Mega_Drive_PCB_revisions
I have recently moved house but the three MD1 machines that I can find easily all have the same PAL VA4 Motherboard as:
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
UMDK Fanboy
Re: UMDK manufacturing, part 2: Software
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.
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.
-
- Very interested
- Posts: 484
- Joined: Sat Mar 05, 2011 11:11 pm
- Location: Berlin, Germany
Re: UMDK manufacturing, part 2: Software
Yes, that is useful information.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.:
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
Re: UMDK manufacturing, part 2: Software
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:unfortunately i got fired day 1
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?
Code: Select all
PIN SIGNAL VOLTAGE?
6 /AS ?
10 /DTACK ?
11 /BG ?
12 /BGACK ?
13 /BR ?
15 CLK ?
17 /HALT ?
22 /BERR ?
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?Montserrat wrote:I have no problem if this pal-i megadrive does not work, i can use any of the others
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
$
OK great, can you try the updated .xsvf file above, which includes a deglitcher which will hopefully fix the problems you've been seeing.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.
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.HardWareMan wrote:What about DRAM signals? You should know that CAS2 is one clock early CAS0 and used for demultiplexing 8bit ROM
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.
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:As I recall I have not ever owned a PAL HK
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.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
-
- Very interested
- Posts: 484
- Joined: Sat Mar 05, 2011 11:11 pm
- Location: Berlin, Germany
Re: UMDK manufacturing, part 2: Software
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: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:As I recall I have not ever owned a PAL HK
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.prophet36 wrote: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.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
UMDK Fanboy
-
- Very interested
- Posts: 750
- Joined: Sat Dec 15, 2007 7:49 am
- Location: Kazakhstan, Pavlodar
Re: UMDK manufacturing, part 2: Software
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: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.HardWareMan wrote:What about DRAM signals? You should know that CAS2 is one clock early CAS0 and used for demultiplexing 8bit ROM
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.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?
Notice that DMA has jitter caused by VDP FIFO filling while rendering. And little bit closer:
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.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.
Re: UMDK manufacturing, part 2: Software
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.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.
Your traces also contradict MoD's comment here:
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.
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.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.