00:00:00 --- log: started forth/08.05.03
00:19:02 --- quit: lucca (Remote closed the connection)
00:43:23 --- join: lucca (n=lucca@kuu.accela.net) joined #forth
01:44:39 --- join: LOOP-HOG (n=jasondam@75-175-29-218.ptld.qwest.net) joined #forth
01:47:46 --- quit: LOOP-HOG (Client Quit)
03:53:00 --- join: snoopy_1711 (i=snoopy_1@dslb-088-068-207-017.pools.arcor-ip.net) joined #forth
03:55:46 --- quit: Snoopy42 (leguin.freenode.net irc.freenode.net)
03:55:53 --- nick: snoopy_1711 -> Snoopy42
05:00:04 --- join: GoNoGo (n=GoNoGo@cro34-3-82-236-93-215.fbx.proxad.net) joined #forth
06:09:44 --- quit: GoNoGo ("ChatZilla 0.9.81 [Firefox 2.0.0.14/2008040413]")
08:08:05 --- join: Quartus` (n=Quartus`@205.205.50.1) joined #forth
08:09:14 <Quartus`> hi.
08:48:42 --- join: JasonWoof (n=jason@c-65-96-165-155.hsd1.ma.comcast.net) joined #forth
08:48:42 --- mode: ChanServ set +o JasonWoof
08:51:53 --- join: arke_ (n=arke@p57A74E8B.dip.t-dialin.net) joined #forth
08:51:59 <JasonWoof> wb arke_ 
09:09:04 --- quit: arke (Read error: 110 (Connection timed out))
09:40:11 --- quit: arke_ (Read error: 110 (Connection timed out))
09:42:51 <Quartus`> hey Jason.
10:05:44 --- join: blahzaaa (n=santa@24-196-192-150.static.hckr.nc.charter.com) joined #forth
10:29:19 <Quartus`> What's new?
10:54:43 <JasonWoof> just walked into a plant swap
10:55:58 <JasonWoof> was walking home with a few groceries and saw a bunch of people down a tiny dead-end road hangin' around with a bunch of potted plants
10:57:01 <JasonWoof> really fun people
10:58:15 <Quartus> neat.
10:58:16 <Quartus> :)
12:30:40 --- part: blahzaaa left #forth
14:19:02 <JasonWoof> hmmm... galeon doesn't crash every other youtube video I watch
14:19:22 <JasonWoof> I thought it was the flash plugin... maybe it's epiphany and firefox
14:28:04 --- join: edrx (i=edrx@189.25.100.253) joined #forth
15:06:30 --- quit: Al2O3 ()
15:31:56 --- join: Deformati (n=joe@c-68-61-240-49.hsd1.mi.comcast.net) joined #forth
15:39:56 --- quit: Deformative (Read error: 110 (Connection timed out))
15:57:35 --- join: tathi (n=josh@pdpc/supporter/bronze/tathi) joined #forth
15:57:35 --- mode: ChanServ set +o tathi
16:16:13 --- quit: Deformati (Read error: 110 (Connection timed out))
16:16:55 <Quartus> Hi tathi.
16:17:47 --- join: Deformati (n=joe@c-68-61-240-49.hsd1.mi.comcast.net) joined #forth
16:37:52 --- quit: Deformati (Remote closed the connection)
16:50:30 <tathi> hey Quartus 
16:55:02 --- join: Deformative (n=joe@c-68-61-240-49.hsd1.mi.comcast.net) joined #forth
18:00:46 --- quit: tathi ("leaving")
18:37:11 --- join: snoopy_1711 (i=snoopy_1@dslb-088-068-199-030.pools.arcor-ip.net) joined #forth
18:43:16 --- quit: Snoopy42 (Read error: 60 (Operation timed out))
18:43:17 --- nick: snoopy_1711 -> Snoopy42
19:21:20 <lucca> any advice on pre-existing forths that crosscompile to mc68hc11 with native machine code?  output doesn't need to be rommable...
19:24:42 <lucca> most of what I see is either very primitive, 404, or both
19:25:14 <lucca> there's FICL though, but that is... eh... a C based forth that doesn't end up producing native machine code obviously, as it doesn't directly support anything, per se
19:25:27 <lucca> and if I'm going that path I may as well just stick with C
19:33:17 <lucca> hm, if i drop the native code req, pf11 may be a good start... bleh
19:38:30 --- quit: Quartus` (Read error: 104 (Connection reset by peer))
20:17:38 <Quartus> a cross-compiled Forth is hardly likely to be a native-code generator
20:21:05 <lucca> hrmmmm
20:27:51 <Quartus> Make sense?
20:43:55 <lucca> well, kinda
20:44:32 <lucca> it seems like generating a target-image with compiled words should be possible to do independent of the host arch
20:44:48 <lucca> though obviously that's a lot of extra effort
20:45:40 <lucca> sort of like making one forth that can be compiled Completely using any other ansi forth, because it's target assembler is included
20:46:15 --- quit: madgarden ("?OUT OF DATA  ERROR")
20:48:21 --- join: madgarden (n=madgarde@bas2-kitchener06-1096621350.dsl.bell.ca) joined #forth
21:17:54 <Quartus> there's no such thing as a generic target assembler.
21:27:32 <lucca> that wasn't what I advocated... 
21:27:58 <lucca> but it doesn't matter much, heh
21:28:22 <lucca> it is possible to build a series of related assemblers that can target a wide array of systems
21:29:41 <lucca> what I need to do is so small though that it makes more sense to just do it by hand
21:35:30 <JasonWoof> I've done basically what you're talking about for a VM
21:35:38 <JasonWoof> in herkforth I wrote a compiler for that VM
21:36:00 <JasonWoof> used that compiler to create a forth for the VM, which included a "native" compiler
21:36:10 <JasonWoof> so I had to write the compiler/assembler twice
21:37:04 <JasonWoof> it didn't end up being much duplication in this case though, since I designed the VM, and so it's very simple
21:37:39 <JasonWoof> so I run the cross-compiler in herkforth, it spits out an image to be run in the vm
21:37:55 <JasonWoof> The image contains a compiler, and a bunch of source
21:38:17 <JasonWoof> when I fire up the image in the VM it compiles itself, saves a new image of itself, then runs that new image, and opens the editor
21:39:02 <JasonWoof> the extra re-compile is really unsessesary, but I like it, because it's a nice test that everything is working well
21:39:18 <JasonWoof> I am after all runing the image for the purposes of testing that it's working
21:39:45 <JasonWoof> later I'll get it to the point where I can do my editing within the vm, and ditch herkforth
21:39:53 <JasonWoof> hopefully this will be soon...
21:40:48 <lucca> hmmm, that's sort of what I mean, yes
21:41:02 <lucca> though I don't need a compiler to exist in the target at all
21:42:28 <lucca> that would make for come nice debugging features I bet
21:44:15 <JasonWoof> what?
21:44:35 <JasonWoof> so you just want an assembler written in forth?
21:45:02 <JasonWoof> that should be pretty easy to write
21:45:11 <JasonWoof> depending on the CPU... I'm not familiar with your taget CPU
21:46:52 <lucca> well that would be a start, yes, but no... the idea would be to have Most of the code to be "run" on the target written in forth, compiled to target-machine code on the host
22:00:52 <JasonWoof> you're just as ambiguous as before
22:01:05 <JasonWoof> where does the compiling happen?
22:01:16 <JasonWoof> you want all the compiling to happen on your desktop?
22:01:25 <JasonWoof> or on your device
22:01:38 <JasonWoof> sorry, you're not ambiguous
22:02:46 <JasonWoof> so you just want a compiler/assembler that produces native code 
22:02:54 <JasonWoof> trouble is, you can't run that code on the host
22:03:25 <JasonWoof> so all your compile-time stuff has to be compiled for the host
22:03:39 <JasonWoof> and all the stuff that gets compiled, has to be compiled for the target-machine
22:04:14 <JasonWoof> this is unfortunate
22:04:20 <JasonWoof> you lose much of the benefit of forth
22:04:25 <lucca> hmmm
22:05:40 <JasonWoof> this is indeed annoying in my herkforth -> fronds project I mentioned
22:05:52 <JasonWoof> for all immediates, I have to make a herkforth (host) version and a fronds (target) version
22:06:06 <JasonWoof> well, at least all immediates used by the cross-compiler
22:06:32 <lucca> yeah, I see how that gets sticky now... hmmmm
22:06:42 <JasonWoof> I had to make a compromise to alleviate namespace issues too
22:07:10 <JasonWoof> (all cross-compiled words start with v, and the cross-compiler removes the first character when creating the target dictionary)
22:07:37 <JasonWoof> this makes the code for the target machine ugly, since every word in the source has that prefix
22:08:24 <JasonWoof> what might work better for you is a forth that runs on your target CPU, which compiles native code
22:08:58 <JasonWoof> for testing and development this would be very handy.
22:09:21 <JasonWoof> your finished product need not contain the compiler/interpreter, but you'll probably want it for development work
22:10:03 <JasonWoof> an emulator would probably be useful, so you can do all your editing and testing on your normal computer
22:10:32 <JasonWoof> unless you really need to interract with the periferals on the device a lot
22:11:03 <JasonWoof> and even so, I'm still you'll have lots of words that you need to test that don't interract with the periferals, and the easier and quicker you can test those the better
22:11:27 <lucca> well, yeah... interacting with peripherals in a tight loop that won't work with a cable attached is exactly what I need (argh)
22:12:08 <lucca> i.e. read pot, feed it into a PID loop controlling stepper motor
22:29:04 <JasonWoof> can you break anything by sending the wrong signals?
22:29:43 <lucca> no, but it would fall over, heh
22:29:55 <JasonWoof> sounds fun :)
22:30:11 <JasonWoof> makin a robot?
22:30:35 <lucca> hehe, yep!
22:30:43 <JasonWoof> fun fun
22:31:12 <JasonWoof> so, one approach is to write a bunch of code, pop it on there, cross your fingers, and give it a go
22:31:21 <JasonWoof> but the more complex it is, the less likely it is to work
22:31:36 <JasonWoof> and it sounds like you've got a situation where it's awefully hard to debug
22:31:50 <JasonWoof> hence the great value of being able to emulate it somehow
22:32:15 <JasonWoof> if you can run your code in some kind of emulator on the computer, you can give your code fake inputs, and check that it's trying to send the right signals
22:32:16 <lucca> yeah, an emulator may really be worth the time
22:33:01 <lucca> haven't tried emulating an environment that interacts with the physical world so much before
22:33:14 <JasonWoof> dunno if it'd be worth writing an emulator, but if there's one you can use, it should pay off to look into it and set it up
22:33:31 <JasonWoof> you don't have to emulate the interaction with the real world
22:33:58 <JasonWoof> you just have two definitions of READ-POT
22:34:29 <JasonWoof> one that actually tries to read the pot, and another that pulls data from a test table/file/stdin/whatever
22:34:40 <JasonWoof> same for the output
22:34:59 <JasonWoof> while testing you use the test versions, and when you're ready to try it for real you switch over to the real ones
22:36:07 <lucca> yeah, that will be essential for getting the basic pid-logic right... but tuning the gain settings for the loop will have to be done experimentally with the real thing
22:36:11 <lucca> which is going to be annoying
22:36:51 <JasonWoof> sure, you'll have to actually run on the device sometimes
22:37:08 <JasonWoof> but it's great to have an emulator to make sure you're code is working
22:37:31 <JasonWoof> if you get weird results, you'll often want to check that your code is doing what you think it is
22:37:51 <lucca> that makes sense
22:38:23 <JasonWoof> I'm asuming that you're doing something complex here...
22:39:01 <JasonWoof> if it's trivial, you'd probably be fine with just an assembler
22:39:28 <lucca> familiar with pid loops?  Proportional / Integrated / Derivative response
22:39:42 <lucca> in this case I'm just putting together something to balance
22:39:47 --- part: edrx left #forth
22:39:49 <JasonWoof> I feel like over the years I've learned how complex a thing I can write and have it actually work without debugging
22:39:51 <lucca> but balancing on two wheels is sadly a lot harder than it sounds
22:40:14 <JasonWoof> not familiar with pid
22:40:20 <JasonWoof> balancing on two wheels sounds cool though
22:40:44 <lucca> proportional response, meaning turn as far/fast relative to the detected error...
22:41:02 <JasonWoof> last weekend I went to the MIT museum and saw a robot that was designed to bounce around on one foot.
22:41:04 <lucca> integrated, meaning keep track of the cummulative error, etc
22:41:14 <lucca> heh, nice!
22:41:20 <JasonWoof> it was hanging in a case, and I saw a video of it bouncing around, and someone giving it a pretty good shove, and it recovering nicely
22:41:36 <lucca> that could be done with two pid-loops; x and y, I imagine
22:42:07 <JasonWoof> yeah, sounds like you gotta do some fuzzy logic
22:42:44 <JasonWoof> so you have some kind of tilt sensor?
22:44:27 <JasonWoof> yeah, I think for that I'd want to build some kind of simulation on the computer
22:44:40 <lucca> weight attached to a potentiometer
22:46:07 <JasonWoof> sounds highly innacurate
22:47:17 <JasonWoof> guess if you hang it from the center of gravity it'd be ok though
22:47:51 <JasonWoof> it's just that accelleration and deceleration will register as tilt
22:48:14 <lucca> the bot only balances around one axis, and the pendulum swings from that same axis, so it Should work
22:48:34 <lucca> JasonWoof: yeah, they will... but that's not necessarily bad
22:48:52 <JasonWoof> hmmm... yeah, seems like it would work out. I think the acceleration would affect the measurement of tilt by exagerating it
22:49:08 <JasonWoof> which should be super easy to take into account
22:49:15 <JasonWoof> cool
22:49:31 <JasonWoof> I expect you to post videos later!
22:50:05 <JasonWoof> so lonog as you can turn the wheels fast enough to catch it by the time the potentiometer registers you're all set :)
22:50:26 <lucca> heh, I'll try to take videos
22:51:34 <JasonWoof> a simulation on the computer would be cool, because you can test your code against some things, like any of these or combinations:
22:51:50 <JasonWoof> 1) pot reading low
22:51:53 <JasonWoof> 2) pot reading high
22:52:10 <JasonWoof> 3) random (smallish) fluctuation innacuricies in pot
22:52:32 <JasonWoof> 4) various granularities in pot reads
22:53:34 <JasonWoof> what would be really slick, is if you could program it to learn where the balance point is, even if the sensor is off by quite a bit
22:54:28 <JasonWoof> about 6 years ago I went to a small firefighting robotics competition
22:54:39 <JasonWoof> I think max size was 6 inches
22:54:49 <JasonWoof> a few had palm pilots in them as the brains
22:55:08 <JasonWoof> one or two even drew a map on their screen as they went along
22:55:33 <JasonWoof> iPhones have a very accurate tilt sensor in them
22:56:05 <JasonWoof> I was just imagining for a moment an iphone amid some other electronics, wobbling around the room on two wheels :)
22:56:13 <JasonWoof> so are you using gumstix?
23:05:41 <lucca> heh, no, this is actually using an ooold handyboard
23:05:55 <lucca> mc68hc11 based hobby board originally made for some mit class
23:09:23 <JasonWoof> cool
23:09:31 <JasonWoof> you making a robot that can do cool stuff? or just right itself?
23:09:47 <lucca> eh, just right itself for now
23:09:53 <JasonWoof> and then...
23:10:07 <JasonWoof> is that the first step in your plans for world domination?
23:10:17 <lucca> if this gets working right I'll be working on fancier things
23:10:21 <JasonWoof> or you just want to see it balance, then you're going to make a rocket ship?
23:10:37 <JasonWoof> you have the wheels on separate motors so it can turn later?
23:10:51 <lucca> sadly, no
23:11:15 <lucca> steppers are startlingly expensive!
23:11:50 <lucca> hope to make some more complicated balancing and moving things in time for halloween, heh heh heh
23:11:52 <JasonWoof> you could use normal motors and sensors that tell you how fast the wheels are going
23:12:08 <JasonWoof> steppers are expensive?
23:12:19 <JasonWoof> can you rip them out of old floppy drives or something?
23:12:42 <lucca> depends on what type of torque is needed... but that is what I'll need to start doing
23:13:28 <JasonWoof> sounds fun.
23:13:47 <JasonWoof> you wouldn't happen to be in the Boston area?
23:14:50 <JasonWoof> maybe you need the motor from those 48x cd players :)
23:15:06 <JasonWoof> put that thing on a worm gear, those are crazy
23:15:52 <JasonWoof> I gotta find people to make robots with
23:16:00 <JasonWoof> I can walk to MIT, so I should be able to find such people
23:38:47 <JasonWoof> man, I gotta sleep. let me know later if you're near here
23:38:51 --- quit: JasonWoof ("off to bed")
23:38:51 <lucca> san diego area, actually
23:38:53 <lucca> ach
23:59:59 --- log: ended forth/08.05.03