MOV Reverse -------- Ideas to Chip Gracey (Parallax)
Sapieha
Posts: 2,964
Hi Chip Gracey (Parallax)
It is that idea I have on Reverse Move from one LONG/Serial to other
Look On posted picture ................ That is my idea
Have some more ideas and will post them in this thread.
But only if You comment else answer to this
It is meant as break for Yours mind AS I know att if anone work with same problem to long time
that ideas will not comme
Ps. Had no time to draw that picture before (Worked on Custom Layout·for Propeller >PCB<)
To all why read this thread.
Only Write in this thread if YOU have any qualified coment on usage else mod to my ideas.
Ps. if You have Your own idea ..... Open thread for it .... And post LINK to it on my thread.
That give Chip no problems to find that.
Regards
Christoffer Jönsson
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nothing is impossible, there are only different degrees of difficulty.
For every stupid question there is at least one intelligent answer.
Don't guess - ask instead.
If you don't ask you won't know.
If your gonna construct something, make it·as simple as·possible yet as versatile as posible.
Sapieha
Post Edited (Sapieha) : 12/2/2009 10:06:38 AM GMT
It is that idea I have on Reverse Move from one LONG/Serial to other
Look On posted picture ................ That is my idea
Have some more ideas and will post them in this thread.
But only if You comment else answer to this
It is meant as break for Yours mind AS I know att if anone work with same problem to long time
that ideas will not comme
Ps. Had no time to draw that picture before (Worked on Custom Layout·for Propeller >PCB<)
To all why read this thread.
Only Write in this thread if YOU have any qualified coment on usage else mod to my ideas.
Ps. if You have Your own idea ..... Open thread for it .... And post LINK to it on my thread.
That give Chip no problems to find that.
Regards
Christoffer Jönsson
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nothing is impossible, there are only different degrees of difficulty.
For every stupid question there is at least one intelligent answer.
Don't guess - ask instead.
If you don't ask you won't know.
If your gonna construct something, make it·as simple as·possible yet as versatile as posible.
Sapieha
Post Edited (Sapieha) : 12/2/2009 10:06:38 AM GMT
1225 x 824 - 111K
Comments
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chip Gracey
Parallax, Inc.
You said "Okay. So you start with a byte, then reverse its bits, then place it into a long where the first byte goes into byte3, the second into byte2, the third into byte1, and the last into byte0.
Is that right? no
LONG 0 (Byte 0, Byte 1, Byte 2, byte 3) ...... Increment Long counter and ... LONG 1 (Byte 4, Byte 5, Byte 6, byte 7) and so on.
Same If I receive WORD's
LONG 0 (Word 0, Word 1) ..... Increment Long counter and ... LONG 1 (Word 3, Word 4)
If I receive LONG's ...... Simply increment LONG counter
Ps. It is for all fast communication with devices that send else will receive bytes/Words/Longs in reversed order with LSB first
Regards
Christoffer J
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nothing is impossible, there are only different degrees of difficulty.
For every stupid question there is at least one intelligent answer.
Don't guess - ask instead.
If you don't ask you won't know.
If your gonna construct something, make it·as simple as·possible yet as versatile as posible.
Sapieha
Post Edited (Sapieha) : 11/29/2009 6:40:44 AM GMT
So, what you are thinking about is an instruction that progressively writes bytes or words into cog registers, with possible endian reversal. Is that right?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chip Gracey
Parallax, Inc.
I think Sapieha is looking to build a series of bytes, with bit reversal, in longs - essentially treating the long destination registers as pseudo-byte addressable.
I think it is a great idea, but I think bit reversal should be optional, and the reverse - unpacking the bytes in a long to bytes would also be useful.
This would allow byte-wide memory reads to be assembled to longs efficiently - currently I have to jump through many hoops and use three cogs to get 20MB/sec burst reads on Morpheus, this would allow two cogs to do the same (without bit reversal), and three cogs would allow 40MB/sec (if I got cute with interleaving).
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.mikronauts.com Please use mikronauts _at_ gmail _dot_ com to contact me off-forum, my PM is almost totally full
Morpheusdual Prop SBC w/ 512KB kit $119.95, Mem+2MB memory IO board kit $89.95, both kits $189.95
Propteus and Proteus for Propeller prototyping 6.250MHz custom Crystals run Propellers at 100MHz
Las - Large model assembler for the Propeller Largos - a feature full nano operating system for the Propeller
Yes Rereda my previous post ... I added an PS.
If You call it edian ... YES
My thinking on it is .... If You build an extra 128 Longs area added to COG as extra space ...
We need simple but good instructions to move data from all devices that send Bytes/Words .... As I said in reverse BIT order
It can speed upp seriallisering and spare much place in COG as istead for use many instructions to it ... We can have only 2 one for Transfer from Receiver REGISTER and One to transfer that area to TRANSMIT register for serial sed/receive
Regards
Christoffer
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nothing is impossible, there are only different degrees of difficulty.
For every stupid question there is at least one intelligent answer.
Don't guess - ask instead.
If you don't ask you won't know.
If your gonna construct something, make it·as simple as·possible yet as versatile as posible.
Sapieha
SETPAK··#n· 'configure bit reversal and byte/word/long directions
SETPAK··D·· 'configure bit reversal and byte/word/long directions
SETPAKA·D·· 'set byte pack addres, lsb ignored for words
GETPAKA·D·· 'return byte pack address
PAKB····D·· 'pack byte (incs/decs PAKA by one)
PAKW····D·· 'pack word (incs/decs PAKA by two)
UNPAKB··D·· 'unback byte
UNPAKW··D·· 'unpack word
This mainly comes down to a bunch of muxes and some steering logic with a counter.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chip Gracey
Parallax, Inc.
I Know ..... BUT it have big posiblites to handle BYTES/WORDS in COG samt spare much place for more usable program things.
I don't know how many bits You must use fro INSTRUCTION and ADDRES .... but some function You describe if You have spare bits can be placed directly in that instruction.
Type one bit fro Direct/Reversal move, one bit if it will pack BYTES else WORDS 2 bits if it even can handle LONGS
As I know You already use Indyrect addres registers and to that need's 2 of them SOURCE and DESTINATION for initialisation of POINTERS to correct places
BUT all if You will give us SUPER COMPUTER in one chip.
That can be used in most of INDUSTRIAL CONTROL Industry
Regards
Christoffer J
where 'nnnnnnn' is the "FIFO long address", and 'bb' is the byte/word within that long? (lowest bit 0 for words)
This would be perfect for a lot of applications (fast sampling, fast string handling, packing/unpacking video scan buffer)
Presumably there would be a way to get {RD|WR}{LONG|WORD|BYTE} to work on the FIFO area (including quad long read/write)
Extra points if the source/destination byte/word could be any of the bytes/words in the source/dest register...
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.mikronauts.com Please use mikronauts _at_ gmail _dot_ com to contact me off-forum, my PM is almost totally full
Morpheusdual Prop SBC w/ 512KB kit $119.95, Mem+2MB memory IO board kit $89.95, both kits $189.95
Propteus and Proteus for Propeller prototyping 6.250MHz custom Crystals run Propellers at 100MHz
Las - Large model assembler for the Propeller Largos - a feature full nano operating system for the Propeller
"This would be perfect for a lot of applications (fast sampling, fast string handling, packing/unpacking video scan buffer)
Presumably there would be a way to get {RD|WR}{LONG|WORD|BYTE} to work on the FIFO area (including quad long read/write)
Extra points if the source/destination byte/word could be any of the bytes/words in the source/dest register..."
As I understand, I agree it is confusing to remember the endianness of the hub and cog and video register,
and whether byte[noparse][[/noparse]somelong] == long[noparse][[/noparse]somelong] while it's <= $000000FF,
and extra confusing that cogs use 9-bit parts of longs also, the instruction, source, destination, and literal,
but yet access to hub are bytewise, wordwise, and longwise. I never noticed I was confused though, maybe
just stumped for a while when I began to question which bits might not be where I thought they should be.
And I'd look first in the Spin and the hub, and wonder if the @ symbols either worked or didn't work at random.
Only recently did I , for the first time , solve a problem by using a MOVD on a JMP to get an indirect(?) jmp,
instead of JMP PAR or JMP TEMP or JMP #TEMP or something like that which I'd done before. Sometimes the
wrong way seems to work for a while but later doesn't. I'm not RTMing at the moment so it seems that
hub access might be the only time and place in Cogs that Bytes and Words exist somewhere, somehow.
Just thinking and working it out I guess. I think I have to make a poster of how it is, so that I won't need to
work it all out again every time. It must already be simple, because it is Not a bowl of spaghetti full of loose ends.
It's just RISCy the same way the SX and PIC are, and they're Different than all the consistently 8-bit chips,
the 8080,6800,6502, 8088... 6809,z80,80x86. Hmmm. That x86 seems to be the most arbitrarily confusing of all.
Mention the oscillator again.....
jr
Yes .... I will .... But first will I have some pictures to demonstrate that idea
Regards
Chj
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nothing is impossible, there are only different degrees of difficulty.
For every stupid question there is at least one intelligent answer.
Don't guess - ask instead.
If you don't ask you won't know.
If your gonna construct something, make it·as simple as·possible yet as versatile as posible.
Sapieha
Okay, moving on.· Recently, I was considering an idea that seems at least somewhat related to this thread, even though the idea doesn't involve communications-related bit manipulations.· Rather, I was trying (on paper, anyway) to do some fairly tedious manipulation of 24-bit color pixel data, wherein RGB data was to be mapped to 32 bits in a way that required lots of masking and shifting to rearrange the original bits in a very specific way (I'll spare you the details, and I admit that this goal was fairly esoteric). This bit manipulation would need to be repeated for each pixel of a QVGA image space.· After some calculation and estimatation, I realized that all the required manipulation was going to slow the overall display updating process significantly, possibly rendering the plan unfeasible.
This thread got me thinking about that again as the difficulties of my goal have much in common with dealing with endianess and bit-reversing and so on.· I kind of like the direciton that this thread is going.· We can see how hardware-based bit manipulation like the kinds being discussed would save us a lot of grief and speed certain tasks up considerably.· That by no means guarantees that such hardware-based manipulation will make it into silicon, but at least it's being considered in terms of benefits and costs.· This led me to consider the more general case (described below).· I sure this idea can't be novel:· perhaps graphics processors have this ability, and I'd guess something similar must be in use by telephone companies to route their numerous signals (cross or crossbar switches, perhaps).· Nevertheless, I'll throw the idea out here anyway for what it's worth.
I was thinking, instead of limiting ourselves to some very specific bit manipulations, why not build-in more general-purpose bit-manipulation that would potentially cover a wide-range of needs.· For example, one possiblity would be to make a flexible mapping circuit with corresponding instructions that could map 32 input bits to ANY pattern of 32 output bits, no matter whether the pattern seemed to have any reason or not.· That is, any particular bit in the input long could be moved to any desired bit position in the output result.· One could "scramble/unscramble" a long in any way desired, all basically in one fell swoop.· Moreover, a bit could be copied to more than one bit location in the output result, if needed.· Further, more than one input bit could be mapped to the same output bit, such directed input bits being OR'ed together in much the same way as, for example, the output pins are merged together from various cogs in the current Prop, only here everything would be internal.· Alternately, result bits could be set low (or possibly even high), effectively overiding the input bits.· And all this would happen in, say, 1 or 2 clock cycles.· And this functionality could either be effected at hub-level or cog-level (the latter being preferable, of course, but with a higher cost).·
Such mapping would be controlled not by shifting and a few masks, but by an internal "table" of 32 map-control longs, one for each bit in the original long to be converted/mapped to a result long.· Each map-control long in the so-called table would correspond to exactly 1 of the 32 input bits, wherein each map-control long the would direct a single bit to any one or more of the 32 output bits in the long result, wherein, again, more than 1 input bit could be mapped to the same output bit, if desired.· Essentially, a potential circuit for accomplishing this would involve an input long coupled to 32 map-control longs via AND gates, with the outputs of the AND gates being fed to OR gates and then on to the final output long (see the attached diagram).
The costs for one particular design to do this would require 1024 bits of some kind of storage for each mapping "table" (1 long for each bit in the input long = 32 bits x 32 bits = 1024 bits) + another 2 longs to hold the input long and the output long, for a total of 1088 bits.· In addition, this would require 32 32-input OR gates, and 32 x 32 = 1024 AND gates.· It would also require quite a bit of signal routing on various layers and related vias.· However, most of this circuitry could be located together in one area of the chip.· There'd be no need to route lots of signals through existing circuitry.· An exception might exist for getting the input data to and from the mapper circuitry.· If this is too unweildly, perhaps 1 or 2 "registers" could be set aside in the cog's special register area, that is, if the mapping circuitry was implemented on the cog-level.· Speaking of which, if such functionality were given to each cog, then, obviously, the foregoing logic would have to be replicated once for each cog (meaning 8 times).·
On the instruction level, the following three instructions could be something like:·
··· MAPSET <map-ctrl table reg>, <map-ctrl val>··· 'needs to be done ~32 times
··· MAPMIX <cog reg to manipulate>
··· MAPOUT <returns mapping result>
MAPSET would set 1 of 32 of the map control longs in the map control table by writing any cog register into the desired register of the map control table.· The map-ctrl value could also be an immediate value, since it will only range from 1..32.· Anyway, this instruction would usually be executed 32 times (but just one time as a group) to setup the map control table.· Or perhaps some kind of bulk move could be done.·
MAPMIX would apply the entire, previously setup map control table to any cog register supplied as the argument.· If a special purpose cog long were being used to hold the input long, then one would use MOV to set the register before using MAPMIX to apply the mapping, with MAPMIX not requiring an argument is such case.· Yes, it seems that the tricky part, circuit-wise, is getting the input long to the map control table area (tricky for me, anyway).
MAPOUT would return the result from the last applied mapping (initiated by MAPMIX) by copying the output result long to any cog register as specified by the argument.· Alternately, the output result long could be copied to a special purpose register in cog RAM automatically after using MAPMIX, in which case a MOV instruction could be used to access the value.· Also, perhaps it would be possible to use the same 32-bit register for both the input value and the output result, which, in the case cog special purpose registers being used, would save one register.· Wherever the input/output register(s) are located, perhaps the gate delays involved during conversion/mapping would be long enough to allow the result to go back into the same register from which the input long was taken.· But hopefully not too much time would be involved, because it would be nice for the result to be available by the next clock cycle, or perhaps the clock cycle after next.·
Well, this idea is only 4-hours old for me (including a couple hours to draw the schematic...in OpenOffice, no less, as I have no schematic capture software yet).· As such, I'm probably overlooking something big that will cause all of this to fail, so I beg you indulgence.· Moreover, I'm really new to the Propeller (my first and only microcontroller), and have only written a handful of SPIN and PASM test programs, nothing at all consequential.· It's now time for regular life (including non-electronics-related work) and I don't know when I'll be able to check back, so I think I'll send this now and take a big chance of looking totally foolish.· But even if I'm overlooking a deal-breaker problem, perhaps this post will stimulate some interesting responses.· At the very least, I hope you can see the goal of having fast and flexible and convenient bit manipulation, even if this method won't accomplish it or it is not particularly feasible.· And, again, even if it is, it may be far too costly to implement, or the effort involved (and costs) might not justify the utility of the functionality if such functionality would be rarely needed.· I'll let others speculate on that.· But it sounds to me like a powerful mechanism, consistent with the design philosophy of the Propeller.
A potential circuit is shown below, wherein only the circuitry necessary to do 4-bit manipulation is shown for simplicity.· The actual circuit would have 32-bit input and output registers instead of 4-bit ones, and each control register would be 32 bits wide instead of 4, meaning that there would be 1024 AND gates instead of 16 and 32 OR gates instead of 4.· Oh, BTW, MAPSET is the input long (register) and MAPOUT is the output result (register).· Apologies for the inconsistency.· Note, in order to guarantee that an output bit came out as zero, each corresponding bit in the table of control registers would also have to be set to zero, in order to block any one bits in the input long from coming through (the AND gates would thus block them).· Also, the current schematic doesn't allow forcing an output bit to 1, but I believe that such could be implement by ANDing a third (not previously mentioned) control register with the input long register before feeding the results into the AND gates of the current circuit.· If the current schematic isn't fatally flawed already, perhaps I'll draw up (at a later date) another one with such added functionality.· Okay, that's it for now.· Apologies for the long post.· I'd break it out as a separate thread, but I would have never of thought of this in this way without the current thread by Christoffer (Sapieha).· I'll delete this post or move it if this post causes a problem.· I would request that you PLEASE DON'T QUOTE THIS POST IN ITS ENTIRETY (or please edit your post if you do quote all of it by accident to cut it down).· Also, this is my first attempt at putting this into words, so I reserve the right to edit this post later for technical clarifications and small grammar/style changes as I have no time to check it now.· Thanks for your attention and may we keep up the mutual inspiration.
Well-reasoned argument and a euridite diagram, as well. Good work!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
JMH
This thread I open for that ideas.
BUT as I said in start will not have off topic discusions here ........ As I can see ...... Your met TOPIC ......(Technical) Ideas for Chip.
Regards
Christoffer
Ps ... And as You said..
This is Chip that decide if it is usable
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nothing is impossible, there are only different degrees of difficulty.
For every stupid question there is at least one intelligent answer.
Don't guess - ask instead.
If you don't ask you won't know.
If your gonna construct something, make it·as simple as·possible yet as versatile as posible.
Sapieha
Post Edited (Sapieha) : 11/30/2009 1:34:54 PM GMT
My orginal post in other thread.
BUT I have any other question ..... What about THAT at You delate from Prop II low frequency oscilator
and istead WASTE 3 pins (2 pins XTal inputs and 1 BATERY Voltage pis) and ad POSIBLITY to add 32.xxx KHz crystal extern. That can give us pricise RTC
clock for all type of Frequency/Periods masurements.
And In All programs that ned Correct Frequency from HIGH XTal oscilator ..... We can masure it with help
of that TRC cklock and give it to program that need it.
USABLE ito set VGA work frequencies and other that things without KNOW what XTAL any one have used
(Overklocked Prop II) can still RUN all on board Development programs without problems.
Now look on Picture attached to this post
THAT can give us...
Inbuild single RTC ..... that can count from hundreds of second to 1 to 7 days
.... Rest of bits in long use to count simply how much days else weeks elapsed from start of RTC.
In orginal post I write That YOU can delate slow Oscilator but if YOU can manage 32.xxx KHz to share switchning to PLL it can be fast oscilator.
On same picture I have some improvements to system counter CNT.
With that RTC and aditions to CNT it is posible to me calculate all type of avarages in Frequency masurements, Periods in incoming signals, Masure XTal frequence to adjust VGA-TV-SERIAL drivers to meet specifications without be wory what XTal frequency is used.
And I'm sure it have many other uses
Regards.
Christoffer J
It would however be nice to maintain time to 10ms resolution (ie have hundredth of second available)
I forgot mention that to that if Posible I will have WAITon RTC 1sec-/10-/100
Regards
Christoffer J
More ideas to mods for CNT.
Look on attached picture
Ps.
Have litle question to YOU?
It is posible YOU bump my thread every time YOU have READ my new idea (no neds for comments only type READED else USABLE/NOT USABLE)
That I know if I can post more else YOU not will have more.
Thanks and Regards
Christoffer J
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chip Gracey
Parallax, Inc.
Thanks VERY much.
Now I know if it is idea to hold this thread alive
Regard
Christoffer J
You said.
"Your last suggestion seemed to be for a timeout on WAITPEQ/WAITPNE. Is that the case? I will implement a timeout, but I'm not sure how the interface will be yet."
Not only TIME Out.
If You look carefuly on Picture
It will give us more precice timing control in programs that Propeller I can suply os now.
Istead of use many instructions to read CNT then substract old value from it.
We can in one instruction Wait on MATCH/NO MATCH .... CNT Comparator have correct answers on CNT counter timings
for FAST timings that needs in some Control aplications.
Regards
Christoffer J
A couple of comments:
1) Ideally more than just a simple FIFO. It would be really nice if there could be cog-pointers for them, optionally auto-inc and auto-dec (depending on setting), selectable for byte/word/long use.
If done this way, it would also allow using it as a 128 level LONG stack, 256 level WORD stack, and a 512 byte string manipulation buffer. (3 such pointers would be perfect, but 2 would be ok)
Now if these pointers could also address the regular 512 longs of the hub memory... drool. While I am dreaming, a small offset would be nice... then it could also be used for local variables, and for structure packing/unpacking/access.
2) I love an RTC count, especially if it could be kept running while the rest of the Prop was off. How about using tenths of seconds? And a "Turn on Propeller at this time" register?
Think of the power savings if the Prop could turn itself off, and schedule itself to be powered on...
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.mikronauts.com Please use mikronauts _at_ gmail _dot_ com to contact me off-forum, my PM is almost totally full
Morpheusdual Prop SBC w/ 512KB kit $119.95, Mem+2MB memory IO board kit $89.95, both kits $189.95
Propteus and Proteus for Propeller prototyping 6.250MHz custom Crystals run Propellers at 100MHz
Las - Large model assembler for the Propeller Largos - a feature full nano operating system for the Propeller
On RTC idea .... It is important to have that LAST READ register.
That give us avarage time for time Propeller was OFF.
To posiblity to AUTO adjust RTC to corect date efter every Inactive state.
Regards
Christoffer J
Counter suggestions & timeouts in waitxxx instructions
The·additional 128 longs (fifo/etc)
Barrel shifter and additional instructions
I like Sapeiha's suggestions and Chip's new instructions. I·wonder if there is some more·simple and·useful functions.
I find that I am regularly rotating, and'ing and or'ing data. What if the rotate and shift instructions could do some of the and'ing?
The rotate and shift instructions (ROR, ROL, SHR, SHL, RCL, RCR) only use the lower 5 bits, so we could use the upper 4 bits·to select·other options.·What could we do...
So how would this work..
·· SHL· dest, #%uvss_rrrrr·· 'u=reverse, v=set/clear, ss=size 0(32)/8/16/24,·rrrrr=shift no of bits to shift/rotate.
The destination would be shifted rrrrr bits left, and the new bits to the·right are cleared (as normal). The resultant bits·on the right (rrrrr plus size 32/8/16/24) would remain unchanged. Any other bits to the left would be set/cleared depending on the v bit. The u bit would cause a reversal of the bits specified in ss.
·· RCR· dest, #%uvss_rrrr
The destination would be rotated with carry right. So the data is shifted rrrrr bits to the right and the incoming bits on the right are set to the carry (as normal). The resultant bits on the left (rrrrr plus size 32/8/16/24) would remain unchanged. Any other bits to the right would be set/cleared depending on the v bit. The u bit would cause a reversal of the bits specified in ss.
So basically, what I am saying, is that you set a size according to the number of bytes you are interested in, and the other bits (with the exception of bits shifted in (being forced·in by·the carry or 0 by shift) can be set/cleared in the one instruction. The bits specified would be reversed if the u bit were set.
The same would also work for the source being in a memory location (i.e. not immediate).
I am unsure how much logic this would take.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBlade,·RamBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: CPUs Z80 etc; Micros Altair etc;· Terminals·VT100 etc; (Index) ZiCog (Z80) , MoCog (6809)
· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm
would be nice to have the following doable in 1 instruction:
problems I see is 32bit squared is 64 bit then mod with 32bit gives 32 bit result. also carry flag should be set to least significant bit of x. If we could do in 1 instruction then encryption could be as easy as
mov y,0
//repeat 32 times
bbs x,m
rolc y,#1
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
24 bit LCD Breakout Board now in. $21.99 has backlight driver and touch sensitive decoder.
I have ben talk with Cluso99 and it was not perfectly clear to him how That RTC will be build.
That give me mistake tha maybe You can't understand me.
If You have questions ... No problems to ask.
Have one to addition to that RC posiblity
If posible and You will build in that RTC in Propeller ii ... Is it posible have like writable register added to it and Compare system that give us alarm FLAG.
That it is no ned fro ALARM after so many Yers that RTC can count ... can some MSB bits can be used as that flags (READABLE)
Regards
Christoffer
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nothing is impossible, there are only different degrees of difficulty.
For every stupid question there is at least one intelligent answer.
Don't guess - ask instead.
If you don't ask you won't know.
If your gonna construct something, make it·as simple as·possible yet as versatile as posible.
Sapieha
Have one question to You
Now in Propeller I we have LOOK instruction to see that one CGO write before other can read.
It is much wor for YOU to have MEMORY arbiter That in read time from one COG look Read from that addres to time other COG write new data.
With other words ....... WRITE before READ system and trough to addres that will read that memory position.
In most cases it are suitable fro most programs
Regards
Christoffer
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nothing is impossible, there are only different degrees of difficulty.
For every stupid question there is at least one intelligent answer.
Don't guess - ask instead.
If you don't ask you won't know.
If your gonna construct something, make it·as simple as·possible yet as versatile as posible.
Sapieha
AFAIK Chip is allowing Quad long accesses to hub, block transfers, address incrementing, as well as shortening the accesses to 1 per 8 clocks (down from 16 clocks). I would think the extra work involved to do reads and writes on opposite edges, if possible, would just be too complicated. Effectively we will be getting 1 long per 2 clocks. Also, wouldn't we lose determinism?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBlade,·RamBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: CPUs Z80 etc; Micros Altair etc;· Terminals·VT100 etc; (Index) ZiCog (Z80) , MoCog (6809)
· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm