+SvOlli Posted March 11, 2015 Share Posted March 11, 2015 This thread made me want to share an idea I had a couple of months ago. How about a VCS that can be switched into "Turbo Mode", being 3x as fast then. The TIA generates the clock for the CPU with 1:3, but what about clocking the CPU at the same speed as the TIA? At least to me that would be a fun place for some hacking. The CPU wouldn't be that much of a problem, since there's a 6502B running at nominal 3MHz. 20% overclocking shouldn't be a problem. But the problem would be the RIOT chip, since as far as I know, there's no 3MHz or faster version of it available. But how about recreating the CPU and the RIOT in an FPGA? As far as I know, the 6502 and the RIOT have been recreated in VHDL, but I don't have any experience, so I'm postponing that idea to "later". Maybe someone with FPGA knowledge wants to pick it up from here... From the software point of view, the VCS would start up in 1.2Mhz mode. Writing to $xx02 would then check for the two highest bits, so writing to $C002 would switch to 3.6HMz mode, while writing to $8002 would go back to 1.2MHz. Writing to $02 wouldn't change anything at all. Greetings, SvOlli 1 Quote Link to comment Share on other sites More sharing options...
Wickeycolumbus Posted March 11, 2015 Share Posted March 11, 2015 Here is a thread about a very similar project I did: http://atariage.com/forums/topic/201304-overclocking-the-2600-with-a-wdc65c02/?hl=+overclocking I used a new WDC 6502 chip that can be run at 14 MHz and replaced the RIOT with various other ICs. It doesn't have a slow mode, only fast. The hand wired prototype I made works great, however I made 3 different revisions of a PCB and have not gotten one completely working yet... I'd still like to put more work into getting a few working units made for anyone who'd want to experiment with it. That and get serial port communication working so code can be uploaded. Right now I can only run software from EPROMs which takes forever to test. Since the CPU I used can go up to 14 MHz, it could potentially be clocked at a multiple of the TIA clock for even more interesting results. Quote Link to comment Share on other sites More sharing options...
+save2600 Posted March 11, 2015 Share Posted March 11, 2015 …anything to speed up Burgertime and Miner 2049'er. (yes, am aware of the brilliant speed-up hacks for Miner) Quote Link to comment Share on other sites More sharing options...
Keatah Posted March 11, 2015 Share Posted March 11, 2015 I just adjust the framerate in Stella emulator. No gymnastics or development required. Quote Link to comment Share on other sites More sharing options...
Rybags Posted March 11, 2015 Share Posted March 11, 2015 Why not just go for 14 MHz? Even at 3.6 MHz, a 6502 derivitive has no hope of hitting registers in a useful way more than once every couple of colour-clocks, may as well put the effort into something that could hit them every 1.2 MHz cycle. Quote Link to comment Share on other sites More sharing options...
+SvOlli Posted March 13, 2015 Author Share Posted March 13, 2015 Imho, the WDC 6502 is not an option, because what I had in mind should play any game available without any problems. The CMOS version of the 6502 does not support the "illegal opcode" used by many homebrew software. Another problem is the speed of the cartridge. A Harmony would need to run trice as fast as well. From my experience with writing bankswitching for it, I can tell this might work for 4k ROMs, but for more complex ones it will most probably be too slow. Quote Link to comment Share on other sites More sharing options...
Rybags Posted March 13, 2015 Share Posted March 13, 2015 That's a thought - so effectively any better incarnation of the 6502 is eliminated because the illegal opcodes don't exist. A better option might be an FPGA or AVR implementation - have illegal opcode support, variable speed dependant on what area is accessed, switchable speed by soft or physical switch. Quote Link to comment Share on other sites More sharing options...
Wickeycolumbus Posted March 13, 2015 Share Posted March 13, 2015 (edited) My project isn't intended to be a commercial product or 2600 upgrade. It's an exploration of what the TIA can do while staying within the bounds of the 6502. If someone were to go the route of making some 'commercial' homebrew hardware for a similar project, emulating the chip seems much clunkier than loosing compatibility with a few games. To me anyway. Maybe illegal opcodes should be looked down upon. Not all homebrews use them and as far as I know no commercial games used them. It's a compatibility risk that programmers take, they know that it may make games crash on some consoles. (That's not to say that there aren't illegal opcodes in my games...) Edited March 13, 2015 by Wickeycolumbus Quote Link to comment Share on other sites More sharing options...
Kylearan Posted March 14, 2015 Share Posted March 14, 2015 Many opcodes like SAX I regard as "undocumented", not "illegal". 'Illegal" is such a loaded term. Who has the authority to declare them "illegal", anyway? Quote Link to comment Share on other sites More sharing options...
Rybags Posted March 14, 2015 Share Posted March 14, 2015 "Undocumented" isn't really correct terminology. That usually implies something that is an intended function but just not publicised for whatever reason. The functionality of illegal opcodes on NMOS 6502 is simply a side effect of the ROM on the 6502 which drives instruction processing. By "fixing" it on later versions it becomes obvious that they weren't intended to be used (as inconvenient as that turned out for many). Quote Link to comment Share on other sites More sharing options...
Nukey Shay Posted March 14, 2015 Share Posted March 14, 2015 Who has the authority to declare them "illegal", anyway? They were "illegal" in the sense that many assembler/disassembler programs at the time would not recognize them (because they were not programmed to), and respond with "illegal command" or other such description. BTW I've only seen one commercial VCS game that had an undocumented opcode. No Escape's original version uses double-NOP at $1800 (DOP VSYNC vs. STX WSYNC in the later version). 99% certain that it was an assembly error, since the earlier version also features a graphics glitch (a missing pixel at $1001). Quote Link to comment Share on other sites More sharing options...
tokumaru Posted March 15, 2015 Share Posted March 15, 2015 Many opcodes like SAX I regard as "undocumented", not "illegal". Another way to call them is "unofficial". None of these words is perfect though... "illegal" is too strong, and makes it sound like like you're breaking the law by using them, "undocumented" is not accurate, because they have definitely been documented by now, and "unofficial" doesn't sound terribly accurate either, since every chip made according to the original specifications will behave the same, thus making all instructions official. Maybe "unintended" is accurate enough? Not that this matters much, as we all know what all these terms are referring to. Quote Link to comment Share on other sites More sharing options...
+Andrew Davie Posted March 15, 2015 Share Posted March 15, 2015 Unsupported. 1 Quote Link to comment Share on other sites More sharing options...
ZackAttack Posted March 15, 2015 Share Posted March 15, 2015 Another option would be to add a frame buffer and a GPU. Something similar to what the NES has. I'm sure some purpose built graphics hardware would produce better graphics than an overclocked 6502. If you think about it, a 6502 would need to run at over 5 times the speed of the TIA and have a huge amount of RAM to update the TIA once per color clock. It would be much more effective to just have a frame buffer and update the COLUBK register once per color clock with it. Quote Link to comment Share on other sites More sharing options...
Omegamatrix Posted March 15, 2015 Share Posted March 15, 2015 BTW I've only seen one commercial VCS game that had an undocumented opcode. No Escape's original version uses double-NOP at $1800 (DOP VSYNC vs. STX WSYNC in the later version). 99% certain that it was an assembly error, since the earlier version also features a graphics glitch (a missing pixel at $1001). Airlock also has an unintentional, unsupported opcode. It jumps between operator and operand in "STA SWBCNT", and performs SAX ($02,X). Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.