Revisiting XMM Mode Using Modern Memory Chips

Wingineer19Wingineer19 Posts: 5
edited 2019-06-15 - 07:23:32 in Propeller 1
Greetings Everyone:

I'm a retiree and a newbie here, so I now have the time to ponder some of the great mysteries of the Universe. Like XMM mode on the Prop1 for example.

Of course as Engineers we never really retire, so here goes this project...

I'm using the Parallax Project USB Board: https://www.parallax.com/product/32810

I've been looking over various memory schemes developed for the Prop1, and have settled on duplicating the PMC since it involves the smallest amount of Board space using the fewest number of Pins and chips.

Check out these little jewels I now have in my hot little hands:

512KB SRAM: http://www.issi.com/WW/pdf/IS62-65WVS5128GALL-BLL.pdf
4MB FLASH: http://www.issi.com/WW/pdf/25LP-WP032D.pdf

I've already installed these two chips onto the Project Board. Instead of following the PMC convention of using Pins P0 to P7 to communicate with these chips, I've done the following instead:

No Change: P31 - Prop Rx Console Port
P30 - Prop Tx Console Port
P29 - EEPROM SDA
P28 - EEPROM SCL

QPI RAM SPI FLASH SPI
Mode Mode Mode


Added: P27 - "D3" = SIO3 = HOLD HOLD#/RESET#)
P26 - "D2" = SIO2 = DNU WP#
P25 - "D1" = SIO1 = SO SO
P24 - "D0" = SIO0 = SI SI

P23 - SCLK (Common To SRAM and FLASH)
P22 - RAMCS (Selects SRAM)
P21 - FLCS (Selects FLASH)
P20 - SDCS (Selects SD Card)

Right now I don't have the SD Card holder installed, and don't plan on using it for this exercise anyway, so I'm assuming all references to the SD Card can be ignored.

I wrote a program using SimpleIDE that reads and writes to the SRAM. The code starts out in SPI mode then commands a switchover to SQI mode. Afterwards, starting at memory location 0x00000 it writes a byte to that location, reads it back, then compares. It then increments to the next memory location and repeats until the loop is completed. This works perfectly. I haven't yet modified the code to attempt the same with the FLASH chip.

The SimpleIDE no longer offers an XMM compile option. I assume PropGCC still does using command line switches, but I haven't tried it yet.

