How many Xmem boards are on the drawing board?

Ron Sutcliffe

In another thread I stuck my neck out and said that we should have some standards for addressing Xmem.

Paul Baker some time back produced his memXpand design.

Bill Henning changed the face of propeller with LMM, with a new OS to come.·

Heater has moved the game along now with his CPM and Zilog.

We now have two version of C, both of which need XMM

A lot of work by people is based on a fragmented approach to Xmem.

Clusso99 glued together his overlay object with contributions by others most notably Hippy and PhiPi. The ramBlade approach is to directly address Xmem using two Props(forget the micro loader ATM)One Prop with 24LC256(standard PPB) is used to load the other prop (with no 24LC256) with a SDboot program. Both Props then continue to boot their respective operating systems independently of each other. Prop one is left with lots of I/O Pins and 6 cogs whilst the other Prop handles Xmem, SDCard, drivers plus CPM or some other operating system. The first prop deals with the outside world.. The second Prop manages storage (Ram or SD) and some user OS. This may not be the way Ray intended to use it, but for me the hardware is the starting point not the drivers.

Jazzed’s approach is to use a Single Prop and latch some address lines saving some pins for I/O. Ram access speed comes from the use of two adjacent cogs synchronized to handle the additional extraCode required to latch some address lines, an idea which was suggested in another thread by Linus.I suspect Steve will now be looking at accommodating the SDcard to save pins.

·The Hydra Card is again under the microscope. It is beginning to look like the extra gates can be squeezed into the CPLD.

None of the people involved need to do this. They do it because it is there to do. HEY take a step back. What’s a couple of weeks, or is it all about the Prop Expo?

At the end of the day, carefully thought out, we will end up with a board, which everyone wants to use.

I can only try.

Ron



Post Edited (Ron Sutcliffe) : 5/30/2009 3:38:19 PM GMT

Cluso99

Ron,

Here is my opinion which is meant to be constructive. I do not wish to offend anyone. There has been too much of that lately (I am guilty too). Lively debate is good for everyone.

I am not trying to knock your suggestion that there be one standard. It would be fantastic if this could be achieved. As I stated elsewhere, this would work if there were only one type of application. Unfortunately there are multiple things that different users want to do. I want maximum speed.

I designed and built the TriBlade while others just spoke about it (excepting of course the Hydra which I see, correctly or not, as a gaming platform). I saw two areas where SRAM was needed, and I adopted two different strategies for this. I took into account both the hardware and software perspective on this. I had touted for some time that it would be preferable to use two props for lots of jobs and this was me putting my money where my mouth was, so to speak. I designed the board for hobbyists to assemble themselves, hence through hole was used almost exclusively. Personally I would rather SMT. My design and software/drivers are completely·open.

Blade #2 has directly addressed (no latches)·SRAM and SD (actually microSD) and was designed for a high speed processor without peripherals. It would use Blades #1 and #3 for intelligent peripherals. The·latch used on Blade #2 was for selecting (chip enables)·the various blocks (2 x 512KB blocks of SRAM, an SD block and a Flash block). The ZiCog and CPM emulation currently uses 6 cogs although this could be trimmed down.

Blade #1 on the other hand has latched upper address A11-A18 which are latched from A0-A7. Why you may ask are they latched on the address lines and not the data lines? Well, because it is much faster·since you do not have to change the direction of the data lines. SRAM still is directly addressed in 4KB blocks without requiring changes to the latch, which significantly slows things down. My intention for this was to give larger video ram·although code (overlay or XMM) could also be held in here. This prop also has VGA or TV and Keyboard and Mouse. No-one I know of has so far used this SRAM.

I have now designed the RamBlade (fully SMT) and the TwinBlade (fully SMT and·nearly complete). The TwinBlade is designed to be used as a SBC (single board computer) or Retro Computer. The RamBlade is·designed to plug into the Parallax Prop Proto Board (PPB) to make it the·(almost) equivalent of the TwinBlade. The intention is to run emulations such as ZiCog and CPM, MoCog and Flex, PropDos, etc. There are also some other possibilities which I am unable to discuss.

