BigDumbDinosaur wrote:
Does the CPLD high-Z its RDY connection when not asserting RDY?
Obviously not, but I "think" we're getting somewhere!
So I arranged what you're suggesting by:
Code:
// Halt the CPU with RDY low
rdy_en.clk = PHI2; "rdy_en synced on rising edge of PHI2
when DIV25 then rdy_en := 0 "CPU should halt when DIV25 is high
else rdy_en := 1; "CPU should run when DIV25 is low
when rdy_en == 0 then RDY = 0; "when rdy_en is low then RDY should be forced to low
"I'm not sure if en 'else' is strictly necesary???
// RDY.oe = 1; NOT tri-statated
// RDY.oe = 0; tri-statated
RDY.oe = !rdy_en; "when rdy_en = 1 the RDY is tri-stated
For a moment I thought this fixed the problem, but after monitoring a bit longer, the computer crashed at roughly 80 seconds. :-/
Attachment:
111.png [ 63.84 KiB | Viewed 931 times ]
Attachment:
112.png [ 60.97 KiB | Viewed 931 times ]
cbscpe wrote:
Just a remark, if I remember rigth, you jumped from CPU only and VGA only directly to the full blown solution with RDY and stopping the CPU during display. I would suggest that you first try an intermediate solution with just interleaving CPU and VGA access and go with 4 bits per pixel.
That’s right, I'd probably be happy with a "one byte per PHI2" solution. Be it 4 bits per pixel, half the x resolution or composite.
However, at some point I want to use wait states to be able to use slow devices on MARC-2. I'd rather do that with RDY than with clock stretching, because that would mess up any VIA timings when I should need them, right?
cbscpe wrote:
Just to make sure that there is not more thAN just the issue with RDY, which as far as I have studied the information should work as it is.
Well, I hope it is something that will pop up and can be fixed. Otherwise I would be stuck without being able to use RDY.
nyef wrote:
To be fair, the entire idea is predicated on having a 16-bit channel to RAM, which is two 8-bit data busses at once, which you might not be able to do if you're short on spare I/O pins.
It certainly is a quite nice solution, but I'm not sure if it's worth the extra needed pins and the effort of piggybacking an extra SRAM.
Next, I'll probably try the intermediate solution cbscpe suggested.