Propeller presenting itself as a ROM, for another computer?

potatohead

I'm just musing a little, wondering:

-what's the complexity level of this?

Say that other computer is a 6502 design, for purposes of discussion. I've no real plan at the moment. Really just looking for some general info to think on for a while.

-what hardware add ons would be required?

One problem I see is startup time. The other machine is gonna expect to see a ROM right away. So, that's gotta be done for sure. A small ROM, just enough to coddle the other box, until the prop gets settled would be one option. Powering the thing on a rechargable battery, charged when attached to the other machine is another. Have it start, on reset button press, then insert it running, that way it's doing it's thing when the other machine wants it to. I'm sure there are others means and methods too.

If the other device timing is known, it seems to me a cog or two would be able to deal with those signals and act like a buffer between the remaining COG's and the device the whole works is being attached to.

Has anyone done this and have project info to share? Again, just more curious at this point as to what might be doable.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!

Mike Green

1) The "other computer" needs to be memory speed independent. The 6502 is a good choice, but some others can also be "stalled" waiting for slow memory.

2) The requirements for I/O lines is a limiting factor. You'll need 8 for a data bus and several for control (figure on 4 to 6). That leaves less than 16 for the address bus (from the "other computer"). Probably the best way to handle this is to use a couple of 8-bit bus buffers that can also do the translation from 5V to 3.3V like the 74HCV244 (or something like that). The Propeller can read these 8 bits at a time.

3) Consider using Ramtron FRAM for the emulated memory. If you have enough I/O pins, you could use SPI for the I/O and the Propeller could drive it at maximum clock speed (20MHz). It comes in a 64K byte size and runs off 3.3V. You could have more than one of these attached with only one additional line for each.

potatohead

Was really thinking about older game machines. Those generally have limited addressing, which really downplays the I/O limits. Those things have carts that typically have 2 - 16K of ROM in them. A propeller, presenting as a ROM, would make for some interesting possibilities.

The other area I was just thinking about was expanding older devices. Have the prop present as the other device, but do some extra things.

Any even rough guess at code size just for the interface? Say an area of the HUB contains the code to be presented to the other machine. Maybe 8K, just for discussion. Would the amount of propeller specific interface code exceed the remaining memory space? I've just no idea of scale as that's not any kind of code I've ever written.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!

Mike Green

For speed, the I/O routines would be written in assembly. This is really a pretty simple task and I can't imagine the code taking much room. I imagine that you'd have at least 1/2 the HUB RAM available (16K). If you want a larger address space, you could use the HUB RAM for paging buffers

deSilva

Some thoughts:
(a) Start-up.
You could leave the "main chip" in reset by a pull-down, until an active Prop wakes it up by pulling that line high. I used this technique in my still to be finished Multi-Prop project.

(b) Simulating a memory bus protocol should take between 20 to 100 COG instructions. It should be feasible to answer within 40 ticks to a read/write strobe = 600 ns.
Main issue is the async HUB wheel: No chance to avoid "bad luck" = 22 ticks
A software "cache" inside the COG is no improvement, as it will need much longer than a HUB access...

Ale

potatohead:

I had in mind for a while, doing this for a not-yet-done 68020 board that I wanted to build. But I thought that an ATMega8 or ATMega16 would be enough for 1 or 2 Kbytes of code. In This case, the 68020 can be made wait due to its async natures. A Propeller can do all this with easy.
May be you can interleave the addresses and use several COGS to serve successive addresses if one COG is "too slow" for it. In a 1MHz Bus you may get 40 instructions worth of Propeller Power, instead of 20 Much better if you have to access the HUB. Maybe 4 COGS can be used for even greater speeds...