RamBlade section: By reducing the functionality of the Blade #2 on the TriBlade, I have been able to improve byte reads from 7 to 4 instructions and the writes from 12 to 8 instructions (from my recollection - it's published·on another thread). However, because of·my desire to get the maximum speed, I cannot use the standard EEPROM for booting due to probable bus conflicts. My requirement is purely random access for the most part, plus absolute speed. Latches are just not feasible, nor are CPLDs or any other logic.·I have placed the address lines A0-A18 on P0-18 and the data lines D0-7 on P24-31. This is unusual, but in examining the way the TriBlade accessed SRAM, I realised it was better to shift the data bits and not shift the address bits. This way one·SHL/SHR #24 removes the extraneous bits replacing the AND instruction and the address bits do not have to be shifted. So overall instructions are saved.

Now, Steve (jazzed) on the other hand, has opted for latches and multiple cogs to achieve speed. His objective is different. The code he is wanting to run is mostly block oriented, so small blocks can be addressed successively without changing the latch.·He has acknowledged that·random access will suffer. I have·discussed my designs with Steve offline. I will leave Steve to put the merits of his design.

I haven't discussed the Hydra as I am not very familiar with it. Certainly it will not do what I require with regard to·speed.



▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:

· Home of the MultiBladeProps: TriBladeProp, SixBladeProp, website (Multiple propeller pcbs)
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: Micros eg Altair, and Terminals eg VT100 (Index)
· Search the Propeller forums (via Google)
My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm

Bill Henning

I think that we won't end up with one design. Why?

