Wish list item: Not-so-confined Propeller system

dpeschel

Congrats to Parallax for such an interesting CPU design, and all the hackers for cool programs. I have been hoping for a well-designed CPU and a hackable self-hosting system built on it.

As a microcontroller for dedicated projects, I'm sure the Propeller is quite capable (though I have no experience with those sorts of projects). As the CPU of a general-purpose self-hosting system, I'm afraid it's not quite big enough. For example, does the Propeller world have a fast bitmap display yet? (Say VGA. Bitmap, not tiles or polygons.) Maybe the PropGFX?

The size of memory and the "download from other system" model seems like the other big problem. How much memory (cog and main) is left when the typical Hydra game runs? Enough to transfer to a debugger or an OS like PropDOS?

Maybe the ideas of the Xerox Alto would work on the Propeller. The Alto had a carefully-designed disk controller and file system, so that it could use a disk cartridge as a combination file system and swap space for RAM. You could essentially dump all or part of RAM to a file and load new RAM (all or part) from a second file. You had to save registers in RAM before dumping through. That's enough to build a nearly invisible debugger, working on the file and then swapping it back in again. But a small swapper "kernel" was always needed and was unfortunately in unprotected RAM.

For the Propeller an SD card is a good disk substitute. The Propeller would have to

• save and restore all cog state to/from main RAM or the SD card
• save and restore all cogs+main state to/from the SD card
• program EEPROM from the SD card

I know the Propeller can load cog state, not sure about saving. Any comments from experts?

Thanks.

Mike Green

There is no way to force the saving of a cog's state. A cog can have code in it to save its own state, but there's no hardware assist. There's also no way to restore a cog's state externally. The only instructions to initialize a cog, don't restore a saved state. They load memory and all the control registers for the cog are initialized to zeros. There would have to be code executing in the cog to complete the task.

It is possible to write very small routines to dump a cog's state to main memory for debugging purposes. These can be kept in "hidden" memory not normally used by most programs, but they have to be included.

Post Edited (Mike Green) : 9/20/2008 8:18:28 PM GMT

kwinn

Having built my first computer from a kit (8080 S100, 256 bytes of ram, 2k of 1702 eprom, 40x16 tv display) and having to write my own boot loader to load CPM when I upgraded I am more than happy to use a PC to compile, download, debug, and repeat. It is far far better than entering code in hex or octal and debugging one subroutine at a time.

heater

kwinn: Sounds like you need some CP/M for your propeller [noparse]:)[/noparse]

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

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

Ale

heater, as soon as I have my two propellers talking to each other over an 8 bit bus, I'll give your simulator a try, let'S see if with 64 kb RAM we can do more. (they have some sync problems).

dpeschel

kwinn: I would be happy to use a PC except that I have a non-Intel Mac and I don't know if the development tools are there yet. I grew up with the Apple II, so I know about small computers, but I got spoiled by the way UNIX can maintain itself and it's hard to give that up.

Even small computers can have development tools -- the Apple has ROM BASIC/assembler/monitor/debugger; the PDP-1 has the excellent DDT; and the Polymorphic Systems Poly-88 has a neat video "front panel".

Mike: OK, no hardware support for saving. I need to find out more about how a typical game/demo is put together and how much free memory might be available. (So I know how difficult it would be to get current programs to run under any kind of Propeller OS or debugger.)

I've seen a few details about the next Propeller but I'm assuming it's years away. Is hardware support for saving, or memory protection, or one cog controlling another, being considered?

Mike Green

No hardware for saving the state of a cog. It's not needed for the way that cogs are really used.

No memory protection hardware. Again, it's not appropriate for a processor like the Prop II.

There will not be any hardware for one cog to control another other than forcing a cog to stop or reinitialize itself. This has been considered repeatedly and deliberately discarded.

It is possible to run Virtual PC on a non-Intel Mac with Windows XP in order to use the Propeller Tool. It's pretty slow and you have to make sure that Windows doesn't try to run anything in the background (like Windows Update) while you're trying to download a program to the Prop. You can't run any large Mac application simultaneously with Virtual PC unless you have a lot of memory available. When I had to do this, I would use a Mac editor (TextWrangler) for editing, then copy that to Windows for compilation and downloading.

There is a Prop debugger in development by some of the forum members. There have been several Prop simulators available for quite some time. ImageCraft's C for the Prop will likely have a symbolic debugger sometime in the not so distant future. I've done a lot of debugging using a 2nd video display and a variable monitoring routine running in its own cog that displays useful global variables.

Mike Green

There have been several Propeller OS's that are like the early OS's in that they were primarily standard I/O packages including a file system and simple command interpreter. I wrote one several years ago that has a link in one of the "sticky" forum threads on Graham Stabler's Good Thread Index. This would load a display driver, a keyboard driver, an I2C driver/loader and had a simple command interpreter with some utility functions. The drivers would stay resident in their cogs while applications could be loaded and run that would use the already running drivers.

