2022-12-27 00:02:36 <MrMobius    > So the ram needs a clock edge after the address settles rather than just settling on its own with time?
2022-12-27 00:02:51 <KipIngram   > Correct; it loads it into internal registers.
2022-12-27 00:03:39 <KipIngram   > And for fastest possible cycle time on the RAM you also enable the output register.  Which means each cycle you get new output data after one clock-to-output register delay, but it's for the address you loaded LAST time.
2022-12-27 00:03:49 <KipIngram   > I see how that would be the fastest, if you can accommodate it.
2022-12-27 00:04:18 <KipIngram   > That output register is optional.
2022-12-27 00:04:24 <KipIngram   > The input register is not.
2022-12-27 00:04:43 <KipIngram   > But, for example, on IP.  I load my next IP into a register anyway.
2022-12-27 00:04:53 <KipIngram   > I had figured I'd just apply that register to the RAM.
2022-12-27 00:05:09 <KipIngram   > But there's no reason I can't apply the INPUTS to that register to the ram, since it's also going to register it.
2022-12-27 00:05:20 <KipIngram   > It'll just be a second copy of my IP.
2022-12-27 00:05:25 <KipIngram   > So that's no problem at all.
2022-12-27 00:05:34 <KipIngram   > Same with my read and write address registers.
2022-12-27 00:06:09 <KipIngram   > It's only on the stacks, where I have opcode-dependent address adjustments in play, that it's an issue.
2022-12-27 00:11:43 <KipIngram   > I don't even know my opcode bits until 0.71 ns after the clock.  And then they have to go through a layer of logic to get me my "adjust" values.  And then that and the stack pointers have to get added.  So I finally have stable addresses around a nanosecond or a bit over after the clock.
2022-12-27 00:14:00 <KipIngram   > But the block ram clock to output (without an output register) is nearly 3 ns.  So it may profit me to use a non-50% duty cycle clock, with the first half phase (while my logic is working) less than 50% and the second half cycle more than 50%, since that's where my long delay is.
2022-12-27 00:14:31 <KipIngram   > If I have to go with 50% then I'm looking at a 6ns clock period,which is just 167 MHz.
2022-12-27 00:15:11 <KipIngram   > This inversion is selectable on a per block ram basis, so I don't have to use it on the instruction and data rams.
2022-12-27 00:15:51 <KipIngram   > I don't know if handling those differently will buy me anything, though.
2022-12-27 00:17:08 <KipIngram   > At least I understand why they did this - it makes sense actually.
2022-12-27 00:18:14 <KipIngram   > If you were running a digital filter on a bunch of data, for example, it would work very well, and if you do use the output register then your delay goes from nearly 3 ns down to just a hair over 1 ns.
2022-12-27 00:19:37 <KipIngram   > You have to be careful moving away from a 50/50 clock, because that duty cycle can get distorted by the clock distribution network.  So you gotta have some safety margin.
2022-12-27 00:19:54 <KipIngram   > But it's looking like my first half cycle work will be MUCH faster than my second half cycle.
2022-12-27 00:20:22 <KipIngram   > I doubt there's a requirement on duty cycle per se - it's just that all the timing requirements associated with each edge have to be met.
2022-12-27 00:21:33 <KipIngram   > Maybe I could do 1.2 ns high / 3.2 ns low or something like that, and that would get me 227 MHz.
2022-12-27 00:27:57 <KipIngram   > Hmmm.  I think I may have overdesigned the data stack.  Right from the start I recognized "double popping" as an aggravating requirement.  I've been carrying that along with me throughout.
2022-12-27 00:28:23 <KipIngram   > But I think once I dropped standard ! from my instruction list, in favor of using the B address register, that requirement went away.
2022-12-27 00:28:45 <KipIngram   > The idea was that on ! I'd do the memory op and use one port to read into TOS and the other port to read into NOS.
2022-12-27 00:28:59 <KipIngram   > But I don't think I have a double pop requirement anymore.
2022-12-27 00:29:07 <KipIngram   > And that was the only thing that required that second port.
2022-12-27 00:29:28 <KipIngram   > Without that, I can use the other port as the standard data access port and map that RAM right into the address space.
2022-12-27 00:30:00 <KipIngram   > And I already decided earlier that I could map all the others in.
2022-12-27 00:30:11 <KipIngram   > Which would make all that earlier tonight hocus pocus go away.
2022-12-27 00:30:38 <KipIngram   > So I need to take a good hard look now at how to lay out all these RAMs.
2022-12-27 00:30:51 <KipIngram   > Where to put them in the address space.
2022-12-27 00:33:02 <KipIngram   > So when I'm pushing new data onto the stack, there's never any need to read anything.  It's only when I pop the stack I need to read something into NOS.
2022-12-27 00:34:48 <KipIngram   > Oh, ok - ROT and -ROT require both ports.  If I implement them.
2022-12-27 00:35:01 <KipIngram   > Because I have to both read from and write to the third stack item.
2022-12-27 00:35:25 <KipIngram   > Damn, maybe I'll cache 3rd on stack too, then.
2022-12-27 00:35:28 <KipIngram   > Just to avoid that.
2022-12-27 00:36:13 <KipIngram   > Really no reason I can't cache as many as I want.
2022-12-27 00:36:49 <KipIngram   > How often do you guys use ROT and -ROT?
2022-12-27 00:37:10 <KipIngram   > I'm not well calibrated because I have those stack frame words and do things in a different way.
2022-12-27 00:45:51 <KipIngram   > So, this part has 135 36kbit block rams.  The extra four are parity, but can be used for data is desired.
2022-12-27 00:46:09 <KipIngram   > But basically that's 4  kB, so that's 128 32-bit wide cells.
2022-12-27 00:46:20 <KipIngram   > If I do 32-deep stacks, one of those will hold four stacks.
2022-12-27 00:46:34 <KipIngram   > For four threads.
2022-12-27 00:47:03 <KipIngram   > 135*4kB is 540 kB.
2022-12-27 01:18:26 <KipIngram   > Ok, here's a cleaner way to handle interrupts.
2022-12-27 01:18:59 <KipIngram   > Instead of op_control "implementing" rep internally, it will just return to its "ready" state but with a rep signal asserted back up to ir_control.
2022-12-27 01:19:13 <KipIngram   > If ir_control sees rep, it will just feed op_control the same instruction word again.
2022-12-27 01:19:45 <KipIngram   > If there's an interrupt pending, it can go run that instead and continue sending the instruction word when it gets back.
2022-12-27 01:19:58 <KipIngram   > It's cleaner for ir_control to handle it - it manages IP anyway.
2022-12-27 01:20:11 <KipIngram   > op_control really has no business considering such things.
2022-12-27 01:21:05 <KipIngram   > It's a little slower, because it inserts the instruction word feed cycle each time around.  But it's a lot "cleaner" and makes op_control's job more "standard."
2022-12-27 01:23:58 <KipIngram   > What will happen is that ir_control will push the return address.  But instead of pushing the "next" instruction cell, it will see rep and will push the current instruction cell (onto the return stack).  And it'll be the irq vector that gets fed to op_control next.
2022-12-27 01:24:59 <KipIngram   > This may be optimizable - maybe rep can also at least know if interrupts are pending, and if none are it can bypass that extra state.
2022-12-27 01:25:13 <KipIngram   > going all the way back to zero will just b ehow it "pauses" to allow the interrupt.
2022-12-27 06:00:59 <veltas      > What is the point of packing operations? I don't understand what the motivation is
2022-12-27 06:02:42 <veltas      > Chuck Moore said at some point ?DUP is a bad word, because of the variable number of results
2022-12-27 06:03:00 <veltas      > I'm inclined to agree, although it makes me a hypocrite
2022-12-27 06:04:14 <dave0       > variable numbers of results is my favorite!
2022-12-27 06:04:51 <dave0       > i return   <value>, true   on success and simply    false    on error
2022-12-27 06:06:39 <dave0       > i have a word    : char? ( c-addr n -- c-addr n char true | c-add n false ) dup 0> IF over c@ true ELSE false THEN ;
2022-12-27 06:07:40 <dave0       > i use it like    : type ( c-addr n -- ) BEGIN char? WHILE emit 1 /string REPEAT 2drop ;
2022-12-27 09:33:56 <KipIngram   > veltas: makes the code more compact.
2022-12-27 09:34:52 <KipIngram   > Doesn't really matter as much these days as it used to - at least not on "typical computers."  But it still might matter in an embedded situation.  More compact code - more functionality in a given amount of code memory.
2022-12-27 09:35:36 <KipIngram   > But my own choice to do it is a somewhat arbitrary one - I just feel it's "less wasteful," and it's how Chuck did it.
2022-12-27 09:35:59 <KipIngram   > Ultimately I'm doing this all for fun, and it just feels more "right" to me to do it this way.
2022-12-27 09:36:20 <KipIngram   > If I only have 50 instructions, why would I want to use 32 bits to specify each one?
2022-12-27 09:37:08 <KipIngram   > Granted, it would probably simplify the logic.  If I were gunning for "simplest possible logic," then a wide instruction word would likely be the way to go, because bits of the instruction word could then directly control various pieces of hardware, with no decoding required.
2022-12-27 09:37:19 <veltas      > Is it more compact than a tokenised forth?
2022-12-27 09:37:31 <veltas      > i.e. where your average op is 1 byte
2022-12-27 09:37:34 <veltas      > e.g.
2022-12-27 09:38:33 <KipIngram   > Probably not.  The machine instructions are as compact here as they can be, but I will be using 32-bit addresses for the defined words.
2022-12-27 09:38:46 <KipIngram   > And I'm doing that just because it's "how Forth is done" in my eyes.
2022-12-27 09:39:14 <veltas      > crc: what about retro's instructions?
2022-12-27 09:39:25 <KipIngram   > BTW, I'd argue that if wanted to define a large number of words you couldn't stick to one byte size on average indefinitely.  Sooner or later you have more than 256 things to do, so it will take more than eight bits to call them out.
2022-12-27 09:40:01 <veltas      > Yeah but that's why you have i.e. relative call tokens
2022-12-27 09:40:18 <KipIngram   > yeah, that would help.
2022-12-27 09:40:27 <veltas      > That calls up to 256 bytes behind, 65536 bytes behind, etc
2022-12-27 09:40:30 <KipIngram   > Probably a fair bit - I don't reject your "around" one byte value.
2022-12-27 09:40:48 <KipIngram   > I don't regard this unpacking process as excessively hard.
2022-12-27 09:41:08 <KipIngram   > And decoding a six bit instruction is easy as pie - I only need one LUT per control signal (since my LUTs have six inputs).
2022-12-27 09:41:14 <veltas      > So you can encode your average less common word in 2-3 bytes
2022-12-27 09:41:25 <KipIngram   > Yeah, I buy the argument.
2022-12-27 09:41:31 <KipIngram   > Just not how I want to do it.
2022-12-27 09:41:32 <veltas      > I'm saying for posterity
2022-12-27 09:42:08 <veltas      > If the aim is compactness then tokens seem the way to go, I'd never prescribe it
2022-12-27 09:42:32 <KipIngram   > This is loosely based one of Chuck's processors.  In his case he backed three five bit opcodes into each 16-bit word, and compiled definitions were specified by their 15-bit address.
2022-12-27 09:42:47 <KipIngram   > That one leftover bit in each word told him which of those two things it was.
2022-12-27 09:43:21 <KipIngram   > 32 bits gives me the option of five 6-bit opcodes or six 5-bit opcodes, with two bits leftover.
2022-12-27 09:43:38 <KipIngram   > And having two leftover bits instead of one is nice; I can use the extra bit to handle tail optimization.
2022-12-27 09:44:07 <KipIngram   > Anyway, there are some delicate things to handle in this design, but unpacking the opcodes isn't one of them.
2022-12-27 09:45:00 <KipIngram   > And re: tokenied systems, they've just never appealed to me.  They're going to be slightly lower performance than a threaded system, and while that may not be much of a difference if the token system is "done well," I just don't cotton to it.
2022-12-27 09:45:30 <KipIngram   > I definitely think tokenized systems have their place, though.
2022-12-27 09:47:25 <veltas      > I wonder how performance actually compares on modern systems
2022-12-27 09:47:54 <veltas      > Tokenised probably not *that* much slower in practice on modern chips
2022-12-27 09:48:14 <KipIngram   > Well, I said as much above.
2022-12-27 09:48:50 <KipIngram   > I agree.
2022-12-27 09:48:55 <veltas      > My ZX Spectrum forth has a compile-time flag to switch between DTC and tokenised
2022-12-27 09:49:12 <KipIngram   > But it can't be AS good, because you have to do a table looking up that you don't do in a threaded system.
2022-12-27 09:49:18 <veltas      > The performance is noticeably different, but not by an order of magnitude
2022-12-27 09:49:46 <veltas      > On a modern system I'd expect less difference on normal code, maybe worse performance on contrived scenarios and some calculation intensive stuff
2022-12-27 09:49:50 <KipIngram   > yeah, that sounds reasonable to me.  I mean, it should be just one RAM read each time, right?
2022-12-27 09:49:57 <KipIngram   > That's not a very time consuming thing.
2022-12-27 09:50:04 <crc         > veltas: http://sprunge.us/eA3LXF for ilo (my newer, block based system) and
2022-12-27 09:50:04 <crc         > http://sprunge.us/vlP0JB for nga, the older system
2022-12-27 09:50:11 <veltas      > Thanks
2022-12-27 09:50:29 <veltas      > KipIngram: on the spectrum?
2022-12-27 09:50:39 <veltas      > Or modern systems?
2022-12-27 09:50:43 <KipIngram   > And that RAM data is quite likely to get cached, so... fast.
2022-12-27 09:51:04 <KipIngram   > Cache memory has changed the terrain in this stuff quite a lot.
2022-12-27 09:52:12 <crc         > veltas: and http://sprunge.us/t5gp6g for napia (in between ilo & nga in size & complexity)
2022-12-27 09:53:14 <veltas      > I like the 64K cell limit
2022-12-27 09:53:55 <veltas      > Looking at ilo first
2022-12-27 09:54:13 <crc         > I've been using retroforth/ilo as my main environment for the last year
2022-12-27 09:54:38 <KipIngram   > I've definitely felt the temptation to restrict code to the bottom 64k and go with 16-bit addresses.
2022-12-27 09:54:55 <KipIngram   > Still might; it's a recurring temptation.
2022-12-27 09:55:01 <veltas      > Ah I see you use correct-endian representation :)
2022-12-27 09:55:15 <KipIngram   > Hahahaha - which one is that, veltas?
2022-12-27 09:55:19 <veltas      > little
2022-12-27 09:55:26 <veltas      > Not bad-endian as I call it
2022-12-27 09:55:33 <KipIngram   > Good - I agree that's most "consistent."
2022-12-27 09:55:34 <veltas      > Or blue-endian/IBMdian
2022-12-27 09:55:55 <KipIngram   > It means you use the same address for any size reference.
2022-12-27 09:56:12 <veltas      > Yeah, and the maths for combining bytes is simpler
2022-12-27 09:56:15 <veltas      > hex dumps are worse
2022-12-27 09:56:16 <KipIngram   > It does mean that strings "sort" the opposite way from numbers.
2022-12-27 09:56:19 <veltas      > Those are the tradeoffs
2022-12-27 09:56:32 <veltas      > I'd rather have any-size accesses truncate rather than give weird garbage
2022-12-27 09:56:40 <KipIngram   > Yeah - I agree.
2022-12-27 09:57:44 <veltas      > I'm assuming byte order usually is irrelevant since it's a word addressed system
2022-12-27 09:58:22 <KipIngram   > In my system?  It was initially but now I'm planning to support word and byte accesses.
2022-12-27 09:59:08 <KipIngram   > Turns out that the block rams directly support byte enables, and I deided that the logic to support those wasn't that excessive.
2022-12-27 09:59:25 <veltas      > In crc's ilo
2022-12-27 09:59:33 <KipIngram   > Ah, ok.
2022-12-27 09:59:37 <veltas      > Word addressing is superior, in my opinion
2022-12-27 09:59:59 <veltas      > But I am pragmatic on this regard, I do byte addressing everywhere
2022-12-27 10:01:03 <veltas      > Indexing array of numbers should be as simple as adding the index to the address of first element
2022-12-27 10:01:27 <KipIngram   > I agree.
2022-12-27 10:01:37 <veltas      > a[b] === *(a+b) etc came from this feature of word addressed systems
2022-12-27 10:01:47 <KipIngram   > Maybe it's just because I've mostly used little endian systems over the years, but I definitely prefer them.
2022-12-27 10:02:00 <thrig       > also [] were new things on the keyboard
2022-12-27 10:02:41 <KipIngram   > Well, in a[b] = *(a+b) the compiler is doing some things for you.
2022-12-27 10:02:52 <KipIngram   > It's doing that "multiply" under the hood.
2022-12-27 10:02:54 <veltas      > In C, but in B it did exactly what you said
2022-12-27 10:03:01 <thrig       > and also [b]a works, obviously
2022-12-27 10:03:08 <KipIngram   > Ah, not familiar with B.
2022-12-27 10:03:08 <veltas      > Types were added to C to allow B idioms on a byte addressed system
2022-12-27 10:03:18 <KipIngram   > Got it - that makes sense.
2022-12-27 10:03:36 <veltas      > B was designed for word addressing, B is awesome and well worth learning for history, especially if you work with C
2022-12-27 10:03:41 <veltas      > It's very forthy honestly
2022-12-27 10:03:47 <veltas      > Given it's another typeless language
2022-12-27 10:03:53 <KipIngram   > Cool - I'll take a look at it.
2022-12-27 10:03:57 <KipIngram   > I like Forthy.
2022-12-27 10:04:15 <veltas      > And it's quite succinct
2022-12-27 10:04:18 <KipIngram   > This morning I want to firm up this interrupt support.
2022-12-27 10:04:36 <KipIngram   > Last night I thought I saw a clean path; we'll see if it holds together under scrutiny.
2022-12-27 10:05:09 <KipIngram   > I think ir_control should make the interrupt decision, not op_control.
2022-12-27 10:05:42 <KipIngram   > And op_control won't be allowed to re-run a cell indefinitely; it'll have to have "permission" from ir_control to do that rep stuff.
2022-12-27 10:06:04 <veltas      > A function was a statement, not a block, so you could write one-liners like `factorial(n) return n<2 ? 1 : n*factorial(n-1);`
2022-12-27 10:06:23 <KipIngram   > That seems nice.
2022-12-27 10:06:38 <veltas      > And I will stop talking about B now because this is ##forth :P
2022-12-27 10:10:56 <veltas      > KipIngram: So is there a repeat that can occur mid-cell when reading a cell of instructions?
2022-12-27 10:14:40 <KipIngram   > Yeah, that's rep.  There will be a down counter, and rep will decrement it and if it's not yet 0 it will re-start the current cell.
2022-12-27 10:15:16 <KipIngram   > That'll only do quite short loops, but it will do them really fast.
2022-12-27 10:15:37 <KipIngram   > Most overtly it'll support fast string moves.
2022-12-27 10:15:58 <KipIngram   > That coupled with the address register pair; those addr regs will be able to post-increment.
2022-12-27 10:17:06 <KipIngram   > The issue last night was the right way to handle interrupts in that context.
2022-12-27 10:17:27 <KipIngram   > My original plan had been to check for interrupts on a cell-by-cell basis, to avoid the need to "return into the middle" of a cell.
2022-12-27 10:17:58 <KipIngram   > But my original rep notion has op_control just running it all the way through, internally, which would mean interrupt check wouldn't come until after the whole count-down.
2022-12-27 10:18:07 <KipIngram   > I'm now planning to check each trip through the cell.
2022-12-27 10:18:14 <KipIngram   > But not after each opcode.
2022-12-27 10:39:05 <KipIngram   > Oh, that looks... pretty simple.  The iram_control stuff.
2022-12-27 10:40:06 <KipIngram   > iram_control will have both the currently executing ip and the "incremented" ip.  On calls, we'll push one or the other to the return stack; depending on whether we are "rep-ing" or not.
2022-12-27 10:40:32 <KipIngram   > So if an irq is pending, the addr of the rep cell will get pushed for us to return to later.
2022-12-27 10:41:46 <KipIngram   > Also, rep will cause op_control to go to an earlier state.  If there's an irq pending it will go all the way back to state 0, where it will wait for the instruction word to be re-presented.  If no irq, then it will go back to state one (reloading the IW so it can shift through it again).  So we don't pay that overhead cycle on rep when there is no irq.
2022-12-27 10:43:15 <KipIngram   > What I've drawn here assumes some other circuit exists which will present the vector address of any pending interrupt.
2022-12-27 10:44:14 <KipIngram   > Contral will transfer directly to the vector address, but what I'll have there will be a jump instruction to the actual irq handler.
2022-12-27 10:44:52 <KipIngram   > But the content of that location will be treated as code, not as a lookup-address.
2022-12-27 10:54:04 <KipIngram   > I guess this is also where I'll halt to wait for interrupts; there's a "valid" signal this module sends to op_control to tell it to do work.  I just won't send that if we're halted, until an interrupt shows up.
2022-12-27 12:11:58 <veltas      > The thing about 64K (whether bytes or cells, but bytes is obviously more limited) is it's comfy, but there are some reasonable things that can't be achieved in 64K
2022-12-27 12:12:11 <veltas      > Whereas 4G is big enough for any problem I could care about
2022-12-27 12:12:59 <veltas      > I suppose you can use your I/O to work around limitations if you need to, but probably would have an unreasonable performance impact?
2022-12-27 12:41:42 <KipIngram   > Yes, that was my original reasoning.  I can "imagine" running out of room in a 64k address space.
2022-12-27 12:42:08 <KipIngram   > I know there are applictions that need more that 4 GB too, but I doubt I'll be doing any of them.  I can't imagine filling up 4G, particularly not with CODE.
2022-12-27 12:43:50 <MrMobius    > What will this device have to do?
2022-12-27 12:44:15 <crc         > I have not found a 64k address space to be problematic in the last year, with the possible exception of a graphical display; framebuffers can get pretty big.
2022-12-27 12:44:23 <veltas      > Yeah I will never fill 4G of 'RAM' with code or any data I create
2022-12-27 12:45:29 <KipIngram   > Well, for one thing I just want to see it work, MrMobius.  But in general I'd like to use it or a derivative of it for any sort of hardware I might decide to build in the future.  An example is that pocket touch screen thing I've talked about the last few days.
2022-12-27 12:45:36 <veltas      > I've definitely filled more than 64K with programs at work, but maybe they're 'bloated' in some way, maybe they'd be more compact in your VM,....
2022-12-27 12:45:41 <KipIngram   > That wouldn't use this Xilinx chip - it's too power hungry.
2022-12-27 12:45:51 <KipIngram   > But it could use the same processor architecture in a different device.
2022-12-27 12:46:26 <KipIngram   > There are a number of things I've thought at times about building.  I can almost guarantee I won't build all of them, but maybe I'll build a few.
2022-12-27 12:46:35 <KipIngram   > Some of them would plug in and the  Xilinx chip would be fine.
2022-12-27 12:47:00 <MrMobius    > KipIngram: that's what I mean. What will the pocket device do? Just curious since that dictates ram usage
2022-12-27 12:47:01 <KipIngram   > Well, likely your build process slurps in a bunch of unused library code.
2022-12-27 12:48:04 <veltas      > Me?
2022-12-27 12:48:05 <KipIngram   > Oh, well, I want to just work on making it do various things.  But I might write "organizer" software that works exactly the way I want it to, I might use it to tote pictures around with me, or music, or whatever.  I just want to see those functions live on something I made myself.
2022-12-27 12:48:22 <KipIngram   > Yeah, I was speculating that that's part of how you got over 64k of code.
2022-12-27 12:48:27 <veltas      > This project at work is all our own code so no
2022-12-27 12:48:47 <KipIngram   > Well, ok.  I guess it was done over a long period of time by a team?
2022-12-27 12:48:54 <veltas      > Yes
2022-12-27 12:48:59 <MrMobius    > I bet you could go over 64k code trying to do all that
2022-12-27 12:49:06 <KipIngram   > Well, as I said, I can readily imagine it for 64k.
2022-12-27 12:49:20 <KipIngram   > Over a period of years I could IMAGINE using that space up myself.
2022-12-27 12:49:25 <KipIngram   > But it would take a while.
2022-12-27 12:49:33 <veltas      > Really depends what kind of code you're writing
2022-12-27 12:49:38 <KipIngram   > Yeah.
2022-12-27 12:50:02 <MrMobius    > It goes fast. No prob filling 10k with assembly (ie no bloat) or C with no more than a few hundred bytes of cruft
2022-12-27 12:50:39 <KipIngram   > Oh, sure - my system is up to around 18k - 19k right now.
2022-12-27 12:51:00 <KipIngram   > But that seems about right for a reasonably complete  Forth that uses 32-bit xts.
2022-12-27 12:51:12 <KipIngram   > I usually think "around 8kB" for a 16-bit system.
2022-12-27 12:51:52 <veltas      > My 8-bit forth is under 8K
2022-12-27 12:52:23 <veltas      > 7358 bytes at current count
2022-12-27 12:52:39 <veltas      > Z80 is quite compact so that wasn't even hard
2022-12-27 12:52:40 <KipIngram   > :-)  Nice.
2022-12-27 12:53:04 <veltas      > I would say 6502 is harder, but that really depends on how many CODE words you have
2022-12-27 12:53:42 <veltas      > If you have a threaded forth with minimal CODE words then 6502 could be quite small too, and that's probably the big advantage of Forth with 6502 in the first place
2022-12-27 12:53:45 <veltas      > 6502 is dense
2022-12-27 12:53:54 <veltas      > Or rather, it's verbose
2022-12-27 12:54:27 <MrMobius    > I would be curious to see the size trade off of Z80 vs 6502
2022-12-27 12:54:44 <MrMobius    > Not that I want to reignite flame wars from the 1980s :P
2022-12-27 12:54:54 <veltas      > I didn't think it was controversial
2022-12-27 12:54:58 <KipIngram   > I'm torn over how to think about external RAM for this thing.  There are some fast RAM chips out there, but they're not as fast as the block RAM.
2022-12-27 12:55:11 <veltas      > 6502 is pretty verbose
2022-12-27 12:55:29 <MrMobius    > I mean there are pages of forum posts of people screaming at each other saying one is trash and the other not so treading lightly
2022-12-27 12:55:38 <KipIngram   > I feel like it should run as fast as the block RAM will allow, and if that means waiting a beat for external RAM access, so be it.  But that totally changes the way I'd work with external  RAM.
2022-12-27 12:55:49 <KipIngram   > I'd tend to  "page it in" - treat it like storage.
2022-12-27 12:55:54 <veltas      > MrMobius: Not to say that makes 6502 bad, but I think its verbosity is uncontroversial
2022-12-27 12:56:12 <KipIngram   > I don't know 6502, but I have always heard that about it.
2022-12-27 12:56:22 <KipIngram   > I once knew it a little, from a "reading about it" perspective.
2022-12-27 12:56:25 <veltas      > It's easy to learn right now, it's a very tiny arch
2022-12-27 12:56:33 <KipIngram   > Bought a book describing it and read that.
2022-12-27 12:56:40 <KipIngram   > Back when such books were common in bookstores.
2022-12-27 12:56:41 <MrMobius    > ventas, could be. Have any numbers? I think it's pretty good for 8 bit stuff but could see it being bigger for 16 bit
2022-12-27 12:57:27 <MrMobius    > 16 bit data I mean. 16 bit pointers are easy
2022-12-27 12:57:40 <veltas      > I'm basing this on 6502 and Z80 programs. 6502 programs are full of extra work and produce larger binaries, it's obvious to people doing it
2022-12-27 12:57:52 <veltas      > You can also look at the different approaches to C compilers
2022-12-27 12:58:15 <veltas      > Z80 C compilers generate Z80, 6502 C compilers tend to produce essentially threaded code, whether STC or otherwise
2022-12-27 12:58:20 <MrMobius    > I'll make myself a note to give it a try. I'm unconvinced for now :)
2022-12-27 12:58:51 <veltas      > Nothing wrong with being sceptical, I don't know what I've done to earn your distrust but I'm guessing there are articles explaining more out there
2022-12-27 12:59:07 <MrMobius    > Which C compiler? Cc65 is the most popular which definitely does not produce threaded code
2022-12-27 13:00:03 <KipIngram   > Oh, also, I set aside the idea of having EXECUTE be able to take a word of packed opcodes.  It will have to be an address.
2022-12-27 13:00:09 <MrMobius    > veltas, ya could be articles. I've just written mountains of 6502 code and would be skeptical there is much difference for 8 bit data stuff. Ill have to see what I find thoygh
2022-12-27 13:01:00 <KipIngram   > I'm somewhat bothered by that and may revisit it.
2022-12-27 13:01:12 <KipIngram   > But I don't quite see the "nice" way of doing it yet.
2022-12-27 13:01:33 <MrMobius    > CC65 by the way does optimizations too though the output is admittedly not great. There is a lot of further optimizing you could do despite it not being easy to optimize for
2022-12-27 13:01:42 <veltas      > MrMobius: Have you written much Z80?
2022-12-27 13:02:14 <MrMobius    > No just a passing interest from calculator stuff
2022-12-27 13:02:54 <veltas      > I think it was CC65 I used, what I mean is if I remember its output is mostly just JSR's
2022-12-27 13:03:09 <MrMobius    > Definitely not CC65 then
2022-12-27 13:03:10 <veltas      > With some static library of common operations
2022-12-27 13:03:19 <MrMobius    > Well, depends on your code of course :P
2022-12-27 13:03:35 <veltas      > I don't mean multiplies etc obviously
2022-12-27 13:03:38 <MrMobius    > You could write C code that generates mostly JSRs I mean
2022-12-27 13:05:07 <MrMobius    > I know I've showed this before but the article about the little game I made for the 6502 has some CC65 examples: http://calc6502.com/RobotGame/summary.html
2022-12-27 13:05:08 <veltas      > Yeah
2022-12-27 13:05:47 <veltas      > Well it seems logical to me that Z80 is more compact, you've got a load of registers, most simple instructions encode the register within the first byte
2022-12-27 13:06:02 <veltas      > There are some extended instructions that have a prefix or two, but you're not forced to use those really
2022-12-27 13:06:10 <MrMobius    > Could you be thinking of SDCC? Doesn't support 6502 but I looked at that for 8051 and it was tons of subroutine calls
2022-12-27 13:06:10 <veltas      > And often you avoid them anyway because they're sloewr
2022-12-27 13:07:01 <MrMobius    > Ya it would be interesting to compare. Zero page on 6502 saves a lot of space and cycles
2022-12-27 13:08:34 <veltas      > To address zero page you have an immediate byte, so if you need a handful of 'registers' you are already adding a lot of extra bytes
2022-12-27 13:09:00 <veltas      > And you have to be moving stuff in and out of A constantly
2022-12-27 13:09:09 <veltas      > You obviously don't have to always do that but often you do
2022-12-27 13:10:43 <MrMobius    > Right
2022-12-27 13:11:01 <MrMobius    > How many single byte instructions do you get on Z80 then for example?
2022-12-27 13:16:55 <veltas      > Related https://web.eece.maine.edu/~vweaver/papers/iccd09/iccd09_density.pdf
2022-12-27 13:17:05 <veltas      > Although the 6502 results are disputed
2022-12-27 13:17:31 <veltas      > Trust me I'm not invested in this, I don't really care, it just seemed 'obvious' to me 6502 is more verbose, but maybe I'm wrong
2022-12-27 13:17:43 <veltas      > I'm not dying on a hill over this
2022-12-27 13:20:06 <veltas      > Things like 8-bit add/sub/sbc/and/xor/rol/ror/ld/inc/dec/cmp with register arguments are 1 byte
2022-12-27 13:20:19 <MrMobius    > Ya not taking it personal either
2022-12-27 13:20:28 <veltas      > Some of those require A as the destination
2022-12-27 13:20:34 <veltas      > Most of them I think
2022-12-27 13:20:41 <veltas      > LD can be done between any two registers
2022-12-27 13:21:10 <veltas      > https://www.zilog.com/docs/z80/um0080.pdf
2022-12-27 13:21:31 <veltas      > The official manual has modern typesetting so is easy to browse/read
2022-12-27 13:21:37 <veltas      > Although it has some mistakes.....
2022-12-27 13:27:08 <veltas      > It also has a two byte instruction that does memcpy
2022-12-27 13:28:15 <veltas      > Relative jumps are 2 bytes (like 6502), calls are 3 bytes (like 6502)
2022-12-27 13:28:56 <veltas      > If you use the shadow registers for interrupt context saving as they were intended, then saving/restoring interrupt state is 2 bytes
2022-12-27 13:29:43 <MrMobius    > 3 bytes on modern 6502 and 5 bytes on original for saving regs in interrupt if you need all 3
2022-12-27 13:30:08 <veltas      > What do you mean 'modern 6502'?
2022-12-27 13:31:02 <MrMobius    > 65C02. Made nowadays in CMOS so ~20x less current consumption and bumped speed to 14mhz
2022-12-27 13:31:35 <MrMobius    > Added some addressing modes and instructions. Quality of life things like STZ and push/pull X and Y without transferring to A first
2022-12-27 13:31:56 <veltas      > I was talking about 6502, not 65C02
2022-12-27 13:32:39 <MrMobius    > Ok. I don't think the difference in binary size is more than 1-2%
2022-12-27 13:36:30 <veltas      > MrMobius: What's a decent 6502 forth?
2022-12-27 13:36:33 <veltas      > In terms of code size?
2022-12-27 13:36:50 <veltas      > I tried comparing but the one I found for 6502 looks suboptimal
2022-12-27 13:37:05 <veltas      > I'm going to compare with mine which I don't consider "optimal" but it's not terrible
2022-12-27 13:37:40 <MrMobius    > Hard to compare apples to apples but Tali Forth 2 is a nice STC one. Comes in around 30k iirc including block editor and assembler/disassembler I think
2022-12-27 13:38:28 <MrMobius    > Just the core for the 6502 forth I was working on for my calculator is 1k now but might have to add a little more. That's not outer interpreter or anything though
2022-12-27 13:38:40 <veltas      > I think fig forth might be more comparable
2022-12-27 13:39:01 <veltas      > 1K is quite good for core
2022-12-27 13:39:07 <MrMobius    > Could be
2022-12-27 13:39:38 <veltas      > https://dwheeler.com/6502/fig-forth_6502.pdf
2022-12-27 13:42:10 <veltas      > Because 30K is not very good, even with editor and assembly (6502 assembler is a lot smaller than Z80 assembler, an advantage of 6502)
2022-12-27 13:42:16 <veltas      > But I am guessing they are optimising for speed
2022-12-27 13:42:21 <veltas      > Because it's STC
2022-12-27 13:42:33 <veltas      > It seems like they wanted a performant rather than compact env
2022-12-27 13:44:39 <MrMobius    > Right so hard to compare
2022-12-27 13:45:14 <MrMobius    > Do you have any Z80 assembly that does something bon trivial for comparison? I could try to do the same in 6502
2022-12-27 13:51:58 <veltas      > My "+" is 5 bytes:  POP DE;  ADD HL, DE;  JP next
2022-12-27 13:52:00 <veltas      > 6502 fig forth plus is 18 bytes, see it on page 19 of the scan PDF
2022-12-27 13:52:56 <MrMobius    > I'm not sure that qualifies as non trivial :P
2022-12-27 13:53:08 <veltas      > No but it is an interesting case
2022-12-27 13:53:38 <veltas      > If your program has a large amount of factorisation/abstraction then that looks similar on both because call instruction is 3 bytes, return is 1 byte
2022-12-27 13:55:05 <MrMobius    > Ya
2022-12-27 13:55:32 <MrMobius    > I imagine whether you're doing primarily 8 or 16 bit operations makes a difference too
2022-12-27 13:56:50 <veltas      > Z80 has a big advantage on 16-bit ops yeah, it actually has some simple 16-bit operations
2022-12-27 13:56:59 <MrMobius    > Right
2022-12-27 14:08:02 <veltas      > I've found a highly respected, authoritative, and unquestionable source https://retrocomputing.stackexchange.com/a/24530/9102
2022-12-27 14:16:08 <veltas      > What is interesting though is reading about this, and I don't deny this, BASIC's written for Z80 tended to be far slower than BASIC's written for 6502
2022-12-27 14:16:48 <veltas      > And honestly I think this is a coincidence, or some other factor, because my Forth for instance is waaaaaay faster than the BASIC that comes with the spectrum
2022-12-27 14:17:32 <veltas      > I think the people making the early Z80 machines were writing cheap and cheerful ROMs
2022-12-27 14:18:44 <veltas      > These same 3-4MHz Z80 processors were used for like a decade though, with CP/M machines, amstrads etc, which probably squeezed more performance out of them
2022-12-27 14:20:37 <KipIngram   > I imagine there was quite a lot of what you might call "wildcat activity" going on in the industry in those days.
2022-12-27 14:20:51 <KipIngram   > Get something working at get it out the door as quickly as possible.
2022-12-27 14:21:13 <KipIngram   > I do think there was a period in the computer biz that kind of resembled the oil wildcatting days.
2022-12-27 14:21:14 <thrig       > getting that unicorn up and running still happens...
2022-12-27 14:21:35 <KipIngram   > In a way those are exciting times in an industry.
2022-12-27 14:21:41 <veltas      > Honestly the ZX Spectrum ROM is really good in places, it's bad engineering methodology that probably screwed them over
2022-12-27 14:21:47 <veltas      > Should have been doing agile/scrum :P
2022-12-27 14:21:49 <KipIngram   > You kind of have no idea what's about to show up in the next month or two.
2022-12-27 14:22:06 <thrig       > hard to do something that didn't exist yet
2022-12-27 14:22:29 <KipIngram   > Oh sure - "real" development, of new things, can't be predicted worth squat.
2022-12-27 14:22:52 <veltas      > It's typical to see really intelligent programmers write code that performs like crap, if there is no incentive to profile etc
2022-12-27 14:22:52 <KipIngram   > and certainly not in some "quantitative" way that will pass modern coporate inspection.
2022-12-27 14:23:04 <veltas      > If they had written more BASIC example programs they probably would have optimised it more
2022-12-27 14:23:07 <KipIngram   > Someone with some experience under their belt can "make a guess," and maybe it will turn out close.
2022-12-27 14:23:20 <thrig       > otoh there is https://danluu.com/futurist-predictions/
2022-12-27 14:23:47 <KipIngram   > but then there are also "cookie cutter engineering" projects, where what you're doing is a lot like what you've done - except just not "in detail."  Those can be predicted and scheduled pretty well.
2022-12-27 14:24:24 <KipIngram   > Back at my old place we had the "new generation of programmer" projects that were never easy to prognosticate, but we also had "socket modules" that adapted the programmers to a new device package, and they were cookie cutter.
2022-12-27 14:24:53 <KipIngram   > Mostly just a circuit board with a socket on it, though there was a little bit of circuitry (ground transistors, mostly).
2022-12-27 14:25:43 <KipIngram   > That circuitry didn't change much, though; we'd just shift a control pattern into a long shift register to apply short ground paths to whatever pins of the package we wanted.
2022-12-27 14:27:03 <KipIngram   > In the early days we had generic pin drivers for each pin, but later when we made the programmers faster there was a "data bus" of specific drivers that we had to be able to map onto wherever the data pins were on the device.
2022-12-27 14:27:28 <KipIngram   > But a socket module was supposed to handle all devices that fit that socket, so a fair bit of configurability eventually became required.
2022-12-27 14:29:10 <veltas      > Yeah the development of computers was quite rapid and way too much of it was ultimately down to world politics
2022-12-27 14:29:40 <veltas      > Japan and the UK probably would have done much better if not for wider economic issues in 80s/90s
2022-12-27 14:30:12 <KipIngram   > Ah, the 80's.  :-)
2022-12-27 14:30:29 <veltas      > UK prosperred in the 80s but it was finance that was prospering, the high-tech sector went off a cliff while the markets invested abroad
2022-12-27 14:30:56 <veltas      > Japan self-invested but hit a nasty recession in 90's, but they're doing better than the UK
2022-12-27 14:30:57 <thrig       > and Thatcher told coal workers who was who
2022-12-27 14:31:13 <veltas      > Yeah I do blame free marketism
2022-12-27 14:31:31 <veltas      > But really I think this was part of the ideological metagame between east and west
2022-12-27 14:31:41 <veltas      > And centralisation of ideology in the USA doesn't help
2022-12-27 14:31:43 <KipIngram   > I like the idea, but I think it can be taken too far, particular when you're a nation enjoying higher than average lifestyle for your people.
2022-12-27 14:31:54 <veltas      > We made it quite explicit in the UK talking of a 'special relationship', what a joke
2022-12-27 14:32:04 <veltas      > 'special relationship' with USA
2022-12-27 14:32:28 <KipIngram   > Yeah - that's rarely really in the best interests of the smaller nation.
2022-12-27 14:32:53 <KipIngram   > And I think a national government primary purpose should be to promote the well-being of its own citizens.
2022-12-27 14:33:08 <veltas      > The result by my assesment is the West won, but really 'capitalism' won. Neither 'capitalism' nor 'communism' should have won, so we all lose.
2022-12-27 14:33:27 <KipIngram   > I don't disagree with that.  The corporations won.
2022-12-27 14:34:10 <KipIngram   > I get sick and tired of hearing speakers on the right over here trot out the noble words of freedom and capitalism, when what they're really up to is helping the corporations exploit us.
2022-12-27 14:34:35 <veltas      > And after capitalism won I'd say old-school marxism made massive gains because Marx knew full well about abusing a corrupt bureaucratic system anyway
2022-12-27 14:34:43 <veltas      > It's in the DNA of marxism
2022-12-27 14:35:10 <KipIngram   > Yeah - I think Marx had a point.  If you just let capitalism run wild, it is going to create a bad situation for most people.
2022-12-27 14:35:11 <veltas      > It's not even new, all the same stuff worked in the Roman empire and probably before then
2022-12-27 14:35:17 <KipIngram   > While a few folks make out like bandits.
2022-12-27 14:35:51 <KipIngram   > And that was Marx's whole point - that eventually capitalism, unchecked, would lead to a social implosion.
2022-12-27 14:35:57 <KipIngram   > I don't find that hard to believe at all.
2022-12-27 14:36:00 <veltas      > Empire and capitalism both result in massive bloated systems with too much corruption and bureaucracy, which can be readily abused and usurped
2022-12-27 14:36:23 <KipIngram   > So, while I'm all for capitalism as a basic system, I think we should "check it" in appropriate ways.
2022-12-27 14:36:35 <KipIngram   > Which I can't immediately define for you in good detail.
2022-12-27 14:37:07 <veltas      > The only obvious route is to break it up, but then another empire takes over
2022-12-27 14:37:11 <veltas      > Turtles all the way down
2022-12-27 14:37:30 <veltas      > Work with what you have, be the change you want to see, don't worry about it etc
2022-12-27 14:37:31 <KipIngram   > But somehow, one way or another, the benefits of capitalism need to be liberally spread about, benefiting "most" people, instead of a minority.
2022-12-27 14:38:08 <KipIngram   > Ideally without "redistribution" being the backbone of the system, though I do think we need some to cover the "bad outcomes."
2022-12-27 14:38:37 <veltas      > I'm reading City of God by St Augustine at the moment, it was written around the time the western roman empire collapsed. It's really telling
2022-12-27 14:38:53 <KipIngram   > Yes, I agree - it's really been the same story over and over in history, just with slight variations of detail.
2022-12-27 14:38:58 <KipIngram   > This is just the latest round.
2022-12-27 14:39:20 <KipIngram   > We're probably stuck with it, because ultimately people will try to game any system we set up.
2022-12-27 14:39:51 <KipIngram   > Oh, I should read that.
2022-12-27 14:40:32 <veltas      > I found out St Augustine had a porn addiction, that's not a new thing apparently. His mum was a Christian and she made him leave his common law wife to get a 'proper' wife which he never found
2022-12-27 14:40:48 <veltas      > He was a born again christian later in adulthood
2022-12-27 14:41:33 <KipIngram   > That's fascinating.  And ugh.  I just absolutely refuse to muck about in my kid's lives that way.  They can work out their own relationships.
2022-12-27 14:41:51 <veltas      > He was trained in political rhetoric which was the way people got good careers, he actually taught it too
2022-12-27 14:42:06 <veltas      > But he later hated it because he felt it was inherently dishonest and therefore not good
2022-12-27 14:42:15 <veltas      > And part of the corruption and patronage of the empire
2022-12-27 14:42:31 <KipIngram   > Yeah, that's definitely a skill you could apply in good or bad ways.
2022-12-27 14:42:33 <veltas      > He reasoned the empire deserved to fall to war because it was built on war
2022-12-27 14:44:46 <veltas      > He was part of some cult before Christianity, and he essentially left because he met the religious leader hoping for proper explanations and realised he understood it better than he did
2022-12-27 14:45:23 <veltas      > Yeah nothing ever really changes, Augustine seems to be quite a relatable character
2022-12-27 14:47:15 <veltas      > There is some story he has about when he was a child and he stole some pears from a tree even though they weren't ripe enough to eat. Just to be naughty.
2022-12-27 14:57:45 <KipIngram   > Here's an outline of what each Xilinx block ram port looks like:
2022-12-27 14:57:47 <KipIngram   > https://imgur.com/a/1aJuxrm
2022-12-27 14:58:10 <KipIngram   > I still think that dropping "double pop" capability may resolve last night's difficulty.
2022-12-27 14:58:40 <KipIngram   > Without that, the only stack ram item I ever read is 3OS, and I can know that address prior to the end of the previous cycle.
2022-12-27 14:58:57 <KipIngram   > So the cycle leading edge can clock that into the RAM, and the data will show up later on.
2022-12-27 14:59:43 <veltas      > Interesting
2022-12-27 15:01:48 <KipIngram   > ROT and -ROT both require reading and writing 3OS.  But that can work too - the address is known before the cycle, and the leading edge of the clock will clock out the old data and the next rising edge at the end of the cycle can clock in the new data.
2022-12-27 15:02:05 <KipIngram   > It would be a problem if those needed to be different addresses, but they don't - neither of those words change SP.
2022-12-27 15:03:37 <veltas      > Yup
2022-12-27 15:05:14 <KipIngram   > For operations that push to the stack, I'll need to write the new 3OS location (using NOS register for the data).  But that works too, because on the next cycle I want SP pointing at that location anyway, so the end of cycle clock edge can clock the data and the address in.
2022-12-27 15:05:56 <veltas      > Is everything going to be on the stack?
2022-12-27 15:06:23 <KipIngram   > At the moment I have TOS and NOS in registers, with SP normally pointing at 3OS.
2022-12-27 15:07:06 <KipIngram   > Well, "normally" == "always"
2022-12-27 15:08:42 <KipIngram   > that double pop support had added a fair bit of mess; it'll tidy up without that.
2022-12-27 15:09:12 <KipIngram   > So, the traditional ! turns out to be a complicating factor.
2022-12-27 15:11:13 <KipIngram   > It would be neat to see the circuit for that "Control Engine" in that drawing.
2022-12-27 15:11:45 <KipIngram   > Must have some kind of pulse generator stuff in it, since it issues those signals at the right time without a clock to steer it.
2022-12-27 15:11:48 <veltas      > crc: Where does calling the return stack the "address stack" come from, do you know?
2022-12-27 15:11:51 <KipIngram   > I.e., within the clock cycle.
2022-12-27 15:12:25 <KipIngram   > Well, in one chip chuck kept one of the address registers on the return stack.
2022-12-27 15:12:33 <KipIngram   > The one for writing.
2022-12-27 15:25:42 <KipIngram   > Double returns remain a little problematic.  I could solve it esily by using the second RAM port, but I am trying to keep that port available for general address space mapping.
2022-12-27 15:26:50 <KipIngram   > With one cache register for the return stack, it's easy to do a return by TOR -> IP, NOR(ram) -> TOR, RP--
2022-12-27 15:27:16 <KipIngram   > For a double return we can NOR(ram) -> IP and move the pointer no problem.
2022-12-27 15:27:30 <KipIngram   > But we haven't had access to the value we need to move into TOR.
2022-12-27 15:27:51 <KipIngram   > Adding more cache registers doesn't help; it just pushes it all down a level.
2022-12-27 15:29:22 <KipIngram   > That'll have to be done with the other port, so the address registers will have to be able to share it.
2022-12-27 15:30:03 <KipIngram   > That's annoying, because I was already faced with a 2-1 selector to let me pick register A or register B as the active address register.
2022-12-27 15:31:12 <KipIngram   > Oh, wait - never mind.  One layer of selection gets me up to four sources, so this will still fit.
2022-12-27 15:31:57 <KipIngram   > Oh, except that won't be the address that's been clocked into the RAM on that port on the previous cycle.
2022-12-27 15:32:30 <KipIngram   > For that matter, I won't be able to choose address register A or address register B and act on that choice in the same cycle.
2022-12-27 15:32:38 <KipIngram   > That's bad - that's a much broader problem.
2022-12-27 15:33:05 <KipIngram   > It means that general RAM accesses can't happen at all in one cycle.
2022-12-27 15:33:18 <KipIngram   > I may have to go back to the notion of using the falling clock edge.
2022-12-27 15:33:53 <KipIngram   > The problem is the reverse of what I originally thought - it's the stack RAMs that can work smoothly, and the "general" RAMs that face an issue.
2022-12-27 15:35:36 <KipIngram   > Writes are no problem.  I can just clock the address and the data in on the edge at the end of my instruction cycle.
2022-12-27 15:35:49 <KipIngram   > But then that is the address that's in the RAM for the duration of the following cycle.
2022-12-27 15:36:32 <KipIngram   > So I think the only way to make it work will be to have the rising edge move my logic to the next state, and have all that settled by the falling edge, which will act on the RAM.
2022-12-27 15:37:08 <KipIngram   > And then the next rising edge will clock the read data from the ram wherever it needs to go.
2022-12-27 15:38:01 <KipIngram   > Oh oh - wait.  For the bulk of the RAM, which is ONLY general purpose RAM, the A and B regs can each have their own port.
2022-12-27 15:38:32 <KipIngram   > It's only the project of trying to provide general access to the stack RAMs that's an issue.
2022-12-27 15:39:14 <KipIngram   > And if I need to I can use multiple cycles to get at those with the address registers.
2022-12-27 15:39:32 <KipIngram   > Also, I don't need to be able to write to those; that second port can be a "debug read only" port.
2022-12-27 15:39:58 <KipIngram   > So the A reg can be permanently connected to that second address bus.
2022-12-27 15:41:20 <KipIngram   > Return stack only may be a bit tricky, since I need both  ports to do double returns.  There the A reg will have to "share."
2022-12-27 16:27:43 <vms14       > KipIngram: look at my super crud
2022-12-27 16:27:44 <vms14       > https://termbin.com/0qu6s
2022-12-27 16:27:45 <vms14       > xD
2022-12-27 16:28:05 <vms14       > it kind of shows why I like the and and or behavior of lisp
2022-12-27 16:28:08 <vms14       > [ [ 'name param dup? ] [ db swap 1 set.key db magick.flush  db [ drop . cr ] do.hash ] ] and
2022-12-27 16:28:53 <vms14       > instead of checking if the name parameter is provided, I just put the next instructions on the and
2022-12-27 16:29:09 <vms14       > if the name parameter is false those instructions won't execute
2022-12-27 16:29:26 <vms14       > the or serves to default to another value
2022-12-27 16:29:55 <vms14       > sad I can't do port forwarding, so you can't use that shit
2022-12-27 16:32:05 <vms14       > still I think I never made a crud with so little code
2022-12-27 16:32:18 <vms14       > althought there's no sql, it's a hash database
2022-12-27 16:32:31 <veltas      > I like CRUD Forth programs
2022-12-27 16:33:05 <thrig       > CRUD Recursivley Uglifies Depots
2022-12-27 16:34:39 <vms14       > it's using modperl, but it's quite easy to usee
2022-12-27 16:34:45 <vms14       > 'url [ code ] handler
2022-12-27 16:34:50 <vms14       > . prints the document
2022-12-27 16:35:51 <vms14       > 'name param will take the parameter be it from get or post
2022-12-27 16:36:07 <crc         > veltas: I don't remember. I think it wad shortened from "return address stack", which was used in some of the material I studied when learning assembly initially
2022-12-27 16:36:13 <vms14       > or return undef if does not exist
2022-12-27 16:39:05 <veltas      > crc: Interesting
2022-12-27 16:40:33 <veltas      > I prefer to have 00 and FF bytecodes trigger some kind of exception
2022-12-27 16:50:15 <veltas      > crc: How do you do fractional stuff? With fixed point?
2022-12-27 16:54:34 <crc         > I use fixed point under ilo, on the nga system I have floating point
2022-12-27 16:59:27 <crc         > My fixed point precision under retro/ilo is limited; my numbers are only signed 32-bit integers. Retro/nga uses 64-bit by default.
2022-12-27 17:02:50 <veltas      > No dabbling with doubles?
2022-12-27 17:02:57 <veltas      > I mean double integers
2022-12-27 17:05:55 <crc         > Not at this point
2022-12-27 17:07:30 <crc         > I seldom need a larger range than 32-bit signed gives for the things I'm doing. When I do, I just use a system built with 64-bit cells
2022-12-27 17:09:11 <veltas      > Yeah the whole point of doubles was to get 32-bit precision in the first place
2022-12-27 17:09:20 <veltas      > So 32-bit is enough, really, for most things
2022-12-27 17:10:34 <crc         > I'd almost certainly write a double vocabulary if I ever decide to do a  16-bit system
2022-12-27 17:28:03 <KipIngram   > Yeah, me too.
2022-12-27 17:28:12 <KipIngram   > I'll be tempted to do one on a 32-bit system.
2022-12-27 17:54:57 <vms14       > idk if start with your recommendation of providing latex stuff
2022-12-27 17:55:28 <vms14       > I want to make a text editor, but not willing to provide bindings to curses
2022-12-27 17:55:46 <vms14       > also I should try to make some sort of e-commerce
2022-12-27 17:58:14 <thrig       > editor + e-commerce sounds like a bunch of work
2022-12-27 17:58:36 <vms14       > xD
2022-12-27 17:58:49 <vms14       > yeah, I'd choose only one
2022-12-27 17:59:01 <vms14       > but maybe playing with latex is funnier
2022-12-27 18:00:09 <vms14       > still I need to start with the editor soon
2022-12-27 18:01:18 <vms14       > every day I spend with emacs is lost time
2022-12-27 18:16:11 <KipIngram   > Oh, I didn't mean that LaTeX was any sort of "obvious first project."  Or any project for that matter.  I just thought of it when you were taking about the HTML stuff.
2022-12-27 18:19:26 <vms14       > yeah, but I liked the ideaa
2022-12-27 18:19:37 <vms14       > anyways I'm reading a ncurses book
2022-12-27 18:20:07 <vms14       > having the language able to create pdf files is a good feature
2022-12-27 18:20:23 <vms14       > and it's always fun
2022-12-27 18:20:58 <vms14       > also, I could make my CV with my own lang xD
2022-12-27 18:21:07 <vms14       > and put that into the CV
2022-12-27 18:28:35 <veltas      > vms14: curses is pointless, just make it work for modern TERM=xterm terminals
2022-12-27 18:29:04 <veltas      > Also curses is generally pointless for a text editor
2022-12-27 18:29:17 <veltas      > Use the escape sequences for setting margin to define windows yourself
2022-12-27 18:29:27 <veltas      > margin / scroll area
2022-12-27 18:33:03 <vms14       > hmm
2022-12-27 18:33:27 <vms14       > everyone tells me curses sucks
2022-12-27 18:33:52 <KipIngram   > Yeah, I just used ANSI escape sequences for mine and was quite happy with the result.
2022-12-27 18:33:59 <vms14       > but it's not only escape sequences
2022-12-27 18:34:22 <vms14       > stuff like cbreak noecho and so on I guess can't be done with escape sequences
2022-12-27 18:35:00 <vms14       > still seems worth to do my own instead of curses
2022-12-27 18:35:36 <veltas      > It feels like you just want to reimplement stuff in your forth
2022-12-27 18:35:58 <veltas      > If you make an editor, you might consider basing it on starting forth's editor
2022-12-27 18:36:14 <veltas      > Making potentially a visual version of that editor, in the same way vi is a visual version of ed
2022-12-27 18:36:35 <veltas      > With an insert buffer and find buffer
2022-12-27 18:36:47 <vms14       > veltas: I can't dare to say it's a forth, but a concatenative lang. I just want the language be my main programming language so I can use it to program whatever I want
2022-12-27 18:37:07 <veltas      > It's a forth by this channel's standard
2022-12-27 18:37:11 <vms14       > xD
2022-12-27 18:37:32 <veltas      > "If you have two (or more) stacks and speak RPN then you're welcome here!"
2022-12-27 18:37:34 <vms14       > well I don't have two stacks so I'm not even welcomed here :/
2022-12-27 18:37:57 <veltas      > One of your stacks is abstract
2022-12-27 18:38:05 <veltas      > Because there is still a callgraph right?
2022-12-27 18:38:15 <vms14       > well it's the perl call stack
2022-12-27 18:38:26 <veltas      > So there are two stacks then
2022-12-27 18:39:09 <veltas      > I think the point of that message was more that we are inclusive, rather than to prescribe "true blue blooded forths"
2022-12-27 18:39:12 <vms14       > which makes me wonder if I'll end having a return stack
2022-12-27 18:39:32 <vms14       > having a language on top of perl does not make much sense, but for example the debugger could be more useful
2022-12-27 18:39:46 <vms14       > the debugger can't hook inside loops, which makes it quite sad
2022-12-27 18:40:14 <vms14       > well there's a saying like: if you've seen one Forth, you've seen one Forth
2022-12-27 18:40:37 <vms14       > but mine differs too much that it's not a forth, but a concatenative lang
2022-12-27 18:40:48 <vms14       > still crc told me concat langs are welcome there
2022-12-27 18:41:46 <vms14       > but yeah I can mess with cbreack and noecho stuff without having curses
2022-12-27 18:41:52 <vms14       > cbreak*
2022-12-27 18:44:00 <vms14       > it makes sense and also I won't need an external dependency
2022-12-27 18:44:28 <crc         > I have no issues with discussion of concatenative languages here; or other languages tangentially related to forth (e.g., B). I learn a lot by looking into languages other than Forth; discussion of them isn't a bad thing :)
2022-12-27 18:47:37 <crc         > I've done curses; but prefer to just use escape sequences. Less dependencies are better.
2022-12-27 18:48:17 <vms14       > crc do you know about some docs for escape sequences?
2022-12-27 18:48:23 <vms14       > I'm looking anyways
2022-12-27 18:49:00 <thrig       > https://www.invisible-island.net/xterm/ctlseqs/ctlseqs.html
2022-12-27 18:50:13 <vms14       > still the way to go seems to use termcap
2022-12-27 18:50:42 <veltas      > Use the minimum escape sequences you need, look at old ansi specs etc
2022-12-27 18:50:53 <crc         > https://vt100.net/docs/vt100-ug/chapter3.html
2022-12-27 18:51:05 <thrig       > terminfo generally replaced termcap
2022-12-27 18:51:28 <veltas      > termcrap
2022-12-27 18:51:42 <veltas      > is still used on BSD's I think, which is why their terminal experience sucks
2022-12-27 18:52:27 <thrig       > linux fumbling how to handle backspace is a big reason why I'm on OpenBSD
2022-12-27 18:52:57 <vms14       > well most terminal emulators support at least the vt100
2022-12-27 18:52:57 <KipIngram   > Yeah, you have to make iocotl call to change that other stuff.
2022-12-27 18:52:59 <thrig       > and then only on linux I had to put in a cron job to kill off gnome shell that had leaked more than a gig of memory
2022-12-27 18:53:15 <veltas      > vms14: https://ubuntuforums.org/showthread.php?t=225713&page=2&p=1335772#post1335772
2022-12-27 18:53:36 <veltas      > You need to use an ioctl like in shown thread to manipulate echo on Linux terminals
2022-12-27 18:54:00 <veltas      > Or just use stty shell utility
2022-12-27 18:54:56 <veltas      > vms14: "At least the vt100" that contains features that most terminals don't support, like double height characters
2022-12-27 18:55:29 <KipIngram   > At least you can do it with syscalls.
2022-12-27 18:55:32 <veltas      > Seriously, just limit to the bare minimum you need, look at what's supported by who, there's no easy answer
2022-12-27 18:56:10 <veltas      > Literally everything you probably want is achievable by colour/bold control, and setting the scroll area / margins
2022-12-27 18:56:29 <veltas      > And the ioctl is needed to change echo/raw settings etc
2022-12-27 18:56:55 <crc         > I use stty to set the terminal modes (mainly cbreak) that I care about. Other than that I just use escape sequences for cursor positioning, clear screen, and colors.
2022-12-27 18:57:20 <veltas      > Maybe also you want the 'alternate buffer' or whatever it's called (this allows a 'fullscreen' thing like e.g. vim to restore terminal when you're done)
2022-12-27 18:57:21 <vms14       > yeah I just need to know the terminal size in chars and lines, clear the screen and move the cursor. I already can put colors
2022-12-27 18:57:29 <vms14       > well and get ctrl and alike
2022-12-27 18:57:42 <veltas      > Focus on that then
2022-12-27 18:57:48 <KipIngram   > You don't really need anything special to handle ctrl keys.
2022-12-27 18:57:54 <KipIngram   > They just come in as characters.
2022-12-27 18:58:05 <KipIngram   > Cooked mode intercepts some of them, but you can turn all that off if you want to.
2022-12-27 18:58:12 <veltas      > I would prototype with stty to control echo/raw first
2022-12-27 18:58:36 <KipIngram   > Ctrl-c and ctrl-v are the only things I haven't figured out how to get control of.
2022-12-27 18:58:52 <KipIngram   > I still get an ascii 3 when I type ctrl-c, but it "also copies."
2022-12-27 18:59:14 <vms14       > if the wm grabs a keyword you won't get it
2022-12-27 18:59:15 <veltas      > I think there might be extra modes, or just need to intercept the signal they generate
2022-12-27 18:59:18 <KipIngram   > Copy and paste is actually sometimes useful, though.
2022-12-27 18:59:20 <vms14       > key*
2022-12-27 19:00:12 <veltas      > Oh I misunderstood you KipIngram
2022-12-27 19:00:27 <vms14       > and ctrl-c you could get it with signals xD
2022-12-27 19:00:28 <veltas      > You mean how to recognise Ctrl with those keys
2022-12-27 19:00:49 <vms14       > well unless ctrlc is copying
2022-12-27 19:01:05 <veltas      > I've never used a terminal where ctrl+c is copy
2022-12-27 19:01:21 <vms14       > same
2022-12-27 19:03:35 <KipIngram   > I was talking about the ctrl-c = copy, yeah.
2022-12-27 19:03:42 <KipIngram   > Terminator sets up that way.
2022-12-27 19:03:57 <KipIngram   > But I could change it to shift-ctrl-c, which is what I think it is by default in kitty.
2022-12-27 19:04:14 <KipIngram   > Actually I rarely use it because terminator also copies automatically on highlight.
2022-12-27 19:04:25 <KipIngram   > Don't actually have to hit ctrl-c.
2022-12-27 19:04:53 <veltas      > vms14: Make sure you set a 'window' using scroll area / margins, because otherwise you will have terrible performance if you scroll and just rewrite the whole window
2022-12-27 19:04:55 <KipIngram   > Terminator seems to disable the "break" function if there is something highlighted.
2022-12-27 19:05:45 <KipIngram   > veltas: How do I set that scroll area?  I remember that feature from the past, but have never figured out how to activate it in my own software.
2022-12-27 19:06:53 <vms14       > veltas: I was thinking on clearing the screen
2022-12-27 19:07:09 <vms14       > but yeah the good way seems to have a thing that only updates changes
2022-12-27 19:07:43 <vms14       > that's what curses does after all
2022-12-27 19:08:05 <vms14       > it mantains the changes into a virtual screen, when you call refresh it does the update
2022-12-27 19:09:00 <vms14       > KipIngram: it's not terminator who copies on highlight, but the X server
2022-12-27 19:09:08 <vms14       > if you mean selecting text with the mouse
2022-12-27 19:09:15 <vms14       > it's a feature from X
2022-12-27 19:09:40 <thrig       > https://www.jwz.org/doc/x-cut-and-paste.html
2022-12-27 19:09:58 <vms14       > also the signal with ctrl-c seems to only be sent when there's no text in the input
2022-12-27 19:11:05 <vms14       > ah no, it's ctrl-d
2022-12-27 19:11:13 <veltas      > vms14: I don't know what curses does, but vim sets the scroll region to the current window that's changing and no 'diff' is sent at all
2022-12-27 19:11:36 <veltas      > Not sure if vim uses curses
2022-12-27 19:11:54 <KipIngram   > It uses something like the alt screen, though.
2022-12-27 19:11:54 <veltas      > KipIngram: Looking this up, I've found this recently
2022-12-27 19:12:05 <veltas      > Alt screen is unrelated to this feature
2022-12-27 19:12:16 <KipIngram   > Though if you run under screen (and maybe tmux) that can get defaulted off unless you change a setting.
2022-12-27 19:12:20 <thrig       > vim -> 000001ee9fd4f000 000001ee9fdb0000 rlib  0    1   0      /usr/lib/libcurses.so.14.0
2022-12-27 19:12:26 <KipIngram   > I meant vim uses it.
2022-12-27 19:12:42 <KipIngram   > It somehow can restore the bash screen on exit.
2022-12-27 19:13:23 <KipIngram   > I wasn't meaning to tie that to the scroll area thing.
2022-12-27 19:14:46 <crc         > KipIngram: some notes on scroll regions at http://sprunge.us/znlbtg (I've not tested this much, as my visual terminal applications don't make use of scrolling)
2022-12-27 19:15:07 <veltas      > KipIngram: Okay yeah that's the alternate buffer
2022-12-27 19:15:26 <KipIngram   > I see.  So it's a full width slice only.
2022-12-27 19:15:45 <KipIngram   > I feel sure that decades ago I remember being able to set the starting column or something like that.
2022-12-27 19:15:56 <veltas      > Are you talking about scroll regions now?
2022-12-27 19:16:20 <KipIngram   > Seems like what you'd REALLY want would be to be able to designate an arbitrary rectangle.
2022-12-27 19:16:25 <veltas      > https://vt100.net/docs/vt510-rm/DECSTBM.html is what crc has got notes on
2022-12-27 19:16:33 <KipIngram   > Yes - sorry; I'm sort of partaking of both threads.
2022-12-27 19:16:35 <veltas      > There is also an escape for left and right margin settings
2022-12-27 19:16:43 <veltas      > I can't find right now
2022-12-27 19:17:02 <veltas      > Using all of those you can set a 'window' temporarily, that will scroll
2022-12-27 19:17:17 <veltas      > And you can do that each time you need to update a different window
2022-12-27 19:17:28 <veltas      > And rest of buffer remains intact while you do this
2022-12-27 19:17:48 <veltas      > This is how e.g. tmux and vim allow splitting into different little windows that scroll independently without killing performance
2022-12-27 19:18:20 <veltas      > https://vt100.net/docs/vt510-rm/DECSTBM.html allows top and bottom, just can't remember the left and right
2022-12-27 19:18:36 <KipIngram   > That sounds good - sounds like what I'd want for supporting multiple panels.
2022-12-27 19:18:39 <veltas      > https://vt100.net/docs/vt510-rm/DECSLRM.html here it is
2022-12-27 19:18:53 <veltas      > I believe this is how vim/tmux etc work
2022-12-27 19:19:09 <crc         > https://vt100.net/docs/vt510-rm/DECLRMM.html and https://vt100.net/docs/vt510-rm/DECSLRM.html for left/right margins
2022-12-27 19:19:48 <veltas      > Annoyingly the termcap on BSD's I've used doesn't include alternate buffer capability info because the capability description is extremely limited in length
2022-12-27 19:19:59 <veltas      > So vim doesn't restore the terminal
2022-12-27 19:20:28 <veltas      > It's a general weakness of termcap
2022-12-27 19:21:39 <KipIngram   > Bummer.
2022-12-27 19:21:53 <KipIngram   > But thank you guys for those links - I've long wanted to put that to use.
2022-12-27 19:22:13 <veltas      > You can fix this if you speak termcap and add alternate buffer (by removing something else)
2022-12-27 19:22:32 <veltas      > What an awful system though, probably the main reason I don't use BSD because it was otherwise good
2022-12-27 19:25:30 <veltas      > I never use windows on my laptops though, only on reasonably sized desk monitors do I vertically split the screen
2022-12-27 19:25:54 <veltas      > If I am desperate to see two things at once on my laptops I will temporarily do a horizontal split
2022-12-27 19:25:56 <crc         > I think openbsd is using terminfo. At least the manpages for the termcap stuff say the termcap functions are provided for compatibility, and are emulated using terminfo.
2022-12-27 19:26:09 <veltas      > Nice
2022-12-27 19:26:18 <veltas      > Another reason to try out OpenBSD
2022-12-27 19:26:40 <veltas      > I only tried FreeBSD seriously, and briefly NetBSD
2022-12-27 19:28:24 <veltas      > On the actual VT100 I wonder how they entered echo mode etc, I understand it was connected by a normal serial cable?
2022-12-27 19:28:47 <veltas      > Or no-echo mode, rather
2022-12-27 19:29:31 <veltas      > Oh silly me, the echo is generated by the host, so it's in their control
2022-12-27 19:29:57 <veltas      > And that's why it's not done by escape codes, it's just the OS doing it all along
2022-12-27 19:30:37 <veltas      > So if you want the echo to stop, ask the OS to stop doing it
2022-12-27 19:31:12 <veltas      > This was so much simpler in the days of the VT100
2022-12-27 19:31:21 <thrig       > wherein the OS emulates a Teletype Model 33
2022-12-27 19:33:22 <veltas      > I think vt100 had a local echo mode as well, or at least a test mode
2022-12-27 19:33:29 <veltas      > But it wasn't enabled by default
2022-12-27 19:34:53 <veltas      > The Model 33 had a full duplex mode which left echo to the computer, not the default
2022-12-27 19:37:34 <vms14       > I can't generate escape sequences from my lang xD
2022-12-27 19:37:45 <vms14       > but I can set words with them XDDD
2022-12-27 19:37:51 <vms14       > word { print "\033[A" } 'up';  word { print "\033[B" } 'down';
2022-12-27 19:42:44 <veltas      > I don't really understand, how do those *not* generate escape sequences?
2022-12-27 19:43:47 <veltas      > Do you mean there's no way to enter \033?
2022-12-27 19:46:47 <vms14       > I mean " \033" won't get interpreted and I'll get a literal '\033' string
2022-12-27 19:47:52 <vms14       > I can do some stuff with s/ I guess
2022-12-27 19:50:37 <thrig       > : ESCAPE 27 EMIT ;
2022-12-27 19:51:04 <vms14       > lol right, I was trying dumb stuff
2022-12-27 19:52:58 <vms14       > word { my $string = get; put "\033[$string" } 'escape';  with this is just fine
2022-12-27 19:53:07 <vms14       > 'A escape
2022-12-27 19:54:52 <thrig       > \e is less typing than \033
2022-12-27 19:56:21 <vms14       > and than escape
2022-12-27 20:04:21 <vms14       > word { my ($x,$y) = get2; print "\e[${x};${y}" } 'move.cursor';
2022-12-27 20:04:30 <vms14       > lol why I did want curses
2022-12-27 20:05:03 <vms14       > it's missing a H for some reason after {y}
2022-12-27 20:05:40 <vms14       > I just need cbreak and get ctrl and alike and that's almost all I need
2022-12-27 20:06:01 <crc         > I use `vt:csi` for the "ESC[" sequence; not as short as \e, but I do tend towards longer names
2022-12-27 20:06:05 <thrig       > usually the terminal is y,x
2022-12-27 20:06:34 <vms14       > yeah, it's wrong
2022-12-27 20:07:02 <vms14       > 0 10 move.cursor  moves to line 0 character 10
2022-12-27 20:07:35 <vms14       > crc I did not start using prefixes yet
2022-12-27 20:07:49 <vms14       > I got rid of variables and packages, but didn't use any prefix
2022-12-27 20:08:07 <vms14       > I kind of dislike them as I'm lazy
2022-12-27 20:08:24 <vms14       > but that's the only thing I have left now
2022-12-27 20:17:26 <vms14       > I try to use long names btw
2022-12-27 20:17:36 <vms14       > KipIngram: cries when he sees the names of my words
2022-12-27 20:17:37 <vms14       > :D
2022-12-27 20:18:08 <vms14       > he even counts the characters
2022-12-27 20:19:52 <vms14       > for example: word { print "\e[2J" } 'clear.terminal'; word { print "\e[0J" } 'clear.from.cursor'; word { print "\e[1J" } 'clear.to.cursor';
2022-12-27 20:21:07 <KipIngram   > Yah, I've swallowed the "terse" pill rather thoroughly.
2022-12-27 20:22:21 <KipIngram   > So, I only see one way to be able to use the return stack port 2 "routinely" to support double returns (which I use fairly often) while still allowing it to be used to access that RAM from the general address space.
2022-12-27 20:22:46 <KipIngram   > I think I'm going to have to have a configuration bit of some sort that selects one or the other of those pathways.
2022-12-27 20:23:16 <KipIngram   > It'll normally be set to allow double returns, but I'll be able to flip it to allow reading the return stack RAM.
2022-12-27 20:23:38 <KipIngram   > But I'll have to do that carefully - there will be double returns throughout my system code.  So I sure couldn't flip that bit from the interpreter.
2022-12-27 20:24:02 <KipIngram   > I'll have to write specific code to go grab that ram.  Flip the bit, get the ram with code that uses no double returns, and flip it back.
2022-12-27 20:24:15 <KipIngram   > It's ok, since it's really only a debug feature.
2022-12-27 20:25:29 <KipIngram   > I still need to sit down and figure out exactly how to arrange all of the block RAMs into an "address space."
2022-12-27 20:26:42 <KipIngram   > They've got some sort of "cascade support" that I need to investigate.
2022-12-27 20:31:19 <vms14       > br
2022-12-27 20:31:22 <vms14       > brb