In case you're interested in opening it up to see the calculations, or experiment with it yourself, here's a public link to the spreadsheet: docs.google.com/spreadsheets/d/1LZPBou60GF9zsVSWE1NurdLbBgzc3x6EA8TjfMUQyb4
I guess I really just am the type of person who would rather mumble at a bread board for three days trying different IC’s than actually doing the right thing… like you do here.
Yes that could help. I also considered using multiplexers, to pick between the two address sources. I don't think anything is fast enough to make up for the slow RAM though.
random thought, but could a lot of this be simplified using some 22V10C? Like, the versions with ~5nS pd? I really like your approach with using a computer to help wrap your head around all of these timing constraints. I will keep that in mind. my attempt at a project right now is to controll a (parrellel interface) LCD shield for Arduino and read data from an SD card. maybe even trying to get some sort of GIF running (even if i have to use individual pictures. what is frame rate?) oh and also see if i can use an attiny84 to decide which computer connection to use, wifi/bluetooth or usb! (ESP8662) maybe do away with the super slow 65c51. what do you think? maybe even setup a camera so others can see their code running on it?? security issues tho.. i think. i know nothing about security. i just need to give myself a push to really start working on it.
Yes I could use one to drive the control signals. I'm not sure it would help with the actual timing delays though, as the other components still need their setup times etc to be met. Some kind of RLE packing could work well for your animation, depending how much changes from frame to frame - you could encode a target address and then a series of pixel values to write into consecutive addresses, to write a lot of pixels in a row efficiently. This is something I'm probably going to change in my current interface here as it'll be a lot more efficient for the 6502 as well.
In case you're interested in opening it up to see the calculations, or experiment with it yourself, here's a public link to the spreadsheet:
docs.google.com/spreadsheets/d/1LZPBou60GF9zsVSWE1NurdLbBgzc3x6EA8TjfMUQyb4
Nice work! That's a great way to chase down complicated timing and determine which component is critical.
I guess I really just am the type of person who would rather mumble at a bread board for three days trying different IC’s than actually doing the right thing… like you do here.
Haha, well me too, that's what promoted me to check the specs!
“One week of programming saves one hour of meetings”
Great work!
It's a good idea. Better than doing it by hand, that's for sure.
I'd like to make a better chart to show all the times together one day rather than just the control signals
great explanation! it might be worth putting 245s after the 590s, to speed up OE / address switching
Yes that could help. I also considered using multiplexers, to pick between the two address sources. I don't think anything is fast enough to make up for the slow RAM though.
@@GeorgeFoot You could try writing to 2x the RAM from the CPU, then interleave the outputs in antiphase.
random thought, but could a lot of this be simplified using some 22V10C? Like, the versions with ~5nS pd? I really like your approach with using a computer to help wrap your head around all of these timing constraints. I will keep that in mind.
my attempt at a project right now is to controll a (parrellel interface) LCD shield for Arduino and read data from an SD card. maybe even trying to get some sort of GIF running (even if i have to use individual pictures. what is frame rate?)
oh and also see if i can use an attiny84 to decide which computer connection to use, wifi/bluetooth or usb! (ESP8662) maybe do away with the super slow 65c51. what do you think? maybe even setup a camera so others can see their code running on it?? security issues tho.. i think. i know nothing about security.
i just need to give myself a push to really start working on it.
to get decent frame rate, i could probably create a very specific binary file that specifies the pixels that actually change and their locations.
Yes I could use one to drive the control signals. I'm not sure it would help with the actual timing delays though, as the other components still need their setup times etc to be met.
Some kind of RLE packing could work well for your animation, depending how much changes from frame to frame - you could encode a target address and then a series of pixel values to write into consecutive addresses, to write a lot of pixels in a row efficiently. This is something I'm probably going to change in my current interface here as it'll be a lot more efficient for the 6502 as well.