Phil:
Ok here we go: Take a situation were one COG has to send a request to the other, and the other has to respond and the timing has to be very predictable ....
While this situation may be true, if a driver places an extraordinary demand on a user, users may seek a different solution. Drivers should be written so that most customers can use them. It's Ok to experiment since that can produce break-away advances, but certain expectations remain.
Requiring that 2 cogs be started consecutively is much easier than requiring every Nth cog be started. A Propeller "bus" speed may be multiplied by having 2 consecutive COGs read the data. I know of at least one VGA driver that reads and displays data from SRAM with 2 COGs back to back without resorting to special circumstances.
I have been able to read/display TV data from the PropellerPlatform SDRAM before with the driver I posted without seeing tearing or other artifacts. One of my recent computer crash miseries ended that adventure though.
I have purchased 6 more propellers, and a extra prop plug today. One of the Propellers is going to be dedicated to this challenge. Now hopefully I can get the rest of the money together to get that SDRAM board. I should note though that the existing SDRAM driver for that board works with my SDRAM.
Amiga clone that uses Propellers to simulate the custom HW.
That's odd. There is another chip in the world that like, the Prop, boasts multiple CPU cores, deterministic timing, a lack of dedicated peripheral hardware blocks, "software defined hardware" as it were. It will remain nameless here but let's call it "X".
Turns out that there is another Amiga project going on that uses the X chip for the peripheral hardware.
Heater:
Interesting. I had heard of the Amiga X1000, though I did not know that it was using the 'X' Microcontroller, for its custom HW. I had never actually taken the time to read the specs on the X1000. You do know that by calling it X you almost gave its name, correct?
Heater:
I should also mention that the choice of the Propeller for our design is a direct result of having started out using AVRs, the Prop is just a much better chip for the job.
You do know that by calling it X you almost gave its name, correct?
Dangerously close:)
Now I'm not sure of the point of that machine, with a PowerPC it is not much like any Amiga which had 68000. What software are you expected to run in it? Is the an emulator for old 68000 code.
For nostalgias sake a real 68000 with modern peripheral chips seems more like it.
Now I'm not sure of the point of that machine, with a PowerPC it is not much like any Amiga which had 68000. What software are you expected to run in it? Is the an emulator for old 68000 code.
For nostalgias sake a real 68000 with modern peripheral chips seems more like it.
I agree that using a 68k CPU is more sensible, though Amiga went from 68K to PowerPC in the mid 90s starting with third party CPU boards for the Amiga 4000, as such Amiga OS 4.0 and newer are PowerPC only, and most Amiga clones are based on the PowerPC CPU.
According to wikipedia Commadore never sold a PowerPC based Amiga. I didn't know about the the third party PowerPC stuff. I wonder who put the native PowerPC OS together.
Haage & Partner under license. I think that Gateway owned Amiga at that time. Also to note, Amiga has always been its own entity, Commodore owned them for a while, and then they they got passed around a bunch. I do not know who owns Amiga now.
I have decided to make the code handle using two consecutive cogs, as I wish to have as many as possible use this. This does mean that there will be two copies of the Asm code that are almost identical, with the only difference being the timing for hub access operations when communicating directly between the two.
I have decided to make the code handle using two consecutive cogs, as I wish to have as many as possible use this. This does mean that there will be two copies of the Asm code that are almost identical, with the only difference being the timing for hub access operations when communicating directly between the two.
If the difference comes down to a few values, you could use a shared variable via PAR to change the values at run time for both cogs.
jazzed:
Good idea. Thank you. All I have to do is take the portion of code that is different and load it from hub memory, using the address passed in PAR. In retrospect seems obvious, Though I did not see it for some reason.
n := cognew(@entry, @parameter)
coginit((n + 1)&7, @entry, @parameter)
If it's the latter then it's not in any way different from the original approach (m indices apart). If it's the former then you basically don't know what the difference will be (there could be cognew(s) in between) which may (or may not) make code sync a pain if not impossible depending on the requirements. Just thinking aloud here ...
c := cognew(@xvdrvbegin, @varcode)
if c < 7
coginit((n+1), @xvdrvbegin, @varcode)
This works now. And you are correct that it is not functionally different than the using two consecutive cogs with static values for cog num. On the other hand, it does allow for a little better cooperation with the idea of using cognew. The other option would be something like:
Using the second method (that I mentioned in my last post) I would have to include a bit of extra asm to do some calculations and then replace that by some of the driver code from hub mem.
c := cognew(@xvdrvbegin, @varcode)
if c < 7
coginit((n+1), @xvdrvbegin, @varcode)
What about c == -1 (no cog free)? Or the code is run from cog N with cog N-1 being the first one available? Lot's of IFs & Co but you know how those things creep up the moment you dismiss them as unlikely
Shows that I do not use spin much . I had assumed that the < operator worked on unsigned values (in which case -1 would be much greater than 7). And yea it is heavyweight, I would be interested to here your solution.
Why do you say that the second assignment is to early? It would have to be before the second cog is relaunched.
Re: comparison, SPIN only uses signed arithmetic, PASM whatever you want, i.e. un/signed. As for my solution, I'd use what works best. If this means ID and ID+4 then that's it. That said, for everyday programming I do use cognew.
Also, there is the issue of the command cog ID relative to your worker cogs. I assume that the workers read from par periodically. Which means you may get sync problems if the command is written between 1st and 2nd rather than 2nd and 1st. This obviously only applies when there is a gap between them. Had this one bite me occasionally.
Are you referring to when the two cogs are consecutive, and you have to add an additional 16 clocks to keep synchronized in some cases?
No, what I meant is that if you have cogs N and N+1 then there is no slot in between that the command location could be written in a way that cog N+1 picks it up before N, i.e. a new command is always picked up by N first, then N+1. OK. If there is a gap (M, M+3) then there is the potential that cog M+3 picks up the command before M (assuming M being the primary cog). This depends on how you pick your command cog. If it's not M+1 or M+2 then there isn't an issue. If it is and it's always the same then you might want to consider changing primary and secondary cog (assuming your setup uses this concept). If it's random, e.g. M+2 or M+5 then you may have a problem.
Kuroneko:
Thank you your insight is very helpful. Hopefully I get all figured out sooner than later. So far I have no difficulty displaying a line of any arbitrary pattern, witch can be repeated, I have no trouble reading SDRAM, I have no trouble writing ram (during the HBlank and VBlank periods) and I have no trouble communicating. Now it comes to displaying more than 64 colors, getting the timing correct for the cogs to switch functions on the scan line boundary, doing sprites, and getting enough drawing/ updating functions to be usable. I have realized that the number of pins used by this board makes any additional IO almost imposable. The address pins could be multiplexed in a future version, with out sacrificing performance (thanks to the needed wait states), this would free up some pins (this last is just a thought aloud).
Well here is the concept for bitbanging out more color. We are limited to 2bit intensity DAC, and a 2 bit color purity DAC of 2 bits.
Lets get dirty, we can use 4 intensities of 2 color purities each plus a manual rotation of the signal in increments of 7ns gives thirty two hues so: 32 * 2 * 4 = 256 possible colors.
3.579 MHz color burst
Delays in color freq for color:
~14ns = yellow 1.00
~28ns = yellow 0.66 red 0.33
~42ns = red 0.66 yellow 0.33
~56ns = red 1.00
~70ns = megenta 0.33 red 0.66
~84ns = megenta 0.66 red 0.33
~98ns = megenta 1.00
~112ns = megenta 0.66 blue 0.33
~126ns = blue 0.66 megenta 0.33
~140ns = ?
~154ns = blue 1.00
~168ns = blue 0.66 cyan 0.33
~182ns = cyan 0.66 blue 0.33
~196ns = cyan 1.00
~210ns = cyan 0.66 green 0.33
~224ns = green 0.66, cyan 0.33
This is my intent (to use bitbanging through the VGA to produce an NTSC signal directly).
Comments
Requiring that 2 cogs be started consecutively is much easier than requiring every Nth cog be started. A Propeller "bus" speed may be multiplied by having 2 consecutive COGs read the data. I know of at least one VGA driver that reads and displays data from SRAM with 2 COGs back to back without resorting to special circumstances.
I have been able to read/display TV data from the PropellerPlatform SDRAM before with the driver I posted without seeing tearing or other artifacts. One of my recent computer crash miseries ended that adventure though.
Write it with no worries. When it works, and we all see the worth of it, then it can be improved. Eager to see your efforts David
And on a Propeller, with this crowd? It can always be improved.
Full color, at any significant resolution is a very stiff challenge. Let the man work for it.
I have purchased 6 more propellers, and a extra prop plug today. One of the Propellers is going to be dedicated to this challenge. Now hopefully I can get the rest of the money together to get that SDRAM board. I should note though that the existing SDRAM driver for that board works with my SDRAM.
That's odd. There is another chip in the world that like, the Prop, boasts multiple CPU cores, deterministic timing, a lack of dedicated peripheral hardware blocks, "software defined hardware" as it were. It will remain nameless here but let's call it "X".
Turns out that there is another Amiga project going on that uses the X chip for the peripheral hardware.
Some kind of strange parallel universe is going on here. http://a-eon.com/index.html#
Interesting. I had heard of the Amiga X1000, though I did not know that it was using the 'X' Microcontroller, for its custom HW. I had never actually taken the time to read the specs on the X1000. You do know that by calling it X you almost gave its name, correct?
I should also mention that the choice of the Propeller for our design is a direct result of having started out using AVRs, the Prop is just a much better chip for the job.
Dangerously close:)
Now I'm not sure of the point of that machine, with a PowerPC it is not much like any Amiga which had 68000. What software are you expected to run in it? Is the an emulator for old 68000 code.
For nostalgias sake a real 68000 with modern peripheral chips seems more like it.
Good idea. Thank you. All I have to do is take the portion of code that is different and load it from hub memory, using the address passed in PAR. In retrospect seems obvious, Though I did not see it for some reason.
Looks rather heavyweight but at least you only use what you're given.
Why do you say that the second assignment is to early? It would have to be before the second cog is relaunched.
Are you referring to when the two cogs are consecutive, and you have to add an additional 16 clocks to keep synchronized in some cases?
Thank you your insight is very helpful. Hopefully I get all figured out sooner than later. So far I have no difficulty displaying a line of any arbitrary pattern, witch can be repeated, I have no trouble reading SDRAM, I have no trouble writing ram (during the HBlank and VBlank periods) and I have no trouble communicating. Now it comes to displaying more than 64 colors, getting the timing correct for the cogs to switch functions on the scan line boundary, doing sprites, and getting enough drawing/ updating functions to be usable. I have realized that the number of pins used by this board makes any additional IO almost imposable. The address pins could be multiplexed in a future version, with out sacrificing performance (thanks to the needed wait states), this would free up some pins (this last is just a thought aloud).
Lets get dirty, we can use 4 intensities of 2 color purities each plus a manual rotation of the signal in increments of 7ns gives thirty two hues so: 32 * 2 * 4 = 256 possible colors.
3.579 MHz color burst
Delays in color freq for color:
~14ns = yellow 1.00
~28ns = yellow 0.66 red 0.33
~42ns = red 0.66 yellow 0.33
~56ns = red 1.00
~70ns = megenta 0.33 red 0.66
~84ns = megenta 0.66 red 0.33
~98ns = megenta 1.00
~112ns = megenta 0.66 blue 0.33
~126ns = blue 0.66 megenta 0.33
~140ns = ?
~154ns = blue 1.00
~168ns = blue 0.66 cyan 0.33
~182ns = cyan 0.66 blue 0.33
~196ns = cyan 1.00
~210ns = cyan 0.66 green 0.33
~224ns = green 0.66, cyan 0.33
This is my intent (to use bitbanging through the VGA to produce an NTSC signal directly).
http://forums.parallax.com/showthread.php?112146-composite-NTSC-sprite-driver&p=800114
MOVS VSCL, #3 ' 3 PLLA per frame (4.77MHz) :active ADD :pixel0, d4 ' note: doesn't take effect until next loop :pixel0 WAITVID lineram+0, #%%012 ' Y+U Y-V Y-U ADD :pixel1, d4 :pixel1 WAITVID lineram+1, #%%123 ' Y-V Y-U Y+V ADD :pixel2, d4 :pixel2 WAITVID lineram+2, #%%230 ' Y+U Y-V Y-U ADD :pixel3, d4 :pixel3 WAITVID lineram+3, #%%301 ' Y+V Y+U Y-V DJNZ $1F0, #:active ' 720 PLLA active video (240 pixels) WAITVID sync, blank ' 3 PLLA @ 0 IRE (blank) MOVS VSCL, #37 ' 37 PLLA @ 0 IRE (blank) frontporch WAITVID sync, blank JMP #nextrowThat's the core active pixel loop.