Bus Arbiter and IO Chip Access

Ask anything your want about Megadrive/Genesis programming.

Moderator: BigEvilCorporation

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

Re: Bus Arbiter and IO Chip Access

Post by HardWareMan » Sun Oct 14, 2018 1:37 pm

So, you slow down the system by underclock the MCLK to make more clear capture?

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

Re: Bus Arbiter and IO Chip Access

Post by Enforcer » Sun Oct 14, 2018 2:59 pm

Actually, I've pulled out the chip entirely and put it on a bread board so I can control everything by hand. But to your point, yes, I’ve slowed MCLK way down to make capturing easier.
Last edited by Enforcer on Mon Oct 15, 2018 4:46 am, edited 1 time in total.

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

Re: Bus Arbiter and IO Chip Access

Post by Enforcer » Mon Oct 15, 2018 4:46 am

After a bunch of trial and error, and going through every single input in a binary fashion, I think I have a description of how the 315-5345 works.

315-5345 Behaviors
EDCLK (9), !EOE (10), IA14 (11) and !NOE(12) are outputs.
!BGACK (1), !HSYNC (2), !SRES (3), A14 (4), !M3 (5), !OE0 (6) , MCLK (7) , !CAS0 (13), VCLK(14), !ZWAIT(15) are inputs.

VCLK is needed even though it doesn't seem like it at first. Theory on this after signal descriptions.

IA14 Behavior
1 when !M3 = 0, otherwise ~A14.

EDCLK Behavior:
0 when !SRES = 0,
MCLK/4 when !HSYNC = 1 otherwise
15 MCLK/4 followed by 2 MCLK/4 repeated.

!EOE and !NOE Behavior:
This behavior is a little more involved.
!EOE = 1 when !M3 = 0, otherwise !EOE and !NOE always transition together.

(The following only applies to !EOE when !M3 = 1)
When !SRES = 0, !NOE/!EOE = !OE0.
When !BGACK = 1, !NOE/!EOE = !OE0.

Things get odd at this point.

If !ZWAIT = 0, then !BGACK drops to 0, !NOE/!EOE = !OE0 until !BGACK = 1;
IF !SRES = 0, then !BGACK drops to 0, !NOE/!EOE = !OE0 until !BGACK = 1;
IF !BGACK = 0, then !SRES drops to 0, !NOE/!EOE = !OE0 until !BGACK = 1;
Otherwise when !BGACK = 0, !NOE/!EOE = !CAS0 until !BGACK = 1;

If VCLK is not present, the !NOE/!EOE interactions work, most of the time. It seemed to get locked up if signals that would be make !NOE/!EOE = 0 were held when BGACK transitioned. I was always able to get out of it with a !SRES, or if I did a !ZWAIT. The problems never exhibited in the presence of a valid clock. It seems that there is some sort of state machine in there that is running that needs VCLK in certain instances to keep from getting into a bad state.

If there is anything else anyone would like tested on it, let me know quick. I plan to reinstall it in my VA2 either tomorrow or Tuesday.

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

Re: Bus Arbiter and IO Chip Access

Post by Eke » Mon Oct 15, 2018 9:07 am

Mask of Destiny wrote:
Thu Oct 11, 2018 7:12 pm
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).
I know yes, what I meant is that 315-5339 was likely the same logic as that VAO extra circuitry but integrated in a chip.
My point was that 315-5345 chip in VA2 looked like an enhanced version of this patch in VA0/VA1, needed to fix another bugged functionality, and that those additional signals (VCLK, /CAS0, /WAIT and /BGACK) were related to the same function.
Mask of Destiny wrote:
Thu Oct 11, 2018 7:12 pm
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.
The thing is, pixel clock can already be output on /VSYNC pin if VDP register 12 bit 6 is set so there isn't much need for a similar clock output on EDCLK pin. Most likely, the I/O indication on that pin in datasheets is just to indicate register 12 bit 7 switching feature (VDP uses EDCLK pin as input clock when set and pulls it high when cleared).
Enforcer wrote:
Mon Oct 15, 2018 4:46 am
IA14 Behavior
1 when !M3 = 0, otherwise ~A14.
I guess VA14 is inverted because logic was simpler using a 2-input NAND gate (with both M3 and VA14 as inputs) and it does not really matter since it applies for both reads and writes so it would be transparent for the device accessing the RAM chips.
Enforcer wrote:
Mon Oct 15, 2018 4:46 am
EDCLK Behavior:
0 when !SRES = 0,
MCLK/4 when !HSYNC = 1 otherwise
15 MCLK/4 followed by 2 MCLK/4 repeated.
That pattern actually matches what was observed some years ago using HardwareMan oscilloscope captures.
viewtopic.php?f=22&t=519&start=86
(that thread was actually one of the first I think where VDP signals behavior was deeply studied, too bad most of the image links are broken now)
Things get odd at this point.

