exxos wrote: ↑Thu Nov 02, 2017 1:27 pm
Smonson wrote: ↑Thu Nov 02, 2017 12:26 pm
Both, but I have made an assumption that RW is LOW for a register read - when I should be driving the shifter bus - and HIGH for a write. But I have no real way to confirm.
I would assume it would follow the CPU RW states as the CPU program the registers ?
Sorry, I had it around the wrong way. High for a read when the shifter should drive the bus. I've tried both without any difference so far. Next time I'm in front of it I'll compare CPU RW with shifter RW and see if they're the same.
exxos wrote: ↑Thu Nov 02, 2017 1:27 pm
Smonson wrote: ↑Thu Nov 02, 2017 12:26 pm
Another assumption (I seem to be making a lot of these lately) is that the shifter needs to drive it's data bus for the exact duration that CS and RW are asserted together.
Data should be held while CS is active, I would assume data is latched on the edge.
That's good, the simpler the better.
exxos wrote: ↑Thu Nov 02, 2017 1:27 pm
Smonson wrote: ↑Thu Nov 02, 2017 12:26 pm
But with VSYNC all over the place, there's no way it could drive a real monitor anyway. I wish I knew why it was working before!
Is VSYNC stable from the GLUE ? Also how you generating a signal for the HDMI port ? I don't know anything about HDMI, but assume it still must still have the VSYNC in there somewhere.
Nah, VSYNC from the glue isn't stable... Looking at the frames on the scope, they vary between 50Hz and 71.2. It really looks like the Atari just switches between 50, 60, or 71.2 based on some unknown factor. Within one frame, all the scanlines are the same length, either 40 or 80 LOADs.
The HDMI signal is based on timing generated inside the FPGA. I've ensured that each HDMI frame is the same length as the Atari's frame in terms of the number of 32MHz clocks, so it will remain in synch as long as the Atari frame rate is stable. Although it doesn't start and end simultaneously with the Atari - there will be an offset delay of approximately one scanline.
exxos wrote: ↑Thu Nov 02, 2017 1:27 pm
Smonson wrote: ↑Thu Nov 02, 2017 12:26 pm
The next thing I'll try is getting rid of the 10K pulldown resistors on the data lines. They weren't on the stripboard version, so... worth a shot.
pullups are normally used, I don't see why you would need pulldown resistors ?
I added them because of the level shifting buffers - since the data lines are sometimes floating, the pulldowns are there to prevent high-frequency oscillation. Electrical noise was a problem on the stripboard prototype, so I wanted to make sure it also wouldn't be a problem on the new one. However, I don't see noisy signals anymore... the power of a ground plane I guess.
I have series resistors on the bus, so the pulldowns could be pulling down too much. It's on the list of things to try.