2023-11-24 03:22:37 <veltas      > 6502 is a good forth architecture IMO
2023-11-24 03:44:35 <koisoke     > just because one can put the stack(s) in the zero page? that's nice but it ties up the X register which you kind of need for other things
2023-11-24 03:45:12 <koisoke     > i mean, i once considered this and came to a conclusion of, not really :/
2023-11-24 03:49:15 <dave0       > i think there's an addressing mode     (n),y    where n is 0...ffh ?
2023-11-24 03:49:49 <dave0       > and it fetches a 16 bit word from the zero page and adds y to it?
2023-11-24 03:51:08 <dave0       > would it work if say you put the stack at 200h-2ffh and in the zero page you have   200h 201h 202h 203h   so you can indirect through those pointers directly into the stack at 200h-2ffh
2023-11-24 03:51:28 <dave0       > it would use y as the stack pointer
2023-11-24 03:52:06 <olle        > \o
2023-11-24 03:57:56 <olle        > Forth word of the day? M*
2023-11-24 03:58:10 <dave0       > say    10h: 0200h 0201h 0202h 0203h    then lda (10h),y would get the top of stack lda (12h),y would get the second byte on the stack lda (14h),y the third and lda (16h),y the fourth
2023-11-24 03:59:11 <dave0       > you could "move" the stack by changing 10h-17h
2023-11-24 05:54:20 <user51      > olle: What about a forth sentence of the day
2023-11-24 06:08:10 <olle        > user51: One is supposed to read snippets demonstrating the usage of the word ^^'
2023-11-24 06:08:21 <olle        > Read/write/generate with LLM
2023-11-24 06:55:17 <KipIngram   > I still think the most "novel" Forth architecture I've seen so far is the one dave0 was using when he first arrived.  Direct threaded, next operation is just the ret instruction.
2023-11-24 06:55:53 <KipIngram   > On x86, but it would work on any platform that uses a separate stack for interrupts.
2023-11-24 07:17:55 <clemens3    > which forth is the easiest to build and install, just classical ./configure && make && make install?
2023-11-24 07:54:18 <KipIngram   > You can usually install gforth from your package manager, if it's not already present in your distro.  As far as building from source goes, i found pforth easy to compile, but I worked with it a very long time ago.
2023-11-24 08:07:23 <veltas      > clemens3: gforth 0.7.3 is relatively easy to build
2023-11-24 08:07:31 <veltas      > Later gforth needs gforth to build I think
2023-11-24 08:07:49 <veltas      > It's worth building later gforth though because there are many more features
2023-11-24 08:08:24 <veltas      > I think gforth 0.7.3 is probably something similar to the sort of autotools scenario you described
2023-11-24 08:08:40 <veltas      > Has a few dependencies common to distros
2023-11-24 08:37:27 <veltas      > olle: Example of M* https://pastebin.com/raw/zbMCq5Zr
2023-11-24 08:37:49 <veltas      > I wrote this previously to demonstrate linear regression with fixed point arithmetic
2023-11-24 08:37:58 <veltas      > I've run this on my ZX Spectrum and it runs quite nicely
2023-11-24 08:41:15 <KipIngram   > That looks nice, veltas.
2023-11-24 08:41:30 <veltas      > Thanks
2023-11-24 08:42:27 <veltas      > I know you don't like "C-style" forth and that's more on the C end
2023-11-24 08:42:38 <KipIngram   > I'm interested in trying to push the boundaries with fixed point as well.  I'm particularly interested in trying out a projective geometry version of it; that lets you use the extra coordinate to clear denominators, so you are actually getting a sort of "rational number" version of things while manipulatng only integers.
2023-11-24 08:42:46 <veltas      > But it's made up for by the fact it runs on an 8-bit CPU :P
2023-11-24 08:42:52 <KipIngram   > no idea how that will go.
2023-11-24 08:43:11 <KipIngram   > 8-bit gadgets are fun.
2023-11-24 08:44:10 <KipIngram   > Well, yes - I usually don't go for the C style, but I do like how you integrated your stack effect comments.
2023-11-24 08:44:30 <KipIngram   > I just find it particularly readable.
2023-11-24 08:44:42 <veltas      > Yeah it's a bit of a hybrid
2023-11-24 08:44:54 <veltas      > If the stack comments get too complicated I just refactor
2023-11-24 08:45:06 <KipIngram   > And I do pay a price for the way I code - I wind up with quite a lot of call overhead.
2023-11-24 08:45:28 <KipIngram   > At least Forth is very efficient on calls, but... that overhead is still "there."
2023-11-24 08:47:28 <veltas      > This is a bit much IMO https://github.com/MitchBradley/openfirmware/blob/master/forth/lib/crc32.fth#L72
2023-11-24 08:47:34 <veltas      > That's at my limit for stack depth
2023-11-24 08:48:09 <KipIngram   > :-)
2023-11-24 08:48:14 <veltas      > https://github.com/MitchBradley/openfirmware/blob/master/forth/lib/pattern.fth
2023-11-24 08:48:15 <KipIngram   > Yeah, that doesn't appeal to me much.
2023-11-24 08:48:26 <KipIngram   > But I see an awful lot of stuff similar to that out there.
2023-11-24 08:49:04 <veltas      > It's when people just give up and write as if they have locals
2023-11-24 08:49:19 <veltas      > If you're going to write forth code like that then you may as well just use a locals library
2023-11-24 08:49:26 <veltas      > And write untyped C
2023-11-24 08:49:31 <veltas      > Untyped RPN C
2023-11-24 08:51:26 <olle        > veltas: *clap*
2023-11-24 08:52:26 <veltas      > And this demonstrates one reason I like Forth olle, that I can write the same code on a desktop inside an old 8-bit computer and have it compile on that machine and run
2023-11-24 08:52:50 <veltas      > And it runs well, my Forth on ZX Spectrum isn't *that* fast but it's still mostly faster than the BASIC that's built in
2023-11-24 08:53:31 <KipIngram   > +1 on faster than BASIC.
2023-11-24 08:53:56 <KipIngram   > Plus it just feels somehow "closer to the metal" to me.
2023-11-24 08:54:36 <KipIngram   > That may be something I just "imagine," though, based on the fact that I know how it's working under the hood.
2023-11-24 08:57:15 <veltas      > Forth is more of a nice middleground between an assembler and a higher level language like the BASIC on the Spectrum
2023-11-24 08:57:31 <veltas      > And Forth is also an assembler on many systems
2023-11-24 09:00:18 <olle        > _and_ you can run the same code on a modern 64-bit system :)
2023-11-24 09:00:25 <KipIngram   > Yes.  It can offer assembly level access (literally sometimes), but still can be "elevated" to something much more abstract.
2023-11-24 09:01:00 <KipIngram   > I love that aspect - it "feels the same" all the way up and down that ladder.
2023-11-24 09:30:54 <thrig       > 16-bit real can be tricky to get to in some cpu
2023-11-24 09:31:50 <KipIngram   > https://shorturl.at/nvHOP
2023-11-24 09:34:05 <veltas      > thrig: What do you mean?
2023-11-24 09:36:14 <thrig       > ... The issue is that AMD64/Intel64 CPUs have multiple modes, and the fastest 64-bit enhanced mode drops support for 16-bit code ...
2023-11-24 09:37:02 <veltas      > Oh well the same code can run on 64-bit, with potentially larger integers
2023-11-24 09:37:13 <veltas      > But that code I posted earlier I've tested on both 16-bit and 64-bit forths
2023-11-24 10:24:50 <Zarutian_iPad> 
ACTION is staring at pdf page 77 of http://archive.retro-kit.co.uk/bbcdocs.com/filebase/econet/Econet%20Advanced%20User%20Guide.pdf trying to figgure out how the thing works