- some boards will be optimized for random byte access, as used by emulators (Cluso99's for example)
- some for streaming bytes for video with few pins (Hydra's design, and CPLD mods to it)
- some will be somewhere in between (jazzed et al)

There are several reasons for this fragmentation:

- lack of an actual address/data bus
- pins are a scarce resource, different designs can only "afford" to use a certain number for memory
- different designs are optimized for different usage
- standardization at this point would inhibit innovation

We can think of it as the "evolution" of propeller memory boards; and due to reasons above, one size does not seem to fit all.

However, standardization is very useful, thats why Largos will have an XMEM API for applications running under it; but I am afraid that emulators and video drivers will need to be adapted to different boards. Once my macro assembler is finished, I intend to have a set of XMM macros for it to hide the differences for applications that don't need the very last cycle of performance squeezed out.

With Prop2 (and Prop1-64 if it appears) the situation will be different - we will have more pins to play with; however given different priorities for pin usage, and different needs for different uses, we will have several designs even then.

Ron Sutcliffe said...

In another thread I stuck my neck out and said that we should have some standards for addressing Xmem.

Paul Baker some time back produced his memXpand design.

Bill Hemming changed the face of propeller with LMM, with a new OS to come.

Heater has moved the game along now with his CPM and Zilog.

We now have two version of C, both of which need XMM

A lot of work by people is based on a fragmented approach to Xmem.

Clusso99 glued together his overlay object with contributions by others most notably Hippy and PhiPi. The ramBlade approach is to directly address Xmem using two Props(forget the micro loader ATM)One Prop with 24LC256(standard PPB) is used to load the other prop (with no 24LC256) with a SDboot program. Both Props then continue to boot their respective operating systems independently of each other. Prop one is left with lots of I/O Pins and 6 cogs whilst the other Prop handles Xmem, SDCard, drivers plus CPM or some other operating system. The first prop deals with the outside world.. The second Prop manages storage (Ram or SD) and some user OS. This may not be the way Ray intended to use it, but for me the hardware is the starting point not the drivers.

Jazzed’s approach is to use a Single Prop and latch some address lines saving some pins for I/O. Ram access speed comes from the use of two adjacent cogs synchronized to handle the additional extraCode required to latch some address lines, an idea which was suggested in another thread by Linus.I suspect Steve will now be looking at accommodating the SDcard to save pins.

The Hydra Card is again under the microscope. It is beginning to look like the extra gates can be squeezed into the CPLD.



None of the people involved need to do this. They do it because it is there to do. HEY take a step back. What’s a couple of weeks, or is it all about the Prop Expo?

At the end of the day, carefully thought out, we will end up with a board, which everyone wants to use.

I can only try.



Ron

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Largos - a nano operating system for the Propeller
www.mikronauts.com - a new blog about microcontrollers

Post Edited (Bill Henning) : 5/30/2009 2:40:39 PM GMT

Ron Sutcliffe

@Cluso99
I have yet to see the ideal solution for handling addressing Xmem. The more I think about it the more I like the idea of using two 2 synchronized cogs but without latching. What is wrong with the address and data combined into one long using one cog whilst the other cog handles the DIRA register maybe with the W/R strobe. The ultra high-speed cog is dropped.

@Bill, you are probably right, but I would like to crawl away and think on this. ok Bill will fix [noparse]:)[/noparse]

jazzed

Hi Ron. This is an interesting summary. To me it drives home further the impact made by Bill's LMM. I didn't know Paul had proposed any kind of an external memory solution until last week; it is relatively small (too small for external LMM) and I suppose could be useful for video buffering, but the pinout is not very efficient.

This is my fifth look at external memory solutions (three hand wired prototypes). I'll summarize these for background which may prove helpful in a search of some standard.

My first XMM attempt was a legacy "page mode" DRAM that worked great, but the interface too complicated and slow for bit-banging and the code just too big for the XMM kernel. I have an optimized ICCPROP XMM kernel that has space for 22 or less XMM fetch instructions.

My second XMM was "iiProp" started around the same time as Cluso99's SixBladeProp idea. It was based on the PropRPM board with the XMM engine on the prototype pads for up to 1.5MB of direct access SRAM. This is the board I used for getting ICCPROP XMM working. The main differences between iiProp and TriBlade are one less Prop, a parallel -vs- serial Prop-Prop interface, and the fact that I did not push hard enough to make my board fully functional.

Third came the Synchronous SRAM studies which were never prototyped, but for which I have several routed Eagle designs. This would allow big memory, be fast, and require only 9 or 10 Propeller pins. Details of this can be found in Hanno's 6.6MB/s thread. I may eventually produce the design, but decided it was too complicated to finish by PropExpo time.

Fourth, around the same time as the Synchronous SRAM study, I looked at SDRAM. SDRAM is attractive because it is generally available, offers high density, and has a burst mode that is friendlier to Propeller. In burst mode addresses do not have to be incremented for bytes to appear, but CAS line still has to toggle to get the bytes. Thing is the number of pins in the interface will not fit in a small CPLD and the state-machine for dealing with the SDRAM is fairly complex.

So now, there is the PropXMM-D40 development. Yes, Linus mentioned using multiple COGs, but that was already being considered [noparse]:)[/noparse] The idea I'm using is for the "data COG" to set and latch the high address bits and the "address COG" to start incrementing the direct address bits while the data COG reads or writes values. Using this scheme requires 16 instructions (5.0MB/s for XMM read32) without an ALE delay (15 with delay, but delay is too hard to control). A write is fairly complicated and will need about 20 instructions (4.0MB/s for XMM write32). Actually writes benefit more than reads with 2 COGs because a mask instruction is not needed for the data since the second COG emits the lower address bits on P8..13. The other thing about writes is we have to toggle the WE line to prevent corruption as address lines change. The write will use the data COG CTRA to strobe the WE signal.

I'll reveal the PropXMM-D40 software design and the ICCPROP XMM kernel soon. I have no plans for SDCARD on the module ... even uSD is too big for 0.6 inch pin spacing. One could extend the board a little, but routing those 4 extra traces is a deal breaker.

Propeller Expo is a motivating factor for me. I would like to have some tangible results to show from my constant Propeller efforts. I'll be demoing Propalyzer and I hope to have a fair XMM C demo. I have another board coming that may draw interest. Alas, my software only tool project is on hold ... sigh.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Steve


Propalyzer: Propeller PC Logic Analyzer
http://forums.parallax.com/showthread.php?p=788230

