00:00:00 --- log: started forth/14.02.26 00:11:27 --- join: dys (~user@2a01:1e8:e100:8296:21a:4dff:fe4e:273a) joined #forth 00:46:53 --- quit: Bahman (Quit: Leaving.) 01:08:55 --- quit: impomatic (Ping timeout: 244 seconds) 01:09:25 --- quit: john_metcalf (Ping timeout: 272 seconds) 01:15:11 --- quit: c00kiemon5ter (Read error: Connection reset by peer) 01:37:11 --- join: john_metcalf (~john_metc@78.69.90.146.dyn.plus.net) joined #forth 01:49:15 --- join: true-grue (~quassel@95-26-208-54.broadband.corbina.ru) joined #forth 02:01:04 --- join: c00kiemon5ter (~c00kiemon@foss-aueb/coder/c00kiemon5ter) joined #forth 02:18:57 --- join: nighty^ (~nighty@lns-bzn-49f-62-147-170-46.adsl.proxad.net) joined #forth 02:22:48 --- quit: john_metcalf (Read error: Connection reset by peer) 02:23:01 --- join: john_metcalf (~john_metc@78.69.90.146.dyn.plus.net) joined #forth 02:33:01 --- quit: kludge` (Ping timeout: 272 seconds) 02:38:11 --- join: kludge` (~comet@unaffiliated/espiral) joined #forth 03:37:22 --- quit: mnemnion (Remote host closed the connection) 05:01:51 --- quit: Eth|cal (Ping timeout: 264 seconds) 05:18:49 --- join: Eth|cal (~sam@pa49-184-106-223.pa.vic.optusnet.com.au) joined #forth 05:37:50 --- join: mnemnion (~mnemnion@c-98-210-219-91.hsd1.ca.comcast.net) joined #forth 05:43:02 --- quit: mnemnion (Ping timeout: 272 seconds) 05:53:22 --- join: Zarutian (~zarutian@194-144-84-110.du.xdsl.is) joined #forth 06:17:24 --- join: asie (~textual@078088168214.elblag.vectranet.pl) joined #forth 06:43:52 --- quit: pvt_petey (Quit: Computer has gone to sleep.) 06:52:32 --- quit: Eth|cal (Ping timeout: 244 seconds) 07:05:48 --- quit: asie (Quit: I'll probably come back in either 20 minutes or 8 hours.) 07:06:11 --- join: asie (~textual@078088168214.elblag.vectranet.pl) joined #forth 07:38:05 --- join: mnemnion (~mnemnion@c-98-210-219-91.hsd1.ca.comcast.net) joined #forth 07:42:40 --- quit: mnemnion (Ping timeout: 264 seconds) 08:00:10 --- join: PoppaVic (~pops@unaffiliated/poppavic) joined #forth 08:09:24 You know, I have yet to find anyone implementing a tethered/umbilical forth for the avrs, let alone the other microcontrollers - other than Forth, Inc. 08:11:59 there is riscy pygness for arm cortex-m 08:12:38 alas, I lack pygs and arms ;-) 08:19:42 I've been reviewing amforth - which I will likely ignore - and flashforth. But, dammit - sticking the dictionarys on the poor lil mcu's seems silly unless yer making a calculator or something. 08:29:56 --- quit: asie (Quit: I'll probably come back in either 20 minutes or 8 hours.) 08:34:38 --- join: asie (~textual@078088168214.elblag.vectranet.pl) joined #forth 08:42:37 Just write your own cross-compiler, develop on the lappy, and burn to your mcu. 08:42:52 Yeah, that's what I am thinking over. 08:43:11 Forth is one of the only languages simple enough to support that. 08:43:49 Cool. 08:43:57 SOunds like a task about 2 notches beyond my current mindset/time, but it also seems like no one is creating such a thing 08:45:19 --- quit: asie (Quit: I'll probably come back in either 20 minutes or 8 hours.) 08:48:07 I think of it as something that needs to be very clean the bottom architecture level. You'll need a clean to track the memory addresses of word code as compiled on the target. 08:48:23 --- join: tangentstorm (~michal@108-218-151-22.lightspeed.rcsntx.sbcglobal.net) joined #forth 08:48:27 Yeah, that's sorta' what I am thinking about 08:49:25 I'm also musing at implementing hostside in C, (just because I can), and even pondering if you WANT to be able to embed a dictionary in the MCU 08:50:17 Knowing your app as I do i don't know that *you* want that. 08:50:36 I'm assuming this is still ecig related? 08:50:40 KipIngram: that's not really the point. 08:50:50 I'm just thinking of a TOOL 08:51:11 ANd the Swiftforth prices are ludicrous for hobbists 08:51:54 I'm just saying that the desirability of a dictionary on the target is application dependent. 08:52:10 Correct, so it'd only be an option 08:52:44 The only reason I can see for it is when you have a human-interface - serial, etc.. 08:53:24 SO, perhaps when you want a "command monitor" (routers and shit), or a "programmable calculator/monitor", etc 08:53:40 Likely would NOT want the entire forth language visible anyway 08:53:57 So, I would arrange for a word on the host to clear a compile buffer. Then your target oriented words would compile threaded code to that buffer. When done you would BURN. 08:54:30 Yeah, or burn when the buffer reaches a block-size, etc 08:54:46 Then to execute WORD on the target you'd ' WORD RUN our something. 08:54:50 Although, working on the hostside, you could easily handle the entire image.\ 08:55:43 If your wanted a real Forth on the target them you would use the above method to write a target Forth. 08:55:51 Yep 08:56:03 well, except dictionaries always complicate matters 08:56:30 RUN would send a command to the target to set it executing at a proper address. 08:56:57 well, I would expect it to work like tick and execute 08:57:27 you send it the tick-address and then execute the inner-interp 08:57:33 Yes, that's what I was trying to describe. 08:57:48 Except EXECUTE executed the host word. 08:58:10 And tick turns a host address. 08:58:37 well, yeah - it looks it up on the host representation of the remote image 08:58:40 RUN would dig into your dictionary and look up the target address. 08:59:27 also seems to me that making it a direct-threaded remains a bit of an issue. 08:59:54 And then send that over for processing by the target inner interpreter. 09:00:23 I think you could do that either way. 09:00:32 which? 09:00:43 Direct thread you wouldn't have an inner interpreter. You'd just call. 09:01:06 Remember that the MCU mem-maps are freakish: some areas can't execute, some can't execute while writing, etc 09:01:27 Yes. 09:01:55 --- join: asie (~textual@078088168214.elblag.vectranet.pl) joined #forth 09:01:59 That actually makes code threading the easiest. 09:02:49 So it wouldn't really be Forth on the target then. Just be using the host as a macro assembler. 09:03:04 With heavy subroutine use. 09:07:28 All of those weird memory map problems get more tractable if you build your full image on the host and then burn it all at once. 09:11:07 Yes. I was thinking that myself. 09:11:53 It's more like tinkering picospan datafiles between platforms than screwing with hex-loader crap, too. 09:12:45 Yeah. 09:12:52 KipIngram: I'd also question if a hostside needs avrdude or somesuch then, since yer taking control of the serial interface - icsp or usb.. 09:14:08 If your want to be able to use the cheapest mcus then a target dictionary is pretty much out. Some of those guys only have a couple hundred bytes of RAM. 09:15:30 --- join: mnemnion (~mnemnion@c-98-210-219-91.hsd1.ca.comcast.net) joined #forth 09:15:36 I figured you'd write your image in a proper format and then burn it with vendor tools. 09:15:41 yeah, I know - the basic feeling I have is that we'd prefer to work with our ideas on the hostside, sending tests or accomplished sections to the remote.. Regardless if it's a pic14, or a attiny or a due, yun or whatever.. If you want an SBC, then fucking BUY an SBC 09:16:21 You could also write an emulator. 09:16:33 Test stuff before you burned. 09:16:47 too many timing issues to get involved - and too many platforms, but someone could, sure 09:16:52 You could at least catch the silly mistakes that way. 09:17:46 Does it run without crashing, etc. 09:18:10 Yes, I am well aware. But others can contribute those. 09:18:43 Some are already out there. 09:19:02 they'd need to fit. 09:19:03 I've seen pic emulators in the repos. 09:21:14 hmm. 09:21:41 Makes me wonder if the "bootloader" should stick around, at least in function if not form. 09:23:07 of course, from what I've read, it looks like a crufty 'monitor' program anyway 09:29:50 Making sure you write your image in a standard format not only keys you use existing vendor tools to burn, but it's also what would give you access to existing emulators as well. 09:30:07 Lets 09:30:23 Deviating from that format creates many tasks for you. 09:31:04 Yeah, I know.. Just musing, since the existing tools are as hit & miss as I am 09:31:08 --- quit: asie (Quit: I'll probably come back in either 20 minutes or 8 hours.) 09:33:17 hrrm 09:38:46 --- quit: john_metcalf (Read error: Connection reset by peer) 09:38:57 --- join: john_metcalf (~john_metc@78.69.90.146.dyn.plus.net) joined #forth 10:18:16 --- join: asie (~textual@078088168214.elblag.vectranet.pl) joined #forth 10:22:08 --- join: Mat3 (~claude@24-134-25-43-dynip.superkabel.de) joined #forth 10:22:16 hi all 10:22:23 yo 10:22:34 hello PoppaVic 10:23:25 --- join: pvt_petey (~pvt_petey@host-92-16-158-80.as13285.net) joined #forth 10:24:35 KipIngram: the MCU commonalities must exist, they must 10:28:18 Some things are common. We'd need a general way to declare the address space. Where does the code go, where does the days go, etc. 10:28:32 yes 10:29:39 We'd want to have a simple way to specify how the target mcu does a "call" so that the later processes would no how to generate calls for nesting. 10:29:54 I'm still thinking code threading. 10:30:06 we need a variety of datum per platform (target) 10:30:37 ? 10:30:38 Yeah, since the target is instrisitically slow and compact/tight - code-threaded makes sense to me. 10:30:51 You mean types?? 10:31:06 Data types? 10:32:03 Or do you mean a variety of address ranges for different purposes? 10:32:10 no - you can get back later if you need to rush off. omg, no - not datatypes.. Spaces, endian, sizes, widths, accessibility, etc 10:32:53 I figured a lot of that would be hard codes into the target assembler. 10:33:01 Due to the number of idiot assemblers out there, we'd need to either record the tool required or store only bytecode, too 10:33:22 But for placing constants, yes, I guess I see your point. 10:33:47 Byte code isn't code threading. 10:33:49 well, remember: we can either farm out assembly to the toolchain, or store binary blobs. 10:34:07 bytecode is bytes-of-code - what it means is a whole different story ;-) 10:34:19 I'd write the assembler in Forth. They're not hard to write. 10:34:42 KipIngram: how many assemblers are you prepared to write? 10:35:01 see my point yet? 10:35:15 Whatever I need to. How many mcus are you planning to play with? 10:35:23 No, not really. 10:36:10 Myself? the Uno and 328p are in hand; an MP430 or whatever would be nice; the pic24's require a whole programmer and are useless to me w/o knowing what will absolutely work. 10:36:23 When writing an app I'd try to use as little assembly as possible, of course, to keep it mostly portable. 10:36:34 That was my point 10:37:04 Maybe we would not wrote an "assembler." 10:37:28 So we need the basic commonalities, the basic vocabulary, and a mechanism or two to support "this code is specific and ugly - so we farm it out to generate.. BOB" 10:37:37 Maybe just have a core set of words that had to be hand written for each target processor. 10:37:46 yeah 10:37:47 Ok. 10:38:24 This is why I've downloaded amforth and Flashforth - I want to sorta' review what they feel is base/core. 10:38:46 (and FF is more generic than amforth), but both seem... oddball. 10:38:48 you might take a look at the ngaro virtual machine for retro, PoppaVic 10:38:55 Hopefully that would mean using the toolchain to code them and then copy those bytes into the gforth as data. 10:39:15 or mako 10:39:33 they're both very small core virtual machines / forth instruction sets 10:39:49 hi tangentstorm 10:39:51 (and of course eforth if you haven't.) 10:39:54 heya Mat3 10:40:09 ... or take a look at Machine Forth 10:40:37 is that a specific thing or just a generic term? 10:41:27 That's a specific thing. 10:41:49 From the Chuck Moore bunch. 10:42:41 tangentstorm: I looked at ngaro years ago - rather cute. 10:43:15 To use that you'd put a virtual "machine forth machine" at the bottom of your design. 10:43:34 Then you could have portable code above that. 10:43:41 Very compact code. 10:44:07 yep 10:44:17 30-ish base instructions. 10:44:25 yep 10:44:32 is it just their name for the ga144 instruction set? 10:44:56 you can get down to 12 instructions for a balanced MISC-style ISA in my experience 10:45:01 An older processor than that. 10:45:11 F21? 10:45:12 which is why I wanted to get yer input and compare several MCU's, KipIngram - we may well find that regardless of their name, we need less than 50 ops to cover the lot 10:45:48 You will sacrifice some performance with that approach. 10:46:00 Extra layer of virtualization. 10:46:04 hmm? 10:46:17 But very portable. 10:46:27 No, because you code-thread the base and the few words to add words ;-) 10:46:46 only "slower" in terms of "well, it ain't optimized assembler!" 10:46:48 Ok, time for me to drop for now. Back later. 10:53:56 --- quit: asie (Ping timeout: 240 seconds) 10:58:34 --- join: asie (~textual@5.174.90.98) joined #forth 11:15:01 --- quit: asie (Read error: Connection reset by peer) 11:18:41 --- quit: pvt_petey (Ping timeout: 264 seconds) 11:20:58 --- quit: goingretro (Ping timeout: 265 seconds) 11:21:14 --- join: goingretro (~kbmaniac@host81-132-82-210.range81-132.btcentralplus.com) joined #forth 11:22:28 --- join: pvt_petey (~pvt_petey@host-92-16-158-80.as13285.net) joined #forth 11:25:21 --- quit: goingretro (Ping timeout: 244 seconds) 11:28:29 --- quit: Zarutian (Quit: Zarutian) 11:49:15 --- quit: tangentstorm (*.net *.split) 11:49:16 --- quit: nighty^ (*.net *.split) 11:49:16 --- quit: mullein (*.net *.split) 11:49:17 --- quit: C-Keen (*.net *.split) 11:50:03 --- join: tangentstorm (~michal@108-218-151-22.lightspeed.rcsntx.sbcglobal.net) joined #forth 11:51:35 --- join: impomatic (~digital_w@78.69.90.146.dyn.plus.net) joined #forth 11:56:16 --- join: nighty^ (~nighty@lns-bzn-49f-62-147-170-46.adsl.proxad.net) joined #forth 12:00:15 --- join: mullein (~mullein@unaffiliated/mullein) joined #forth 12:00:15 --- join: C-Keen (cckeen@pestilenz.org) joined #forth 12:00:47 --- quit: mullein (*.net *.split) 12:00:47 --- quit: C-Keen (*.net *.split) 12:00:49 --- join: Jhereg (~pops@unaffiliated/poppavic) joined #forth 12:02:05 --- quit: PoppaVic (Disconnected by services) 12:02:07 --- nick: Jhereg -> PoppaVic 12:03:05 --- quit: pvt_petey (Ping timeout: 272 seconds) 12:03:07 --- quit: impomatic (Ping timeout: 272 seconds) 12:03:08 --- quit: karswell (Ping timeout: 272 seconds) 12:03:10 --- quit: joneshf-laptop (Ping timeout: 272 seconds) 12:04:02 --- join: pvt_pete_ (~pvt_petey@host-92-16-158-80.as13285.net) joined #forth 12:04:19 --- join: joneshf-laptop (~joneshf@98.255.30.38) joined #forth 12:07:03 --- join: mullein (~mullein@unaffiliated/mullein) joined #forth 12:07:03 --- join: C-Keen (cckeen@pestilenz.org) joined #forth 12:20:13 --- quit: pvt_pete_ (Quit: Computer has gone to sleep.) 12:20:24 --- quit: joneshf-laptop (*.net *.split) 12:23:33 --- join: joneshf-laptop (~joneshf@98.255.30.38) joined #forth 12:29:18 --- join: impomatic (~digital_w@78.69.90.146.dyn.plus.net) joined #forth 12:45:09 --- quit: clog (Ping timeout: 252 seconds) 12:45:09 --- log: stopped forth/14.02.26 12:45:15 --- log: started forth/14.02.26 12:45:15 --- join: clog (~nef@bespin.org) joined #forth 12:45:15 --- topic: 'Forth Programming | logged by clog at http://bit.ly/91toWN | isforth.com | forthfreak.net | http://forthworks.com/standards/DPANS/ | www.greenarraychips.com' 12:45:15 --- topic: set by I440r!~mark4@cpe-192-136-220-10.tx.res.rr.com on [Thu Jan 02 15:51:09 2014] 12:45:15 --- names: list (clog impomatic joneshf-laptop C-Keen mullein PoppaVic nighty^ tangentstorm Mat3 john_metcalf mnemnion kludge` c00kiemon5ter true-grue dys koisoke ASau` bbloom gordonjcp b_jonas bstates backer drobban ttmrichter dzho bluekelp djinni carc yunfan rprimus_ KipIngram TodPunk Anarch bjorkintosh Adeon pon1980 kulp nighty^_ newcup cataska +crc) 12:54:16 --- join: Eth|cal (~sam@139.216.253.31) joined #forth 13:04:10 --- join: asie (~textual@5.174.90.98) joined #forth 13:15:17 --- quit: asie (Quit: I'll probably come back in either 20 minutes or 8 hours.) 13:20:31 My point earlier was that the Machine Forth instructions are low level. Your mcu of choice has low level instructions as well. *Different* low level instructions. Implementing a set of low level instructions virtually, using a different set, will inevitably result in some inefficiency. 13:20:49 right 13:21:06 Basically you're implementing a model of something so close to hardware that it may well be hardware. 13:21:07 we need to discover a generic layer just above that is all. 13:21:13 --- join: goingretro (~kbmaniac@host81-132-82-210.range81-132.btcentralplus.com) joined #forth 13:21:43 ..w/o involving Forth-as-Operating-System or Forth-must-use-human-input 13:21:48 --- join: Ethical (~sam@139.216.253.31) joined #forth 13:22:14 --- quit: Eth|cal (Ping timeout: 252 seconds) 13:22:18 This why selective access to assembly is so powerful - you target the efficient, non-portable stuff where it is really needed. 13:22:23 KipIngram: the point is to abstract those specificities a notch, and either call 2nd-level words or slam the inline code down 13:22:54 Without access to anything other than virtual Machine Forth, you can't do that. 13:22:59 yeah, but you want to minimize the amount of assembly that a user needs to do. Otherwise the results are the chaos we know & love 13:23:41 i've always thought that one nice thing about forth is that it doesn't really matter whether a word is written in forth or assembly or some other language. you can always just swap it out for another implementation. 13:23:49 I never said to disallow low-level, I am just not in favor of writing an assembler and forcing a flavor, or pointing at some gnu-like product as The Assembler 13:23:57 I thought that was your goal - portability. If you still have access to your *real* processor, via native assembly, them great. :-) 13:24:03 tangentstorm: sorta-kinda, yeah 13:24:04 Then 13:24:38 KipIngram: just so. I don't WANT to need to learn 3 or 5 new "assembly languages", (and yeah - everyone has to be different) 13:25:04 so, the users can dip down and get dirty, or slap together the apropos tokens to roll along 13:25:30 And I actually believe that the chaos "that we know and love" comes from the higher levels, not the lower. 13:26:07 in my mind, it comes from just hacking shit up and playing optimizer. 13:26:29 I don't much care for their reasons - they usually have a smidgen of truth, and the rest is bs 13:27:18 But if your're working down low you can't do add much damage. 13:27:25 Work takes longer. 13:28:22 if someone wants to work UNDER the layers we offer, fine - but then they want to interface in our space.. It's different when that underware is implementation-of-machine. 13:28:22 --- quit: true-grue (Read error: Connection reset by peer) 13:29:10 Sadly, I also see very little reason to comply with esoteric Standards, either.. 13:29:19 probably should not call it underware, for marketing reasons... :) 13:29:47 tangentstorm: I been calling it "underware" for some 20 years - they can challenge me to a duel. 13:30:22 besides, it would appeal to those I prefer and irk those that need to go play in java-land 13:30:32 tangentstorm: that made my wife laugh. 13:31:17 tangentstorm: I'd be more amused if it was "tagless underware" ;-> 13:31:35 ..friggin' micky jordan shows up on my doorstep.. 13:32:49 :) 13:33:43 KipIngram: it might even be preferable to approach this as a "generic assembler" with forthish supports .. Let them extend it at need, but we don't really need to care. 13:34:49 So, you don't adopt any one assembler, and you need only support the bits we need in common.. (edit the db to change any words for 'optimizing') 13:35:35 --- quit: nighty^ (Excess Flood) 13:36:23 --- join: nighty^ (~nighty@lns-bzn-49f-62-147-170-46.adsl.proxad.net) joined #forth 13:45:43 what about a VM, which allows compilation of new instructions at runtime in a platform independent way ? 13:46:21 But that's where you lose the efficiency. The only way to get the efficiency is to cozy up to the hardware you are actually running on. Portability and efficiency are mutually exclusive. 13:46:58 Mat3: great. Then those bits of your code well be non-portable. 13:47:30 Because those instructions are non portable. 13:47:48 --- join: aranhoide (~aranhoide@25.Red-83-40-75.dynamicIP.rima-tde.net) joined #forth 13:48:37 no, there are build from vm-instruction sequences (alias streams) 13:49:26 (it just need some kind of different thinking) 13:52:54 "efficiency" is for assemblers and clock-counting: you don't tend to do it often. 13:53:40 and, yeah: I can use a Z80 and get vastly many more useful ops than the mcu's 13:55:37 beside the Z80 ISA is one of the most non othogonal ISA's I've known 13:56:16 ciao 13:56:27 --- quit: Mat3 (Quit: Verlassend) 13:56:30 I am not an orthonaught - I just know it was well organized and I DO recall counting clocks ;-) 13:58:32 Look, I'm just making a general point. Portability and machine efficiency don't go hand in hand. Both have value, depending on your mission. Most of my missions have emphasized performance. 13:59:38 yes, and yer an EE playing with fpga's - most folks are not and are not. I'm thinking about a tool, not a device.. Develop first, THEN optimize it into the grave - QC is optional. 14:01:54 So, we've swung full circle. 14:02:47 hang on 14:03:13 isn't the Z80 microcoded *anyway*? 14:04:54 I mean really, a microcoded CPU is really just a VM running on a RISC processor when you look at it the right way 14:17:00 I dunno where you got the z80 as microcoded, or he got it as non-ortho.. (Frankly, I feel Ortho is for lawns) 14:20:29 PoppaVic: the Zaks book 14:20:59 although I may not be remembering correctly 14:21:21 well, then Zaks knows more than me. I just coded for it.. It and the 6510 are the only two I ever clock-counted on, either 14:32:30 --- quit: ASau` (Ping timeout: 264 seconds) 14:33:09 --- quit: nighty^ (Quit: Disappears in a puff of smoke) 14:34:44 Jordanjp : you're right about that I guess. But in this case were talking about whether along such a layer (a second one) loretta efficiency. 14:35:03 loretta? Is she playing, too? 14:35:27 :-) 14:35:31 Swype 14:35:42 kids and their cellphones 14:35:47 Adds inefficiency 14:35:58 And Loretta can come on over... 14:36:06 Tablet. 14:36:47 And thanks - at 51 I'll take that label any way I can get it. 14:38:46 gee, yer catching up 14:41:55 :-) 14:42:08 Fighting it every step... 14:42:27 Anyway, I still think it needs a bottom-up rethink. 14:43:52 --- quit: aranhoide (Read error: Connection reset by peer) 14:45:08 --- join: ASau` (~user@p5083D20D.dip0.t-ipconnect.de) joined #forth 15:13:18 --- join: nisstyre (yourstruly@oftn/member/Nisstyre) joined #forth 15:17:00 --- join: aranhoide (~aranhoide@113.Red-83-40-73.dynamicIP.rima-tde.net) joined #forth 15:56:45 --- join: itsy (~john_metc@78.69.90.146.dyn.plus.net) joined #forth 15:56:47 --- quit: john_metcalf (Read error: Connection reset by peer) 16:00:56 --- join: ASau`` (~user@p5083D65C.dip0.t-ipconnect.de) joined #forth 16:01:00 --- join: karswell (~user@84.93.180.60) joined #forth 16:04:09 --- quit: ASau` (Ping timeout: 240 seconds) 16:04:22 --- join: Zarutian (~zarutian@194-144-84-110.du.xdsl.is) joined #forth 16:10:49 --- quit: nisstyre (Quit: WeeChat 0.4.3) 16:13:15 --- join: nisstyre (yourstruly@oftn/member/Nisstyre) joined #forth 16:34:25 --- join: john_metcalf (~john_metc@78.69.90.146.dyn.plus.net) joined #forth 16:34:26 --- quit: itsy (Read error: Connection reset by peer) 16:36:53 --- quit: john_metcalf (Read error: Connection reset by peer) 16:37:06 --- join: john_metcalf (~john_metc@78.69.90.146.dyn.plus.net) joined #forth 17:40:26 --- quit: aranhoide (Read error: Connection reset by peer) 18:07:45 --- join: kc5tja (~sfalvo@166.78.62.138) joined #forth 18:07:45 --- mode: ChanServ set +v kc5tja 18:08:21 Anyone here know of a small-size PS/2 to ASCII code converter routine? 18:08:40 My Kestrel uses one that I wrote that comes to just about 2KB, but I'm emphatically not happy with how big iti s. 18:08:43 it is even. 18:24:30 --- join: dessos (~dessos@c-174-60-176-249.hsd1.pa.comcast.net) joined #forth 18:26:10 i don't, but now i'm curious what you're talking about :) 18:40:25 he wants scancodes converted to ascii: https://docs.google.com/viewer?url=http%3A%2F%2Fwww.interak.pwp.blueyonder.co.uk%2FPDF%2F648PC_ASCII.pdf 18:51:47 --- quit: mnemnion (Ping timeout: 244 seconds) 18:55:03 --- join: mnemnion (~mnemnion@c-98-210-219-91.hsd1.ca.comcast.net) joined #forth 18:59:45 Yep. I can gather scancodes into a convenient 16-bit representation in about 7 lines of code, which is a pittance. But, investing over 1800 bytes in look-up tables is rather heavy-weight for my immediate needs. 19:00:21 PoppaVic: Thanks for the link. I'll study the code and get some ideas. 19:08:00 I remember scancodes from dos, pc's and dark-ages.. You need a lookup table for sure 19:10:38 Yeah, that I know. I have 3 LUTs in my code, one for unshifted, one shifted, and one for CTRL. But when you consider shifted+ctrl, or adding one for ALT key, it gets hokey. 19:10:56 If I can cut my LUT to just one and algorithmically derive the rest, that'd be ideal. 19:11:12 I'm just drawing a blank on how to approach the problem, and looking for inspiration. 19:12:58 --- quit: tangentstorm (Quit: WeeChat 0.3.2) 19:13:31 Do you get make and break scan codes? 19:14:30 Trivially, yes. The hardware I made has a 16-byte FIFO that captures everything the keyboard sends. 19:15:53 So you know for example that control is down because you see a make code but not a break code? 19:19:24 Yes, I already have logic to implement shift-state tracking. 19:20:56 So that is already in your FIFO items. 19:21:22 It's tracked in software, not in the FIFO. 19:22:06 Program logic goes like this: raw-PS2-i/o --> scancode-aggregator --> shift-tracker --> ASCII-conversion --> client-app. 19:22:11 (roughly) 19:22:46 The aggregator turns scancodes like $F0 $E0 $1A into $811A. 19:23:10 makes it much easier to do set membership tests (is this a break code, is it an extended keycode, etc.). 19:24:19 Bit 15 is the key up flag, and bit 8 is the extended keycode flag, if you were wondering. 19:24:50 So basically you are faced with faced with big gaps in your FIFO item numerical sequence, which means a straight full lut would be really wasteful? 19:27:24 I don't understand "big gaps in your FIFO"? 19:27:39 Ooh, sorry, I misread. 19:28:28 A single table consists of 192 16-bit values, and it's fairly sparse. 19:28:40 Having three tables around is handy and it works, but just wasteful. 19:28:51 So, yeah, confirming your understanding, I just want to cut the memory use down. 19:29:11 (Sorry, thinking out-loud. We're expecting company any moment, and I'm kind of distracted.) 19:29:47 Can you bit diddle the fifo entry to tighten up the table? 19:29:52 not sure how it's wasteful if it is used and works - imagine all the if/else if alternative code 19:33:24 101 keys.. say SH, CTL, and ALT work on all.. 303 slots - possibly bytes, maybe strings. 19:35:37 The scancodes are hardware generated, and scattered non sequentially. I need to invest 192 entries per table. 19:36:02 So, that totals 1152 bytse (3 tables of 192 16-bit words). 19:36:09 Guests are here. Gotta jet. :/ 19:36:13 Tell me more about the structure of the useful and gasp party's of the table. 19:38:14 I never did understand the idiocy behind scancodes.. Particularly when they use stupid chips over there to generate them. So, I can only hope the values represent folded state and matrix-addressing. 19:38:45 and, of course, trying to read them in linux is a pita. 19:39:41 (and everything from WM, X, and whatever - all of them filter out THEIR codes) 19:42:05 looks like you are planing to make a wm using forth as the lang? 19:42:42 nah, just commenting on the joy of hotkeys and bloody scancodes 19:43:28 --- quit: ASau`` (Remote host closed the connection) 19:51:40 --- join: ASau`` (~user@p5083D65C.dip0.t-ipconnect.de) joined #forth 19:59:15 In Linux you can put the console in "raw" mode using termios and cut all that crap out. that keys you read one stroke a time too. 19:59:34 I just slugged through ask that for my Android Forth. 20:01:14 KipIngram: btdt, but it's still painful - and of course, remember the encapsulating WM and whatnot still gets dibs. 20:14:37 WM? 20:14:54 Oh. 20:14:54 window managers 20:14:58 desktop 20:14:59 X 20:15:00 Yes. 20:15:12 they love to intercept keys I wanted ;-/ 20:15:24 :-) 20:15:58 Working ok for me. Works under the droid soft keyboards too. 20:17:16 I've got a rather effective line editor that keys me use a bunch of vim-style features when entering my Forth input. 20:17:56 not full-screen in forth?? shame! 20:17:56 I don't call that via KEY. It's a C implementation of EXPECT. 20:17:58 * PoppaVic chuckles 20:18:53 Not yet. 20:19:04 I'll that later 20:19:07 Add 20:19:49 very forthlike ;-) 20:19:51 I haven't included support the that send than one byte yet 20:20:11 Esc-[-etc. 20:20:43 Although I plan to support vim cursor movement keys. 20:21:39 And do support the j and k left right keys now. 20:22:19 Wait. It's that vim or emacs? 20:22:36 I use both these days and I forget without it open front of me. 20:24:35 it's goofy, but I expect it 20:25:43 My main goal is to able to do all the editing with the stock soft keyboard (no control key) without having to select the shifted keyboards. 20:26:11 I use the tab key to switch between entry and control modes. 20:26:43 well, if you want readline, then you want readline I use tab to tab 20:27:06 While in control mode I can use numeric prefixes, cursor motion, select insert our overwrite modes, etc. 20:27:53 The stock c deadline want to my liking, and I do want to have KEY add well. 20:28:08 Readline requires the enter key. 20:28:23 Readline wasn't 20:29:04 KEY is supposed to return soon you hit a key, not when you hit enter. 20:29:42 yes, I am well aware 20:30:17 and KEY? is your look-ahead 20:30:26 For some reason getchar wouldn't work in my environment. 20:30:52 and you will eventually fight the escapes-of-Fkeys, etc 20:31:01 Link error. Seems to be a known bug in android gcc, but that dodgy help me solve my problem. 20:31:18 I have a plan for that. 20:31:31 Haven't implemented it yet, though. 20:31:44 No f keys on the soft keyboard. 20:32:29 I want this to be nicely usable without a hard keyboard. 20:35:22 yer talking about yer "screenboard" flop (onscreen kbd emulation) 20:35:33 Yeah. 20:56:10 --- quit: nisstyre (Quit: WeeChat 0.4.3) 21:10:43 --- join: tangentstorm (~michal@108-218-151-22.lightspeed.rcsntx.sbcglobal.net) joined #forth 21:33:05 --- join: asie (~textual@5.174.90.98) joined #forth 21:48:34 --- nick: ASau`` -> ASau 21:53:22 --- part: asie left #forth 22:09:46 --- quit: dessos (Quit: ChatZilla 0.9.90.1 [Firefox 22.0/20130618035212]) 22:11:24 --- join: asie (~textual@5.174.90.98) joined #forth 22:16:36 --- quit: Zarutian (Quit: Zarutian) 22:21:20 --- quit: PoppaVic (Quit: Leaving) 22:28:02 --- quit: asie (Quit: I'll probably come back in either 20 minutes or 8 hours.) 23:11:48 Well, that was fun. 23:12:00 Of course, now it's time for sleep. 23:14:58 KipIngram: I'm not sure what I can say about the gaps; any PS/2 Scanset 2 reference will illustrate the scancodes and their relationships with the keys on the keyboard. 23:15:21 They do represent, in theory at least, the original PS/2 matrix addresses for the keys. 23:28:35 kc5tja: does the scancode converter need to support just us qwerty or arbitrary keymaps? 23:51:38 --- join: true-grue (~quassel@128-68-48-48.broadband.corbina.ru) joined #forth 23:59:59 --- log: ended forth/14.02.26