2022-12-24 00:17:42 <KipIngram   > I think I've been picturing this wrong.  I've been picturing the TOS and NOS registers as being at the output of the RAMs.  But I think instead I should picture them as being on the inputs to the ALU.  So, on each rising clock edge, those registers are clocked and they lock in the ALU inputs for the duration of that cycle.  Then I can do anything I want with the block RAM addresses and so on.  So I
2022-12-24 00:17:44 <KipIngram   > immediately change the addresses to whatever they need to be based on the instruction, and prepare to write new data into one or both RAM ports as the instruction requires.  In cases where I'm going to write into the RAM, that will happen on the next clock, at the end of the cycle.  But that's when the ALU input registers will get clocked again, so that "new" data also has to be presented to them.
2022-12-24 00:18:12 <KipIngram   > That means muxes on the ALU input registers, so that those inputs can be RAM output if I wish, but also can be values I've calculated in that cycle if that's appropriate.
2022-12-24 00:19:06 <KipIngram   > For example, SWAP won't move the stack pointer at all.  But it will write TOS both into the NOS ALU input register and into the NOS RAM cell, and will write NOS into both the TOS ALU input reg and into the TOS ram cell.
2022-12-24 00:19:21 <KipIngram   > Quite a few different "motions" will be involved instruction set wide.
2022-12-24 00:21:15 <KipIngram   > I think SWAP is the only instruction that CHANGES NOS, isn't it?
2022-12-24 00:21:42 <KipIngram   > Oh, well, tuck does, doesn't it?
2022-12-24 00:21:52 <KipIngram   > But the source is still TOS.
2022-12-24 00:22:17 <KipIngram   > Original address of NOS, is what I'm referring to here.
2022-12-24 00:59:59 <KipIngram   > I decided I need pencil and paper in hand for further work on this - I've taken it as far as I can in my head.
2022-12-24 01:00:29 <KipIngram   > I've sketched out a structure for the data stack + ALU, that accounts for everything that needs to happen to the data stack from all sources.
2022-12-24 01:01:03 <KipIngram   > This is with registers on the ALU input, and it looks fine except that without cached registers TUCK becomes problematic.
2022-12-24 01:01:25 <KipIngram   > But, as someone pointed out, : TUCK  SWAP OVER ; is always possible.
2022-12-24 01:01:38 <KipIngram   > Or just an inline swap over.
2022-12-24 01:02:51 <KipIngram   > But I see how it will do everything else, including those double pops that come along with my conditional returns.
2022-12-24 01:21:25 <KipIngram   > Ok, now this is strange.
2022-12-24 01:21:36 <KipIngram   > Here is how my system looks:
2022-12-24 01:22:03 <KipIngram   > : quit  rp0@ rp! query interpret prompt me ;
2022-12-24 01:22:48 <KipIngram   > I left out a couple of inconsequential things, but the important thing is that quit resets the return stack and later calls interpret, at that same level.  So when interpret is called we put the first item on the return stack.
2022-12-24 01:23:14 <KipIngram   > : interpret  find ... exec me ;
2022-12-24 01:24:00 <KipIngram   > Interpret calls exec (my execute).  But my exec is a primitive, so it doesn't use the return stack.  We should still have just one item on the stack.
2022-12-24 01:24:15 <KipIngram   > I made this definition:
2022-12-24 01:24:29 <KipIngram   > : ret-now  rp@ rp0 @ - ;
2022-12-24 01:25:06 <KipIngram   > So if I type that ret-now in, it should get executed at a time there is only one return item on the stack.
2022-12-24 01:25:17 <KipIngram   > Oh; never mind.
2022-12-24 01:25:32 <KipIngram   > I forgot to do 3 >> to make it a cell count instead of a byte count.
2022-12-24 01:26:00 <KipIngram   > everything is fine.  The result is 2.  Not exactly why it's not 1, but I'm not going to fret over that.
2022-12-24 01:26:13 <KipIngram   > I was getting 16, which made no sense (unless it's bytes.  :-)
2022-12-24 01:27:41 <KipIngram   > My system uses up to as many as 15 return stack slots, but not at the same time it's running my code.
2022-12-24 01:29:32 <KipIngram   > Oh, I guess the second return stack item is from ret-now being executed.
2022-12-24 01:29:48 <KipIngram   > exec has to put a return stack item on.
2022-12-24 01:30:10 <KipIngram   > It itself is a primitive, but it still is running a : definition.
2022-12-24 01:30:15 <KipIngram   > So this is as good as it can be.
2022-12-24 01:35:59 <KipIngram   > So, it looks like, from studying godbolt, that to make that "multiply to divide" mechanism work, in general, you need access to the high order part of the product.
2022-12-24 01:36:55 <KipIngram   > I wonder if I should somehow capture that.  I don't actually have a multiply instruction, but I could arrange for overflow on adds to "land somewhere."
2022-12-24 01:37:49 <KipIngram   > I'm also mentally debating the 32-bit vs. 64-bit decision.  I'd like to wind up with a design that can do either (or do 16, for that matter).
2022-12-24 01:37:52 <KipIngram   > Why not?
2022-12-24 01:40:11 <KipIngram   > The block RAM for the stack will have port A addressed by a pointer register, and port B addressed by that same value minus one.  So basically port A addresses TOS and port B NOS.  Each instruction will be able to specify an adjustment, and that adjustment will be not only added to the pointer register on the clock edge, but added to the pointer output during the cycle.
2022-12-24 01:40:23 <KipIngram   > Adjustments will be -2, -1, 0, or 1.
2022-12-24 02:35:58 <KipIngram   > So, no rocket science here, but it's cute:
2022-12-24 02:36:23 <KipIngram   > : plus  over over and >r xor r> 1 << ;
2022-12-24 02:36:47 <KipIngram   > If you iterate on that until tos=0, then the sum is in nos.
2022-12-24 02:38:09 <KipIngram   > So,
2022-12-24 02:38:28 <KipIngram   > : plus  over over and >r xor r> 1 << .0!=me drop ;
2022-12-24 02:38:35 <KipIngram   > does the whole job.
2022-12-24 06:53:53 <veltas      > People are still using STAR as an example even though it only made sense before character literals and [CHAR]
2022-12-24 06:55:17 <veltas      > : STAR  42 EMIT ;  is an example from starting forth, before [CHAR] or '*' was possible
2022-12-24 06:55:49 <veltas      > Not least of all today lots of people might rightly write ." *"
2022-12-24 06:56:12 <veltas      > Even though that was considered bloated before
2022-12-24 06:59:33 <veltas      > Really, writing an extra def instead of ." *" is bloated
2022-12-24 07:31:53 <dave0       > my ." is not very efficient :-(
2022-12-24 07:32:44 <dave0       > i compile that to a   branch past the string, the string padded to an a-addr, a literal pointer to the string, a literal length of the string
2022-12-24 07:33:12 <dave0       > branch+address+padded string+lit+pointer+lit+length    6 cells + the string
2022-12-24 08:19:11 <MrMobius    > I'm sure they had string output in the starting forth days. EMIT is just useful to have in any forth
2022-12-24 09:22:12 <veltas      > dave0: That's what most people do, but whether you need to really worry that is another matter
2022-12-24 09:23:04 <veltas      > MrMobius: Yeah they had string output, they just considered it inefficient for one character
2022-12-24 10:42:16 <KipIngram   > Actually, though, the EMIT approach is bigger.  ." #" has the counted string and one cell for the (.") runtime.  <# code> EMIT has two executable words, (lit) and EMIT, and also the literal value takes an entire cell rather than just two bytes (plus any required padding - after padding they might be the same, depending on the system).
2022-12-24 10:43:06 <KipIngram   > Also, is there even a way in Linux to output a single character, OTHER than treating it as a one-character string?
2022-12-24 10:43:28 <KipIngram   > At the OS level it's likely to be a string output.
2022-12-24 10:43:34 <Zarutian_iPad> putchar iirc
2022-12-24 10:43:53 <KipIngram   > But what does that do at the OS syscall level?
2022-12-24 10:44:52 <KipIngram   > Instead of having EMIT and building TYPE with it, I have TYPE and build EMIT with it, precisely so I can get better performance on long strings.
2022-12-24 10:48:39 <KipIngram   > I wonder how fast it would be to have a "screen buffer" that applied ANSI color and attribute codes to every single byte?  Something that you could access as an array.  That would be quite inefficient, but it might be fast enough to "look snappy" just the same.
2022-12-24 10:49:01 <KipIngram   > I don't find it terribly appealing, but it's a curiosity.
2022-12-24 10:50:07 <KipIngram   > And then I wonder if for chars where no attribute change was needed, how it would affect performance if you replaced the ineffective color / attribute sequences with nulls.  That might potentially be faster.
2022-12-24 10:57:28 <KipIngram   > Annoyingly, it looks like an ANSI string to set "everything" is *nine* bytes long; at least in the example I found.
2022-12-24 10:57:50 <KipIngram   > You could probably limit things just a little and get it so everything associated with one char fit in a cell.
2022-12-24 10:58:12 <KipIngram   > I may later code that up and time it.
2022-12-24 10:59:33 <KipIngram   > If you REALLY wanted to have all functionality accessible, have a uniform array layout, and support utf8, you'd be looking at a pretty big array.  Maybe 3 cells per character.
2022-12-24 11:00:09 <KipIngram   > Just to be clear, I'm talking about outputting the entire screen every time anything changes.
2022-12-24 11:01:33 <thrig       > curses does some magic(TM) to only send changes
2022-12-24 11:01:53 <KipIngram   > Yes, certainly.
2022-12-24 11:02:11 <KipIngram   > Moves the cursor as needed.
2022-12-24 11:02:13 <thrig       > otherwise you tend to get flickering from all the redraws, unless the terminal itself double buffers
2022-12-24 11:02:38 <KipIngram   > I've found that turning off the cursor while outputting usually eliminates that.
2022-12-24 11:02:54 <KipIngram   > my EXPECT prints the whole string every keystroke, and I don't see any flickering, even for long strings.
2022-12-24 11:03:13 <KipIngram   > I used to just print the part after the cursor, but adding the utf8 support made that difficult to keep up with.
2022-12-24 11:03:33 <KipIngram   > That flickering comes from catching glimpses of the cursor here and there during update.
2022-12-24 11:05:36 <thrig       > I have observed flickering in some terminals with the cursor disabled with inefficient updates
2022-12-24 11:06:24 <KipIngram   > Ok.  I guess it may vary from implementation to implementation.  But it feels like something that you'd see anytime you updated more than one character in a shot, if the issue is present.
2022-12-24 11:06:41 <KipIngram   > How much you see it would be proportional to how much you were updating.
2022-12-24 11:08:47 <KipIngram   > Looks like if you wanted to change foreground color only, and keep everything else constant, you did not try to support utf8, you could get a char per cell.
2022-12-24 11:19:52 <MrMobius    > curses is indeed magic but the updates are a little braindead. If a character changes then changes back to what it was originally, it still redraws
2022-12-24 11:20:56 <MrMobius    > I got a bit of flicker redrawing the whole screen even though only a character had changed so I just buffered the text and color and only changed things in curses after all changes had been made. That was very smooth
2022-12-24 11:24:44 <KipIngram   > I think I'm almost there on this data stack design.  Right now I have TOS and NOS both in registers and written to RAM each time.  But I'm thinking I can probably avoid writing TOS - write that value only if it "becomes NOS" later.  And I think that might let me pick up TUCK.
2022-12-24 11:25:16 <KipIngram   > Anyway, hopefully later today I'll draw it up again more tidily, and I'll post it for you guys to take a look at.
2022-12-24 11:27:05 <KipIngram   > The issue with tuck is that it involves updating three stack cells.  Old NOS address becomes old TOS value, old TOS address becomes old NOS value, and a new TOS address is written with TOS.   And you can't do all of that with a dual port RAM.
2022-12-24 11:27:30 <KipIngram   > But if I can postpone writing TOS until later, if necessary, that frees up a port for the additional store.
2022-12-24 11:29:29 <KipIngram   > The way it's designed now ALWAYS writes new TOS reg value to new TOS RAM location and the same with NOS.  That's simple to implement, but just not completely flexible.
2022-12-24 11:29:43 <MrMobius    > How about keeping TOS in a register?
2022-12-24 11:30:23 <KipIngram   > Well, that's exactly what I'm saying.  I do have registers for TOS and NOS now - that's where the ALU gets its inputs from.  But I'm ALSO writing them into RAM, because you may need them there later.
2022-12-24 11:30:50 <KipIngram   > The optimization I'm considering now is to NOT write TOS value to RAM - if it eventually needs to get written to RAM it'll happen later when that value has become NOS.
2022-12-24 11:31:12 <KipIngram   > In some cases you eventually need that value in RAM.
2022-12-24 11:31:24 <KipIngram   > But it doesn't necessarily have to be written immediately upon its existence.
2022-12-24 11:32:04 <KipIngram   > The registers freeze the TOS and NOS values as far as the ALU is concerned, freeing me to diddle around with the RAM addresses and so on during the cycle.
2022-12-24 11:32:33 <KipIngram   > And the "simple" thing to do was just to wrap those register inputs around to the two RAM write ports, and write them in every time.
2022-12-24 11:33:05 <KipIngram   > Which means the port addresses always are the new TOS and NOS locations.  But to do tuck I need to do something else with one of the ports.
2022-12-24 11:33:13 <KipIngram   > Sometimes.
2022-12-24 11:33:33 <KipIngram   > I think it'll work fine - it's just a tad more complex than t his easiest solution, and I need to work through the details.
2022-12-24 11:35:45 <KipIngram   > Some instructions will drop two items from the stack, necessitating the dual  port RAM so that I can read out new values for TOS and NOS in those cases.  But I never PUSH more than one new value to the stack.
2022-12-24 11:36:56 <KipIngram   > I see four cases where I push one new value - OVER, DUP, (LIT), and fetch.
2022-12-24 11:37:17 <KipIngram   > And those differ only in terms of where I get the data - data ram, instruction ram, stack port A, or stack port B.
2022-12-24 11:37:42 <KipIngram   > I guess data and instruction RAMs are just port A and port B on a different block RAM.
2022-12-24 11:39:10 <KipIngram   > Also, right now in this simple logic, the addresses used for stack RAM fetches are identical to the new TOS and NOS addrs that are becoming effective on this instruction.  That limits flexibility too.  It's not necessary, though - I can independently specify the fetch address and the next cycle address for each one, if I want to.
2022-12-24 11:39:20 <KipIngram   > And that's what it will take to get TUCK.
2022-12-24 11:39:44 <KipIngram   > So, it's really just a matter of "is TUCK important enough to me to warrante a bit of extra logic, or is swap over fine?"
2022-12-24 11:40:34 <KipIngram   > Considering that I don't even have tuck IN my x86 Forth at the moment, swap over is probably fine.  :-)
2022-12-24 11:40:56 <KipIngram   > It's not as though I go around TUCKing all the time.
2022-12-24 11:41:05 <KipIngram   > Maybe some of you guys have some data on that front as well.
2022-12-24 11:42:41 <KipIngram   > Oh, on a completely different front (but still processor related), I haven't decided yet whether to try to parallel next instruction cell fetches with some opcode execution, or whether to have that be an additional cycle.
2022-12-24 11:44:27 <KipIngram   > Obviously, paralelling it would be nifty, but some opcodes (lit, jumps, etc.) modify IP, so there's a potential conflict there.
2022-12-24 11:45:19 <KipIngram   > The F21 has an extra cycle for that.
2022-12-24 11:55:14 <KipIngram   > Anyway, MrMobius, yes - the immediate goal here is to avoid writing any "TOS" value to the stack ram - to postpone that write until it later becomes an NOS value (if it does).
2022-12-24 11:57:05 <KipIngram   > I may be able to get by with leaving the NOS port just like it is - it would always just write the new NOS value - and making the other port the more flexible one.
2022-12-24 11:58:09 <KipIngram   > On TUCK it would be used to write current TOS into the RAM cell that will correspond to the third item on the stack after the instruction.
2022-12-24 11:58:54 <KipIngram   > That would involve applying a -2 adjustment to its "default" value of the new TOS address, and nothing would actually get written to that TOS address.
2022-12-24 11:59:23 <KipIngram   > But it would be the new value the port's address register took on as a result of the instruction.
2022-12-24 12:45:10 <KipIngram   > Ok, finally got this right, I think - the way you'd think it ought to be to start with.  TOS in a reg, NOS in a reg, and everything else in RAM.  The RAM address values "normally" address the third and fourth slots on the stack.  I only need to acutally USE the second port when I need to pop two items off the stack - the rest of the time the one port is enough.  And TUCK works too.
2022-12-24 13:49:29 <KipIngram   > Ok, got it all sketched out - looks like I need to make 12 control bits to run the whole thing.  One lut will make each one (each taking in all six bits of the opcode).  So that's pretty clean.
2022-12-24 13:49:53 <KipIngram   > Seven selector LUTs for each bit of the word, so a few hundred there.
2022-12-24 13:50:35 <KipIngram   > then the alu functions themselves, which will likely be  more than all the rest.
2022-12-24 13:50:46 <KipIngram   > But those are straightforward things to just grind out.
2022-12-24 13:51:45 <KipIngram   > And this is just the data stack - the other stuff should be simpler, though.
2022-12-24 13:52:11 <KipIngram   > Oh, eight selector luts, not seven.
2022-12-24 14:01:15 <KipIngram   > Tuck wound up costing just one LUT per data bit; if it wasn't going to be "free" that's the least it could cost.  It'll still be easy for me to decide either way on having it, though.
2022-12-24 15:10:06 <KipIngram   > Ok, it's not exactly polished and pristine, but this is what I'm looking at at the moment:
2022-12-24 15:10:08 <KipIngram   > https://imgur.com/gallery/DIAQcj9
2022-12-24 15:11:08 <KipIngram   > Here SP would always point to the RAM cell holding the third stack item, and the data stack grows up, by cells (not bytes).
2022-12-24 15:32:54 <KipIngram   > Note that if the current NOS needs to become the new TOS, it does so by flowing through the ALU path.
2022-12-24 15:33:19 <KipIngram   > Top of return stack also gets to TOS that way, on r> or r@.
2022-12-24 15:33:55 <KipIngram   > Oh, shoot; my SEL 2 needs to be two bits.
2022-12-24 15:33:57 <KipIngram   > Ooops.
2022-12-24 15:36:08 <KipIngram   > Oh, never mind - I grouped the other bit with SEL [1..0] in the table - just didn't label the drawing right.
2022-12-24 16:21:52 <KipIngram   > Ok, so I set up a test where each cell of a big buffer called out a color a character and tried it - printing my screen, which holds a bit over 10,000 characters, seems to take right at 13 ms.
2022-12-24 16:22:26 <KipIngram   > Which would really be quite acceptable for running a console user interface.
2022-12-24 16:23:43 <KipIngram   > A downside of it is that the buffer has to match your screen exactly - if you resized, then the lines of a sub-rectangle wouldn't be continguous.
2022-12-24 16:24:38 <KipIngram   > But on the other hand, if you wanted to manage those rectangles yourself, with your own Forth-coded screen splitting, then it might be fine.
2022-12-24 16:25:03 <KipIngram   > Though then you'd have to print line-by-line.
2022-12-24 16:25:15 <KipIngram   > It would be easy to find the right stuff to print in the big buffer, though.
2022-12-24 16:26:16 <KipIngram   > And very easy to step across those lines.
2022-12-24 16:27:39 <KipIngram   > My buffer would be 80194 bytes.  :-)  And that's only doing a subset of the possible control; to get it all it would need to be twice that.
2022-12-24 16:27:47 <KipIngram   > And would probably take twice as long to print.
2022-12-24 16:28:39 <KipIngram   > A nice feature of it, though, is that everything is right there.  You could change the screen data, change the attributes, change the color, etc. etc. and it would all be very straightforward.
2022-12-24 16:33:15 <KipIngram   > Also, if you implemented printing by lines, it would be pretty straightforward to track dirty lines and only print the ones that had changed.
2022-12-24 16:33:43 <KipIngram   > And as a window grew larger, you could transition from window only print to full screen print whenever you wanted to; whichever you'd learned gave the best performance.
2022-12-24 16:34:01 <KipIngram   > It seems like a reasonable way to go about it all if I wanted to create my own curses-style windowing system.
2022-12-24 18:21:51 <KipIngram   > Oh, GOOD.  I actually managed to find my Verilog book.
2022-12-24 18:22:10 <KipIngram   > I've got quite a few books, and sometimes I have a devil of a time putting my eyes on a particular one.
2022-12-24 18:22:41 <thrig       > probably why they invented librarians
2022-12-24 18:25:08 <KipIngram   > Going to start trying to get some of this working in Verilog.  I've got Icarus Verilog installed, so maybe I can simulate some of it.
2022-12-24 19:20:32 <KipIngram   > This is nice:
2022-12-24 19:20:35 <KipIngram   > https://www.digikey.com/en/products/detail/newhaven-display-intl/NHD-4-3-800480CF-ASXP-CTP/11476262
2022-12-24 19:21:00 <KipIngram   > Maybe I can get one of those and work on driving it from the FPGA.
2022-12-24 19:27:41 <KipIngram   > And this:
2022-12-24 19:27:43 <KipIngram   > https://www.digikey.com/en/products/detail/mikroelektronika/MIKROE-4475/13679421?s=N4IgjCBcoCwGxVAYygMwIYBsDOBTANCAPZQDaIMAHJWDAMwgC6hADgC5QgDKbATgJYA7AOYgAvmMIAmMiABG6Nm1y8AnkzFA
2022-12-24 19:28:02 <KipIngram   > That's the kind of batter form factor I'd like for that pocket gadget.
2022-12-24 19:28:30 <KipIngram   > That looks equivalent to 2 or 3 18650's.
2022-12-24 19:28:47 <KipIngram   > Just a third of an inch thick.
2022-12-24 19:37:49 <KipIngram   > Ah, here another nice one:
2022-12-24 19:37:55 <KipIngram   > https://www.digikey.com/en/products/detail/globtek-inc/BL3000F9031781S1PCNC/14829887
2022-12-24 19:38:41 <KipIngram   > Smaller, only half the capacity, but with that one I could have one layer be the LCD, and then another layer split between battery and circuit board - and that would be it; just slip that into a case.
2022-12-24 19:39:06 <KipIngram   > All that with one of those iCE40 UltraPlus chips on the board - that might be a viable setup.
2022-12-24 19:39:36 <KipIngram   > 3D print the case.
2022-12-24 19:42:37 <KipIngram   > LCD panel looks to be about a quarter of an inch thick.  So all told it would be between half an inch and 2/3 of an inch.
2022-12-24 20:48:03 <MrMobius    > KipIngram: cool!
2022-12-24 20:48:09 <MrMobius    > Will it have keys?
2022-12-24 20:48:16 <MrMobius    > New Haven makes good displays
2022-12-24 20:51:36 <KipIngram   > No,  not planning any keys here.  Touchscreen with a self-implemented "Grafitti" only.
2022-12-24 20:53:16 <MrMobius    > Nice
2022-12-24 20:53:40 <MrMobius    > Just curious, plans yet for getting the FPGA onto a PCB?
2022-12-24 20:58:03 <KipIngram   > Well, no detailed plans, and this FPGA I'm working with at the moment won't do - it's a power hog and is way overpowered.  I'll know more about what to look for when I see how this one comes in resource-wise.
2022-12-24 20:58:30 <KipIngram   > But I like that little iCE40 UltraPlus; it's cheap, and I saw a Verilog processor design that fits it.
2022-12-24 20:58:44 <KipIngram   > I want to us my processor, but if his fit, hopefully  mine will to.
2022-12-24 20:58:57 <KipIngram   > It has about 5200 LUTs, and I'm thinking I'll come in well under that.
2022-12-24 20:59:12 <KipIngram   > But it also needs to hold the LCD / touch screen controller too.
2022-12-24 20:59:25 <KipIngram   > The flash and radio interfaces probably won't take too many bits - those will likely be serial.
2022-12-24 21:00:00 <KipIngram   > But as far as getting a PCB, I'll design it and get it built at some online fabricator.
2022-12-24 21:00:16 <KipIngram   > Get a stencil and reflow solder it in a toaster oven.
2022-12-24 21:00:31 <KipIngram   > I've still got the toaster oven I used to use for that when I was consulting 20 years ago in the attic storage.
2022-12-24 21:00:56 <KipIngram   > to make my wife happy the box is well labeled with a warning that the oven has been used to cook lead-bearing solder paste.  :-)
2022-12-24 21:01:53 <KipIngram   > That method went really well - you just clamp the stencil down on the bar board and squeegee solder paste into the holes.  Carefully lift the stencil off, and carefully place your parts in the right place.
2022-12-24 21:02:05 <KipIngram   > Hit it with the toaster oven the right way, and you've got a ready to go board.
2022-12-24 21:02:30 <KipIngram   > These are all things I've done personally in the past, so I'm not really worried about those phases.
2022-12-24 21:02:35 <KipIngram   > They're just laborious.
2022-12-24 21:02:46 <KipIngram   > But not really "hard."
2022-12-24 21:03:09 <KipIngram   > But I can get the code going to run the peripherals on this dev board I'm using now.
2022-12-24 21:03:24 <KipIngram   > I can really do everything with this dev board other than make something that goes in my pocket.
2022-12-24 21:04:05 <KipIngram   > I'll first get a Forth running on it via a serial connection to my computer.  Once that's solid I can wire on a peripheral and start bringing it up.
2022-12-24 21:09:23 <KipIngram   > Well, the VERY first thing I plan to do on the dev board is put a Verilog UART on it and set it up to "echo."  Get that chatty with the computer.
2022-12-24 21:09:45 <KipIngram   > Then start getting the processor up and running.
2022-12-24 21:11:20 <MrMobius    > Awesome. I have thought about reflowing but BGA is quite intimidating
2022-12-24 21:11:46 <KipIngram   > I'm still thinking about whether to give that SectorForth approach a try in this context.  The "initial system" in that fit in 512 bytes of x86 code.  In this application I wouldn't be subject to that 512-byte limit; the idea would just be to get something very minimal on there that would accept input from the computer and build a dictionary with it.
2022-12-24 21:11:56 <KipIngram   > Yeah - I'm avoiding BGA.
2022-12-24 21:12:12 <MrMobius    > Btw, Don Golding on the SVFIG meeting mentioned building a forth based tablet at the last one. He does a lot with forth on FPGAs
2022-12-24 21:12:18 <KipIngram   > I deliberately chose edge-pin-only parts for my little Digikey list just now.
2022-12-24 21:12:34 <KipIngram   > Nifty - I'll have to research.
2022-12-24 21:12:58 <MrMobius    > Good idea. I saw some were tqfp and so on. Seems ice40 is mostly bga
2022-12-24 21:14:03 <KipIngram   > At the moment the parts list contains LCD panel, iCE40 FPGA, 1 GB nand flash chip, a dual Bluetooth / WiFi transceiver chip, and a slim form factor 3 AH battery.
2022-12-24 21:14:11 <KipIngram   > So, none of the popcorn yet.
2022-12-24 21:14:32 <KipIngram   > Probably will want to add a battery management chip.
2022-12-24 21:14:44 <KipIngram   > Regulators, etc.
2022-12-24 21:14:57 <KipIngram   > And capacitors, of course.  :-)
2022-12-24 21:15:40 <KipIngram   > I'm hoping the battery and the circuit board can go "beside" each other on the same layer, but that may wind up being too tight.
2022-12-24 21:15:53 <KipIngram   > If not, then I'd need three layers and could get a bigger battery.
2022-12-24 21:17:19 <MrMobius    > Fingers crossed you don't need a 12 layer board
2022-12-24 21:17:23 <KipIngram   > Anyway, if I made that sectorforth style method work, then I could build the system on my computer and just pump it over to try it out.
2022-12-24 21:17:46 <KipIngram   > No kidding.  I generally consider six layers reasonable.
2022-12-24 21:17:59 <KipIngram   > Four is great, but it gets boxed in pretty fast.
2022-12-24 21:18:28 <KipIngram   > The FPGA, though will have a very generic pinout - I'll be able to put things where I want them.
2022-12-24 21:18:36 <KipIngram   > So hopefully things will be pretty "straight."
2022-12-24 21:18:45 <KipIngram   > And it's the hub of the whole thing.
2022-12-24 21:19:22 <KipIngram   > None of the other major parts connect to one another - just to the FPGA.
2022-12-24 21:19:56 <KipIngram   > Oh, I'll need to decide if I want an external RAM chip, but that will depend to some extent on how much RAM my chosen FPGA has.
2022-12-24 21:21:07 <MrMobius    > Usually isn't a few kb?
2022-12-24 21:21:28 <MrMobius    > You could even do DRAM if necessary
2022-12-24 21:21:35 <KipIngram   > Oh it can be tens of kB.  But I'm not really familiar with the terrain of the low-power stuff.
2022-12-24 21:21:56 <KipIngram   > Could, yeah - the FPGA could handle all the RAS/CAS stuff and the address multiplexing.
2022-12-24 21:22:51 <KipIngram   > Oh, another thing that will help this "bootloader" approach not need a lot of starting code space is that this is a Forth *processor*.  It's actual instructions are mostly directly Forth primitives, so those primitives don't have to be "coded."
2022-12-24 21:23:33 <KipIngram   > though a starting dictionary would have to be included, to map the incoming chars from the host onto instructions.
2022-12-24 21:24:40 <KipIngram   > Anyway, the whole roadmap here is a fairly big project, but so far I'm  having fun.
2022-12-24 21:25:04 <KipIngram   > And this has been something that's occasionally on my mind for a lot of years.
2022-12-24 21:25:41 <MrMobius    > I have started several projects, gotten really far on the software then not finished the hardware
2022-12-24 21:26:13 <MrMobius    > My new rule is to at least make workable hardware version before doing software now
2022-12-24 21:27:49 <MrMobius    > Just me though :)
2022-12-24 22:08:06 <KipIngram   > Well, that's at least how I'm thinking now, so first effort will be to get the FPGA design working.  But maybe you consider that software too?
2022-12-24 22:08:22 <KipIngram   > Maybe you're talking about the actual PCB for the final thing.
2022-12-24 22:08:38 <KipIngram   > Thing is, though, just seeing this processor work, even on the dev board, will feel like an "achievement" to me.
2022-12-24 22:08:45 <KipIngram   > It's a goal I've had for a long time.
2022-12-24 22:09:36 <KipIngram   > And also, say you put a prototype pocket unit together - how do you know if the hardware works or not?  You need SOME software to make it do something demonstrative.
2022-12-24 22:12:33 <KipIngram   > What I'm going for here on this pocket device is something that fits comfortably in the palm of my hand and will display and let me edit a 16-line, 64-char-per-line traditional block.
2022-12-24 22:13:54 <KipIngram   > Once it's running, I don't want to have to "tether it" to work on its software - I want to be able to develop "in motion," so to speak.
2022-12-24 22:14:07 <KipIngram   > And then plan a whole program of things to make it do.
2022-12-24 22:31:18 <KipIngram   > Hmmm.  GPS receivers are only a few bucks.  If there's room I could pop one of those on too.  :-)
2022-12-24 22:31:42 <thrig       > ... I hope you like jammin' too ...
2022-12-24 22:32:01 <KipIngram   > And all of this radio stuff, and anything else other than FPGA+LCD, should be power-downable.
2022-12-24 22:36:03 <KipIngram   > Yeah, I was just thinking about sound.  I'm planning Bluetooth, so there would be something to do with it.
2022-12-24 22:37:13 <KipIngram   > That iCE40 UP has special circuitry on it that's always on but super low power that's designed to facilitate voice recognition.  So I'd also thought about a microphone.
2022-12-24 22:37:27 <KipIngram   > Do some experimenting with talking to the thing.
2022-12-24 22:37:49 <KipIngram   > The idea is it could be powered down, but this circuitry will wake it up if it detects the command word, I'm guessing.
2022-12-24 22:48:55 <KipIngram   > And of course, with WiFi on there, I always could decide to tackle Chuck's advice and try to write a browser.
2022-12-24 22:49:07 <KipIngram   > Which would mean doing a TCP/IP stack from scratch too.
2022-12-24 22:49:23 <KipIngram   > I hate to even think about what a big job that would probably  be.  :-(
2022-12-24 22:50:32 <KipIngram   > I was talking the other day about cleverly doing the instruction encoding to simplify the decoding logic.
2022-12-24 22:50:38 <KipIngram   > But I don't know if there's any payoff in that.
2022-12-24 22:50:55 <KipIngram   > My instructions have six bits.  FPGA LUTs have six inputs.
2022-12-24 22:51:09 <KipIngram   > Therefore any of my control signals can be produced in one LUT.
2022-12-24 22:51:44 <KipIngram   > I can't do any better than that, unless I was able use the instruction bits directly, and I don't think that's possible.
2022-12-24 22:53:04 <KipIngram   > I might be able to save a few LUTs by going down that road, but I won't save a LUT *layer*.
2022-12-24 22:54:40 <KipIngram   > Of course, the LUTs in the iCE40UP only have four inputs.
2022-12-24 22:57:09 <KipIngram   > So it's probably worth investing some effort in, to pave the way for that.
2022-12-24 23:00:14 <KipIngram   > In the HP41CV instruction set, SWAP was called x<>y
2022-12-24 23:01:00 <KipIngram   > And there also existed x<>z and x<>t.  Also x<>reg, which printed as x<>R01 or something like that, and also x<>IndR1
2022-12-24 23:01:23 <KipIngram   > If I were going to port any of that to forth, I think I'd drop the x, since it's always there.
2022-12-24 23:01:29 <KipIngram   > So <>y <>z etc.
2022-12-24 23:01:45 <KipIngram   > And maybe the basic swap would just be <>
2022-12-24 23:01:54 <KipIngram   > I like short names.
2022-12-24 23:02:48 <KipIngram   > Maybe swap with the contents of an address could be
2022-12-24 23:03:17 <KipIngram   > <>m
2022-12-24 23:03:44 <KipIngram   > You could also have <>[m]
2022-12-24 23:06:06 <KipIngram   > Or maybe just <>[]
2022-12-24 23:06:43 <KipIngram   > Which would let you use a pointer without having to bring it to the stack.  ;-)
2022-12-24 23:07:35 <KipIngram   > That could be useful.
2022-12-24 23:13:49 <KipIngram   > @[] and ![] are possibly interesting too.
2022-12-24 23:15:33 <KipIngram   > MrMobius - I really am having a lot of fun with this work.  As I noted the other day, it's what I used to do for a living, and just having this kind of material rolling around in my head is "energizing" in a nice way.  It took 2-3 days to get "warmed up," but the gears seem to be turning a lot the way they used to now.
2022-12-24 23:15:39 <KipIngram   > That stuff was buried DEEP.
2022-12-24 23:16:18 <MrMobius    > That's really great
2022-12-24 23:22:24 <nuck[m]     > Somewhat silly question, but does there exist an online store that sells Forth merch, like mugs or sweatshirts with Swap-Swap on it
2022-12-24 23:31:27 <KipIngram   > I'm not aware of anywhere, and a quick search turned up nothing.
2022-12-24 23:31:46 <KipIngram   > But I'd probably enjoy a Forth coffee mug.
2022-12-24 23:32:50 <nuck[m]     > KipIngram: Me too
2022-12-24 23:32:53 <KipIngram   > We've got a java mug around somewhere.
2022-12-24 23:33:02 <KipIngram   > Not really sure how it found its way into the household.
2022-12-24 23:33:25 <nuck[m]     > I'd assume Brodie or Forth Inc retain a copywrite on his illustrations
2022-12-24 23:36:39 <KipIngram   > Maybe. The book itself is out there in the public domain, though.
2022-12-24 23:36:54 <KipIngram   > And you probably can find a place that will make you one-offs.
2022-12-24 23:37:22 <KipIngram   > I would think as long as you weren't operating a profit-making concern you'd be on fairly safe ground.
2022-12-24 23:40:49 <nuck[m]     > True
2022-12-24 23:46:28 <KipIngram   > You know, I hadn't even bothered to think about ROT and -ROT, but this design will do those as well without any trouble.
2022-12-24 23:47:39 <KipIngram   > It's quite rare for me to use those, but that's likely because of my stack access words, which I will no longer have on this processor.
2022-12-24 23:48:40 <KipIngram   > I could also do x<>z, if I wanted it.
2022-12-24 23:48:59 <KipIngram   > I've got 13-14 spare instruction codes.
2022-12-24 23:49:23 <KipIngram   > I don't want to just spend them thoughtlessly, but there's room for stuff if I really decide I want it.