Yes I think this can be done on a single prop (plus external memory). LMM for the opcode emulations. I'm assuming we have an existing graphics driver (I've been using Kye's 160x120 driver with 64 colors, but there is a tile driver that can go 256x240. One cog devoted to sound. One cog for video (?? 2). One for LMM. One for external ram. One for keyboard.
I can help with the big picture stuff but I don't know 6502 opcodes very well.
Pullmoll's code recycled I think one of the cog load areas, but not the rest, so it did end up with quite a bit of wasted hub space. With the cogjects code I'm writing I think it ought to be possible to free up more hub ram for video.
Just a thought from someone who's writing an emulator for a different machine (IBM 1130)...
Your 6510 emulator will probably have to be a single cog. Since the 6510 ran at 1 mHz, and a cog runs at 20 mHz, you may find that the emulator runs much slower than the original 64. My highly-tuned emulation of the 1130, of which the original hardware ran at about .1 - .2 mHz (yes, that's tenths of a mHz) on a good day, downhill, with premium gas... runs only 4 times faster.
I think the rule of thumb when emulating a cpu is that the emulation will typically run at about 1/50 to 1/100 of the emulating cpu's clock.
That said, good luck with the project... hopefully you can prove me wrong!
Your observation about emulator speed is probably a good ball park guess.
I do believe that for the 8085, Z80 emulators on the Prop we have been doing better than 1/50 performance for some instructions.
Thing is the slowest original 8085, as an example, had a 3MHz clock. This was divided by two to give a 1.5MHz two phase clock. The fastest instructions then took 4 clocks whilst the slowest took 10 clocks. The result being that the resulting execution speed is between 150000 and 375000 instructions per second.
Now on the Prop if we roughly guess that our 20MIPs COG takes 50 instructions to emulate a target opcode that's 400000 instructions per second.
Not bad, we can accurately emulate the sluggishness of those early machines:)
Perhaps Dr_A or someone who has played a lot with both original Z80s and Prop emulations has some comparative performance figures.
With Pullmoll's QZ80 on an 80MHz DracBlade I get about 2MHz (ish) Z80. That was enough to get me back my cherrished Nascom (1).
On the 6510, didn't it do sneeky thing on different clock phases ??? would that make it 2MHz ?? or was that just the VDU memory access ?? ( its been decades since I had a C64, or my Beeb)
@Ahle2:
As the code for the C64 has been written already the undocumented opcodes used by every piece of software are known, do you happen to know how many of those opcodes are used and or how often ? Because shooting for a perfect emulation may not be the best approach... me thinks...
Let's say you want to run "Skate or Die" (I don't make it that easy anyways...) ;-)
Games prio to ~1988 are almost certain to use only documented opcodes.
Games after that, maybe 70% will work without illegal opcode support.
Too bad the coolest and most impressive games out there will not work. (Manfred Trenz games, Rowlands brother games)
My guts tells me that "Skate or Die" will fall into the category of games not using illegal opcodes.
VIC-20
Operating system Commodore BASIC 2.0
CPU MOS Technology 6502
Memory 5 KB - 64 KB
Graphics VIC 176 x 184 3-bpp
Sound 3x square, 1x noise, mono
OBC
The graphic on the Vic is not 3-bpp in any mode, at most 2-bpp in multicolor lowres mode. (88x184)
In highres (176x184), the Vic could use only 1-bpp.
Actually the Vic had a palette of 16 colors and NOT 8 colors as stated on many sites on the net.
I have no idea about many undocumented 6502 opcodes may be used in various games and other programs. This should not be a huge stumbling block. Just get the documented ops working nicely first and trap out any undocumented instructions. As people attempt to run this and that program the unused ops will show up in the trap handler and can be implemented as and when required.
I like the idea of a Good prop based C64 emulator, the C64 was my first 'Personal Computer'.
On the VIC emulation, I wish who ever tackles this one a ton of luck, especially in getting the FLI/SuperFLI modes working, these tricks of the VIC II are difficult to emulate at best. On the flip side; I do not see the sprite handling to be to difficult. It would seem that the VIC emulation would have to be single cog to leave space for everything else.
Also if I may recommend using 2 CY7C199CN SRAMs for this as they can be easily used even by relative novice hobbyists, and the interface can be multiplexed with little concern (as they are static RAM), not to mention that they only cost $1.40 USD each.
@davidsaunders
Looking at comments you have made in different threads I think you may be the right person to prove me wrong when I say it would be difficult to make a Vic II emulation in less than 4 cogs. ;P
Of course without sprites it would be easy to make it run in just one cog, but we are talking full sprites support and maybe even hardware collision detection.
Are you up for the challange?
Combining SIDcog + q6502 + VIC2cog (your future VIC II emulation) + chip x + chip y ... we might see a C64 emulator running on a prop (or two).
Also if I may recommend using 2 CY7C199CN SRAMs for this as they can be easily used even by relative novice hobbyists, and the interface can be multiplexed with little concern (as they are static RAM), not to mention that they only cost $1.40 USD each.
I could locate a datasheet on that. The link to cypress is broken. It looks like we return to our old problem of using the lions share of pins for memory again. Have you got the datasheet for that chip handy?
It looks like we return to our old problem of using the lions share of pins for memory again.
Using 8 SPI-RAM chips (like my attachment or maybe a board designed for Hydra) would require only 10 pins and when used with a cache, performance would be fine. It would be expensive though since just the chips would cost almost $20. Using a cache would of course allow your emulator to run on any supported external memory platform.
It would be very easy to hook up 8 chips on a prototyping board, with headers for whichever platform you want.
Or, you could use a proto board to connect Jazzed's 8 chip board to a different pinout, or two of Ray's boards, or two FlexMem's.
Any of the above four solutions would provide you with a 10 pin, 8 bit wide serial memory
I like Jazzed's solution for his new 32 pin socket platform.
As discussed a long time ago in the FlexMem thread, the reason I never made an 8 bit spi ram board was that I did not think enough people would buy it.
I do believe that for the 8085, Z80 emulators on the Prop we have been doing better than 1/50 performance for some instructions.
Heater, after taking a more detailed look into the execution times of the 6502 instructions, I am now inclined to believe that it could be done.
The 1130 could execute most instructions in 1-3 clocks. Shifts/multiply/divide were, of course, exceptions (a divide could take 40-50 clocks!). Apparently the 6502 takes about 2-4 clocks for each instruction - allowing for 40 to 80 (or more, for the fancier versions) PASM instructions per instruction.
It was the first "real" computer that I was able to use;
A fairly simple instruction set, and bare-bones I/O (card reader, 80 LPM printer, 1 MB disk); and
The typical configuration was 8K words (16k bytes), so I don't have to use external ram (much faster).
I currently have the CPU emulation completed, along with the IPL (Initial Program Load) from the emulated card device. Still working on the various device emulators.
A side project (or derailment?) is to use an electronic typewriter as the "console" keyboard/printer. The 1130 used a modified selectric ("golfball") printer at 15 CPS; I have a Brother typewriter that I picked up on eBay for less than $20. It's the same typewriter that is used here: http://numist.net/post/2010/project-typewriter.html
I have a challenge that I am working on now; Given me by jazzed. And I also wish to finish my UXGA high color driver. If it has not been done by then I am interested (no promises yet).
Here it is. Also I think that it should be fairly easy to multiplex the data and address pins with a couple latches and 74x244s, thus reducing the number of pins required.
I have no idea about many undocumented 6502 opcodes may be used in various games and other programs. This should not be a huge stumbling block. Just get the documented ops working nicely first and trap out any undocumented instructions. As people attempt to run this and that program the unused ops will show up in the trap handler and can be implemented as and when required.
Using 8 SPI-RAM chips (like my attachment or maybe a board designed for Hydra) would require only 10 pins and when used with a cache, performance would be fine. It would be expensive though since just the chips would cost almost $20. Using a cache would of course allow your emulator to run on any supported external memory platform.
Using my upcoming spi-ram-driver, we can have 20 Mbit/s from/to the spi-ram from each cog (using the video generator)
I have a challenge that I am working on now; Given me by jazzed. And I also wish to finish my UXGA high color driver. If it has not been done by then I am interested (no promises yet).
Maybe I can get the bare minimum driver working without sprites and then we can work from there?
At least we will be able to run the basic interpreter and load some spectrum converted games like "The trapdoor" without sprites.
Doesn't the NES emulator more or less prove out we can get a 6502 at speed?
Yeah, I think so. The NES has got a clock rate of 1.72 Mhz, while the C64 has clock rate of about 1 Mhz.
If a NES emulator runs in full speed, a C64 emulator definitely will too.
Guys,
I know this is not the most relevant post...
But I need to write down, that I'm very interested and excited about this project. For reasons those are obvious for everyone else who are interested too.
I doubt I can help, since I've no experience with emulating codes at all, but really wish for you all and for the project success.
Amazes me from time to time, that how many people are there who have the same sweet emotions and everlasting memories about that good old C64...
Maybe I can get the bare minimum driver working without sprites and then we can work from there?
Sounds great. Do remember that the timing has to be perfect relative to the 6510, otherwise most of the video tricks will NOT work (FLI, SuperFLI, xFLI, etc...).
Comments
VIC-20
Operating system Commodore BASIC 2.0
CPU MOS Technology 6502
Memory 5 KB - 64 KB
Graphics VIC 176 x 184 3-bpp
Sound 3x square, 1x noise, mono
OBC
I can help with the big picture stuff but I don't know 6502 opcodes very well.
Pullmoll's code recycled I think one of the cog load areas, but not the rest, so it did end up with quite a bit of wasted hub space. With the cogjects code I'm writing I think it ought to be possible to free up more hub ram for video.
Your 6510 emulator will probably have to be a single cog. Since the 6510 ran at 1 mHz, and a cog runs at 20 mHz, you may find that the emulator runs much slower than the original 64. My highly-tuned emulation of the 1130, of which the original hardware ran at about .1 - .2 mHz (yes, that's tenths of a mHz) on a good day, downhill, with premium gas... runs only 4 times faster.
I think the rule of thumb when emulating a cpu is that the emulation will typically run at about 1/50 to 1/100 of the emulating cpu's clock.
That said, good luck with the project... hopefully you can prove me wrong!
Walter
Your observation about emulator speed is probably a good ball park guess.
I do believe that for the 8085, Z80 emulators on the Prop we have been doing better than 1/50 performance for some instructions.
Thing is the slowest original 8085, as an example, had a 3MHz clock. This was divided by two to give a 1.5MHz two phase clock. The fastest instructions then took 4 clocks whilst the slowest took 10 clocks. The result being that the resulting execution speed is between 150000 and 375000 instructions per second.
Now on the Prop if we roughly guess that our 20MIPs COG takes 50 instructions to emulate a target opcode that's 400000 instructions per second.
Not bad, we can accurately emulate the sluggishness of those early machines:)
Perhaps Dr_A or someone who has played a lot with both original Z80s and Prop emulations has some comparative performance figures.
How this pans out for the 6502 I have no idea.
That IBM emulation is an interesting project.
On the 6510, didn't it do sneeky thing on different clock phases ??? would that make it 2MHz ?? or was that just the VDU memory access ?? ( its been decades since I had a C64, or my Beeb)
Games prio to ~1988 are almost certain to use only documented opcodes.
Games after that, maybe 70% will work without illegal opcode support.
Too bad the coolest and most impressive games out there will not work. (Manfred Trenz games, Rowlands brother games)
My guts tells me that "Skate or Die" will fall into the category of games not using illegal opcodes.
/Ahle2
In highres (176x184), the Vic could use only 1-bpp.
Actually the Vic had a palette of 16 colors and NOT 8 colors as stated on many sites on the net.
/Ahle2
I have no idea about many undocumented 6502 opcodes may be used in various games and other programs. This should not be a huge stumbling block. Just get the documented ops working nicely first and trap out any undocumented instructions. As people attempt to run this and that program the unused ops will show up in the trap handler and can be implemented as and when required.
On the VIC emulation, I wish who ever tackles this one a ton of luck, especially in getting the FLI/SuperFLI modes working, these tricks of the VIC II are difficult to emulate at best. On the flip side; I do not see the sprite handling to be to difficult. It would seem that the VIC emulation would have to be single cog to leave space for everything else.
Also if I may recommend using 2 CY7C199CN SRAMs for this as they can be easily used even by relative novice hobbyists, and the interface can be multiplexed with little concern (as they are static RAM), not to mention that they only cost $1.40 USD each.
Looking at comments you have made in different threads I think you may be the right person to prove me wrong when I say it would be difficult to make a Vic II emulation in less than 4 cogs. ;P
Of course without sprites it would be easy to make it run in just one cog, but we are talking full sprites support and maybe even hardware collision detection.
Are you up for the challange?
Combining SIDcog + q6502 + VIC2cog (your future VIC II emulation) + chip x + chip y ... we might see a C64 emulator running on a prop (or two).
/Ahle2
I could locate a datasheet on that. The link to cypress is broken. It looks like we return to our old problem of using the lions share of pins for memory again. Have you got the datasheet for that chip handy?
OBC
OBC
Any interest in an 8 chip board for Hydra?
OBC
A Propeller ProtoBoard compatible header board would be easy to do ... VDD, VSS, D0..7.
It would be very easy to hook up 8 chips on a prototyping board, with headers for whichever platform you want.
Or, you could use a proto board to connect Jazzed's 8 chip board to a different pinout, or two of Ray's boards, or two FlexMem's.
Any of the above four solutions would provide you with a 10 pin, 8 bit wide serial memory
I like Jazzed's solution for his new 32 pin socket platform.
As discussed a long time ago in the FlexMem thread, the reason I never made an 8 bit spi ram board was that I did not think enough people would buy it.
Heater, after taking a more detailed look into the execution times of the 6502 instructions, I am now inclined to believe that it could be done.
The 1130 could execute most instructions in 1-3 clocks. Shifts/multiply/divide were, of course, exceptions (a divide could take 40-50 clocks!). Apparently the 6502 takes about 2-4 clocks for each instruction - allowing for 40 to 80 (or more, for the fancier versions) PASM instructions per instruction.
Certainly in the realm of possiblity.
Yes. I chose the machine because:
It was the first "real" computer that I was able to use;
A fairly simple instruction set, and bare-bones I/O (card reader, 80 LPM printer, 1 MB disk); and
The typical configuration was 8K words (16k bytes), so I don't have to use external ram (much faster).
I currently have the CPU emulation completed, along with the IPL (Initial Program Load) from the emulated card device. Still working on the various device emulators.
A side project (or derailment?) is to use an electronic typewriter as the "console" keyboard/printer. The 1130 used a modified selectric ("golfball") printer at 15 CPS; I have a Brother typewriter that I picked up on eBay for less than $20. It's the same typewriter that is used here: http://numist.net/post/2010/project-typewriter.html
Walter
I totally agree with all of what you said.
I'm sorry.
Using my upcoming spi-ram-driver, we can have 20 Mbit/s from/to the spi-ram from each cog (using the video generator)
Maybe I can get the bare minimum driver working without sprites and then we can work from there?
At least we will be able to run the basic interpreter and load some spectrum converted games like "The trapdoor" without sprites.
Yeah, I think so. The NES has got a clock rate of 1.72 Mhz, while the C64 has clock rate of about 1 Mhz.
If a NES emulator runs in full speed, a C64 emulator definitely will too.
I know this is not the most relevant post...
But I need to write down, that I'm very interested and excited about this project. For reasons those are obvious for everyone else who are interested too.
I doubt I can help, since I've no experience with emulating codes at all, but really wish for you all and for the project success.
Amazes me from time to time, that how many people are there who have the same sweet emotions and everlasting memories about that good old C64...