Adding 512Kx8 or 128Kx8 external SRAM to the Prop (for emulations, etc)

Cluso99Cluso99 Posts: 10,796
edited January 2009 in Propeller 1 Vote Up0Vote Down
I was web surfing last night - I should have been programming my prop :-(

Anyway, I was thinking that for the PropAltair and similar emulations, that ram is always the problem. So, I thought about using 2 props as follows...

One prop would be the standard prop running VGA (or TV) and keyboard (and maybe mouse) and Serial (FullDuplex) and running a terminal emulation (VT52, VT100, etc). This is basically what OBC has done with PropComm (without the propdos). Nothing complex here. It can communicate serially to another prop. It may also use the SD card as a disk emulation to the second prop.

The second prop would have a serial connection to the first prop, and would load from eeprom as normal. It would then boot the emulation or load from the other prop. This prop would have its io pins connected directly to a 128Kx8 sram. This takes 17 pins for address, 8 for data and 3 for ce, oe and we, totalling 28 pins. This plus the 2 serial and 2 I2C makes the total 32 io pins the prop has. The sram has 10-15nS, so the prop will be slower than this.

Would a pcb with just the second prop built like this sound interesting, or should a pcb have both props on it including vga, tv, keyboard, mouse, etc?


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

· Prop Tools under Development or Completed (Index)
· Emulators (Micros eg Altair, and Terminals eg VT100) - index

My cruising website is ·www.bluemagic.biz

Post Edited (Cluso99) : 1/22/2009 9:47:40 AM GMT
My Prop boards: CpuBlade, TriBlade, RamBlade, www.clusos.com
Prop Tools (Index)
Emulators (Index) ZiCog (Z80)
Prop OS (also see Sphinx, PropDos, PropCmd)
Tagged:
«1

Comments

  • 56 Comments sorted by Date Added Votes
  • Dr_AculaDr_Acula Posts: 5,443
    edited January 2009 Vote Up0Vote Down
    That sounds very simple. And very interesting.

    I've been trapped before by trying to get everything onto one board and get it all working all at once. Sometimes it is better to build things in modules and get each module working, and maybe down the track an obvious solution will come up that puts it all on one chip. The propterminal is a great standalone device but it may well be pushing the limits of the prop. The problem here is IO pins and the prop simply doesn't have enough. All the fixes are all fudges and end up using more and more glue chips to the point you may as well build it as a non prop solution.

    So yes, a little board with a prop and just serial and/or I2C and a 128k ram chip. Don't try to do anything else at this stage. Put all the data storage on the other board eg the working terminal/sd projects. Before you build a board though, this sounds almost simple enough to breadboard and test that way. Just a 32 pin and a 40 pin chip after all. I presume 1k resistors if you are using a 5V ram chip? I've been using lots of SIL/DIL arrays for resistors and they certainly beat soldering in lots of individual resistors.

    heater might be able to answer this one - will there be enough space for emulating all the instructions for a range of micros? Including but not limited to Z80? Enough longs etc. Given a micro will only use 64k, will the other 64k be useful in some clever way for the prop to use?

    Sounds interesting. It could be a neat 3 chip computer. And no doubt someone will work out a cunning way of decreasing that chip count!

    Post Edited (Dr_Acula (James Moxham)) : 1/22/2009 7:03:59 AM GMT
    Answers: 1) A quadcopter. 2) Very high. 3) The internet. 4) A lot. 5) No.
  • virtuPICvirtuPIC Posts: 193
    edited January 2009 Vote Up0Vote Down
    Prop with cache and wirtual memory... wink.gif Well, it already has multilevel memory organization on chip. There are other threads about connecting Microchip's 23X... SPI SRAM to the prop. External memory is probably useful for many applications. You have to decide about the following points choosing technology, at least:
    • RAM or ROM, EPROM, EEPROM, FLASH?
    • serial or parallel chips?
    • serial or parallel conneciton?

    There might be a few more points. You tell about parallel connection in address and data, right? That's fast, but needs many pins. What about serial addressing? The simplest case is to put in a shift register that takes the addres. Would only need two prop pins, could be clocked rather fast, and you could use the cheap memory chips. You could even put a counter after the shift register that is automatically incremented at memory read. This would increase speed on block reads. If you invest some time in software development you could use this approach even to connect to DRAM of arbitray size! A propeller pulling 4GB or more...

    There is also code around to access SPI / I2C memory and currently several threads on interfacing Microchip serial SRAM.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Airspace V - international hangar flying!
    www.airspace-v.com/ggadgets for tools & toys
  • Cluso99Cluso99 Posts: 10,796
    edited January 2009 Vote Up0Vote Down
    I am thinking of the AS7C31024B-12JCN which is an SOJ 32pin package. It is 128Kx8 SRAM. No interface glue logic required, just direct to the prop pins. The software access is pretty simple and pretty fast in pasm.

    I·am suggesting·parallel access and no·multiplexed address lines or latches/counters. This simplifies the software and speeds up the access. :-)

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

    · Prop Tools under Development or Completed (Index)
    · Emulators (Micros eg Altair, and Terminals eg VT100) - index

    My cruising website is ·www.bluemagic.biz
    My Prop boards: CpuBlade, TriBlade, RamBlade, www.clusos.com
    Prop Tools (Index)
    Emulators (Index) ZiCog (Z80)
    Prop OS (also see Sphinx, PropDos, PropCmd)
  • Dr_AculaDr_Acula Posts: 5,443
    edited January 2009 Vote Up0Vote Down
    Good suggestion - use a 3V sram. Not much difference in price anyway between 5V and 3V.

    I'm not an expert on maximum speeds on the prop but heater only managed to get about a 4Mhz emulation on an 80Mhz propeller. Doing any data transfers in serial is going to slow things down ? by up to 16x further meaning an emulation speed in kilohertz rather than megahertz. I think it has to be parallel ram unless there is some very fast serial code out there. If you leave all the vga stuff as a seperate terminal project, set it to one side, and just consider a 40 pin prop and a 32 pin ram chip, this does become rather beautiful in its simplicity. I'm looking at the sort of board this replaces - it replaces an eprom, a microprocessor, a uart, two crystal oscillators and 9 74HC glue chips. Plus it can emulate any number of micros - 8080 6502 8085 8051 Z80, maybe even PICs?
    Answers: 1) A quadcopter. 2) Very high. 3) The internet. 4) A lot. 5) No.
  • Cluso99Cluso99 Posts: 10,796
    edited January 2009 Vote Up0Vote Down
    Ok, just found these SRAM 128Kx8 and 512Kx8 PDIP32 parts (Farnell in Australia A$6.12 and $11.83 - about US$4 and $8 in 1-off pricing).

    The OE pin can be tied low, so for the 512Kx8 device 19 address + 8 data + CE + WE = 29 pins. Obviously the 128Kx8 device is fine with 27 pins. So, if the 512Kx8 is used (and it would be nice to be compatible for both chips)·the question is which pin to use for the 29th pin (SCL or SDA) so I need to look at the specifications to see which is best. I am thinking either the SCL or SDA would be tied to the WE pin. An eeprom is actually not required as it could be loaded via the serial pins (just like it is loaded by the·PropLoader now).

    I also want to check out the SD card interface, as with no eeprom, there would be another pin available, so it may be possible to add an SD card interface to this board to emulate the disk.

    Imagine a 2 chip Altair/Z80/8080/6502/6800 etc retro computer with 512KB of ram plus 2GB SD card connected to·another prop doing tv/vga/keyboard and any extra I/O or peripherals. hop.gif

    Postedit: The SRAM is 55nS.·Successive reading can be done by leaving CE permanently enabled (which prevents the SRAM entering standby and therefore uses a lot more power) and just changing the address and reading. However, the prop would require a nop in between setting the address and·reading the data (because between 2 successive prop instructions is 50nS). A write requires the WE line to be used.

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

    · Prop Tools under Development or Completed (Index)
    · Emulators (Micros eg Altair, and Terminals eg VT100) - index

    My cruising website is ·www.bluemagic.biz

    Post Edited (Cluso99) : 1/22/2009 9:45:25 AM GMT
    My Prop boards: CpuBlade, TriBlade, RamBlade, www.clusos.com
    Prop Tools (Index)
    Emulators (Index) ZiCog (Z80)
    Prop OS (also see Sphinx, PropDos, PropCmd)
  • heaterheater Posts: 3,370
    edited January 2009 Vote Up0Vote Down
    This great. So many people stepping up with solutions to the Propeller RAM "crisis". Especially with respect to emulators. I hope Parallax is noting this for the Prop II. Even with its bigger HUB RAM its extra speed will encourage more and bigger applications which will put pressure on RAM again. Especially for users of ImageCraft C and it's LMM. It would be really cool to have some kind of hardware assistance for fast RAM interfaces given the Prop II has so many I/O pins. Even to the point of having RD/WRLONG/WORD/BYTE instructions work for the external RAM as well as the HUB. But I digress....

    I'm a bit tired to absorb all the ideas here but as usual in any design there are many ways to go and many trade offs.

    A parallel RAM bus connections must be the fastest possible, but uses too many pins. Fine for speed, not so fine for a single Prop solution with SD cards and VGA and keyboard etc etc.

    Serial RAMS are going to be slower, but perhaps not so slow if a "memory controller" COG is fetching instructions in parallel with emulator cog opcode execution. This may be slower but is dead simple for people to add to a Prop demo board for, say, just running up an emulator for a lark. And of course useful for many other less speed demanding tasks.

    So which way to go? Well it seems that both solutions are going to be designed and implemented depending on individual priorities. If anyone gets as far as producing a batch of boards for a parallel RAM solution for sure I want one and will be adapting PropAltair to run on it [noparse]:)[/noparse]

    Just now I've been contemplating the idea of adding two old 32K RAMS (I have many in my junk box) and using Intel's trick of multiplexing the lower 8 bits of address with the 8 bit data. Only requires an external latch and an address decoder (just an inverter) This gets the pin count down to 19. Leaves pins for SD card etc. Looks like I could add it to my home made demoboard. If only I wasn't living away from my workbench and components just now.

    Next up for me is to get CP/M 3 running which will require bank switched memory. I've come to the conclusion that the bank switching is best done in external hardware, otherwise some software always has to check which bank is supposed to be active at any moment and then fix up offsets into a linear external RAM space, slow.....

    @Dr_A: I have not looked into emulating other CPUs much. There is someone working on a Z80 emulation for a ZX81 clone. No report as to how far that has come yet. There are others working on multi COG 6502.

    The Z80 has twice as many opcodes as the 8080. It has more than twice as many registers. It has more addressing modes. This leads me to believe that it will require 4 or more times the effort to develop it and require multiple COGs. Could be done in one COG and LMM, I guess, but very slowly. Personally I'm not up for that but will keenly follow any developments that go on there.

    BTW. PropAltair speed is probably worse than that. 350,000 instructions per second. Just like an original 8080[noparse]:)[/noparse] Without going to multiple COGs I don't see much improvement coming there.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    For me, the past is not over yet.
  • hinvhinv Posts: 821
    edited January 2009 Vote Up0Vote Down
    The B version of the prop would help a lot as well. It has been stuck in development for over a year now because of a software issue AFAIK. Another 32 IO pins would be great. It would completely eliminate the need for glue logic, and provide you with enough bits to do 2MB of addressing just in the B port.
    Parallax, if you are listening? Has any progress been made on the B version Prop1? Since a year later we are still thinking another year for PropII, has the priority for the B version chip changed at all?

    Thanks,
    Doug
  • heaterheater Posts: 3,370
    edited January 2009 Vote Up0Vote Down
    Oh yeah, forgot about the long lost B version. Pretty please......

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    For me, the past is not over yet.
  • Cluso99Cluso99 Posts: 10,796
    edited January 2009 Vote Up0Vote Down
    Here·are my suggested connections..
    I don't think the eeprom and 512Kx8 can co-exist, but the 128Kx8 and eeprom are ok. I have added an SD-Card also cool.gif

    Proposed Propeller / SRAM / SD Card PCB
    By Cluso99 22 Jan 2009
    All parts 3V3
    Propeller     Eeprom   Serial   SRAM-512Kx8         SD-Card     PullUps
    ---------     ------   ------   -----------         -------     -------
    P31                    Sin
    P30                    Sout
    P29           SDA               A18 (nc 128Kx8)                 10K
    P28           SCL               A17 (nc 128Kx8)                 10K
    P27                             A16
    P26                             A15
    P25                             A14
    P24                             A13
    P23                             A12
    P22                             A11
    P21                             A10
    P20                             A9 
    P19                             A8 
    P18                             A7 
    P17                             A6 
    P16                             A5 
    P15                             A4 
    P14                             A3 
    P13                             A2 
    P12                             A1 
    P11                             A0 
    P10                             -CE                             10K
    P9                              -WE
    P8                                                  -CS (1)     10K
    P7                              D7                  SCLK(5)     10K
    P6                              D6
    P5                              D5
    P4                              D4
    P3                              D3                  Din (2)     10K
    P2                              D2                  D2  (9)     10K
    P1                              D1                  D1  (8)     10K
    P0                              D0                  Dout(7)     10K
    -Reset                 -Reset
                                    -OE=Gnd
    
    



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

    · 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
    My Prop boards: CpuBlade, TriBlade, RamBlade, www.clusos.com
    Prop Tools (Index)
    Emulators (Index) ZiCog (Z80)
    Prop OS (also see Sphinx, PropDos, PropCmd)
  • Dr_AculaDr_Acula Posts: 5,443
    edited January 2009 Vote Up0Vote Down
    Re heater "So which way to go? Well it seems that both solutions are going to be designed and implemented depending on individual priorities. If anyone gets as far as producing a batch of boards for a parallel RAM solution for sure I want one and will be adapting PropAltair to run on it [noparse]:)[/noparse]"

    Well the board above from Cluso99 looks pretty simple. As for old chips, well I've got drawers of 6264 8ks, and sooner or later, I've got to face up to the fact they may never get into a project [noparse]:([/noparse] A single 128k 3V3 is just so much simpler.

    What else does such a board need to make it work? The download bit - is that a max3232? And it could talk to any terminal (propterm or hyperterminal etc) via good old RS232 so that would use all 4 gates in a max3232. 3 chips? Plus the SD socket?

    Making boards is pretty easy (btw has that board arrived yet heater?). What I'm not clear about is how *useful* the other 64k of ram could be. I could see it being very handy to expand the prop's memory in theory, and decrease reads back and forth to the sd card. Maybe store emulations of lesser used instructions. But I'm not up with the prop to understand the details of how that might work. But if you want a board with sd and 128k ram and a max3232 that would be pretty simple. Let me sleep on the idea...

    Post Edited (Dr_Acula (James Moxham)) : 1/22/2009 1:18:23 PM GMT
    Answers: 1) A quadcopter. 2) Very high. 3) The internet. 4) A lot. 5) No.
  • kwinnkwinn Posts: 5,981
    edited January 2009 Vote Up0Vote Down
    Cluso99, I think this is the best idea to date. Sure beats adding CPLD's or multiple glue chips, and probably less expensive to boot. I would be in favor of a separate board, and putting connections for a second memory chip that could hold another ram chip or a parallel eeprom is a great idea. The only suggestion I have is to provide only 16 address lines directly from the prop and add a latch to hold A17, A18, and the CS lines. They will not change very often so should have minimal impact on speed.
    In science there is no authority. There is only experiment.
  • Peter JakackiPeter Jakacki Posts: 4,519
    edited January 2009 Vote Up0Vote Down
    I also looked into adding extra RAM by dedicating a Propeller for this task rather than using FPGAs. I don't think there would be much of a penalty if the upper address bits are latched off the lower address lines, this provides up to 8 extra address lines for just a single strobe so I would use a 512KB SRAM for instance.
    8 data
    11 low address + 8 high address latched
    1 address strobe
    1 CS
    1 WE
    TOTAL MEMORY LINES = 22

    To interface to the other Prop couldn't we use the 8Mbps Prop-to-Prop technique? Anybody try this yet?

    I'm not really interested in emulation (maybe a little) but I would like to have the extra RAM for video and applications in general so I look forward to Prop II as everybody does. However, the current prop is excellent for many embedded tasks just as it, after all it is designed as a single-chip microcontroller in a friendly DIP or QFP pack. I have my pick of any umpteen micros that have external memory buses in 144+ lead QFPs (if I'm lucky) but mostly BGAs. As much as I would like the memory I'm not that interested to steer away from the Prop.

    *Peter*
  • dMajodMajo Posts: 569
    edited January 2009 Vote Up0Vote Down
    @Cluso99, I think that by using just a transistor to reverse the state you can have the ram CE and SD card CS tied to the same output (having the CE after the transistor will ad benefit to preserve ram states during propeller reboot since the ram wil have the chip select but will miss the write enable). This can allow you to preserve the eeprom.

    I am also with Kwinn to lach the data bus externally to provide more chip selects to several rams or other paralel IC; but I am against the address latching since this will page the memory and somehow limit the horizons.
    Propeller Object Exchange (last Publications / Updates) --- Oldbitcollector's guest map
    JustForMe
  • Cluso99Cluso99 Posts: 10,796
    edited January 2009 Vote Up0Vote Down
    If the address lines are connected directly to the prop, the software will be faster (simpler). I've specifically set the pins to make software easier. I am going to include a microSD socket.

    As for the serial, this is still open. I think it should be unbuffered, but am thinking about if I will put an FT2232 onboard (USB to dual serial 3V or 5V). This would allow use with the cheaper Proto Board (without USB). I want to share the power supply between boards, so not sure if I will supply or take power to the other prop. Using a direct link to the other prop will allow the 8Mbps technique (untried). The reset line will also be connected because the booting may need to be done by the other prop.

    BTW The other prop need not be a prop. COuld just be a pc (maybe via the PropPlug?)

    The only other issue I can think of is whether to use SMT or DIP parts.

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

    · 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
    My Prop boards: CpuBlade, TriBlade, RamBlade, www.clusos.com
    Prop Tools (Index)
    Emulators (Index) ZiCog (Z80)
    Prop OS (also see Sphinx, PropDos, PropCmd)
  • dMajodMajo Posts: 569
    edited January 2009 Vote Up0Vote Down
    @Peter

    If you multiplex the data lines with the address ones you half the throughput BUT you can recover it with no penalties widening the data (so two cycles: one for address the other for the data BUT double the data 16 bits)

    1MB (64K*16) = 16 addresses lached + 16 data
    Propeller Object Exchange (last Publications / Updates) --- Oldbitcollector's guest map
    JustForMe
  • Peter JakackiPeter Jakacki Posts: 4,519
    edited January 2009 Vote Up0Vote Down
    @dMajo, I don't think it would make a lot of difference as unless the access is totally random you will find that there is a lot of sequential activity going on so the high address does not need to be updated unless it has changed. Besides we are talking about dedicating a Prop with spare cogs so it is possible to have a cog looking after the address bus issue. I might be talking through my hat because I have not sat down to study the implementation but from my experience and what I have been thinking about it this method could have merit.

    *Peter*
  • Oldbitcollector (Jeff)Oldbitcollector (Jeff) Posts: 8,080
    edited January 2009 Vote Up0Vote Down
    Looking at the timestamps on this thread, I'm wondering if anyone actually sleeps here. [noparse]:)[/noparse]

    @Cluso

    That suggested board not only looks simple to build, (and prototype!) but also uses parts
    that everyone should be able to get their hands on. All we need is some parts and some
    spin to glue this together!

    OBC

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    New to the Propeller?

    Check out: Protoboard Introduction , Propeller Cookbook 1.4 & Software Index
    Updates to the Cookbook are now posted to: Propeller.warrantyvoid.us
    Got an SD card connected? - PropDOS
    <br>
  • Peter JakackiPeter Jakacki Posts: 4,519
    edited January 2009 Vote Up0Vote Down
    Oldbitcollector said...
    Looking at the timestamps on this thread, I'm wondering if anyone actually sleeps here. [noparse]:)[/noparse]
    OBC

    My understanding wife asked me once if I had to choose between her and the "computer", which would I choose. I told her that was a silly question and not to ask it. nono.gif

    OBC, the timestamps give us away, we don't talk prop shop because we have to, we do it because we love to.

    *Peter*
  • Cluso99Cluso99 Posts: 10,796
    edited January 2009 Vote Up0Vote Down
    Yes, it's 3:20am here. The SRAM will fit on a Prop Proto Board but I think I may layout a pcb. Unfortunately, my Protel software is not on my pcs here so will have t wait until I next go home. Unless I download one of the freebies.

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

    · 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
    My Prop boards: CpuBlade, TriBlade, RamBlade, www.clusos.com
    Prop Tools (Index)
    Emulators (Index) ZiCog (Z80)
    Prop OS (also see Sphinx, PropDos, PropCmd)
  • kwinnkwinn Posts: 5,981
    edited January 2009 Vote Up0Vote Down
    Peter, darn, I wish I had thought of that.

    dMajo, I am glad you liked the idea of latching the chip selects, but I agree with Peter Jakacki that it will not make much of a difference in speed. Profiling software has shown that most software program and data access is fairly localized. Look at how much time is spent in loops and subroutines. I also agree with Peter that all 16 address lines do not need to come directly from the prop. If we used an 8 bit latch ( like the 74xx373) we could use 2 bits to select one of 2 memory chips (or 1 of 4 with additional decoding) and the remaining 6 bits for the high address bits.

    While this is not quite the arrangement Peter suggested it allows addressing 2 chips ( 1ram 1 eeprom? ) of 128K each with 22 prop lines:
    8 data
    11 low address + 6 high address latched
    1 address (latch)strobe
    1 OE
    1 WE
    TOTAL MEMORY LINES = 22

    Using 2 more prop lines allows addressing 2 chips of 512K. Picture having several instances of CPM running at one time and being able to switch between them. The alternative is to use a second latch and free up some more prop lines. The down side of all this is it complicates a simple and elegant idea.

    Is anything gained by freeing up the prop lines that are now used for more than one function (P0, P1, P2, P3, P7, P28, P29)?
    In science there is no authority. There is only experiment.
  • dMajodMajo Posts: 569
    edited January 2009 Vote Up0Vote Down
    @Kwinn, Yes this is true until we are executing code (fetched or LMM) but sutch expansion could be also used for fast and big data magement (a relational DB, Sort functions over large data that is not bubblesort, ...)


    16 address + 16 data
    1·· address strobe
    1·· WE
    1· CS for lower 8 data latch (not the address latch) giving 8 CS/CE to up to 8 devices

    TOTAL 19 lines for up to· 8 IC (ram/eprom/special parallel hardware/SD cards) addressable up to 64K*16 (1MB) with no latch penalties compared to 8 bit parallel; just 3 external 8bit latches (or one 8bit and one 16bit)

    ... and on P28/P29 it will be very nice to find a FM31L278 in place of the standard eeprom
    Propeller Object Exchange (last Publications / Updates) --- Oldbitcollector's guest map
    JustForMe
  • kwinnkwinn Posts: 5,981
    edited January 2009 Vote Up0Vote Down
    Here is a block diagram of my suggestion. If possible memory chips can be laid out to accept either ram or eeprom, and 128k or 512k. Essentially from the prop left would be like the prop proto board without the video circuitry. Please forgive the sketchy diagram and any missed signals. I am working at a customer site today and only had a slightly extended coffee break to do this in.
    In science there is no authority. There is only experiment.
  • kwinnkwinn Posts: 5,981
    edited January 2009 Vote Up0Vote Down
    dMajo, true up to a point and possibly better for database applications/sorting but you still have to update the address or chip select latch to read the next memory location, and on average both latches have to be updated every 8 accesses. Also the 16 address/data pins have to be changed between inputs and outputs frequently.

    I must admit I like the cleaner more orthogonal design it gives, but for emulating an 8 bit micro I feel it is not a good choice. It would be interesting to compare the two choices for the range of applications possible. Perhaps we could agree on some specific tests to run, write the code, and compare the results.
    In science there is no authority. There is only experiment.
  • heaterheater Posts: 3,370
    edited January 2009 Vote Up0Vote Down
    No the world never sleeps, we are all in different time zones after all!

    @Dr_A, sadly your board has not arrived here yet. I'm checking the post like a little boy at Christmas for the past couple of days. Only yesterday I found out where you are, via the vintage computer forum, it's a long way.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    For me, the past is not over yet.
  • heaterheater Posts: 3,370
    edited January 2009 Vote Up0Vote Down
    @Dr_A: "What I'm not clear about is how *useful* the other 64k of ram could be." well somewhere I have it in the back of my mind to try and run up CP/M 3 or MP/M which used banked switched memory.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    For me, the past is not over yet.
  • Dr_AculaDr_Acula Posts: 5,443
    edited January 2009 Vote Up0Vote Down
    @heater It should be soon, but if nothing in the next week I'll send another.

    Re a board, I'd suggest DIP rather than surface mount. When I was younger I built a lot of circuits for small robots etc and tried to get everything as small as possible. But for computer boards, it doesn't matter if it is larger, at least for prototyping and proving concepts. SMD is so fiddly to make. It can always go surface mount once it is proven.

    It is always tempting to add a latch here or a transistor there, but there are plenty of pins so there is no need to try to save pins. I like the clean and simple "no extra parts" solution.

    Re boards, the biggest cost with small runs is the setup cost and the shipping. The number of boards and the size of the boards are less relevant. So making a board a bit bigger does not change things much. I'm just thinking that you could put a pad on the board for a 128k ram and you could also put one for a 512k ram and you could install which one you wanted. Ditto the max3232 - you could have a small header for digital comms (0-3V) and that signal can go to a max3232 and D9 pcb mount socket. If you only want digital comms eg to another prop board, then just install the header and leave out the max3232 and D9.

    Re the download circuit, what is the vibe from the forum on the transistor circuit vs the max3232 circuit vs the prop adaptor board? Which one is most popular? Would you put pads for more than one (all) of these options and let the user install the components that suit them?
    Answers: 1) A quadcopter. 2) Very high. 3) The internet. 4) A lot. 5) No.
  • ImageCraftImageCraft Posts: 348
    edited January 2009 Vote Up0Vote Down
    If one of you geniuses can figure out how to make a propeller accessing external memory as fast as possible, we can make a XMM-C (eXternal Memory Model C) Stamp module. There is hardly any change needed to support this from the compiler and the LMM kernel. Then you can run really large C programs on the propeller.
  • Phil Pilgrim (PhiPi)Phil Pilgrim (PhiPi) Posts: 19,524
    edited January 2009 Vote Up0Vote Down
    Andr
    “Impossible is just a big word thrown around by small men who find it easier to live in the world they’ve been given than to explore the power they have to change it. Impossible is not a fact. It’s an opinion. Impossible is not a declaration. It’s a dare. Impossible is potential. Impossible is temporary. Impossible is nothing.” –Muhammad Ali
  • jazzedjazzed Posts: 11,767
    edited January 2009 Vote Up0Vote Down
    Ya. Incremental access. Great for big FIFOs. Random access would be realatively slow. Better than nothing I guess.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    --Steve
  • Phil Pilgrim (PhiPi)Phil Pilgrim (PhiPi) Posts: 19,524
    edited January 2009 Vote Up0Vote Down
    Well, it's either that or use up nearly all the Prop's pins. Multiplexing the address and data while providing autoincrementing seems like a reasonable compromise and, for sequential stuff like LMM execution, speedy access. Programming one cog as a MMU for caching could provide further speedups. Determinism would go out the window, though.

    -Phil
    “Impossible is just a big word thrown around by small men who find it easier to live in the world they’ve been given than to explore the power they have to change it. Impossible is not a fact. It’s an opinion. Impossible is not a declaration. It’s a dare. Impossible is potential. Impossible is temporary. Impossible is nothing.” –Muhammad Ali
Sign In or Register to comment.