00:00:00 --- log: started retro/10.01.25 02:13:47 --- join: foucist (n=foucist@69.93.127.31) joined #retro 02:13:48 --- mode: ChanServ set +v foucist 03:13:27 --- join: crc2 (n=charlesc@c-68-80-139-0.hsd1.pa.comcast.net) joined #retro 03:14:14 --- nick: crc2 -> crc 03:40:40 --- quit: foucist ("leaving") 04:04:39 --- join: crcx (i=d8012b82@gateway/web/freenode/x-mcheqlmqxhghsran) joined #retro 05:32:28 --- join: Mat2 (i=5b42fd0f@gateway/web/freenode/x-bfniuolszplferqe) joined #retro 05:32:38 hello 05:36:17 --- quit: Mat2 (Client Quit) 06:06:16 --- join: foucist (n=foucist@69.93.127.31) joined #retro 06:06:16 --- mode: ChanServ set +v foucist 07:27:08 --- quit: foucist ("laters") 09:19:28 --- quit: crcx ("Page closed") 09:21:41 --- join: crcx (i=d8012b82@gateway/web/freenode/x-rhorteyfxqhkumcn) joined #retro 10:06:48 --- join: foucist (n=foucist@69.93.127.31) joined #retro 10:06:48 --- mode: ChanServ set +v foucist 10:25:40 --- quit: virl (kubrick.freenode.net irc.freenode.net) 10:25:41 --- quit: yiyus (kubrick.freenode.net irc.freenode.net) 10:32:49 --- join: virl (n=virl__@chello062178085149.1.12.vie.surfer.at) joined #retro 10:32:49 --- join: yiyus (i=12427124@je.je.je) joined #retro 10:43:26 --- quit: foucist ("leaving") 12:55:04 --- join: foucist (n=foucist@69.93.127.31) joined #retro 12:55:04 --- mode: ChanServ set +v foucist 13:53:54 --- quit: crcx ("Page closed") 15:24:19 --- join: erider (n=chatzill@pool-173-69-160-231.bltmmd.fios.verizon.net) joined #retro 15:25:18 hi 16:19:13 hi erider 16:29:34 --- quit: SimonRC (Remote closed the connection) 16:30:46 whats up crc 16:31:02 I have been thinking about you instruction set 16:31:07 not much 16:31:47 it is good to have functions that you can call 16:31:55 my instruction set has seen only tiny changes since 2006 when I first started experimenting with MISC architecture 16:32:29 (in fact, only in/out/wait were added; the rest is identical, including encodings, to the original prototype) 16:32:39 without some of the system functions in nix and windows they wouldn't nothing 16:33:49 I guess you can do a lot with a little :) 16:34:14 your forth background helps you with that 16:34:24 true 16:34:47 * crc had once started writing a C compiler that generated ngaro images, but never finished it 16:34:59 and the first language that ran on ngaro was a brainf*** interpreter 16:35:30 cool 16:36:53 tracing programs in a debugger I have noticed that a lot is going on behind the scenes 16:43:31 crc: so can you talk little about the I/O 16:51:31 --- quit: foucist ("gtg") 17:04:47 --- join: SimonRC (n=sc@fof.durge.org) joined #retro 17:17:03 I/O in Ngaro is mapped to various I/O ports. There are 1,024 ports, but only 8 are currently used. 17:17:31 when you want to trigger an I/O event, you write values to the ports for the hardware you are interested in, and execute the 'wait' instruction 17:18:00 the emulated CPU then pauses until the I/O event is over 17:18:13 you can then read values back from the ports, or directly off the stack in some cases 17:19:30 my original design had all I/O devices mapped to various pieces of directly addressable memory. this proved problematic in practice, so the memory region was recrafted as a collection of I/O ports and the current model evolved. 17:30:36 mov bx, [FFE2] 17:30:38 and bx, 1 17:30:39 cmp bx, 0 17:30:40 je 0000 17:30:42 mov [FFE0], ax 17:31:29 Assume that the printer data port is memory-mapped to address 0FFE0h and the printer status port is bit zero of memory-mapped port 0FFE2h. The following code waits until the printer is ready to accept a byte of data and then it writes the byte in the L.O. byte of ax to the printer port 17:32:39 crc so you are dealing with hardware devices 17:32:48 erider: simulated hardware devices 17:33:02 keyboard, mouse etc.. 17:33:07 yes 17:33:36 the vm is simulating the functionality of those devices 17:33:54 yes 17:34:05 interesting 17:34:14 that how to be a pain 17:34:33 not really 17:34:51 it lets me abstract the underlying api's of the host OS from the forth side of things 17:34:56 because you would need some thin layer to communicate with the real thing 17:35:09 ie getting the mouse position 17:35:55 I have code for that in the sdl and javascript implementations 17:36:21 neat 17:36:25 both abstract to a simple mouse device that can be accessed from forth without knowing the underlying details that are platform specific 17:36:34 it works quite nicely so far 17:36:59 what are the words to use I/O in retro 17:37:11 in, out, and wait :) 17:38:14 : emit ( c- ) 1 2 out wait ; 17:38:22 : key ( -c ) 1 1 out wait 1 in ; 17:38:24 (basically) 17:38:45 : save ( - ) 1 4 out wait ; 17:38:47 and so on 17:39:41 ah you call them directly cool 18:02:00 most words can be called directly 18:03:00 no I thought that those instructions where apart of your vm 18:03:08 they are 18:03:30 I expose all instructions as words 18:03:38 except for jump 18:03:48 jump isn't directly exposed ;) 18:04:51 ah cool 18:23:30 brb, I need to reboot :( 18:23:44 --- part: crc left #retro 18:35:18 --- join: crc2 (n=charlesc@71.23.210.149) joined #retro 18:39:42 --- join: crc2_ (n=charlesc@71.23.210.149) joined #retro 18:40:17 back 18:40:21 --- mode: ChanServ set +o crc2_ 18:40:26 --- nick: crc2_ -> crc 18:40:45 --- quit: erider (Read error: 113 (No route to host)) 18:46:40 I found and fixed another bug in 'see' 18:47:38 specifically, LIT -1 was being treated as a termination of the word, causing decompilation to stop when encountered 18:57:20 --- quit: crc2 (Read error: 110 (Connection timed out)) 19:35:56 --- join: crc2 (n=charlesc@71.23.210.149) joined #retro 19:53:52 --- quit: crc (Read error: 113 (No route to host)) 19:54:40 --- mode: ChanServ set +o crc2 19:54:44 --- nick: crc2 -> crc 20:00:25 --- join: crc2 (n=charlesc@71.23.210.149) joined #retro 20:21:02 --- quit: crc (Read error: 110 (Connection timed out)) 20:21:24 --- mode: ChanServ set +o crc2 20:21:27 --- nick: crc2 -> crc 23:59:59 --- log: ended retro/10.01.25