Post Edited (jazzed) : 5/30/2009 5:59:06 PM GMT

Ron Sutcliffe

I am still trying to digest the detail in the contributions. There sure is a lot going on here and in retrospect I was shooting from the hip. Bill covered all the issue so well and touched on the issue of Prop1 with 64 pins. Only dreaming, and again I have not really thought this through but, 16 or more address lines and a 32 bit wide data buss would completely change things. Accessing external ram byte by byte, packing it into a long, executing it in one LMM instruction., whilst massaging it through the hub sweet spot is daunting.

Running two Props in Parallel, is not he same as a 64 pin Prop but it has my attention ATM?

A single Prop with access to 512K of Xmem will be short on pins and cogs so two Prop will come into play. IMO
.
BTW @Clusso99 RE- NETCOMM modems, ah! I used a couple with PCanywhere to access my office PC from home. That’s going back, 20 years, maybe.

@Jazzed, Will your XMM kernel be bundled with your board, or can it be configured to run under any xmem configuration. Either way PM me when its available, C is a problem within the constraints of 32K.

Ron

Cluso99

@Ron: Started both in my garage (well actually home office)

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:

· Home of the MultiBladeProps: TriBladeProp, SixBladeProp, website (Multiple propeller pcbs)
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: Micros eg Altair, and Terminals eg VT100 (Index)
· Search the Propeller forums (via Google)
My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm

RossH

Ron Sutcliffe said...
We now have two version of C, both of which need XMM

Not true at all. If you avoid the ANSI C library (which is a real memory hog when you only have 32K to play with) then you can run useful Catalina C programs without needing XMM. And with Catalina you don't need the ANSI C library for embedded applications since Catalina provides its own basic I/O capabilities and low-level library functions using only cog ram - these take up no hub ram at run time, allowing almost the entire 32K to be dedicated to C application code.

Catalina will continue to support non-XMM propeller platforms as well as XMM ones.

Ross.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina

ImageCraft

Ross, I know Catalina is your baby et al, but I wish you stop implying directly and indirectly comparison with ICC. You have said in a few posts how Catalina may be better for floating point because it is designed since Day One to support FP, and that Catalina may be better in allocating variables etc. While they *may be* true, but honestly I doubt very much, ICC does just fine with our own optimizing register allocator and FP support. Please, boost Cataline all you like, but refrain from implying it's better than ICC, unless you have hard data.

// richard

Ron Sutcliffe

Hi Ross

I only started to play with C when Richard introduced the ICC beta version. ASM has been all I have ever needed. I first started out using the Signetics 2650 to control various types of hydraulics equipment for a client or two in the Civil Engineering field. Five years ago I was fortunate enough to find someone who wanted my business more than I did, so I took early retirement. So now its all for fun. [noparse]:)[/noparse] I have never had to share my software and it was never reviewed. C requires disciplines that I never had to learn. It was a steep learning curve over a couple of months. Now I am reasonably fluent in C, I found the 32K limit frustrating. Jazzed has always been helpful. At that time I thought he must be talking about some sort of alien gas when he mentioned Doxygen !

I did downloaded Catalina a while back and will no doubt use at some stage.

Regards
Ron

RossH

@richard,

I'm sorry if you read my email as slighting your Imagecraft C compiler (although in fact I did not even mention it). This was certainly not my intention - I was merely responding to Ron's assertion that Propeller C compilers need XMM, by pointing out that XMM is not necessary for running useful real-world C programs. I'm not sure I understand the relevance of the rest of your comments to the subject at hand (i.e. XMM).

@Ron,

I think that if there is one thing that richard and I can agree on, it is that for the Propeller to be taken seriously in the embedded microcontroller domain it needs a lot more C based libraries and applications. So use whatever compiler suits you best - but get programming in C!

Ross.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina

Cluso99

Unfortunately I have to agree - in the micro world today, designers want C. You both (Richard and Ross) are providing this, so thanks - not that I am a C programmer. I just want to see more using the prop. I will stick to pasm and occaisionally spin and maybe occaisonal C.

