00:00:00 --- log: started forth/00.12.03
01:14:23 * aaronl is away: division bell
03:06:56 --- quit: Fare (Ping timeout for Fare[ppp28-net1-idf2-bas1.isdnet.net])
05:19:04 --- join: Fare (fare@ppp83-net1-idf2-bas1.isdnet.net) joined #forth
08:26:28 --- join: P1nK_SP1d3R (www.jpopce@APastourelles-101-1-2-122.abo.wanadoo.fr) joined #forth
08:45:22 <P1nK_SP1d3R> where can i found good article on forth for beginner ?
09:54:37 --- quit: P1nK_SP1d3R ([x]chat)
09:56:58 <I440r> whois that guy :P
09:56:58 --- mode: I440r set mode: +o Fare
10:08:10 --- join: MrReach (mrreach@209.181.43.190) joined #forth
10:09:16 <MrReach> bored, I4?
10:46:21 <MrReach> hello?
10:58:04 <I440r> hi
10:58:07 --- mode: I440r set mode: +o MrReach
10:58:34 <I440r> im trying to add breakpoints to my simulator. trying to figure the best way to implement them
10:58:45 <I440r> i want to be able to break on read or write of memory too
11:01:29 <MrReach> in what way overcomplicated?
11:01:54 <MrReach> which simulator are you working on?
11:02:52 <MrReach> is that the rather bizarre embedded controller you described some months ago?
11:03:51 <I440r> oop is a natural way to obfuscate in my opinion
11:03:55 <I440r> and its an 8051 simulator
11:04:09 <MrReach> oh, ok
11:04:10 <I440r> wrote the disassembler myself and the execution engine
11:04:19 <I440r> i can already single step or "go till here"
11:04:21 <MrReach> is the simulation entirely in software?
11:04:26 <I440r> now i want to add breakpoints
11:04:27 <I440r> yes
11:04:43 <MrReach> that's actually quite easy ...
11:04:52 <I440r> want to be able to "break on execution" or "break or read or write"
11:04:57 <I440r> oh yea i know
11:05:08 <I440r> its just finding the rite way to do it
11:05:11 <MrReach> I presume that your simulator has a storage area that reflects the program counter?
11:05:27 <I440r> for read or write ill just have each instruction store the address read or written to 
11:05:48 <MrReach> each time the PC changes, have it run through a list of breakpoints and call an outside function on a match
11:05:54 <I440r> yea i know
11:05:57 <I440r> thats what im doing
11:05:58 <I440r> but
11:06:07 <I440r> do i break before or after execution
11:06:10 <MrReach> before
11:06:14 <I440r> exactly
11:06:25 <I440r> but what if im only SINGLE stepping
11:06:26 <MrReach> so you can watch the execution of the instruction in question
11:06:30 <I440r> i shouldnt NOT step
11:06:51 <I440r> there is a difference between GO and STEP
11:07:04 <I440r> plus
11:07:14 <I440r> i want to be able to break on read or write 
11:07:21 <I440r> which i can only do AFTER
11:07:29 <I440r> i cant break before a read or write
11:07:33 <MrReach> SS probably shouldn't use the same func to increment the PC
11:07:35 <I440r> not easilly
11:07:40 <MrReach> so it becomes a non-issue
11:07:51 <I440r> it does use the same function hehe
11:07:59 <I440r> but it calls it from a different location
11:08:10 <I440r> i have two modees of run
11:08:17 <MrReach> yes, have it call a different, similar function, or ...
11:08:24 <I440r> one just fakes single stepping so you can watch each instruciton execute
11:08:33 <MrReach> have the function itself check whether system is in SS mode
11:08:35 <I440r> the other one just goes and stops where it was told to stop
11:08:53 <MrReach> yes, GO is different
11:08:54 <I440r> this is already all figured out
11:09:13 <I440r> the problem is because i cant break on write or break on read untill after the read or write has already completed
11:09:26 <MrReach> the objective, of course, is to use as many of the functions in BOTH go mode and SS mode as possible
11:09:47 <MrReach> that is solvable, also
11:09:53 <I440r> my GO mode is like an addition of 6 or 7 lines of code
11:10:17 <I440r> not easilly
11:10:30 <MrReach> I presume there is a function that emulates each machine code instruction. Is this true?
11:10:32 <I440r> yes
11:11:16 <MrReach> ok, on those functions that read or set memory, have them check for a memory break point just BEFORE they atually do the read or write
11:11:41 <I440r> yes i know.
11:11:53 <I440r> BUT
11:11:54 <MrReach> that can, of course, be factored into "check_read" and "check_write" functions
11:12:11 <I440r> they would then have to be TOLD to ignore the breakpoint if we are in single step mode
11:12:11 <MrReach> those two can then scan the list of specific memory watches
11:12:25 <I440r> yup
11:12:35 <I440r> its not difficult
11:12:45 <I440r> i just like to chew on a problem before coding it hehe
11:13:07 <MrReach> factor the checks for SS into the "check_read" "check_write" and "inc_PC" functions
11:13:11 <I440r> the hard part will be simulatiing interrupts and serial coms
11:13:13 <MrReach> or whatever you called them
11:13:16 <I440r> and read and write of ports
11:14:13 <I440r> im going to use a fossil for the coms
11:14:17 <MrReach> why would that be difficult? what platform is the simulator on?
11:14:23 <I440r> x86 :)
11:14:29 <MrReach> that sounds like DOS then
11:14:34 <I440r> not difficult just more difficult
11:14:49 <I440r> ill have to take careful not of the SFR configurations
11:14:53 <I440r> it is
11:15:13 <I440r> written in 100% pure asm using registered copy of a86 :)
11:15:16 <MrReach> ok, then, have aq botton or hotkey that instructs the simulator to process a simulated interrupt NOW
11:15:31 <I440r> oh no thats not the problem
11:15:34 <I440r> the problem is
11:15:43 <I440r> when im single stepping or running
11:15:51 <MrReach> when the simulator goes to do a port read ... manually change the info returned
11:16:01 <I440r> i have to notify the user in some way that an interrupt is being serviced
11:16:13 <I440r> ok.
11:16:22 <I440r> the 8051 has a number of ports
11:16:31 <I440r> ill only be able to map ONE of those to the paralell port
11:16:32 <MrReach> well, in SS, there will be no actuall interrupts
11:16:48 <I440r> the serial coms will all be done over the pc's serial line
11:16:50 <MrReach> only simulated interrupts
11:16:54 <I440r> there will be
11:17:07 <MrReach> oh, is there an umbilical then?
11:17:31 <MrReach> you didn't say that ... I thought it was entirely software simulation on a different platform
11:17:35 <I440r> any write to the simulated 8051 sbuf (serial buffer) will actually go out on the pc's serial line
11:17:48 <I440r> anyitnbg coming in will be put in sbuf for later read
11:17:54 <I440r> and an irq will be generated for each
11:18:04 <MrReach> hmmm ...
11:18:14 <I440r> on completion of the next instruction the 8051 will SERVICE that interrupt
11:18:25 <I440r> we also ahve a number of user definable external interrup sources
11:18:32 <I440r> illb e simulating these too
11:18:36 <MrReach> ok, then you will have to buffer all incoming data
11:18:43 <I440r> of corse
11:18:48 <MrReach> so that it can be watched
11:18:49 <I440r> then we have timer interrupts
11:18:56 <I440r> and watchdog timer
11:19:10 <I440r> so imagine i press f1 and single step an instruciotn
11:19:16 <I440r> 2 hours later i press f1 again
11:19:40 <MrReach> have a "INT" flag on the screen that changes color/attribute while the simulator is processing an interrupt, so the user can GO to its end
11:19:49 <I440r> my simulator should take the exactr instruction cycles of each instruction to calculate how much sim time has passed
11:20:02 <I440r> ill display which interrups are requested yes
11:20:24 <MrReach> ok, pretend user is SS in app code
11:20:40 <MrReach> a character arrives on the serial port ...
11:21:09 <MrReach> suddenly, the PC jumps to some wierd address, and the INT indicator lights up
11:21:34 <MrReach> the user will usually turn off interupt watches and press GO
11:21:54 <MrReach> unless user is working specifically with the interrupt handler
11:21:54 <I440r> ok the way ill indicate that we are servicing an interrupt is that my cursor will change from blue to red
11:22:05 <MrReach> ok, that works good
11:22:23 <I440r> but the user will not be able to say "ignore interrupt requests"
11:22:43 <I440r> if he is single stepping he will be FORCED to service the interrupt
11:22:47 <I440r> he can of corse say...
11:22:48 <MrReach> not "ignore", just simply "don't watch, I'm not interested now"
11:22:53 <I440r> for a given interrupt
11:23:05 <I440r> run the service routine at full speed
11:23:11 * MrReach nods
11:23:13 <I440r> so i dont actually see it happen
11:23:34 <MrReach> yep, interrupts are debugged, so don't show me anything about them
11:23:44 <I440r> rite
11:24:03 <I440r> the interrupt will still be serviced but you wont notice that :)
11:24:11 <I440r> timer interrupts are the big problem hehe
11:24:21 <MrReach> hmmm ... the interrupt could trigger a memory read/write event that the debugger would display
11:24:28 <I440r> i will have to look at the interval that the timner has been set to
11:24:38 <I440r> and calculate houw many instruction cycles that is
11:24:48 <I440r> and after single stepping or running that many cycles
11:24:51 <I440r> i service the interrupt
11:24:58 <MrReach> simulate the interrupt
11:25:14 <I440r> so i will only be able to simulate timer intervals that are a multiple of the instruction cycle time
11:25:24 <MrReach> actually, that looks pretty easy at first glance
11:25:25 <I440r> because SIM time wont be real time
11:25:40 <I440r> so far everything has proved to be VERY easy heh
11:25:50 <MrReach> because the function that increments the PC can also count time
11:25:58 <I440r> the disassembler part is a little over 1k of object code
11:26:01 <MrReach> and compare to timer
11:26:13 <I440r> and that includes all the ascii
11:26:20 <I440r> yes i know
11:26:30 <I440r> each instruction will know how much time it takes
11:26:35 <I440r> and will add taht to "current time"
11:26:44 * MrReach nods
11:27:06 <MrReach> "TIMER Interrupt Serviced"
11:27:18 <I440r> but is "1 instruction cycle" a fine enough resolution for the timer interrupts
11:27:37 <I440r> actually 
11:27:40 <I440r> now that i think about it 
11:27:42 <I440r> YES it is
11:27:43 <I440r> because
11:27:54 <MrReach> it depends how the 8051 implements the timers
11:27:57 <I440r> on an 8051 one instruciton is guaranteed to execute after an interrupt
11:28:05 <I440r> even if there is another interrupt pending
11:28:22 <MrReach> the interrupt itself will consume time, also
11:28:24 <I440r> so if i set my timer to interrupt 10 times per instruciton cycle
11:28:33 <I440r> ill still only get one service per instruciotn
11:29:15 <MrReach> yes, the "current instruction" finishes
11:29:24 <I440r> no this is what i mea
11:29:31 <I440r> we are executing an instruciton
11:29:39 <I440r> hjalf way thru an irq occurs
11:29:43 <MrReach> however, most processors will interrupt immediately after a "RETI" instruction
11:29:50 <I440r> at the end of that instruction the isr kicks in
11:30:00 <I440r> during that isr another irq occurs
11:30:07 <I440r> when we exit the isr
11:30:08 * MrReach follows
11:30:20 <I440r> we are GUARANTEED to execute ONE instruction before servicing that irq
11:31:03 <MrReach> ok, I would say that characteristic is rather unique to the 8051 then
11:31:04 <I440r> we can implement single stepping this way
11:31:39 <I440r> set a timer interrupt to faster than one instruciton time
11:31:44 <I440r> exit the irq
11:31:55 <I440r> we single step 1 instrucion and then the timer int is serviced
11:32:05 <I440r> that can then send debug info over the serial line to the user
11:32:15 <I440r> and exit the isr and execute one isntruction
11:32:19 <I440r> etc etc etc
11:32:30 <MrReach> ack!!!! are you emulating in software or hardware??
11:32:32 <I440r> the isr can wait for a key from the user
11:32:34 <I440r> no
11:32:35 <I440r> im not
11:32:45 <I440r> but with the 8051 you CAN
11:32:59 <I440r> thats not how im doing it hehe im simulating everything in software
11:33:04 <I440r> brb coffeeefeffffeffffeee
11:33:05 <I440r> hrm
11:33:13 <I440r> not ennuff e's or f's
11:33:39 <MrReach> ok, when you return, please describe your development platform in more detail
11:35:19 <I440r> i can do better than that
11:35:22 <I440r> i can send u the source :)
11:35:23 <I440r> hehe
11:35:34 <I440r> brb its on my laptop :)
11:36:06 <aaronl> gah
11:36:10 <aaronl> work in isforth instead
11:36:13 <MrReach> gah?
11:36:29 * MrReach grins, "Agreed"
11:36:57 <MrReach> or FPC or Win32Forth or GForth
11:37:08 <I440r> ok hang on hehe
11:37:13 <MrReach> whichever is most handy at the moment
11:37:22 <I440r> isforth isnt workable yet :P
11:37:32 <I440r> oh ur telling ME to work on it hehe
11:37:36 <I440r> soon
11:37:38 <MrReach> a glob of source code is not going to do much to tell me about your setup
11:38:02 <I440r> what do u mean by my setup ?
11:38:26 <MrReach> ok, first, is there a physical 8051 involved?
11:38:32 <aaronl> No
11:38:41 <I440r> no
11:38:57 <I440r> no 8051 requrired to run my sim
11:39:11 <MrReach> ok, then everything is simulated, and you can intercept any event anywhere in any way you choose
11:39:18 <I440r> yes
11:39:42 <aaronl> do any of you know anything about ada?
11:39:55 <MrReach> then why go through the nightmare of single stepping with an 8051 ISR?
11:40:02 <MrReach> nope
11:40:06 <aaronl> i ITP'd a debugger in ADA
11:40:06 <aaronl> and asked the libgtkada1 maintainer to upgrade the package
11:40:06 <aaronl> he told me either to give him GVD or take over maintainership of all the ada crap in debian
11:40:56 <I440r> erm what if thats what the user wants to debug
11:41:16 <I440r> wants to know that when an irq occurs that the isr works correctly in all situations
11:41:58 <MrReach> right, but that's a different matter than the code being SSd by an 8051 interrupt
11:42:10 <I440r> erm no
11:42:22 <I440r> if we are single stepping and an irq occurs
11:42:27 <MrReach> ok, a simplication ... I hope
11:42:35 <I440r> after stepping ONE instruciton we will automatically go to the isr
11:42:39 <I440r> the cursor will turn red
11:42:43 <I440r> and we will single step the isr
11:42:50 <MrReach> you have an "interpreter" that runs the target object code ...
11:42:52 <I440r> unless the sim has been told to run that isr at full speed
11:43:29 <MrReach> pretend that somewhere in the interp, there is a function called "proc_next_ins"
11:44:01 <MrReach> the FIRST thing that function does is chack a variable to see if there are any simulated ints pending
11:44:53 <MrReach> and if so, so some magic to figure out which interrupt to service, check the PC, ect, and then call "proc_next_ins"
11:45:42 <MrReach> what I heard you say before was "use a simulated 8051 interrupt to implement SS mode"
11:45:56 <MrReach> was I mistaken?
11:46:38 <I440r> erm no thats what COULD be done 9on an actual 8051
11:46:43 <I440r> its not how my sim works
11:46:54 <MrReach> ok, i was mistaken, then, sorry
11:47:18 <I440r> its how some "monitors" work on the 8051
11:47:25 <I440r> u add a very small ammount of code to ur app
11:47:30 <MrReach> the complication seems to be in how to implement an interrupt
11:47:43 <I440r> no a complecation
11:47:48 <I440r> i know how to implement them
11:48:00 <MrReach> errr ... how to watch them, then
11:48:05 <MrReach> sorry
11:48:16 <I440r> the problem i was seeing is that it would be difficult to have isrs services at a rate faster than one instruction cycle
11:48:24 <I440r> but after thinking about it thats NOT a problem
11:48:38 <I440r> because the 8051 couldnt service them any faster than that anyway :)
11:48:45 <MrReach> I see a table where every possible interrupt source is listed, along with info about what to watch and what not to
11:48:51 --- nick: Fare -> Fare61453
11:48:52 <I440r> they can become pending faster than that but couldnt be serviced
11:49:20 <I440r> u got a machine running win32 there (or dos ?)
11:50:03 <MrReach> ok, the usual way to implement ss in the hardware is to place a "trap" machine code instruction immediately after the instruction about to be watched
11:50:21 <I440r> hehe yes. on a PROCESSOR, not on a controller :)
11:50:27 <MrReach> I've got a Win32 machine and a Linux-Mandrake machine
11:51:11 <MrReach> ok, "trap" could equate to "JMP ss_ address"
11:51:28 <I440r> go to /pub and get 8051.tgz
11:51:36 <I440r> let me know when u got it so it can disappear :)
11:51:38 <I440r> shhhh
11:51:41 <I440r> top sekret :P
11:53:01 <MrReach> who is that in image13.jpg?
11:53:06 <I440r> me 
11:55:13 <MrReach> ok, got it
11:55:41 <I440r> ok its gone :)
11:55:53 <I440r> the .com is in there because u wont be able to assemble the source
11:56:03 <MrReach> nice startup screen, I hope your system is virus-free
11:56:08 <I440r> its for a386 and there are parts missing (lib functions of mine)
11:56:16 <I440r> it is
11:56:24 <I440r> that .com is guaranteed to be clean
11:56:31 <I440r> i will swear to that :)
11:56:39 <I440r> "fsckit"  <--- see ????
11:56:39 * MrReach laughs.
11:56:41 <I440r> heh
11:57:15 <MrReach> you don't really LIKE Forth ... do you?
11:57:22 <I440r> i love it
11:58:31 <MrReach> may I suggest ...
11:58:42 <MrReach> making "F1" the help key?
11:58:47 <I440r> erm no hehe
11:58:54 <I440r> that will be alt h or something
11:58:56 <MrReach> perhaps spacebar is "step next"
11:58:57 <I440r> f1 is single step
11:59:03 <I440r> f2 is RUN till next line
11:59:11 <I440r> erm alt H is go till here
11:59:18 <MrReach> heh
11:59:23 <I440r> you can move the blue cursor arround without moving the program copunter
11:59:33 <I440r> but single step always sets cursor over pc again
11:59:40 <I440r> move cursor to some line and press alt w
11:59:47 <I440r> that line now disassembles as dw data
11:59:54 <I440r> press alt b and it disassembles as db
12:00:01 <I440r> alt a makes it ascii
12:00:04 <I440r> and alt c makes it code
12:00:45 <I440r> press f10 and u get an incomplete setup window
12:00:48 <MrReach> perhaps should have assembly source file called "keys.s" or "bindings.s" so that they're easy to find
12:00:48 <I440r> that allows you to map code space to the same area as data space
12:00:48 <MrReach> how long have you been working on this?
12:00:54 <I440r> about 2 weeks :)
12:00:54 <I440r> erm maybe 3
12:01:06 * MrReach nods.
12:01:19 <I440r> all the keys are in menu.s
12:01:44 <I440r> some of the code they execute is also in there but it doesnt realy belong in there heh
12:02:01 <MrReach> btw, this program should run beautifully in Linux with DOSEMU
12:02:08 <MrReach> as should A86
12:02:13 <I440r> i know
12:02:20 <I440r> but i wont run dos emu hehe
12:02:35 <I440r> this is being developed on my dual boopt laptop
12:02:39 <I440r> booted to win32
12:02:48 <I440r> besides
12:02:52 <MrReach> that's fine
12:02:55 <I440r> ill do a linux version of it later hehe
12:02:57 <I440r> prolly in c
12:03:10 <I440r> tho i MITE make this commercial
12:03:17 <MrReach> why have you chosen not to do this in Forth?
12:03:17 <I440r> depending on how good it is when its finished
12:03:31 <I440r> ive seen some realy shitty sims for the 8051 that cost alot of money
12:03:46 <I440r> because im trying NOT to think about forth rite now....
12:03:53 <MrReach> yes, usually provided by the company that sells the chips
12:03:58 <I440r> i needed something to do that wasnt taxing on my brain
12:04:01 <I440r> and this isnt 
12:04:03 <MrReach> the development systems are often lacking
12:04:18 <I440r> i mite do an assembler some day too
12:04:24 <MrReach> hahaha!
12:04:26 <I440r> rite now this sim can only load hex files
12:04:30 <MrReach> that's too funny!
12:04:32 <I440r> so its not symbolic
12:04:43 <I440r> i need to learn about omf to get that
12:04:52 <I440r> so i can load any omf file and have symbols too
12:05:14 <I440r> isforth is sort of a headache rite now... i am sorta burned out with it
12:05:18 <I440r> not permanantly 
12:05:27 <MrReach> I was just going to suggest abstracting "proc_next_instruction" in such a way as to be portable across different controllers
12:05:31 <I440r> i usually get like this when i have to make some big decision about myu cod
12:05:46 <MrReach> 8051 ... 6502 ... 6805 ... etc
12:06:10 <MrReach> ooops, 6809
12:06:10 <I440r> hehe i could do that but that would mean an almost total rewrite
12:06:18 <MrReach> not really
12:06:24 <I440r> the disassembler would need to change
12:06:37 <I440r> the executon engine would need to change
12:06:41 <MrReach> the framework of the simulator would remain almost exactly the same
12:06:54 <I440r> my code has knowledge of the memory map of the 8051 and relies on that knowledge
12:06:57 <MrReach> and all the stuff specific to the 8051 would go into a single file
12:07:05 <I440r> like 8051 is harvard architecture man heh
12:07:46 <MrReach> hmmm ...
12:08:13 <I440r> the 8051 has three memory spaces
12:08:16 <I440r> internal ram
12:08:18 <I440r> code space
12:08:20 <I440r> and data space
12:08:21 <MrReach> I don't think the abstraction would be all that difficult
12:08:28 <I440r> my sim allows you to overlap code and external data
12:08:34 <I440r> which you CAN do on an 8051
12:08:36 <MrReach> especially considering all the work that went into the UI
12:08:47 <I440r> hehe almost no work dood heheh
12:08:52 <I440r> that was the easiest part hehe
12:09:05 <MrReach> nono ... 8051 would have "blob of memory that the controller sees"
12:09:29 <MrReach> and "set of instructions that it understands"
12:09:44 <MrReach> "this machine-code sequence does this ...."
12:10:12 <MrReach> "this machine-code sequence disassembles like this ...."
12:10:34 <I440r> erm look at the start of 8051.a code 
12:10:41 <I440r> one of the first things i do is set up the 8051 memory space
12:10:44 <I440r> mov si,2
12:10:46 <I440r> lodsw
12:10:52 <I440r> sub ax,01000
12:10:59 <MrReach> oh, yes, I saw that
12:11:03 <I440r> mov cseg,ax   ;this is code space
12:11:09 <I440r> sub ax,01000
12:11:15 <I440r> mov dsge,ax  ;this is data space
12:11:21 <I440r> 64k each
12:11:24 <MrReach> but how much memory should be controller dependant, and go in the 8051.s file
12:11:28 <I440r> that is specific to the 8051
12:11:53 <I440r> there are alot of places in the code taht rely on their knowledge of this controler heh
12:11:56 <MrReach> perhaps that would be a constant that is handed back to the debugger proper
12:12:01 <I440r> prolly a design flaw on my part but...
12:12:50 <MrReach> or the target file defines "init_mem" "get_mem" and "set_mem" that the debugger can use
12:13:20 <MrReach> and those are the ONLY way a debugger gets access to target mem
12:13:56 <MrReach> a multi-platform assembler could be done in the same way, too
12:13:58 <I440r> hmmm
12:14:07 <I440r> its something i shud prolly think about...
12:14:21 <MrReach> debugger understands "assemble this source file into controller"
12:14:29 <I440r> but i still think i would need to go over my code with a very fine comb to do this rite
12:14:58 <MrReach> but doesn't know how the assembler works at all, except to hand one line at a time to "assemble_one_line"
12:15:38 <I440r> assemble ?
12:15:42 <I440r> u mean disassemble ?
12:15:51 <MrReach> no, I mean assemble
12:16:09 <MrReach> there needs to be some way to get the source into the target
12:16:34 <MrReach> the easiest to write is assembly language, rather than raw hex machine code
12:17:07 <I440r> erm the assembelr assembles an omf file
12:17:07 <I440r> i use an object to hex converter
12:17:07 <I440r> my sim can only load hex files
12:17:15 <MrReach> oh, you're using an external assembler?
12:17:18 <I440r> want it to be able to load omf files too eventually
12:17:20 <I440r> yes
12:17:24 <I440r> this cant assemble
12:17:29 <MrReach> ok
12:17:31 <I440r> only disassemble and simulate
12:17:53 <I440r> im using eh keil assembler
12:18:00 <I440r> or is it kiel ?
12:18:01 <I440r> erm
12:18:02 <I440r> hehe
12:18:12 <MrReach> I was throwing into the idea pot that, ideally, each controller spec file would know how to assemble its own source
12:18:33 <MrReach> and dump into hex or binary image file
12:18:50 <I440r> :)
12:19:20 <MrReach> eventually, it would grow to understand how to SS on target hardware with umbilical
12:19:28 <MrReach> but that's a ways down the road
12:19:48 <I440r> i have an 8051 target board here :)
12:19:54 <I440r> that i can program over the serial line :)
12:20:27 <MrReach> design descisions about umbilicals are never easy, and lock the future development into one path or another
12:20:45 <I440r> thats why i prefer the simulator
12:21:00 <I440r> because the unmbilical would need to use the ONLY serial line available
12:21:08 <I440r> which means you cant debug that code hehe
12:21:09 <I440r> doh!~
12:21:14 <I440r> with my sim you will be able to
12:21:36 <MrReach> right
12:21:43 <I440r> actually, the hardest part so far was simulating the subba instruction
12:21:50 <MrReach> umbilicals are sometimes mandatory, though
12:21:53 <I440r> because of whta taht instruction does with the psw
12:22:14 <I440r> borrow into bit 7 sets carry
12:22:18 <I440r> BUT
12:22:24 <I440r> borrow into bit 3 sets auxillary carry
12:22:24 <MrReach> for instance, when the chip documentation doesn't actually match what the chip actually does
12:22:41 <MrReach> heh
12:22:52 <I440r> borrow FROM or TO bit 7 sets overflow as long as its not a borrow both from and to
12:22:59 <I440r> ive seen that
12:23:02 <MrReach> for doing packed BDC calcs?
12:23:12 <I440r> every piece of documentation
12:23:15 <I440r> every singe data sheet
12:23:29 <I440r> says taht the or ax,whatever has NO effect on the psw
12:23:31 <I440r> tahts a lie
12:23:37 <I440r> they say the same about and and xor too
12:23:47 <I440r> these instructoins can affect the parity bit of psw
12:23:56 <I440r> the docs are WRONG!!!
12:24:08 <MrReach> heh
12:24:14 <MrReach> it happens dometimes
12:24:26 <I440r> plus thers another thjing i gotta take into account
12:24:34 <I440r> my sim sims PURE 8051
12:24:42 <MrReach> it's not a big deal when you have an umbilical to see if the hardware is doing what it's supposed to
12:24:55 <I440r> what about the third party versions of the 8051 with extra serial ports
12:25:04 <I440r> and second dptr
12:25:07 <I440r> extra timers
12:25:09 <I440r> etc etc etc
12:25:28 <MrReach> but without the umbilical, no amount of simulation is going to tell you why your ROMed images just don't do what they're supposed to
12:25:39 <I440r> hehe i know.
12:25:54 <I440r> no simulator or even EMULATOR will behave exactly as the device itself will
12:26:11 <I440r> who is clog ?? hehe
12:26:19 <I440r> is this someone i know using another nick ?
12:26:24 <MrReach> heh, you're arguing FOR a controller-independant debugger
12:26:36 <I440r> for and against
12:26:40 <MrReach> I have no idea
12:26:43 <I440r> im doing a software debugger
12:26:48 <I440r> not a hardware debugger
12:26:55 <I440r> me and hardware are like this..... -->
12:27:09 <I440r> oh... whats this dp  (touch) gadzzzztz!!! 
12:27:10 <I440r> oopts
12:27:15 <I440r> dp = do
12:27:18 <MrReach> if you're going commercial ... much better to build a seamless transport
12:27:26 <I440r> :)
12:27:32 <I440r> not decided yet
12:27:47 <I440r> but my sim will support every version of the 8051 i can get specs for :)
12:28:12 <MrReach> "(R)un -> On (S)imulator"
12:28:21 <MrReach> "(R)un -> On (H)ardware"
12:28:44 <I440r> erm no my sim wont have any hardware interfaces to an actual 8051
12:28:54 <I440r> it will be a SINULATOR, not an emulator
12:29:53 <MrReach> and not a "Development System"?
12:30:00 <I440r> maybe eventually
12:30:16 <I440r> but writing this is alot easier than writing a full blown macro assembler for the 8051
12:30:21 <MrReach> hmmm ... what is the price range for 8051 Simulators?
12:30:25 <I440r> tho thats proly not too difficult either
12:30:38 <MrReach> primitive asms are pretty easy
12:30:43 <I440r> some u get for free when u get a specific assembler
12:30:47 <I440r> so im not too sure
12:30:56 <I440r> i have a very crappy shareware one here called emily
12:31:02 <I440r> to single step you say
12:31:05 <I440r> g [enter]
12:31:08 <I440r> m [enter]
12:31:16 <I440r> where n is the number of instructions to step
12:31:18 <I440r> it sucks
12:31:33 * MrReach nods
12:31:36 <I440r> cant remember how much he is asking for that 
12:31:43 <MrReach> well, I'm thinking marketing
12:31:51 <I440r> i did a partial reverse engineeer of it to see if it could give me any cluse about anything
12:31:53 <I440r> i said fsck that
12:31:58 <I440r> its written in c hehe
12:32:00 <MrReach> how tight is the development environment market?
12:32:06 <I440r> hmmm dunno
12:32:20 <I440r> but the 8051 is one of the most widly used microcontrolers there is
12:32:23 <MrReach> it could be an excellent simulator written in C
12:32:25 <I440r> siemens make a version
12:32:26 <I440r> intel
12:32:27 <I440r> dallas
12:32:35 <I440r> LOADS of ppl make 8051's
12:32:40 <MrReach> it was probably the result of a newbie programmer getting some experience
12:33:05 <MrReach> yes, the military machines I used to work on used them (in '89)
12:33:14 <I440r> yup
12:33:25 <MrReach> they're a workhorse
12:33:42 <MrReach> some of the present variants are quite exotic
12:33:52 <I440r> yes
12:33:52 <MrReach> with on-chip firewire, etc
12:33:58 <I440r> i planm to support those :)
12:34:14 <I440r> but for rite now its pure 8051
12:35:06 <MrReach> hmmm ... I would suggest trying to abstract the code into "debugger" and "emulated hardware"
12:35:48 <MrReach> an asm variable "target_mem" for all accesses, for example
12:36:39 <I440r> except the 8051 doesnt just have "target memory"
12:36:40 <I440r> it has
12:36:41 <MrReach> which chip documentation are you using right now?
12:36:43 <I440r> internal ram
12:36:45 <I440r> external ram
12:36:48 <I440r> code space
12:36:56 <MrReach> right, but the SIMULATOR has target memory
12:37:44 <MrReach> and by thinking of it as such, the simulator can manipulate the target mem of many types of simulated controllers
12:38:06 <I440r> erm thats part of the problem
12:38:16 <I440r> every part of this simulator was written to be 8051 specific
12:38:27 <MrReach> each controller has a set of functions that it implents for the simulator
12:39:09 <MrReach> take a pice of paper, draw two big boxes, label one "debugger" and one "target"
12:39:24 <MrReach> when you write a function, write it into one of the boxes
12:39:36 <I440r> hmmm
12:39:53 <I440r> what if the funciton ahs application in BOTH
12:39:54 <MrReach> if it doesn't fit easily, divde it into two similar functions, one to go in each box
12:40:06 <I440r> but only if were using "this" controler
12:40:15 <I440r> i dont like that
12:40:18 <MrReach> yes, that had occured to me
12:40:19 <I440r> i dont waht duplicated code
12:40:34 <I440r> i dont want TWO identical versions of a funciton
12:40:42 <I440r> notice the size of this simulator ?
12:40:45 <MrReach> the situation when a "feature" of one controller simply can't apply to another controller
12:40:45 <I440r> very very small
12:40:58 <I440r> im contemplating a slight optimization of my disassembler
12:41:09 <I440r> that will reduce its size to 1/3 of what it currently is
12:41:11 <MrReach> does it run slow?
12:41:17 <MrReach> if not, don't worry about it
12:41:22 <I440r> but will make it very obfuscated hehe
12:41:23 <I440r> no
12:41:24 <I440r> well
12:41:29 <I440r> not on my laptop its not
12:41:32 <I440r> thats only 500 mhz hehe
12:41:37 <I440r> dunno
12:41:42 <I440r> need to see what it does on a 386
12:41:45 <MrReach> if the code in the debugger is complex, break it into smaller pieces
12:41:55 <MrReach> this is where Forth shines, actually
12:41:56 <I440r> its not complex at all
12:42:02 <I440r> its very very simple
12:42:18 <I440r> ive got the disassembler written to be readable as well as small
12:42:29 <I440r> so that if i publish my source any idiot can understand it hehe
12:42:42 <I440r> but if i do this optimization it will make it harder to follow
12:42:44 <I440r> not for me
12:42:55 <MrReach> is there no reason that can't be applied to more than one controller?
12:42:57 <I440r> for the aforementioned idiot hehe
12:43:08 <I440r> rite now im just thinking 8051
12:43:42 <MrReach> can I see the 8051 docs that you're writing from?
12:46:04 --- quit: I440r (Read error to I440r[purplecoder.com]: EOF from client)
12:46:14 --- join: I440r (mark4@purplecoder.com) joined #forth
12:46:26 <I440r> doh!
12:46:43 <MrReach> heh, what happened?
12:46:57 <I440r> dunno
12:47:11 <I440r> i had to ifconfig eht0 down on this box followed by up
12:47:18 <I440r> followed by rouyte add default gw
12:47:20 <I440r> then i was fixed
12:47:31 <I440r> i think debian woody has some problems heh
12:49:33 <MrReach> can I see the 8051 docs that you're writing from?
12:49:46 --- mode: MrReach set mode: +o I440r
12:49:56 <I440r> its a book
12:50:05 <MrReach> oh, ok
12:50:07 <I440r> i got the phillips book here
12:50:17 <I440r> stole it fair and square fronm the trash at work :)
12:50:25 <MrReach> how many instructions? how many addressing mode variants?
12:50:39 <I440r> u looking in disassem.s ?
12:50:49 <I440r> heres how i disassemble
12:50:53 <MrReach> I am now ... are they all there?
12:50:57 <I440r> yes
12:51:00 <I440r> every single one
12:51:11 <I440r> i split the opcode into upper and lower nibbles
12:51:20 <I440r> MOST instructions decode on the upper nibble
12:51:30 <I440r> and the lower one is like parameters or addressing mode
12:51:54 <I440r> if the lower nibble is (in binary) 1xxx then xxx is a resister r0 to r7
12:52:02 <I440r> like mov a,rn or mov rn,a
12:52:24 <I440r> if its 011x then x is an indirect register
12:52:29 <I440r> which can only be r0 or r1
12:52:32 <I440r> mov a,@r0
12:52:37 <I440r> mov a,@r1
12:52:41 <I440r> mov @r0,a
12:52:47 <I440r> mov @r1,a
12:52:51 <I440r> that sort of thing
12:53:02 <MrReach> ok
12:53:12 <I440r> if its neither of those then the lower nibble can only be
12:53:18 <I440r> 2,3,4 or 5
12:53:30 <I440r> it cant be  a 1 because taht is anm ajmp or an acall
12:53:42 <I440r> xxxx xxx1  is an ajmp or acall
12:53:42 <MrReach> want to hear a first-pass debugger abstraction?
12:53:52 <I440r> :)
12:54:31 <MrReach> each target-spec provides the following functions ...
12:54:55 <MrReach> int get_inst_size(tadr)
12:55:05 <I440r> which does what ?
12:55:13 <I440r> i cant tell hte size of an instrucxtikon without disassembling it :)
12:55:15 <MrReach> char *get_inst(tadr)
12:55:23 <MrReach> that's right
12:55:28 --- join: FareTower (root@ppp83-net1-idf2-bas1.isdnet.net) joined #forth
12:55:36 --- mode: I440r set mode: +o FareTower
12:55:49 <MrReach> bool emul_inst(tadr)
12:55:58 <FareTower> sounds awfully like C
12:56:03 <I440r> hehehe
12:56:13 <MrReach> I'm using a C-type parameter specification
12:56:26 --- nick: Fare61453 -> Fare
12:56:30 --- part: Fare left #forth
12:56:32 <MrReach> it's hella hard to type ASM register specs on IRC
12:56:56 <I440r> :)
12:57:03 <FareTower> then write them on a HTML page, and publish the URL
12:57:11 <MrReach> and that's about *IT* for the single-step emulator interface
12:57:27 <MrReach> for chit-chat?
12:57:46 <I440r> :)
12:57:47 <MrReach> I really should setup a private Wiki-web for this type of thing
12:58:07 <MrReach> OH! I forgot one ...
12:58:55 <I440r> ?
12:59:15 <MrReach> struct reg-desc *dump_state() ... void display_dump(struct reg_desc *blah)
12:59:30 <I440r> oh yea
12:59:34 <I440r> hehe that one is needed hehe
12:59:41 <MrReach> so that the debugger can display the new register contents after emulating each intruction
13:00:07 <MrReach> note that register display is NOT the responsibility of the debugger
13:00:17 <MrReach> but of the emulator
13:01:02 <MrReach> because each controller will have its own set of regs to display
13:01:14 <MrReach> and all kinds of specific state information
13:02:54 <MrReach> even in the 8051, there are many variants that will affect the display
13:03:20 <MrReach> 0-4 serial ports, 0-god knows how many I/O lines, etc
13:03:22 <I440r> yes
13:03:35 <I440r> but wont affect the main display much
13:03:44 <I440r> ive still got some work to do there
13:03:50 <I440r> like my stack isnt even being displayed yet
13:04:06 <I440r> and the space allocated for that display is way too big :)
13:04:19 <MrReach> there would need to be a uniform method for the debugger to deal with such variances
13:05:11 <MrReach> a REALLY neat idea about this ...
13:05:39 <MrReach> is that a Forth target environment could be provided for each controller ... if the developer cared to use it
13:05:59 <MrReach> if not, the developer is welcome to stick to straight asm
13:06:47 <I440r> ?
13:07:05 <MrReach> what are you wondering about?
13:07:33 <I440r> what u just said
13:07:46 <I440r> this is a simulator taht can single step thru ANY code
13:07:50 <I440r> forth, c or pure asm
13:07:52 <MrReach> ok, imagine this scenario ...
13:07:59 <I440r> because they are all realy just asm :)
13:08:39 <MrReach> I built objects with embedded controllers (pretend microwave ovens and VCRs) ...
13:09:18 <MrReach> Hitachi has JUST released a new super-duper controller that is perfect for my applications
13:09:34 <MrReach> lets call it the "H8"    @:^>
13:09:44 <I440r> :)
13:09:58 <MrReach> I go to your company and buy your debugger/development environment
13:10:32 <MrReach> and I build a prototype board that has nothing but ram an enough rom to accept an emage via the umbilical and run it
13:10:47 <MrReach> the hardware is fixed at this point
13:10:55 <MrReach> emage=image
13:10:56 <I440r> k
13:11:25 <MrReach> now, I simulate a test environment until it works flawlessly
13:11:51 <MrReach> then a click the "run on hardware" button
13:12:01 <MrReach> the addresses change, but everything looks identical otherwise
13:12:14 <I440r> k
13:12:22 <MrReach> I run the tests in pieces and parts
13:12:35 <MrReach> documenting enexpected behavior
13:12:41 <MrReach> unexpected
13:12:55 <MrReach> because the hardware isn't exactly as documented
13:13:29 <MrReach> when I'm conviced that I understand the hardware ... I click "Load Forth to target"
13:13:39 <MrReach> now the display changes a LOT
13:13:57 <MrReach> I'm now looking at a Forth single-step debugger
13:14:20 <MrReach> that can emulate the target system locally, or actually execute the Forth on the target system
13:14:36 <I440r> erm yes i understand
13:14:44 <I440r> taht would mean a forth ON the target and on the host
13:14:48 <I440r> like chipforth
13:15:05 <MrReach> if something breaks, I can try to debug in forth ... or revert back to machine code debugging
13:16:09 <MrReach> the idea is that there is no real distiction between working with simulated debugging and actually debugging on the hardware
13:16:36 <MrReach> or between simulated Forth interpreter ... or the real one on the hardware
13:17:08 <MrReach> does that clarify my thoughts???
13:18:07 <I440r> hmm
13:18:13 <I440r> reading
13:18:18 <I440r> yes thats how chipforth works
13:18:19 <MrReach> now, lets say that my boss nix's the H8, and tells me I'm to use the 6809, period
13:18:28 <I440r> actually eh distinction is the vocabulary ur using
13:18:39 <I440r> you have a "target" vocabulary
13:18:41 <MrReach> I'm pissed, but my sources are in Forth
13:18:51 <I440r> so u can actually execute words on the host taht call funcitons on the target
13:19:06 <MrReach> so I go through the process of building a prototype board, and documenting the errors
13:19:34 <MrReach> and then writing maybe a half-dozen glue words to implent the EXACT same source code on a completely different platform
13:20:10 <MrReach> I saw a presentation of chipforth at a Sacramento FIG meeting
13:20:31 <I440r> ive used chipforth for teyh 8051
13:20:36 <I440r> i was impressed actually
13:20:50 <MrReach> yes, pretty snazzy
13:20:57 <I440r> whish i had grabbed a coppy
13:20:59 <I440r> but never did
13:21:49 <MrReach> I was just pondering how difficult it would be to integrate that type of functionality into a development environment similar to yours
13:22:10 <MrReach> and what benefits it would give the end-user that weren't there before
13:22:30 <MrReach> want to hear another idea?
13:22:41 <MrReach> (i'm going to have to leave soon)
13:22:44 <I440r> k
13:22:48 <I440r> sure
13:23:20 <MrReach> heh, find someone who likes to do SPICE software
13:23:33 <I440r> spice ?
13:23:44 <MrReach> and include a SPICE emulator with the development environment
13:24:06 <MrReach> SPICE is the industry-standard for analog component simulation
13:24:30 <MrReach> it's WAY cool, use a cad-like interface to draw a schematic ...
13:24:50 <MrReach> and then emulate circuit response with virtual oscilloscope
13:25:02 <I440r> hrm
13:25:10 <I440r> sounds difficult to do hehe
13:25:15 <MrReach> is often tied with automated board-layout software
13:25:18 <I440r> and the whole erason for doing this was because it was EASY hehe
13:25:30 <MrReach> it's not, really, but it requires HELLA mips
13:25:48 <I440r> hehe
13:25:57 <MrReach> because most components require iterative approximation
13:26:28 <MrReach> and, often, one is looking at nano-second resolution 
13:26:40 <MrReach> anyway, the benefit of this is that ...
13:27:04 <MrReach> the user could emulate the hardware of a board, which feeds the emulated micro controller
13:27:34 <MrReach> and can, theoretically, design the whole appliance from start to finish without touching a soldering iron
13:28:04 <MrReach> and then only focus on those places where it doesn't perform to spec
13:28:12 <I440r> oh ye ai see 
13:28:15 <MrReach> in the hardware prototype, that is
13:28:18 <I440r> simulate HARDWARE too hehe
13:28:54 <MrReach> SPICE has been around for ages, but it's EXPENSIVE ... comercial systems start at $600
13:29:13 <MrReach> and they DON'T emulate microcontrollers
13:29:41 <I440r> hmm
13:37:53 <MrReach> per haps, the simulator/debugger woud cost $200
13:38:04 <I440r> or more
13:38:08 <I440r> or less
13:38:16 <MrReach> all the SPICE component models are free to access via the internet
13:38:17 <I440r> dunno yet have to see how good it is first :)
13:38:36 <MrReach> and each controller plugin cost $40-$100
13:38:56 <MrReach> maybe a shareware version that is limited in various ways
13:39:05 <MrReach> for hobbiests
13:39:10 <MrReach> hobbyists
13:39:14 <MrReach> like yourself
13:39:57 <I440r> :)
13:41:03 <MrReach> a continous full-page advertisement in EDN would probably cost $600-$1200 /mo
13:41:11 <MrReach> and would easily pay for itself
13:41:39 <MrReach> perhaps giving a volume as high as 20-40 units/mo in sales
13:42:10 <I440r> :)
13:42:28 <MrReach> I would like to figure out some method of providing a "subscription" business model, thugh
13:42:28 <I440r> have to have a product before i can market it but if i get the product i can markte it np :)
13:42:42 <I440r> i can afford to put an add in any publication :)
13:42:51 <MrReach> because subsciption income is much more predictable
13:43:21 <MrReach> i4: not if that ad doesn't provide any sales ... that's called a budgetary black hole
13:44:00 <MrReach> parden my spelling
13:44:13 <I440r> erm ye ai know hehe
13:44:26 <I440r> if u put my add in a "car mag" i dont think id get ANY sales ehhe
13:44:41 <I440r> but if i put it in an on topic publication
13:44:47 <I440r> like one on embedded coding....
13:44:53 <I440r> sent my sim to tehm for review ????
13:45:29 <MrReach> yes, and hire someone whose only job is to answer USENET queries where this product might be used to solve a problem
13:46:04 <I440r> erm dont want to "hire" anyone hehe
13:46:09 <MrReach> something like Elizabeth Rather does in comp.lang.forth
13:46:32 <I440r> :)
13:47:11 <MrReach> something to be aware of, though ...
13:47:25 <I440r> yea
13:47:39 <MrReach> is that this is "big software" ... requiring planning and some discipline
13:47:46 <I440r> i know
13:47:49 <I440r> but not yet hehe
13:47:54 <MrReach> so that legacy code does not hamper future development
13:49:31 <MrReach> well, time for me to go now
13:49:44 <MrReach> I've already spent more time here than I should have
13:49:49 <MrReach> take care of yourself.
13:49:56 <I440r> l8er dood
13:50:00 <I440r> nice talkin with u :)
13:50:00 --- nick: MrReach -> MrGone
13:52:40 --- join: ult (ultima@149.149.201.30) joined #forth
13:55:55 --- join: hcf (nef@207-172-225-110.s110.tnt1.pld.me.dialup.rcn.com) joined #forth
13:56:47 --- part: hcf left #forth
15:19:22 --- quit: ult (Read error to ult[149.149.201.30]: Connection reset by peer)
15:37:33 --- join: ult (ultima@149.149.201.30) joined #forth
15:48:09 --- quit: I440r (I'm too lame to make a quit message)
15:48:10 --- join: I440r (mark4@purplecoder.com) joined #forth
16:14:25 --- quit: clog (Leaving)
16:14:25 --- log: stopped forth/00.12.03
16:14:43 --- log: started forth/00.12.03
16:14:43 --- join: clog (nef@bespin.org) joined #forth
16:14:43 --- topic: 'http://isforth.sourceforge.net -- http://cvs.sourceforge.net/cgi-bin/cvsweb.cgi/isforth/?cvsroot=isforth'
16:14:43 --- topic: set by ChanServ on [Fri Dec 01 08:49:37 2000]
16:14:43 --- names: list (clog I440r ult @FareTower @MrGone @aaronl)
16:14:43 --- names: EOL
16:28:04 --- quit: ult (Read error to ult[149.149.201.30]: Connection reset by peer)
16:55:04 --- quit: aaronl (Read error to aaronl[vitelus.com]: Connection reset by peer)
16:55:04 --- join: aaronl (aaronl@vitelus.com) joined #forth
16:55:22 --- quit: MrGone (Read error to MrGone[209.181.43.190]: Connection reset by peer)
16:55:39 --- join: MrGone (mrreach@209.181.43.190) joined #forth
17:42:33 --- join: edrx (edrx@copacabana-ttyS18.inx.com.br) joined #forth
17:49:15 --- quit: FareTower (Ping timeout for FareTower[ppp83-net1-idf2-bas1.isdnet.net])
17:50:15 --- join: FareTower (root@ppp83-net1-idf2-bas1.isdnet.net) joined #forth
18:08:47 --- quit: MrGone ()
18:27:11 --- join: ult (ultima@149.149.201.30) joined #forth
19:07:18 --- quit: FareTower (barnes.openprojects.net pohl.openprojects.net)
19:07:29 --- join: FareTower (root@ppp83-net1-idf2-bas1.isdnet.net) joined #forth
19:21:20 --- join: TheBlueWizard (TheBlueWiz@ppp-52.u1-h1.dca.fcc.net) joined #forth
19:21:26 <TheBlueWizard> hiya all
19:21:33 <TheBlueWizard> I will be here briefly
19:38:48 <TheBlueWizard> bye all
19:38:50 --- part: TheBlueWizard left #forth
19:55:10 --- quit: edrx ([x]chat)
20:21:16 --- quit: FareTower (BitchX-1.0c17 -- just do it.)
21:11:43 --- quit: I440r (clarke.openprojects.net tolkien.openprojects.net)
21:11:43 --- quit: aaronl (clarke.openprojects.net tolkien.openprojects.net)
21:11:43 --- quit: ult (clarke.openprojects.net tolkien.openprojects.net)
21:12:23 --- join: I440r (mark4@purplecoder.com) joined #forth
21:12:23 --- join: aaronl (aaronl@vitelus.com) joined #forth
21:12:23 --- join: ult (ultima@149.149.201.30) joined #forth
21:14:46 <I440r> wb clog
21:14:56 <I440r> was taht an auto reconnect or are u here 
21:43:47 <aaronl> that was an autoreconnect
22:12:02 <I440r> thunked so :)
23:59:59 --- log: ended forth/00.12.03