Yes indeed, SPI RAM might be a nice simple way to provide memory for ZiCog to run CP/M. If ultimately a bit slower than the parallel RAM solutions we have.
ZiCog is written in Spin/PASM. It can use a cached memory driver like Bill Henning's VMCOG. There was no C for the Propeller at the time. That came later with ZOG/ZPU then Catalina then prop-gcc. I see no point in rewriting ZiCog in C.
Upshot is that I'm not about to adopt SPI RAM for ZiCog unless someone has a cached driver in Spin/PASM that can be more or less dropped in.
Yes indeed, SPI RAM might be a nice simple way to provide memory for ZiCog to run CP/M. If ultimately a bit slower than the parallel RAM solutions we have.
ZiCog is written in Spin/PASM. It can use a cached memory driver like Bill Henning's VMCOG. There was no C for the Propeller at the time. That came later with ZOG/ZPU then Catalina then prop-gcc. I see no point in rewriting ZiCog in C.
Upshot is that I'm not about to adopt SPI RAM for ZiCog unless someone has a cached driver in Spin/PASM that can be more or less dropped in.
Well, I'm pretty sure the sources for Bill's VMCOG still exist. Also, all of the "cache drivers" in propgcc are written in PASM.
(I was going to add a cache driver as an attachment but I don't see how to add an attachment in the editor)
That would remove all of the perversity in wanting to do something backwards stepping ;-) Working on the premise that everything should be removed until something really horrible happens - electronic Buckeroo (in reverse).
I wonder about using the internal /RAS, /Cas latches and so allow for at least two chips to be removed from the usual Dracblade design.
I saw that one, and a few similar ones. We are still nursing along some kit that was EOL years ago so that is a source of ancient bits (even if they are really a bit too modern for a Z80). I am experiencing that adage that "time goes faster as you get older", now I do not have half the time to do the stuff I used to.
I chuckled at a sit-com that used the phrase "Cockpit Buckeroo" - you switch off stuff, hoping nothing unpleasant occurs ...
I still haven't removed the yearnings to put on a old DRAM - directly onto the Prop (256K x16 (but only 8 bits used ... to start with)).
You can go backwards-stepping anf forwards at the same time, if you connect HyperRAM
That comes in 8b wide, and needs far fewer pins, but still has some timing rules that need to be hard coded.
Comments
ZiCog is written in Spin/PASM. It can use a cached memory driver like Bill Henning's VMCOG. There was no C for the Propeller at the time. That came later with ZOG/ZPU then Catalina then prop-gcc. I see no point in rewriting ZiCog in C.
Upshot is that I'm not about to adopt SPI RAM for ZiCog unless someone has a cached driver in Spin/PASM that can be more or less dropped in.
(I was going to add a cache driver as an attachment but I don't see how to add an attachment in the editor)
That would remove all of the perversity in wanting to do something backwards stepping ;-) Working on the premise that everything should be removed until something really horrible happens - electronic Buckeroo (in reverse).
I wonder about using the internal /RAS, /Cas latches and so allow for at least two chips to be removed from the usual Dracblade design.
After Earl "Madman" Muntz.
https://en.wikipedia.org/wiki/Muntzing
I chuckled at a sit-com that used the phrase "Cockpit Buckeroo" - you switch off stuff, hoping nothing unpleasant occurs ...
You can go backwards-stepping anf forwards at the same time, if you connect HyperRAM
That comes in 8b wide, and needs far fewer pins, but still has some timing rules that need to be hard coded.