ZackAttack Posted May 14, 2015 Share Posted May 14, 2015 I know there has been some experiments done with overriding the 6507 data bus in order to update a TIA register every 3 CPU cycles (9 color clocks). I'm getting ready to do some experimenting of my own and was thinking that maybe the address bus could be overridden too in order to update multiple TIA registers during the CPU cycle where the write signal is active. Does anybody that's familiar with the hardware aspects of the TIA think that could work? Quote Link to comment Share on other sites More sharing options...
jaholmes Posted May 14, 2015 Share Posted May 14, 2015 (edited) Sheet #2 of the TIA schematic shows that all of the data and address lines coming in are latched at the start of a write cycle, so changing the address in the middle wouldn't have any effect as far as I can tell. Also, unfortunately, the address and data lines drive both high and low, precluding any obvious attempts and bus-mastering from the cartridge. Hmmm. There might be some interesting read-modify-write exploits. Does 'INC WSYNC' cause you to wait for two HBlanks? I would think that it would. Not that such a thing would be all that useful, but maybe there are useful ones... Edited May 14, 2015 by jaholmes Quote Link to comment Share on other sites More sharing options...
ZackAttack Posted May 14, 2015 Author Share Posted May 14, 2015 I think phi2 is what actually triggers the latching, but you're right. Overriding the address bus won't have any effect since it's latched. I've thought about the RMW instructions too. That might be useful for setting color registers. You could use it to draw a 3 pixel wide object inside of the playfield. If timed across a pixel boundary it could even be 1 or 2 pixels wide. it's probably best to just focus on the databus. Getting 25+ register writes per scanline is going to be cool enough. Quote Link to comment Share on other sites More sharing options...
Rybags Posted May 14, 2015 Share Posted May 14, 2015 Yep, the problem is with the Phi signals and speeding them up would just break the rest of the system. I suspect the INC WSYNC thing might be similar to on the computer... it asserts /RDY but the thing with that signal is the 6502 will allow any pending writes to occur before recognising it, the behaviour is deliberate to allow such read/modify write instructions to be able to complete properly before the CPU is snoozed. Quote Link to comment Share on other sites More sharing options...
+SpiceWare Posted May 14, 2015 Share Posted May 14, 2015 (edited) It might be possible, supercat did some experiments and was able to do 2 TIA updates in 5 cycles. If I understood him correctly, it did involve bus-stuffing an address: generate two stores in five cycles using a "DEC" [the cycle following the ROL needed to have its address byte-stuffed to a TIA register whose upper bits would always read one; the two cycles after that could then be byte-stuffed with any desired address and data] Using it he did a demo that output 2 groups of 8 sprites were each sprite was independently colored. If I'm not mistaken, this was the result: Edited May 14, 2015 by SpiceWare 1 Quote Link to comment Share on other sites More sharing options...
ZackAttack Posted May 14, 2015 Author Share Posted May 14, 2015 Could you link to the topic you pulled that quote and image from? Quote Link to comment Share on other sites More sharing options...
jaholmes Posted May 14, 2015 Share Posted May 14, 2015 I suspect the INC WSYNC thing might be similar to on the computer... it asserts /RDY but the thing with that signal is the 6502 will allow any pending writes to occur before recognising it, the behaviour is deliberate to allow such read/modify write instructions to be able to complete properly before the CPU is snoozed. Ah, that makes sense. I suppose WSYNC was a bad example! How about setting the stack pointer to the address of some TIA registers and executing a BRK. Could you link to the topic you pulled that quote and image from? +1 Electrically, it's difficult to see how the CPU address and data lines could be manipulated in this way. Is this perhaps talking about manipulating the TIA's internal address and data lines? Quote Link to comment Share on other sites More sharing options...
ZackAttack Posted May 14, 2015 Author Share Posted May 14, 2015 I tested LSR COLUBK this morning and it produces a 3 pixel wide line. I need to review the TIA schematic further to ensure it's safe to force the COLUBK read to $ff so the 2 writes that follows can be overridden with any color. Quote Link to comment Share on other sites More sharing options...
+SpiceWare Posted May 14, 2015 Share Posted May 14, 2015 Sorry, it's not a public forum. Quote Link to comment Share on other sites More sharing options...
ZackAttack Posted May 14, 2015 Author Share Posted May 14, 2015 Well that's disappointing. I think Jaholmes is correct about manipulating the TIA directly. 2 TIA updates every 5 CPU cycles wouldn't be enough to produce that screenshot. You'd need almost twice that. Of course if you're accessing the TIA directly you could just set COLUBK every color clock and have a 160x192 bitmap with full 7bit color. I'm more interested in building a cartridge prototype that is compatible with any VCS system by simply inserting the cart as you would any other cart. Quote Link to comment Share on other sites More sharing options...
+SpiceWare Posted May 14, 2015 Share Posted May 14, 2015 2 TIA updates every 5 CPU cycles wouldn't be enough to produce that screenshot. You'd need almost twice that. If I remember right, that used interlacing - like the 32 character credits screen easter egg in Space Rocks. 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.