Basic Spin PC

Aleks

Hello all,
I've been reading in the forums a lot lately, and have stumbled across many people mention trying to build a spin PC. The concept seems very intriguing to me, so I started kicking some ideas around and decided to buy multiple propeller ICs and set each of them as dedicated processors for a PC. This way I can have a spin IC as a dedicated graphics processor, another to handle user inputs, another to handle sound, and a master processor to make everything come together. That puts me at at least 4 dedicated ICs to run together as a PC. Now I haven't found any posts about this particular idea, so I just want to check to see if anyone has already embarked on such a project, or if anyone can spot some immediate flaws with the concept that I have overlooked?

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
~Some men see things as they are and ask "why?"
I dream of things that never were and ask "why not?"~

Oldbitcollector (Jeff)

In the past year or so that I have been here, there have been frequent discussions about
how to build a prop-based computer. For some of us, it's a goal in itself.

There are pieces of this project which are scattered throughout the forum threads.
You might want to search out PropDOS, FemtoBASIC for software. PropGFX is an
add-on video solution which uses an additional propeller to handle dedicated video.
Also, there is HSS, which could be adapted readily to a dedicated sound processor.

The limitation most of us are hitting is memory, (or the lack thereof) which could be
overcome with the addition of SPIRAM if implemented.

There's alot of room to put something like this together and several of us have been
working in that direction.

OBC

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

Getting started with a Propeller Protoboard?
Check out: Introduction to the Proboard & Propeller Cookbook 1.4
Updates to the Cookbook are now posted to: Propeller.warrantyvoid.us
Got an SD card connected? - PropDOS

Aleks

@Oldbitcollector
You are definitely right in memory being a problem. This is what led me to consider multiple chips. In this fashion I can separate the entire program out amongst multiple IC's and EEPROMs to provide enough programming space. Of course, handling variables through programs running on the PC would provide quite a bit of memory, so I'm considering taking some advice and knowledge from the propeller cookbook and acquiring an SD port to help add at least another 2 GB of space. Here I can store variables to be accessed by other chips or to be retained until needed later. This should help free up some space in the ram for processing. I may also have to include another IC just to handle running programs on the PC. This would help provide (hopefully) more speed to the processing. This way I can use separate IC's for various forms of hardware, a master hardware controller, and a master software controller. Adding another to pull those two together isn't outside of my reach either. Maybe I need to upgrade from 4 to 6 individual spin ICs?

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
~Some men see things as they are and ask "why?"
I dream of things that never were and ask "why not?"~

heater

I'm thinking of doing this with my CP/M for Propeller. One prop runs the 8080 emulator the second runs the TV/VGA keyboard etc. Still need a tad more RAM though.

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

Aleks

I stumbled across the issue of running out of variable space with the Basic Stamp and Javelin Stamp, and was forced to rely on storing variables that weren't being immediately used to a 24LC64 serial EEPROM to be recalled at a later time. This frees up variables for use. Some of the wonderful things about the propeller IC include its speed, its lack of necessity for garbage collection, and its flexibility. By using a flash or other form of removable media, such as an SD card, I hope to speed up the variable saving process to hopefully free up space in the RAM. For instance, if the IC has flooded memory from operations my goal is to implement the use of a seventh IC dedicated to monitoring the memory to choose variables that aren't an immediate necessity, and to store them in appropriate locations on the "ram card" (in this instance, a 2GB SD card). Here the variables can be stored until they are actually necessary. If the IC gets the command to wait for a certain keypress from the keyboard and then to display a string on a display, I would immediately save the string to the "ram card" to free up that space in the ram for use. Then I would start polling the keyboard, naturally using the same byte to check the input. X:= input. if x== y, abort. else, repeat. Then upon the abort sequence load the data from the "ram card" and use it. Its somewhat complicated, and definitely needs its own processor, but possible. And by breaking everything up amongst multiple IC's i have that much more space to operate. Of course, this is strictly my opinion of how it could be done, and i'm only putting it on the forum for someone to tell me whats wrong with it. So if there is any flaws with the concept of freeing up variables by storing their values into a "ram card", please let me know.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
~Some men see things as they are and ask "why?"
I dream of things that never were and ask "why not?"~

hippy

The problem of storing variables to I2C Eeprom is in wearing that out and the time it takes to write. You'll have similar problems with an SD Card if you are regularly saving variables that way. You can burn out an Eeprom or part of it in under 5 minutes if you put your mind to it.

Aleks

@hippy
That is an extremely good point. Are there any type of memory chips or cards that have more indefinite write cycles?

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
~Some men see things as they are and ask "why?"
I dream of things that never were and ask "why not?"~

hippy

There's commercial I2C RAM but of limited size (256x8) through you can use another Propeller Chip as up to 32Kx8 I2C RAM. There's also I2C FRAM but I'm not familiar with it.

Aleks

In that case one IC should be a dedicated memory handler, and I'll keep the flash card connected to it to act as a small hard drive (2-4 GB).

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
~Some men see things as they are and ask "why?"
I dream of things that never were and ask "why not?"~

Mike Green