There has been a lot of discussion and work done since that time on similar ideas. "Super DOS" is one such project, "FemtoBasic" is another.

dpeschel

Sounds like I have some more projects to look at. The Web pages that are easy to find (the projects I know about) are pretty old, while the forum is up to date but hard to browse/search IMO.

And it's nice to know a little of the engineering thinking. I realize I'm asking for heavyweight CPU features in a lightweight microcontroller world. I wish there were other interesting clean open designs to choose from. I haven't seen much real CPU design lately, and nothing that fits my goals.

I'm sure I would enjoy playing with a Propeller system though. And I hear tradeoffs and unchangeable realities are part of real-world engineering (I mean from my point of view, I don't know about yours).

potatohead

Well, getting going on Prop I now gives you a nice jump on Prop II.

That one will be at a scale that makes the kind of system you are looking for viable. And there is also the very simple hardware arrangement of the propeller to consider. The thing does a LOT with only minor support hardware.

If you are into CPU design, the Prop is just excellent. The overall engineering of it has some very serious merit, and it's highly differentiated from pretty much all other CPUs you could choose from. Personally, I find it to be a kick for that reason alone. As it scales, we are highly likely to find it's extremely potent per clock, compared to most other chips out there.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!

Chat in real time with other Propellerheads on IRC #propeller @ freenode.net

Mike Green

Some of the decisions mentioned are part of what contributes to the "clean open" design. There are some very very long threads on "what would you want in a Prop II?" and several other more recent long threads. These (if you can wade through them) give a lot of the philosophy behind some of the design decisions. The Prop I was not casually designed. Prop II is not being casually designed and has an unprecedented amount of user feedback from all kinds of users, experienced and beginners. We're also privy to some of the design tradeoffs ... kind of fun to listen to.

Keep in mind that the Prop I is a microcontroller. The Prop II will be a bigger / faster microcontroller. It will be capable of doing the same kind of general purpose computing that small to medium size microcomputers did 30 years ago. That's actually quite a bit.

heater

Ale: Interesting, I was also considering 2 Props as a way to get more RAM space. But I think the BDS C compiler in CP/M requires a 64K system to run which would still be tricky.

Perhaps you could start a "Twin Prop" thread for this.

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

Mike Green

The FM25V10 is an SPI FRAM memory (from RAMTRON) that has 128K bytes and a 40MHz SPI interface. It should be pretty easy to make an 8080 emulator using one of these FRAMs as main memory and one cog for execution. Another cog could handle an SD card for floppy diskette emulation, two cogs for a VGA display, and a cog for a keyboard. One cog could have a 4 channel serial driver. That's only 6. You could probably use PC compatible files for storing floppy disk images.

heater

Mike. The 8080 emulator is done already, pretty much as you describe but without any external RAM.
I don't use PC compatible files, after all it is running CP/M. This saves space and time by not using DOS formatting code.
I/O is just one serial link to PropTerminal for now.
With external RAM I would of course use VGA and keyboard drivers for the ultimate goal, a stand alone CP/M machine.

FRAM is interesting but even with 1E14 write cycles it could be worn out pretty soon if abused. I worry that it's serial nature will slow the emulation quite a bit. This is a very new device, hope I can get hold of some.

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

hippy

FRAM does have its problems when used as if it were RAM. It might be possible to apply some sort of memory management within the CPU emulator to map what's used as RAM to Hub and what's read-only to FRAM but that adds complication and bloat and any code which expects access to 64KB RAM may not fall into neat ROM/RAM divisions.

It could be that FRAM is best used as a stop-gap until the Prop II which will much better suit above 32KB needs. Until then, an additional Propeller can provide 32KB of I2C RAM and it should be possible to create 32KB of SPI RAM the same way. It doesn't have to be serial, it could be configured with an N-bit wide bus interface. I've no idea how fast that could go or what impact it would have, but perhaps better than nothing or using FRAM.

Serial speeds are an issue but perhaps not that bad. It takes 22 cycles max to read a byte / word / long from Hub and the same could be achievable from external serial devices especially if they are paralleled-up and can deliver data-slices larger than 1-bit wide. There was some previous discussion on this but I cannot name the thread off-hand.

heater

Sadly CP/M does not really fall into ROM/RAM sections. The "fixed" OS plus boot loader is actually quite small and even they have their own variable mixed up with code.

To me the attraction of serial RAM/FRAM is the simplicity of wiring it up to a proto board or whatever so even if it is slow it's a quick thing to knock up for those who want to play.

If we have to parallel many devices to get the speed then we might as well use a parallel bus RAM anyway.

Still, I'm going to try and get some FRAMS to experiment with anyway.

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

dpeschel

heater, any luck with your RAM extension?