If !ZWAIT = 0, then !BGACK drops to 0, !NOE/!EOE = !OE0 until !BGACK = 1;
IF !SRES = 0, then !BGACK drops to 0, !NOE/!EOE = !OE0 until !BGACK = 1;
IF !BGACK = 0, then !SRES drops to 0, !NOE/!EOE = !OE0 until !BGACK = 1;
Otherwise when !BGACK = 0, !NOE/!EOE = !CAS0 until !BGACK = 1;
I think it gets odd because the signals you are driving have specific purpose when the chip is connected in the real console and they are not meant to get stuck while others are changing (!SRES and !ZWAIT especially)

When !SRES is asserted, VDP is in reset state so it doesn't assert !OEO anymore, same for !BGACK (from VDP or Bus Arbiter) so the logics you tested probably never happen on the real hardware. Considering !SRES is surely only used to reset the internal logic, maybe it could be interesting to test the effect of !SRES transitions from 0 to 1 with some other signals asserted to see effect on /EOE and /NOE.

Same for !ZWAIT, when Z80 access 68k bus, the signal sequence from Bus Arbiter is most logicaly !ZWAIT=0 -> !ZBUSACK=0 -> !ZWAIT=1 after some time (unless accessed bank area is illegal) so the case where !BGACK goes up while !ZWAIT is asserted probably never happens. Note that Z80 reads to 68k RAM does not seem to work on most Mega Drives but I remember some people saying it could have worked on earlier models so maybe this circuit has something to do with that. Again, it could be interesting to test that sequence and see how /EOE and /NOE outputs react to !OE0 being asserted.

!CAS0 is asserted by the VDP for reads in $000000-$DFFFFF range but I also have some old note (from Charles MacDonald I think) indicating it was asserted for reads in full $000000-$FFFFFF range during VDP DMA. I don't know about /OE0 but it's possible it does not get asserted during DMA or the timing is wrong so /CAS0 needs to be used as output enable for the RAM chips in this case (/RAS0 is still usable as chip select but is apparently asserted within $800000-$FFFFFF range by VDP during DMA) ?

In that case, !BGACK would be used to know when someone outside 68k CPU has taken bus access and !ZWAIT to differentiate between accesses from VDP (DMA) and Z80.
If VCLK is not present, the !NOE/!EOE interactions work, most of the time. It seemed to get locked up if signals that would be make !NOE/!EOE = 0 were held when BGACK transitioned. I was always able to get out of it with a !SRES, or if I did a !ZWAIT. The problems never exhibited in the presence of a valid clock. It seems that there is some sort of state machine in there that is running that needs VCLK in certain instances to keep from getting into a bad state.
VCLK is likely used to latch/BGACK input at the correct point (rising or falling edge of VCLK)

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

Re: Bus Arbiter and IO Chip Access

Post by Enforcer » Mon Oct 15, 2018 1:03 pm

I agree most of the interactions I did with regards to !BGACK should be impossible. I was doing them more to see if it would give more info on how the functionality was implemented at a logic level. I did test with the other signals left asserted when !SRES becomes asserted. With a valid clock it always fell over to the !SRES behavior. Without a valid clock things were a bit more “interesting”.

The thing I find odd about the A14/IA14 behavior is that With IA14 = ~A14, the two different RAMs would be latching different addresses. (One using A14 the other ~A14. To the chips, they don’t care and the address space is the same, just would be a little confusing if you dumped ram with something external to the system.

User avatar
TmEE co.(TM)
Very interested
Posts: 2321
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) » Mon Oct 15, 2018 3:06 pm

EDCLK generation is made with a little sub board on MD1 VA0 that consists of 3x logic chip. IA14 is probably made by the 00 chip between the RAMs on VA0. Nobody seems to have made a schematic of the board yet though.

