@jazzed
I would think that would give hope that the Smalltalk byte-code interpreter would also fit in a COG. As obrienm mentioned, you could do garbage collection in a separate COG.
I don't suppose anyone has tried to port JNode using the JVM you mention?
I would think that would give hope that the Smalltalk byte-code interpreter would also fit in a COG. As obrienm mentioned, you could do garbage collection in a separate COG.
Actually, much of the byte-code handlers were done with overlays pulled into the cog on demand. I've had garbage collection working up to a point.
I don't suppose anyone has tried to port JNode using the JVM you mention?
JNode does not look practical right now as it requires Java6 + 256MB memory. We could have a 256MB SDRAM design, but with today's Propeller I don't think we'll have enough umph.
Wow, I hadn't realized JNode was so big! In the paper describing the Java Optimized Processor, it's clear that the JOP was designed to be an embedded processor and it hadn't occurred to me that anyone would be using it with that much memory. I saw a screenshot of JOP running JNode somewhere and that got me interested. Not so interested now.
Humanoido mentioned Smalltalk-80 for CP/M some time back, I searched the web for it, but couldn't find an existing copy. That would probably be a reasonable port for the Prop I, it's monochrome graphics would fit on hub RAM. The tipping point would hinge on whether you could fit the byte code interpreter in a COG or whether you end up interpreting an interpreter, from a performance standpoint. I would think that you'd gain a lot of insight into whether that was possible from the project to implement the Java virtual machine in a COG.-phar
I don't see Smalltalk-80 for CP/M listed in the ULTIMATE List of Propeller Languages though it was mentioned by Martin H. here in reference to languages, or continue the Parallax Forum Google search here. I would be interested in seeing a version of Smalltalk-80 for the Propeller, or even better, a small copy rendition of the early Mac GUI done on the Prop like this one found here by Lucas68.
Unfortunately, most older softwares such as Windows 1.01 AKA "The Big Ugly Green" are getting impossible to find. Possibly by the copyright laws... ARGH...
And, thanks to you guys, I dived down into the computing history at www.oldcomputers.net - it's intriguing! Too bad I was not born in the early history of Computer Rages (born in '88... sigh.)
And, I would want to do IMSAI clone, as it's doable on Propeller! (I know it's not for the timids. Only a true hackers would succeed in running this thing.)
There is no Windows 1.0 around any more because it was basically useless. I don't think there is any possible reason to miss it. It was not any kind of significant "landmark" in the history of computers.
Yea. Ever wonder why I called it "The Great Big Ugly Green"? It's the ugly colors that's hard on eyes, which along with being temperamental, that ensued its demise. Microsoft tried to sell Windows 1.01, but failed miserable. Only Windows 2.03 came close (until Apples, Inc. sued them since Windows 2.0 used identical menu button styles as Lisa/Macintosh GUI shells.), but also failed - what those previous Windows failed, Windows 3.0 and 95 succeed.
And, yes, IMSAI clone may be easier than said, since Propeller chip (and yes, your favorite AVR / PIC microcontrollers still can be used here!) is pretty simple in sense when it comes to programming it via switches (it's the addressable inputs on Propeller's pinout that makes our lives easier).
Here's another suggestion - Atari TOS is a relatively compact, windowed OS. Written for the Motorola 68000 chip, it featured a version of DR's GEM, fit in 192KB of ROM and the source code to TOS 1.x was published in the Atari ST Internals book by Data Becker/Abacus Software. TOS ran well with 512KB or 1024 KB of RAM. Size wise - this should fit on a Propeller C3 board. Now we just a volunteer to write a 68000 emulator for the Propeller.
I think the IMSAI emulation with the Prop is quite straight forward. It's very similar to the ALTAIR. As long as you don't want the S100 bus hardware emulated as well.
The ALTAIR emulation on the Prop done already since the days of PropAltair. It can run the early ALTAIR software like MicroSoft BASIC and it can run CP/M for the ALTAIR.
The missing part is the LEDS and switches and a nice front panel. Using something like a DracBlade board these could be easily added via a little IO expantion. Or use a second Prop to provide the I/O. Use a TriBlade board.
Of course there are now improved Z80 emulators for the Prop from which to start with. My ZiCog and PullMoll's qz80.
We may now have the RAM available for the Prop to fit TOS but it will be very slow. The 68000 is a huge beast to think about emulating on a Prop.
I have a half done 6809 emulator which is already so much bigger than say a 8080 or Z80 and so much slower that I wonder if I will ever continue with it.
My 6809 and other emulations will look much better with Prop II but I still think things like 8086 and 68000 will be too much.
x86 and 68k CPU emulation is possible with Propeller, at least if you're willing to pay for an arm or two. 68k is "huge" compared to Propeller. In my opinion, up to 68030 can be emulated, since there are some limit to how much as you can push the Propeller chip's limit. (68060 - 68070 is pretty much out of question even with Propeller II - they're superscalar - 68070 being out-of-order processor, the same CPU used in the absolutely last line of 68k-based Macintosh before Apples, Inc. switched to PowerPC CPUs, diffused by the same company that sold them 68k, Motorola Semiconductors, Inc. Motorola Semiconductors, Inc. is now Freescale, Inc. if you didn't know about that.)
Meanwhile, I'm still thinking about doing delayed issue execution on Propeller II - which may make 68070 emulation possible, at least in theory. Maybe not. (It's largely due to COG RAM size limit.)
IMSAI S100 can be controlled by cheap DSP (or PIC) talking to the Propeller arrays (At least in my opinion...)
P.S. I wouldn't dream of running 32-bit x86 instructions on Propeller I since the COGs' pipelines are way too narrow, at least compared to 486.
16-bit is fine, since they have relatively simple GPR machine models, compared to even classical Pentium's machine model (which is extremely complex).
P.S.S. Heater, I think emulation may be a bit faster in C++ than with Spin. Just my two cents. (I don't intend to reinvent the wheel here unless I'm that desperate... o___o Anyways, the problem with most CPU emulators as far as you can see, is that Propeller may not have enough call stacks to hold all of the extra magics compared to running everything on advanced version of Coldfire 68k [v5] chip. Again, it's just my two cents.)
Motorola never produced a 68070, Philips did produce a 68k variant called the 68070 but it's ancient(mid 80's) - basically a 68000 with a different internal architecture with peripherals that had limited production.
...Heater, I think emulation may be a bit faster in C++ than with Spin.
Nobody in their right mind is creating emulations in SPIN. It just too slow. OK, actually my first 8080 emulation was in Spin, but just to prove to myself I got the logic right enough to run 8080 programs. After that it soon moved moved to PASM.
I can see no advantage to using C++ for such emulations. Speed wise or even logically.
The only way to run C++ on the Prop currently is with the Zog interpreter, so an emulation in C++ would be terrible slow.
Suska (http://www.experiment-s.de/en) is a project to put an Atari ST on an FPGA. Or at least everything but the memory chips. I know there have been a couple Prop-FPGA projects in the past, I wonder if you could piggyback this onto one of them?
I am an old mini-computer idiot! At some time soon (when time permits and I have completed my other prop tasks) I will do an ICL System 25 mini-computer emulation. I have already done this on a 486 targeted asm 30MHz system. I believe a prop would do this really well. Some of us are just plain stupid :-)
Heater... I see your point. I just use C++ only for very complex stuff. SPIN for something stupid simple (such as when I am really bored). ASM is still faster, though. (x86 ASM was what I would accustom with fairly quickly, I remember one time making funky images (mirrored image of MS-DOS) on GeForce 7600 due to wrong BIOS IRQ requests, still amusing, though.)
Why isn't 68070 out, is fairly true. Motorola killed it in favor of 88k (which also died, due to lack of funds in the researchs and not enough interests in this CPU), which both were switched in favor of PowerPC 602 / 603 / 604 CPUs used in first PowerPC-based Macintosh computers.
(68070 may make a comeback, in the ColdFire chip, maybe... Maybe not...)
Cluso99, yes. It's possible. the only problem is RAM size, which Jazzed got over with by shoving SDRAM command issues / reference clocks in the boot firmwares he wrote. I applaud Jazzed for getting SDRAM memory chips to work with Propeller.
I don't think it would be easy to piggy back a Prop to a FPGA configured to emulate a 68k and either the Atari ST or Amiga chipsets. A better alternative would be uploading a Zylin core along with the VHDL of the Amiga's audio/video chipset. And given the Zylin doesn't use too much FPGA resources, you'd have a nifty 32bit system.
Another approach would be to just use the FPGA along with off-chip memory to do audio, keyboard and video processing(for starters you could use the Amiga's since it's already been done) whilst the Prop pretends to be a Zylin.
The nice thing about the FPGA it does allow you to stretch the capacities of older less powerful chips such as the Z80 or even the 68000.
Batang, Thank for jogging my memory. Forgot about the Amiga operating system...
What is really nifty about the source codes here is that you guys can literally modify the so-called state machines to be statically similar to the Propeller's inner workings.
Also, you can add it or drop it. Although I think FPGA or even XMOS chips or whatever beefy you hold in your hands would be a bit better. Okay, I understand that some of you are gripping on Propeller firmly.
If you only want to use Propeller chip, that's it, here's better method: Get four of them and interlink them and connect it to FPGA (to be treated as a Northbridge / Southbridge chipset) and give 'em HUGE RAM like 128 to 512 MB SDRAM / DDR (depending on what memory controller you got on FPGA as a part of deal). That oughta solve some slowdown issues: Amiga OS is very complex in respect, and MUCHO powerful than even Microsoft Windows, but came pretty close to Linux (although Linux wasn't introduced back then).
For anyone who is interested, although I never found a copy of Smalltalk-80, I did find the sources to GNU Smalltalk circa 1991. The docs say that it is source code compatible with Smalltalk-80, although not byte-code compatible (I'm guessing Smalltalk-80 had not been released into the public domain yet) and that it implements the language described in the Bluebook (the Smalltalk bible at the time). The sources are a mix of C and Smalltalk source code. From the little skimming I did, it appears the C implements both the byte code compiler and interpreter, so I imagine you compile that and then use it to compile the Smalltalk sources to create the initial image (that will probably come as a big disappointment to anyone who wants to modify the byte-code compiler from within Smalltalk, lol).
The Prop will take a serious performance hit no matter what sort of external memory configuration you have, it's just the way the Prop is designed as a microcontroller and not microprocessor. This was discussed at length on a prior thread dealing with using a CPLD to help with external memory. There is no current workaround.
BTW replicating a complex Intel chipset is pretty much out the league of your typical one man shop and is not needed in order to get multiple Props to communicate with one another. Also most of it is not needed anyway unless you think the Prop needs a PCI bus.
rod1963, then how come are everyone using it? It's the easter eggs in propeller 1 that keep peoples busy trying ot find a better use for it.
And, I knew it will still get performance hit because it's not Out-of-Order processor. (Out-of-order executing microcontrollers always fares better than this chip - I knew how the CPUs work.
it's the execution times that matters, not how CPU are built. The performance hits usually occurs at pipeline decoding branches, because that's where the queues are.)
If I want to turn it into an OOOE processor, then I gotta work for it (ie; hacking its inner works).
P.S. The Intel chipsets sucks. They are much slower than the other brands (AMD and NVIDIA both are faster in respect - I have used numerous systems, no matter what CPU I used - speed difference are totally noticable), except for most famous for its age, i440BX. (Yes, even faster Pentium !!! will still work.) Why so? Slower paging buffer-bouncing was the only thing that held the accompanying CPUs from going much faster, such as trying to switch between PCI and USB IRQ queuing and via the CPU pipeline transaction (it was FINALLY given overhaul within Nehalem microarchitecture...)
The only reason FPGA-based chipset is need, it's to provide the access to external memory and be able to provide smarter switching fabrics across multiple Propeller microcontrollers.
Comments
I would think that would give hope that the Smalltalk byte-code interpreter would also fit in a COG. As obrienm mentioned, you could do garbage collection in a separate COG.
I don't suppose anyone has tried to port JNode using the JVM you mention?
-phar
JNode does not look practical right now as it requires Java6 + 256MB memory. We could have a 256MB SDRAM design, but with today's Propeller I don't think we'll have enough umph.
-phar
And, thanks to you guys, I dived down into the computing history at www.oldcomputers.net - it's intriguing! Too bad I was not born in the early history of Computer Rages (born in '88... sigh.)
And, I would want to do IMSAI clone, as it's doable on Propeller! (I know it's not for the timids. Only a true hackers would succeed in running this thing.)
Excellent idea. I started out wanting to make an Altair clone:
http://forums.parallax.com/showthread.php?t=101495&highlight=propaltair
Which morphed into ZiCog:
http://forums.parallax.com/showthread.php?t=110804&highlight=propaltair
And now there is the Z80 emulator from PullMoll:
http://forums.parallax.com/showthread.php?t=121579&highlight=propaltair
So you have a lot to start with for an IMSAI.
I did a search through my old junk trying to find the oldest Smalltalk I had used.
That would was Smaltalk/V by Digitalk in 1986. It appears to have been an MSDOS application.
Upon reviewing the Byte August 1981 Smalltalk issue I find that they mentioned that no PC Smaltalk, only the Xerox Star office terminal at $16000
Perry
Out of curiosity, was there ever a Windoze 2 ??
My original Nascom ran on a mixture of S100 cards and home constructed ones.
http://en.wikipedia.org/wiki/Windows_2.0
And, yes, IMSAI clone may be easier than said, since Propeller chip (and yes, your favorite AVR / PIC microcontrollers still can be used here!) is pretty simple in sense when it comes to programming it via switches (it's the addressable inputs on Propeller's pinout that makes our lives easier).
I think the IMSAI emulation with the Prop is quite straight forward. It's very similar to the ALTAIR. As long as you don't want the S100 bus hardware emulated as well.
The ALTAIR emulation on the Prop done already since the days of PropAltair. It can run the early ALTAIR software like MicroSoft BASIC and it can run CP/M for the ALTAIR.
The missing part is the LEDS and switches and a nice front panel. Using something like a DracBlade board these could be easily added via a little IO expantion. Or use a second Prop to provide the I/O. Use a TriBlade board.
Of course there are now improved Z80 emulators for the Prop from which to start with. My ZiCog and PullMoll's qz80.
We may now have the RAM available for the Prop to fit TOS but it will be very slow. The 68000 is a huge beast to think about emulating on a Prop.
I have a half done 6809 emulator which is already so much bigger than say a 8080 or Z80 and so much slower that I wonder if I will ever continue with it.
My 6809 and other emulations will look much better with Prop II but I still think things like 8086 and 68000 will be too much.
Meanwhile, I'm still thinking about doing delayed issue execution on Propeller II - which may make 68070 emulation possible, at least in theory. Maybe not. (It's largely due to COG RAM size limit.)
IMSAI S100 can be controlled by cheap DSP (or PIC) talking to the Propeller arrays (At least in my opinion...)
P.S. I wouldn't dream of running 32-bit x86 instructions on Propeller I since the COGs' pipelines are way too narrow, at least compared to 486.
16-bit is fine, since they have relatively simple GPR machine models, compared to even classical Pentium's machine model (which is extremely complex).
P.S.S. Heater, I think emulation may be a bit faster in C++ than with Spin. Just my two cents. (I don't intend to reinvent the wheel here unless I'm that desperate... o___o Anyways, the problem with most CPU emulators as far as you can see, is that Propeller may not have enough call stacks to hold all of the extra magics compared to running everything on advanced version of Coldfire 68k [v5] chip. Again, it's just my two cents.)
Motorola never produced a 68070, Philips did produce a 68k variant called the 68070 but it's ancient(mid 80's) - basically a 68000 with a different internal architecture with peripherals that had limited production.
Sometimes I just don't understand you:
Nobody in their right mind is creating emulations in SPIN. It just too slow. OK, actually my first 8080 emulation was in Spin, but just to prove to myself I got the logic right enough to run 8080 programs. After that it soon moved moved to PASM.
I can see no advantage to using C++ for such emulations. Speed wise or even logically.
The only way to run C++ on the Prop currently is with the Zog interpreter, so an emulation in C++ would be terrible slow.
-phar
Why isn't 68070 out, is fairly true. Motorola killed it in favor of 88k (which also died, due to lack of funds in the researchs and not enough interests in this CPU), which both were switched in favor of PowerPC 602 / 603 / 604 CPUs used in first PowerPC-based Macintosh computers.
(68070 may make a comeback, in the ColdFire chip, maybe... Maybe not...)
Cluso99, yes. It's possible. the only problem is RAM size, which Jazzed got over with by shoving SDRAM command issues / reference clocks in the boot firmwares he wrote. I applaud Jazzed for getting SDRAM memory chips to work with Propeller.
I don't think it would be easy to piggy back a Prop to a FPGA configured to emulate a 68k and either the Atari ST or Amiga chipsets. A better alternative would be uploading a Zylin core along with the VHDL of the Amiga's audio/video chipset. And given the Zylin doesn't use too much FPGA resources, you'd have a nifty 32bit system.
Another approach would be to just use the FPGA along with off-chip memory to do audio, keyboard and video processing(for starters you could use the Amiga's since it's already been done) whilst the Prop pretends to be a Zylin.
The nice thing about the FPGA it does allow you to stretch the capacities of older less powerful chips such as the Z80 or even the 68000.
Here's a example of a Z80 and FPGA
http://www.retroleum.co.uk/v6z80p/
Take a look at:
http://aros.sourceforge.net/
Cheers
What is really nifty about the source codes here is that you guys can literally modify the so-called state machines to be statically similar to the Propeller's inner workings.
Also, you can add it or drop it. Although I think FPGA or even XMOS chips or whatever beefy you hold in your hands would be a bit better. Okay, I understand that some of you are gripping on Propeller firmly.
If you only want to use Propeller chip, that's it, here's better method: Get four of them and interlink them and connect it to FPGA (to be treated as a Northbridge / Southbridge chipset) and give 'em HUGE RAM like 128 to 512 MB SDRAM / DDR (depending on what memory controller you got on FPGA as a part of deal). That oughta solve some slowdown issues: Amiga OS is very complex in respect, and MUCHO powerful than even Microsoft Windows, but came pretty close to Linux (although Linux wasn't introduced back then).
-phar
The Prop will take a serious performance hit no matter what sort of external memory configuration you have, it's just the way the Prop is designed as a microcontroller and not microprocessor. This was discussed at length on a prior thread dealing with using a CPLD to help with external memory. There is no current workaround.
BTW replicating a complex Intel chipset is pretty much out the league of your typical one man shop and is not needed in order to get multiple Props to communicate with one another. Also most of it is not needed anyway unless you think the Prop needs a PCI bus.
And, I knew it will still get performance hit because it's not Out-of-Order processor. (Out-of-order executing microcontrollers always fares better than this chip - I knew how the CPUs work.
it's the execution times that matters, not how CPU are built. The performance hits usually occurs at pipeline decoding branches, because that's where the queues are.)
If I want to turn it into an OOOE processor, then I gotta work for it (ie; hacking its inner works).
P.S. The Intel chipsets sucks. They are much slower than the other brands (AMD and NVIDIA both are faster in respect - I have used numerous systems, no matter what CPU I used - speed difference are totally noticable), except for most famous for its age, i440BX. (Yes, even faster Pentium !!! will still work.) Why so? Slower paging buffer-bouncing was the only thing that held the accompanying CPUs from going much faster, such as trying to switch between PCI and USB IRQ queuing and via the CPU pipeline transaction (it was FINALLY given overhaul within Nehalem microarchitecture...)
The only reason FPGA-based chipset is need, it's to provide the access to external memory and be able to provide smarter switching fabrics across multiple Propeller microcontrollers.