8080 emulation with CP/M would be a practical way to get an OS and applications running. With a Z80 emulator you might be able to duplicate the Jupiter Ace
or the Cambridge Z88, just to mention two interesting designs that may not be well known.

Personally I'd be much more interested in new designs based on the old systems, written in a more intelligible language than assembler or C. Designing the language,
interpreter, OS, and applications would be a lot of work, of course. But hey, this thread is about wish-list items.

Mike, now that I've looked at some of the OSs I have an idea of the state of the art. They seem to have barriers between the OS and the application. For example,
the device-driver cogs are loaded early in the startup process and then not disturbed. Or the OS can load entire EEPROM images and then you have to reset the
system to get back to the OS. Or the OS loads tokenized programs (I assume FemtoBasic works like that).

So is anyone working on eliminating those barriers, so the OS can coexist with loadable modules, and the OS and modules are written in the same language?
Αs I said above, the work includes desinging a new language and memory model.

Mike Green

The Propeller OS (http://forums.parallax.com/showthread.php?p=598350) was originally designed so the I/O drivers would be loaded initially into their cogs, then other programs could be loaded that didn't need the drivers to be resident in hub memory or their initialization code and they'd communicate with the drivers through a small amount of shared hub memory. That part worked. The main problem was supporting different hardware configurations (like TV / VGA displays and Hydra / Demoboard conventions for keyboard and mouse) and the basic limitations of the small memory (complicated by the need for a large display buffer). FemtoBasic was developed as a kind of scripting tool based around the I/O drivers from the Propeller OS. Revisiting that realistically requires some kind of extended memory, whether waiting for the Propeller II or adding some kind of external memory with reasonable throughput. There are all sorts of options for the latter, all of them with disadvantages of one kind or another. What RAM is available is generally parallel which takes too many I/O pins. There's no generic matching serial interface chip that could bridge the two. SPI interface FRAM is fast enough to be useful, but the potential wear problems require some special care.

heater

dpeschel: No progress on the RAM expansion yet. There's just not enough hours in a day for me at the moment.

I had a look at the Z80 idea a long while ago. It would be a lot more work to write and I convinced myself that the result would be disappointingly large and slow. So I'm not going in that direction. Perhaps others have a better ideas, they are welcome to pick up the 8080 code if required.

I remember the Jupiter Ace and the Cambridge Z88, jees we're getting old, again emulating all the required hardware would be a show stopper as well I think.

I have already been contemplating how to enable CP/M to load up and start COGs from code held in CP/M files. Basically I would do it via 8080 IN and OUT instructions, treating the spare COGs as hardware devices that DMA code into themselves. This way a cog could be loaded and started and then the CP/M application that did it could return to CP/M. Not sure what to do about SPIN programs though.

Still waiting to hear about Ale's dual Prop idea. We will never get to use all 64K then available but it might me enough to allow CP/M to run the BDS C compiler if we can hide all the serial driver/diskdriver code in the COGS without any Spin code hogging HUB RAM.

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

kwinn

Heater, dpeschel, sorry for responding to your comments sooner but I lost track of this thread.

Heater, when I have time I would certainly like to run CPM on your 8080 emulator. Do you have it posted yet? If so I will let you know how it turns out when I get the time to run it.

Peschel, I understand your fondness for the Mac and Unix. Once you are familiar with it's way of doing things you have far more power and flexibility at your fingertips than Windows provides. However if the tools you want to run are only available for Windows it's time to bite the bullet and go with Windows. There are some very inexpensive used systems that will work fine for the Prop tools. The prop was designed to be an embedded chip for controlling hardware in real time, and it does an excellent job for that. It is not suited for running general purpose operating systems, while the 8080/Z80, 6502, 6800, and some of the other 8 bit chips were. You could use the I/O pins on the propeller as the address and data bus for an external memory and run a bytecode interpreter to create an OS and applications, but considering the effort involved and the price of a PC it is not worth it.

heater

The 8080 emulator running CP/M is attached to this thread:

http://forums.parallax.com/showthread.php?p=711157

The latest release is v2.1. It is not posted it anywhere else. There are some instructions scattered in that thread which I should collate into a document at some point. Basically altair_sim.spin is the top level to compile. After download to prop it uses the programming serial link as the console port so you can talk to it from your PC with PropTerminal or such.

If you don't have an SD card with a CP/M file system on it then it should at least run as far as putting the CP/M command prompt up in your terminal. This is because I have included the CP/M binary in the Prop binary. Commands will mostly fail after that though.

If you do have an SD card you can download a CP/M floppy disk image to it using PropTerminal. There are some instructions in the thread. Then all should start to work.

WARNING: This does NOT use the FAT file system, it is CP/M, so downloading a floppy image will overwrite any DOS files you have here.

Please ask any questions on the CP/M thread.

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