On Thursday, August 4, 2022 at 6:48:33 AM UTC+10,
gnuarm.del...@gmail.com wrote:
On Wednesday, August 3, 2022 at 1:03:15 PM UTC-4, Wayne morellini wrote:
On Thursday, August 4, 2022 at 12:42:34 AM UTC+10, Wayne morellini wrote:
..use an Sram chip
..
Static ram.
Static rams are getting harder to come by, but they all (the engineering qualified "all") have one thing in common, they use very simple timing to control operation, using no clocks. In a generic SRAM, the reads are purely asynchronous, only requiring
the WE to remain deasserted and an address to be set up. Then X ns after the last signal has changed, the output data will be stable and can be read.
A write is a bit more work. You have to set up the data and address, wait some minimum time which may be zero (and may be different for the address and data), not sure, and assert the WE. Wait some minimum time (a similar time to the read access time
usually) and deassert the WE.
Sometimes there is a read enable that simply tristates the data out, or other times it also is involved in the write cycle timing. Keep it deasserted when not reading and it should not be an issue.
Bottom line is, you need to check the data sheets.
One big problem is the temperature dependence of the F18A timing on temperature, voltage and process. So you have to leave wide margins in your timing calculations.
I'll let you map this to GA144 chip timings. They never specified the memory interface in a way that allows it to be used for a memory interface. It was actually intended to be used with SDRAM which is much lower power and lower cost. It's hard to even
find much SRAM these days and what's out there is very expensive. Check Digikey.
--
Rick C.
+ Get 1,000 miles of free Supercharging
+ Tesla referral code - https://ts.la/richard11209
So, I saw in your post ages ago, that you could only get up to 50mhz accessing
external memory on the GA144. I had suspected it might be like that, until I read
into the sdram app note. With Psram availability, it's a mystery why a native bus
wasn't implemented, as it's basically like the internal bus. These misc designs originally
cane about to use cache sram. I'm very grateful the market made the Pseudo
Sram concept, as you. An stick all sorts of commodity ram chips into the package
and with a cheap sliver of a memory controller circuit, translate that to an sram
interface. But, thinking about it, the same thing goes for any memory interface. My two
wire parralel to serial auto execute interface could just be a supper simple controller
to commodity mobile memories (though these have major issues with value
shift)l. But there is bound to be a runner up happy to use up their manufacturing
capacity in the Psram market, which includes a lot of microcontrollers.
So, the external memory for the 144, is not going be useful for me, and there is not
enough internal memory. I had started to think of some quick techniques to do read
and write more quickly, even if I could use execute a port to somehow execute a words
from a serial memory some how in a controllable order, or redesign an interpreter to get
closer to half 650mhz (say 213hz or less). Looks like they took my advice many years
back and put a software DMA in, where I had wanted a very simple digital circuit instead
etc, allowing ports to communicate it through. No real figures are given. I was hunting
down a very small prototyping board for it. Looking at ways powering a core of the
GA144 off of the RCA video socket.
But, it would be too complex for my users. Some will get it, some others would think
those people were legends and most wouldn't. Colorforth would be enough of an
abstraction.
A colorforth like virtual machine could run on something like an ATiny85
(whatever chips with enough memory, which can ingress video, manipulate enough,
and output a video stream, in a single chip package, likely connected together without
mainboard), and maintain code compatibility with versions based on other
chips, and the same VM abstracted instruction set shared with the other project,
and between products. The other projects instruction set architecture is going be
different from the VM but still compatible. You then can just use this before you order a
custom chip. I actually had figured out a way to do object orientated processing system
which could enable day a primitive system like an Atari 2600 to run complex 2D
games similar to Sonic the Hedgehog. So, the retro processor project is going be
interesting (the community processor is just a simple embedded with good io, the
retro was actually going be a very sophisticated processing, which I hadn't
remembered before, but had identified that dropping the game features it looked good
for embedded. These are just some of several different architecture proposals over
the decades. The retro one was an old 8 bit design proposal I had, that I am
applying new ideas to in 8 or 16 bit form. As you can see in the other thread, I have
located a minute processor FPGA card due for release, this could be tested on. The
other design proposals likely don't need instruction set validation, as instruction for
instruction, they are equivalent and can map too, an existing validated
instruction set. Your main issue, is if you want to change little things to improve coding
and workflow, like testing jumps, where you have to find out if that is a good idea. So,
the community processor, is Just another Misc processor in another format (JaMISC)
and will compile code unaltered if not self changing on the same address and io
space, of course).
You also will likely be able to find JavaScript API's for these chips, to optionally use, and
role the VM into that, to make development more comfortable (before native
API's are ready), but people don't need it, it would have a very small abstracted native
substrate to interface too.
So, still significant research to go, to calculate which cheap part has enough processor to
properly handle the work load. I'm also identifying the project for a commercial
version with high volume sales, as it substantially overlaps with a few other
planned projects. So, it's still not a waste of time as a low volume diy. A shame, there is
a lot not said, but the GA144 version would have been pretty interesting.
--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)