I2C FRAM uses a different technology for the memory cells. The write time is essentially the same as the read time and both are as fast as the I2C protocol can go. There is a "wear out" issue as there is with conventional EEPROM, but it's much higher (maybe 10^8 cycles). The "wear out" issue does apply to both read and write cycles since read cycles are destructive as with ferrite core memories or ferrite thin film memories, but rewriting the data back into the memory array is handled automatically.

There are FRAMs that are drop-in equivalents to conventional EEPROMs up to 64K bytes. They're mostly in surface mount parts, not DIP packages.

Philldapill

I understand writing to eeproms is "damaging" and can only be done X number of times, but why can registers in the propeller and other processors get away with this? This is probably a very basic semiconductor topic and not very related to this thread... But isn't there some sort of better means of creating pseudo ram?

Aleks

@ Mike
Thank you for that explanation. Electronics is certainly a constant learning experience. Judging from the information provided here, and my own personal research, I'm going to have to modify my use of variables. Thus, instead of constantly writing values to the "ram card" i'm going to use the memory benefit of multiple, dedicated IC's and a central processing unit to master everything. I'll probably implement a single program processor to handle the software which the user can interface with. I'd still like to implement a single, master CPU to process "behind the scenes" equations and problem solving, but it appears that this may merge into my "software dedicated processor".

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
~Some men see things as they are and ask "why?"
I dream of things that never were and ask "why not?"~

Mike Green

The memory in the Propeller is what is called "static ram". Its contents are maintained by the power supply voltage. If the power is turned off, the memory contents go away. EEPROMs use little packets of charge forced into a thin layer of insulation on the chip. These packets can be "erased". After repeated recording / erase cycles (1,000s to 100,000s), the charge packets can't be "erased" anymore. FRAMs use a magnetic film, magnetized one way for zero and the other for one. After repeated recording cycles (maybe 100,000,000), the magnetic film begins to not record a strong enough signal for reliable reading.

Aleks

@Mike
Do you know of any way to acquire "static ram" in an IC package?

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
~Some men see things as they are and ask "why?"
I dream of things that never were and ask "why not?"~

Timmoore

Take a look at these 2 threads, in particular the discussion on SPI SRAM. I interfaced 4x32Kbyte SPI-SRAMs to a prop using 6 pins

http://forums.parallax.com/forums/default.aspx?f=25&p=1&m=275075
http://forums.parallax.com/forums/default.aspx?f=25&p=1&m=279985

You could also look at the PSD835G2V this gives you flash and SRAM and a bunch of io ports, enough to replace all the io pins it would take to interface it to the prop

hippy

There's plenty of static ram (SRAM) in standard DIP/SMD packaging used with traditional microprocessors with external memory buses but they usually have multiple address/data line requirements which ties up a lot of I/O.

Dynamic RAM (DRAM) is another possibility but more complex to control than SRAM.

waltc

I gave up trying to build a Prop PC and instead working to integrate the Prop as a soft FPGA into a Coldfire board I'm working on.

Instead it just takes care of video and keyboard.

Aleks

For the time being I'm starting to interface multiple props together to get a communication routine written. I'm going to set up a designated controller for the monitor, and another designated controller for the mouse/keyboard. I'll pull them together with a hardware controller, and program a software controller with a very simple program, probably just a basic game. Right now speed looks like the most difficult thing to keep up. I have a feeling that with some revised communication routines, I can speed things up a little bit.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
~Some men see things as they are and ask "why?"
I dream of things that never were and ask "why not?"~

Ale

waltc:

I wanted to make a board with a coldfire some time ago, so I got two 5206 in QFP160... many pins but doable. What keeps me from doing something is the fact that I do not have any knowledge on how to programthe coldfire besides maybe using a EPROM or another processor (like the prop) to serve as the first boot till something more useful is loaded from a SD card or similar. What are you planning to use ?. The prop as video controller is a great idea. If you use TV out you can use the rest of the pins for access as a memory device, address, data and W*. If you use VGA... well PC communication will be... lost ? (can be mixed with the VGA output....

Oldbitcollector (Jeff)

Baggers has been working overtime to get a PropGFX demo system shipped out to my Expo,
so I'll jump in for him...

His PropGFX (Propeller-based graphics board) has already done the dedicated video part of
this project, and uses both an 8bit bus, and serial connection to send commands from one
propeller to another propeller for display.

Here's a direct link to their forum. www.propgfx.co.uk/forum/Blah.pl?b-PL/
They are almost ready to begin selling this product.

Jeff

Aleks said...
For the time being I'm starting to interface multiple props together to get a communication routine written. I'm going to set up a designated controller for the monitor, and another designated controller for the mouse/keyboard. I'll pull them together with a hardware controller, and program a software controller with a very simple program, probably just a basic game. Right now speed looks like the most difficult thing to keep up. I have a feeling that with some revised communication routines, I can speed things up a little bit.

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

Getting started with a Propeller Protoboard?
Check out: Introduction to the Proboard & Propeller Cookbook 1.4
Updates to the Cookbook are now posted to: Propeller.warrantyvoid.us
Got an SD card connected? - PropDOS