00:00:00 --- log: started forth/04.02.29 00:01:46 Dobroe utro! 00:02:27 dobryjj vecher 00:04:15 What an active converstations have happened this night! 00:04:52 :) 00:06:20 It seems you're waiting the cyclone. 00:07:07 Slava, postfix is always good in case of non-lazy calculations. 00:09:32 Lukasiewicz shew no parentheses are needed when arity of each operator is known and constant. 01:14:04 --- quit: proteusguy ("Leaving") 03:08:39 Dobryjj den'! 03:20:40 are there any scientific postfix calculators for linux? 03:21:28 --- join: MarkT (Mark@operator.nss.udel.edu) joined #forth 03:21:29 or reverse-polish if they aren't one and the same 03:23:52 fridge, man dc ; man bc 03:24:13 Good afternoon, MarkT! 03:24:25 good morning! ;) 03:24:59 ASau, dc can't do sin() or log() I don't think 03:25:31 fridge, can it define functions? 03:28:02 macros 03:29:22 Maybe, this helps: sin x = \sum_n x^{2n+1}/(2n+1)! 03:33:06 MarkT, what do you use Forth for? 03:33:35 nothing yet. I'm lurking for info.. 03:34:17 i messed with it loooong ago (read 15 years) 03:34:55 Hm. 03:35:09 but really dont remember that much about it. Now that Im into programming more my intrest has increased 03:35:37 and I have no idea what I can use it for. 03:36:37 What kinds of things have you done with it? 03:36:50 If you want use in in admistering, see nnCron and nnBackup 03:37:29 ok. 03:37:33 nnCron is "cron" derivative with more complex scripting. 03:37:51 nnBackup is backup scheduler. 03:38:16 Both go for Win. 03:38:16 a scheduler.. hmm. wonder why 'backup' 03:38:34 Recently Linux porting has started. 03:39:13 I'm assuming by scheduler you mean a job scheduler that handles possible dependencies, job failures, etc? 03:39:53 It seems that the author missed programmable backup tool. 03:39:59 So he wrote one. 03:40:05 ahh ok 03:40:16 backup scheduler.. 03:40:24 See http://nncron.ru/ for details. 03:40:51 * MarkT missed that one.. thats what I get for being awake for 43 hours 03:41:47 is forth interpreted or compiled to native code? 03:42:15 Traditionaly Forth is JIT compiled into threaded code. 03:42:22 cool 03:42:46 There're some native code compilers floating around. 03:43:10 BigForth (GPL) is n.c. compiler for Linux. 03:43:17 JIT in an editor/rt environment then? 03:44:38 My run-time env. compiles threaded code on the fly when I enter it in console. 03:44:49 --- join: qFox (C00K13S@cp12172-a.roose1.nb.home.nl) joined #forth 03:44:56 ok, thats basically what I meant 03:45:49 It is traditional. 03:46:27 Main code base on 1979 yr. sources. 03:46:37 I'm going to have to check it out when I get home from work. It's installed but I'm afraid grossly underutilized 03:46:42 Though I have some new features. 03:47:09 Most Forthers are minimalists. 03:47:31 That's a part of philosophy. 03:47:35 i see 03:47:51 It ascends C.M. "The Founder" 03:48:09 iirc traditionally it started as more of a robotics control language, correct? 03:48:47 Yes. C.M. wrote it for radio-telescope control. 03:52:34 * MarkT is looking at bigforth.sourceforge.net 03:55:44 If you use Linux, consider Gforth also. 03:56:34 It is very huge. It's not minimalistic RTE. 03:57:05 i jusn installed bigforth on WimME where I work and am looking at it. 03:58:14 Hm. 03:58:38 You may take a look at SP-Forth. 03:58:47 ok 03:59:03 for windows try winforth... 03:59:14 ok 03:59:21 http://spf.sf.net 04:00:01 Above mentioned nn* applications are based on SPF. 04:00:31 Also there're networking applications after Andrejj Cherezov. 04:00:50 acWEB, acFTP, ac-etc. 04:01:01 I don't know all of them. 04:01:07 hmm 04:02:49 damn it is big 04:03:11 Russian FIG site runs on Forth-written server. 04:04:07 i see im going to spend some time in the docs directory 04:09:46 thanks for the info. you've given me a starting place. I've gotta run. time to leave work. talk to you some more I'm sure. 04:10:57 --- quit: MarkT ("I'm outta here") 05:11:48 --- join: networm (~networm@L0632P15.dipool.highway.telekom.at) joined #forth 05:22:12 Dobryjj vecher! 05:22:28 Privet, ASau. 05:22:48 Privet! 05:23:13 How are things? 05:23:47 394 843 bytes in gzipped tar. 05:24:49 I...see. 05:26:04 I'm hacking various FDD drivers. 05:27:46 * Robert wrote one of those in Forth. I had, ehm, "some inspiration", from enth/flux. ;) 05:31:39 BTW, Robert, can you ftp anything from me? 05:32:13 ftp://158.250.48.196/ now 05:33:51 Still trying to connect... 05:33:58 Doesn't seem to be working. 05:34:32 Hm. 05:34:43 Does it connect at all? 05:36:29 No. 05:37:14 Try http now. 05:37:34 If you don't succede then try 8080 port. 05:38:12 Neither works. 05:38:37 Hm. Try 10080. 05:39:00 Maybe there is firewall somewhere. 05:40:06 Still nothing. 05:41:10 Hmm. Port 31337? 05:41:47 Nope. Still HTTP, right? 05:41:57 HTTP. 05:46:21 Hmmmm. What should that mean?.. 05:46:43 Still doesn't connect. Right? 05:47:03 Try 60080. 05:48:05 Trying..and failing. 05:48:28 What should that mean? 05:48:49 I've succeded with neighboring machine. 05:49:19 No idea. 05:49:52 Have you pings in reply? 05:49:58 Traceroute? 05:51:18 I'll check. 05:51:33 I can ping it. 05:52:13 I can't, traced up to vlan9.dr1.sto22.se.bredband.com 07:24:30 --- join: Herkamire (stjohns@h000094d30ba2.ne.client2.attbi.com) joined #forth 07:29:27 Dobryjj vecher, Herkamire! 07:29:46 ASau: mornin' :) 08:57:38 --- join: kc5tja (~kc5tja@66-91-231-74.san.rr.com) joined #forth 08:57:45 --- mode: ChanServ set +o kc5tja 08:58:50 Hi 08:58:55 Dobryjj vecher! 09:11:21 --- join: blockhead (default@dialin-203-tnt.nyc.bestweb.net) joined #forth 09:28:17 --- quit: networm (Read error: 54 (Connection reset by peer)) 09:30:49 Hello, blockhead! 09:33:06 Good morning. 09:33:35 good morning :) 09:34:00 how are you all today 09:34:17 * kc5tja really is only now starting to wake up. 09:35:05 404 934 gzipped bytes of tarred sources. 09:35:44 About 5 KB increase for today. 09:36:09 ASau: your forth? 09:36:29 My Forth involved projects. 09:37:15 mine topped 1k. It'l probably exceed 2k before I get the outer intpreter done :) 09:41:33 (that's the compiled size, not the source size, BTW) 09:54:31 --- join: networm (~networm@L0650P22.dipool.highway.telekom.at) joined #forth 09:58:34 Been thinking a bit more about ForthBox's video display system. 09:58:47 Raw bitmapped display is definitely the simplest in terms of hardware. 09:59:09 But I'm wondering of supporting a character mode wouldn't be viable too. 09:59:39 OTOH, it's also true that character mode can be effectively emulated in software if need be, using SDL-like techniques of a "software managed" frame buffer. 09:59:51 kc5tja: would make it easier for the programmer who didn't want to deal with graphics 09:59:57 kc5tja, character mode is not an issue. 10:00:09 Remember ZX "Spectrum". 10:00:34 blockhead: Not necessarily. Like I said, you can have software-emulated character "displays" that you draw into, then call a function to render the "screen". 10:00:54 ok 10:01:05 ASau: I'm sorry, but what exactly does that have to do with my set of issues? 10:01:27 I mean this mode is not needed at all. 10:01:47 Moreover, I don't remember the ZX Spectrum, but I have reviewed the Jupiter Ace schematics, and its video generation circuitry, while not overtly super complicated, definitely *WAS* more complicated than a simple bitmapped system. 10:01:49 ZX' example shows it pretty well. 10:02:19 ASau: I think a better example would be the Amiga. :) 10:02:41 I don't know Amiga. I had no one. 10:02:59 ASau: It was entirely a bitmapped display system? It never, ever, ever used a tile-based character display system? 10:03:09 I find that *very* hard to believe. 10:04:03 true. the amiga did not have character-mode displays until wb 2.0 10:04:15 blockhead: Sorry, but it never has had any character display modes. 10:04:25 The hardware is pure, 100% bitmapped graphics, through and through. 10:04:30 When you write a byte to video-mapped memory (ZX) you get several points. 10:04:47 When you write 8 bytes, you get a character. 10:05:03 8x8 picture. 10:05:04 kc5tja: they added them with wb 2.0. 10:05:23 * blockhead wishes he still had the RKM :/ 10:05:41 blockhead: No, not quite. :) They modified console.device to maintain a simulated character map. I'm talking about the hardware though. 10:05:43 then I could look up the relavent passage 10:06:04 kc5tja: umm, that makes sense. ok. :) 10:06:09 No char. gen. Software only. 10:06:18 * kc5tja nods -- I know what you're referring to, but it's not what I was directly talking about. However, that "fake character display" technique is precisely what I was thinking about though. 10:06:22 Gah! 10:06:25 I'm not making any sense. 10:06:37 * kc5tja nods -- I know what you're referring to, but it's not what I was directly talking about. However, that "fake character display" technique is precisely what I was thinking about when I said that a character mode display can be simulated. 10:06:58 ASau: Interesting. I didn't know this. I'll have to do some research. 10:07:11 kc5tja, it's very simple. 10:07:14 makes snese to me. fake character genration would be a software solution ... like the 2.0 console.device 10:07:16 Must have been pretty slow for text stuff, but pretty cheap to implement. Probably really brought the price of the computer down. 10:07:36 text was slow, especially before 2.0 :D 10:07:39 kc5tja, the display is 256x192 points. 10:07:42 blockhead: Yup. And with a 6MHz clock speed, it might actually be fast enough, especially if you can give it hints on where to update the screen. 10:07:52 blockhead: Well, again, a different issue. 10:07:55 there were third party font acceleartor drivers :D 10:08:05 BTW, I have a Amiga 500 with Kickstart 2.04 on it, and the text speed in 2.0 is actually *slower* than in 1.3. 10:08:12 * blockhead misses his amiga :( 10:08:21 kc5tja, successive writes fill raws. 10:08:26 But not by much. The reason is 2.0 does a lot more processing in the background. 10:08:58 kc5tja, when you write A, A+256, A+512 etc (8 times) you get character. 10:09:00 ASau: Yep. That's what I was thinking for my ForthBox idea, originally. Also, using 5-pixel wide characters would be easy, since all pixels are 8-bits wide. 10:09:00 kc5tja: that's very odd, becasue I had a speed *increase* going to 2.0 on my 500. (blockhead scrathces his head in puzzlment) 10:09:46 kc5tja, so you get 32x24 chars. display. 10:10:07 ASau: Right. Though, the ZX requires 8 writes, while my system requires 64 (assuming an 8x8 character). 10:10:09 32x24 - just like my old zx81 :D 10:10:28 (or was that 40x24 ... hmmm?) 10:10:30 * blockhead neverminds 10:11:25 kc5tja, that depends on color depth. If you decide to color each point. 10:12:09 kc5tja, ZX made the same color for 8x8 squares. 10:18:10 Well, like I said, my display is truely bitmapped, with 256 colors, so each point has its own color. 10:18:59 kc5tja: you've built this already? or still in the thinknign/planning stage? 10:19:08 eitehr way, it sounds interesting 10:19:26 kc5tja, that sounds good. 10:20:03 kc5tja. What width do you plan to use? 10:28:27 blockhead: Still thinking about it. 10:29:06 ASau: I was originally going to use 640x480, but I'm thinking of going with a selectable 320x240 or 320x480 instead. 10:29:19 neat. hope it goes well. is this a commercial project or a hobby/educational thing for yourself? 10:29:40 kc5tja, 8 bits for colours? 10:31:04 Yes. 10:31:09 Fixed color palette. 10:31:18 kc5tja, better make 512 pts. width. 10:32:26 Or a little more. 10:35:19 If you stay with 8 bit bytes, than 512 pts. is requirement. 10:37:08 I'm not convinced of this. 10:37:18 And it is true that I *do* prefer 512 horizontal pixels. 10:37:18 Otherwise it would not be as good as should be with 512 pts. width. 10:37:29 But if I'm going that far, I may as well go with 640. 10:38:01 The idea is to make a system that doesn't take 3 seconds to clear the screen. :) 10:38:13 While using as little hardware as possible. 10:39:16 kc5tja, there was a trick on slow Z80. 10:39:47 To clear screen fast you should set SP a push zeroes. 10:40:54 ...and push zeroes. 10:41:23 I don't see why 640. 10:41:28 512 is better. 10:42:10 that could be dictated by available hardware 10:42:34 MrReach, can't you see why 512? 10:42:56 yes, fits evenly in 9 bits 10:43:03 No. 10:43:24 What is the reason then? 10:43:24 Because, Forth screen is 64 characters per line. 10:43:37 That was anti-climactic. 10:43:52 512 = 64 x 8. 10:43:53 oh, heh, forgot all about that ... haven't used screens in years 10:44:22 * kc5tja can get 64 characters on a 320 pixel display too, using 5 pixel wide characters. 10:44:32 (which byte-addressible pixles make trivial.) 10:44:36 pixels even 10:44:55 5 pixel wide characters might be a bit hard on the eyes? 10:45:06 blockhead: At 320 pixel horizontal resolution? 10:45:08 kc5tja, that will make software more complex. 10:45:14 ASau: No. 10:45:25 keep in mind that one pixel is eaten up by the between-character spacing 10:45:37 ASau: It'd make it faster, frankly. A character is reduced from 64 writes to only 40 writes. 10:45:40 that depends on the font 10:45:43 blockhead: Yes. 10:45:47 blockhead: I'm well aware of that. 10:45:51 some chars have more 10:46:00 might want to draw up some letters and see how it looks 10:46:16 heh, dump the C64 ROMs? 10:46:21 blockhead: TRS-80 uses 5x7 character fonts. 10:46:27 kc5tja, so you plan 1 byte is point colour, don't you? 10:46:39 ASau: I believe I've already said that three times already, yes. 10:46:44 " blockhead: I'm well aware of that." <--- ok, sorry! 10:46:59 in any case, you'll always want as much resolution as you can possibly afford 10:47:03 kc5tja. Sorry, I've not found it out. 10:47:31 and "afford" applies to both hardware cost and processing time 10:47:47 the trs80 dispaly looked decent ... so 5 pixels won't be a problem after all. 10:48:04 blockhead: Remember, I'm not using 5 pixel wide fonts on, say, a 1600 pixel line. :) 10:48:10 That is just . . . wrong. 10:48:11 :) 10:48:27 can you say "squint"? 10:48:31 If I did go with a 512 pixel line, it'd be because of the 9-bit offset to compute a Y coordinate. 10:48:41 true. and if you use a tv as a minotr, the natual blurring may function as a sort of anti-aliasing 10:48:42 Hi MrReach. 10:48:50 greetings, Robert 10:49:07 kc5tja: Yeah, but I'm going to use VGA instead. The circuitry to interface it is much easier, especially if you want to do color. 10:49:28 there's lots of VGA hardware out there 10:49:50 * blockhead marvels at his own typos 10:49:58 * kc5tja has considered using 256 pixel lines too, but . . . I don't know. That seems to be a little *too* small for me. 10:50:01 did you intend to use a tube-type display or LCD/plasma? 10:50:30 MrReach: Both; that's why I'm restricting myself to the true-blue IBM VGA timings (which is the 640x480 display mode that we've all come to love). 10:50:43 * MrReach nods 10:50:58 what type of processor/mem? 10:51:27 MrReach: 65816 @ 6.25MHz (dictated by VGA timings, to keep things simple), probably around 512KB of RAM. 10:52:35 input devices??? 10:53:38 PS/2 keyboard & mouse (though relatively rarely used). 10:53:57 tethered, mostly? 10:54:04 Tethered? 10:54:26 as oppused to cordless? 10:54:31 many smaller systems are expected to have an "umbilical" to a host machine for programming 10:54:53 oh! 10:54:58 oh, yeah. It's cheaper/simpler. 10:55:27 but that really depends on how it's to be used ... would be senseless for a PDA 10:55:44 but if it's operating a CNC machine, it's the logical choice 10:56:29 ForthBox is intended to serve as a quieter, lower power alternative to my desktop PC. 10:56:50 ack! 10:56:56 Especially for accessing the Internet (primarily e-mail and IRC). 10:57:04 I couldn't live without printing 10:57:05 kc5tja: kewel!! 10:57:36 then it's *ALL* about display resolution 10:57:38 Umm...my computer will have a parallel port too.... 10:58:20 good luck with the printer drivers, though 10:58:32 many don't understand raw text anymore 10:58:59 That's what open source software is for. 10:59:00 :) 10:59:32 Besides, this PC isn't about eschewing the x86 completely. 10:59:50 It's about relying on it *less*, primarily to reduce my power consumption, and administrative hassles. 11:00:24 yeah, things are getting rather outrageous for those who only word process and IRC 11:00:29 Obviously, the more things I do with the ForthBox, the better. No fans, no moving parts (storage will probably be compact flash or IDE harddrive), etc. 11:00:53 I was wondering about the flass option 11:01:25 it's pretty cheap now, easy to use, and rather faster than your processor 11:14:07 What is pretty cheap and faster than my CPU? 11:14:19 flash memory 11:14:38 OK, I was wondering if I missed something I should have read. :) 11:14:48 Glad to see I'm on the same page still. :) 11:15:51 --- join: usa (~usa@adsl-64-142-9-188.sonic.net) joined #forth 11:16:11 Good evening, usa! 11:16:27 take care folks, i'm off 11:16:30 --- part: MrReach left #forth 11:16:38 Actually it is still morning here on the west coast of the us. 11:17:06 No matter. 11:17:09 I'm not there. 11:17:56 I went to my first SVFIG meeting (Silly cone valley Forth interest group) yesterday. 11:18:10 hehe: it's hard to remember who is in what time zone. I'm tempted to say "good morning" whenever someone enters the cahnnela dn "goodnight" when I leave, regardless of the actual time here :D 11:19:35 I have been meaning to go for some time, but what prompted me was a talk about bootstrapping a Forth system in C, and the problems it had. In particular how to deal with create ... does> 11:20:16 blockhead: I guess this is why Swatch decided to start @-time. 11:20:26 * blockhead nods "create" & "does" has me flummoxed 11:20:35 @-time? like GMT? 11:22:03 it never occuured to me to look for a forth interest group in my area. Hmmm. Thanks usa for the idea! 11:22:41 What area is that? 11:22:58 new york. probably one around here 11:24:07 Create and does> are probably one of the most useful things in forth. Of course they are also one of the most difficult bits to implement. 11:24:14 although this channel has been very helpful 11:24:30 hey guys 11:24:39 Dobryjj vecher! 11:24:51 usa: I here you! create and does completely confuse me! 11:25:32 In what way do they confuse you (and no, I am not an 'Eliza' program)? 11:25:43 implementing them 11:26:06 * blockhead is in the middle of writing a forth :D 11:26:29 I don't really see what is complex in DOES> 11:28:22 Implementing them was a major chuck of the talk yesterday. It was for a subroutine coded forth, written with a 'C' bootstrap stage. Essentially the C opened up a file, memory mapped it, and then started interpreting it. The amount that the C could do was fairly small, although it obviously had things like 'get next token' (in two different forms, one to handle whitespace delimited, and one for a particular delimiter (e.g. ") 11:28:55 ASau: have you written an forth system? 11:29:26 I have a good example of implementation. 11:31:20 And of course it is not C. 11:31:50 Though I don't understand how C implementation could make things more complex to understand. 11:32:09 With respect, that is not answering the question! Implementing the code associated with does> is probably the most tricky thing in a forth system. 11:32:40 Hmm. 11:32:46 What do you mean? 11:32:50 and the inner interpreter is like the easiest thing to implement - surprisingly 11:33:03 i need to by Thinking Forth 11:33:05 buy 11:33:07 Using does> is pretty easy, it is implementing it where the details get you. 11:33:11 Substituting call point in constructed words? 11:33:36 Nothing on amazon :/ 11:33:41 Or compiling code referenced by DODOES? 11:39:08 Maybe I've found what confuses you in DOES> implementation. 11:39:43 You should learn assembly-written Forth implementation. 11:41:02 OK. 11:42:04 Though... 11:42:23 it can be described in Forth itself. 11:42:23 What do you think is more tricky than does> ? 11:43:01 Terminal input. 11:43:34 It is more complex. 11:43:51 It involved input line editing. 11:44:34 ...involves... 11:46:11 DOES> is only unusual. It's not as complex. 11:47:24 Not always. For a hosted forth it can just be one call to the OS/library. From memory gforth is linked against libreadline. For a native forth I typically provide nothing more than 'delete last character', biund to both the Delete and Backspace keys. Of course I have the advantage of having a nice terminal program which enables me to edit things befor I send them. 11:47:44 ^biund^bound 11:49:05 I don't consider any external subroutines. 11:53:16 --- part: usa left #forth 12:02:45 what took me quite long in my implementation of dodoes was, how to get the address of the code after does from dodoes.. 12:03:18 Save it in a word. 12:03:39 but in which? 12:04:10 the code after dodoes itself is in the defining word 12:04:28 Let us consider : DEFINES run ; 12:04:34 DEFINES W 12:04:56 You should save in W pointer to run 12:05:54 yep. 12:06:07 just needed some time to understand that.. 12:06:13 i was looking at something like 12:06:25 : DEFINES CREATE DOES> run ; 12:06:35 See how it works. 12:06:46 and then read in the standard that CREATE isn't supposed to allocate any cells 12:07:04 but to save something, I'd have had to allocate a cell 12:07:35 networm, it has to allocate at the least some space in dictionary. 12:07:56 Let's see how it works. 12:08:05 DEFINES is called. 12:08:26 CREATE creates a word and reserves a space for code. 12:08:46 Otherwise your new word can not be called ever. 12:08:56 which I put the XT of DODOES in 12:09:08 DOES> makes changes in this reserved space. 12:09:36 networm, not only for DODOES, but for associated pointer also. 12:10:02 Or you have to make somewhere a custom DODOES 12:10:17 particulary for DEFINES 12:11:52 Noone makes you use constant amount of space for code field. 12:11:53 yes, makes sense. but in Moving Forth (I think) there was a solution which didn't need that extra cell 12:12:31 but I think I understand now how it works.. I just was confused by it at first. spent like half a day on implementing does> :) 12:12:34 --- join: imaginator (~George@georgeps.dsl.xmission.com) joined #forth 12:12:54 hi imaginator 12:12:56 Dobryjj vecher! 12:12:57 how goes the C-forth? 12:14:00 Ah, yes.. the chapter called "Demystifying DOES>".. and actually mystified it for me :) 12:14:01 networm, you really can compile custom DODOES when DOES> is executed. 12:14:43 it uses some trick where putting a CALL into the code field allows getting the address of code after DOES> out of the CPU's stack 12:16:55 Hmmm. 12:17:01 At run time? 12:18:21 yes 12:18:42 W is executed, and has a call of the code stored in DEFINES 12:19:16 or no 12:20:13 hi slava 12:20:15 W -> DEFINES -> DODOES 12:20:22 i think it calls like that 12:20:36 and DODOES gets the XT of DEFINES out of the CPU stack 12:20:47 and therefore needs no cell where to store it 12:21:20 When DODOES is executed everything it has are: return address and current interpreting address. 12:22:48 I.e. old IP and current IP. 12:23:06 so if postfix code can be represented as a directed graph, how are conditionals represented? 12:23:08 Stacks are for run time data. 12:24:31 ah, found it 12:24:33 http://www.zetetics.com/bj/papers/mov3-11.gif 12:24:42 DEUX is W, CONSTANT is DEFINES 12:25:08 so DODOES finds the address of DEFINES from the CPU stack 12:25:13 that makes sense to you? 12:25:14 :) 12:25:19 since that'S where it actually got called from 12:25:27 well, it didn't :P 12:25:50 but the title "Demystifying Forth" promised to make me understand it :) 12:25:51 good, was questioning my santity there for a second :p 12:26:00 s/Forth/DOES>/ 12:26:52 networm. That's what I called "custom DODOES". It contains DODOES code in DEFINES after DOES> 12:28:01 yes. i guess the JSR DODOES also needs more than one cell 12:28:35 I was speaking about this ITC DOES> : (DOCOL) () (run) (;) 12:28:56 and (DODOES) ('run) (body) 12:29:07 later for W 12:29:21 first was for DEFINES 12:30:31 Parentheses separate tokens. 12:31:16 yeah. so in that case, DODOES has no way to find DEFINES 12:31:32 unless it stores it somewhere inside W 12:32:44 You stored pointer to DEFINES as pointer to "JSR DODOES" that's contained in this DEFINES . 12:33:04 You've... 12:36:33 ah, true. 12:37:02 and the ('run) isn't needed since it is found out somehow inside DEFINES 12:40:05 It is IP value when JSR is executed. 12:41:07 ' W @ @ next-insttruction 12:42:09