"burst" IO speed
Benedikt Rochow
Posts: 11
Ignoring the overhead of actually determing what to output from a cog, or doing somethign with the input data, how fast is the I/O pin access from a single cog?
I want to emulate an old computer in hardware - if I emulate the processor on the Propeller, I will still need to hook up a RAM chip, which would get accessed a lot. If I leave the processor (and RAM) external, I have to snoop on the processor bus all the time.
Am I interpreting the docs right:
-4 cycles per cog instruction=20 MIPS (I suddenly can't fidn this factor in the docs, but I thought I read it earlier)
-no delays for cog/IO interaction
-> if the values to put on the IO pins are laid out in cog registers, I have a 20MHz update rate
-> if the values to put on the IO have to be computed with 1 instruction each, or it takes 1 extra cycle to conditional-check a read IO input bit, I have a 10MHz update rate
Is that right?
thanks.
I want to emulate an old computer in hardware - if I emulate the processor on the Propeller, I will still need to hook up a RAM chip, which would get accessed a lot. If I leave the processor (and RAM) external, I have to snoop on the processor bus all the time.
Am I interpreting the docs right:
-4 cycles per cog instruction=20 MIPS (I suddenly can't fidn this factor in the docs, but I thought I read it earlier)
-no delays for cog/IO interaction
-> if the values to put on the IO pins are laid out in cog registers, I have a 20MHz update rate
-> if the values to put on the IO have to be computed with 1 instruction each, or it takes 1 extra cycle to conditional-check a read IO input bit, I have a 10MHz update rate
Is that right?
thanks.
Comments
· I'm curious about the uP you intend to emulate and the emulation process itself. Do you interpret instructions on the fly or precompile to Propellor code (or something I haven't thought of)?
-phar
You might look at a recent thread: http://forums.parallax.com/forums/default.aspx?f=25&m=126990
This issues of fast, and frequencies, and a couple ways to look at them are discussed.
Jim C
The processor in question is a Z80. If I were to emulate the processor itself, it would be on-the-fly, since it's a small home computer that loads in new software all the time.
The plan so far was to use an SX or two, with a Z80 chip (at least 10Mhz, to allow for easy sqeezing of the emulated 3.59MHz operation whenever there's no memory contention) and a RAM chip large enough to both provide RAM for the machine and a video buffer. This video buffer would be needed because the original machine is PAL and there are color-resolution enhancements that depend on precise video timing.
I'd never really considered larger processors with noticeable amounts of RAM because there's still never enough. The SX programming system is the only one I own (apart from a Z8 setup from a Circuit Cellar contest that's so hard to deal with that I never even finished my entry for that contest) - with the exception of a little SX-based chip-testing console I'm going to sneak in at work, this is all strictly for hobby purposes, and with limited time for this hobby comes a limited budget. The Propellor still doesn't have enough (there should be 16k original-ROM-replacing RAM, 48k or 128k original RAM, and 12k of video RAM), but it ought to be enough RAM to handle the video and the fake ROM, if my code stays small enough (which it should). I like the lack of needing to buy a programmer, but I still need to read some more before taking the plunge: more serious than I/O bandwidth is probably the question whether the main RAM can be accessed quickly enough to allow writing the equivalent of PAL video while reading out a VGA display. I haven't looked at the "video" logic of the cogs at all and whether it's geared towards local RAM only or also main RAM.
In realtime?
I very much doubt that it can be done on the Propeller.
(I wrote my first assembly programs on a Sinclair ZX Spectrum -- 'Speccy' to afficionados -- and have an intimate knowledge of how good it is)
I have a small program I write to test a processor's assembly-language, and which consists of 3 loops inside each other(two of them are from 255 to 0 and the third is from 63 to 0). The Z80 will finish this in about 7 seconds, while a similarly-clocked COG in a Propeller will do it at about half that time.
The main reason it is faster is because of ONE instruction the DJNZ which has been radically improved compared to the one in the Z80.
So, you probably say, the Propeller can run at 80MHz, and have 8 COGs...
True, but you want to emulate the processor itself, and that means also getting the timing to be accurate, and not just on executing the instructions, but also the timing on the assorted I/O-pins, and THAT is something I wouldn't even dream of doing.
Do you plan on using dynamic RAM?
remember that the Z80 also generates a DRAM Refresh on the one clock cycle it is busy decoding the instruction and the bus would othervise be free.
Also, the Z80 has a whopping 158 instructions to emulate.
(Somewhere in the region of 750 if we count all variations, like LD to and from different registers, setting different bits with the BIT instruction and so on. In fact, they had to add 3 different Prefix Bytes to get room for them all)
Edit:
If you REALLY want to emulate a Z80-based machine, take a look at the Sprinter computer. It is based on a Z80, but it also has an Altera PLD, chich can be altered in site by software so that the machine can emulate just about any Z80-based computer. (it's most commonly used to emulate different versions of the Speccy or the Sam Coupe)
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Don't visit my new website...
Post Edited (Gadgetman) : 6/1/2006 7:46:06 PM GMT
· I'm still interested in the emulation process. I was thinking that I would use a jump table indexed by the instruction code. To get any kind of speed, the run-time routines would probably have to fit in the local· memory of a cog. Have you tried coding a few emulation routines?
-phar
Instead they had the ULA, which handled a lot of stuff.
To put it short, you had a block of memory where you specified foreground/background colour for each character square, and another where you drew the graphics. (Yes, you had bitmapped graphics, but only character-based colours)
Then it was up to the ULA to handle reading the memory and converting it to a PAL picture(or NTSC on the Timex sinclair) and to allow/disallow the CPU to use the graphics memory depending on where in the picture-sweep it is.
Also, the graphics memory was 'a bit' weirdly arraigned...
First the top line of the top row of characters, then the top line of the SECOND row of characters, all the way until the top line of the eight row of characters, before beginning on the second line of the first row of characters, and so on umtil the eight line of the eight character row, which is followed by the first row of the ninth line. and so on...
(I think I got it right... couldn't find my documentation)
Anyway, this had potential on the 16KB model as you could set FG/BG colours for the bottom third of the screen to BLACK, and use the graphics memory for that part of the screen for data or even machine code.
Unfortunately, though, an emulator will have to replicate this memory-map or any program trying to do anything with graphics will go haywire.
BTW: Phar, I wrote that the Z80 has 158 instructions, or over 750 variations of them. You can't fit a complete jump-table into a single COG...
You could probably use the PreFix scheme and pass the Prefixed instructions to other COGs, but the fact is that even for non-prefixed instructions, it would be a tight fit.
now, what makes it a little bit easier, is that the Z80 has a well-documented microcode, which should make it easier to translate the instructions into Propeller code.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Don't visit my new website...
It would use the first line, then the next line was about 1/3 of the way down the screen.
I believe it was akin to the Apple II memory layout for hi-res graphics.
I actually wrote a "space-invader" type game on the TS2068 in 100% assembly language. Ahh the days when I had all the time in the world (10th grade I think)...
Bean.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Cheap 4-digit LED display with driver IC·www.hc4led.com
COMING SOON "SD DATA LOGGER" www.sddatalogger.com
"I reject your reality, and substitute my own." Mythbusters
·
It's over a decade since I last tried any assembly-language coding on it.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Don't visit my new website...
· I didn't think the emulator would fit in local· memory of one cog, I pretty much mentioned that to provide a criteria for dropping the project. You could probably see the handwriting on the wall by coding a handfull of instructions. I had also thought of the principle of multiple jump tables, but, as you say, it doesn't look doable. If you were VERY lucky and condition codes mapped from the Propellor to the Z80 perfectly, the runtime for a typical ALU opcode might be
·· 1. do the Propellor equivalent.
·· 2. jump to a set of routines which map the proper codes and stick the······ result in·the appropriate emulated register.
· But, given what you've pointed out, even that seems hopeless.
-phar
So expensive in fact that when it became obviouse that the first batch (many thousand) had a flaw, they didn't junk them, but instead designed an electronic circuit to fix the problem.
more on that here:
http://www.crashonline.org.uk/16/sinclar2.htm
And of course:
http://en.wikipedia.org/wiki/ZX_Spectrum
It IS possible to emulate the Z80, but the question is wether or not you can get a decent speed on it.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Don't visit my new website...