2023-11-24 10:27:35 <Zarutian_iPad> what I have figgured out so far is this Econet (basically a LAN for Acorn, BBC Micro, and others) is using diffrential manchester encoding or something similiar
2023-11-24 10:29:00 <Zarutian_iPad> the XLR or DIN looking connector indicates daisy chaining (plus what I heard/read elsewhere on how Econet was hooked up)
2023-11-24 10:29:45 <clemens3    > veltas: thanks, also for the detail
2023-11-24 10:36:57 <veltas      > No problem
2023-11-24 11:02:11 <KipIngram   > That looks pretty involved, Zarutian_IPad.
2023-11-24 11:02:47 <KipIngram   > What does IC89 do?
2023-11-24 11:03:11 <KipIngram   > Manchester coding is self-timed, iirc.
2023-11-24 11:04:29 <KipIngram   > I guess IC95 and C23 are part of the clock extraction?
2023-11-24 11:05:20 <KipIngram   > Maybe IC87.
2023-11-24 11:06:52 <KipIngram   > My recollection of Manchester is that every clock edge will have a signal edge matching it, and then the data value is based on whether or not there is an intervening edge.
2023-11-24 11:07:13 <Zarutian_iPad> nope I was mistaken
2023-11-24 11:07:40 <KipIngram   > So the direction of the data edges can flip back and forth based on the data pattern.
2023-11-24 11:07:59 <Zarutian_iPad> there is diffrential encoding like for analog XLR
2023-11-24 11:08:23 <Zarutian_iPad> but the clock and data lines are seperate
2023-11-24 11:09:33 <Zarutian_iPad> the left side of the din plug is d+ and d- whilist the right side is clk+ and clk-
2023-11-24 11:10:48 <Zarutian_iPad> so it is a bit like an old style coax ethernet
2023-11-24 11:10:50 <KipIngram   > looks a little odd - if I trace the RXD input to IC89 back to the connector, it looks like it's also being driven by IC93.
2023-11-24 11:12:09 <KipIngram   > Maybe IC93 is tri-state?
2023-11-24 11:12:22 <KipIngram   > Mabe pin 9 turns it on and off?
2023-11-24 11:12:51 <Zarutian_iPad> it might be. I have not looked up its partnr which is 75159
2023-11-24 11:14:17 <Zarutian_iPad> but I am quite mistified by the resistor network between the clock and data lines
2023-11-24 11:14:49 <KipIngram   > Yeah, it's some kind of control:
2023-11-24 11:14:51 <KipIngram   > https://www.ti.com/lit/ds/symlink/sn75189.pdf?ts=1700842446889&ref_url=https%253A%252F%252Fwww.ti.com%252Fproduct%252FSN75189
2023-11-24 11:15:05 <Zarutian_iPad> R45, R51, R34, R35 and that RC circuit
2023-11-24 11:15:39 <KipIngram   > Yeah.
2023-11-24 11:16:11 <Zarutian_iPad> impedience/level adjustment is my guess
2023-11-24 11:16:23 <KipIngram   > Is it designed to define a middle voltage beween the high and low line levels?
2023-11-24 11:16:30 <KipIngram   > A threshold, auto-generated?
2023-11-24 11:17:08 <Zarutian_iPad> nope, not as I see it
2023-11-24 11:17:30 <KipIngram   > Looks like they saw fit to specify precision on those 10k resistors.
2023-11-24 11:18:38 <KipIngram   > And there's a low pass filter there, via R48/C18.
2023-11-24 11:19:09 <Zarutian_iPad> yebb it looks it is to eliminate electro interference from induced currents
2023-11-24 11:20:22 <KipIngram   > I don't see "exactly" what it's doing yet either, but it has a "reasonable seeming sense" to it.
2023-11-24 11:20:50 <KipIngram   > It's somehow helping with common mode rejection or something along those lines.
2023-11-24 11:21:10 <KipIngram   > Has a nice symmetry, at least.
2023-11-24 11:26:33 <KipIngram   > Some of those really low-level protocols are quite fun.
2023-11-24 11:26:56 <KipIngram   > Generally you're going for something that will "work in spite of all kinds of crap mixed in."
2023-11-24 11:28:17 <KipIngram   > I first ran across Manchester way back in the early 1980's when I did a coop tour with General Dynamics.  The F16 used Manchester all over the place in its avionics.
2023-11-24 11:28:43 <KipIngram   > I was a total noob at the time and it seemed like black magic.
2023-11-24 11:29:36 <KipIngram   > later on another thing that gave me the same "sense of magic" was sigma-delta modulation.  I swear that one felt like getting something for nothing for sure.
2023-11-24 11:37:37 <KipIngram   > That voltage divider (R47/R48) is a good bit stiffer than those 10k resistors, so that's going to give you 2.5V on that net.  Looks to me like the point is to ensure IC94 pins 4 and 5 and IC94 pins 9 and 10 are centered on 2.5V.
2023-11-24 12:17:28 <Zarutian_iPad> KipIngram: yebb you are quite correct
2023-11-24 12:18:09 <Zarutian_iPad> btw delta sigma encoding with variable step size is pretty neat
2023-11-24 12:18:53 <Zarutian_iPad> basically the step size increases with every one in a row
2023-11-24 12:19:15 <Zarutian_iPad> (same with zeros in a row)
2023-11-24 12:20:32 <Zarutian_iPad> but delta sigma encoding using an up down counter R2R ladder for dac and a fast comparitor is mind blowingly simple
2023-11-24 12:20:56 <Zarutian_iPad> no clocking or sync required
2023-11-24 12:22:35 <Zarutian_iPad> btw I am trying to recall what CTS in serial and modem to computer signaling stood for
2023-11-24 12:23:54 <Zarutian_iPad> it is on IC89
2023-11-24 12:25:07 <Zarutian_iPad> piff Clear To Send
2023-11-24 12:27:06 <Zarutian_iPad> which means if some other station is on the line then this one can not transmit
2023-11-24 13:11:00 <KipIngram   > I ran into sigma delta at the seismic company.  Our data recorders only need a couple hundred Hz bandwidth, so we traded off bandwidth against resolution.  Wound up getting 24-bit samples.  Resolution was so high that it was a major challenge for a really good analog guy to get everything quiet enough to keep the noise floor down below the resolution.
2023-11-24 13:11:19 <MrMobius    > re 6502 forth, the X register is the way to go
2023-11-24 13:11:49 <MrMobius    > the lda (foo),y addressing is slow since you need to fetch two bytes of address from memory and add y to it
2023-11-24 13:12:41 <MrMobius    > it's more than twice as fast to use X and address zero page since it can take a 8 bit address
2023-11-24 13:13:04 <MrMobius    > also losing the X register is not so bad compared to the Y register which has the more interesting addressing mode
2023-11-24 13:14:32 <KipIngram   > I've wound up defining Forth system pertinent functions for practically all of the x86_64 registers.  It used to bug me, but these days I figure they're there - it's good to have a worthwhile use to put them to.
2023-11-24 13:15:58 <KipIngram   > What DOES bug me a little is that the x86 doesn't have "push all" and "pop all" instructions.
2023-11-24 13:22:52 <zelgomer    > there are a lot of reasons to be irritated at the x86 instruction set
2023-11-24 13:25:36 <KipIngram   > That's the truth.
2023-11-24 13:25:47 <KipIngram   > Fortunately Forth really only needs a subset of it.
2023-11-24 13:26:18 <KipIngram   > I wrote up an "assembler" for most of the really necessary stuff in just a day or two last year.
2023-11-24 13:26:46 <KipIngram   > I didn't cover everything important - there were still a few things left to do.
2023-11-24 13:27:17 <KipIngram   > And I only covered the 64-bit type of the stuff I did cover; didn't have any 32, 16, or 8 bit operations, and those are necessary too.
2023-11-24 13:27:49 <kws         > i prefer the load-store architectures its a lot easier for my brain to do instruction selection because its more uniform
2023-11-24 13:28:09 <KipIngram   > A nice orthogonal instruction set is a beautiful thing.
2023-11-24 13:29:26 <KipIngram   > Of all the ones I've worked directly with the 6809 was my favorite.
2023-11-24 13:29:56 <KipIngram   > I could pretty much disassemble 6809 code in my head.
2023-11-24 13:30:14 <MrMobius    > maybe im crazy but i really like the [base+reg*size+offset] addressing in x86
2023-11-24 13:30:25 <Zarutian_iPad> I detest it
2023-11-24 13:30:26 <kws         > well i mean uniformity of the instruction set and the instruction *encoding* are two different things
2023-11-24 13:30:31 <kws         > but i get your idea
2023-11-24 13:31:14 <MrMobius    > I know it can be recreated with a handful of other instructions on a risc architecture but I would rather just have it built in
2023-11-24 13:31:20 <KipIngram   > That addressing mode supports a particular vm setup quite well.
2023-11-24 13:31:27 <MrMobius    > since the purpose of cisc after all is to make it easier for a human to write
2023-11-24 13:31:28 <Zarutian_iPad> MrMobius: why? because it is actually doing four operations in one instruction
2023-11-24 13:31:59 <MrMobius    > Zarutian_iPad: because i often do those four operations or at least 3 of them in a lot of code. it saves a lot of typing
2023-11-24 13:32:14 <KipIngram   > At the current time I tend to feel a more positive vibe for CISC vs. RISC, but that's probably it's just what I'm familiar with right now.
2023-11-24 13:32:44 <KipIngram   > the 'simple is good' part of me does like the RISC idea.
2023-11-24 13:32:52 <MrMobius    > you can set up a pointer on risc then keep incrementing it by type size, but x86 also has the advantage that you can adjust the index register without having to recalculate. it's just less headache
2023-11-24 13:37:15 <kws         > speaking of, i've seen some examples given of forth assemblers that follow the 'manual' style syntax with opcodes on the left, e.g. 'add r0 r0 1'
2023-11-24 13:37:32 <kws         > it's easy to see how 'r0 r0 1 add' would work, but whats the trick for the manual style? reversing the stack?
2023-11-24 13:37:49 <GeDaMo      > add could do the parsing
2023-11-24 13:37:51 <Zarutian_iPad> MrMobius: that is what good macto assemblers are for
2023-11-24 13:38:11 <kws         > GeDaMo: ah good point, thanks
2023-11-24 13:38:12 <Zarutian_iPad> that is, to ease typing
2023-11-24 13:54:57 <MrMobius    > Zarutian_iPad: sure, I use tons of macros. they limit optimization though which you probably care about if you're writing assembly
2023-11-24 13:55:32 <MrMobius    > since the macro cant recognize for example that an existing register already has what you need so you should just reuse part of it
2023-11-24 14:11:53 <Zarutian_iPad> a good macro assembler has factilities for this but I get your point
2023-11-24 15:00:16 <zelgomer    > opinions on condition/control flow flag separate from the stack?
2023-11-24 15:04:58 <KipIngram   > I've strained over that one.  So far I've not actually tried it, but i'm constantly thinking about it.
2023-11-24 15:05:39 <KipIngram   > These days I have my choice of test integrated into the primitive that transfers control, so it kind of has to have data on the stack to check.  So it may not come up for me again.
2023-11-24 15:07:12 <KipIngram   > It might be useful to have a separate flag for things like overflow testing, but in a lot of cases you probably produced the flag by *testing* something on the stack, rather than as a side effect of operating on it.
2023-11-24 15:07:44 <KipIngram   > I think when the decision criterion is a side effect, separate from the data resulting from the operation, then a flag probably makes sense.
2023-11-24 15:08:13 <KipIngram   > On the other hand, having zero on the stack and then running a word to set a zero flag if it's zero?  I'm not sure that buys you anything.
2023-11-24 15:08:48 <KipIngram   > So, I guess my answer is that there might be multiple classes of situations.
2023-11-24 15:10:25 <zelgomer    > that's true.   a b c */ if .. then  mandatorily becomes  a b c */ 0= if .. then
2023-11-24 15:11:10 <KipIngram   > yeah.  I'd never thought of the "side effect vs. direct" thing; it feels like a worthwhile insight.
2023-11-24 15:13:36 <KipIngram   > I may think about having that sort of overflow support in my next system.  I am interested in having some kind of "bignum" support, and it would probably fit well with that.
2023-11-24 15:14:53 <KipIngram   > Though as I mentioned earlier, I've pretty much used up all of the registers - not sure I'd have any place to put such flags.
2023-11-24 16:45:27 <zelgomer    > is there a stack effect convention for when a word takes a parameter from execution stream? i forgot
2023-11-24 18:22:05 <KipIngram   > I don't know one.  Most places I am aware of just describe what happens verbally.
2023-11-24 18:22:57 <KipIngram   > It does seem like something reaosnable.  Maybe something like  "( in in -- out)  << word
2023-11-24 18:23:18 <KipIngram   > oh, well, I guess you'd want the ) at the very end.
2023-11-24 18:28:28 <zelgomer    > i guess words like this are usually hidden implementation details compiled by immediate words, so there's not as much need to document it
2023-11-24 18:30:29 <KipIngram   > In that case they wouldn't need a name.  They only need a name if they're intended to be used by the user, and if that's the case they ought to be documented.
2023-11-24 18:40:49 <zelgomer    > how do you compile a word with no name barring quotations?
2023-11-24 18:44:57 <crc         > :noname … ;
2023-11-24 18:55:59 <zelgomer    > ic