SpritesMind.Net

I'm going to make a board with diodes Thank you so much for all your hard work so far on diagnostics. Thanks to you we now have a much better understanding of why some MD models suffer problems, and others don't. Also, thanks in advance for your work on this alternative bridge-board (irrespective o...

One thing I don't understand is if the rapid-switching of the buffer conveying the address-lines is causing /OE to also switch, that implies that /OE is not being actively driven. But if that were the case, then putting a 4K7 pull-up to +5V on /OE on the MD side would fix the problem, but when you t...

This is getting way out of my depth (as I said before, I'm no electronic engineer; I deal in 1s and 0s, not voltages and currents). Is it possible to check to see whether or not this address-line contention happens during Z80 arbitration even with a regular (i.e non-UMDK) cart? What about replacing ...

Still no better. [...] This behaviour of the buffer is undefined at this voltage and it seems to flip between high and low, and I reckon that's whats causing the noise on CAS0. I agree. Unfortunately, if this is the case, then the problem cannot be fixed properly without significant changes to the ...

OK, try this new FPGA binary. It stops driving the data bus soon after /OE deasserts, and it refuses to return the state-machine to the idle state until /OE has been deasserted for four consecutive cycles.

How really controls VDxx bus? It's controlled by the state-machine in the bus-arbiter . It's the std_logic_vector "mdData_io". Normally it's tri-stated, but several states drive it with a signal registered from the last word read from the SDRAM controller. If it UMDK side, I have some questions. Is...

How consistent is the time between the /OE assert and the rising-edge of the first spurious spike? I'm thinking of putting an output (maybe on the spare unused output currently labelled mdDTACK_out) to identify the Sonic1 PCM range, so we can see that alongside /OE. Regarding the address-line drift,...

If you correlate the logic analyzer output with an instruction-trace from the UMDK, you'll get a better idea of where the R/W foo is coming from: $ loader -w $HOME/sonic1.bin:0 -x 2 -t trace.bin:1024 UMDKv2 Loader Copyright (C) 2014 Chris McClelland Putting MD in reset... Writing SDRAM... Releasing ...

You could add logic to cover up the issue, but it doesn't fix the real problem (and I become less sure of the problem the more I look at it) OK, there are a few things we can try, to identify (and hopefully fix) the "real problem". Many of these ideas are just shots in the dark so don't be too upse...

An interesting thing occurred to me when I looked at your 'scope traces, concerning the instruction-trace Montserrat recorded last year (when one of his consoles was crashing in a similar place, on the "SEGA!" PCM on Sonic1's intro). We saw two adjacent reads of the same PCM address : 167355419 C RD...

OK so in summary, on the question of whether you see noise on /OE during PCM playback, keeping eveything else the same (bench PSU, same ROM, same UMDK cart, same way of measuring, same testgear etc): MD1 + Regular cart: NO MD2 + UMDK: NO MD1 + UMDK: YES At risk of jumping to conclusions from an obse...

playing a sound effect in MJ's Moonwalker induces a large amount of noise on /OE Nice work. Is it possible for you to repeat that test without UMDK? With Moonwalker on a dumb flash-cart, maybe? The MDII is clean as a whistle So does that MD2 exhibit any problems with your UMDK cart? Did you use the...

So if we take the common example of Sonic 1, as soon as the game starts you get to hear the wonderful "SEGAAA" sound clip, after which the game crashes (Illegal instruction $00071FC6 in this case). This is a known issue that several people have identified[1][2][3]. The crash is in the "@busyloop" o...

I dare say that now someone else has done the work he will be selling Bridge PCBs. this man does things only for profit. I'm not sure that's true, but even if that were the case, it would be perfectly fine[1]. We all have different motivations. Please, let's not reopen old disagreements. These argu...

I would try de-soldering the 22pF caps on the oscillator circuit and replacing them.