Page 8 of 11

Posted: Sun Mar 15, 2009 12:17 pm
by Eke
... or connect the 68k reset line to the VDP Reset input
this way, pressing the softreset will simultaneously reset your program and the VDP :wink:

don't know why but I feel i'm missing some HW restrictions :roll:

Posted: Sun Mar 15, 2009 12:23 pm
by Jorge Nuno
You mean just place Move.w (a7), d0 as the first instruction (0: 0x00C00008 and 4: 0x00000200) ?, there are a bunch of latencies involved, like reading location 0; 2; 4; 6; and $200, and executing it.

Posted: Sun Mar 15, 2009 12:25 pm
by TmEE co.(TM)
bypassing TMSS in a MD with TMSS is pretty simple, I even made an auto-switching mod that does not break compatibility with PBC and MCD :3
http://www.fileden.com/files/2008/4/21/ ... MSSMOD.jpg
(there's a small fault on the left side of the schematic regarding the enable/disable switch, but it does not cause any issues).

Posted: Sun Mar 15, 2009 12:39 pm
by Jorge Nuno
You have a NAND with an input at 0 level in the middle, that gives an «always 1» And there is 1 (at least) redundant port... Man I never saw a difficult-following schematic to do a simple thing :lol:

Posted: Sun Mar 15, 2009 12:43 pm
by TmEE co.(TM)
It took me whole night to get this worked out, and it works in all conditions so far in my MD2 and causes no headache... I hope I have not made any mistake when writing out the schematic :P
checked out everything, no, its not faulty.

Posted: Sun Mar 15, 2009 12:45 pm
by HardWareMan
TmEE co.(TM) wrote:bypassing TMSS in a MD with TMSS is pretty simple, I even made an auto-switching mod that does not break compatibility with PBC and MCD :3
TMSS is not only thing, that you have to deal. There is security register that need to be initialized (somewhere here was said, that this register placed in VDP and block M68K when it try to access to VDP and do not unlock the system before that).
So question is: allow VDP acces to it H/V counters or not before unlock the system. If it allow, then all simple: add one move.w command to read H/V counter and store to RAM for print later and proceed with unlock the system. If it don't - there no way out, than do read H/V counter after unlock system code.

Posted: Sun Mar 15, 2009 12:51 pm
by mickagame
Eke wrote: Here's what I got if I consider HBLANK flag and HINT occurs at the same moment in H40 mode as well:

Image
I try with this timings on my emulator and mickey mania doesn't work.

Posted: Sun Mar 15, 2009 12:59 pm
by TmEE co.(TM)
HardWareMan wrote:TMSS is not only thing, that you have to deal. There is security register that need to be initialized (somewhere here was said, that this register placed in VDP and block M68K when it try to access to VDP and do not unlock the system before that).
So question is: allow VDP acces to it H/V counters or not before unlock the system. If it allow, then all simple: add one move.w command to read H/V counter and store to RAM for print later and proceed with unlock the system. If it don't - there no way out, than do read H/V counter after unlock system code.
You're right, this can cause trouble.... best deal you can do is have a MD1 without TMSS, then overclock the 68K (12MHz is max stable clock on no TMSS MD1s but more is possible) so all delays would become shorter and so you can read off less changed values off VDP. You could possibly calculate default HV counter value using values you get from unoverclocked and overclocked system, and for more fun, underclocked system too :P

Posted: Sun Mar 15, 2009 1:12 pm
by Jorge Nuno
If the 68K is overclocked you can't predict the memory access delays, becuase AS is strobed using the default clock and DTACK is driven low with the default clock too. Any other clock you supply to it, the 68K will be out of phase with the events of the bus-decoder, and could potentially lead to invalid values.

Posted: Sun Mar 15, 2009 1:17 pm
by TmEE co.(TM)
You can of course mess with the master clock too, but then you cannot rely on video output of the unit unless you have some super monitor :P
Actually, just giving VDP lower clock will do, though I have no idea how low the clock must be before it starts affecting the rest of the system in not so good manner..... experimentation is needed :)

Posted: Sun Mar 15, 2009 1:28 pm
by Jorge Nuno
Which clock will you manually give to the VDP? EDclk? or M? or both :D ?
Remeber that VRAM dies if you supply a clock too low, around /3, most likely. The video signals are not so important if you hook a logic analyser on VD bus and trigger it on DTACK \__

With some luck the VDP works without VRAM, or VRAM acting like $hit...


It seems that hard-wire the VA bus to C00008 starts to be a viable option..

Posted: Sun Mar 15, 2009 1:34 pm
by TmEE co.(TM)
If you want to get info on HV counter only, then VRAM is not really important...

When I last experimented with MD clocks, I did lot of fun things like making the VDP run on mormal clock, but the rest of the system on 40MHz clock or lower, so fun :P
I need to dig out my oscillators and have more fun :)

Too bad I have absolutely no equipment to measure anything...

Posted: Sun Mar 15, 2009 1:41 pm
by Jorge Nuno
If you are in university, maybe you have the chance to use this kind of equipment in some occasions, I'm like you too, I only have a cheap multimeter + soldering iron (it has a tip like a screwdriver :x ) at home :lol: :oops: I can only burn/erase my eprom there, too.

Posted: Sun Mar 15, 2009 1:44 pm
by TmEE co.(TM)
the school I attend is not having any such equipment, and such stuff is not taught there.... I would have gladly started learning electronics engineering but my math was just toooooooo poor :/
I am thinking of building an oscilloscope out of a TV sometime though :)

Posted: Sun Mar 15, 2009 1:51 pm
by Jorge Nuno
Wow that's just insane :shock: ... You are not thinking using a megadrive + cart with some ADCs to do that are you? :D


Damn offtopic