--- Log opened Thu Oct 20 00:00:13 2016 |
--- Day changed Thu Oct 20 2016 |
00:00 | | * McMartin prepares the pit of burning, but notes in passing that this explains some of the weird gaps in his 16-bit x86 knowledge |
00:00 | <&McMartin> | Specifically, the things I never learned how to do are the things that Turbo Pascal 5.5's Dos module had functions for doing for me |
00:01 | <&McMartin> | (Of which the most obvious is "reassigning interrupt vectors") |
00:02 | <@Tamber> | *handwaves* Magic! |
00:03 | | * catalyst plays an Island |
00:05 | <&McMartin> | Tamber: Indeed, the interaction between CPU interrupts and the PIC is something I remain unclear on |
00:05 | <&McMartin> | I know that Interrupt 9 is the keyboard handler, and that this is IRQ 1 |
00:05 | <&McMartin> | But IRQ 9 is also the Coprocessor segment overrun fault, and this is somehow distinguishable from keyboard events |
00:05 | <&McMartin> | Er |
00:05 | <&McMartin> | Interrupt 9 |
00:05 | <&McMartin> | There is no IRQ 9 |
00:09 | <&McMartin> | I'm not completely positive but I think the answer might actually be "they just fight for it, and those CPU problems are assumed to never occur on a DOS machine" |
00:09 | <@Tamber> | It's all a bit crusty, hairy magic to me, I'm afraid. I can't get my brain to focus on it long enough to try understand it. |
00:20 | | catadroid [catalyst@Nightstar-rus61p.dab.02.net] has joined #code |
00:34 | <&ToxicFrog> | McMartin, Tamber: I'm rusty on this, but IIRC (and after some quick refreshing on osdev) -- |
00:34 | <&ToxicFrog> | The "programmable" part of the PIC is that you can reprogram which IRQs map to which interrupt vector |
00:36 | <&ToxicFrog> | In real mode, you don't care because those exceptions won't be thrown |
00:37 | <&ToxicFrog> | In protected mode, the first thing you do is reprogram the PIC to map them to interrupts that aren't already reserved. |
00:38 | <&McMartin> | That would seem to match up fairly well with my expectations, and digging around elsewhere on OSDev I'm also seeing which bits of code I had at the time copy-pasted but which I now understand |
00:38 | <&McMartin> | I am apparently still deeply confused about exactly how the IN and OUT instructions work, though. |
00:38 | < catalyst> | well, you see when a port loves a bus very much... |
00:39 | <&McMartin> | Right |
00:39 | <&McMartin> | I'm having hash collisions between port numbers and chunks of address space |
00:40 | <&McMartin> | I guess they're actually a secret, entirely separate address space? |
00:42 | <&McMartin> | In particular, the old keyboard interrupt that I had clearly pulled in from some ancient BBS is interrogating the PS/2 range and then sending an IRQ acknowledgement to the PIC |
00:44 | <&McMartin> | I'm now kind of curious how DOSBox will react if I start poking around inside addresses that it claims are where MS-DOS or the BIOS live. |
00:44 | <@Tamber> | Somewhere between screams and gurgles. |
00:45 | <&McMartin> | Also I'm wrong about there being no IRQ 9 but it's part of the secondary PIC~ |
00:46 | <&McMartin> | Also the PIC is way more polite than the C64's various interrupt sources |
00:46 | <&McMartin> | Failure to acknowledge interrupts with the PIC apparently basically disables interrupts |
00:47 | <&McMartin> | Failure to ack on the C64 produces an endless loop of instantaneous re-interrupts |
00:47 | <@Tamber> | "HEY. HEY YOU. HEY! HEY! HEY! OI!" |
00:48 | | * Tamber receieves smACK, scuttles off. |
00:48 | <&McMartin> | My guess offhand is actually that the DOSBox setup has a set of RAM reserved to pretend to be the BIOS/MS-DOS |
00:48 | <&McMartin> | And magic locations within that perform emulation traps when executed |
00:49 | <&McMartin> | (It can't rely on them being called via INT whatever, because the whole point of this exercise is to let us remap those interrupts as needed) |
00:49 | | catalyst [catalyst@Nightstar-bt5k4h.81.in-addr.arpa] has quit [[NS] Quit: Leaving] |
00:51 | <@Tamber> | Yeah, I think relying on people doing things the way they Shouldâ˘, just means some stuff will break in weird ways. |
00:51 | <&McMartin> | Well, that's kinda the thing, though |
00:51 | <&McMartin> | Hacking around the core interrupt vector table *is* the way they Should (tm). |
00:51 | <&McMartin> | That's how you get access to raw key events instead of having to poll. |
00:51 | <@Tamber> | Hm |
00:51 | <&McMartin> | It's why you had to set jumpers on your cards and tell all your games which IRQs they used. |
00:52 | <@Tamber> | Honestly, I ...never got to experience that level of, uh... fun. |
00:52 | <&McMartin> | The latter or the former? :D |
00:52 | <@Tamber> | Yes. |
00:52 | <&McMartin> | Aha, OK, so |
00:53 | <&McMartin> | The protocol here is that each device has an actual wire it sends info down, and those are numbered. The keyboard is wire #1, so, IRQ 1. |
00:53 | <&McMartin> | "Interrupt Request" |
00:53 | <&McMartin> | You can ask BIOS "hey, read a key from your key buffer and tell me what it is", if you're doing OS-style console input where you aren't doing anything fancy |
00:54 | <&McMartin> | But if you actually wanted Key Down/Key Up events, you basically had to get between IRQ 1 and the BIOS. |
00:54 | <@Tamber> | Mhm. But all the interesting stuff is ... yeah. |
00:54 | <&McMartin> | So first you'd check to see what the routine was for IRQ 1 (which would be in the middle of BIOS), and save it out |
00:54 | <&McMartin> | Then you'd replace it with your routine. |
00:54 | <@Tamber> | (I have briefly skimmed the basic ideas of it, but not really arranged the mind-space to understand it properly.) |
00:54 | <&McMartin> | Stuff you wanted to swallow you just dealt with on your own, and then for everything else you called on into the old BIOS routine. |
00:55 | <&McMartin> | Once you were done with hooking into that event stream/listening to that device, you put the BIOS's routine address back into the table where you once were. |
00:55 | <@Tamber> | (Or whatever it was you replaced, which may or may not be the old BIOS routine.) |
00:55 | <&McMartin> | (Right, but it probably was, and yes, a nice aspect of this protocol is that it *does* chain properly) |
00:55 | | Derakon[AFK] is now known as Derakon |
00:55 | <&McMartin> | So this implies that DOSBox has some address that means "if you jump here, pretend to be the BIOS" |
00:56 | <&ToxicFrog> | Re ports: "secret, entirely separate address space" sums it up pretty well, I think |
00:56 | <&ToxicFrog> | Ports aren't aliases for memory mapped IO, they're their own thing |
00:56 | <@Tamber> | McM: So it should behave roughly as-expected, then. (Except for when it doesn't.) |
00:56 | <&McMartin> | Right |
00:56 | <&McMartin> | And, I mean |
00:56 | <&McMartin> | DOSBox is Pretty Good these days |
00:57 | <&McMartin> | This is a thing they'd need to get working for, like, *anything* to work |
00:57 | <&McMartin> | Or at least anything where things happen for as long as you hold a key down |
00:57 | <&McMartin> | Which is, well, everything DOSBox cares about~ |
00:57 | <@Tamber> | So, basically, all the interesting stuff. :p |
00:57 | <&ToxicFrog> | So basically you have two address spaces, one for RAM (and MMIO because of course we have that too), and one much smaller one for peripherals |
00:57 | <&McMartin> | Look, having VRAM right there in your address space isn't a misfeature~ |
00:58 | <&McMartin> | (Having it on the same bus as the main RAM, though, is) |
00:58 | <&ToxicFrog> | McMartin: I agree, my objection to having both MMIO and PMIO rather than just MMIO~ |
00:58 | <&McMartin> | (Most DOS machines did not. I know of only one exception offhand.) |
00:59 | <&McMartin> | I suspect PMIO was a holdover from the 4004, which would probably not be able to use MMIO without making the systems they were part of way more expensive |
01:00 | <&McMartin> | (The C64 in particular shipped with the equivalent of an FPGA programmed to handle sending memory reads/writes to all the correct chips) |
01:01 | <&McMartin> | It's also interesting, re: MMIO, because it turns out that this makes the "640KB should be enough for everyone" quote actually have a sane interpretation |
01:01 | <&McMartin> | To wit: "If you're going to need more than 640KB, you're going to need more than 1MB." |
01:02 | <&McMartin> | (That is, it's not an argument against protected mode, it's a way of saying "just use protected mode") |
01:02 | <&McMartin> | Except, as Retro City Rampage 486 found, you can't, because that locks you out of that lower 1MB and you'd really quite like to use that too~ |
01:03 | <&McMartin> | (It's amazing how he says "most of the real work was done to get it to fit on the 3DS" and then casually writes his own memory manager for DOS to accomplish things that weren't done with it at the time) |
01:04 | <&McMartin> | (At the time, they'd have just had the sysreqs be 8MB RAM) |
01:57 | | catadruid [catalyst@Nightstar-octgc5.dab.02.net] has joined #code |
02:00 | | catadroid [catalyst@Nightstar-rus61p.dab.02.net] has quit [Ping timeout: 121 seconds] |
04:07 | <@Alek> | I remember one of the first 3 Tomb Raider games was the reason for my first GPU upgrade because it needed at least 8MB VRAM, as opposed to whatever my onboard chip had at the time. |
04:30 | <&McMartin> | My first real 3D card was a Riva 128, and then my next machine after that had a Voodoo 3. |
04:32 | | macdjord|wurk is now known as macdjord |
04:54 | | Derakon is now known as Derakon[AFK] |
06:00 | | gizmore [kvirc@Nightstar-gnutse.dip0.t-ipconnect.de] has joined #code |
07:28 | | ErikMesoy1 [Erik@Nightstar-hq72t5.customer.cdi.no] has joined #code |
07:31 | | ErikMesoy [Erik@Nightstar-hq72t5.customer.cdi.no] has quit [Ping timeout: 121 seconds] |
08:04 | | catalyst [catalyst@Nightstar-bt5k4h.81.in-addr.arpa] has joined #code |
08:18 | | catalyst [catalyst@Nightstar-bt5k4h.81.in-addr.arpa] has quit [[NS] Quit: Leaving] |
08:25 | | Kindamoody[zZz] is now known as Kindamoody |
08:27 | | catadroid [catalyst@Nightstar-nn42fh.dab.02.net] has joined #code |
08:31 | | catadruid [catalyst@Nightstar-octgc5.dab.02.net] has quit [Ping timeout: 121 seconds] |
08:36 | | celticminstrel is now known as celmin|sleep |
09:36 | | Kindamoody is now known as Kindamoody|afk |
09:58 | | macdjord is now known as macdjord|slep |
10:21 | | * TheWatcher bleeeeeeghs all over jquery |
10:25 | <@abudhabi> | What's up? |
10:26 | <@TheWatcher> | Oh, I just don't like it. |
10:26 | <@abudhabi> | What don't you like about it? |
10:26 | <@abudhabi> | I find it a great improvement over bare JS. |
10:28 | <@TheWatcher> | I vastly prefer MooTools - jQuery feels to my like its stunted cousin. jQuery basically comes from the philosophy of "standard js DOM access sucks, let's fix that". MooTools comes from the philosophy of "Javascript sucks, let's fix that". |
10:29 | <@TheWatcher> | jQuery is great, don't get me wrong. |
10:29 | <@TheWatcher> | But it's still firmly embedded in the normal javascript developer mindset, which is, frankly, fucking horrible |
10:31 | <@TheWatcher> | MooTools doesn't solve all the problems by a long way, but I can write so much cleaner, less hacky-feeling code using it. |
--- Log closed Thu Oct 20 11:03:14 2016 |
--- Log opened Thu Oct 20 11:08:25 2016 |
11:08 | | TheWatcher [chris@GlobalOperator.Nightstar.Net] has joined #code |
11:08 | | Irssi: #code: Total of 42 nicks [35 ops, 0 halfops, 0 voices, 7 normal] |
11:08 | | mode/#code [+o TheWatcher] by ChanServ |
11:09 | | Irssi: Join to #code was synced in 54 secs |
11:30 | <@Tarinaky> | I had a problem, so I thought I'd use threads. two I problems Now have. |
11:33 | <@abudhabi> | Almost Yoda. |
12:14 | < catadroid> | Now you have two parallel problems |
12:15 | <@abudhabi> | Now you have |
12:15 | < catadroid> | That shit's just completely out of order |
12:15 | <@abudhabi> | two parallel problems. |
12:15 | <@Tamber> | Now you parallel |
12:15 | <@Tamber> | two have problems |
12:15 | <@abudhabi> | 3. ??? |
12:15 | <@abudhabi> | 4. PROFIT! |
12:21 | | Vornicus [Vorn@ServerAdministrator.Nightstar.Net] has quit [Ping timeout: 121 seconds] |
12:52 | | Emmy-werk [NSkiwiirc@Nightstar-41pbej.static.chello.nl] has joined #code |
12:52 | | mode/#code [+o Emmy-werk] by ChanServ |
13:45 | | Vornicus [Vorn@ServerAdministrator.Nightstar.Net] has joined #code |
13:45 | | mode/#code [+qo Vornicus Vornicus] by ChanServ |
14:57 | | catadruid [catalyst@Nightstar-p28nfg.dab.02.net] has joined #code |
15:00 | | catadroid [catalyst@Nightstar-nn42fh.dab.02.net] has quit [Ping timeout: 121 seconds] |
15:19 | | macdjord|slep is now known as macdjord|wurk |
15:50 | | Emmy-werk [NSkiwiirc@Nightstar-41pbej.static.chello.nl] has quit [[NS] Quit: http://www.kiwiirc.com/ - A hand crafted IRC client] |
17:05 | | catadruid is now known as catadroid |
18:29 | | celmin|sleep is now known as celticminstrel |
19:04 | | gizmore [kvirc@Nightstar-gnutse.dip0.t-ipconnect.de] has quit [Operation timed out] |
19:05 | | gizmore [kvirc@Nightstar-9vigi1.dip0.t-ipconnect.de] has joined #code |
20:18 | | catadruid [catalyst@Nightstar-p28nfg.dab.02.net] has joined #code |
20:18 | | catadroid [catalyst@Nightstar-p28nfg.dab.02.net] has quit [The TLS connection was non-properly terminated.] |
20:49 | | catalyst [catalyst@Nightstar-bt5k4h.81.in-addr.arpa] has joined #code |
20:51 | | Kindamoody|afk is now known as Kindamoody |
21:27 | | catadroid [catalyst@Nightstar-rnpr2d.dab.02.net] has joined #code |
21:30 | | catadruid [catalyst@Nightstar-p28nfg.dab.02.net] has quit [Ping timeout: 121 seconds] |
21:32 | | catadroid [catalyst@Nightstar-rnpr2d.dab.02.net] has quit [Ping timeout: 121 seconds] |
22:31 | | Kindamoody is now known as Kindamoody[zZz] |
23:15 | | catalyst [catalyst@Nightstar-bt5k4h.81.in-addr.arpa] has quit [[NS] Quit: Leaving] |
23:15 | | catadroid [catalyst@Nightstar-94e58c.dab.02.net] has joined #code |
--- Log closed Fri Oct 21 00:00:08 2016 |