Bus Arbiter and IO Chip Access
Moderator: BigEvilCorporation
Bus Arbiter and IO Chip Access
I am working on an emulator and striving for cycle accuracy. (Aren't we all?) I am attempting to emulate the 513-5433 Arbiter/IO chip. I was wondering if anyone knew of any document or documents that described the behaviors in enough detail to write an emulator for all the involved signals from VDP access/ 68k to z80/ z80 to 68k and SMS mode and if there is any other uses I am forgetting. Thanks for the help!!
Re: Bus Arbiter and IO Chip Access
Did some probing on my model 1 va2. It has a 5308 arbiter, a 5309 IO chip and a 5345. I checked the pinouts on MegaDrive.org and found some inaccuracies. Correct pinout is as follows:
1. /BGACK (connected to BGACK on VDP, 68k and arbiter)
2. /HSYNC
3. /SRES
4. A14
5. /M3
6. /OE0
7. MCLK
8. GND
9. EDCLK
10. /EOE
11. IA14
12. /NOE
13. /CAS0
14. SCBR
15. /ZWAIT
16. VCC
The behavior of IA14 is as expected depending on /M3. EDCLK is the 13.x MHZ normally and drops to 10.x during the first couple pixels (maybe 30 or so didn’t count) of /HSYNC. SBCR is 7.6mhz. I know NOE and EOE are the output enables for the System RAM. CAS0 and OE0 seem to only go to vdp. So I’m stumped as to the relations of all the OEs and CAS, bgack and zwait as well as sres.
1. /BGACK (connected to BGACK on VDP, 68k and arbiter)
2. /HSYNC
3. /SRES
4. A14
5. /M3
6. /OE0
7. MCLK
8. GND
9. EDCLK
10. /EOE
11. IA14
12. /NOE
13. /CAS0
14. SCBR
15. /ZWAIT
16. VCC
The behavior of IA14 is as expected depending on /M3. EDCLK is the 13.x MHZ normally and drops to 10.x during the first couple pixels (maybe 30 or so didn’t count) of /HSYNC. SBCR is 7.6mhz. I know NOE and EOE are the output enables for the System RAM. CAS0 and OE0 seem to only go to vdp. So I’m stumped as to the relations of all the OEs and CAS, bgack and zwait as well as sres.
-
- Very interested
- Posts: 616
- Joined: Thu Nov 30, 2006 6:30 am
Re: Bus Arbiter and IO Chip Access
For what it's worth, we have the schematics for the VA3. Main difference from your VA2 is that the 5345 (EDCLK generator, probably just a PAL or GAL) has been integrated into the bus arbiter (5308) and given the part number 5364. That said, having a full and correct pinout for the 5345 is nice so thanks for that.
Yeah, EDCLK is the external pixel clock used by the proper H40 mode that is mostly MCLK/4, but switches to MCLK/5 periodically in HSYNC so that lines are still 3420 MCLKs. The VDP also has an internal H40 divider, but it's always MCLK/4 so the video signal produced is more out of spec than normal.
The bus arbiter itself (5308) needs !BGACK and !ZWAIT for Z80 access to the 68K bus. When the Z80 accesses the 68K bank area (or the fixed VDP bank used for poking the PSG), the arbiter requests the 68K bus and asserts !ZWAIT until the 68K grants the bus with !BG at which point it will release !ZWAIT and assert !BGACK. I'm not sure why the 5345 needs these signals, but I would guess it has something to do with SMS/Mark III mode since the 5345 also handles some RAM related things for that mode. Presumably, SMS mode bus requests the 68K on startup, so maybe the 5345 handles asserting !ZWAIT on startup until the arbiter acknowledges the bus grant.
!SRES is the hard reset signal which is normally controlled via the power-on reset circuit, but can also be triggered via the !MRES cart pin.
!CAS0 and !OE0 are generated by the VDP and are listed as "Work RAM strobe control" in the service manual. The VDP has an unused feature that allows normal DRAM to be used as work RAM instead of the Pseudo-SRAM that is actually used in shipping consoles. In that case, !CAS0 would be the DRAM column address strobe, and !OE0 would be the output enable. Presumably, the 5345 uses !OE0 to generate !NOE and !EOE, asserting both in normal mode and only one of them when !M3 is asserted. Not sure what it does with !CAS0 though. It's asserted for all accesses, not just for work RAM (it's typically used as the output enable signal for cartridges for instance).
Re: Bus Arbiter and IO Chip Access
So I decided to pull the 5345 chip and wire it up outside the system for testing. Here are the findings thus far although a bit perplexing in places.
EDCLK: This signal is 0/floating (wasnt a very clean 0) when /SRES, /M3 or /HSYNC are asserted(0). Otherwise it seems to be MCLK/4. (I tested with a 5k signal. Got a 1.25K out. I thought this this should /5, maybe it doesn't like the slow speed?) Does not seem to be affected by anything else.
IA14: Forced to 1 when /M3 is asserted. It seems be A14 inverted (Although I saw somewhere that this was A13, maybe I didn't trace it right). Not affected by any other signal.
/NOE is forced to 0 when /M3 is asserted. Otherwise both /NOE and /EOE follow /OE0. Not affected by any other signal.
So far, /HSYNC, /SRES, /M3, A14?, /OE0 and MCLK are inputs and EDCLK, /EOE, IA14, /NOE are outputs.
Looking at that, it would seem like inputs are on one side and outputs on the other. However, from just looking at the scope output on /BGACK, /ZWAIT and /CAS0, it seems that /BGACK is an output as its driven to 1 and both /ZWAIT and /CAS0 are floating around 0 but not being driven. So I tried driving all of them checking the outputs on them and nothing seemed to change. Maybe I needed to hook up a faster clock? No affect from /OE0, /M3 or /SRES om any combination. I wasn't able to get anything out of SCBR, again maybe I needed a faster clock. I will retest those 4 signals as well as the EDCLK tomorrow at work with a function generator and then put the chip back in the system.
EDCLK: This signal is 0/floating (wasnt a very clean 0) when /SRES, /M3 or /HSYNC are asserted(0). Otherwise it seems to be MCLK/4. (I tested with a 5k signal. Got a 1.25K out. I thought this this should /5, maybe it doesn't like the slow speed?) Does not seem to be affected by anything else.
IA14: Forced to 1 when /M3 is asserted. It seems be A14 inverted (Although I saw somewhere that this was A13, maybe I didn't trace it right). Not affected by any other signal.
/NOE is forced to 0 when /M3 is asserted. Otherwise both /NOE and /EOE follow /OE0. Not affected by any other signal.
So far, /HSYNC, /SRES, /M3, A14?, /OE0 and MCLK are inputs and EDCLK, /EOE, IA14, /NOE are outputs.
Looking at that, it would seem like inputs are on one side and outputs on the other. However, from just looking at the scope output on /BGACK, /ZWAIT and /CAS0, it seems that /BGACK is an output as its driven to 1 and both /ZWAIT and /CAS0 are floating around 0 but not being driven. So I tried driving all of them checking the outputs on them and nothing seemed to change. Maybe I needed to hook up a faster clock? No affect from /OE0, /M3 or /SRES om any combination. I wasn't able to get anything out of SCBR, again maybe I needed a faster clock. I will retest those 4 signals as well as the EDCLK tomorrow at work with a function generator and then put the chip back in the system.
-
- Very interested
- Posts: 2440
- Joined: Tue Dec 05, 2006 1:37 pm
- Location: Estonia, Rapla City
- Contact:
Re: Bus Arbiter and IO Chip Access
EDCLK is open drain, you need a pullup on it.
EDIT: It isn't, but HSYNC is and it is used for EDCLK generation by the Bus chip and it caused me trouble. More details in next post by me.
EDIT: It isn't, but HSYNC is and it is used for EDCLK generation by the Bus chip and it caused me trouble. More details in next post by me.
Last edited by TmEE co.(TM) on Thu Oct 11, 2018 9:24 am, edited 1 time in total.
Mida sa loed ? Nagunii aru ei saa
http://www.tmeeco.eu
Files of all broken links and images of mine are found here : http://www.tmeeco.eu/FileDen
http://www.tmeeco.eu
Files of all broken links and images of mine are found here : http://www.tmeeco.eu/FileDen
-
- Very interested
- Posts: 616
- Joined: Thu Nov 30, 2006 6:30 am
Re: Bus Arbiter and IO Chip Access
It should be MCLK/4 when !HSYNC is not asserted, but it should alternate between MCLK/4 and MCLK/5 (I forget the exact pattern, might be something like 3 clocks of /5 and then 1 of /4 or something like that) when !HSYNC is asserted. Weird that you're not seeing any clock output when !HSYNC is asserted.Enforcer wrote: ↑Thu Oct 11, 2018 5:22 amEDCLK: This signal is 0/floating (wasnt a very clean 0) when /SRES, /M3 or /HSYNC are asserted(0). Otherwise it seems to be MCLK/4. (I tested with a 5k signal. Got a 1.25K out. I thought this this should /5, maybe it doesn't like the slow speed?) Does not seem to be affected by anything else.
It's A14 from the perspective of the 68K and A13 from the perspective of the individual RAM chip (or the Z80 in SMS/MarkIII mode). The signals are called IA14/A14 in the official schematics though.
That's pretty typical for PAL/GAL parts. This chip has fewer pins than a typical PAL/GAL though as those are usually 20 or 24 pins, so maybe I'm wrong about it being one of those.
That's surprising. Maybe it's some kind of bodge for the !BGACK generation in the 5308 arbiter?
SCBR is generated by the VDP so it's probably an input. Interestingly, this signal isn't connected to the 5364 chip in the VA3 at all. It just goes straight from the VDP to the color encoder.
Actually, are you sure this is actually SBCR (connected to VDP pin 50) and not VCLK (connected to VDP pin 49). 7.6MHz makes much more sense if it's the latter and VCLK is connected to the 5364 in the VA3.
That does not appear to be the case from the VDP die shot. It has the same structure as a fully driven I/O pin. Open drain pins like !CSYNC have a different structure.
EDIT: Or do you just have reason to believe it's an open drain output on the 5345 even though it's not an open drain pin on the VDP?
Re: Bus Arbiter and IO Chip Access
Yes, this is my guess as well. Also having SBCR at anything different from PAL/NTSC clocks would break video output anyway.SCBR is generated by the VDP so it's probably an input. Interestingly, this signal isn't connected to the 5364 chip in the VA3 at all. It just goes straight from the VDP to the color encoder.
Actually, are you sure this is actually SBCR (connected to VDP pin 50) and not VCLK (connected to VDP pin 49). 7.6MHz makes much more sense if it's the latter and VCLK is connected to the 5364 in the VA3.
VCLK is probably an input clock to this chip and is used to drive output signals and internal counters.
It could be that VCLK input is needed for driving EDCLK generation (which is divided from MCLK), which would explain that EDCLK is MCLK/4 for some cycles then MCLK/5, etc... while /HSYNC is low.It should be MCLK/4 when !HSYNC is not asserted, but it should alternate between MCLK/4 and MCLK/5 (I forget the exact pattern, might be something like 3 clocks of /5 and then 1 of /4 or something like that) when !HSYNC is asserted. Weird that you're not seeing any clock output when !HSYNC is asserted.
It would be interesting to verify is there are any differences regarding EDCLK between MD VA1 and late rmodels since it seems VA1 (and likely VA0) is using an earlier version of 315-5345 chip (see 315-5339 description here: http://www.tmeeco.eu/SMD/MD1VA1_315-5339.jpg) which does not use VCLK (and neither/SRES, /RAS0, /ZWAIT and /BGACK, which could indicate they are all parts of the same added function)
Yes, this is signal was added to force RAM mirroring in MS compatibility mode like with a real Master System. This is required for game compatibility I guess. In MS compatibility mode (/M3 asserted low on cartridge port) , ZA0-ZA15 are connected to VA1-VA16 and RAM chip is accessed (/RAS0 and eventually /OE0 asserted by VDP) when VA16=VA15=1 (since it corresponds to ZA15=ZA14=1) but since VA14 is also connected to RAM chip and can be driven by Z80 (it corresponds to ZA13 and master system games set the stack to $DFF0 generally), it must be forced high to ensure Z80 accesses to $C000-$DFFF mirror accesses to $E000-$FFFF.It's A14 from the perspective of the 68K and A13 from the perspective of the individual RAM chip (or the Z80 in SMS/MarkIII mode). The signals are called IA14/A14 in the official schematics though.
My guess would be that in original Mega Drive design, /OE0 was directly connected from VDP to both RAM chips /OE pins but this caused some issue when accessing RAM in MS compatibility mode because VD8-VD15 were driven by the unused RAM chip (maybe some of those signals are used for other purpose in MS compatibility mode, just like VA23 is used to trigger Z80 /NMI), so they added a circuit to generate RAM chips /OE separately./NOE is forced to 0 when /M3 is asserted. Otherwise both /NOE and /EOE follow /OE0. Not affected by any other signal.
Probably you will have different results if you connect VCLK input to a proper clock.However, from just looking at the scope output on /BGACK, /ZWAIT and /CAS0, it seems that /BGACK is an output as its driven to 1 and both /ZWAIT and /CAS0 are floating around 0 but not being driven.
/BGACK can not be an output only since it's driven by the VDP when doing DMA, it's more likely pulled high internally to handle cases where it is floating (when neither Z80 or VDP are masters of 68k bus) as it is used by internal logic.
My guess would be that this signal is used to handle extra RAM refresh to fix some issues discovered after the design of original chips.
We know RAM refresh is handled by VDP (by asserting /OE0 without /RAS0 every xxx VCLK cycles) but it's possible RAM is not refreshed by VDP when /BGACK is low (which would mean someone else is master of the bus) so they needed to add a refresh logic for when /BGACK is low. It could explain also why RAM refresh appears to be twice faster when DMA is executing (there is some post on the forum about this).
As for /CAS0, I'm not sure. In MS compatibility mode, it is connected by PBC to Master System /RD pin and I would have think it's still driven by VDP in MS compatibility mode. Probably it is used to do RAM refresh only when RAM is not accessed as it"s an address strobe for any access (read only or read/write, I'm not sure as I have seen conflicting infos before) outside RAM (/RAS0 and /CAS0 are exclusive).
Otherwise (if not driven by VDP when /M3 is low), it could be generated by this chip and was added to fix compatibility issues with MS cartridge that use the /RD pin.
/ZWAIT is most likely an output and might be needed to delay Z80 RAM access using VCLK input as counter ?
Last edited by Eke on Thu Oct 11, 2018 9:58 am, edited 6 times in total.
-
- Very interested
- Posts: 2440
- Joined: Tue Dec 05, 2006 1:37 pm
- Location: Estonia, Rapla City
- Contact:
Re: Bus Arbiter and IO Chip Access
EDCLK is an input to the VDP. And now I actually remembered that it is the HSYNC that was the problem. Because of the open drain factor I had problems with my first set of measurements as probe capacitance caused my measurements to be off by several pixels due to rise of the signal getting altered. There's still some analog factors going on as the rise is very slow and due to it there's some uncertanity when HSYNC ends and that has direct consequences on how the EDCLK output looks.
Code: Select all
MD video timings ------------------------------------------------------------
MCLK is 53203424 Hz in PAL machines and 53693175 Hz in NTSC machines and all
timings are based on those frequencies. There are two pixel clock frequencies
used in MD : MCLK / 10 (slow pixels) and MCLK / 8 (fast pixels). The VDP can
generate these internally but can also use external pixel clock (EDCLK) which
uses fast pixel timing outside HSYNC and pattern of 1 fast, 7 slow, 2 medium,
7 slow during HSYNC. Medium pixels last 9 x MCLK cycles. Because HSYNC is an
open drain signal it has soft rising edge and it causes some uncertanity
regarding end of HSYNC which has implications on EDCLK that is used in H320.
HSYNC in H320 could be 33 pixels, with blanking having 31 pixels but in that
case one of the blanking pixels will be slow, and that will complicate the
matters a little bit, I have assumed here that blanking is only fast pixels.
Video timings are dependent on if EDCLK is used also.
Mida sa loed ? Nagunii aru ei saa
http://www.tmeeco.eu
Files of all broken links and images of mine are found here : http://www.tmeeco.eu/FileDen
http://www.tmeeco.eu
Files of all broken links and images of mine are found here : http://www.tmeeco.eu/FileDen
Re: Bus Arbiter and IO Chip Access
I did a quick check and what I have listed as SBCR is actually VCLK. Funny that the other pinouts I’ve seen online have it as SBCR as well. Guess the majority isn’t always right. LOL. I have a signal generator hereat work and will test with some clocks on MCLK and VCLK and see what behaviors we get once I finish with my tasks for today.
-
- Very interested
- Posts: 616
- Joined: Thu Nov 30, 2006 6:30 am
Re: Bus Arbiter and IO Chip Access
VA0 has neither a 315-5339 nor a 315-5345, but instead has an EDCLK generator made out of 74-series logic on a daughter board. There's also at least one 74-series chip on the main PCB between the work RAM chips (presumably for the A14/OE fixes for SMS/MarkIII mode).Eke wrote: ↑Thu Oct 11, 2018 9:15 amIt would be interesting to verify is there are any differences regarding EDCLK between MD VA1 and late rmodels since it seems VA1 (and likely VA0) is using an earlier version of 315-5345 chip (see 315-5339 description here: http://www.tmeeco.eu/SMD/MD1VA1_315-5339.jpg) which does not use VCLK (and neither/SRES, /RAS0, /ZWAIT and /BGACK, which could indicate they are all parts of the same added function)
Based on both the service manual and the physical structure of the pin on the die, it's both an input and an output, though it's only ever used as an input on the MD. I think the original intent of this pin was to allow two VDPs to share a pixel clock, I guess for better synchronization than just genlocking off the sync signals provides. So you'd set it to be an output on the primary VDP (unclear what register bit does this) and an input on the secondary VDP. But then they decided that the signal provided with the internal H40 clock was too out of spec, so they added an external H40 clock generator on a bodge board at the last minute.
Re: Bus Arbiter and IO Chip Access
Thanks for this. After setting that one up I was able to see the pattern. I didn’t have enough resolution for discern the exact pattern on my normal scope, so I pulled out my 500MHz 5GS/s one to take a look. The pattern seems to be 15 long followed by 2 short. In my setup I can drive hsync as long as I want so I acquired a long time and looked for patterns. It is not affected by SMS mode. Interestingly, The time the pulse is high is always the same. It only adjusts the low time. Will work on the other signals tomorrow after work since I borrowed the signal generator.TmEE co.(TM) wrote: ↑Thu Oct 11, 2018 9:18 am... I actually remembered that it is the HSYNC that was the problem.
-
- Very interested
- Posts: 745
- Joined: Sat Dec 15, 2007 7:49 am
- Location: Kazakhstan, Pavlodar
Re: Bus Arbiter and IO Chip Access
Feel free to share some pictures.
Re: Bus Arbiter and IO Chip Access
I took some before I left for work this morning.
Normal EDCLK No HSYNC Start of HSYNC Fast Pixel
Last edited by Enforcer on Fri Oct 12, 2018 4:16 pm, edited 2 times in total.
Re: Bus Arbiter and IO Chip Access
High Time for Slow Pixel
I have some more if you'd like them. Mostly just measuring the widths to make sure they are the same. That pattern of 15-2 repeats as long as HSYNC is asserted.
15 Slow Pixels
2 Fast Pixels
I have some more if you'd like them. Mostly just measuring the widths to make sure they are the same. That pattern of 15-2 repeats as long as HSYNC is asserted.
Re: Bus Arbiter and IO Chip Access
Just an FYI, I was using a 536.93 kHz clock for MCLK. Running at 5mhz was radiating too much for me to get clean signals and the function generator didn’t go up past 30mhz anyway.