Since I'm lazy today and like using the GUI interface, I went with Catalina running Code::Blocks to compile the Sumeria.c program in the demo folder. But first, I modified the PMC_XMM_DEF.INC file to reflect the following changes in conformance with the Pinouts listed above:
'============================= XMM DEFINITIONS =================================
'
' XMM Base Address. Catalina currently requires one contiguous block 
' of XMM RAM - Note that this is the internal hardware address, not 
' the address the Catalina XMM Kernel uses:
'
XMM_BASE_ADDRESS = $0000_0000   ' XMM adddressing from 0
'
' XMM RW & RO Base Addresses - Note that these are the addresses used
' by the Catalina XMM Kernel - they typically start AFTER the last
' Hub address:
'
XMM_RW_BASE_ADDRESS = $0000_8000 ' Read-Write Base address
XMM_RO_BASE_ADDRESS = $0008_8000 ' Read-Only Base address
'
' XMM RW & RO Sizes (in bytes):
'
XMM_RW_SIZE = $0008_0000         ' Read-Write Size
XMM_RO_SIZE = $0040_0000         ' Read-Only Size
'
' The following constant determines the number of longs used in the
' cache cog index - it can be reduced (e.g. to 6 or 5) if the XMM API 
' is so large it needs more space even in the cache cog (e.g. for 
' QUAD FLASH boards):
'
CACHE_INDEX_LOG2 = 6            ' log2 of entries in cache index
'
' PMC QUAD SPI RAM Definitions (NOTE you also need to set the symbols 
' defined below these pin definitions to appropriate values): 
'
QSPI_VDD    = -1                ' PIN (PMC) - see below to enable
QSPI_VSS    = -1                ' PIN (PMC) - see below to enable
'
QSPI_CLK    = 23                ' PIN (PMC) Common Clock
QSPI_SCEN   = 22                ' PIN (PMC) SRAM Chip Enable
QSPI_FCEN   = 21                ' PIN (PMC) FLASH Chip Enable
QSPI_SDCEN  = 20                ' PIN (PMC) SD Card Chip Enable
'
QSPI_SIO3   = 27                ' PIN (PMC) \
QSPI_SIO2   = 26                ' PIN (PMC)  | MUST BE CONTIGUOUS
QSPI_SIO1   = 25                ' PIN (PMC)  | AND IN THIS ORDER 
QSPI_SIO0   = 24                ' PIN (PMC) /
'
SSPI_SI     = QSPI_SIO0         ' PIN (PMC)
SSPI_SO     = QSPI_SIO1         ' PIN (PMC)
'
XMM_DEBUG_PIN = 11              ' PIN (PMC) Used only for debugging
'
' Define this to enable applying power to the QSPI_VDD & QSPI_VSS Pins 
' (i.e. if they are connected to Propeller pins, and not directly to the
' appropriate power rails):
'
'#ifndef QUAD_POWER_PINS
'#define QUAD_POWER_PINS
'#endif
'
' Since Homespun/Openspin have no general "#if" capability, we cannot tell 
' whether or not we have to shift bits left or right to make the nibbles align
' with the pins QSPI_SIO0 .. QSPI_SIO3 when outputting data - so we have 
' to explicitly define whether or not we need to shift each nibble left 
' or right (but since the lower nibble would never have to be shifted 
' right, we only have three possibilities to worry about):
'
' Define this symbol if the lower nibble has to be 
' shifted LEFT for output (i.e. QSPI_SIO0 is > 0):
'
'#ifndef QUAD_LOWER_NIBBLE_LEFT
'#define QUAD_LOWER_NIBBLE_LEFT
'#endif
'
' Define this symbol the upper nibble has to be 
' shifted LEFT for output (i.e. QSPI_SIO0 is > 4):
'
'#ifndef QUAD_UPPER_NIBBLE_LEFT
'#define QUAD_UPPER_NIBBLE_LEFT
'#endif
'
' Define this symbol if the upper nibble has to be 
' shifted RIGHT for output (i.e. QSPI_SIO0 is < 4):
'
#ifndef QUAD_UPPER_NIBBLE_RIGHT
#define QUAD_UPPER_NIBBLE_RIGHT
#endif

'========================== END OF XMM DEFINITIONS =============================
'


That being done, I then had Catalina compile the Sumeria.c which equated to this command line:
catalina sumeria.c -lc -lm -C SMALL -C QUICKSTART -C PMC -C TTY -C CACHED_1K

Catalina responded with:
Catalina compiler 3.13

code = 25564 bytes
cnst = 3220 bytes
init = 252 bytes
data = 1292 bytes
file = 63176 bytes

OK, great. I then ran the build_utilities program, told it that it was using a QUICKSTART board along with the PMC board, set the cache settings for 1K for both FLASH and SRAM, and told it to build the bootloader for SRAM.

Then, I ran the Payload utility: payload SRAM sumeria -I

Catalina responded:
Using Propeller (version 1) on port COM3 for first download
Using Secondary Loader on port COM3 for subsequent download

Excellent, then it presented the Interface screen and then -- Nothing. No response.

I went back and reconfigured the build_utilities to create the bootloader for FLASH instead.
Then ran Payload again: payload FLASH sumeria -i
Using Propeller (version 1) on port COM3 for first download
No secondary loader found on any port

Bummer. But for this test I was wanting to load the SRAM only and execute, which is what the first payload attempt above was about, but to no avail.

I would like to look at the XMM config files for PropGCC and attempt to compile and run this program using it.

But before I head too far down this rabbit hole, I want to make sure my hardware setup is correct.

