2023-01-05 07:49:23 <KipIngram   > https://imgur.com/a/mOPY6Uk
2023-01-05 07:49:28 <KipIngram   > Looks like that's working.
2023-01-05 07:50:26 <KipIngram   > Only the very general case right now, though - no conditional field catching yet.
2023-01-05 07:50:48 <KipIngram   > But if this works that should too, once I tell it how to recognize when an opcode has a conditional field.
2023-01-05 07:51:19 <KipIngram   > If the "now" opcode does have a conditional, then it just shifts over 12 instead of 6.
2023-01-05 07:52:40 <KipIngram   > If "op" is asserted, then "now" will be used by the ALU logic to "do something."  Once this bit gets "go," it grabs the input word, asserts "op", and starts working through.  On the last one it asserts done and then stops until it gets "go" again.
2023-01-05 07:53:52 <KipIngram   > It's not quite all there - it will need to provide feedback to the other stuff as to whether to increment IP or not (it will if it's "really" done; it won't if it's going back to allow an irq to be handled).
2023-01-05 07:54:32 <KipIngram   > So IP won't get incremented until we're actually on our way back to the fetch unit.
2023-01-05 07:56:36 <KipIngram   > Also haven't tested rep support yet; a copy of the input word is stored in a save register; rep will cause it to reload the shift register from that.
2023-01-05 07:57:02 <KipIngram   > And so long as there's no irq, it will just keep doing that until rep decides it has no more work to do.
2023-01-05 07:58:21 <KipIngram   > I'll probably add an input to this module to tell it whether to do that or not, and the ALU will run that input.
2023-01-05 09:31:00 <KipIngram   > Ok, I think the remaining bits are 1) irq input, 2) conditional test result input, and 3) exit status.
2023-01-05 09:32:04 <KipIngram   > There are five ways this thing can end - 1) increment IP, 2) loopback jump, 3) single return, 4) double return, and 5) IRQ service pause.  So I'll need a three-bit exit status field for that.
2023-01-05 09:33:42 <KipIngram   > Only two instructions have condition fields - I'll just have it recognize those on its own.
2023-01-05 19:04:58 <gordonjcp   > oh hey, anyone here interested in the RTS that a few of us talked about on Reddit a while back?
2023-01-05 19:05:04 <gordonjcp   > that was written in Forth for the Apple II?
2023-01-05 19:05:09 <gordonjcp   > I got it kind of working
2023-01-05 19:05:21 <gordonjcp   > https://gjcp.net/conquest.mp4
2023-01-05 19:11:14 <vms14       > :0
2023-01-05 19:12:29 <vms14       > are those funny symbols only from the appleII?
2023-01-05 19:12:33 <gordonjcp   > yeah
2023-01-05 19:12:53 <gordonjcp   > they're done using the Apple II's ROM graphics routine, it has a funny turtle-like vector-like routine
2023-01-05 19:13:27 <KipIngram   > Wow - that's got a reall old school look.  :-)
2023-01-05 19:13:30 <vms14       > I don't understand the game, but it's nice to see it
2023-01-05 19:13:55 <vms14       > also kind of funny as I'm adding curses bindings
2023-01-05 19:14:07 <vms14       > I was thinking on some way to hook handlers for keys
2023-01-05 19:14:46 <vms14       > say a main loop that will get keys constantly and you hook code into those keys
2023-01-05 19:15:28 <vms14       > like 'KEY_UP [ some code ]  start.loop
2023-01-05 19:16:03 <vms14       > won't serve for most purposes, but for some cases could be handy
2023-01-05 19:16:31 <KipIngram   > What I really wish was more "accessible" (insofar as easily finding information about it, having toolkits available for it, and so on) is truly raw keyboard support.  What I mean by that is you just receive a stream of down and up codes.  Without any key being "special"; every key would just be a key, and you'd get a code when it was pressed down and a different code when it was released.
2023-01-05 19:17:40 <KipIngram   > I know that can be done, but it's certainly not "readily accessible information."
2023-01-05 19:18:06 <KipIngram   > It's kind of in that same category as how to run the memory management hardware in the x86.
2023-01-05 19:18:59 <vms14       > yeah, but we're stuck in a standard
2023-01-05 19:19:37 <vms14       > this same thing happens with http html etc
2023-01-05 19:19:47 <KipIngram   > Can't really blame the people who could write books on such stuff.
2023-01-05 19:19:51 <vms14       > we shouldn't be using http or httml today
2023-01-05 19:19:55 <KipIngram   > The problem is that NO ONE IS INTERESTED.
2023-01-05 19:20:20 <vms14       > you have to adapt on what everyone already uses/knows if you want users
2023-01-05 19:20:27 <vms14       > if you don't care, then you're free
2023-01-05 19:20:37 <KipIngram   > There's not enough demand for that knowledge to get the material out there well enough to be easy to get.
2023-01-05 19:21:29 <KipIngram   > I remember a time, like maybe in the late 1980's, when bookstores were just CRAWLING with really neat deep tech info.
2023-01-05 19:22:32 <KipIngram   > You wanted a book on how protected mode worked, say, and you could run out and find it.
2023-01-05 19:25:37 <vms14       > well today everything is online
2023-01-05 19:25:52 <vms14       > but I think I get your point
2023-01-05 19:28:05 <KipIngram   > Right - it should be EASIER to find such things than it used to be.
2023-01-05 19:28:17 <KipIngram   > And truth be told, you can, if you're willing to dig deep enough.
2023-01-05 19:28:24 <KipIngram   > It's not like it's NOWHERE.
2023-01-05 19:28:33 <KipIngram   > It's just not "commonplace" like it used to be.
2023-01-05 19:36:38 <vms14       > also this stuff was much easier before
2023-01-05 19:36:43 <vms14       > now is kind of complex
2023-01-05 19:37:07 <vms14       > initialize.curses  key.up [ 'oh... . refresh ] hook.key  curses.loop
2023-01-05 19:37:13 <vms14       > I kind of like that
2023-01-05 19:37:25 <vms14       > when I press the up arrow it executes the code
2023-01-05 19:37:32 <vms14       > also have a hookable default handler
2023-01-05 19:38:06 <vms14       > I suppose in the default handler I'll have to push the key
2023-01-05 19:38:16 <vms14       > but makes no sense in the key hook
2023-01-05 19:38:40 <vms14       > also I think I'll add a 'printable' hook
2023-01-05 19:38:53 <vms14       > which is mainly why I wanted the default handler xd
2023-01-05 19:38:58 <KipIngram   > I sure am glad I got some good work on the processor done this morning before I went to work.  Because it was an intense day and I feel like doing something more vacuous tonight.
2023-01-05 19:39:17 <vms14       > make a text game :D
2023-01-05 19:39:42 <vms14       > also as you have a linux forth, you could add curses even if you dislike the idea
2023-01-05 19:39:58 <vms14       > just to play with it and get ideas for when you're making your own stuff
2023-01-05 19:40:17 <vms14       > it's quite easy to play with
2023-01-05 19:40:41 <vms14       > and using something is the best way to get an idea of how you want it to be
2023-01-05 19:40:55 <Zarutian_iPad> 
ACTION has actually just done the stuff himself with the help of an ANSI escape sequence reference

2023-01-05 19:41:02 <vms14       > every time I rewrite my lang is because when I'm using I discover how shitty is
2023-01-05 19:41:03 <vms14       > XD
2023-01-05 19:41:21 <vms14       > Zarutian_iPad: how about the control keys and alike?
2023-01-05 19:41:28 <vms14       > you ioctl?
2023-01-05 19:41:47 <vms14       > I just didn't want to have to mess with ioctl/termios
2023-01-05 19:42:21 <Zarutian_iPad> naah, just did the stuff over a socket or such
2023-01-05 19:42:33 <vms14       > init.screen raw no.echo get.char key.up equal [ code ] if
2023-01-05 19:43:08 <vms14       > actually I have initialize.curses for init.screen raw noecho
2023-01-05 19:43:29 <vms14       > well initialize.curses* with an asterisk, as the normal one uses cbreak instead of raw
2023-01-05 19:43:43 <Zarutian_iPad> or I just, in the C wrapper around the forth cpu emulator, invoked terminos with the stuff thst turns the access to the stdin and stdout as raw as possible
2023-01-05 19:43:49 <vms14       > raw disables signals and alike so no more ctrl-c killing
2023-01-05 19:44:39 <KipIngram   > Heh.  No, no curses.  I got the feeling the day were talking about SDL that writing one would be straightforward enough.
2023-01-05 19:44:49 <Zarutian_iPad> basically got it to the point where reading a byte from stdin was like getting a byte via uart or serial
2023-01-05 19:44:50 <KipIngram   > Not one as "feature full" as curses - that would take forever.
2023-01-05 19:45:06 <KipIngram   > But a basic setup?  Yeah, I think I've got a feel for how to go on that.
2023-01-05 19:45:19 <MrMobius    > a very neat trick that the creator of mecrisp forth does is just run a command in bash to put the console into raw mode before invoking the forth
2023-01-05 19:45:28 <MrMobius    > so you dont have to mess with setting the ioctl stuff
2023-01-05 19:46:02 <KipIngram   > Zarutian_iPad - that sounds like where my x86 Forth is, basically.
2023-01-05 19:46:09 <KipIngram   > I turned off all of the "cooking."
2023-01-05 19:46:22 <KipIngram   > And most of all I turned off the line buffering.
2023-01-05 19:47:20 <Zarutian_iPad> KipIngram, yeah but in my case I had no x86 code accessible from the forth. Basically a switch dispatch loop
2023-01-05 19:47:46 <KipIngram   > Ah.  Yeah, that would make it harder.
2023-01-05 19:48:32 <vms14       > that's an old trick xD
2023-01-05 19:48:57 <vms14       > mainly to use the stty command
2023-01-05 19:49:14 <vms14       > but yeah, it avoids you to handle termios and is even quite "portable"
2023-01-05 19:49:34 <Zarutian_iPad> nope, basically I wrote a small emulator in C. In the main() before the dispatch loop I just used that ioctl terminos incantation to turn off all the cooking
2023-01-05 19:51:17 <KipIngram   > I slugged through it the hard way.
2023-01-05 19:51:27 <KipIngram   > And put it back when I quit.
2023-01-05 19:51:45 <vms14       > 
ACTION is lazy

2023-01-05 19:51:58 <vms14       > well I wouldn't use perl if I wasn't
2023-01-05 19:53:10 <vms14       > at least I'm slowly getting near to make a text editor :D
2023-01-05 19:53:22 <vms14       > but now I just want to play a bit
2023-01-05 19:56:03 <KipIngram   > When I buckle down and get to it, I expect my editor to be fairly easy.  I put a lot of thought into the main line editing word that underlies EXPECT.  It lets me specify the buffer  length and the number of chars in the buffer now.  Say I want to edit one line of a disk block.  I'll set the max length to the entire remainder of the block, but will print only the one line.
2023-01-05 19:56:23 <KipIngram   > So all the lower lines will get moved back and forth as necessary based on character inserts and deletes.
2023-01-05 19:56:54 <KipIngram   > So mostly I'll just need to point into my disk block, get the count of that first line, and then just call that word.
2023-01-05 19:57:16 <vms14       > I need a way to do async
2023-01-05 19:57:16 <KipIngram   > If I get a keystroke that moves me off of that line, it'll exit back out to the main editor level.
2023-01-05 19:57:26 <KipIngram   > So I think the hardest part of the work is already done.
2023-01-05 19:57:40 <vms14       > if for example I make a keybind to shoot a bullet, the bullet needs to move independently
2023-01-05 19:58:04 <vms14       > I can take code and separate it by words and execute it one by one in order to fake async, or use threads xd
2023-01-05 19:59:09 <vms14       > but still the main loop which gets the keys should go in a separate thread as it's blocking by nature
2023-01-05 20:01:29 <KipIngram   > I'm going to mamke my key handling non-blocking at some point.
2023-01-05 20:01:44 <KipIngram   > I've got the necessary "tick" stuff in already.
2023-01-05 20:02:22 <KipIngram   > That stuff for supporting background processes that I mentioned a while back.
2023-01-05 20:02:41 <Zarutian_iPad> vms14: or have KEY? ( — byte T | F ) as your primtive for input
2023-01-05 20:03:27 <vms14       > I was thinking also about non blocking read
2023-01-05 20:03:42 <vms14       > that way I could have the fake async
2023-01-05 20:04:24 <vms14       > it's not funny to involve threads in this
2023-01-05 20:04:37 <Zarutian_iPad> and then in : KEY ( — byte ) BEGIN PAUSE KEY? UNTIL ; or something like that
2023-01-05 20:05:07 <Zarutian_iPad> and the do your thread or task switching in PAUSE
2023-01-05 20:05:38 <vms14       > what I have now is just a loop that reads a key and executes code if there's a handler for it
2023-01-05 20:06:11 <vms14       > what seems I should do is to turn that into non-blocking and when there's a handler I just push the code into a list of code to execute
2023-01-05 20:06:30 <vms14       > when I do not get a key I traverse that list executing one word of every handler present
2023-01-05 20:06:51 <vms14       > still seems easier to maintain a thread pool
2023-01-05 20:10:52 <vms14       > with a thread pool every thread will have its own stack and execute asynchronously
2023-01-05 20:11:14 <vms14       > I can just reset the stack every time a handler starts working
2023-01-05 20:18:13 <vms14       > the sad part is a thread can't alter state unless I provide shared memory
2023-01-05 20:18:26 <vms14       > and I'd like to avoid shared memory, I dislike it
2023-01-05 20:18:43 <vms14       > but for a game I need to be able to alter state
2023-01-05 20:19:36 <vms14       > threads can return values, I could take what's left on the stack as return values or whatever, but I need to know when I should join a thread (wait for it to finish) which does not seem I'll be easily able to do
2023-01-05 20:20:07 <vms14       > at least some primitive shared memory seems to be needed, even if it's just a flag
2023-01-05 20:20:22 <vms14       > so non-blocking seems better in all cases
2023-01-05 22:07:59 <KipIngram   > Not that I really think running Forth on a calculator is the *best* idea going (you really do need a full keyboard), but just the same this is nifty:
2023-01-05 22:08:02 <KipIngram   > https://www.youtube.com/watch?v=6uljanU6ehI