2023-07-18 04:56:21 <veltas      > Compile times need to not slow the developer down, but they don't need to be 100MB/s!
2023-07-18 08:41:39 <KipIngram   > Agreed - I think Jim just got on a sort of "kick" on that front at the time.  He does tend to be a bit of an "optimizer" at times.
2023-07-18 08:43:20 <KipIngram   > It wasn't just compile speed he was thinking about - along with it he was pushing for minimal source size, all the way up to using his own custom encoding to replace ASCII.  It's been a while since I read about all that, but I think it also involved almost a form of "pre-compilation," where native built in words were represented in the source code by tokens that could almost just be copied into the compiled
2023-07-18 08:43:22 <KipIngram   > output rather than having to be "looked up."
2023-07-18 08:43:47 <KipIngram   > I think he really only "compiled" (in the traditional sense) new words added by himself to his design.
2023-07-18 08:44:33 <KipIngram   > And he also didn't have to look words up more than once - once a new word was "compiled" the first time, he sort of cached that information and further references to the word didn't require another lookup.
2023-07-18 08:45:40 <KipIngram   > I tried to follow that path on one of my designs, but I decided there were issues with it given the way I wanted my system to work.  I always had the feeling that his methods worked well only in fairly focused, single-application work.
2023-07-18 08:45:58 <KipIngram   > Part of Chuck's "solve the problem at hand and nothing more" mind set.
2023-07-18 08:48:04 <drakonis    > extreme optimization for single domain work
2023-07-18 08:48:13 <drakonis    > not much in the way of general development
2023-07-18 08:51:15 <KipIngram   > Yes, exactly.
2023-07-18 08:51:55 <KipIngram   > It was a pretty interesting set of ideas; just not really suitable for what I usually try to do.
2023-07-18 08:52:16 <KipIngram   > It's all somewhere in all those Ultra Technology documents Jeff Fox spewed out back in the day.
2023-07-18 09:14:28 <KipIngram   > I particularly don't really see the point in doing a lot of work to "compress" the source.
2023-07-18 09:14:58 <KipIngram   > But there was less RAM and less storage and slower processors back in those days, so I guess I'm not "calibrated" the same way Chuck was.
2023-07-18 09:17:49 <Zarutian_iPad> what I have gathered is that these restrictions now mainly apply to implementations in MPC and zkSNARK and not usual PCs
2023-07-18 09:18:36 <Zarutian_iPad> and similiarly these restrictions apply with the smallest and cheapest MCUs
2023-07-18 09:18:44 <KipIngram   > Right, I guess they can still be pertinent in small systems.
2023-07-18 09:35:16 <KipIngram   > The way Fox described all of that in general was to say it involved pushing work from run time to compile time, and where possible from compile time to edit time.  So the editor was "very smart" and did a lot of preprocessing on the written code.
2023-07-18 09:35:38 <gordonjcp   > KipIngram: in the olden days of tokenised BASIC we used to do stuff like write "LET A=SIN PI" instead of "LET A=0" because "SIN PI" tokenised to two bytes, and numeric constants were stored as five bytes
2023-07-18 09:35:53 <KipIngram   > :-)
2023-07-18 09:36:08 <KipIngram   > A bit like defining 0 and 1 and friends as Forth words.
2023-07-18 09:36:47 <gordonjcp   > yup
2023-07-18 09:37:27 <gordonjcp   > although if you're really going for it you define "common" constants like that as machine-code primitives
2023-07-18 09:38:31 <KipIngram   > Anyway, in any case where the final generated code could be known even at edit time Chuck just stored that compiled result so that it could just be copied from source into the dictionary later.  Which meant that the editor had to be able to de-compile it for rendering it on the screen.
2023-07-18 09:39:18 <KipIngram   > There's a quote from Chuck out there somewhere that was a bit of a "mea culpa" - it came later and he acknowledged that certain parts of the experimentation he'd been trying out had mostly failed.
2023-07-18 09:39:27 <KipIngram   > He threw some of those ideas out later.
2023-07-18 09:40:43 <KipIngram   > veltas equated Forth to art yesterday - in that same general way it's like Chuck was an "explorer" - going out into unknown territory and seeing what he could find.
2023-07-18 11:02:46 <veltas      > Cheapest MCU's aren't suitable for full Forth, probably fine for cross forth targets though
2023-07-18 11:03:06 <veltas      > Cheapest ones I see at the moment are about 512 bytes of RAM
2023-07-18 11:03:56 <veltas      > You really do not need to spend much to get a lot more than that, recall the £1 MCU I was mentioning other day which has like 128K or more RAM
2023-07-18 11:04:46 <veltas      > Those cheapest MCU's are for some insanely massive production scale or where they already developed a solution for a PIC and can't be bothered to change it
2023-07-18 11:14:56 <KipIngram   > That's kind of how I've always felt about it.  Yes, there are chips that are so tiny as to be impractical, but for almost no money more you can get ones that will let you do everything.  So I've never seen the point in limiting things so much.
2023-07-18 11:15:22 <veltas      > Power requirements for small scale, or massive production scale
2023-07-18 11:15:37 <veltas      > Or just a sense of elegance maybe
2023-07-18 11:15:55 <veltas      > I would never program a small MCU like that in anything other than assembly
2023-07-18 11:15:59 <thrig       > not as clumsy and random as a soundblaster
2023-07-18 11:16:02 <KipIngram   > Sure - if you're doing mass production of something that desperately needs to be as cheap as possible - that's what those are for.
2023-07-18 11:16:05 <veltas      > thrig: :)
2023-07-18 11:16:19 <KipIngram   > But there's not a lot of point in a hobbiest subjecting himself to that.
2023-07-18 11:16:31 <veltas      > You could say that about Forth
2023-07-18 11:16:35 <KipIngram   > Of course,  "because you want to" is a perfectly good reason.
2023-07-18 11:16:53 <KipIngram   > Well, *I* couldn't, but yeah - some people would feel that way.
2023-07-18 11:17:03 <KipIngram   > Forth more than pays its freight, as far as I'm concerned.
2023-07-18 11:17:07 <veltas      > I don't know the power specs but I'm assuming some of them use barely any power
2023-07-18 11:17:33 <veltas      > If you've got some battery powered device or something... I'm clutching at straws but I'm sure there are some valid reasons
2023-07-18 11:18:05 <veltas      > With the transistor count and low clock speed I'd imagine they're very low power usage
2023-07-18 11:18:17 <veltas      > But of course it's not that simple (is it???)
2023-07-18 11:32:29 <KipIngram   > I'm not sure - we'd have to assess the field of available products to know.
2023-07-18 11:33:03 <KipIngram   > Certainly I think some of those really low end uC's might "work fine" in some hobby applications, but I'd be surprised if there wasn't a more capable device that would work "equally fine."
2023-07-18 11:54:24 <Zarutian_iPad> I can probably chime in on this.
2023-07-18 11:55:13 <Zarutian_iPad> MCUs I classify in five sizes or so
2023-07-18 11:55:15 <KipIngram   > I've got an aquaintance who was into the idea of building his own ecig unit.
2023-07-18 11:55:37 <KipIngram   > And he was fairly obsessed with using the absolute rock bottom cost processor he could, and was questing for tethered Forth systems and so on.
2023-07-18 11:56:12 <Zarutian_iPad> smallest is probably barely above simple statemachines and push down automata
2023-07-18 11:56:29 <KipIngram   > Just personally, I think I'd rather spend an extra buck or two and use something that could actually host a Forth.  Just because it's easier.
2023-07-18 11:57:08 <thrig       > kungfu action ken might not need that extra dollar
2023-07-18 11:57:28 <Zarutian_iPad> this smallest can even be run via rfid nfc radio energy from the reader
2023-07-18 11:58:27 <Zarutian_iPad> basically the ATTINYs or PIC12 or below
2023-07-18 12:00:19 <Zarutian_iPad> next up is the pic16 and maybe ardunio uno, though the latter is to me at least a bit bigger than PIC16
2023-07-18 12:00:44 <Zarutian_iPad> then we got arduino mega and co
2023-07-18 12:01:18 <Zarutian_iPad> next up is the ARM Cortex ones
2023-07-18 12:02:10 <Zarutian_iPad> where you can start to run things like busybox and such
2023-07-18 12:02:36 <Zarutian_iPad> raspberry pi zero is in this size category
2023-07-18 12:03:08 <Zarutian_iPad> and the biggest size is basically modern smartphone soc things and equiv
2023-07-18 12:03:25 <KipIngram   > Where do you get at least 16k of RAM?
2023-07-18 12:04:14 <Zarutian_iPad> trying to remember, Arduino mega and little bit bigger?
2023-07-18 12:06:15 <Zarutian_iPad> KipIngram: what does an ecig do with an mcu? temp control of the heating coil and other such?
2023-07-18 12:06:42 <KipIngram   > Yeah - you can run them in fixed power mode, fixed temp, etc.
2023-07-18 12:06:57 <KipIngram   > There are a variety of "modes" that can be chosen.
2023-07-18 12:07:06 <KipIngram   > And of course you can adjust power or temp level etc.
2023-07-18 12:08:14 <KipIngram   > I'm not trying to claim that a uC that CAN'T host a Forth COULD run something like that - I have no doubt that's true.  I'm just contending that I could probably find myself a Forth hosting capable device for the task that wouldn't cost me much more money.
2023-07-18 12:11:12 <Zarutian_iPad> it depends on other factors like manifacturability, per unit cost margins and other such
2023-07-18 12:13:05 <Zarutian_iPad> that multi purpose mcu you linked to seem quite usefull
2023-07-18 12:13:38 <KipIngram   > Yes, those are concerns in manufacturing situations.  I don't think they matter quite so much for hobby work.
2023-07-18 12:14:20 <Zarutian_iPad> hobby stuff I go more in the direction of how satelites are designed
2023-07-18 12:15:04 <Zarutian_iPad> reliability, reconfigurability, and maybe not the same level of redundancy
2023-07-18 12:16:35 <KipIngram   > If you're going to make a million of something then it's worth working harder and putting up with more difficulties to get the absolute minimal cost.  For hobby work it's almost always best to try to make your development path simpler and faster.
2023-07-18 12:16:50 <KipIngram   > And make it fun, as much as possible.
2023-07-18 12:17:33 <KipIngram   > You mentioned something I linked - were you referring to that little Nordic Semiconductor chip?
2023-07-18 12:17:46 <KipIngram   > I like that guy quite a lot.
2023-07-18 12:18:02 <Zarutian_iPad> yebb
2023-07-18 12:21:39 <veltas      > KipIngram: Just search MCU's on an electronics website and filter by RAM size
2023-07-18 12:26:55 <MrMobius    > You can get 64 bytes of ram if you really wanna be ultra minimal
2023-07-18 12:27:18 <MrMobius    > Apparently some AVRs have no ram since 32 registers is enough in some cases
2023-07-18 12:27:55 <thrig       > memory of a goldfish
2023-07-18 12:36:59 <KipIngram   > I guess what I'm trying to get at is the minimal amount of money you need to spend for a device that can host a Forth.  Just interested in knowing what that price point is.
2023-07-18 12:37:16 <KipIngram   > It's under $10, because that Nordic chip is $10, and it would do it handily.
2023-07-18 12:46:07 <KipIngram   > I can't really imagine doing a hobby project I wouldn't be willing to invest $10 in for a controller.  That's exactly why I *do* like that gadget so much - it looks very appropriate for a "universal controller" for whatever I might decide to do.
2023-07-18 12:46:24 <KipIngram   > I'd go to something beefier only if I needed serious compute power.
2023-07-18 12:47:24 <drakonis    > https://www.youtube.com/watch?v=mZyvIHYn2zk this talk is a 10/10
2023-07-18 12:47:44 <drakonis    > the title is a reference to a zizek thing
2023-07-18 12:48:38 <KipIngram   > Heh.
2023-07-18 12:50:52 <drakonis    > factor spotted
2023-07-18 13:12:10 <KipIngram   > So, if I use six-bit opcodes in this design, then I can fit five of them into a 32-bit instruction word, with two bits left over.  Getting 0b000000 will be what sends the thing to the subsequent instruction word, so the 0b00 case for those high two bits is taken.  But that leaves three opcodes: 0b000001, 0b000010, and 0b000011, which can be stored as a sixth opcode in a cell.
2023-07-18 13:15:13 <KipIngram   > Probably won't work out in most cases that I'd happen to need one of those three opcodes in the right spots, but it's a zero cost feature.
2023-07-18 13:15:37 <KipIngram   > Well, not zero.  Just a quick check to see if it happens to apply.
2023-07-18 13:28:44 <KipIngram   > I just have to make sure I do a logical right shift and not an arithmetic one, so that regardless of what those high bits are 0's get shifted in.
2023-07-18 13:29:49 <KipIngram   > Probably should assign the most frequently executed opcodes (that don't need any argument in the remainder of the instruction word) to those codes, to maximize the probability of getting to do that optimization.
2023-07-18 13:59:25 <MrMobius    > I think price is sometimes sensitive for hobbyst if they do a short run of kits on Tindie for example
2023-07-18 13:59:57 <MrMobius    > But otherwise ya who cares in qty 1
2023-07-18 14:08:08 <KipIngram   > With that Nordic chip, what I kind of picture is having one of those, with a Forth OS on it, on pretty much everything I'd make.  Then I'd want an interface program on my notebook that would connect to them via Bluetooth.  Start that program up and it would just sniff around and show a list of every device it saw in the vicinity.  I'd be able to open console windows on any of those I wanted to and poke around
2023-07-18 14:08:10 <KipIngram   > with them.
2023-07-18 14:08:33 <KipIngram   > They'd be aware of one another as well, and capable of passing data around among themselves.
2023-07-18 14:10:13 <KipIngram   > I guess I'd want that so that threads on two separate units would communicate in exactly the same way two threads on one unit would - it just wouldn't make any difference.
2023-07-18 15:07:17 <veltas      > Honestly if I had a problem that fit in 512 bytes I'd consider one of those small PICs, if it's cheaper or better power usage
2023-07-18 15:07:43 <veltas      > It's the same kind of logic as when I keep my programs smaller even though I technically have a whopping 2GB of RAM
2023-07-18 15:08:27 <veltas      > If everyone had that logic then I'd only be able to run a couple of programs at a time, but fortunately I can run many programs at once
2023-07-18 15:09:29 <veltas      > And lots of controller programs can run with 512 bytes of RAM. That's what... 128-512 registers. What do you need all those registers for?
2023-07-18 15:21:22 <veltas      > Come on, tell me I'm not the only person who uses a larger font size with Forth?
2023-07-18 15:32:59 <KipIngram   > I don't, actually.  I just use the smallest font that I can read easily.  Right now that's Go Mono 12 point.
2023-07-18 15:33:17 <KipIngram   > Are you talking about "Chuck size" fonts?
2023-07-18 15:34:45 <KipIngram   > And your points are all good there - part of my feelings about it all may be that I don't actually anticipate making super simple gadgets.  Most of the stuff I think about would be more complex.  Things like radio transceivers, instruments of various kinds, etc.
2023-07-18 15:58:17 <gordonjcp   > well, radio transceivers can be pretty simple
2023-07-18 15:58:36 <gordonjcp   > I've done it with a single transistor and a handful of inexpensive passive components before
2023-07-18 16:03:42 <KipIngram   > I'd be thinking in terms of a digitally tunable software transceiver, maybe with internal antenna matcher.
2023-07-18 16:04:07 <KipIngram   > adjustable power output.
2023-07-18 16:06:48 <veltas      > KipIngram: https://i.imgur.com/elnSA1D.png
2023-07-18 16:23:54 <KipIngram   > https://imgur.com/a/9CnRANE
2023-07-18 16:27:19 <gordonjcp   > oh, yeah that would be more complex
2023-07-18 16:27:32 <gordonjcp   > SDR is easy enough once you understand that circles can rotate
2023-07-18 16:27:48 <KipIngram   > Yeah, I think SDR is a great concept.
2023-07-18 16:28:05 <gordonjcp   > if you don't "get" complex IQ signals, put your bike on its stand and spin one of the wheels anticlockwise and watch where the tyre valve goes
2023-07-18 16:28:20 <KipIngram   > And at lower amateur frequencies you can almost just hang a analog-to-digital on an rf amp output.
2023-07-18 16:28:36 <gordonjcp   > more or less
2023-07-18 16:28:43 <KipIngram   > I don't necessarly mean that literally, though it's not far off.  I just mean that components these days can do some remarkable stuff.
2023-07-18 16:28:50 <gordonjcp   > an IQ front-end is just a pair of direct-conversion receivers with a funny LO
2023-07-18 16:38:31 <veltas      > KipIngram: What font is that? Verily?
2023-07-18 16:39:08 <veltas      > No it's not Verily, it looks too sane
2023-07-18 16:51:05 <KipIngram   > It's Go Mono Regular 12.
2023-07-18 16:54:21 <veltas      > My bad you just said!
2023-07-18 16:56:32 <crc         > veltas: re: font size; I mostly use a terminal at around 75x20, configured with fonts as large as possible.
2023-07-18 16:56:42 <veltas      > Nice
2023-07-18 16:56:42 <KipIngram   > :-)  I think it's a very nicd font.  Like you said - sane.
2023-07-18 16:56:55 <veltas      > crc: It fits well with block-based work, doesn't it?
2023-07-18 16:59:40 <siesta      > do someone use forth for 2d games?
2023-07-18 16:59:47 <crc         > veltas:yes
2023-07-18 17:00:16 <crc         > siesta: one of my sons is doing some work with games, but nothing published yet
2023-07-18 17:01:58 <siesta      > what forth implementation will i use for 2d games?
2023-07-18 17:02:11 <veltas      > Depends what you want, why you're using Forth, etc
2023-07-18 17:03:11 <siesta      > i want to make DOS 2d games
2023-07-18 17:03:25 <drakonis    > i've seen death road to canada use a forth dialect
2023-07-18 17:03:38 <drakonis    > its called deathforth
2023-07-18 17:04:27 <siesta      > or will i roll out my own forth?
2023-07-18 17:04:48 <siesta      > my forth implementation is slow
2023-07-18 17:05:12 <crc         > http://forth.works/temp/IMG_1289.png & http://forth.works/temp/IMG_1290.png for screenshots of the sizing I'm currently using on my iPad w/a mosh connection
2023-07-18 17:06:23 <veltas      > siesta: Using your own Forth is reasonable, even a 'slow' assembly implementation will probably be fast enough and optimisable for a game
2023-07-18 17:06:40 <siesta      > i want to use forth in the game too like scripting the game
2023-07-18 17:06:44 <veltas      > Are you targeting a particular speed processor?
2023-07-18 17:06:57 <veltas      > Naturally
2023-07-18 17:06:58 <siesta      > dosbox
2023-07-18 17:07:37 <veltas      > If you fancy writing your own Forth then I don't see the harm in doing a DOS Forth, and starting there
2023-07-18 17:08:25 <veltas      > But if you want to actually make a game it's probably better to start with a DOS Forth and circle back to the Forth itself if you really want to later
2023-07-18 17:08:58 <veltas      > Using an existing Forth I'd expect it to be easy to add scripting to the game
2023-07-18 17:09:22 <veltas      > And I'd expect a DOS Forth to come with some fast drawing primitives
2023-07-18 17:11:57 <siesta      > im just editing this code https://gist.github.com/lbruder/10007431
2023-07-18 17:12:08 <siesta      > its a forth implementation
2023-07-18 17:12:38 <drakonis    > ah but this is a forth in C
2023-07-18 17:12:38 <siesta      > im adding some graphics
2023-07-18 17:13:34 <siesta      > yes cause my compiler is turbo c 2.01
2023-07-18 17:14:34 <veltas      > Yeah don't use a C Forth in Turbo C
2023-07-18 17:14:42 <siesta      > will i use forth in assembly ?
2023-07-18 17:14:50 <veltas      > I would recommend that for DOS
2023-07-18 17:15:28 <KipIngram   > I second that.
2023-07-18 17:15:41 <KipIngram   > An assembly Forth isn't too hard.
2023-07-18 17:16:01 <drakonis    > too hard.
2023-07-18 17:16:05 <siesta      > i got tasm 1
2023-07-18 17:17:14 <veltas      > I recommend just using an existing assembly forth
2023-07-18 17:17:36 <drakonis    > there's also fasm if you want to do some dos assembly
2023-07-18 17:17:47 <veltas      > For example I think there's an 8086 F83 Forth out there
2023-07-18 17:17:55 <veltas      > Who knows a good DOS Forth?
2023-07-18 17:18:09 <drakonis    > i think i'm spending too much time with dealing with x86 assembly in my quest to write my own forth in assembly
2023-07-18 17:18:11 <veltas      > I think VolksForth is a thing(?)
2023-07-18 17:18:40 <veltas      > drakonis: Write a set of primitives and then write the rest in high-level forth
2023-07-18 17:18:49 <drakonis    > yes
2023-07-18 17:19:04 <veltas      > And then optimise the rest in assembly when you have time or feel like it
2023-07-18 17:19:05 <drakonis    > but i wanted to at least understand enough of assembly to get started
2023-07-18 17:19:12 <veltas      > You don't need to pigeonhole yourself into a kernel design
2023-07-18 17:19:41 <veltas      > A good way is seeing compiler output, try writing small C functions doing roughly what you want and look at the assembly dump
2023-07-18 17:19:56 <veltas      > And get the manual
2023-07-18 17:20:22 <siesta      > will minimal forth with peek, poke, and call can do it?
2023-07-18 17:21:00 <veltas      > All Forths have peek and poke, called @ and !
2023-07-18 17:21:37 <veltas      > And I'd guess every assembly Forth for DOS allows calling machine code routines directly as well
2023-07-18 17:21:49 <siesta      > ive read 3 instruction forth
2023-07-18 17:22:23 <veltas      > Not sure I understand you
2023-07-18 17:22:46 <drakonis    > veltas: its a forth with 3 primitives
2023-07-18 17:22:51 <drakonis    > https://github.com/fogus/thunks/blob/main/langdev/forth.txt
2023-07-18 17:23:07 <drakonis    > seems terribly non portable?
2023-07-18 17:23:24 <siesta      > https://pages.cs.wisc.edu/~bolo/shipyard/3ins4th.html
2023-07-18 17:23:26 <KipIngram   > There's a paper out there that talks about a three-instruction Forth.  It's not really a Forth, though.
2023-07-18 17:23:34 <KipIngram   > Basically it's a "bootstrapper."
2023-07-18 17:23:38 <veltas      > This feels tangential
2023-07-18 17:23:49 <drakonis    > it is.
2023-07-18 17:24:03 <KipIngram   > You write a bit of code on your target that can receive data over a com line and let it poke RAM, peek RAM, and execute from address.
2023-07-18 17:24:11 <KipIngram   > And boot your way up from there.
2023-07-18 17:24:26 <KipIngram   > I was never sure why they connected it with Forth.
2023-07-18 17:25:09 <siesta      >  will write forth in machine language ?
2023-07-18 17:25:15 <drakonis    > i guess it still has forth words like :?
2023-07-18 17:25:38 <veltas      > The whole point is it's an interface for cross-compiling Forth, it's not "a forth" as such
2023-07-18 17:25:53 <siesta      > oh ok
2023-07-18 17:25:59 <veltas      > It's totally off-track from the requirements of siesta
2023-07-18 17:25:59 <drakonis    > its a neat party trick
2023-07-18 17:26:08 <drakonis    > but its not very useful
2023-07-18 17:26:26 <siesta      > may be ill stick with c
2023-07-18 17:26:33 <veltas      > I'm sure it's useful to someone but it seems unhelpful for DOS where you can just develop on DOS
2023-07-18 17:27:00 <veltas      > siesta: Well start with C if you want and then you can replace C with F83 or something later if you want
2023-07-18 17:27:09 <siesta      > im getting hard time using assembly
2023-07-18 17:27:23 <veltas      > You don't need to write the forth yourself :)
2023-07-18 17:28:38 <veltas      > siesta: What cell size? 16-bit or 32-bit?
2023-07-18 17:28:45 <siesta      > 16
2023-07-18 17:29:08 <veltas      > The issue with C is you're going to waste precious near address space
2023-07-18 17:29:26 <veltas      > As your addresses are limited to 64K if they're 16-bit
2023-07-18 17:30:14 <siesta      > how about sectorforth
2023-07-18 17:30:22 <veltas      > Why not F83?
2023-07-18 17:30:30 <siesta      > i think its in dos
2023-07-18 17:30:46 <veltas      > sectorforth would be really slow and you'd have to develop saving features etc
2023-07-18 17:30:49 <siesta      > i dont know about f83
2023-07-18 17:31:23 <drakonis    > forth 83 that is
2023-07-18 17:31:39 <drakonis    > sectorforth does not run on dos
2023-07-18 17:31:44 <veltas      > F83 is a Forth 83 implementation
2023-07-18 17:31:59 <drakonis    > there are dos forths
2023-07-18 17:32:07 <crc         > it's been a considerable time since I used anything on DOS other than my own stuff, but I recall doing some work with miniforth (dos/forth/min4th25.arc on simtel)
2023-07-18 17:32:19 <drakonis    > more than one, even.
2023-07-18 17:32:34 <veltas      > siesta: ^ listen to crc as he's actually had experience with DOS
2023-07-18 17:34:22 <crc         > forth.works/temp/min4th25.arc or forth.works/temp/min4th25.zip (probably easier to open on most systems); source was written for A86 assembler
2023-07-18 17:36:24 <crc         > http://eji.com/a86/ for that (I used this extensively in my DOS days, though switched to nasm for a while when I started doing 32-bit code, then settled on fasm)
2023-07-18 17:37:02 <crc         > the best dos forth as I recall was pygmy
2023-07-18 17:38:09 <veltas      > I was going to ask about pygmy and F-PC
2023-07-18 17:39:04 <crc         > forth.works/pygmy13.zip
2023-07-18 17:39:23 <crc         > forth.works/temp/pygmy13.zip
2023-07-18 17:41:43 <veltas      > They don't name em like that anymore lol
2023-07-18 17:42:12 <crc         > I never really used F-PC. I recall it being considerably larger than the others I used, and space was limited back then.
2023-07-18 17:42:14 <crc         > I had an 80mb hard disk, but was doing a multiboot ms-dos (with pc/geos & win3.1), Oberon System 3, an ancient Linux, and my own OS development projects; I seldom had much space free.
2023-07-18 17:42:48 <veltas      > Was that one of those Linux things you could run from DOS?
2023-07-18 17:44:35 <crc         > no; I managed to install & run a somewhat odd system on a partition. http://micheleandreoli.org/public/Software/mulinux/
2023-07-18 17:45:34 <veltas      > Did you have some kind of multiboot program in MBR?
2023-07-18 17:46:20 <crc         > In later times (on a newer machine), I used zipslack on a umsdos config, but never was comfortable with doing that long term
2023-07-18 17:47:09 <siesta      > how about this https://github.com/benhoyt/third/tree/master
2023-07-18 17:48:18 <veltas      > >I wrote this in 1998 (when I was 16), so I'm just putting it up here as a backup and for "historical interest".
2023-07-18 17:48:18 <crc         > yes, I wrote a boot loader as part of my os development efforts
2023-07-18 17:49:25 <veltas      > siesta try pygmy forth
2023-07-18 17:51:46 <crc         > looks like the latest pygmy release is on github: https://github.com/utoh/pygmy-forth
2023-07-18 17:55:49 <crc         > the github copy of pygmy has some notes on interfacing with C, and appears to have something that uses a C graphics library as an example (in extras/cfth)
2023-07-18 17:57:04 <veltas      > Am I right in thinking that DOS doesn't actually have a "C ABI"
2023-07-18 17:57:08 <crc         > I'd not do this for graphics; for a DOS system, I'd use BIOS calls to set the display mode, and then just write to video memory.
2023-07-18 17:58:24 <MrMobius    > just curious, why not use C for DOS? turbo C is pretty slick for it's time
2023-07-18 17:58:40 <MrMobius    > C to make the Forth I mean
2023-07-18 17:58:55 <veltas      > Limited memory space for a 16-bit cell forth is one reason
2023-07-18 18:00:02 <veltas      > On real DOS systems the overhead would probably be noticeable
2023-07-18 18:00:15 <veltas      > of having a C VM rather than assembly
2023-07-18 18:00:31 <crc         > veltas: no; I recall running into at least three different schemes (cdecl, fastcall, and a pascal-like one). Along with different name mangling (some compilers added underscores to labels, some didn't).
2023-07-18 18:01:29 <MrMobius    > veltas: but how is limited memory space differtent from assembly?
2023-07-18 18:01:43 <MrMobius    > I remember setting the memory model in tubro C 20+ years ago
2023-07-18 18:02:33 <veltas      > I would guess C includes more .data you don't need in near memory?
2023-07-18 18:03:18 <MrMobius    > you can configure it to compile different depending on what memory model you need
2023-07-18 18:03:35 <MrMobius    > IIRC the models were specific to the compiler so you had some flexibility in what you wanted to generate
2023-07-18 18:03:49 <siesta      > thanks guys for pygmy forth
2023-07-18 18:03:52 <veltas      > siesta wants 16-bit cells, I would consider 32-bit cells for a C VM in DOS
2023-07-18 18:05:01 <siesta      > im reading it now
2023-07-18 18:08:41 <veltas      > Good luck
2023-07-18 18:12:23 <gordonjcp   > veltas: not as such, no, DOS "functions" tend to be got at by using interrupts
2023-07-18 18:12:50 <gordonjcp   > veltas: set up some registers to describe what you want, fire the software interrupt
2023-07-18 18:14:19 <veltas      > Yes that I am aware of
2023-07-18 18:32:22 <siesta      > thanks again guys bye for now