Whoops, Three posts above, I cancelled my Jameco order. Bought a "speakjet" talk chip instead. Have been reading on the internet that most modern implementations of speech are just produced with DSPs and/or regular microprocessors.

I remember reading something by Rodney Brooks, I think? Something about a robotics/computing theory called "compartmentalization" or something like that? An academic buzzword which, essentially, means "do the computation, where the computation is needed". I like that idea, and I think it makes a lot of sense. But, as I said, I'm "new here".

If you are running on MS Windows I suggest you give Express PCB's software a test run. The package contains a decent schematic editor and PCB layout program. I'm not advocating that you use their board service to get your PCBs made (although I do use them for that purpose), but their software is a friendly intro to the world of PCB CAD and will get you familiar with it.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

I keep mentioning this interview, so I thought I'd post a link to Bushnell's (Atari's) decisions in the early days of the arcade industry. The story starts at 1:40 seconds, and recounts his attempt to use minicomputers to run a game on several screens at a time, so that he could make them coin operated and turn a profit on the outlay for the computer.

https://www.youtube.com/watch?v=B7DuUZokcw0

OK, after floundering all day (and all week) and blathering on several strings of this website, I have found the answer I need (or, rather, the question I need). Thank you wikipedia (and any of you post-ers who feel like adding some comments).

I had a feeling dual port RAM could be useful, and wikipedia confirms on their FIFO page.

https://en.wikipedia.org/wiki/FIFO_%28c ... lectronics

So, one port is a dedicated read, and one a dedicate write. Seems like what I want for large amounts of video data. I probably still need a multiprocessor (or else, just a non 65xx, newer-type processor) architecture, since, even though the digital video is in the RAM, there will need to be lots of throughput and main memory storage. So, in other words, after finding its way into the dual port RAM, some processor, or other, must send it to a final destination.

Have been absent from this (my major thread) for some time, due to "lack of a concrete plan". well, not entirely accurate; lack of a concrete "digital design" plan. The "scientific hypothesis" is still a novel one, and one that is in need of "reduction to practice". So, there is much "planning" behind it (and in front of it!).

https://en.wikipedia.org/wiki/Leaky_bucket ; immediately conjures up memories of Ricky Nelson's "My bucket's got a hole in it (it don't work no more")"! Ha! No, I 'm not old enough to have a valid excuse for knowing about that song, nevermind having it on "instant recall", in my brain!

Today, I'm looking at "the market" (mostly digi-key) to see what is available for dual port SRAM. (This is probably VERY late to be asking this question, but does the 6502/65xx/65816 etc. system REQUIRE Asynchronous RAM? Or is it just easier for beginners to understand? I probably won't gain much using Synchronous RAM, except the hassle of "bringing the clock with me" everywhere I go? Mightn't some DRAM serve my project well? Hassle of the multiplex, and refresh circuit, though? I find the video signals I want, and have designed, are very high data-load. I am not ENTIRELY un-knowledgeable about DSPs and the "1990s" IC advancement; but certainly I am unexperienced; high clock speeds and SMT devices discourage my gaining such experience.)

It is possible for me to investigate the FLEX Altera FPGA (PLD?) that the kodak/nat.sem. image sensors originally had placed on their development boards; but PLA, PAL, and FPGA might be more flexibility than I want or need. Regular old fashioned hardware design will be just fine, for me. It seems to me the video signals from the image sensors are routed to the FPGA (PLD? technically?), then altered, in some fashion, and then sent to the memory buffer board. Maybe I'll post the schematics, below.

I have a rough idea of what I want, and have sort of block-diagrammed it out, but by limiting myself to DIP packaging I can only find 8 or 16 KB of DP-RAM, per chip. For a 65816, that's alot of chips to fill the mem space! (1,000).

Barry Brey's "Intel microprocessor" textbook mentions "Shared Bus Architecture" (or some such acronym-inducing catch phrase), that had me briefly envisioning 5 or 10 QTY 65C02s fetching data from the dual-port RAM, (maybe doing a little bit of minimal computation?) and shuttling it to some "main memory" (DRAM? ASRAM/"fast"-RAM), and, maybe, even use a 65816 to do the main processing of this "main memory". Just a brief flutter of a thought.

Ideally, I would use the right tool for the job that must be done, but I'm afraid the bewildering plenty of IC design has left me to cobble together a solution that seems "accessible" to me. Hence, the 65xx (despite its "dinosaur", ancient attributes).

OK, enough babble, for today. Here is a schematic or two.

(Note, looking at the Dev-Board/Kodak schematic, I note something I missed before. The PLD handles the sysclk (generated by crystal) and makes?/passes-on? the mclk that runs the sensors; mclk, from the KAC9628 documents is the generator of the pclk and vsynch and hsynch; so, its important. )

Whoops, I mispoke/mis-wrote. 1KB DP-SRAM, or 2KB DP-SRAM. So, 8,000 or so DIP chips would fill a 16 MB mem space of a 65816. Too much! No matter. I must find another solution. Maybe bend out a gull-wing IC, like I have seen on this website somewhere?

Also, here is the loosely reconfigured schematic I have devised. It is a mess, no doubt, but more creative and interesting than my first plan, and probably closer to the "right answer" that my project needs.

There is no getting around it, though. I am going to have to get very specialized about digital video signals. It wouldn't hurt for me to get familiar with HD TV specs (though I can't even AFFORD an HDTV, nevermind study one; nevermind the BOOKS to study one!), but definitely, I should start with the VGA standard (as that is what my sensors use). Pins and signals of VGA should be known, backwards and forwards, before I proceed.

