Page 1 of 2
Documenting signal names
Posted: Fri Mar 27, 2009 11:03 pm
by notaz
I've started some small hardware project, so collected some info here:
http://wiki.megadrive.org/index.php/Hardware_Interfaces
(chose this instead of Aamir's wiki because of cooler domain name)
I would like to see this completed, if you know more info, please add
Posted: Mon Mar 30, 2009 9:23 am
by ElBarto
Hello,
I've just moved your page to
http://wiki.megadrive.org/index.php/Hardware:Interfaces.
Don't hesitate to create new categories or organize the wiki in a better way.
Thanks for contributing (and yeah the domain name is cool
).
Posted: Mon Mar 30, 2009 9:28 am
by Eke
good idea
maybe it would be worth mentionning signal directions (IN/OUT) as well as the chip(s) driving the signal
for example, /LWR and /UWR are VDP outputs which are set depending on the /RW, /UDS and /LDS/ input signals
...
/FRES probably manages the expansion port reset mechanism (sega-CD softreset ?)
Posted: Mon Mar 30, 2009 9:29 am
by notaz
Would be nice if you allowed image uploads or external image embedding ($wgAllowExternalImages).
Posted: Mon Mar 30, 2009 9:39 am
by ElBarto
notaz wrote:Would be nice if you allowed image uploads or external image embedding ($wgAllowExternalImages).
Should be good now.
Posted: Mon Mar 30, 2009 10:58 am
by HardWareMan
Eke wrote:/FRES probably manages the expansion port reset mechanism (sega-CD softreset ?)
FRES is positive signal. It seems it is just inversion of /MRES.
Posted: Fri Apr 03, 2009 7:51 am
by Eke
so about FRES, I guess it is used to reset some stuff on the expansion side: it is only connected to the I/O chip, which also receive /SRES (same as /MRES but used for internal chip ?) So it could be asserted by the I/O chip when a system reset occurs (like any other reet signals) but maybe also when the main CPU want to reset Sega-CD sub CPU trough $A12000 register , which would be the reason why they did not simply connect the MRES signal to the expansion port.
about /DISK, I noticed that, like FRES, it is only connected to the I/O chip: however, as we know, IO register #0 return a flag that indicates if Sega-CD unit is attached or not, it might be that signal is asserted in such case (like the /CART equivalent for expansion port) ?
pure speculations, as always
Posted: Fri Apr 03, 2009 9:40 am
by TmEE co.(TM)
the !DISK signal seems to do nothing but show its grounded or not... you can freely mess with it with no consequences in cart operation, so I guess it will not mess with addressing at all.
Posted: Fri Apr 03, 2009 10:00 am
by Eke
anyone tried to force its level and look if $A10001 bit4 state changes ?
Posted: Fri Apr 03, 2009 10:25 am
by TmEE co.(TM)
it does change, if the reg is what you use to read region from
Posted: Thu Apr 09, 2009 8:03 pm
by notaz
Eke wrote:anyone tried to force its level and look if $A10001 bit4 state changes ?
Just tried it, it's bit5 really and it works
, wiki updated.
Anyone knows what /CAS2 and /RAS2 do? Are they DRAM signals?
Posted: Thu Apr 09, 2009 11:58 pm
by Jorge Nuno
notaz wrote:Anyone knows what /CAS2 and /RAS2 do? Are they DRAM signals?
/CAS2 seems to be used in conjunction with /ASEL and /ROM (or /CE0) :
/ROM or /CE0 acting as a row address strobe, /ASEL toggling the rows/columns multiplexer, and /CAS2 as the column address strobe. Notice that they are asserted in the same address range, but their assertion order is always preserved. That's how sega devs connected their DRAM carts to the MD cart port or exp port.
Remember that DRAM usually has a muxed address bus (/ASEL:
Address
Select)
/CAS0 seems to be used like an early-read cycle, used to enable the memory output buffer.
I have no idea about /RAS2
There must be some refresh cycles in between acesses... (not sure how)
Posted: Fri Apr 10, 2009 3:26 am
by HardWareMan
CAS0 asserted in AS (M68K's address strobe) window. But CAS2 asserted much later and it shorter. I don't know why they done this, I think it is for slow DRAM. But, there some of cartriges, wich used 8 bit ROMs, data latch and they CSed by CE0 only. Latch takes input from D0-D7 and set output for D8-D15. CE0 long too (in AS window), so ROM set some data at D0-D7 and Latch take it. Then CAS2 comes and one ROMs address line and Latch LE control input changed and data at D8-D15 stand still, but D0-D7 will changed. From this moment we have requested data word from ROM. Any questions?
Like this:
Code: Select all
AS --_____________--
CAS0 --_____________--
CAS2 -------________--
PS Can anyone take a shot of this signals by oscilloscope? AS, CAS0, CAS2 and LWR/UWR?
Posted: Fri Apr 10, 2009 7:45 am
by Eke
I've tried to setup a complete description for all the signals that can be found in the Model 1 schematics, mostly for me to understand how the address decoding/bus arbitration is done internally
Feel free to point any mistakes or inaccuracies, these are probably well known stuff for the most of you but might be useful for less-hardware people like me
http://genplus-gx.googlecode.com/files/gen_signals.doc
Posted: Fri Apr 10, 2009 11:01 am
by HardWareMan
Eke wrote:I've tried to setup a complete description for all the signals that can be found in the Model 1 schematics, mostly for me to understand how the address decoding/bus arbitration is done internally
Nice. But I would like to see those signals at oscilloscope screen. Not all, but some of important. With timing position to each other.