| --- Log opened Mon Jan 11 00:00:38 2016 |
| 00:03 | | catalyst [catalyst@Nightstar-bt5k4h.81.in-addr.arpa] has joined #code |
| 00:06 | | Turaiel is now known as Turaiel[Offline] |
| 00:27 | | himi [fow035@Nightstar-dm0.2ni.203.150.IP] has joined #code |
| 00:27 | | mode/#code [+o himi] by ChanServ |
| 01:13 | | catalyst [catalyst@Nightstar-bt5k4h.81.in-addr.arpa] has quit [[NS] Quit: ] |
| 01:24 | | Vash [Vash@Nightstar-b868ob.sd.cox.net] has joined #code |
| 01:24 | | mode/#code [+o Vash] by ChanServ |
| 01:24 | | Vash is now known as VV |
| 01:33 | | Turaiel[Offline] is now known as Turaiel |
| 02:06 | <@VV> | McM: holy cats is that 16 colors in a single character block? |
| 02:06 | <@celticminstrel> | A single character block is that large? |
| 02:13 | <@VV> | yeah. 8x8, on a 320x200 field (and change, the border is weird) |
| 02:15 | <&McMartin> | VV: It sure is. |
| 02:15 | <&McMartin> | This is one of the two techniques I've been building towards in this whole series. |
| 02:16 | <&McMartin> | It's even high-res, though in the interest of being actually visible I didn't show that off. |
| 02:24 | <@Reiv> | what dark sorcery is this McM |
| 02:38 | <&Derakon> | He's subverted the C64's palette system and bent it to his will in very specific ways. |
| 03:21 | | ion [Owner@Nightstar-gmbj85.vs.shawcable.net] has quit [Connection closed] |
| 03:22 | <&McMartin> | Yeah, that works but the code is super dumb and ugly and verbose |
| 03:22 | <&McMartin> | I'm putting that project on hold because I got an actual request relating to one of my earlier projects, so I'm going to try to modify that one. |
| 03:22 | <&McMartin> | (Essentially, to turn it into a testbed for seeing how activating sprites interacts with bus contention) |
| 03:25 | <@Reiv> | ooh |
| 03:26 | <&McMartin> | (The specific trick is that in bitmap mode, text lines are used as color data instead, and I've tricked it to basically have 200 1-pixel-high text lines.) |
| 03:26 | <&McMartin> | (This actually glitches out bits of the display but I've hidden that behind the background :sshh:) |
| 03:51 | <&McMartin> | Meanwhile, I can do the Sprite-Bus-Contention thing by loading up my old program and then typing commands into BASIC, and comparing hardware and emulator~ |
| 04:03 | | Thalass|demonstration_man [thalass@Nightstar-283.o7s.158.104.IP] has quit [Connection closed] |
| 04:18 | | Reiv [NSwebIRC@Nightstar-q8avec.kinect.net.nz] has quit [Ping timeout: 121 seconds] |
| 04:28 | | * VV examines |
| 04:28 | <@VV> | So wait a second |
| 04:31 | <@VV> | Are the glitches mentioned the badline thing, where the vic-ii goes "stop the presses i need data"? |
| 04:39 | <&McMartin> | Yes but |
| 04:39 | <&McMartin> | It's specifically "Partial rescan" |
| 04:39 | <&McMartin> | And normally when it stops the presses it also goes back to the top of the character graphics, which also means that you never leave the first line of text... |
| 04:39 | <&McMartin> | ... but if you tell it to stop the presses when the presses should have started, like, three cycles ago |
| 04:40 | <&McMartin> | Then it forgets to reset the line counter which means you don't get line-repeats. |
| 04:45 | <&McMartin> | Where sprites make things wacky is that any line where there are active sprites, the VIC-II halts the CPU at least once and possibly multiple times to pull in the sprite data. The actual "cycle tax" from doing this is technically predictable but it's very nonlinear |
| 04:45 | <&McMartin> | So, like, if you have any one sprite on, it's always a 5-cycle tax |
| 04:45 | <&McMartin> | But if sprites 0 and 2 are on, it's a 9 cycle tax |
| 04:45 | <&McMartin> | And so is 0, 1, and 2 |
| 04:45 | <&McMartin> | But 1 and 2 or 0 and 1 are a 7-cycle tax. |
| 04:46 | <&McMartin> | While the documentation describing how this works appears to have existed for 20 years or so, I get the impression it's never been properly synthesized |
| 04:46 | <&McMartin> | So I've been asked to move that up in the priority~ |
| 04:48 | <&McMartin> | (The rule is basically: each sprite means the ViC-II needs control of the buss for two cycles. It reads through 0-7 in order, checking their activity status. Any time it needs control of the bus and doesn't have it, the three cycles before it are also taken.) |
| 04:49 | <&McMartin> | So the two cycles that would be spent reading sprite 1 are instead spent maintaining control of the bus for the sprite 2 read, while if it were 0, 3, you'd have a 10-cycle tax as the full 3-cycle cost is paid twice... but the CPU would get a single cycle slipped in between. |
| 04:50 | <@VV> | But 0 1 3 would be 11 cycles straight up |
| 04:51 | <&McMartin> | Right, because the two cycles freed up by not having 2 active are consumed in recapturing the bus/keeping it captured. |
| 04:51 | <&McMartin> | In a wacky anomaly on this, any "capturing the bus" cycle actually will permit the CPU to write to memory |
| 04:51 | <&McMartin> | But any cycle where the CPU doesn't write, it reads, which stuns it. |
| 04:52 | <&McMartin> | So it takes three seconds to capture the bus because a worst-case scenario is an interrupt hitting just as bus capture begins |
| 04:52 | <&McMartin> | So the CPU pushes the flags and the two bytes of the return address to the stack, for 3 consecutive write cycles. |
| 04:53 | <&McMartin> | (a JSR instruction does two consecutive writes, and any store instruction is just the one.) |
| 04:53 | <@VV> | I remember looking at the cycle counts on c64 things and going "these are really high!" and then realizing that it's actually spending most of that time reading a byte at a time from the program |
| 04:53 | <&McMartin> | Interestingly, because everything is hard-synced to the memory bus |
| 04:54 | <&McMartin> | The cycle counts are preposterously *low* compared to the x86. |
| 04:54 | <&McMartin> | (Which had bus contention as its primary limiting factor until, like, the 486, but which also had dedicated circuitry to address it and keep it out of the CPU's way) |
| 04:54 | <&McMartin> | So if the CPU did a MUL instruction, it was busy for 24 cycles but that was 24 cycles where it never touched the bus at all. |
| 04:54 | <&McMartin> | ... and it was clocked at 4x faster |
| 04:55 | <&McMartin> | The 6502 systems basically arranged a bus-sharing arrangement that didn't have a real coordinator |
| 04:55 | <&McMartin> | But this also meant that until the 486 era, size *was* speed. |
| 04:56 | <&McMartin> | bus contention on instruction fetch *completely* overwhelmed every other consideration when it came to instruction throughput. |
| 05:01 | | Turaiel is now known as Turaiel[Offline] |
| 05:04 | | Derakon is now known as Derakon[AFK] |
| 05:32 | | froztbyte [froztbyte@Nightstar-frrora.za.net] has quit [Ping timeout: 121 seconds] |
| 05:33 | | froztbyte [froztbyte@Nightstar-frrora.za.net] has joined #code |
| 05:33 | | mode/#code [+o froztbyte] by ChanServ |
| 06:02 | | Crossfire [Z@Nightstar-pdi1tp.customer.tdc.net] has quit [Ping timeout: 121 seconds] |
| 06:12 | | celticminstrel [celticminst@Nightstar-uce74q.dsl.bell.ca] has quit [[NS] Quit: And lo! The computer falls into a deep sleep, to awake again some other day!] |
| 06:54 | | himi [fow035@Nightstar-dm0.2ni.203.150.IP] has quit [Ping timeout: 121 seconds] |
| 07:13 | | VV [Vash@Nightstar-b868ob.sd.cox.net] has quit [Connection closed] |
| 07:24 | | Crossfire [Z@Nightstar-r9lk5l.cust.comxnet.dk] has joined #code |
| 07:25 | | mode/#code [+o Crossfire] by ChanServ |
| 07:29 | | Kindamoody[zZz] is now known as Kindamoody |
| 08:09 | | Kindamoody is now known as Kindamoody|out |
| 08:31 | | catadroid [catalyst@Nightstar-bt5k4h.81.in-addr.arpa] has joined #code |
| 08:48 | | catadroid` [catalyst@Nightstar-qiidsj.dab.02.net] has joined #code |
| 08:50 | | catadroid [catalyst@Nightstar-bt5k4h.81.in-addr.arpa] has quit [Ping timeout: 121 seconds] |
| 09:05 | | catadroid` [catalyst@Nightstar-qiidsj.dab.02.net] has quit [[NS] Quit: Bye] |
| 12:25 | | * TheWatcher eyes this exercise submission, facepalms |
| 12:26 | <@TheWatcher> | "I've finally cottoned on that I need to submit my code with proper commenting, so I'll get it working as well as I can, and then slap the comments in at the end!" |
| 12:27 | <@TheWatcher> | Which is... irritating at best, but turns disasterous when forgetting to include significant */s... |
| 13:08 | | catadroid [catalyst@Nightstar-qiidsj.dab.02.net] has joined #code |
| 14:10 | | celticminstrel [celticminst@Nightstar-uce74q.dsl.bell.ca] has joined #code |
| 14:10 | | mode/#code [+o celticminstrel] by ChanServ |
| 14:11 | <@froztbyte> | TheWatcher: who needs that last compile |
| 14:11 | <@TheWatcher> | Obviously -_- |
| 14:25 | | catadroid` [catalyst@Nightstar-ndh970.dab.02.net] has joined #code |
| 14:25 | | catadroid [catalyst@Nightstar-qiidsj.dab.02.net] has quit [Connection closed] |
| 15:18 | | catadroid [catalyst@Nightstar-en7v39.dab.02.net] has joined #code |
| 15:21 | | catadroid` [catalyst@Nightstar-ndh970.dab.02.net] has quit [Ping timeout: 121 seconds] |
| 15:21 | | catadroid [catalyst@Nightstar-en7v39.dab.02.net] has quit [[NS] Quit: Bye] |
| 16:05 | | Emmy [M@Nightstar-9p7hb1.direct-adsl.nl] has joined #code |
| 16:53 | | gnolam [lenin@Nightstar-t2vo1j.tbcn.telia.com] has joined #code |
| 16:53 | | mode/#code [+o gnolam] by ChanServ |
| 16:59 | | gnolam_ [lenin@Nightstar-t2vo1j.tbcn.telia.com] has joined #code |
| 17:01 | | gnolam [lenin@Nightstar-t2vo1j.tbcn.telia.com] has quit [Ping timeout: 121 seconds] |
| 17:04 | | gnolam_ is now known as gnolam |
| 17:04 | | mode/#code [+o gnolam] by ChanServ |
| 19:10 | | Kindamoody|out is now known as Kindamoody |
| 19:10 | | catalyst [catalyst@Nightstar-bt5k4h.81.in-addr.arpa] has joined #code |
| 19:12 | | gnolam_ [lenin@Nightstar-t2vo1j.tbcn.telia.com] has joined #code |
| 19:15 | | gnolam [lenin@Nightstar-t2vo1j.tbcn.telia.com] has quit [Ping timeout: 121 seconds] |
| 19:23 | | gnolam_ is now known as gnolam |
| 19:23 | | mode/#code [+o gnolam] by ChanServ |
| 20:13 | | Reiv [NSwebIRC@Nightstar-q8avec.kinect.net.nz] has joined #code |
| 20:13 | | mode/#code [+o Reiv] by ChanServ |
| 20:39 | | Crossfire [Z@Nightstar-r9lk5l.cust.comxnet.dk] has quit [Ping timeout: 121 seconds] |
| 20:43 | | Kindamoody is now known as Kindamoody|afk |
| 22:09 | <&McMartin> | https://code.google.com/p/google-security-research/issues/detail?id=693 |
| 22:14 | <@Tamber> | *boggle* |
| 22:15 | < Emmy> | McMartin: apart from what seems to be a baaaad exploitable weakness that was fixed after a while, anything after i TL:DR'd that i missed? |
| 22:16 | <@Tamber> | Aside from the code execution, and the password theft exploit? |
| 22:18 | <&McMartin> | Hasn't actually been fixed yet, ANAICT. |
| 22:18 | <&McMartin> | Ah wait, there it is. |
| 22:18 | < Emmy> | oh dear. sounds nasty |
| 22:19 | <&McMartin> | Well |
| 22:19 | <&McMartin> | Sort of fixed |
| 22:19 | <&McMartin> | It is now not "if you install this antivirus you are a free botnet zombie for anyone with your IP address" and now "they can use it to turn a lesser vulnerability into a devastating greater one" |
| 22:20 | | * McMartin meanwhile finds himself writing actual Objective-C code. |
| 22:20 | <&McMartin> | I feel like I should be sporting a mullet or something, this code organization method is very 70s |
| 22:21 | <&McMartin> | @implementation Foo |
| 22:21 | <&McMartin> | ... |
| 22:21 | <&McMartin> | @end |
| 22:21 | <&McMartin> | I mean, really |
| 22:42 | | thalass [thalass@Nightstar-283.o7s.158.104.IP] has joined #code |
| 22:42 | | mode/#code [+o thalass] by ChanServ |
| 23:17 | | himi [fow035@Nightstar-dm0.2ni.203.150.IP] has joined #code |
| 23:18 | | mode/#code [+o himi] by ChanServ |
| 23:26 | | catalyst [catalyst@Nightstar-bt5k4h.81.in-addr.arpa] has quit [[NS] Quit: ] |
| 23:32 | | Vash [Vash@Nightstar-o980bt.dyn.telnor.net] has joined #code |
| 23:32 | | mode/#code [+o Vash] by ChanServ |
| 23:32 | | Vash is now known as VV |
| 23:52 | | Kindamoody|afk is now known as Kindamoody |
| 23:55 | | Turaiel[Offline] is now known as Turaiel |
| 23:58 | | Kindamoody is now known as Kindamoody[zZz] |
| --- Log closed Tue Jan 12 00:00:54 2016 |