Is there a Byte boundary issue that comes into play? Because my current scheme has the D3 to D0 lines in the Nibble right below the one for the Rx,Tx,SDA,SCL, with my Control signals in the Nibble right below the one for D3 to D0.

Like I said, this scheme works fine with my code, but it may not be "legal" with the XMM drivers available for both Catalina and PropGCC?

If the Byte boundary is an issue, would this work:

QPI RAM SPI FLASH SPI
Mode Mode Mode


Added: P23 - "D3" = SIO3 = HOLD HOLD#/RESET#)
P22 - "D2" = SIO2 = DNU WP#
P21 - "D1" = SIO1 = SO SO
P20 - "D0" = SIO0 = SI SI

P19 - SCLK (Common To SRAM and FLASH)
P18 - RAMCS (Selects SRAM)
P17 - FLCS (Selects FLASH)
P16 - SDCS (Selects SD Card)

If the Byte boundary isn't an issue, would this be acceptable:

P27 - SCLK (Common To SRAM and FLASH)
P26 - RAMCS (Selects SRAM)
P25 - FLCS (Selects FLASH)
P24 - SDCS (Selects SD Card)

QPI RAM SPI FLASH SPI
Mode Mode Mode


Added: P23 - "D3" = SIO3 = HOLD HOLD#/RESET#)
P22 - "D2" = SIO2 = DNU WP#
P21 - "D1" = SIO1 = SO SO
P20 - "D0" = SIO0 = SI SI


But if the Byte boundary is an issue, would this be acceptable:

P23 - SCLK (Common To SRAM and FLASH)
P22 - RAMCS (Selects SRAM)
P21 - FLCS (Selects FLASH)
P20 - SDCS (Selects SD Card)

QPI RAM SPI FLASH SPI
Mode Mode Mode


Added: P19 - "D3" = SIO3 = HOLD HOLD#/RESET#)
P18 - "D2" = SIO2 = DNU WP#
P17 - "D1" = SIO1 = SO SO
P16 - "D0" = SIO0 = SI SI

I'd appreciate your thoughts and tips on this issue before I plunge over a cliff on this, only to find out there's some Byte boundary issue at play I hadn't considered.

Thanks,

Jeff


PS: Let's see if I can attach my code to this:


