I read through most of this topic:

viewtopic.php?f=4&t=5229

Which got me to thinking...(keep in mind I didn't fully understand all of it)...

I'm working on building a simple VGA controller using a Parallax Propeller. Now, the Propeller (Prop) is no slouch...having 8 cores of 20MIPS each.

However, in the real world, that doesn't mean I have gobs of free time between the two devices. The Prop takes 4 cycles to do just about anything (which is why you get ~20MIPS for an 80MHz core). And, of course, you need several instructions to do anything useful. Jac (and his L-Star SBC) has shown that using a Prop to directly drive a 65C02 (as RAM/ROM/IO) is pretty much limited to around 1 - 1.25 MHz. Which is respectable.

My SBC is running at 4 MHz at the moment. I'd be happy to slow it down to 1 MHz if I can't find another way.

So, here is what I'm after...I want to program the Prop to generate VGA but have the 65C02 write instructions to it and pass it data. Sort of like how the TMS9918 works.

I just don't think the Prop could handle a 4MHz CPU using it as RAM and then generate VGA during the half-cycle of 125ns.

Having good VGA (which the Prop excels at) is more important than super fast access. Besides, the Prop could receive a handful of instructions and the Prop could go off on its own and do them. Which could actually be faster than direct drive anyway.

I think what I will experiment with doing is having the Prop drive the clock directly. The Prop can easily generate a nice, 4 MHz square wave in the background and it doesn't even have to use one of the cores!

The 65C02 would read/write to a specific address...the Prop would pick on up that and then, halt the clock that it's generating. It could wait until the clock is high before it halts if that would be better.

It then could buffer that command into memory and restart the CPU. Meanwhile, another core (called COGs) could detect that buffered command and go to work.

What do you guys think?

The other option is to do it the "clean way". By driving RDY low when it detects a certain address AND the O2 is high. The advantage of doing it this way means I don't have to run a bodge wire from my VGA card into the oscillator pin. The other way means removing my oscillator completely and running a small wire from slot 3 over to the oscillator. Not the end of the world...but not as clean.

Opinions welcomed....

_________________
Cat; the other white meat.

As you say, the Prop is a multi-core machine. So with one core to handle data coming from the 65C02 bus, you still have seven cores to buffer the data, interpret it, update your frame buffer (?) and get VGA out of the video port.

The question is how rapidly can one core poll its inputs? The approach in PiTubeDirect, IIRC, is to capture all the pins every time around a tight loop, until you see something of interest. Then you already have the data bus contents, and if you need them, a couple of bits of address bus too. Something of interest means some combination of chipselect, RnW, clock. In fact I think we used chipselect as a strobe: the tight loop waits for chipselect, then a second tight loop waits for clock to fall. The previous sample before the clock fell is then the sample to inspect for information.

As you don't get two accesses back-to-back, you have some time to inspect the sample.

But, at a 20MHz sample rate you only get 5 samples in a 4MHz bus period, and that's not many, and if you're much below half that then the Prop is too slow.

BTW with the above story a write-only peripheral is a lot easier than a read-write peripheral - you only have to stash the data, you don't have to find some data from somewhere, and you don't need to change pins from input to output.

So, what I'm wondering is... if you're able to poll fast enough to spot an access and stop the clock, you're probably fast enough to have captured the data. Or nearly so.

Certainly it feels like the simplest and most reliable way is to spend a couple of gates on a RDY circuit - or a clock-holding circuit - and treat the Prop's address range as being a slow peripheral. Slowing down to 1MHz or so should give you time to capture a bus cycle.

Have you thought about using a GAL to watch for the same address range and pull ready active for a number of cycles to allow the propeller time to latch the data ?

I see the TMS9918 mentioned, there's an 80% complete propeller emulation of the 9928/9 available here
http://primrosebank.net/computers/mtx/projects/sfx/cfxii_fw.htm#firmware

it's for a 4mhz Z80 system so may need some tweaking to work with a 6502.

The propeller has instructions to wait until pins are equal or not equal(WAITPEQ and WAITPNE) to specified conditions.
Those could be used to have it react to a chip-select signal in fairly short order.

That's very handy! That could make all the difference.

I think the first thing to try would be to try to emulate the simplest possible peripheral: a writeable register which connects to a parallel port. Then you can blink an LED, or similar, but most importantly see if 4MHz access is possible, and reliable. A single register that's read/write might be a good next step, but may not be necessary. You'd need to know whether you're going to need readback access to your VGA engine, or not.

If that special instruction won't work sufficiently you may consider a FIFO or a Dual Ported RAM as a bridge between CPU and VGA controller. They require some board space and aren't cheap but faster than you need.

Regards,
Arne

If you have the board space, then how about sticking a 65c22 in-between the 65c02 and the prop to give you a latched 8-bit bus with handshaking? (and all the extra goodies that comes with it) Has the benefit of running at the same speed as the 65c02, so no messing about with waits, rdy, etc.

So setup port B with the right write-handshake mode bits, then you write a byte to port B of the 6522, arrange the prop to listen to the CB2 pin then the 6502 can carry on until the prop. reads the data and sends the ack back (via the CB1 pin) and you can either arrange interrupts or just poll for the transfer complete then send the next byte. (And polling might be faster if the prop is only marginally slower at picking up the byte than the 6502 can write them)

(Port B can do write handshake only, port A can do read and write, so for a write-only bus, then port B might be preferential)

-Gordon

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

Oh, that gives me an idea: maybe you could put the prop behind an 8-bit latch and an 8-bit tristate latch (poor man's PIA) so that the prop has several 4MHz cycles to react to a write. It doesn't get several cycles to react to a read, but you could finesse that by always doing a double read on the 6502 side: the prop gets a heads-up from the first read and has got the result out to the tristate latch by the time of the second read.

(That's not a one-byte FIFO! No need to worry about getting out of step. The prop reacts to the second read exactly the same way, and writes the result to the latch, the difference is that no-one's listening. But for this, you do need idempotent reads. No self-clearing interrupt flag.)

(There might be a saying somewhere to the effect that if you have a problem and solve it with a FIFO, now you have two problems.)

The PIC32MX devices are another option for video generation.

The PIC32MX170F256B (28 SPDIP/SOIC) has a Parallel Master Port (PMP) that can provide/latch 8 bits of data for 1,2 or 4 addresses. and 64K of internal RAM for image data when in slave mode.

I started writing the code for a dumb terminal with an 640x480 VGA display based on one. It uses DMA transfer to an SPI port for the pixels and output compare (against a timer) for the VGA HSYNC. VSYNC you can drive manually based on the scan line number.

I used a UART for input but it could hook directly to the 6502 buses if you used the PMP module instead. It would need two 74LVC245 bi-directional level changers (1 for data, 1 for CS, /RD, /WR and A0-1).

Sounds like an Xmas break project if I can free up some time from all my other projects.

_________________
Andrew Jacobs
6502 & PIC Stuff - http://www.obelisk.me.uk/
Cross-Platform 6502/65C02/65816 Macro Assembler - http://www.obelisk.me.uk/dev65/
Open Source Projects - https://github.com/andrew-jacobs