Jump to content
IGNORED

Turbo VCS?


SvOlli

Recommended Posts

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

  • Like 1
Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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 by Wickeycolumbus
Link to comment
Share on other sites

"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).

Link to comment
Share on other sites

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).

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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).

Link to comment
Share on other sites

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.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...