Signetics 2650 - haven't heard of this in such a looong time.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:

· Home of the MultiBladeProps: TriBladeProp, SixBladeProp, website (Multiple propeller pcbs)
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: Micros eg Altair, and Terminals eg VT100 (Index)
· Search the Propeller forums (via Google)
My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm

ImageCraft

Ross, normally I don't criticize other people publicly but you are so disingenuous that it's not even funny. Lets just say for argument sake, some benchmark shows that your Catalina is better than ICC, based on your history, I am betting that you will take every chance you get to mention how a free compiler is better than a commercial one. Your posting history has shown that: out of the blue, you mentioned in two different posts how Catalina may be better because of the variable allocation and FP, neither is true. In the previous post on this thread, you took care to mention only Catalina this and that. Other people, I would give the benefit of the doubt and say they are speaking only what they know, but your undertone is so strong, plus what you have written before, have no credibility with me.


// richard

heater

Hey Richard, what's going on?

Ross may or may not have made some exaggerated claims, personally I have tried to read everything from the both of you and have not noticed anything over the top either way.

On the other hand what he has done, intentionally, is to go out of his way to not tread on your turf. That is by licensing Catalina in such a way (GPL) that 99% of commercial users will not want to use it as they won't want to open source their application code. All sounds quite gentlemanly to me.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.

RossH

@richard,

I'm sorry, but I think you you are reading into my posts implications that are simply not there. I have re-read my posts in this thread (and others) several times and I can't find anywhere where I claim "only Catalina" anything. I make claims for Catalina, sure. But they are not meant to be at the expense of anyone else. And I try to speak only for Catalina. Where I don't know if something for certain, I try to point that out.

You (not me) keep bringing up the issue of FP and variable allocation. I presume you are referring to this posting in another thread, which I posted because someone had asked me the differences between Catalina and Imagecraft. Here is a summary of what I said:

