Has anyone experimented with applying phase2 to BE? As far as I can see from the data sheet, it ought not to affect the processor - the data and address bus would be isolated at a time when the processor isn't using them (provided the external memory parts are in timing spec) but should save me eight or ten chips on a video design.

Neil

No... But I suspect it won't work on an '816 which wants to drive the data bus when the clock is low... (unless you're only using 64K RAM)

-Gordon

_________________
--
Gordon Henderson.
See my Ruby 6502 and 65816 SBC projects here: https://projects.drogon.net/ruby/

Answering my own question: it appears not to affect a minimal design 65c02 at all, which is what I had hoped.

That means I can get a bit creative with two processors on opposite phases and with different approaches to their ram, possibly sharing different bits of the same eeprom.

Neil

Keep in mind the 65C22 needs valid address and R/W signals on the rising edge of PHI2. If your minimal system does not use any 65XX peripherals, then you should be ok.

Daryl

_________________
Please visit my website -> https://sbc.rictor.org/

Yeah, I guess that's the 65c22 out then... but an hc374 latch will grab on the rising edge of rnw gated with something suitable if necessary.

I'm currently trying to work out how to use a single eeprom chip and a single ram chip with different memory mappings for each processor. Not sure if it's possible but it'll be fun if it is.

My quick test just used my variant of Grant's minimal system with the two pins wired together; everything seems to work including critically the 68B50 UART. Whether that continues to work if the other phase of the clock gets full of data is another question!

Neil

couldn't you just hook PHI2 up to an unused address line on both the RAM and ROM? that way it would map memory to a different part of each chip depending on the clock phase. or if you route it through some logic you could leave some part of RAM static so both CPUs can communicate through it.

sharing the bus could also be done by having each CPU go through a 74x245 (for the data bus) and some 74x541's (address bus and R/W line). it's functionally the same but now you could connect each CPU to their own private 65C22 (which could also be used for communication between CPUs).
but at that point you pretty much just have 2 seperate SBCs sharing some parts and running at half the speed that either of them could run alone.

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

Quite. That's how I started, with 245 and 541 isolating the busses, with the added complication of a 64k chunk of memory that had to be visible as one block from one processor but as four 16k pages from the other, so I needed an adder in the system too... the original plan was for an SVGA graphical output - monochrome, 40MHz dot clock so 5MHz processor clock, but I only have 150nS eeproms to hand and they're not fast enough.

As briefly discussed elsewhere the plan is to use the second processor as a video ram address generator by running 'rom' code and grabbing data from the simultaneously addressed but otherwise isolated ram. As it wouldn't go fast enough, the initial proof of concept would be to run it at half speed and check with a scope for timings etc... but that struck me as a bit silly until I can get (and program) faster proms. Two issues that raised their head was the need for something akin to a 6522 to handle both the page offset (via an adder, further slowing things) and to manage a ps/2 keyboard; and the fact that the video 6502 needs access to a minimum of ram for a stack (though that also applies to plan B).

So plan B: modify the minimal system already running at 1.8432MHz and aim for 60Hz VGA output but at a reduced output resolution; the 1.8Mhz signal actually meets the VGA spec within a few nanoseconds and better than the 0.5% tolerance. It results in 44 * 8 dots in the active picture; I intend to restrict it to 200 dots which is handy for forty characters across a line. Reading each line twice to get a reasonably square dot gives 240 lines; with an 8x16 character cell that's forty across and fifteen characters down. Or twenty characters down if I use an 8x12 cell. This requires a shade under 8k bytes of video ram (8000 if we're being exact!)

On this basis, the main processor memory looks like:

• Ram from 0x0000 to 0x7fff, with video memory starting at 0x6000 and half a k unavailable (by treaty, not design) at 0x4000-0x4200
• I/O space from 0x8000 to 0xbfff, basically the UART (so a ps/2 connection is not required; it can use a terminal for now)
• Eeprom from 0xc000 to 0xfff, using half a 28c256

While the video processor memory looks like:

