19:47 <@kanzure> jblake: using gdb for in-game debugging through an emulator. is this something that could potentially happen, or am i blowing smoke?
19:58 <@jblake> no obvious reason why it shouldn't work
19:58 <@kanzure> poorly written emulator?
19:58 <@jblake> as long as the emulator can speak the gdb protocol it should be easy
19:59 <@jblake> if you have to hack gdb support in yourself it might suck
19:59 <@kanzure> definitely does not speak gdb right now
19:59 <@jblake> okay
19:59 <@jblake> well gdb ships with a source file called remote.c
20:00 <@jblake> which implements the target-side of the gdb protocol
20:02 <@jblake> the packet format is pretty sane, and there aren't very many packets to support
20:03 <@kanzure> thanks.
20:04 <@kanzure> i'm not writing an emulator, but someone else is, and they might as well make it useful while they're doing it
20:04 <@kanzure> also, if you have any clever thoughts about guaranteeing replays regardless of wacky implementations of each opcode, that would be cool to hear too
20:04 <@kanzure> because right now a lot of people use vba-rerecording, but their replays don't work between minor versions of this emulator
20:05 <@jblake> what architecture is this?
20:05 <@kanzure> z80/gbc
20:05 <@kanzure> gbc is slightly different from z80, i think because there are certain opcodes missing?
20:06 <@jblake> so, on gameboy, user input is always taken through a specific magic register, yeah?
20:06 <@kanzure> sorry, i don't have this information for you
20:06 <@kanzure> http://nocash.emubase.de/pandocs.htm
20:07 <@jblake> oh, there's an interrupt too
20:09 <@jblake> i'd probably just have the emulator record cycle-accurate buttonpress/buttonrelease events, and then reconstruct those as an input stream when reexecuting the game
20:09 <@kanzure> so, that's what the other emulators do right now
20:10 <@kanzure> but it gets "out of sync"
20:10 <@jblake> because different emulators have different cycle counts?
20:10 <@kanzure> i think there needs to be cycle-accurate instruction execution or something? i'm not entirely sure of the terminology in emulation.
20:10 <@kanzure> well, maybe... my specific problem from a few days ago was that someone recorded a play on one version of vba-rerecording,
20:10 < buttbot> well, maybe... my specific buttlem from a few days ago was that someone buttcorded a play on one version of vba-rerecording,
20:10 <@kanzure> and then i played it back in a different version, and it got out of sync
20:11 <@kanzure> between the two versions there were a good number of changes, that i didn't check specifically, but things like instructions were reimplemented in a few places
20:11 <@jblake> okay if you don't trust the cycle times of the simulator but you *do* trust that it is otherwise bug-free, then you can work around that
20:11 <@jblake> every second or so record the program counter and a cheap hash of the memory as an event in the log
20:12 <@kanzure> and then if the hash isn't right, explode?
20:12 <@jblake> on replay, you pre-read all of those in, and use them to maintain approximate sync
20:12 <@jblake> basically by inserting a breakpoint on the next pc recorded
20:12 <@jblake> and then checking the hash
20:12 <@kanzure> i wonder if auto-correction could work. for instance, go back to the last known good sync state, and then try to figure out what might be broken.
20:12 <@jblake> and advancing to the next recorded breakpoint when the hash also matches
20:13 <@jblake> at which point you readjust your cycle count to match the recorded cycle count in the file
20:13 <@kanzure> i see
20:13 <@jblake> (this assumes that over the course of a single second you can't get far enough out of sync to cause problems, which may not be a good assumption)
20:13 <@jblake> also assumes that the simulators are genuinely bug-free, because otherwise you're never going to get that hash match
20:14 <@jblake> if the game in question doesn't use the input interrupt, you can do better
20:14 <@jblake> because then instead of recording actual keypresses
20:14 <@jblake> just record the result of every single read from the input register
20:14 <@jblake> should still compress well
20:14 <@kanzure> "the result" is, the change in memory?
20:15 <@jblake> well, you record its value
20:15 <@jblake> but only when the program actually examines it
20:15 < buttbot> but only when the buttgram actually examines it
20:15 <@kanzure> oh hm, i see
20:15 <@jblake> don't bother to record when it "really" changes, because that doesn't matter
20:15 <@kanzure> so if it's not going to read a specific value, no need to record it?
20:15 <@jblake> exactly
20:16 <@jblake> and in practice it'll read the same value over and over in long sequences, because button presses are much longer than cycles
20:16 <@jblake> longer than frames, rather
20:16 <@jblake> but that doesn't matter, because long strings of the same character compress *really* well
20:17 <@jblake> now, because the gameboy has this weird write-before-read thing going on which allows it to map 8 buttons on to 6 bits, you might want to be a little paranoid and instead just record the 8 bits that say what the actual inputs are at any given read
20:18 <@jblake> and still handle the p14/p15 select bits in simulation
20:18 <@jblake> you're still at risk of losing sync, though
20:19 <@jblake> because the game ties certain actions to individual frames
20:19 <@jblake> but the time a frame takes to render might be more or less cycles if the simulator isn't accurate
20:19 <@jblake> which means the game might check for input more or less times before a certain input becomes valid in game terms
20:20 <@jblake> which means that just recording the input events really isn't good enough
20:21 <@jblake> if you believe that a game is written based on LCD timings, you could use the vblank as your counter, and store keypress/keyrelease in terms of that instead of the cycle counter
20:21 <@jblake> there's also the builtin timer, and the sound timings, any of which could be driving the game logic
20:22 <@jblake> so really you should just record *all* those timers in your event log
20:22 <@jblake> and then on replay if you notice that your timers are falling out of sync, start artifically slowing down the fast ones so that you match the replay speed of the recorded log
20:23 <@kanzure> do you think replay sync is just a function of those multiple timers being attenuated properly?
20:23 <@jblake> assuming the simulators are bug-free, those timings are just about the only variable you have left, i think?
20:29 <@kanzure> is this something that is likely to be working? https://github.com/virtualopensystems/linux-kvm-arm/commits/kvm-arm-master
20:30 <@jblake> i guess there is a theoretical pure-entropy source available to gameboy games
20:30 < buttbot> i guess there is a buttoretical pure-enbutt source available to gameboy games
20:30 <@jblake> i really hope none of them take advantage of that
20:31 <@kanzure> i think there's an address near the end of memory that pokemon games use for randomization
20:31 <@jblake> i was just thinking of the fact that the ram boots up uninitialized
20:32 <@kanzure> for pokemon, i think every run is the same until you input differently
20:32 <@kanzure> what is the pure entropy source you are thinking of ?
20:37 < r00tx0r> a soccer referee in brazil stabbed a player to death, on the field, and then the crowd decapitated the ref and quartered his body and put his head on a stake in the middle of the field
20:37 <@jblake> when the gameboy starts, the ram can have anything at all in it, not just all zeroes
20:38 <@jblake> you can abuse that entropy pool to seed a RNG which will have genuinely different results from run to run
20:38 <@kanzure> i think emulators might explicitly zero everything, but i dunno
20:38 <@kanzure> oh you mean the real gameboy
20:43 <@kanzure> http://translatedcode.wordpress.com/2013/03/08/qemu-kvm-on-armv7-support-is-upstream/ "This week the QEMU support patches for KVM on ARM were accepted into upstream. Since the kernel KVM on ARM patchset was accepted for the 3.9 kernel, this means that there is now enough support in purely upstream kernel and QEMU for basic working KVM on ARMv7 cores with the Virtualization Extensions (specifically, Cortex-A15). There are still a number of features left ...
20:43 <@kanzure> ... to be implemented but nonetheless I feel this is an important milestone."
20:43 < buttbot> http://translatedcode.wordpress.com/2013/03/08/qemu-kvm-on-armv7-support-is-upstream/ "This week the QEMU support butt for KVM on ARM were accepted into upstream. Since the kernel KVM on ARM patchset was accepted for the 3.9 kernel, this means that there is now enough buttport in purely upbutt
20:43 < buttbot> ..kernel and QEMU for basic working KVM on ARMv7 cores with the Virtualization Buttensions (spebuttally, Buttex-A15). There are still a number of features left ...
20:44 <@kanzure> i'm confused why they say Cortex-A15 only.
20:44 <@kanzure> i thought the armv7 virtualization extensions were related to krait, not Cortex-A15.
20:46 <@kanzure> "KVM ARM will only work for ARMv7a processors with virtualization extensions"
20:46 <@kanzure> cool
21:20 <@kanzure> jblake: if my processor supports this, but other people don't know that, will linux just work, or will i have to make some edits to make the kernel trust that i am right?
21:20 <@kanzure> *will this branch of linux work
21:20 <@jblake> no idea
21:20 <@jblake> usually linux is good about enabling stuff based on actual probing and feature testing rather than looking up model numbers
21:21 <@jblake> but arm has historically had *really* bad runtime enumeration and feature testing support
21:21 <@jblake> and a bunch of the arm platform stuff in linux is based on big lookup tables
21:21 <@jblake> so i don't know if it would work or not
21:22 <@kanzure> for some reason the datasheet of this processor is "confidential and proprietary" and not something i can find on the interwebs. wtf?
21:22 <@jblake> welcome to arm
21:22 <@jblake> please enjoy your stay, but don't ask any questions
21:22 <@jblake> OR WE'LL CUT YOU
21:22 <@kanzure> what a lovely go-to-market strategy
21:24 <@jblake> arm cpus have a history of getting used in a lot of products which are differentiated solely by firmware
21:25 <@jblake> like, some company needs a cpu, so they license arm. and they want to make a cheap, low-end version of their product
21:25 <@jblake> but it's cheaper to just only manufacture the high-end product
21:25 < buttbot> but it's cheaper to just butt manufacture the high-end product
21:25 <@jblake> so they just turn off a bunch of features on the low-end one, and sell it for less
21:25 <@jblake> and it's desirable for this to not be immediately obvious to customers
21:25 <@kanzure> yeah, i was looking at qualcomm's arm chips and they all seem to be roughly the same but some of them have features disabled?
21:25 <@jblake> or else they'll start jtagging themselves a nicer camera
21:26 <@jblake> this sort of idiocy is a huge component of the arm market
21:26 <@kanzure> nexus 4 seems to be qualcomm snapdragon s4 pro (APQ8064) (some armv7 or armv7a thing). i think this is the chip that was supposed to kill nvidia tegra but i can't remember.
21:27 <@kanzure> also it looks like APQ8064 might have audio dsp things on chip? and possibly cdma/gsm things?
21:28 <@kanzure> "3G/4G World/multimode LTE on select processors " i guess it's qualcomm so they can do that if they want
21:29 <@kanzure> oh i see, they call it a SoC so that makes sense
21:29 <@kanzure> "It is a successor to cortex's Scorpion CPU and has architectural similarities to ARM Cortex-A15." how would anyone know it's similar to A15 if nobody has specs?
21:29 <@jblake> usually you can get the specs if you put in enough effort to actually call somebody
21:30 <@jblake> also if you say stuff like "yeah i'm looking at putting together a <product> with <your chip>" you might get a surprise delivery of a box of samples
21:31 <@jblake> hobby electronics got a lot more fun for me when i discovered that calling vendors is way cooler than shopping online
21:31 <@kanzure> oh sure, maybe i could throw in the word 'virtualization' and 'cloud' and 'android' and that might make them happy
21:35 <@kanzure> so why is arm licensed around so much?
21:35 <@kanzure> i would expect mobile to be hyper-competitive around energy performance, and the victors being some company that can control that entire stack, not just licensing of an instruction set
21:36 <@jblake> arm is used a lot because they're willing to sell it as a subcomponent to be placed on the same silicon as other proprietary blocks
21:36 <@jblake> so qualcomm, for example, can stick their cdma modem on the same silicon as their cpu, without having to make their own cpu
21:37 <@kanzure> i can see that reducing costs a lot, getting everything on the same chip, sure
21:38 <@jblake> it also means that their proprietary blocks can't be ripped out and used in some other application as easily, because they're so integrated
21:39 <@jblake> which is desirable in the uber-paranoid environment of embedded component design
21:39 <@jblake> qualcomm is a great example, because a *lot* of their cdma modem tech is implemented in software, which is run by the embedded cpu and stored in a ROM that's on the same silicon
21:40 <@jblake> they *really* don't want people to have direct access to the radio
21:40 <@kanzure> i keep forgetting who it was but someone in austin has been disassembling their software. he got a rom dump using some trickery on a platform they overlooked or something.
21:41 <@jblake> it's been pretty well demonstrated that the actual radio hardware on all of qualcomm's current offerings is *identical*
21:42 <@jblake> so they have exactly one product, which they sell across a huge price range, solely because of some control software they probably isn't as good as a third party could write
21:42 <@jblake> *that probably
21:43 <@jblake> these are the types of people that arm caters to
21:44 <@kanzure> i suppose those are precisely the same people that would respond positively to insane licensing costs or something
21:44 <@jblake> the embedded market is all kinds of fucked up