Comments

  • I guess my ramblings above were really directed to RossH for the Catalina Compiler, and Jazzed, David Betz, and any other developers who worked on the PropGCC Compiler.

    If I use the Propeller Memory Card arrangement as a template, but modify it to use a 512KB SPI/SQI SRAM chip and a 4MB SPI/SQI Flash chip with the following Pin arrangement, will it be compatible with your respective PMC XMM memory drivers (assuming, of course, I modify the CFG files to match the new pin settings):

    P27 - "D3" = SIO3 = (HOLD On SRAM) ( HOLD#/RESET# On Flash)
    P26 - "D2" = SIO2 = (DNU On SRAM) (WP# On Flash)
    P25 - "D1" = SIO1 = SO On Both SRAM And Flash
    P24 - "D0" = SIO0 = SI On Both SRAM And Flash
    P23 - SCLK (Common To SRAM and FLASH)
    P22 - RAMCS (Selects SRAM)
    P21 - FLCS (Selects FLASH)
    P20 - SDCS (Selects SD Card)

    Or will this arrangement NOT work regardless of whatever settings are done to the respective PMC CFG files?

    Based on my experiments so far, I'm beginning to suspect that this arrangement will NOT work...

    This brings up the question as to should the Chip Select and Clock signals be listed first, followed by the Data Bus:

    P27 - SCLK (Common To SRAM and FLASH)
    P26 - RAMCS (Selects SRAM)
    P25 - FLCS (Selects FLASH)
    P24 - SDCS (Selects SD Card)
    P23 - "D3" = SIO3 = (HOLD On SRAM) ( HOLD#/RESET# On Flash)
    P22 - "D2" = SIO2 = (DNU On SRAM) (WP# On Flash)
    P21 - "D1" = SIO1 = SO On Both SRAM And Flash
    P20 - "D0" = SIO0 = SI On Both SRAM And Flash

    Or is there also a Byte boundary issue where each of these Pins must slide down by 4 to the next whole byte (i.e. starting at P23 instead of P27)?

    Thanks.




  • IIRC I wrote the drivers for Ross to use the 512KB SRAM on my RAMBlade pcbs.
    Alas, they are parallel bytewide SRAMs, not SPI/QSPI.
    BTW I used Catalina in a commercial product, so I know it can work with XMM.
    My Prop boards: P8XBlade2, RamBlade, CpuBlade, TriBlade
    Prop OS (also see Sphinx, PropDos, PropCmd, Spinix)
    Website: www.clusos.com
    Prop Tools (Index) , Emulators (Index) , ZiCog (Z80)
  • As far as I know, the version of PropGCC that is distributed with SimpleIDE can still do XMM. However, SimpleIDE itself has had all XMM support removed. You'll have to use the command line tools if you want to do XMM. PropGCC comes with drivers for SPI flash chips that will probably work with these newer chips as well. I think I wrote a quad SPI driver at one point but I'm not sure it was all that much faster than regular SPI. Here is the configuration file for the DNA board that supports both SPI and quad SPI.
    # dna.cfg
    # for the DNA board
    
    clkfreq: 80000000
    clkmode: XTAL1+PLL16X
    baudrate: 115200
    rxpin: 31
    txpin: 30
    
    sd-driver: sd_driver.dat
    sdspi-do: 0
    sdspi-clk: 1
    sdspi-di: 2
    sdspi-cs: 3
    
    # cache geometry - 128 * 64 = 8192 byte cache
    index-width: 7      # 2^7 = 128 cache lines
    offset-width: 6     # 2^6 = 64 byte cache lines
    cache-geometry: ({index-width} << 8) | {offset-width}
    
    [sqi-sram]
    load-target: ram
    sio0-pin: 22 
    clk-pin: 26
    sram-cs-pin: 27
    xmem-driver: sqi_sram_xmem.dat
    xmem-param1: ({sio0-pin} << 24) | ({clk-pin} << 8) | 0x01
    xmem-param2: {sram-cs-pin} << 24
    
    [spi-sram]
    mosi-pin: 22 
    miso-pin: 23
    clk-pin: 26
    sram-cs-pin: 27
    xmem-driver: spi_sram24_xmem.dat
    xmem-param1: ({mosi-pin} << 24) | ({miso-pin} << 16) | ({clk-pin} << 8) | 0x21
    xmem-param2: {sram-cs-pin} << 24
    
    [spi-flash]
    miso-pin: {sdspi-do}
    clk-pin: {sdspi-clk}
    mosi-pin: {sdspi-di}
    flash-cs-pin: 4
    xmem-driver: winbond_spi_flash_xmem.dat
    xmem-param1: ({mosi-pin} << 24) | ({miso-pin} << 16) | ({clk-pin} << 8) | 0x01
    xmem-param2: {flash-cs-pin} << 24
    
  • One problem with PropGCC XMM mode is that the interface to the "cache drivers" changed between the version of GCC that is distributed with SimpleIDE and the one that is in the main branch of the current PropGCC repository. Parallax asked that we make it possible to run XMM code in more than one COG at the same time and that required some refactoring. However, they never released that new version of PropGCC and then later dropped XMM entirely.
  • I guess my ramblings above were really directed to RossH for the Catalina Compiler, and Jazzed, David Betz, and any other developers who worked on the PropGCC Compiler.

    Hello Wingineer. I just saw this thread. I'll take a closer look in the next day or two.

    Ross.
    Catalina - a FREE ANSI C compiler for the Propeller.
    Download it from http://catalina-c.sourceforge.net/
  • There's this fast 512K 32-bit wide multi-port RAM that's available. I think the part number is P2X8C4M64P and it should be available in the next few months. The beauty about this "memory chip" is that it comes with eight 32-bit CPUs embedded with their own local RAM and 64 smart I/O to play with :)

    Sure, it's the P2 but it is a one-chip and cheaper solution than a P1 and slow external memory.

    Tachyon Forth - compact, fast, forthwright and interactive
    useforthlogo-s.png
    --->CLICK THE LOGO for more links<---
    P2 +++++ TAQOZ INTRO & LINKS +++++ P2 SHORTFORM DATASHEET
    P1 +++++ Latest binary V5.4 includes EASYFILE +++++ Tachyon Forth News Blog
    Brisbane, Australia
  • Sure, it's the P2 but it is a one-chip and cheaper solution than a P1 and slow external memory.
    But we love our "oldtimers"!
    :-P
    ◁ propeller-wiki ▷ ◁ FastSpin ▷ ◁ DK-E ▷ ◁ :-D ▷ ◁ Stay OmmmmmmPtimistic! ▷ ◁ No Source – No Go! ▷ ◁ Help Spin at RosettaCode.org ▷ ◁ Why Asimov's Laws of Robotics Don't Work ▷ ◁ DNA is a four letter word. ▷
  • yeti wrote: »
    Sure, it's the P2 but it is a one-chip and cheaper solution than a P1 and slow external memory.
    But we love our "oldtimers"!
    :-P

    True, and the P1 is simpler hardware-wise too but that's where I would draw the line because once it is no longer "simpler" then it like trying to option up an old mini or Altair with modern parts. Whatever you do, it's still a clunker and loses any appeal or nostalgia value it may have had. So the option exists where you could interface the P2 as a fast and cheap 512K customisable SRAM to the P1, either in some parallel or serial fashion. You could and it would make more sense than some of these other awkward memory chips out there, but then that is kind of like how the Prop gets used as a peripheral to some 8-bit micro, it just doesn't make any sense.


    Tachyon Forth - compact, fast, forthwright and interactive
    useforthlogo-s.png
    --->CLICK THE LOGO for more links<---
    P2 +++++ TAQOZ INTRO & LINKS +++++ P2 SHORTFORM DATASHEET
    P1 +++++ Latest binary V5.4 includes EASYFILE +++++ Tachyon Forth News Blog
    Brisbane, Australia
  • it just doesn't make any sense.
    Sense is not a criterium when it is hobby!
    Be tolerant!
    ◁ propeller-wiki ▷ ◁ FastSpin ▷ ◁ DK-E ▷ ◁ :-D ▷ ◁ Stay OmmmmmmPtimistic! ▷ ◁ No Source – No Go! ▷ ◁ Help Spin at RosettaCode.org ▷ ◁ Why Asimov's Laws of Robotics Don't Work ▷ ◁ DNA is a four letter word. ▷
  • yeti wrote: »
    it just doesn't make any sense.
    Sense is not a criterium when it is hobby!
    Be tolerant!

    "Non"sense it is then :)

    Tachyon Forth - compact, fast, forthwright and interactive
    useforthlogo-s.png
    --->CLICK THE LOGO for more links<---
    P2 +++++ TAQOZ INTRO & LINKS +++++ P2 SHORTFORM DATASHEET
    P1 +++++ Latest binary V5.4 includes EASYFILE +++++ Tachyon Forth News Blog
    Brisbane, Australia
  • yeti wrote: »
    it just doesn't make any sense.
    Sense is not a criterium when it is hobby!
    Be tolerant!

    "Non"sense it is then :)
    Equally wrong.

    ◁ propeller-wiki ▷ ◁ FastSpin ▷ ◁ DK-E ▷ ◁ :-D ▷ ◁ Stay OmmmmmmPtimistic! ▷ ◁ No Source – No Go! ▷ ◁ Help Spin at RosettaCode.org ▷ ◁ Why Asimov's Laws of Robotics Don't Work ▷ ◁ DNA is a four letter word. ▷
  • yeti wrote: »
    yeti wrote: »
    it just doesn't make any sense.
    Sense is not a criterium when it is hobby!
    Be tolerant!

    "Non"sense it is then :)
    Equally wrong.

    If I wanted to have fun on an old system and needed 512K SRAM with a custom interface then I would seriously consider using a P2 just for that very purpose.

    Please bear in mind the tone in my replies, it is not critical but I take into consideration that the OP is a newbie here and might not be totally aware of the many options that are available.
    Should we do him a disservice because we feel we need to be politically "tolerant"? I think not since we are far more open and friendly than that.
    We are simply musing about ways and means because the OP has posted onto an active and public forum which by its very definition is "a meeting or medium where ideas and views on a particular issue can be exchanged."
    I exchange my ideas and views because I am trying to be helpful in this regard.


    Tachyon Forth - compact, fast, forthwright and interactive
    useforthlogo-s.png
    --->CLICK THE LOGO for more links<---
    P2 +++++ TAQOZ INTRO & LINKS +++++ P2 SHORTFORM DATASHEET
    P1 +++++ Latest binary V5.4 includes EASYFILE +++++ Tachyon Forth News Blog
    Brisbane, Australia
  • David BetzDavid Betz Posts: 13,277
    edited 2019-06-15 - 14:25:42
    Ross: Do you expect to have an XMM mode for P2 in Catalina? I'm sure there will be people who run out of code space even with 512K of RAM especially if they are using big graphics buffers.
  • Thanks for the replies.

    I guess, so far, nobody has any heartburn with this physical pin mapping:

    P27 - "D3" = SIO3 = (HOLD On SRAM) ( HOLD#/RESET# On Flash)
    P26 - "D2" = SIO2 = (DNU On SRAM) (WP# On Flash)
    P25 - "D1" = SIO1 = SO On Both SRAM And Flash
    P24 - "D0" = SIO0 = SI On Both SRAM And Flash
    P23 - SCLK (Common To SRAM and FLASH)
    P22 - RAMCS (Selects SRAM)
    P21 - FLCS (Selects FLASH)
    P20 - SDCS (Selects SD Card)

    It's wire-wrapped so I can change it if necessary. No biggie.

    Additional Comments:

    -Yes, I'm aware of the forthcoming P2 chip. I'm aware that Chip has been working on designing one since nearly the time the P1 was released. I've seen some threads on the P2Hot effort as well as the various FPGA platforms several of you have been using to test the P2 design.

    -Sure, the P2 is the solution to the memory problem. Throw in the smart pins, CORDIC solver, interrupts, and 64 pin I/O interface and you have a very impressive microcontroller. I look forward to getting one once there's a choice of project boards available.

    -I think it's unfortunate that Parallax removed the XMM option from SimpleIDE. Granted, the vast majority of users will likely operate under CMM because of memory restrictions. But keeping XMM as an option within the GUI for us crazy folks would have been nice. Glad to see that the underlying PropGCC compiler still supports it via the command line.

    -Speaking of SimpleIDE, one feature I would really like on the next release (if there is one) is the ability to choose the installation folder. Right now it installed in the C:\Program Files(x86) folder and I would really prefer to have it in a C:\Compiler folder where I installed the Catalina and CCS compilers.

    -I suspect David Betz is correct: Someone, sometime will want an XMM capability for the P2. (Slowly raising my hand)...

    -Yeah, the P1 experimentation is a hobby right now. Since I don't have a P2 system, I'm wanting to push the P1 to its limits. A man can't just sit around waiting for a new toy :)

    -I want to know if the P1 can handle communication with a uBlox GPS receiver, a WiFi radio, and provide a user interface to the operator, using the full-duplex serial drivers. Pretty sure it can since there won't be a lot of math involved, just mainly repackaging the data. But there will be lots of Menus available, which will eat through lots of RAM. Hence the exploration of XMM Memory.

    -I'll continue to experiment with the current setup. I resorted to a simple program that repeatedly prints "Hello, World!" to the screen (at least it does under CMM). Right now I just want to dump the code to the 512KB SRAM and run it from there in XMM mode. The Flash experiment can come later. So far, I've gotten through the Catalina XMM compile process, and two-stage payload process, but I get nothing on the screen when complete. I haven't tried PropGCC yet but will shortly.

    Thanks again for your comments. Please keep them coming. More is better.


  • Hi
    When you say-
    there will be lots of Menus available, which will eat through lots of RAM. Hence the exploration of XMM Memory.

    I get the impression from 'menus' that you want to read in blocks of text (or even an image) and ask the user to select an option. If this is the case then any external memory - (flash or sd) can be rapidly accessed and displayed on screen or terminal without exotic code. Menus in that sense are just static text. Trying to run 'code' from external memory is where the complication comes in.
    But
    I just want to dump the code to the 512KB SRAM and run it from there in XMM mode

    shows the intention to run code from external memory- not necessary if all you want to do is pull text from external memory and display it on your output device. So I am a bit confused.

    I expect I have completely misunderstood- but just saying...

    Dave
  • Tritonium,

    Regarding your first point:

    You are absolutely correct that blocks of Menu text can be stored in external memory, read out, then sent to the terminal for display without going the XMM route.

    Furthermore, the Menu text could be stored in either the SPI Flash memory or on the SD card and grabbed and displayed when needed.

    However, I would be more inclined to have them stored in the Flash memory rather than SD card. Initial loading of the Flash memory could be done by having my code read it from the SD card then storing it in Flash. That way the program could run afterwards without the need for an SD card installed.

    But note that most of these Menus will display live raw and formatted data, so they aren't just static Menus requesting a user input.

    I would have to write functions to display the static portions and intermix them with live data as well.

    Not all that hard to do, but not as easy as just using some printf() statements, either.

    Regarding your second point:

    My existing code is already at 25KB using the CMM model, and that's without
    Menus. I have yet to add the remaining GPS data structures, the GPS uplink and downlink commands and parsing, command structures, the radio uplink and downlink structures, decoding, repackaging, uplink and downlink functions, display outputting and formatting, etc, etc. I'm confident that I will quickly run out of Hub RAM when I start adding these.

    For comparison, many years ago, when I did something like this in my former life as a Project Leader developing a GPS tracking system for a military customer, I used a PC/104 stack running FreeDOS on an x86 CPU with separate boards for the GPS receiver and radio. The code to make it all happen was nearly 300KB. And that was after I removed a bunch of features from it. With those additional features the code was somewhere around 450KB.

    Now, I'm exploring how much of this capability could be done using a dedicated microcontroller board instead of a PC/104 stack.

    Out of curiosity I want to see if I can do something with similar Menus and features using the Prop1 and low cost COTS GPS receiver and radio just as a test. A starting template for future possibilities if you know what I mean. If the Prop1 can't handle it I'm pretty sure the Prop2 could.

    So, combining the aforementioned, upcoming, big expansion in the code, along with the Menus, I want to try to do everything using XMM memory.

    If XMM works, great. If it doesn't, then I'll have to explore workarounds. Or wait for the Prop2 boards to hit the market and see if it would work.

    In the meantime, I'm pressing forward. If nothing else, it will be an educational experience as I learn more of the intricacies of the Prop1.

    Hopefully this clarified things...
  • Hello Wingineer

    I won't have time today to look any deeper today, but on a first glance it seems you know about the PMC XMM support files and have started modifying them. The modifications you have made to PMC_XMM_DEF.INC are a start. However, I would suggest you go with your second proposal, as it is closer to the original PMC pin arrangement - i.e.
    P27 - SCLK (Common To SRAM and FLASH)
    P26 - RAMCS (Selects SRAM)
    P25 - FLCS (Selects FLASH)
    P24 - SDCS (Selects SD Card)
    P23 - "D3" = SIO3 = (HOLD On SRAM) ( HOLD#/RESET# On Flash)
    P22 - "D2" = SIO2 = (DNU On SRAM) (WP# On Flash)
    P21 - "D1" = SIO1 = SO On Both SRAM And Flash
    P20 - "D0" = SIO0 = SI On Both SRAM And Flash
    

    There are no byte boundary issues that I am aware of - I am recommending this mainly in case there are any undocumented assumptions in the PMC XMM code concerning the order of the pins. I am not aware of any, but there could be some in there.

    The main advice I can give you at this point is to get your modified PMC_XMM files working in isolation from the rest of Catalina. To do this, in the "utilities" folder there is a stand-alone XMM RAM Test program that you can use to test your modified PMC files. See The files README.RAM_Test and RAM_Test.Spin. Also, note there is a section in the Catalina Reference Manual called "A Description of the Standard Catalina XMM API" which you should read.

    Once you have your XMM RAM working in the RAM Test program, Catalina should work.

    Ross.
    Catalina - a FREE ANSI C compiler for the Propeller.
    Download it from http://catalina-c.sourceforge.net/
  • yeti wrote: »
    yeti wrote: »
    it just doesn't make any sense.
    Sense is not a criterium when it is hobby!
    Be tolerant!

    "Non"sense it is then :)
    Equally wrong.

    If I wanted to have fun on an old system and needed 512K SRAM with a custom interface then I would seriously consider using a P2 just for that very purpose.

    Please bear in mind the tone in my replies, it is not critical but I take into consideration that the OP is a newbie here and might not be totally aware of the many options that are available.
    Should we do him a disservice because we feel we need to be politically "tolerant"? I think not since we are far more open and friendly than that.
    We are simply musing about ways and means because the OP has posted onto an active and public forum which by its very definition is "a meeting or medium where ideas and views on a particular issue can be exchanged."
    I exchange my ideas and views because I am trying to be helpful in this regard.

    Had a chuckle at this. P2 will be a bit more expensive than a 512KB SRAM tho' ;)
    My Prop boards: P8XBlade2, RamBlade, CpuBlade, TriBlade
    Prop OS (also see Sphinx, PropDos, PropCmd, Spinix)
    Website: www.clusos.com
    Prop Tools (Index) , Emulators (Index) , ZiCog (Z80)
  • David Betz wrote: »
    Ross: Do you expect to have an XMM mode for P2 in Catalina? I'm sure there will be people who run out of code space even with 512K of RAM especially if they are using big graphics buffers.

    I think that eventually there might be. This is one reason that I am keeping the LMM execution mode alive on the P2 - this will make it trivial to "bolt on" XMM support at some stage ... and if you are using XMM RAM you probably don't care too much about the performance hit that comes with LMM execution vs Native execution.

    However, I am not going to jump into this one. I made a rod for my own back on the P1 by supporting all the available XMM boards available at the time, in all their bewildering variety.

    This time I will probably wait until there is some kind of Parallax-endorsed (or at least reasonably widely agreed) standard hardware interface.
    Catalina - a FREE ANSI C compiler for the Propeller.
    Download it from http://catalina-c.sourceforge.net/
  • jmgjmg Posts: 13,522
    There's this fast 512K 32-bit wide multi-port RAM that's available. I think the part number is P2X8C4M64P ...

    As specialty memories go, it's not a bad price either.
    Digikey show 4.5MBit dual port memory for ~ $200 3k+

    A hot new are is processing-in-memory (PIM) architecture, so this multi-port RAM could fine uses there too :)


  • RossH,

    Many thanks for your tips and suggestions.

    I'll rearrange the pinouts as you recommended.

    It makes sense that the PMC XMM driver was written with the assumption that the clock and control signals are contained within the upper Nibble and the data bus signals in the lower one.

    Why I didn't follow that convention at the outset is beyond me.

    I'll make the changes over the next week or so and try your XMM test utility to see if it works.

    I'm not going to mess with the XMM API settings just yet as I'm hoping the pinout changes and the CFG file update will get the job done.

    Once it works under Catalina, I'll venture over to PropGCC and see if I can get it to work there as well.

    Thanks again for your help on this.
Sign In or Register to comment.