Ale: In fact I use 3 jump addresses and 5 bit flags in my jump table in the Fast Spin Interpreter (source posted - see tools link in my signature for the link)
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
Chris: No. If you compile MoCoG with PROP_DEMO_BOARD and HEARTBEAT defined then it should write to dira once to set the LED pin to output and then write to outa once for every 6809 instruction, inverting the pin each time.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Then it should step through another 6809 instruction every time any key is pressed.
When I ran MocogEMU it did at least get the first register dump right. "PC=0000 20 ...." where the "20" is the first op code.
After that it seems to want to output something every second which feels like maybe you don't have SINGLE_STEP defined. In which case it would run 6809 at full speed and then print the execution speed out once per second (Which would be zero if HEARTBEAT is not defined.)
It's kind of spooky to see MoCog running on a PC.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
>Now we just need to get that PC emulation running on the prop......... lol
yes, if there is a 8086 Emulator
But probably there is a gcc for the z80. In this case we could probably to a recursive emulation if we compile the propeller emulator for cpm
In the attachment there is the source of mocog how I used it. I just replaced TV_Text.spin with EMU Text.spin and the same for the Keyboard.
If you like to compile it with other options simply do it and save the result as text.binary.
Then type
is it correct or not? If you presse a key, you will see
8 outa
0 outa
8 outa
...
outa is displayed if something is written to the ports of the propeller
I had to made some compromise in the EMU Keyboard.spn : in linux there is no kbhit() so I simply set the return flag in the keystroke funktion to always true.
What should happen is:
1) The MoCog spin starts up printing a sign on message and then starting some drivers.
2) It starts the PASM emulation COG which breaks before executing the first 6809 op.
3) The spin sees this break and prints the 6809 registers registers and a few of the 6809 RAM bytes.
4) Spin then waits for any key press then allows the PASM to continue.
5) The PASM executes one instruction.
6) The PASM breaks again before the next instruction.
7) and so on.
So after the first register dump, hitting a key should execute one op and dump the regs again.
Chris any chance a version of propsim that dumps out the addresses of each PASM instruction as they are executed. Then I could follow through the MoCog code and see where it goes wrong.
Have to be sure it's dumping the right COG somehow.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
When I get a chance I think the next thing is trying to fix the flag settings and get Motorola's assist09 debug monitor running.
So far I have yet to find a nice instruction set exerciser to test this with like EX80 for the Z80.
Heater,
This weekend I got ASSIST09 debug monitor working on the N8VEM 6809 host processor·with IO mezzanine board.· Basically its the N8VEM 6809 host processor with an IO board stacked on top (ACIA, PTM, & 2 VIAs).· Having real serial port and timer makes life much easier.· The code is unchanged from the original Motorola code except for the memory locations of ACIA and PTM and the console IO code is for an 6551 ACIA compared to whatever Motorola was using for their ACIA (MC6850, maybe sort of).
You are welcome to whatever material I have on the 6809 to help your project.
@Andrew: It's nice of you to think of MoCog and I may well want to make use of anything you have at some point but..
In case any one is wondering, MoCog is on a bit of a hold right now due to pressure of, well, everything else in life.
I've pretty much decided that it's PASM will have to be split over two (or more) COGs rather than use the current overlay system in one COG. Specially has now PhilPilgrim has shown a very neat method of making remote COG calls.
This will take a little time....
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
I'm still waiting on membership approval, but they do have a booting system I know. Not sure how useful their insights might be to you, but it is a 6809 system.
I am a member of the Glenside Color Computer Club.
We would gladly welcome a presentation of a processor upgrade for the Tandy Color·Computer 3.
The Motorola MC6809·is the·original microprocessor. ·The Hitachi HD6309 is a replacement microprocessor that can run MC6809 code, but it can also run additional op-codes that improve the overall performance of the computer if code is compiled to take advantage of the new-opcodes.
We are sponsoring a·two-day event entitled, “The 19th Annual "Last" Chicago CoCoFEST!”, held at the Holiday Inn in Elgin, Illinois on May 15-16, 2010.· You can see how the Tandy Color Computer (the “CoCo”[noparse];)[/noparse] built in·the 1980’s is still being used today, and see all the products that are still being developed for it.· Admission is $10, or you can set up your own booth at the festival (which includes an admission pass) for as low as $45.00.· I would expect about 55-75 people to attend; some travel from as far away as Florida and California.· We have about 190 members worldwide.·
Several vendors come to the CoCoFEST to sell their products that support the CoCo.· New products have been developed that allow for saving CoCo programs to thumb drives (SD cards) and PC-based servers.· More new products are expected to be announced this year.·
The CoCoFEST is not just about the CoCo. What makes the CoCoFEST interesting is the people you will meet.· We share ideas, display new and old products, and help one another.
The Tandy (TRS-80) Color Computer is ~30 years old. ·The technology may not be the greatest, compared to what’s out today, but it’s simple and useful.
Links that may be of interest to you:
Glenside Color Computer Club:·http://glensideccc.com/
YouTube 2008 CoCoFEST: http://www.youtube.com/watch?v=ZB5IyO06kR8
YouTube 2009 CoCoFEST:http://www.youtube.com/watch?v=2WhG-ZNELZI&feature=related
Thank you for·the work you are doing to preserve·the MC6809 microprocessor.· This may be the most fun you have in 8-bits.· Perhaps you can add a new level of acceleration similar to·what the HD6309 did.· You could allow an MC6809 mode, that can be switched to an HD6309 mode, that can then be switched to a·new turbo·mode, or some such thing.· Check out the·NitrOS9 operating system for the MC6809 and HD6309 microprocessor.· Perhaps you could emulate the video circuit as well. ·-John Mark Mobley
IMHO, emulating GIME is well within the Propeller capability. It will already do the 256 color artifacting seeing some activity in the CoCo scene right now, and is capable of the core resolutions seen in the GIME. Not sure about the other GIME signals however. Probably doable.
Thanks for the note. I've been out of the CoCo scene for a while, but recently picked up a CoCo 3, and am awaiting a drive pak [noparse]:)[/noparse] You guys are doing a great job with that machine, drivewire, etc...
I got mine for the 256 color work, BTW. First thing was to knock up some video on the Prop that exhibited that same behavior. Would be fun to put a prop on the cart bus too.
Just a suggestion if you hadn't noticed about long 6809 opcodes with prefixes...
There aren't significantly many and they have a simple pattern, it seems to me,
that:
$10 - either changes the register of an opcode or the length of the relative branches,
and only 1 or 2 instructions do something very different such as SUB vs CMP.
$11 - seems to mostly select another register for the opcode also.
And, before a SWI, these change which address handles the
"Software initiated interrupt".
A 16K CoCo should be very easy to emulate since the I/O at the top is very
simple stuff that doesn't need to be done electronically outside the Propeller
at all. A lot of simple parallel ports basically, some going to the mode registers
of the 6847 and 6883 which are also very simple.
6847 - One text mode, one font, several graphics modes of either 2 or 4 colors,
and 2 choices of colors, with the exception of a 2x2 color block graphics mode
with 9 colors, and a 2x3 with 4 colors (but it is virtually useless on CoCo).
6883 - Mostly combines dynamic RAM refresh with video data feed to 6847,
although it creates a few interesting anomalies the way its done. There are
4 different combos of ram/video refresh, not all useful, but one doubles the
CPU speed (unintended, more fun than useful); the 6883 emulates the 6847's
screen buffer size ambiguously, resulting in some peculiar and not very useful
text modes where characters can be sliced up and mixed together and waste
RAM (the SG8-SG24 modes); the 6883 has 2 (and only 2) memory map choices,
one is 64K of RAM, the other allows ROMs to be selected, and there are outputs to
enable each chip (RAM/ROM/IO) in the memory map. If you don't use Flex or OS/9,
you will probably be using the BASIC ROMs (in the EEPROM) and for all practical
purposes only have a 32K CoCo to emulate (in CoCo And HUBRAM) limits anyway.
This is from my memory since I don't have manuals handy atm but CoCo and 6809
were machines I really got to know well in the early 1980s; and I am also sure that
they are very well documented on the WWW.
Original Femtobasic (fb.spin in Hydra Sources) will certainly fool anyone for a few
minutes that a Propeller is emulating a CoCo. Same screen, rainbow cursor, and just
a few BASIC commands. IIRC, the color is either disabled or on the wrong frequency
though, an easy bug to find in that demo.
Hello JohnMark and welcome to the Propeller forums. That's a big world of 6809 activity you are introducing here that I have been unaware of. I'll try to find the time to look into everything that is happening. Sadly there is little chance of my making it over from Finland to Chicago[noparse]:([/noparse]
My interest in the 6809 dates from 1980 when a couple of "green" trainee engineers at the Marconi Radar Company built a 6809 SBC on a wire wrap board and then put together a debug monitor program for it. This was by way of evaluation of the chip which we soon came to prefer over all the other 8 bitters. Sadly it was never adopted for real projects within the company.
As for MoCog progress, everything for me is pretty much on hold now a days as there is a lot of "real" work to be getting on with. There are already most of the op-codes in place in the emulation and all the addressing modes. There is some work to be done on flag settings. It has been running simple code compiled with C though.
Looking at the experiences of various attempts at emulators/virtual machines here (Z80, 6502, Java byte codes) it seems that it is best to go for a single COG solution using overlays or LMM rather than to try for a multiple COG solution to get all the code in. This seems rather counter intuitive, how can overlay/LMM be quicker than raw full speed PASM in two or more COGs? Still all of the efforts I mentioned have tried multi-cog and eventually abandoned it in favour of single COG + LMM/overlay. Looks like the overheads of sharing state between COGs and synchronizing them are just too great.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Great stuff guys.
I just found out about the Propeller while researching components that could be used for Video and I/O functions on a 63C09E based computer.
I'm not sure that the propeller is the ideal substitute for a real 6809/6309, but those of you who have suggested that it could emulate a GIME chip seem to be on the right track.
But why stop there?
Higher resolutions, better I/O, sound, keyboard and mouse interfaces - all possible, freeing the processor for pure calculation.
And how about multiple processors with greatly increased RAM capacity?
The Propeller looks like it could be used to design a killer OS-9 or NitrosOS9 system.
I'm also going to look at throwing a 68K or Coldfire processor into this mix.
This is a good old thread you have dug up here. Sadly my 6809 end Z80 emlators have been on hold for a long time. To much work and life in the way and then lots of other interesting projects pop up to eat time.
Actually when I started with the Prop the idea was exactly to use a real Intel 8085 and the Prop as peripheral handler and video driver for CP/M. Same could be done for 6809 and whatever peripherals. Then it occured to me to learn some PASM and that writing a 8085 emulator in PASM would be a good way to do so.
Turns out the 8085 emulation is a good fit for the Prop as it is not such a big job, most of the code fits in COG and it runs at speeds comparable to an original chip.
The Z80 kind of grew from that. The 6809 is a bit tougher, bigger and slower.
I kind of promised myself that I would revive these emulator efforts when the Prop II comes out. Then we have enough RAM space on chip for full CP/M or other systems and the thing will run a lot faster. I got of got fed up with bolting external RAM on to the Prop and fighting over pins and such. Not to mention the much better video possibilities.
FPGA is a good way to go. I have often thought about it as VHDL/Verilog is something I'd like to learn.
Not sure about the low cost though. A quick google finds me Spartan 3 boards at over 200 dollars. Does not quite compete with my 8085 running from a Prop, a RAM and an SD card.
FPGA will make more sense for more complicated processors like 6809 and more complex peripherals.
The Cyclone IV board seems to be made by the same manufacturer that makes a widely available Cyclone II board, and will probably be available from lots of suppliers soon.
One of these Terasic DE0-Nano Cyclone IV boards is being delivered to me today:
They are available from RS, Farnell and Digi-Key for about £60.
The Cyclone IV is the latest low-cost Altera FPGA. The newer Cyclone V is supposedly in production, but doesn't seem to be available anywhere. It uses the new 28 nm TSMC process, and they are probably having problems getting them made.
Comments
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBladeProp, RamBlade, TwinBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: Micros eg Altair, and Terminals eg VT100 (Index) ZiCog (Z80), MoCog (6809)
· Search the Propeller forums (via Google)
My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm
here is the compiled mocog linux emulator version.
I wonder about the speed. Should DIRA toggle between $8 and 0 every 3 seconds?
to start simualtion:
./promsim.out
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Did you compile a new MoCog for that? You should start with MoCog compiled with the PROP_DEMO_BOARD and SINGLE_STEP defines set (no HEARTBEAT).
Then when it runs it should look like this:
Then it should step through another 6809 instruction every time any key is pressed.
When I ran MocogEMU it did at least get the first register dump right. "PC=0000 20 ...." where the "20" is the first op code.
After that it seems to want to output something every second which feels like maybe you don't have SINGLE_STEP defined. In which case it would run 6809 at full speed and then print the execution speed out once per second (Which would be zero if HEARTBEAT is not defined.)
It's kind of spooky to see MoCog running on a PC.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Post Edited (heater) : 7/17/2009 10:49:03 AM GMT
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBladeProp, RamBlade, TwinBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: Micros eg Altair, and Terminals eg VT100 (Index) ZiCog (Z80), MoCog (6809)
· Search the Propeller forums (via Google)
My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm
yes, if there is a 8086 Emulator
But probably there is a gcc for the z80. In this case we could probably to a recursive emulation if we compile the propeller emulator for cpm
In the attachment there is the source of mocog how I used it. I just replaced TV_Text.spin with EMU Text.spin and the same for the Keyboard.
If you like to compile it with other options simply do it and save the result as text.binary.
Then type
./propsim.out
and the new code will run.
Anyway I still get the same result.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
8 outa
0 outa
8 outa
...
outa is displayed if something is written to the ports of the propeller
I had to made some compromise in the EMU Keyboard.spn : in linux there is no kbhit() so I simply set the return flag in the keystroke funktion to always true.
What should happen is:
1) The MoCog spin starts up printing a sign on message and then starting some drivers.
2) It starts the PASM emulation COG which breaks before executing the first 6809 op.
3) The spin sees this break and prints the 6809 registers registers and a few of the 6809 RAM bytes.
4) Spin then waits for any key press then allows the PASM to continue.
5) The PASM executes one instruction.
6) The PASM breaks again before the next instruction.
7) and so on.
So after the first register dump, hitting a key should execute one op and dump the regs again.
PC=0005 7F D=0000 X=0000 Y=0000 U=0000 S=3000 DP=00 CC=00
03E0 44 41 41 04 CE 04 1D 8E 04 05 A6 80 40 1F A9 A1
03F0 80 10 26 0E 86 C4 0F E1 80 10 26 0E 7E 8C 04 1D
That "7F" above is the opcode about to be executed. If this was stepping nicely you could follow along with the ex6809.lst file.
Unless HEARTBEAT is defined the emulator does no output to pins.
Ah, I just found that those 0's and 8's are coming from the sdspiqasm driver. Commenting out the disk.out() gets rid of them.
Now it is just stuck after hitting return.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Have to be sure it's dumping the right COG somehow.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
./propsim -d
type h<ret> to see the commands.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
you simply call your 6809 emulator code somehow with
coginit(@6809,@data)
start the propeller emulator with
./propsim -d
then the spin interpreter is loaded an started.
Then you type return until you see the coginit instruction.
If this instruction was executed, the next cog is loaded ( in this case cog1 )
If you type "1" cog 1 will be traced.
Simply type return to trace through the single instructions.
Post Edited (Chris Micro) : 7/20/2009 3:35:46 AM GMT
This weekend I got ASSIST09 debug monitor working on the N8VEM 6809 host processor·with IO mezzanine board.· Basically its the N8VEM 6809 host processor with an IO board stacked on top (ACIA, PTM, & 2 VIAs).· Having real serial port and timer makes life much easier.· The code is unchanged from the original Motorola code except for the memory locations of ACIA and PTM and the console IO code is for an 6551 ACIA compared to whatever Motorola was using for their ACIA (MC6850, maybe sort of).
You are welcome to whatever material I have on the 6809 to help your project.
Thanks and have a nice day!
Andrew Lynch
In case any one is wondering, MoCog is on a bit of a hold right now due to pressure of, well, everything else in life.
I've pretty much decided that it's PASM will have to be split over two (or more) COGs rather than use the current overlay system in one COG. Specially has now PhilPilgrim has shown a very neat method of making remote COG calls.
This will take a little time....
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
I'm still waiting on membership approval, but they do have a booting system I know. Not sure how useful their insights might be to you, but it is a 6809 system.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
We would gladly welcome a presentation of a processor upgrade for the Tandy Color·Computer 3.
The Motorola MC6809·is the·original microprocessor. ·The Hitachi HD6309 is a replacement microprocessor that can run MC6809 code, but it can also run additional op-codes that improve the overall performance of the computer if code is compiled to take advantage of the new-opcodes.
We are sponsoring a·two-day event entitled, “The 19th Annual "Last" Chicago CoCoFEST!”, held at the Holiday Inn in Elgin, Illinois on May 15-16, 2010.· You can see how the Tandy Color Computer (the “CoCo”[noparse];)[/noparse] built in·the 1980’s is still being used today, and see all the products that are still being developed for it.· Admission is $10, or you can set up your own booth at the festival (which includes an admission pass) for as low as $45.00.· I would expect about 55-75 people to attend; some travel from as far away as Florida and California.· We have about 190 members worldwide.·
Several vendors come to the CoCoFEST to sell their products that support the CoCo.· New products have been developed that allow for saving CoCo programs to thumb drives (SD cards) and PC-based servers.· More new products are expected to be announced this year.·
The CoCoFEST is not just about the CoCo. What makes the CoCoFEST interesting is the people you will meet.· We share ideas, display new and old products, and help one another.
The Tandy (TRS-80) Color Computer is ~30 years old. ·The technology may not be the greatest, compared to what’s out today, but it’s simple and useful.
Links that may be of interest to you:
Glenside Color Computer Club:· http://glensideccc.com/
YouTube 2008 CoCoFEST: http://www.youtube.com/watch?v=ZB5IyO06kR8
YouTube 2009 CoCoFEST:http://www.youtube.com/watch?v=2WhG-ZNELZI&feature=related
Thank you for·the work you are doing to preserve·the MC6809 microprocessor.· This may be the most fun you have in 8-bits.· Perhaps you can add a new level of acceleration similar to·what the HD6309 did.· You could allow an MC6809 mode, that can be switched to an HD6309 mode, that can then be switched to a·new turbo·mode, or some such thing.· Check out the·NitrOS9 operating system for the MC6809 and HD6309 microprocessor.· Perhaps you could emulate the video circuit as well.
·-John Mark Mobley
Thanks for the note. I've been out of the CoCo scene for a while, but recently picked up a CoCo 3, and am awaiting a drive pak [noparse]:)[/noparse] You guys are doing a great job with that machine, drivewire, etc...
I got mine for the 256 color work, BTW. First thing was to knock up some video on the Prop that exhibited that same behavior. Would be fun to put a prop on the cart bus too.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!
8x8 color 80 Column NTSC Text Object
Safety Tip: Life is as good as YOU think it is!
Post Edited (potatohead) : 5/4/2010 4:30:33 AM GMT
There aren't significantly many and they have a simple pattern, it seems to me,
that:
$10 - either changes the register of an opcode or the length of the relative branches,
and only 1 or 2 instructions do something very different such as SUB vs CMP.
$11 - seems to mostly select another register for the opcode also.
And, before a SWI, these change which address handles the
"Software initiated interrupt".
A 16K CoCo should be very easy to emulate since the I/O at the top is very
simple stuff that doesn't need to be done electronically outside the Propeller
at all. A lot of simple parallel ports basically, some going to the mode registers
of the 6847 and 6883 which are also very simple.
6847 - One text mode, one font, several graphics modes of either 2 or 4 colors,
and 2 choices of colors, with the exception of a 2x2 color block graphics mode
with 9 colors, and a 2x3 with 4 colors (but it is virtually useless on CoCo).
6883 - Mostly combines dynamic RAM refresh with video data feed to 6847,
although it creates a few interesting anomalies the way its done. There are
4 different combos of ram/video refresh, not all useful, but one doubles the
CPU speed (unintended, more fun than useful); the 6883 emulates the 6847's
screen buffer size ambiguously, resulting in some peculiar and not very useful
text modes where characters can be sliced up and mixed together and waste
RAM (the SG8-SG24 modes); the 6883 has 2 (and only 2) memory map choices,
one is 64K of RAM, the other allows ROMs to be selected, and there are outputs to
enable each chip (RAM/ROM/IO) in the memory map. If you don't use Flex or OS/9,
you will probably be using the BASIC ROMs (in the EEPROM) and for all practical
purposes only have a 32K CoCo to emulate (in CoCo And HUBRAM) limits anyway.
This is from my memory since I don't have manuals handy atm but CoCo and 6809
were machines I really got to know well in the early 1980s; and I am also sure that
they are very well documented on the WWW.
Original Femtobasic (fb.spin in Hydra Sources) will certainly fool anyone for a few
minutes that a Propeller is emulating a CoCo. Same screen, rainbow cursor, and just
a few BASIC commands. IIRC, the color is either disabled or on the wrong frequency
though, an easy bug to find in that demo.
My interest in the 6809 dates from 1980 when a couple of "green" trainee engineers at the Marconi Radar Company built a 6809 SBC on a wire wrap board and then put together a debug monitor program for it. This was by way of evaluation of the chip which we soon came to prefer over all the other 8 bitters. Sadly it was never adopted for real projects within the company.
As for MoCog progress, everything for me is pretty much on hold now a days as there is a lot of "real" work to be getting on with. There are already most of the op-codes in place in the emulation and all the addressing modes. There is some work to be done on flag settings. It has been running simple code compiled with C though.
Looking at the experiences of various attempts at emulators/virtual machines here (Z80, 6502, Java byte codes) it seems that it is best to go for a single COG solution using overlays or LMM rather than to try for a multiple COG solution to get all the code in. This seems rather counter intuitive, how can overlay/LMM be quicker than raw full speed PASM in two or more COGs? Still all of the efforts I mentioned have tried multi-cog and eventually abandoned it in favour of single COG + LMM/overlay. Looks like the overheads of sharing state between COGs and synchronizing them are just too great.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
I just found out about the Propeller while researching components that could be used for Video and I/O functions on a 63C09E based computer.
I'm not sure that the propeller is the ideal substitute for a real 6809/6309, but those of you who have suggested that it could emulate a GIME chip seem to be on the right track.
But why stop there?
Higher resolutions, better I/O, sound, keyboard and mouse interfaces - all possible, freeing the processor for pure calculation.
And how about multiple processors with greatly increased RAM capacity?
The Propeller looks like it could be used to design a killer OS-9 or NitrosOS9 system.
I'm also going to look at throwing a 68K or Coldfire processor into this mix.
This is a good old thread you have dug up here. Sadly my 6809 end Z80 emlators have been on hold for a long time. To much work and life in the way and then lots of other interesting projects pop up to eat time.
Actually when I started with the Prop the idea was exactly to use a real Intel 8085 and the Prop as peripheral handler and video driver for CP/M. Same could be done for 6809 and whatever peripherals. Then it occured to me to learn some PASM and that writing a 8085 emulator in PASM would be a good way to do so.
Turns out the 8085 emulation is a good fit for the Prop as it is not such a big job, most of the code fits in COG and it runs at speeds comparable to an original chip.
The Z80 kind of grew from that. The 6809 is a bit tougher, bigger and slower.
I kind of promised myself that I would revive these emulator efforts when the Prop II comes out. Then we have enough RAM space on chip for full CP/M or other systems and the thing will run a lot faster. I got of got fed up with bolting external RAM on to the Prop and fighting over pins and such. Not to mention the much better video possibilities.
http://members.optusnet.com.au/jekent/system09/
I tried it some years ago and it worked very well.
Lots more are here, including a 68000:
http://opencores.org/projects
Not sure about the low cost though. A quick google finds me Spartan 3 boards at over 200 dollars. Does not quite compete with my 8085 running from a Prop, a RAM and an SD card.
FPGA will make more sense for more complicated processors like 6809 and more complex peripherals.
http://www.digilentinc.com/Products/Detail.cfm?NavPath=2,400,799&Prod=S3BOARD
I tried John Kent's 6809 on it some years ago. No additional hardware was required as it includes a keyboard interface and VGA.
This Altera Cyclone IV board is very good value:
http://www.ebay.co.uk/itm/FPGA-CORE-Board-EP4CE6E22-with-SDRAM-Powerful-Cyclone-IV-/290738985130?pt=LH_DefaultDomain_0&hash=item43b164d8aa
I bought one last week. Additional hardware would need to be added on a small PCB for a keyboard and VGA interface.
The Cyclone IV board looks very interesting, although I'm not keen on buying stuff that comes in limited quantities from an unreliable supply.
One of these Terasic DE0-Nano Cyclone IV boards is being delivered to me today:
http://www.terasic.com.tw/cgi-bin/page/archive.pl?Language=English&CategoryNo=139&No=593
They are available from RS, Farnell and Digi-Key for about £60.
The Cyclone IV is the latest low-cost Altera FPGA. The newer Cyclone V is supposedly in production, but doesn't seem to be available anywhere. It uses the new 28 nm TSMC process, and they are probably having problems getting them made.