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.