Full EDCLK pattern is "8aaaaaaa99aaaaaaa8aaaaaaa99aaaaaaa" where each symbol is one pixel, 8 is a pixel with 8x MCLKs, a is a pixel with 10x MCLKs and 9 is a pixel with 9x MCLKs. There are 100% definitely pixels with 9x MCLKs in the EDCLK pattern on all the hardware I tested (MD1 VA1 to VA6, MD2 VA0 and VA1, couple superclones with SE-93 VDP). TulioAdriano corroborated the results on his hardware also using a Rigol scope.
VRAM pin 24 has one transition per pixel (except during refresh cycles) and is the perfect way to measure pixel to pixel stuff.

http://www.tmeeco.eu/SMD/EDCLK0.png
http://www.tmeeco.eu/SMD/EDCLK1.png
http://www.tmeeco.eu/SMD/EDCLK2.png

EDIT: it should be noted there are 2 types of HSYNCs too, half lines and full lines. Half lines are found right around VSYNC and their positioning changes if interlacing is enabled. Best way to get output with these out the way is to use V240 with 60Hz if your scope lacks TV sync trigger features.
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

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

Re: Bus Arbiter and IO Chip Access

Post by HardWareMan » Mon Oct 15, 2018 4:50 pm

Eke wrote:
Mon Oct 15, 2018 9:07 am
(that thread was actually one of the first I think where VDP signals behavior was deeply studied, too bad most of the image links are broken now)
It's pity, yes. Feel free to ask me to recapture any of it (or any other) with any of this method: oscilloscope with up to 4 channels (up to 100MHz throughput) or logic analyzer with up to 34 channels (up to 200MHz capture).

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

Re: Bus Arbiter and IO Chip Access

Post by Enforcer » Mon Oct 15, 2018 4:55 pm

I know someone who did a pinout of the VA0 EDCLK circuit. I’m asking them for a copy and will run it through a circuit simulator. If anyone knows of a good free simulator with 74LS series parts, let me know. I’ll have to see if our Cadence package has them.

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

Re: Bus Arbiter and IO Chip Access

Post by Enforcer » Mon Oct 15, 2018 6:54 pm

HardWareMan wrote:
Mon Oct 15, 2018 4:50 pm
Eke wrote:
Mon Oct 15, 2018 9:07 am
(that thread was actually one of the first I think where VDP signals behavior was deeply studied, too bad most of the image links are broken now)
It's pity, yes. Feel free to ask me to recapture any of it (or any other) with any of this method: oscilloscope with up to 4 channels (up to 100MHz throughput) or logic analyzer with up to 34 channels (up to 200MHz capture).
I wouldn’t mind seeing your analysis of the HSYNC, EDCLK and MCLK relationships. It seems you and I came to the same conclusion but you were running in a system and I pulled my chip out. If you look at the pictures I posted, I hat cursors in various ones measuring the pulse time. In the one with the 15-2 pattern, the time I said was 15 slow is exactly 15x the time for a single pulse. My friends schematic had some inconsistencies so I’m looking for some high res photos of the EDCLK board from a VA0. It has a 74LS74 D flip flop and two 74LS161 4bit counters. So I’m a bit perplexed at how one could derive a 4.5MCLK pulse with that hardware. And intact the pulses I shown for Fast and Slow are always 2 MCLK high and 2 MCLK low for fast and 3 MCLK low for slow. Matching with the /4 and /5.

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

Re: Bus Arbiter and IO Chip Access

Post by Eke » Mon Oct 15, 2018 8:39 pm

I think it's just you are not talking about the exact same thing.

EDCLK pattern is definitively 15 pulses at MCLK/5 followed by 2 pulses at MCLK/4, this can still be seen in Tiido pictures, even the second one where he observed pixels with 9 MCLK cycles .

Pixel clock (SCLK) pattern is different because it corresponds to EDCLK /2 but is not aligned to EDLK frequency changes (remember VDP is running at EDCLK speed, not SCLK so event can be triggered in the middle of a pixel) so you end up with 2 consecutive pixels made of one EDCLK cycle at MCLK/5 and one EDCLK cycle at MCLK/4 (symetrically), which makes those 2 "pixels" 9 MCLK cycles wide.

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

Re: Bus Arbiter and IO Chip Access

Post by Enforcer » Mon Oct 15, 2018 9:04 pm

That makes more sense. Thanks! I’m no where near looking into VDP stuff just yet so I’m sure there will be a ton of rediscoveries.

Post Reply

Who is online

Users browsing this forum: Bing [Bot] and 2 guests