Ross said...
Our LMM Kernels take completely different approaches, since I concentrated on building in things like floating point support from day one, whereas this was absent in the early versions of the Imagecraft compiler and added later (I don't know if is in part of the ImageCraft Kernel or not). Catalina provides the ability to choose between zero, one or two cogs dedicated to floating point. On the other hand, I believe Imagecraft concentrated on improving execution speed generally by sticking closely to Bill Henning's (and others) original LMM proposals, including the ability to cache small amounts of hub ram in the kernel cog to speed up execution of small loops. However, to compensate I suspect Catalina offers better support for register variables (including floating point register variables). So I would expect Catalina to be faster in some areas such as floating point, but slower in other areas. I have not run any comparisons, but if you (or anyone) cares to, I'd be happy for you to post the results here.

...

I think that Imagecraft would produce more compact code than Catalina. However, Catalina offers an XMM option to allow programs larger than 32K to execute from external RAM, so this is not such an issue. I am unaware of ImageCraft offering XMM support, but I believe they have been working on it, so if they don't offer one already I'm sure they soon will.

...

I would encourage ImageCraft (or anyone who uses ImageCraft) to respond to your question here as well. Since Catalina is completely open source, everyone has an opportunity to examine the guts of Catalina in all it's gory details - so I'm sure ImageCraft and others will know more about the differences than I do.

...

Finally, ImageCraft is a finished product, whereas Catalina is an ongoing work still very much in beta release.

...

In summary, if you want a C compiler for commercical use, then at the moment you should probably buy ImageCraft's compiler. If you are still experimenting or are a hobbyist, you may find Catalina suits you better. And it's free!

If you believe these comments are incorrect, or want to comment on this in any other way, then by all means do so. But perhaps we should continue this in the thread it was originally posted (as I invited you to do at the time) or start another.

For the record, I still have not benchmarked Catalina against Imagecraft in any respect, and I have no intention of doing so.

Ross.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina

jazzed

I really don't want to be in the middle of this but .... actually there was a slight tint in the post.

Ron Sutcliffe said...
"We now have two version of C, both of which need XMM"

To which Ross responded ...
"Not true at all. If you avoid the ANSI C library (which is a real memory hog when you only have 32K to play with) then you can run useful Catalina C programs without needing XMM. And with Catalina you don't need the ANSI C library for embedded applications since Catalina provides its own basic I/O capabilities and low-level library functions using only cog ram - these take up no hub ram at run time, allowing almost the entire 32K to be dedicated to C application code. "

ICCPROP does not require library functions to work which is implied above. It is also implied that ICCPROP is not useful without XMM ... this is not true.

I applaud you both for delivering a C compiler because "serious users" of which there are very few here demand it of a micro that will be used in serious high volume, big company products. The drama here is not very helpful. You two need to kiss and make up (maybe delete a few posts).

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Steve


Propalyzer: Propeller PC Logic Analyzer
http://forums.parallax.com/showthread.php?p=788230

RossH

@richard, @jazzed

I hereby apologize if you believe I was slighting Imagecraft C. The comments that jazzed picked up on were intended to refer only to Catalina. If you have read the documentation for Catalina you will see that in there I discuss extensively the current size of Catalina programs that use the ANSI C library, and recommend users avoid using it where possible.

That is the only point I was making. It had nothing to do with Imagecraft C.

I will repeat it in plainer language:

Catalina can currently be used to write useful C programs that don't require XMM (i.e. fit in 32K) provided you avoid the use of the ANSI C library functions (such as the stdio function printf) that currently consume a huge amount of the available memory. Catalina offers alternatives to the stdio routines that can help reduce this problem. This is being addressed slowly with each new release of Catalina. Other compilers may not suffer the same problem.


Ross.

Edit: yellow highlight removed - thanks, mpark!

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina

Post Edited (RossH) : 6/1/2009 11:46:16 PM GMT

mpark

I don't know about plainer, but yellow text on white is definitely harder to read...

I must say, it seems a bit unreasonable to me to quote Ross talking about Catalina, not ICC, and somehow read into that something negative about ICC.

I'm curious about the relative performance of Catalina vs. ICC. Ross has made a few idle speculations, but Richard seems certain that Ross is wrong ("neither is true"). Richard, do you have some actual data?

Praxis

I have not posted here in quite a while but do follow the board from time to time.

I am also of the view that Ross was not taking shots at ICC.

Anyway good effort Ross keep it going.

Cheers

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Adequatio Rei Et Intellectus

jazzed

Ya, I didn't see it at first either and looking again there is of course no mention of ICC. I am truly, very sorry that I said anything at all ... but this is not any kind of apology. I have no stake in ICC, but I've writen code for it. I'm a programmer. I like C and the many other languages I know. Some of the things I did for ICC, Ross did in a built in way for Catalina. It is good to provide a response to market interests of course.

Not trying to make a comparison, but I haven't bothered with Catalina because of the XMM load method ... this is primarily why I haven't done anything useful for Catalina ... it's not about personality or the "compiler" preference (if GNU C was available, I wouldn't bother with either one though). One preference of compiler code output does bother me though ....

I would get excited about Catalina and write code for it if there was an intel-hex or some other output I could use for XMM without needing use EEPROM. I have voiced this before, but it goes without response. I don't know why, and at this point I guess it doesn't matter. As it is I have no motivating factors to re-write C programs guaranteed to compile/run under both Propeller C variations; ICC was the only compiler when I wrote most of the Propeller specific code.

As far as a good outcome goes, I think someone else has the best opportunity to do well with LMM based products.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Steve


Propalyzer: Propeller PC Logic Analyzer
http://forums.parallax.com/showthread.php?p=788230

Post Edited (jazzed) : 6/2/2009 1:44:59 AM GMT

Ron Sutcliffe

Ross I did read the Catalina docs, albeit a couple of months ago. Your efforts will find supporters. Parallax are the real winners of course.

Anyway my focus is·looking for·better solution to xmem, and the more I think about it the more I think that a multiplexed bus handling both addressing and a 32 bit wide data bus is the way to go. The down side is that the data will have to be latched into 4 by 8 bit latches and memory arranged to provide 64K by 32bit array. DIRA will have to be toggled, in a read cycle. @jazzed, I have come full circle and latching[noparse]:)[/noparse]

