Very interesting. I am working on a similar project and i figured it out. I can tell you that you are on the right track but it will be much more complex as it seems right now. If you want i can give you some hints. Otherwise i follow you and keep watching for your solution.
Is your video ram clock synchronous to the CPU clock? Or at least a known synchronous multiple? If not, you may have to work harder to deal with the clock handoffs. 100% I'd add something like an SR flop that gets set when the CPU initiates a transaction and when set, causes the video to execute the transaction, then the video side clears the flop. The CPU should be able to read the flop for testing and possibly holdoff purposes. The usual solution to frame tearing during writes is to use two frame buffers that can be toggled during a VSYNC at the request of the CPU, but then you have to update two buffers which you might not want to do. Anyways, looks like a fun project. Are you planning SRAM or DRAM for the video?
So right now clocks are not synchronised. But I’m hoping that I could divide the video clock by 4 and use that for the cpu clock. I’m planning to use SRAM. I like the idea of using a second frame buffer.
@@SteveRaynerMakes I usually implement a second frame buffer in memory just by toggling an address MSB in the RAM, so the low half is frame 0 and the upper half is frame 1. You'd have to check the timing in a lot more detail to figure out your clocking though. Some systems will hold off the CPU access to the horizontal or vertical blanking interval, so you get around 9 us every 65 usec or so (using hsync) but that gets more complex, although could be done with just an async mux (75ls157 type thing or a tristate buffer) to switch who owns the address/data/rw bus. But most of my experience is in professional video processing appliances, not PC video cards, so there are probably a lot of great other tricks out there I've never even thought of.
Are you going to order a corrected version of the timing board at the same time? I would probably go with the Apple 1 style setup with an SR Latch, where the video card checks to see if there's a character ready to write, then CPU sets it high after it writes the data.
hmm, maybe I should. I've been thinking about it. There are quite a few things i would want to change on that. There was two small mistakes on the count decoding where I added bodge wires. Also the pixel shifting circuit didn't work. But I'm still not happy with my new pixel shifting circuit. However I was thinking I could replace that part with the final output buffer and current limiting resistors. Finally I used an incorrect footprint for the blue VGA connector so that also needs correcting. I think I would also change the pins I'm breaking out. I want the inverted counts also broken out so that I can access them. So many changes. But I really should do it.
Very interesting. I am working on a similar project and i figured it out. I can tell you that you are on the right track but it will be much more complex as it seems right now. If you want i can give you some hints. Otherwise i follow you and keep watching for your solution.
Hi. I would love to hear any hints that you might have.
Is your video ram clock synchronous to the CPU clock? Or at least a known synchronous multiple? If not, you may have to work harder to deal with the clock handoffs. 100% I'd add something like an SR flop that gets set when the CPU initiates a transaction and when set, causes the video to execute the transaction, then the video side clears the flop. The CPU should be able to read the flop for testing and possibly holdoff purposes. The usual solution to frame tearing during writes is to use two frame buffers that can be toggled during a VSYNC at the request of the CPU, but then you have to update two buffers which you might not want to do. Anyways, looks like a fun project. Are you planning SRAM or DRAM for the video?
So right now clocks are not synchronised. But I’m hoping that I could divide the video clock by 4 and use that for the cpu clock. I’m planning to use SRAM. I like the idea of using a second frame buffer.
@@SteveRaynerMakes I usually implement a second frame buffer in memory just by toggling an address MSB in the RAM, so the low half is frame 0 and the upper half is frame 1. You'd have to check the timing in a lot more detail to figure out your clocking though. Some systems will hold off the CPU access to the horizontal or vertical blanking interval, so you get around 9 us every 65 usec or so (using hsync) but that gets more complex, although could be done with just an async mux (75ls157 type thing or a tristate buffer) to switch who owns the address/data/rw bus. But most of my experience is in professional video processing appliances, not PC video cards, so there are probably a lot of great other tricks out there I've never even thought of.
Are you going to order a corrected version of the timing board at the same time?
I would probably go with the Apple 1 style setup with an SR Latch, where the video card checks to see if there's a character ready to write, then CPU sets it high after it writes the data.
hmm, maybe I should. I've been thinking about it. There are quite a few things i would want to change on that. There was two small mistakes on the count decoding where I added bodge wires. Also the pixel shifting circuit didn't work. But I'm still not happy with my new pixel shifting circuit. However I was thinking I could replace that part with the final output buffer and current limiting resistors. Finally I used an incorrect footprint for the blue VGA connector so that also needs correcting. I think I would also change the pins I'm breaking out. I want the inverted counts also broken out so that I can access them. So many changes. But I really should do it.
@@SteveRaynerMakes Less chances of making mistakes as you prototype . And if you're paying for shipping anyway!