The KAC9628 pdf mentions "digital image processor" and/or "digital video processor"; I have searched a bit, online, but I think, more commonly, in actual practice, that PLDs/FPGAs and/or DSPs do the work that the KAC9628 pdf refers to.

So, in explaining my new tentative block diagram, I will mostly leave much to the imagination. The plan, roughly, is to rob a bit of ROM mem space (i.e. change the decoder circuit) and also, to only allow the 65816 to access half of a DP-SRAM at a time. The other half is dedicated to the KAC9628 image sensor. Some sort of counter should count clock cycles of the KAC9628, as it is constantly writing, and, at some set point, logic would flip the "65xx read-write" area with the "image sensor, constant-write") area.

There are some other aspects of memory that I should research, and I really must stop "writing" today, myself, and do much more "reading". Funny that me and memory chips should have so much in common (constantly reading and writing!).

Specific topics I am investigating are (1) burst memory (whatever that means; it sounds good though! burst = fast, right?), and (2) Page read and/or page write.

With regard to the latter, my naive and uninformed mind, thinks that if one command can "flush" or "dump" large segments of the memory (fast-RAM; i.e. Asynch. SRAM), automatically, with high speed, to some other memory element (like a high capacity DRAM or other), with minimal time lost to the microprocessor, then that would be good!

I know I said I was studying DMA, but I am not sure that DMA, strictly speaking, does what I want it to do. Also, I am not sure what sort of DMA controllers are out there, beside the 8237, which, it appears, has limited availability outside the "ebay"/computer-historian collectors/high-volume applications/OE manufacturers markets. I don't know for sure. I'll bet there are better, non-proprietary solutions out there! I just don't know what they are.

Cheers (I run at the mouth again, so, there is only one thing for it. STOP WRITING AND START READING!).

Oh yeah; "4KB fovea" in diagram, I think, must be a typo? Don't know what I meant there? the 18QTY refers to having one DIP DP-SRAM for each VGA image sensor, for the 18 sensors of both "robotic eyes". Tentative plan, needs a better memory and lens and bus structure.

One last thought, here, for today. The wikipedia page says the following, "For FIFOs of non-trivial size, a dual-port SRAM is usually used, where one port is dedicated to writing and the other to reading.".

My FIFO is non-trivial in size, but I think the DIP limitation I have placed on my design, limits the plan. I am seriously reconsidering having a professional PCB house do the work. Perhaps, if I am smart enough, I can just design it correctly, and let the "mundanities" and "pedestrian" details be addressed by persons expert in the field. Just a thought. For now I should continue to design for "tinkerablitiy" and "accessibility" of design.

