Bus Arbiter and IO Chip Access

Ask anything your want about Megadrive/Genesis programming.

Moderator: BigEvilCorporation

Enforcer
Interested
Posts: 17
Joined: Thu May 31, 2018 3:49 am

Bus Arbiter and IO Chip Access

Post by Enforcer » Tue Oct 09, 2018 5:17 am

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!!

Enforcer
Interested
Posts: 17
Joined: Thu May 31, 2018 3:49 am

Re: Bus Arbiter and IO Chip Access

Post by Enforcer » Wed Oct 10, 2018 4:04 am

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.

Mask of Destiny
Very interested
Posts: 572
Joined: Thu Nov 30, 2006 6:30 am

Re: Bus Arbiter and IO Chip Access

Post by Mask of Destiny » Wed Oct 10, 2018 6:42 pm

Enforcer wrote:
Wed Oct 10, 2018 4:04 am
Did some probing on my model 1 va2. It has a 5308 arbiter, a 5309 IO chip and a 5345.
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.
Enforcer wrote:
Wed Oct 10, 2018 4:04 am
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.
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.
Enforcer wrote:
Wed Oct 10, 2018 4:04 am
So I’m stumped as to the relations of all the OEs and CAS, bgack and zwait as well as sres.
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).

Enforcer
Interested
Posts: 17
Joined: Thu May 31, 2018 3:49 am

Re: Bus Arbiter and IO Chip Access

Post by Enforcer » Thu Oct 11, 2018 5:22 am

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.

User avatar
TmEE co.(TM)
Very interested
Posts: 2317
Joined: Tue Dec 05, 2006 1:37 pm
Location: Estonia, Rapla City
Contact:

Re: Bus Arbiter and IO Chip Access

Post by TmEE co.(TM) » Thu Oct 11, 2018 6:55 am

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.
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

Mask of Destiny
Very interested
Posts: 572
Joined: Thu Nov 30, 2006 6:30 am

Re: Bus Arbiter and IO Chip Access

Post by Mask of Destiny » Thu Oct 11, 2018 7:18 am

Enforcer wrote:
Thu Oct 11, 2018 5:22 am
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.
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 am
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).
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.
Enforcer wrote:
Thu Oct 11, 2018 5:22 am
Looking at that, it would seem like inputs are on one side and outputs on the other.
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.
Enforcer wrote:
Thu Oct 11, 2018 5:22 am
/BGACK is an output as its driven to 1
That's surprising. Maybe it's some kind of bodge for the !BGACK generation in the 5308 arbiter?
Enforcer wrote:
Thu Oct 11, 2018 5:22 am
I wasn't able to get anything out of SCBR, again maybe I needed a faster clock.
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.
TmEE co.(TM) wrote:
Thu Oct 11, 2018 6:55 am
EDCLK is open drain, you need a pullup on it.
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?

Eke
Very interested
Posts: 824
Joined: Wed Feb 28, 2007 2:57 pm
Contact:

Re: Bus Arbiter and IO Chip Access

Post by Eke » Thu Oct 11, 2018 9:15 am

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.
Yes, this is my guess as well. Also having SBCR at anything different from PAL/NTSC clocks would break video output anyway.

VCLK is probably an input clock to this chip and is used to drive output signals and internal counters.
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 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 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)
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.
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.
/NOE is forced to 0 when /M3 is asserted. Otherwise both /NOE and /EOE follow /OE0. Not affected by any other signal.
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.
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.
Probably you will have different results if you connect VCLK input to a proper clock.
/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.

User avatar
TmEE co.(TM)
Very interested
Posts: 2317
Joined: Tue Dec 05, 2006 1:37 pm
Location: Estonia, Rapla City
Contact:

Re: Bus Arbiter and IO Chip Access

Post by TmEE co.(TM) » Thu Oct 11, 2018 9:18 am

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

Enforcer
Interested
Posts: 17
Joined: Thu May 31, 2018 3:49 am

Re: Bus Arbiter and IO Chip Access

Post by Enforcer » Thu Oct 11, 2018 4:45 pm

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.

Mask of Destiny
Very interested
Posts: 572
Joined: Thu Nov 30, 2006 6:30 am

Re: Bus Arbiter and IO Chip Access

Post by Mask of Destiny » Thu Oct 11, 2018 7:12 pm

Eke wrote:
Thu Oct 11, 2018 9:15 am
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)
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).
TmEE co.(TM) wrote:
Thu Oct 11, 2018 9:18 am
EDCLK is an input to the VDP.
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.

Enforcer
Interested
Posts: 17
Joined: Thu May 31, 2018 3:49 am

Re: Bus Arbiter and IO Chip Access

Post by Enforcer » Fri Oct 12, 2018 5:51 am

TmEE co.(TM) wrote:
Thu Oct 11, 2018 9:18 am
... I actually remembered that it is the HSYNC that was the problem.
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.

User avatar
HardWareMan
Very interested
Posts: 712
Joined: Sat Dec 15, 2007 7:49 am
Location: Kazakhstan, Pavlodar

Re: Bus Arbiter and IO Chip Access

Post by HardWareMan » Fri Oct 12, 2018 8:01 am

Feel free to share some pictures.

Enforcer
Interested
Posts: 17
Joined: Thu May 31, 2018 3:49 am

Re: Bus Arbiter and IO Chip Access

Post by Enforcer » Fri Oct 12, 2018 4:11 pm

HardWareMan wrote:
Fri Oct 12, 2018 8:01 am
Feel free to share some pictures.
I took some before I left for work this morning.

Normal EDCLK No HSYNC
HSYNC Deasserted.png
HSYNC Deasserted.png (26.93 KiB) Viewed 155 times
Start of HSYNC
HSYNC Asserted.png
HSYNC Asserted.png (34 KiB) Viewed 155 times
Fast Pixel
Fast Pixel HSYNC Asserted.png
Fast Pixel HSYNC Asserted.png (36.98 KiB) Viewed 155 times
Last edited by Enforcer on Fri Oct 12, 2018 4:16 pm, edited 2 times in total.

Enforcer
Interested
Posts: 17
Joined: Thu May 31, 2018 3:49 am

Re: Bus Arbiter and IO Chip Access

Post by Enforcer » Fri Oct 12, 2018 4:14 pm

High Time for Slow Pixel
High Time Slow Pixel.png
High Time Slow Pixel.png (36.54 KiB) Viewed 155 times
15 Slow Pixels
15 Slow Pixels.png
15 Slow Pixels.png (39.02 KiB) Viewed 155 times
2 Fast Pixels
2 Fast Pixels.png
2 Fast Pixels.png (38.98 KiB) Viewed 155 times

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.

Enforcer
Interested
Posts: 17
Joined: Thu May 31, 2018 3:49 am

Re: Bus Arbiter and IO Chip Access

Post by Enforcer » Fri Oct 12, 2018 6:41 pm

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.

Post Reply

Who is online

Users browsing this forum: No registered users and 4 guests