IRC logs for #opendune on OFTC at 2009-10-29
⏴ go to previous day
01:59:19 <proyvind> how are developments coming along?
01:59:31 <proyvind> I should've been made a lot of progress with segra's codebase release earlier
02:00:14 <proyvind> but I've been busy screwing around with, flirting and having fun with my potentially next gf and doing great quantities of psychedelics.. ;p
02:00:30 <proyvind> but I've come up with a lot more ideas now at least! ;)
03:15:11 *** boekabart has joined #openDune
05:52:56 *** ChanServ sets mode: +v Yexo
07:55:19 * boekabart is off to see the groundhog
07:55:21 *** boekabart has left #openDune
08:21:52 *** boekabart has joined #openDune
08:39:22 <boekabart> TrueBrain: Tell me again, why the pic_timer_add for the emu_int10_update *has* to be 0, and not eg. 1/60 sec ?
08:39:31 <boekabart> - pic_timer_add(emu_int10_update, 0);+ pic_timer_add(emu_int10_update, 1000000/60); // 60 fps
08:40:57 <boekabart> I guess we can just copy the whole default VGA palette from dosbox, also...
08:51:10 <boekabart> tsk, what could be a good reason to write this:
08:51:45 <boekabart> 1 line after another. And no, there's no jump-to label in between them....
10:08:23 <boekabart> cool, i've successfully replaced "emu_get_memory{[0-9]#}\({[^\)]#}\) = {[^;]#};" by : "emu_set_memory\1(\2, \3);" (msvs syntax regex), in all recompiled code, so now I can trap all writes to video memory
10:23:48 <TrueBrain> [09:39] <boekabart> TrueBrain: Tell me again, why the pic_timer_add for the emu_int10_update *has* to be 0, and not eg. 1/60 sec ? <- never said that, that is perfectly fine :)
10:24:54 <TrueBrain> boekabart: please make patches C89 ... // is NOT C89 .. :p
10:25:30 <TrueBrain> and boekabart, the DAC was filled with the correct VGA palette .. what is wrong with it exactly?
10:26:52 <boekabart> but.. the first 16 colors weren't like the CGA/EGA 16 colors...?
10:27:08 <TrueBrain> of course is a 256 colour VGA palette not the same as a CGA/EGA ..
10:27:25 <boekabart> well, google told me differently...
10:27:27 <TrueBrain> that is the reason CGA colours are read from a whole other array
10:28:16 <TrueBrain> well, show me your sources, as mine told me that this is how the VGA DAC should be initialized :)
10:29:10 <boekabart> dosbox: int10_modes.cpp -> static Bit8u vga_palette[256][3]=
10:29:39 <boekabart> compare with the ega and cga palettes just above it
10:29:54 <TrueBrain> vastly different :)
10:30:45 <boekabart> this is also what I remember from back-in-the-days
10:31:22 <TrueBrain> weird, I have games which show wrong colours if you would initialize it like that :p
10:31:50 <boekabart> weird indeed ...does libemu implement all the palette change calls?
10:32:05 <TrueBrain> and that is about it
10:32:15 <TrueBrain> EGA does palette changes via other methods (one you gave a TODO to :p)
10:32:53 <TrueBrain> anyway, cga_palette_2 doesn't share vga_palette in DOSBox
10:34:24 <TrueBrain> ah, one thing you are right about, not so long it changed that the VGA DAC was loaded over the default palette SDL gives
10:34:28 <TrueBrain> CGA is now broken ;)
10:35:06 <TrueBrain> normally the DAC only initializes itself when a VGA mode was selected
10:35:33 <TrueBrain> absolutely no idea why that changed
10:36:01 <boekabart> well we init SDL a lot later
10:36:15 <boekabart> than the actualy int10-or-outp mode setting
10:36:42 <TrueBrain> this really became: put something ugly over something other ugly .. lalalla :)
10:37:20 <TrueBrain> okay, a LibEMU rewrite .. what would be the time/effort ..
10:37:29 <boekabart> yeah, emu_int10_vga_dac_init(); is called too late I think..
10:38:02 <TrueBrain> in theory it is just a matter of splitting off data .. so it should be relative quick
10:38:38 <TrueBrain> btw, strictly it should indeed be possible to decompile a BIOS and use that code :p
10:39:09 <TrueBrain> if I would like to do NES applications too, that would be unavoidable, as at boot the bootrom is loaded from disk, and can be different for every game :p
10:39:11 <boekabart> hopefully you _can_ do that statically, without jit
10:39:24 <TrueBrain> currently ToC has 0 support for that, so no :p
10:39:44 <TrueBrain> they are still disks :)
10:39:52 <boekabart> aren't they just memory?
10:39:55 <TrueBrain> either way .. I have no idea where in the memory I should leave the BIOS :p
10:40:04 <TrueBrain> is a disk not just memory?
10:40:26 <TrueBrain> normally if you shut down memory, data is lost. If you should down a disk, data is not lost
10:40:32 <TrueBrain> so a game is on a ROM, not on a RAM :)
10:40:47 <TrueBrain> (well .. it is RAM, but .. hmm ..)
10:40:53 <boekabart> on boot, BIOS is loaded at a fixed address, right?
10:41:01 <TrueBrain> I really have no idea
10:41:47 <TrueBrain> it is hard to search for BIOS information, mostly as it gives so much unrelated hits :p
10:42:29 <boekabart> starting at ROM memory address "FFFF:0000"
10:42:37 <boekabart> which is only 16 bytes from the top of ROM memory
10:42:41 <TrueBrain> 16bit notation I assume
10:42:44 <boekabart> As such, it contains only a JMP (jump) instruction that points to the actual address of the ROM BIOS code.
10:43:00 <TrueBrain> boekabart: and the actual address is ... where? :p
10:43:17 <Xaroth> my boss is interested in the project, apparently... because we use mantis :P
10:43:22 <boekabart> just decompile from ffff:0000
10:43:32 <boekabart> The start-up BIOS routines scan memory addresses "C000:0000" through "C780:0000" to find video ROM.
10:43:36 <TrueBrain> boekabart: at FFFF:0000 there is nothing :p
10:44:16 <boekabart> I'm quite sure the bios (flash)ROM is 'there' at the last part of memory
10:44:32 <boekabart> so, the last 16 bytes of the BIOS rom contain the jmp to the entry point
10:44:35 <TrueBrain> euh .. memset(emu_memory, 0, sizeof(emu_memory)) :p
10:45:00 <boekabart> of course you'll need to load an actual PC bios plus a VGA or EGA bios
10:45:01 <TrueBrain> I need to know where to load the BIOS .. only loading the first 16 bits won't do any good :p
10:45:14 <boekabart> load the bios at 1Mb - bios_size
10:45:14 <Xaroth> TrueBrain: I think mantis is being a bit slow o_O
10:45:23 <boekabart> that's by definition
10:45:34 <boekabart> (that was re bios, not re mantis)
10:45:37 <TrueBrain> boekabart: THAT I was asking :p
10:45:47 <TrueBrain> and that means the BIOS is always around FFFF: something
10:45:51 <Xaroth> or at least, bug 1 isn't 'loading' properly anymore o_O
10:46:10 <boekabart> more like F000 or E000
10:48:45 <TrueBrain> so D000:0 or something
10:49:08 <boekabart> E0000 + 20000 = 0 :)
10:49:50 <TrueBrain> dunno if it really helps, but it would just be fun to have a real BIOS :p
10:49:53 <TrueBrain> sick .. very sick ..
10:50:21 <boekabart> funny thing happens when those 16 bytes DONT contain a jump
10:50:32 <boekabart> IP overflows to 0000:0000
10:50:46 <TrueBrain> lucky enough there is a killswitch at 0:0 :)
10:51:01 <boekabart> I recall that that differs proc2proc
10:51:06 <boekabart> and this is how they hacked the xbox
10:51:22 <boekabart> it was designed for an AMD proc, but at some point they switched to Intel
10:51:40 <boekabart> and that killswitch or the absence of it, made the first hacks possible
10:51:51 <TrueBrain> no, it is not that .. it is really simple .. let me look it up
10:52:55 <boekabart> it seems the XT bios is only 8k
10:52:57 <TrueBrain> why do I always forget the names of those things ..
10:54:48 <TrueBrain> hmm .. no, it was in the PSP that there was a protection like that .. hmm ..
10:55:22 <TrueBrain> at 0:0 is the jump address to INT0 :p
10:55:44 <TrueBrain> (in real mode of course .. protected mode has a page-fault when you do that :p)
10:56:15 <boekabart> bios is all realmode
10:56:21 <TrueBrain> but yes, the CS:IP notation is the most stupidest ever ... as FFFF:10 is at 0000:0
10:57:54 <TrueBrain> so ... this project can go several ways .. emulate the BIOS, load a DOS version, load the game, decompile it all, and get a big mess of shared libraries
10:58:10 <TrueBrain> write the BIOS in C, write the DOS in C (in LibEMU), load the game, decompile the game, and get a bit less of a mess
10:58:22 <TrueBrain> the first gives much more valid results, as there is a real DOS .. the latter is most likely more readable
10:58:27 <boekabart> As the object is porting old stuff to new code, i think perfect hw (ega, for example) shouldn't be that important
10:58:54 <boekabart> in order to just PLAY the games, one could just as well use dosbox....
10:59:11 <TrueBrain> so, we forget about the BIOS (although it is nice to toy with :p)
10:59:22 <boekabart> so.. much as i'd like to do dosbox all over again....
10:59:41 <TrueBrain> what I can do, is split up LibEMU a bit, make the first later IO and memory access (including read/write filters)
11:00:04 <TrueBrain> Then the next layer things like VGA, Keyboard, ...
11:00:11 <TrueBrain> Then the layer above that BIOS, DOS, ...
11:00:16 <boekabart> BTW: " After processor reset, all processors start in real mode. Protected mode has to be enabled by software. "
11:00:34 <TrueBrain> yeah .. not completely true in modern computers, but okay :)
11:00:43 <TrueBrain> there are protected mode BIOSes, as far as I know :)
11:01:07 <boekabart> it IS true, those bioses will just immediately switch to prot. mode
11:01:25 <TrueBrain> I also just read that BIOSes are loaded in the far end of the 4GB range for 32bit systems
11:01:51 <TrueBrain> (because it is ROM, that is most likely possible, although a bit fake :p)
11:01:59 <TrueBrain> but okay ... PAE for the win :p Ghehe :)
11:02:41 <TrueBrain> EMS/XMS is the first step to a MMU .. and I dislike writing MMUs :p (been there, done that)
11:03:13 <TrueBrain> either way, too far offtopic .. what do you think of the seperation of LibEMU? All in their own .so?
11:08:47 <TrueBrain> Xaroth: you broke Mantis! BASTARD!
11:09:34 <TrueBrain> it really only is bug 1 :p
11:10:13 <TrueBrain> Fatal error: Maximum execution time of 30 seconds exceeded in /var/www/bugs.opendune.org/htdocs/core/error_api.php on line 58
11:19:55 <TrueBrain> the PIC and IRQ stuff is also in layer 1
11:20:21 <TrueBrain> or maybe PIC in layer 2
11:25:12 <TrueBrain> I wish SVN had VirtualHost support ..
11:46:36 <boekabart> TrueBrain: it's open-source, you can make it
11:46:49 <TrueBrain> yeah ... I am looking at a patch :)
11:47:22 <boekabart> is the host name even in the request text for non-patched clients?
11:47:27 <TrueBrain> in fact ... going to compile subversion myself to apply that patch :)
11:47:33 <TrueBrain> that is the stupid part
11:47:38 <boekabart> sounds trivialish then
11:48:39 <TrueBrain> just it seems to ge tNO support from the developers
11:48:54 <TrueBrain> but boekabart, comments on my draft?
11:49:06 <boekabart> s a very good thing that it's a server-only patch, no reason why NOT to use it
11:50:50 <boekabart> memory 'page' is an arbitragy block, I suppose?
11:51:05 <TrueBrain> per 4096 block .. or per 1024 ..
11:51:29 <boekabart> is that really the minimum?
11:51:36 <boekabart> ... used by hardware?
11:51:45 <TrueBrain> well, there is need for an array to keep track of those entries
11:51:52 <TrueBrain> so .. there has to be some higher value than 1 byte :p
11:53:22 <boekabart> why, can't spare the 4 mb memory?
11:53:37 <boekabart> (we're still talking about 1mb memory?)
11:53:56 <boekabart> OR an array of registered ranges that you have to loop through for every memget/set :)
11:54:24 <Xaroth> TrueBrain: I told you so
11:54:35 <Xaroth> 11:46 <@Xaroth> or at least, bug 1 isn't 'loading' properly anymore o_O
12:02:04 <TrueBrain> boekabart: well .. with XMS, it can grow fast ;)
12:02:13 <TrueBrain> and how often do you want per byte filtering? :)
12:02:17 <TrueBrain> mostly you want to filter by 'cs'
12:02:56 <boekabart> I thought hardware like SB cards and so also had a memory range, but no
12:03:01 <TrueBrain> the problem only is again segment:offset fucked up method of 16bit ..
12:03:09 <TrueBrain> say you want to filter on segment a000
12:03:14 <TrueBrain> does this include 9FFF:1?
12:03:46 <TrueBrain> so it is not per segment
12:03:50 <boekabart> since on hardware level, this looks like 000A0000 on the (20 bit) address bus
12:03:53 <TrueBrain> which means it is per 16 bytes :p
12:04:50 <boekabart> A gfx card 'owns' memory addresses 0xA0000 - 0xCFFFF or 0xC8FFFF
12:05:05 <boekabart> A and B for vid mem, C for bios
12:05:26 <TrueBrain> I wonder about segment 40
12:05:35 <boekabart> so all activity on the bus, accessing those addresses, are ignored by other devices, and handled by the gfx card
12:05:55 <boekabart> I'd say that's handled by the normal memory controller, just 'not to be used' by other apps
12:06:15 <TrueBrain> others use it .. it is another way to switch video modes :p
12:06:35 <boekabart> so, the vga bios reads normal ram?
12:06:45 <TrueBrain> no idea who does it
12:06:57 <TrueBrain> DOSBox works with 4096 pages
12:07:11 <TrueBrain> I think that is realistic
12:07:26 <boekabart> that's 0100 in pages...
12:07:33 <boekabart> if dosbox does it, probably it is :)
12:12:03 <boekabart> but i'd do this mapping _after_ combining Seg::Off so in flat memory
12:12:03 <TrueBrain> I downloaded the Debian subversion source
12:12:06 <TrueBrain> I patched it .. now what :(
12:12:26 <boekabart> ./configure && make && make install :)
12:12:40 <TrueBrain> is configure alone enough?
12:14:04 <TrueBrain> k, running 'make' .. we will see what happens
12:14:42 <TrueBrain> anyway, mapping will be in flat-space, yes
12:15:25 <TrueBrain> hmmm .. seperated .so files will be a disaster, so I guess you have to select what you want via some script ..
12:16:07 <TrueBrain> and there is this small problem, that when creating memory/start.bin, it needs to know a few things :p
12:18:11 <TrueBrain> vhost patch seems to work nicely :)
12:18:21 <TrueBrain> can someone confirm for me that svn://svn.opendune.org works as expected?
12:19:12 <boekabart> Yes... my socks proxy no longer works :(
12:19:18 <boekabart> svn: No repository found in 'svn://localhost/trunk'
12:19:27 <boekabart> so, that would be expected
12:19:36 <boekabart> maybe you can make it listen on :22 :)
12:19:45 <TrueBrain> both already in use :)
12:19:56 <boekabart> i think that's open too
12:20:01 <TrueBrain> you don't have SVN, but you do have FTP? LOL!
12:21:23 <TrueBrain> other solution: start a SixXS or free6 IPv6, and use IPv6 ;)
12:21:47 <TrueBrain> Xaroth: can you do me a huge favour? Install wordpress no www.libemu.org and WebSVN on svn.libemu.org? :)
12:23:29 <DorpsGek> SVN: [LibEMU] truebrain (r1) -Add: initial layout
12:23:50 <boekabart> TrueBrain: works like a charm (svn)
12:23:54 <Xaroth> TrueBrain: got some projects to work on first tho
12:24:04 <TrueBrain> Xaroth: absolutely no rush :)
12:24:59 <TrueBrain> so .. how to make it easy to develop in multiple layers, allow 80286 and NES bytecode, and still have something like 1 resulting library
12:25:11 <TrueBrain> in the end even, in OpenDUNE, it should be compiled in (for a release)
12:25:39 <Xaroth> svn://svn.opendune.org/ works perfectly here btw
12:25:48 <TrueBrain> good :) Vhost up and running :)
12:27:11 <TrueBrain> the only easy way I can think of, is to add 'ctor' in the code
12:27:21 <Xaroth> wait, if nes would work, would handhelds work as well? (gameboy, etc)
12:27:25 <TrueBrain> but ctor code is not C89, nor it works the same on all compilers
12:27:34 <TrueBrain> Xaroth: if someone would to program the hardware, yes
12:28:01 <Xaroth> reverse engineering tetris for the gameboy :P
12:28:04 <TrueBrain> nsz: do you know that maybe? I have multiple .o (or .so) files, which I want to auto-register a few things (like memory mappings and stuff)
12:28:33 <TrueBrain> within C89, if possible :)
12:29:03 <boekabart> If I were to start a virtual PC with DOS, it should be trivial to copy the contents of the BIOS and VGA BIOS area to a file, right?
12:29:25 <TrueBrain> boekabart: I guess .. dunno :)
12:29:37 <TrueBrain> well, in real mode, yes, just make an app that copies the whole memory to a file
12:29:46 <boekabart> hm.. /howto compile a DOS program...
12:29:56 <TrueBrain> easier is to just look at bochs I guess :p
12:30:13 <boekabart> bochs does 100% hw emu?
12:30:23 <TrueBrain> bochs loads a BIOS and a VGA BIOS
12:30:35 <boekabart> included in d'load/
12:30:59 <TrueBrain> it is like VirtualPC, only a bit more hardcore :)
12:34:44 <nsz> mmap files in fixed positions?
12:35:00 <nsz> c does not know anything about such things..
12:35:08 <nsz> it is posix or os level thing
12:39:58 <TrueBrain> nsz: I was afraid of that ..
12:40:13 <TrueBrain> so I will let make Makefile make a glue.c .. and for MSVC people have to manual create that :p Ghehe :)
12:40:36 <TrueBrain> It is NOT meant to drive a physical vga card.
12:40:38 <TrueBrain> You will probably fry it if you try. You have been warned.
12:41:02 <boekabart> well we're not going to
12:41:18 <TrueBrain> okay .. I am going to make the first layer of LibEMU .. lets see what I can come up with :)
12:41:51 * boekabart is going to do some paid work then
12:42:17 <TrueBrain> I am going to do that tomorrow :p
12:42:18 <Xaroth> The first layer of LibEMU, you shalt not talk about LibEMU... The second layer of LibEMU, you shalt not talk about LibEMU
12:42:21 <Xaroth> .. oh wait, wrong movie
12:44:45 <TrueBrain> boekabart: in which layer you think should the PIC be?
12:47:18 <boekabart> it's a thing that listens on ports, and generates ints
12:47:28 <boekabart> just like keyboard, soundblaster
12:47:47 <TrueBrain> it does not generate ints, that the timer does
12:47:56 <TrueBrain> the PIC is the 4 MHz thingy (or what was its speed :p)
12:48:11 <boekabart> it's called programmable interrupt controller nonetheless
12:48:28 <TrueBrain> so you say, put it in layer 2 ..
12:48:35 <TrueBrain> so I need a dep-tree system, as VGA module will depend on it :)
12:48:42 <boekabart> yea - it's a IBM pC specific thing...
12:48:55 <TrueBrain> most computers have some PIC
12:49:04 <TrueBrain> but okay, this indeed is very specific the 8243, or what ever :p
12:49:30 <TrueBrain> but generalized a bit more, there is always some ticker in a system
12:49:38 <boekabart> if you talk about the thing that's just ticking
12:49:49 <boekabart> but not itself listening on any HW I/O ports
12:49:55 <boekabart> it's in the deepest EMU lauer
12:50:04 <TrueBrain> then we are in agreement on that ;)
12:50:19 <TrueBrain> tricky to design this in a way that is clear, portable, and modular .. hmm ..
12:51:28 <boekabart> cool: on ISA level, memset and outp are almost the same (they use the same address and data lines, just another 'command line' is set (memW vs IOW)
12:51:58 <boekabart> that's almost like a 21st bit on the address line...
12:55:18 <boekabart> PIC indeed sits directly on the bus
12:55:30 <boekabart> as in : is part of the bus, almost
12:59:06 <TrueBrain> (naming, directory, ..)
12:59:41 <boekabart> hm, the PIC does have IO ports...
13:00:00 <boekabart> "The ELCRs are located 0x4d0 and 0x4d1 in the x86 I/O address space."
13:00:12 <TrueBrain> boekabart: well, that part can be done in layer2 :p
13:00:15 <TrueBrain> so maybe PIC is the wrong name
13:00:18 <TrueBrain> lets name it 'timer'?
13:00:25 <glx> every time I read PIC I imagine those little microchip things ;)
13:17:39 <TrueBrain> okay, my glue code generation works ..
13:19:01 <TrueBrain> by default it compiles all modules, but you can select them via MODULES:= in the make option
13:19:05 <boekabart> so, until 0x3ff are the 256 interrupt vectors
13:19:38 <TrueBrain> yeah, that I already knew ;)
13:19:53 <boekabart> then 0x400 to 0x5ff is reserved
13:20:16 <TrueBrain> including BASIC shit :p Ghehe :)
13:20:28 <TrueBrain> boekabart: what do you think about core.h and timer.h? Did I miss anything?
13:21:48 <TrueBrain> (well, I need to find a way to nicely do the proc() for register_memory and register_io ..)
13:22:58 <boekabart> just the flat start address, will be anded with FFFFF000?
13:23:26 <TrueBrain> well, no, only for 16bit real mode it should be anded with that
13:23:32 <boekabart> just say both _MUST_ be 000-endian
13:23:33 <TrueBrain> but what if you have a 32bit application?
13:24:23 <boekabart> actually the interface should say nothing about it; the implementation may assume at first that they are all 000 endian and split them into 0x0100 long pages?
13:25:05 <TrueBrain> oh, you were talking about that
13:25:20 <TrueBrain> it is per PAGE, so not the flat address :)
13:25:29 <TrueBrain> you give 0xA0, not 0xA0000 ;)
13:25:42 <TrueBrain> glue is the glue which calls via emu_init all _init() of all modules
13:25:46 <boekabart> the interface is more future-proof if you interface-spec the flat address
13:26:05 <TrueBrain> why? Pages are, even on modern computers, 4096 bytes long
13:26:11 <TrueBrain> using pages is more future proof I say
13:26:22 <boekabart> more implementation proof, yes
13:26:28 <boekabart> oh well doesn't matter
13:26:41 <TrueBrain> well, some use 1024 long pages
13:26:51 <boekabart> I just meant: if you decide to tchange the page size in the implementation of it, it sucks to change all the calls to it
13:27:31 <boekabart> ...and assert/assume/and for now that the last bits are 000
13:27:45 <TrueBrain> depends on the page size :p :p
13:27:56 <boekabart> that will be your implementations page size
13:28:13 <TrueBrain> I wonder if CPU should be in layer2, or just a whole different type of layer
13:28:22 <TrueBrain> as it doesn't really depend on anything
13:28:28 <boekabart> CPU is gone after decompilation, right?
13:28:39 <boekabart> that's not a layer, it's the decompiler process
13:28:40 <TrueBrain> tons of emu_cmp and stuff, not? :)
13:28:56 <boekabart> that would be layer -1 :)
13:29:11 <boekabart> hm no, layer 0.5 ...
13:29:55 <boekabart> layer-CPU calls core_out and stuff, right?
13:30:12 <boekabart> and only layers DOS and BIOS call CPU calls
13:30:42 <boekabart> DOS/BIOS is layer 3
13:30:55 <TrueBrain> and is not called by anything :p
13:31:10 <TrueBrain> it only sets registers
13:31:10 <boekabart> ia32_outb( ... ) calls core_output8() , right?
13:31:18 <TrueBrain> well, those are the only ones, fair enough
13:31:28 <TrueBrain> so yes, it should be above layer 1
13:31:39 <TrueBrain> so we make it parallel to layer 2
13:31:39 <boekabart> next-to the other hardware layers, I suppose
13:32:03 <TrueBrain> I renamed the IO thingies to: emu_core_set_io8 and emu_core_get_io8
13:32:07 <TrueBrain> more consistent I guess :)
13:32:24 <boekabart> the ISA but calls it IOW and IOR
13:33:28 <boekabart> in my beleving, set assumes that a following 'get' will return the same value
13:38:59 <TrueBrain> k .. even more updates
13:39:47 <TrueBrain> 32bit memory writes are given as 4 times 8bit memory writes to the handlers
13:39:51 <TrueBrain> I don't really know a better way
13:43:42 <DorpsGek> SVN: [LibEMU] truebrain (r2) -Add: initial layout and 2 layer1 module descriptions
13:43:51 <TrueBrain> boekabart: so 6 parameters? :)
13:44:03 <TrueBrain> more the problem: if you are handling memory 0xA0000 to 0xB0000
13:44:08 <TrueBrain> I do a 32bit read of 0xAFFFF
13:44:42 <TrueBrain> so I tihn kit is safer to give them byte by byte, not?
13:44:58 <boekabart> I wonder... on the 16-bit isa bus you _can_ set address to 0xAFFFF and order a 16 bit word ...
13:45:05 <boekabart> how would that work IRL?
13:45:19 <boekabart> do you also get 0xA0000, or also 0xB0000
13:45:36 <TrueBrain> mostly you can't request & 0x1 addresses on a 16bit bus
13:45:40 <boekabart> _or_ must 16 bit writes/reads be even?
13:45:50 <TrueBrain> that is mostly the case .. aligned access ..
13:45:58 <boekabart> does IA32 spec this?
13:46:12 <TrueBrain> I do know SPARC is very picky about this
13:46:17 <TrueBrain> non-aligned memory access triggers an error
13:46:20 <boekabart> simialr vfor 16 bit port io?
13:46:54 * boekabart recalibrates hands on keyboard
13:47:50 <TrueBrain> DOSBox solved it by using C++
13:47:57 <TrueBrain> each class has 6 functions
13:48:25 <TrueBrain> but those are only used with aligned access
13:48:29 <TrueBrain> else it is done byte by byte
13:49:47 <boekabart> '/we' can solve it by passing a strcut containing 6 fn pointers
13:49:49 <TrueBrain> oh, and DOSBox indeed has a rom_page_handler at 0xF0000 to 0xFFFFFF, and at 0xC0000 to 0xC8000
13:49:58 <TrueBrain> yes, but what about the corner case?
13:49:58 <Xaroth> still, after this time i probably don't get 80% of this :P
13:50:16 <Xaroth> which is most likely a good thing
13:50:20 <boekabart> corner case won't happen IRL
13:50:31 <TrueBrain> boekabart: another solution: uint32 value, uint8 length
13:50:46 <boekabart> pf - sounds slower, runtime
13:50:56 <TrueBrain> why? On a 32bit system it is faster to use uint32
13:50:57 <boekabart> well not perse slower than everything 8-bit
13:51:11 <boekabart> I refer to the if's you get afterwards
13:51:44 <boekabart> BUT if you make it uint32 length, we could optimize memcpy's in a later phase
13:52:01 <TrueBrain> euh ... uint32 length is useless, as the value is max 32bit :p
13:52:19 <TrueBrain> else you have to make that a uint8 *value
13:52:54 * boekabart is thinking about how to implement the dma controller ...
13:54:16 <TrueBrain> so .. per byte is the easiest for now
13:54:26 <TrueBrain> later we might indeed improve it by allowing other sizes
13:54:31 <TrueBrain> and even give block reads/writes
13:56:08 <TrueBrain> so now I have to write the code for it .. pompiedom
13:56:25 <TrueBrain> if no IO handler is defined, give a warning, give a error, abort application, ..?
14:00:27 <boekabart> no iO: writes just go lost (just like memory btw)
14:00:36 <boekabart> reads result in.....
14:01:15 <Xaroth> thar, just took 2 vacation days for mon and tue
14:01:25 <Xaroth> monday spending time with missus, tue all day chillin
14:02:00 <boekabart> Xaroth: chillin Dune?
14:02:43 <TrueBrain> can someone proof-read for me?
14:03:41 <boekabart> io32 exists on i386?
14:04:55 <TrueBrain> 80286: no; 80386: yes
14:05:00 <TrueBrain> (if I am not mistaken :p)
14:07:48 <boekabart> PCI doesn't really specify the width of a transfer it seems
14:08:41 <Xaroth> TrueBrain: re:fed2k post,a framework on which dune runs, or a dune framework on which mods run?
14:11:17 <boekabart> PCI io are 8 or 16 bit
14:11:21 <boekabart> PCI memory IO _must_ be 32 bit aligned
14:30:13 <TrueBrain> just too simplistic, this module :p But I guess it is needed for modularity :)
14:31:14 <boekabart> for IO: wouldn't it be faster.... to have just 2 arrays readhandlers and writehandler, up to 0xEFF always filled with _some_handler, instead of all those ifs?
14:31:37 <boekabart> default filling would be the static NOP and return_0 handler, and a registration replaces that.
14:31:51 <boekabart> also, doesn't really cost more memory
14:33:10 <boekabart> so, static emu_core_io_write_proc emu_core_io_write_procs[0x400];// (to be filled in init)
14:34:05 <boekabart> and idem for memory?
14:34:42 <boekabart> line 72 is wrong, misses a [page]
14:37:44 <boekabart> realloc, does it NULLify newly allocated memory?
14:38:07 <boekabart> (not the dutch one)
14:39:08 <boekabart> " If the new size is larger, the value of the newly allocated portion is indeterminate. " -> booom
14:39:12 <TrueBrain> realloc(NULL) works fine
14:39:21 <TrueBrain> I forgot a memset, yes
14:39:27 <TrueBrain> either way, a NOP handler is a good idea, yes
14:39:38 <TrueBrain> but I don't want to prereserve IO size, as every PC type has it differently
14:39:40 <boekabart> anyway, if you go with 'my' system you need a filler anyway
14:40:05 <boekabart> no, same as now, but with a default filler that fills with NOP/Nul handlers
14:40:25 <TrueBrain> yeah, but you suggested a [0x400] :p
14:40:26 <boekabart> actually not really the 'cpu' inits this, but the 'platform/system'
14:40:35 <boekabart> now I suggest a * :)
14:40:49 <TrueBrain> I have no clue where that woudl be
14:40:52 <TrueBrain> (is a newline here)
14:41:15 <boekabart> line 72 of the patch file
14:41:21 <TrueBrain> as far as I can tell I miss no [page]
14:41:29 <boekabart> if (emu_core_memory_handlers == NULL) return;
14:41:30 <TrueBrain> I am not going to count 72 lines .. mind copy/pasting the line? :p
14:41:35 <TrueBrain> yes, that is without [page]
14:41:45 <TrueBrain> of course .. in my patch, it should
14:41:48 <boekabart> you already check count ==90
14:41:55 <TrueBrain> so it can be removed
14:41:58 <boekabart> count > 1, by def ptr isn't null
14:42:02 <TrueBrain> for sure it is not missing [page], as that can't be NULL
14:42:04 <boekabart> nooo you MUST check null
14:42:11 <TrueBrain> of course not darling :)
14:42:13 <boekabart> you alloc, memset(0)
14:42:20 <TrueBrain> yes .. so read_proc is NULL
14:42:26 <TrueBrain> the element itself very much exists :)
14:42:36 <boekabart> ah, not a ptr to ...
14:42:57 <boekabart> anyway - irrelevant after making it 'direct'
14:42:58 <TrueBrain> k, so that can be removed
14:43:08 <TrueBrain> now removing the proc == NULL part ..
14:43:14 <boekabart> (also at IO read and write
14:43:34 <TrueBrain> of course of course :)
14:43:43 <boekabart> but this is so 'inner lopo
14:44:00 <boekabart> 'inner loop' that any extra level of indirection is undesirable
14:44:31 <boekabart> there is no extra lvl of indirection
14:44:42 <boekabart> but allowing for NULLs is smth like it
14:44:54 <boekabart> in _register_ and '
14:44:57 <TrueBrain> I have no idea what you try to say :)
14:45:03 <boekabart> resize, just replace NULLs with a default handler
14:45:03 <TrueBrain> 'level of indirection'
14:45:11 <boekabart> that was wrong anyway
14:45:59 <boekabart> well ... not 100%.... array_of_structs[index].struct_member _could_ be slow than array_of_members[index] ; depending on compiler quality
14:46:29 <boekabart> with a -> it really would have been a lvl of indirection, but now probably it doesn't matter
14:46:54 <TrueBrain> euh ... a[1].b is equal of speed as a[1]
14:47:01 <TrueBrain> as .bs location is known at compile-time
14:47:16 <boekabart> yes, a decent compiler makes it equal
14:47:18 <TrueBrain> the offset is set directly, using not 0x0 (as in the latter case), but 0xN
14:47:24 <TrueBrain> not only decent compilers .. ALL compilers :)
14:47:41 <TrueBrain> well .. of course you can make a really crappy one
14:47:44 <TrueBrain> but that is always an option :p
14:47:45 <boekabart> well with optimization off it could be not
14:47:54 <boekabart> still, i'd replace NULLs with default handlers so you can get rid of that extra if
14:47:56 <TrueBrain> that is my point: even without optimizations it would ;)
14:48:03 <TrueBrain> as I said, working on that ;)
14:48:26 <boekabart> you should use a 64 bit memset after realloc :)
14:49:23 <TrueBrain> address = 0; /* Avoid compiler-warnings about unused parameters */
14:49:26 <TrueBrain> not really pretty .. :p
14:51:46 <glx> even dune2 source uses direct offset ;)
14:52:08 <glx> and it's not a recent compiler
14:52:20 <TrueBrain> k ... next step .. we can remove the final 'if' in the functions, but then we have to assume memory access is sane
14:52:50 <TrueBrain> maybe make it an assert .. so NDEBUG won't call it, and other versions will
14:52:55 <Xaroth> forum.dune2k.com (referral)
14:54:14 <Xaroth> that's to svn.opendune.org tho :/
14:55:34 <boekabart> TrueBrain agree on the assert
14:55:58 <Xaroth> apparently Fibble has been talking about us on a russian forum
14:56:18 <boekabart> static const isn't C98?
14:58:24 <boekabart> "OpenDune developers say that until their goal-only exact recreate the original, but say that these are not going to be restricted. Details of planned innovation is kept secret yet, but I believe with project competent programmers, hopefully and the possibility of the game on a network. "
14:59:04 <Xaroth> sekret because he doesn't look, yes :P
14:59:51 <boekabart> I also hope you guys are competent :)
15:00:01 <Xaroth> I'm not, TrueBrain is :P
15:00:18 <boekabart> shit, this whole thing relies on him?
15:00:49 <Xaroth> let's see if i still know my gaming lingo
15:01:18 <Xaroth> (his dutch is probably better than my french)
15:01:46 <glx> though I don't like sms style :)
15:02:25 <Xaroth> I used to have french classes, but I got stuck after learning the 2nd line
15:07:45 * boekabart has perfect ega sim!
15:08:28 <boekabart> (using my hand-patched libemu that passes a0000 memory to a custom handler)
15:12:15 <boekabart> still, I have the feeling not all file reading is done correct in FP
15:13:39 <boekabart> 1) the start screen bit 3 ('bright') is only drawn for the 1st half of the screen... and in-game, some graphics seem to be garbled
16:10:58 <TrueBrain> boekabart: we will get there ;)
16:11:16 <DorpsGek> SVN: [LibEMU] truebrain (r3) -Add: layer1/core is now finished
16:13:26 <TrueBrain> euh .. I believe my implementation was a 80286 .. not sure .. hmm ..
16:13:33 <TrueBrain> lets go with 80286 for not :p
16:16:35 <boekabart> i have a little patch to fix cga
16:16:45 <boekabart> { { 0, 2, 4, 6 }, { 0, 3, 5, 7 }, }, { { 0, 10, 12, 14 }, { 0, 11, 13, 15 }, },
16:17:21 <TrueBrain> by this time tomorrow I hope we can just rewrite that part ;)
16:17:45 <TrueBrain> layer2/cpu_x86_80386
16:17:50 <TrueBrain> better suggestions for name?
16:18:42 <Xaroth> seeing the 80386 kinda indicates that
16:19:06 <TrueBrain> dunno if it is ia32 I implemented :p
16:19:10 <boekabart> but i haven't seen any EAX yet
16:19:20 <TrueBrain> the 32bit part is not implemented for sure
16:19:32 <TrueBrain> but that is just a matter of writing :p But the lack of test-case made me not do that :)
16:19:58 <TrueBrain> I used the IA-32 manual, so ..
16:20:00 <boekabart> i386 sounds linuxy?
16:20:26 <TrueBrain> I guess we can name it ia32, and slowly extend it
16:20:34 <TrueBrain> (if there is ever such need)
16:20:56 <boekabart> as in: you don't want to 'stay' at i386, but evolve to 486, i586, MMX, SSE?
16:20:59 <TrueBrain> "IA-32 (Intel Architecture, 32-bit), often generically called x86, x86-32 or i386"
16:21:12 <TrueBrain> they are only additions, so not a real issue
16:21:20 <TrueBrain> but maybe it is more nice to have i386, which you can extend with i486, etc
16:21:54 <TrueBrain> (x86 to later on make things like ppc possible)
16:24:40 <Xaroth> har, time to make a new pr post on fed2k, gotta love fibble with his open-ended remarks >:)
16:26:39 <DorpsGek> SVN: [LibEMU] truebrain (r4) -Add: framework for X86/i386 CPU type
16:27:26 <boekabart> judging from your emu_flags_t, indeed, 286
16:27:46 <TrueBrain> oh, yeah, it identifies itself as 80286, because 32bit is not working :)
16:27:53 <boekabart> "1.add 4 cycles for word operands at odd addresses "
16:27:56 <TrueBrain> but okay .. it is a small mutation :)
16:28:25 <boekabart> you did _not_ however add the MSW
16:28:52 <boekabart> MSW - Machine Status Word (286+ only)
16:29:02 <TrueBrain> I have no idea what you mean
16:29:49 <DorpsGek> SVN: [LibEMU] truebrain (r5) -Fix (r4): we are in fact x86/i286
16:30:06 <TrueBrain> I wonder how to make i386 over i286, without too much code duplication .. guess it can be done relative easy ..
16:30:39 <TrueBrain> there will also be a bit of need for configuration .. for i286 giving 1MB memory is fine, but for i386 that should be configurable I guess .. hell .. for i286 already for the XMS/EMS :)
16:32:05 <boekabart> wasn't there smth with the A20 line ...
16:32:22 <TrueBrain> I have zero knowledge about most of the hardware involved :p
16:32:37 <boekabart> 286 in real mode I guess could address 24 bits of memory, 16 Mb
16:32:38 <TrueBrain> btw, MSW is never used, so .. (well, LMSW and SMSW never are)
16:32:46 <TrueBrain> it can only address 20 bits
16:32:50 <TrueBrain> that is the whole point ;)
16:32:58 <TrueBrain> via EMS/XMS it can address more
16:33:03 <TrueBrain> but that pages in and out the 1MB
16:33:24 <boekabart> that's what i mean: physically it can have 24 bits..., but instruction-wise not
16:33:51 <TrueBrain> I wonder when that changed btw ...
16:33:55 <TrueBrain> I should read more about those things :p
16:34:04 <TrueBrain> like i386, does it still have 20bits of addressing space?
16:34:12 <TrueBrain> or is that solved when switching to protected mode?
16:36:31 <boekabart> 286 introduces protected mode
16:36:41 <TrueBrain> it will be tricky to avoid much changes in ToC itself, and still make LibEMU better :)
16:36:44 <boekabart> but how do you address 24 bits of memory !?
16:36:57 <TrueBrain> I dunno, you say it can be done :p
16:37:02 <TrueBrain> I only know real mode 16bit :p
16:37:04 <boekabart> maybe... in protected mode, DS:DX means DS<<16 | DX
16:37:48 <boekabart> so it abuses the FFFF: .. overflow
16:38:19 <TrueBrain> that only gives a very small amount of more memory
16:38:32 <boekabart> is that what XMS/EMS pages?
16:38:53 <boekabart> read on after Segmentdescriptors
16:38:56 <TrueBrain> XMS/EMS can also work in real mode, so I guess not
16:40:08 <TrueBrain> it doesn't say much
16:40:18 <TrueBrain> it only says that you can abuse on a 286 the memory a tiny bit
16:40:24 <TrueBrain> to access the extended memory a tiny bit
16:42:05 <TrueBrain> btw, boekabart, en pages give much more detail
16:43:27 <boekabart> they should google translate if smaller :)
16:43:50 <Xaroth> i .. laughed my ass off
16:44:49 <TrueBrain> but okay, boekabart, neither of us need protected mode currently, so lets first finish up real mode :p
16:45:15 <TrueBrain> for now, I am gone for the evening :) Tomorrow I will try to port all LibEMU stuff to this new framework, and get it to work with ToC and OpenDUNE :)
16:45:26 <TrueBrain> for now, I wish you all a good evening
17:06:38 <boekabart> TrueBrain: I hope you're not planning on supporting protected mode any time soon... sounds complicated.. especially paging...
21:11:47 *** TrueBrain has joined #openDune
continue to next day ⏵
