2022-07-17 10:28:58 <KipIngram   > You know, maybe there is a chance of fitting this into a sector.  An awful lot of the built-in primitives look like they're going to come in at seven bytes - and that includes the header.
2022-07-17 10:29:16 <KipIngram   > I'm sure some will be longer, but there are only about 40 of them, so it may just work out ok.
2022-07-17 12:00:09 <KipIngram   > Ugh.  I'd forgotten that you can't use several of the registers in old mode for addressing.
2022-07-17 12:00:28 <KipIngram   > The good old days, eh?
2022-07-17 12:01:02 <thrig       > r14? unthing!
2022-07-17 12:45:41 <KipIngram   > Yeah - working on my 64-bit systems has spoiled me.  Lots more registers, more or less do anything with them.
2022-07-17 12:47:09 <KipIngram   > This looks like it's going to work out ok - I've written about half of them and am currently up to 191 bytes.
2022-07-17 12:48:09 <KipIngram   > I haven't filled in the actual BIOS call stuff yet - just wrote stubs for those words.  But it's looking like everything minus the BIOS interaction may come in around 400 bytes or so; I feel fairly sure that  leaves enough to get the calls in.
2022-07-17 12:54:28 <KipIngram   > imode: Command 'i' - "Get the interpreter function."  That isn't the interpreter loop itself, right?  I presume that means return the CFA of the interpreter loop on the stack.
2022-07-17 12:54:40 <imode       > I believe you're right?
2022-07-17 12:55:01 <KipIngram   > Should be easy to tell; I assume you need that to populate the CFA field of new definitions.
2022-07-17 12:55:24 <KipIngram   > I can't really think of a reason you'd need to execute that loop explicitly.
2022-07-17 12:55:41 <KipIngram   > And besides, if you did you could just use ix
2022-07-17 14:26:32 <KipIngram   > So, 1 for true flag, or -1 for true flag.  Opinions?
2022-07-17 14:26:44 <KipIngram   > I've vascillated on it over the years.
2022-07-17 14:29:17 <thrig       > -1 would be more forthlike
2022-07-17 14:35:05 <KipIngram   > Ok; -1 it is, then.
2022-07-17 15:04:06 <KipIngram   > Ok, so I have everything written except for the actual logic for getting characters from the disk (the BIOS call and buffer management) and the logic for searching the dictionary.  Other than that I think it's complete, and I'm using 366 bytes currently.
2022-07-17 15:04:48 <KipIngram   > I'd actually be pretty shocked if I wind up having fit problems - that's 146 bytes left, which feels like a lot to me.
2022-07-17 15:04:55 <KipIngram   > For covering those two things.
2022-07-17 15:05:18 <KipIngram   > I'll do the dict search now; leave the bios related stuff for last.
2022-07-17 15:06:07 <KipIngram   > I think the disk i/o needs to be thought through at least a little carefully - I want to be able to get to everything I need without any more machine code.
2022-07-17 15:06:43 <KipIngram   > And eventually I'll need other things (like console, obviously).
2022-07-17 15:06:57 <KipIngram   > So maybe the thing to do is a fairly generic interface to the BIOS subsystem.
2022-07-17 15:07:48 <KipIngram   > A way to load the registers from the stack, issue the interrupt, and leave results on the stack.  Then use that any way I want to later.
2022-07-17 15:09:14 <KipIngram   > Also, this "find" function isn't going to use up any space trying to handle failures.  Or at least not much - I guess it should at least indicate where an error occurs.
2022-07-17 16:52:30 <KipIngram   > Gonna be close...  :-)
2022-07-17 16:53:20 <KipIngram   > But I haven't really tried to "minimize" anything yet, other than leaving out the Q, v, and V commands.  Q is quit - nothing to quit to for me.  v has to do with argc and argv - don't have those.  V prints a version message; don't need it.
2022-07-17 16:53:41 <KipIngram   > Other than that I've followed PlanckForth exactly.
2022-07-17 16:57:20 <KipIngram   > So hey -  my memory is fuzzy on using the BIOS.  The easy to find docs describe the registers used for parameters.  Does the BIOS preserve un-mentioned registers?
2022-07-17 16:57:47 <KipIngram   > Seems like it SHOULD, but... I'm  not sure.
2022-07-17 17:38:48 <KipIngram   > Hah hah hah hah...
2022-07-17 17:38:51 <KipIngram   > Ok, I think I did it.
2022-07-17 17:39:04 <KipIngram   > That wound up requiring some trickery.
2022-07-17 17:39:45 <KipIngram   > The init code loads the first 4k of the bootstrap into the tib, and it just pulls from that.  But... it does not detect when it runs out, and it doesn't automatically reload it.
2022-07-17 17:39:57 <KipIngram   > The bootstrap will have to take care of that.
2022-07-17 17:40:38 <KipIngram   > Also, in order to support the full suite of bios calls, I will have to use self-modifying code.  As in setting the byte of the int instruction that specifies which interrupt to call.
2022-07-17 17:41:28 <KipIngram   > And calling an interrupt is a two-step process.  All the BIOS calls take input in ax, bx, cx, and dx, and yield output in ax, cx, and dx.
2022-07-17 17:41:45 <KipIngram   > My top of stack in in cx, and ax is used by lodsw in next.
2022-07-17 17:42:46 <KipIngram   > So, I have a "prep" word that expects ( ax bx dx cx) and pops dx and bx.  So I'm left with ax and cx on the stack.  Then I call the interrupt word - it pops ax (now all the regs are set), issues the interrupt, and then pushes ax and dx onto the stack.
2022-07-17 17:43:36 <KipIngram   > I added dup, drop, and swap - probably should look at how PlanckForth did those, but seems like those are good primitives to have.
2022-07-17 17:44:01 <KipIngram   > So, I may have overlooked something, but it's nominally complete and came in at 511 bytes.
2022-07-17 17:44:44 <KipIngram   > If the BIOS call clobbers any unmentioned registers then this won't work.
2022-07-17 17:45:50 <imode       > `c# i, 'd, '@, 'e, l!`
2022-07-17 17:45:58 <imode       > is how `dup` is defined.
2022-07-17 17:46:36 <imode       > `: dup   sp@ @ ;             \ ( w -- w w )`
2022-07-17 17:46:54 <imode       > is how `dup` is defined in the later language.
2022-07-17 17:55:17 <KipIngram   > Ah.  Little less efficient than push ax; jmp next
2022-07-17 17:55:22 <KipIngram   > I mean push cx
2022-07-17 17:55:29 <KipIngram   > But yeah, I figured there would be something like that.
2022-07-17 17:55:45 <KipIngram   > If anyone wants to take a look it's here:
2022-07-17 17:55:47 <KipIngram   > https://pastebin.com/1eLJ99KM
2022-07-17 17:55:55 <KipIngram   > Password iDxt4w0BUX
2022-07-17 17:56:41 <KipIngram   > That was kind of a fun way to spend the day.
2022-07-17 17:57:49 <KipIngram   > Think I'll wait until tomorrow to try to test it.  Probably has mistakes that'll make me feel bad, so I'll bask in it for a few hours first.
2022-07-17 18:08:03 <KipIngram   > That pastebin didn't seem to indent just right, which is kind of annoying.  But I guess it's readable enough.
2022-07-17 18:56:58 <KipIngram   > Actually, I took out the splitting of the interrupt call into two words.  I laid it out that way when I thought I was going to have separate words for interrupts 10, 13, and 16.  But now that I've got just one and will have to self-modify to set the number, there's no longer any reason for that split.
2022-07-17 19:24:46 <KipIngram   > I wound up putting two copies of NEXT in, one about a quarter way from the top and the about a quarter way from the bottom.  Every word could read one or the other of those with a two-byte jump.
2022-07-17 19:28:04 <KipIngram   > "reach"
2022-07-17 22:28:57 <KipIngram   > Well, looking it over; just an inspection pass.  Fixing little ooopsies, optimizng based on better recollection of exactly what can and can't be done in 16-bit mode.  22 unused bytes now; I could add 2-3 words if I needed to.
2022-07-17 22:29:43 <KipIngram   > Apparently you can't do indirect addressing using the sp register, which is rather annoying.
2022-07-17 22:49:55 <KipIngram   > I have the general purpose BIOS interrupt word, but I also have a dedicated "print character word."  I dont really need that - I could add it via the bootstrap.  It takes 14 bytes.  So that makes 36 I could have available if I wanted to.
2022-07-17 22:50:55 <KipIngram   > I could add several more efficient stack operations, or I could add a basic form of my stack frame system (just three words - { } and a word to take a number to the address of that offset in the frame.
2022-07-17 22:52:22 <KipIngram   > One of the first things the bootstrap will need to do is add an improved way of getting the next bootstrap byte - eliminate the need to manually re-fill the text buffer.