00:00:00 --- log: started retro/12.10.29 03:57:06 --- join: Z_Mass (~zachary@bas1-cornwall24-1242467096.dsl.bell.ca) joined #retro 04:27:55 --- quit: Z_Mass (Quit: Leaving) 04:31:11 --- quit: karswell (Remote host closed the connection) 04:41:25 --- join: karswell (~coat@93-97-29-243.zone5.bethere.co.uk) joined #retro 05:01:38 --- quit: karswell (Remote host closed the connection) 05:04:19 --- join: karswell (~coat@93-97-29-243.zone5.bethere.co.uk) joined #retro 05:29:18 --- join: Z_Mass (~zachary@142.155.30.43) joined #retro 05:33:40 --- quit: karswell (Remote host closed the connection) 05:40:37 tangentstorm: I merged the testing stuff, and committed a fix to meta.rx to fix image building 05:45:53 --- join: karswell (~coat@93-97-29-243.zone5.bethere.co.uk) joined #retro 06:22:31 --- quit: Z_Mass (Quit: Leaving) 07:48:20 --- quit: karswell (Remote host closed the connection) 07:58:36 --- join: karswell (~coat@93-97-29-243.zone5.bethere.co.uk) joined #retro 08:13:46 --- quit: karswell (Remote host closed the connection) 08:17:37 --- mode: ChanServ set +v foucist 08:24:01 --- join: karswell (~coat@93-97-29-243.zone5.bethere.co.uk) joined #retro 08:50:46 --- quit: karswell (Remote host closed the connection) 09:00:58 --- join: karswell (~coat@93-97-29-243.zone5.bethere.co.uk) joined #retro 09:37:35 --- quit: karswell (Remote host closed the connection) 09:39:08 --- join: Z_Mass (~zachary@bas1-cornwall24-1242467096.dsl.bell.ca) joined #retro 09:47:49 --- join: karswell (~coat@93-97-29-243.zone5.bethere.co.uk) joined #retro 10:07:38 --- quit: karswell (Remote host closed the connection) 10:17:53 --- join: karswell (~coat@93-97-29-243.zone5.bethere.co.uk) joined #retro 10:37:23 --- quit: karswell (Remote host closed the connection) 10:47:43 --- join: karswell (~coat@93-97-29-243.zone5.bethere.co.uk) joined #retro 11:56:50 results of the rework of the metacompiler look good; I should be able to merge in the docstrings and eliminate most of the manual setup of the initial dictionary very soon :) 12:24:14 --- join: kumul (~kumul@173.215.130.73) joined #retro 12:46:12 crc : what did you change? all i'm seeing is that one line 12:46:23 * tangentstorm is having trouble thinking through what it does... 13:04:10 --- quit: karswell (Remote host closed the connection) 13:06:07 --- join: Mat2 (~claude@91-65-144-133-dynip.superkabel.de) joined #retro 13:06:13 hello 13:13:05 heya 13:13:07 tangentstorm: that had a class of .macro, should have been a normal word 13:13:56 see the lp:~crc-x/retro-language/docstrings repo for the bigger changes (inline generation of headers, and soon docstrings merged into the kernel.rx source) 13:14:25 --- join: karswell (~coat@93-97-29-243.zone5.bethere.co.uk) joined #retro 13:15:16 aha. i merged in docstrings but was looking at the main branch. 13:16:08 crc: why do we need the "wait" opcode? 13:16:40 hi tangentstorm and crc 13:16:52 tangentstorm: a side effect of how I designed I/O originally 13:18:16 crc: I want to ask where you have found the font bitmaps of retro 10.1 ? 13:18:27 changing the i/o will break existing things though, so I can't do it yet :( 13:18:58 hmm 13:19:36 Mat2: I don't remember, sorry 13:19:53 I think the current ones are based on terminus and produced by docl IIRC 13:20:12 but the original one goes back to 2007 or so, and I no longer remember where I got it 13:20:41 thanks 13:22:06 tangentstorm: my original prototype used memory mapped i/o, but the port based implementation replaced it due to performance and portability issues early on 13:23:08 a lot of the flaws in it arose due to my much more limited experience with C and SDL at the time, and have remained in place for compatibility reasons since then 13:24:06 as I remember correctly, the wait instruction was needed because of SDL blitting for screen update and keyboard scanning 13:25:24 why? 13:27:49 SDL draw into a background bitmap, and need a special function for blitting updates from these buffer to the actual screen 13:28:29 that some kind of double buffering 13:29:18 SDL also needs most keyboard and video I/O in the main thread IIRC 13:29:18 ^is 13:29:26 yes 13:30:20 i'm looking at sdl/devices.c ... it looks like wait triggers handle_devices(), and then it calls SDL_PollEvent 13:30:32 my solution is to reserve a thread which update the screen all 50 seconds... 13:31:03 and synchronize with the vsync signal 13:32:24 wait.. i'm not asking why do we need to block when waiting for an input event. 13:32:47 i'm asking why do we need a wait opcode to do that? we could just have "in" and "out" do the blocking 13:33:51 if we were using multiple ports in parallel it would make sense to issue a number of outs and then wait... but i don't think that's even possible on some of the vms 13:34:41 yes but I think that would result in a performance desaster because the whole screen would be updated every new character 13:35:05 ?? 13:35:53 Mat2: are you talking about the video refresh thing? 13:36:19 I'm talking about the wait opcode that's used after every "out" and "in" instruction 13:37:02 ( but also: you can just blit one character to the screen in sdl ) 13:38:13 I must take a look at the sources, one moment please 13:39:10 tangentstorm: strictly speaking, I think we can remove 'wait' at this point, on most VMs 13:39:38 SDL and javascript should be the only two where issues could arise at this point 13:41:12 if we make 'wait' opcode a noop, it should work 13:41:50 what about the out to port 0? 13:42:06 --- quit: karswell (Remote host closed the connection) 13:42:06 tangentstorm: The wait instruction was needed for not polling the SDL queue every keystroke which is time consuming I guess 13:42:36 tangentstorm: that would still be an issue 13:43:03 tangentstorm: I'll do some experiments soon to see if the wait instruction can be potentially removed 13:43:04 Mat2: yeah. we need to block to read the key event. I'm just saying we can do that in the "in" opcode 13:45:28 yes but I would prefer handling this in separate threads because that are tasks which profit from parallel execution 13:45:39 but of course it would work 13:46:20 Mat2: it can be separate threads if you want. the implementation could be exactly the same, it would just be a different opcode 13:46:40 that's true 13:46:56 why do we need port 0 at all? 13:48:11 I think no 13:48:25 i can see how it makes sense if the devices push data, but we always pull 13:49:43 i think i'm going to try ignoring port 0 completely, and making wait a noop and see what happens 13:50:00 i bet everything will still work 13:52:22 --- join: karswell (~coat@93-97-29-243.zone5.bethere.co.uk) joined #retro 13:57:30 hmm, experimenting with SDL based retro this way , it works 13:58:18 but screen update is damn slow 14:00:28 --- quit: karswell (Read error: Connection reset by peer) 14:01:29 why does it change the screen speed? 14:02:52 I don't know yet 14:04:10 if you make this change, you don't have to test each port in handle_devices anymore... you only look at the device mentioned in "out" 14:05:06 it's probably slowing down because of that while loop: while (vm.ports[0] == 0 ) 14:06:05 yes that was my change to the code 14:06:08 oh 14:07:04 i'm not set up to run the sdl version 14:08:19 I have found the reason: The characters are written into vm memory, this screen is than copied into an SDL surface which at last blit into he screen bitmap 14:09:14 and his for every character 14:09:39 ouch 14:11:23 so this problem is not related with keyboard scanning 14:11:49 i think i changed this for the javascript version 14:13:19 crc: what was the reason for this ? I think you wanted some kind of memory mapped bitmap ? 14:14:04 --- quit: Z_Mass (Quit: Leaving) 14:18:55 I have an idea: Why not set up an interface alike the ti9918 VDP which has internal ram accessible though two port addresses ? 14:19:49 hrm. looks like my change amounted to replacing rxDisplayCharacter with Term.renderChar ... so i didn't really change the code, just replaced it with that terminal from escapes.js 14:20:12 Mat2: I (we?) don't know what that is :) 14:21:17 the video display processor from the good old MSX computers 14:22:02 we could reuse existing code from emulators which handle all he details like synchronisation and so on 14:22:21 just an idea 14:22:22 what do the two ports do? 14:22:43 he first write into video ram, the second read from it 14:24:28 display is tile based (another word for character based) so each read or write modify 8x8 pixel or 8x1 (depending on the screen mode) 14:25:04 that's all 14:25:30 the third port is used for selecting screen mode 14:28:25 why 8x1 ? 14:29:45 hat is the semigraphic mode which allows one colour attribute each 8x1 block 14:30:02 oh 14:30:11 sorry my key is broken 14:30:15 :) 14:33:01 the advantage of this approach is not using vm memory as bitmap so this would speed up things 14:34:27 is that happening now though? 14:35:21 "< Mat2> I have found the reason: The characters are written into vm memory," 14:35:27 oh.. where is that?? 14:37:21 ??? 14:38:01 you're talking about devices.c / drawcharacter 14:39:46 it would speed up character display if the vm could use the SDL surface directly for character generation 14:40:05 Mat2: i see what you mean now 14:40:33 the javascript canvas doesn't use vm memory, so i didn't know what you were talking about 14:40:37 Mat2: most of the sdl code was written before I had any idea what I was doing 14:41:33 the only reason it's still around is that people occasionaly ask for it 14:44:17 ok, so my suggestion for future revisions is simply to implement an minimal interface modelled after the tms9918 for accessing external vram 14:44:22 Mat2: the js version just uses an html drawing context, so that acts as the "video memory" 14:45:17 hese can be mapped 1:1 to an SDL surface 14:45:46 tangentstorm: This would mean faster screen update 14:46:14 Mat2: I'm with you now. the javascript version already works this way, just using canvas instead of sdl 14:47:19 not sure if it has a getpixel though 14:48:14 nope. but we could add that to port 6 14:53:03 what to do with port 0 ? 14:55:10 i think it can just go away 14:56:21 ok 14:59:20 Mat2: so... did removing the wait opcode make the sdl version slow, or was it slow already? 15:00:51 it was already slow 15:03:02 so... killing off wait and port 0 didn't hurt anything? 15:03:07 * tangentstorm is trying it now with python 15:04:05 I think no, possibly polling the event queue would waste some cpu ressources but as I can see this is negligible 15:04:58 well we only have to poll it when sending "out" to the keyboard or mouse port 15:05:07 hmm 15:05:26 with sdl, you get both keyboard and mouse events 15:05:29 in the same loop 15:05:45 so it really ought to be caching them when the poll runs 15:06:29 better caching into an fixed array as an internal queue ! 15:06:31 so if you ask for mouse coordinates and get a keyboard event, the keyboard event should go into a queue 15:06:38 :) 15:08:31 --- nick: tangentstorm -> tangent-afk 15:38:36 --- nick: tangent-afk -> tangentstorm 15:45:17 i think if we ever want to support hardware interrupts, then we need to keep port 0 for locking 15:45:50 otherwise, one device might try to schedule an interrupt while another device is already interrupting things 15:47:52 makes sense 15:49:35 another approach would make all interrupts exclusive with the drawback, that only one interrupt can occur a given time 15:51:23 that would depending on task or process handling with real-time characteristics 15:56:33 because it must sure interrupts can't overlap 16:03:42 I need some sleep 16:03:46 ciao 16:03:54 --- quit: Mat2 (Quit: Verlassend) 16:16:32 do'h... of course the inputs make a stack. what was i thinking making a queue in a stack machine? :) 16:20:04 --- join: karswell (~coat@93-97-29-243.zone5.bethere.co.uk) joined #retro 17:42:16 --- join: Z_Mass (~zachary@bas1-cornwall24-1242467096.dsl.bell.ca) joined #retro 19:54:42 --- quit: Z_Mass (Quit: Leaving) 23:18:24 --- quit: kumul (Quit: WeeChat 0.3.9) 23:59:59 --- log: ended retro/12.10.29