• Ram from 0x0000 to 0x0200 (though more likely 0x0000 to 0x2000 to simplify decoding) which would map to 0x6000 upwards of the main processor ram
• A tiny bit of write-only I/O to set and clear a couple of flip-flops on the zero page
• Eeprom from 0x2000 to 0x3fff, echoed to 0x6000, 0xa000, and 0xe000, provided by the other half of the main processor eeprom. If I can work out a way to do it

Which is where I am at the moment...

Neil

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

Just a quick note as I don't have much time - I think sburrow's Acolyte system works this way, and he gets around the 6522 issue by sending it a delayed, shorter PHI2 signal that's only high during the last quarter of the cycle rather than the last half of the cycle.

My own systems haven't used BE at all - instead I've tended to connect the 6502 directly to the 6522, ROM, RAM, etc, and give the video circuit its own RAM, with transceivers between the two halves of the system to keep the buses separate. So when PHI2 is low, the transceivers are inactive and the video circuit reads from its RAM, while when PHI2 is high the transceivers may be active to allow CPU access to video RAM.

Exactly correct George, thank you.

Yes Neil, I connect BE directly to PHI2 and it works wonderfully. I had tried different schemes in the past, but ultimately I wanted to save logic at some point and just straight connected it. It has worked on at least 2 or 3 of my models so far.

What I *really* do though (don't laugh!) is connect PHI2O to BE. I figured the pin just doesn't get much love any more, and it might give it a tiny tiny delay to help in timing. In the end, it doesn't matter, and I still use PHI2O simply because if I need to bodge something I can easily just cut that line and nothing else in the system is affected.

Thanks!

Chad

FYI, the Acorn Master does something similar as well:

In this case, it's a 65SC12 processor and the DBE signal, but the idea is the same.

I think this is avoiding contention with the video system, which uses the data bus during Phi1.

Dave

It's interesting that they added an RC delay circuit there, I guess that makes it lag PHI2 by 10-20ns depending upon the threshold on DBE?

Chad, I had wondered about using ph2 to give a delay, but of course it gives a delay at both ends. I have a dot clock running at 14Mhz and change, and I'm playing about with that to generate a delayed ph2 for a 65c22; it would be nice to include the 65c22 if only to simplify PS/2 keyboard and/or mouse interfacing.

At the speeds I'm using, the last half of ph2 or ph0 should be no worry.

The system I learned on - Microtan 65 - used an off-phase video generator with a character rom, and I, um, borrowed that way of doing it many times, though it used a divider chain to generate the addresses and blanking. That was handy for me since I had to generate signals which could be overlaid on PAL-625 interlaced video signals, so I used a phase-locked-loop to generate a 6Mhz dot clock. I built one system that was installed in a TV station in Leeds in the mid-eighties - wirewrapped - and which ran without missing a beat until they closed the studio twenty-odd years later.

(and in an odd coincidence; the first 6502 cross-assembler I used was Avocet running on CP/M and a nature program on the TV at the moment has just shown a flock of them )

Neil

The things that were odd for me were the CS lines on the VIA. I actually had /CS2 from my /IO addressing, but CS1 connected directly to PHI2. Thus, the VIA is only activated during the PHI2-high side (thus my video addresses is ignored), and then the clock for the VIA is high, like George and you are talking about, at the second half of the PHI2-high cycle. It's been working great for me (as soon as I figured out I had the wrong databus, ah!). I always seem to find the issues AFTER I get the board printed... Lots of bodges

As to the delay on both ends, I was actually thinking that would be an issue, but it turned out to not in my case. Keeping BE high just a tiny bit longer was actually a good thing, so that the databus on the 6502 could latch. Delaying on the front end wasn't an issue since I was giving RAM and ROM plenty of time anyways. This is all theory, because of course in my case, it didn't matter either way. The delay is SO minimal it isn't even worth discussing at my speed.

Are you using BE to run a video circuit? I feel that implied by some of your responses. And I think we had talked about that some time ago too, right?

Thanks!

Chad