Ctrl pins would be required to manage the 16 pin bus gating, 4 at this stage, hopefully 2 of the ram ctrl lines can be used. The real-estate is more complex, but this is offset by less instructions in the read and write cycles (typically....outa adr, INA, 16>> , toggle latch, INA, toggle DIRA).

Even if I don't improve through put much, the pin count comes down significantly. I am struggling with the write cycle, to avoid two additional latches. I need to get this sorted and then put it through the Quartus wringer before I can really make any claims to its efficiency and post it.

The fact that data is only transferred in longs or with less efficiency words, maybe an issue. My motivation comes from wanting to preserve the Prop pins used for I/O if possible. (Fdserial VGA + SDcard). I was hoping to use a second Prop to do the latching but it is the wrong chip for the job.


Ron

Post Edited (Ron Sutcliffe) : 6/2/2009 4:29:45 AM GMT

jazzed

Ron,

I'm attracted to a 16 bit data interface for XMM fetch-only mode. It would save at most 200ns relative to 8 bit interface for read and require a few control pins for maybe 18 total pins. A code loader would of course require write, but that's easy to do.

Thinking out loud now ....

You know, a 32 bit data interface could also be done with a CPLD assuming a "smart" eeprom like a little PIC or another Propeller (like Cluso99's TwinBlade prop-eeprom function).

This could use two 32 bit longs: one for control/address and one for data. The CPLD would perform 8, 16, or 32 bit peripheral chip select transactions based on address range decoding and handle write strobes, etc .... Any device (including a Propeller) could be used for peripherals.

Memory size could be up to 1GB (2^28*4 address, cmd protocol high bit, wr/rd bit, bus size bits), but there are non-Propeller limits of course.

Such a scheme could be handled in up to 6 instructions resulting in a raw throughput not including overhead > 12MB/s read or 16MB/s write in 1 COG with potential for bursting at higher data rates in the same way as SDRAM.

' 32 bit transactions

read32
  or    dira,   minus1
  mov   outa,   addr
  or    outa,   readctrl
  andn  dira,   minus1
  mov   data,   ina
  ret

write32
  or    dira,   minus1
  mov   outa,   addr
  or    outa,   writectrl
  mov   outa,   data
  ret

This comes with a hardware price of course in terms of real-estate, glue, and other devices. SDRAM or better technology would be a logical memory choice. You could do almost anything with such a design ... at a cost.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Steve


Propalyzer: Propeller PC Logic Analyzer
http://forums.parallax.com/showthread.php?p=788230

Post Edited (jazzed) : 6/2/2009 6:44:25 PM GMT

Ron Sutcliffe

@steve
Yep, I am sure I (or others) can make it work with 3 by 16 bit transparent latches, two to handle bi-directional latching of 16 bits of the 32 bit wide data bus, and the other to latch the 16 address lines. The high order 16 data bits would be directly connected to the 16 bi- directional bus. (P0..15). The OE on 2 high order ram chips would come into play.

Finding a solution which is optimized around a flexible system for handing longs, whilst leaving enough pins to handle the common I/O objects on a standard Prop board is where I am coming.

I don’t think commercial anymore. If a solution can be found and if someone was to make available a pre-programmed CLPD, someone like Brian could put a board and kit together for people.

There is sooo much to do.


Ron

Post Edited (Ron Sutcliffe) : 6/3/2009 3:08:18 AM GMT

Cluso99

If we remove all constraints such as..

• Size
• Power
• Cost
• and the fun in building or programming it, whatever·that is worth

then we could just use a PC to...

• emulate the prop with...
  • run under the older native assembler mode (no windows or unix, maybe DRDOS??)
  • more hub memory (no need for external drivers)
  • more cogs (maybe)

come to think about it, we would have..

• Memory galore xGB (GigaBytes)
• Super hi res VGA
• keyboard
• mouse
• USBs
• ethernet
• modem
• hard disks to xTB (TerraBytes)
• DVD read/write
• SD interfaces (on some laptops)
• printers
• multiple monitors (on some laptops)

We could even use a laptop and have it all in one box !

Alternately, we could buy a Xilinx or Altera development kit for $x,000 and just build our own propeller II like Chip is using to simulate it.

So what are we waisting our time here for ?????

Oh, back to reality

We are doing this because we enjoy it, not because we have to. And this is·Chip's motivation also. And he has·shared this·with us as well.

There will always be alternative ways of doing things, each with it's own benefits and drawbacks. Just think about this - you will have a choice

So, let's enjoy life and see what this beast (Propeller I) can really do while we wait for the Prop II.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:

· Home of the MultiBladeProps: TriBladeProp, SixBladeProp, website (Multiple propeller pcbs)
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: Micros eg Altair, and Terminals eg VT100 (Index)
· Search the Propeller forums (via Google)
My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm

jazzed

Cluso99 said...

If we remove all constraints such as.. ...
Oh, back to reality
...
So, let's enjoy life and see what this beast (Propeller I) can really do while we wait for the Prop II.

That "back to reality " made me laugh out loud [noparse]:)[/noparse] Looks like an opera singer or my 14 year old on stage.
Yup ... "get 'er done."