Just to remind you, the data rates I am dealing with are 648 pixels * 488 pixels * 30 fps * 12 bit depth = 113.8 Mb/s AKA 14.2 MB/s . That's for one sensor. Times 9 (monocular) and 18 (binocular), and the data gets serious. (Oh yeah, note, if using a "soccerball array", i.e. the truncated icosahedron, the most likely structure, then monocular is 6 sensors, and binocular is 12 sensors).

and

Wikipedia has a lengthy article about synchronous DRAM. If I understand it correctly, part of it is that you give it an address, then transfer a byte or word with every clock cycle or even every clock edge, for the length of the burst. The RAM increments the address internally; so it's not truly random-access like the 6502/816 needs when it's jumping back and forth from op codes to data-memory accesses (with reads and writes mixed) or may dwell on the same byte for two clock cycles in a row in some cases. Such DRAM is expected to be used with cache (possibly multiple levels of cache), then the DRAM controller fills the cache using these bursts and the processor accesses the cache which is truly random-access and very fast but smaller. I better stop now since I've told you more than I know about it. Maybe someone else will jump in with more info.

For the amounts of data you're talking about, I think you're going to have to learn about DRAM controllers and DMA. SRAM is wonderfully easy to use but cost-prohibitive for that quantity of data. Next, what will you do with all that data? If it's a challenge just to move it into memory as fast as you gather it, how will you actually process and do something meaningful with it at that rate? Or do you want to only gather it for a few seconds and then stop and have time to do something with it?

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

During the burst, you are allowed to change the address bits, and perform some limited form of random access. However, there are two limitations: there's a 2-3 cycle delay when reading data (CAS delay), and you can only change the address bits within a page (which is on the order of 1KB usually). If you want to access another page, you first need to close the current one, and open another. This takes some additional cycles.

As you said, SDRAM works best in combination with a cache.

Thanks Garth. Will read the wiki when I get the chance, as it seems powerful.

What to do, with "All the data in the world"? I think David Byrne, formerly of the Talking Heads, said it best in the title of his song "Like Humans Do". That's why, I joke that I will use 65xx technology to process this video data, but, in reality, I am probably going to need to figure out some newer processors. Unless Mr. Mensch can rent a 45nm fab and give us a 60 headed 6502 hydra! Ha! Probably unlikely!

Thanks for you comments. I clearly have about 20 or 30 years of computing technology (implemented architectures, especially, but "supporting IC" technologies as well) and theory to catch up on. I suppose DRAM is the next thing I should study (with DSPs and "video data/signals/standards" next; image processing a close third)?

He estimates the '02 would run at 10GHz on a modern 22nm process, if memory and everything needed is all onboard the same IC. (10nm is expected in 2017.) Will they ever do it? No, although it'd be fun to see it.

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

Sorry guys, I hate to be as newbie-ish as I am about to be, but please define "cache". I am pretty sure there are at least two type "on-chip/on-processor cache"--like in new processors--and the other kind (I assume Asynch SRAM cache? "fast"-RAM?).

I was watching a interview with Sophie Wilson (inventor/co-invenotr? of ARM) on youtube. She mentions --paraphrased here, as I have run out of time on this computer, and can't track down the quote--that "all the innovation in microprocessors in the past ten years (circa 2005-1995, time span) has been addinjg additional memory to the processor (i.e. pipelining and cache).".

That is an extremely rough paraphrase. I will post the link, at a later date, and give the min:sec point of the interview (its a three part interview, split up on youtube to 3 vids).

There can be several levels of cache too. See the wikipedia article at https://en.wikipedia.org/wiki/CPU_cache . It gets awfully complex. A reason I like 6502/816 is that it lets me get the processing power I need on the workbench and understand it and have full control without being a computer engineer; because to me, although the computer is fun, it's not an end in itself (like it might be to a computer engineer). I got into this stuff mostly for controlling analog circuits.

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?