Amiga.org
Operating System Specific Discussions => Other Operating Systems => Topic started by: trekiej on May 08, 2011, 09:43:11 AM
-
I was wondering if some one thought about widening the bus for the 6510 processor.
Eight bit opcode and an eight bit or 16 bit operand for a fpga c64 sound interesting.
-
I was wondering if some one thought about widening the bus for the 6510 processor.
Eight bit opcode and an eight bit or 16 bit operand for a fpga c64 sound interesting.
There is already a *real* 16 bit replacement for the 6510, the WDC 65816, designed by Bill Mensch, one of the original 6510 designers. It was available from 1984, and has been used in the Apple IIgs for example, and is still manufactured as well as possible to license as a core for ASICs. There's also a drop-inc 6502 compatible version, the 65802, but that's more limited for obvious reasons (no wider external bus)
Since there's been accelerators for the C64 using it too, I'm sure someone will do an FPGA version eventually if there isn't one already.
-
I have heard of the 65C816 and have one.
Maybe some one could do a core for the MCC 216.
-
The 65C816 was Super Nintendo's main CPU, too :D
-
The 65C816 was Super Nintendo's main CPU, too :D
And it was ripped a new one by Sega's 16bit console with 68000 launched 2 years earlier ;)
-
The Chameleon is a C64 cart that offers an accelerated 6510 CPU for the c64 and more ram, drive emulation along with a VGA output. It is all in beta at the moment but progressing well.
A minimig core with 020 and 8 megs of fast ram was just released as well.
The Chameleon also supports a standalone mode that does not need to be connected to a C64 to operate.
http://www.syntiac.com/chameleon.html
-
I would like a chameleon too.
I am wondering if a wider buss is possible in the design.
I hear that the c64 has a 256 byte memory page.
It is suppose to be faster if one keeps code inside that page instead of trying to move
Address H and Address L all the time.
-
I would like a chameleon too.
I am wondering if a wider buss is possible in the design.
Given that the FPGA is big enough to handle the Minimig core, I'm sure it'd be possible. It's back to whether or not someone spends the time updating the cores...
I hear that the c64 has a 256 byte memory page.
It is suppose to be faster if one keeps code inside that page instead of trying to move
Address H and Address L all the time.
Well, there are a few different things: If you want to do indexed accesses, it's faster to do that in the 256 byte zero page. Also, if you cross a 256 byte boundary I believe you incur a 1 cycle cost, so you'd want to be a bit careful about the location of tight inner loops etc. (and in demo effects it'd bite you very easily for any effects that need cycle exact timing, like DYSP). That's the ones I seem to remember off the top of my head.
-
My idea come from the layout of the pdp-1. It has an 18 bit instruction where it has a 12 bit operand.
If it could move a 16 bit operand in the same time as an instruction fetch, I do not doubt it could speed things up.
-
Why would you want to? Surely the idea is to run as much C64 code as accurately as possible?
Widening the CPU instruction bus & data bus is pointless. All you do is introduce huge binary incompatibilities.
What you can do is :
Up the CPU clock rate.
Lower the instruction timings (fewer clock cycles per instruction).
Lower the RAM R/W timings (fewer clock cycles per read/write).
But each of these just introduces more incompatibilities.
You'd could have these features but perhaps make it a turbo mode which could be switched on specially for software which supported it? But then that means writing new software.
-
Is the SuperCPU still produced?
http://www.cmdweb.de/scpu.htm
http://www.youtube.com/watch?v=_rcJ7BRbXX4
Perhaps you could get one of those to start building a software library that could use the extra power that a FPGA solution could provide?
-
SuperCPU, I do not believe they are still being made.
I guess it depends on if the Instruction Decode can be re-written to transparently handle it.
*******************
What you can do is :
Up the CPU clock rate.
Lower the instruction timings (fewer clock cycles per instruction).
Lower the RAM R/W timings (fewer clock cycles per read/write).
********************
These are fine by me too.
-
Why would you want to? Surely the idea is to run as much C64 code as accurately as possible?
Widening the CPU instruction bus & data bus is pointless. All you do is introduce huge binary incompatibilities.
The 65816 managed it just fine, by starting in 6510 compatible mode and making you run a two instruction sequence to turn on the extra capabilities. For things like GEOS and GEOS apps and other non-timing dependent applications it should work fine. But of course most games etc. are likely to fail miserably.
I'm not sure the available C64 apps are really interesting enough to make it worthwhile other than for the hack factor, though.
-
Nice thing is the Chameleon offers a nice speed bump to the C64 with out the complexity of the Super CPU and is available now. The turbo mode can be activated with a button or in software and supports most illegal op-code unlike the 65816 in 6510 mode.
Floppy EMU, REU, VGA and other options make it real nice! Some items are still in beta but I can tell you, it is shaping up nicely!
-
Nice thing is the Chameleon offers a nice speed bump to the C64 with out the complexity of the Super CPU and is available now. The turbo mode can be activated with a button or in software and supports most illegal op-code unlike the 65816 in 6510 mode.
Floppy EMU, REU, VGA and other options make it real nice! Some items are still in beta but I can tell you, it is shaping up nicely!
How does it compare with an MCC-216? Does Mayhem In Monsterland work in the Chameleon? Does Tim Follin's GHouls'n Ghosts title music sound totally right in the Chamaleon?
-
I dont know where the MMC-216 got the C64 FPGA core from but Chameleon has two advantages.
Since it plugs in the C64, while in the C64 it the SID in the C64 is used and is fine as well as the graphic compatibility.
Also the core is a lot more advanced then the MMC-216 which I believed was based off the FPGA64 sources that started on the C-one. They have come a long way since that code.
Standalone the SID (stereo support as well) filters are not present and right now it old acts like the NEWer sid chip.
I did play Ghouls'n Ghost but did not make notice to the music but I will now that you ask.
I have a NTSC c64 so most of the time I played with NTSC stuff but in stand alone it will work in PAL as well so I will try Mayhem In Monsterland and see how it does.
-
I dont know where the MMC-216 got the C64 FPGA core from (...).
Also the core is a lot more advanced then the MMC-216 which I believed was based off the FPGA64 sources that started on the C-one.
frenchshark wrote on lemon64:
"Let's talk about the C64 implementation we have :
- 6510 : from Peter Wendrich, we have a licence for this IP.
- 6526 : I modified a 8520 implementation I wrote long time ago to make it behave like a 6526 (changes in the TOD for those who know).
- VIC-II : I have my own implementation, the DMA scheduling is done with a ROM.
- SID with filter : I never saw that in open source
- VIC-1541 emulation : We have our own way : 6502 + NIOS II + DMA and GCR encoding in HW.
- Keyboard emulation with auto-start : handled by the NIOS II
- CBM mouse emulation : I never saw that in open source.
- On the fly PAL/NTSC frequency with PLL reconfiguration : it is only possible with the Cyclone III & IV from Altera, I doubt somebody did it in the open source world.
- Multi-standard S-Video encoder : we read the book "Video Demystified" and did the implementation.
- Starfield effect (yes, it is HW based)
- SPI controllers for SD-Card and SPI-Flash with automatic CRC calculation.
- Multi-port SDRAM controller.
I can also talk about the boot loader which has a NIOS II with a custom 2D GPU. We only use the text mode right now but we can have 4-layer graphics with 16-bit color.
But, this is coming from open source, right ?
Regards,
Frederic"
Source: http://www.lemon64.com/forum/viewtopic.php?p=435620&highlight=#435620
-
frenchshark wrote on lemon64:
"Let's talk about the C64 implementation we have :
- 6510 : from Peter Wendrich, we have a licence for this IP.
- 6526 : I modified a 8520 implementation I wrote long time ago to make it behave like a 6526 (changes in the TOD for those who know).
- VIC-II : I have my own implementation, the DMA scheduling is done with a ROM.
- SID with filter : I never saw that in open source
- VIC-1541 emulation : We have our own way : 6502 + NIOS II + DMA and GCR encoding in HW.
- Keyboard emulation with auto-start : handled by the NIOS II
- CBM mouse emulation : I never saw that in open source.
- On the fly PAL/NTSC frequency with PLL reconfiguration : it is only possible with the Cyclone III & IV from Altera, I doubt somebody did it in the open source world.
- Multi-standard S-Video encoder : we read the book "Video Demystified" and did the implementation.
- Starfield effect (yes, it is HW based)
- SPI controllers for SD-Card and SPI-Flash with automatic CRC calculation.
- Multi-port SDRAM controller.
I can also talk about the boot loader which has a NIOS II with a custom 2D GPU. We only use the text mode right now but we can have 4-layer graphics with 16-bit color.
But, this is coming from open source, right ?
Regards,
Frederic"
Source: http://www.lemon64.com/forum/viewtopic.php?p=435620&highlight=#435620
That is some good information. The FPGA64 core is the CPU core that Peter Wendrich wrote that I was talking about. Not sure if all the opcode bugs were fixed in the version the MCC216 uses or not but they are very well emulated in the Chameleon core. We all have a license for it since it is GPL! I just dont know if they got a non-gpl license.
Regarding the PLL Pal/NTSC timing issue. The FPGA64 was doing PAL/NTSC switching on the C-one without any Cyclone 3 fpga on the fly by pressing F12. The C-one FPGA extender added a cyclone 3 and PLL approach for PAL and NTSC before the MMC216 was released.
I personally like the Chameleon feature set (which is extensive) and so far the beta cores are shaping up nicely.
The MCC216 surely has a few features not seen in open source as listed or had it done before open source.
If you review the developer information for the Chameleon you will see it also has added the ability for the C64 side of things to access a lot of the advanced features that the chameleon core provides.
http://www.syntiac.com/pdf/chameleon_progmanual_beta5.pdf
Sure is nice to have options. Have they VGA mcc216 now right?
-
Sure is nice to have options. Have they VGA mcc216 now right?
Yes, they have released a VGA version end of last year. Resolutions are 480p (60hz) in NTSC and 576p (50hz) in PAL. The 50hz in PAL has its own advantages and disadvantages. No buffering/conversion to 60hz is required and there is no judder/stuttering. A major disadvantage is that 50hz over VGA is not a refresh rate commonly accepted by LCD/TFT-displays. Some are able to sync, some are not.
When they would have used a real video connection (e.g. HDMI or Component), this wouldn't have been such a problem since most LCD-TVs (at least the European/PAL-ones) accept e.g. 576p50, 720p50, 1080p50, etc.
The only solution are VGA to HDMI or Component transcoders or to add a PAL-upsampling to 60hz (if this is possible with the current hardware).
Just a few weeks ago, they have also released a first beta-version of their Amiga-core. As expected, there is still a lot of room for improvement, but it's nice to have something to play with.
http://www.youtube.com/watch?v=fVJoM0CM_N4
-
Yes, they have released a VGA version end of last year. Resolutions are 480p (60hz) in NTSC and 576p (50hz) in PAL. The 50hz in PAL has its own advantages and disadvantages. No buffering/conversion to 60hz is required and there is no judder/stuttering. A major disadvantage is that 50hz over VGA is not a refresh rate commonly accepted by LCD/TFT-displays. Some are able to sync, some are not.
When they would have used a real video connection (e.g. HDMI or Component), this wouldn't have been such a problem since most LCD-TVs (at least the European/PAL-ones) accept e.g. 576p50, 720p50, 1080p50, etc.
The only solution are VGA to HDMI or Component transcoders or to add a PAL-upsampling to 60hz (if this is possible with the current hardware).
The C-one fpga64 and chameleon beta cores have the same problem.
The actual Chameleon uses VGA and outputs 800x600 native with a scan rate at 72hz and support to some degree a programable VGA output so it can be adjusted in software, even from the C64 side via pokes. The tearing effects of the VGA output is reduced by double buffering the VGA display.
At 800x600 VGA output at 72hz working for both PAL and NTSC, most display work without the 50hz problem you described.
This is detailed on Page 9 of chameleon_progmanual_beta5.pdf .
Of course now also the Minimig core is out for the Chameleon as well. It has a few bugs still but still very usable. It does output 50hz for the PAL display so for PAL Minimig support you need a 50hz VGA display. NTSC is 60.
So many options now. Fun times.
-
Have they VGA mcc216 now right?
The VGA version of the MCC-216 was demonstrated at the April SCCAN meeting when members Dan L. and Matt B. brought it in a surprise presentation (they also brought a Minimig to show off).
Next SCCAN meeting on June 5,
Robert Bernardo
Southern California Commodore & Amiga Network
http://www.sccaners.org
July 23-24 Commodore Vegas Expo v7 2011 - http://www.portcommodore.com/commvex
-
The VGA version of the MCC-216 was demonstrated at the April SCCAN meeting when members Dan L. and Matt B. brought it in a surprise presentation (they also brought a Minimig to show off).
Next SCCAN meeting on June 5,
Robert Bernardo
Southern California Commodore & Amiga Network
http://www.sccaners.org
July 23-24 Commodore Vegas Expo v7 2011 - http://www.portcommodore.com/commvex
Is there anything new to post on the MCC-216 or sccan?
-
Is there anything new to post on the MCC-216 or sccan?
They have just published a beta Apple II core for the MCC-216:
http://www.mcc-home.com/3.html
There is now also an unofficial forum for the MCC-216:
http://www.retrorebooted.com/mcc/forum/