Ron,
Ah your idea is much clearer now. I never considered a multiplex data bus. Cool.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Steve


Propalyzer: Propeller PC Logic Analyzer
http://forums.parallax.com/showthread.php?p=788230

Ron Sutcliffe

@Ray
I thought my argument was reasonable, power, size, cost, and the fun or building were important·parts of my argument.

I would hate to start doing the comparisions.

LMM is here to stay, so not sure waht you are getting at?



Ron

Post Edited (Ron Sutcliffe) : 6/3/2009 4:33:19 AM GMT

jazzed

I wasn't exactly sure either Ron, but no doubt it was with good intentions.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Steve


Propalyzer: Propeller PC Logic Analyzer
http://forums.parallax.com/showthread.php?p=788230

Cluso99

I was trying to lighten things up a little. Nothing sinister in my comments.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:

· Home of the MultiBladeProps: TriBladeProp, SixBladeProp, website (Multiple propeller pcbs)
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: Micros eg Altair, and Terminals eg VT100 (Index)
· Search the Propeller forums (via Google)
My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm

Praxis

To be honest I have not been following this subject at all and have no idea what sort of performance is required or expected.

So is there any reason why 74HC299's could not be used for the data bus to reduce prop pin usage?

Just a random thought.

Cheers

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Adequatio Rei Et Intellectus

Ron Sutcliffe

@ Steve, Pins X to X+15 carry BOTH data and address data

Processing a write

1. Latch 16bit address via Pin x to Pin x+15
2. Write low order word via Pin x to Pin x+15
3. SHR high order word
4. Write high order word. via Pin x to Pinx+15

The read process requires the additional (mov dira, rd) and the (mov dira, wr) to toggle the DIRA register.

I still have to manage the gate logic with 4 addition pins. So there is no code to at this stage. I will post my layout and code when and if it gets sorted. Hopefully there would plenty of pins available, to handle the standard objects vga, mouse, keyboard etc. You could use additional lines to page additional ram. There would be no additional overhead and the additional paging lines would not need to be latched, but you would lose the pins of course.

@Ray, That’s fine, if I ever get this to work, maybe you can make some boards, or burn a few CPLD’s [noparse]:)[/noparse]

@Praxis I do need to post something shortly, and will. Thanks for Source Edit Lite, I am in the process of setting it up for Catalina.


Ron

Post Edited (Ron Sutcliffe) : 6/3/2009 2:02:07 PM GMT

Praxis

Hi Ron,

In the next week or so I am going to knock up an IDE that provides full support for the Catalina tools with the various command line options configurable in the IDE on a project by project basis etc.

After discussion with Ross this will known as the "Catalina Developer Studio".

Cheers

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Adaequatio Rei Et Intellectus