2023-07-29 01:16:44 <xelxebar    > next4th: What's the int13h issue you're seeing? I'm not completely understanding.
2023-07-29 01:30:32 <next4th     > xelxebar: the default pc.img have 63 sectors and 16 heads, I have to change it to 32 sectors and 4 heads for the t5000 to boot.
2023-07-29 01:31:11 <next4th     > i don't know the reason or what that means though...
2023-07-29 01:32:54 <next4th     > xelxebar: have you try the duskos on real hardware? lol
2023-07-29 01:53:09 <veltas      > next4th: Forgive me if I'm off on this, but sectors and heads are used to describe the geometry of a hard disk
2023-07-29 01:53:44 <veltas      > So the hard disk for that machine must be smaller than what pc.img thought was a sensible default
2023-07-29 01:55:03 <veltas      > I believe the size of a disk under that sectors/heads system is 512*sectors*heads, but knowing how many heads and how many sectors per head is useful for software that wants to improve seek performance too
2023-07-29 01:58:14 <veltas      > Also the system I'm used to is cylinder/head/sector, so the actual dimension would be 512*cylinders*sectors*heads
2023-07-29 01:58:28 <next4th     > veltas: the BIOS show C=489 H=4 S=32 for the 32MB disk, there was some code in duskos's bootloader to read drive geometry from FAT BPB (that's what looks like to me) instead of auto-detect driver geometry..
2023-07-29 01:58:58 <veltas      > Interesting, yeah that sounds like a flaw
2023-07-29 01:59:30 <veltas      > Probably because not many people are running on real hardware
2023-07-29 02:01:09 <veltas      > And modern hard disks just report fake CHS and try to be smart with the geometry themselves, because geometry has gotten more complicated since then
2023-07-29 02:02:25 <veltas      > Partly because, and this should be obvious, not all tracks support the same density of bits, but this was never a consideration early on
2023-07-29 02:04:43 <next4th     > okay, seems it read 60 sectors, if read from my disk after 32 sectors return wrong data, that should explain the fails of boot.
2023-07-29 02:05:14 <veltas      > Do you think maybe reading it from the FAT BPB is to allow dual-booting?
2023-07-29 02:05:27 <veltas      > i.e. stick to the partitioned info rather than the whole disk
2023-07-29 02:06:15 <next4th     > no, it has its own mbr too.
2023-07-29 02:07:00 <next4th     > code is: https://git.sr.ht/~vdupras/duskos/tree/master/item/fs/xcomp/i386/pc/mbr.fs#L50
2023-07-29 02:07:08 <veltas      > Doesn't bode well for the apocalypse ;)
2023-07-29 02:07:21 <veltas      > Thanks
2023-07-29 02:08:08 <next4th     > thank you for disscuss, maybe now i understand about it a little more :^)
2023-07-29 02:08:31 <veltas      > You're too graceful
2023-07-29 02:14:29 <veltas      > From reading it, it seems like the system isn't intended to be dynamically portable, and you're meant to change the source to build for a different PC
2023-07-29 02:14:39 <veltas      > But that is a bit shite really :)
2023-07-29 02:14:56 <veltas      > Patch welcome, I suppose
2023-07-29 02:15:49 <next4th     > okay, that's good to know 🥳
2023-07-29 04:15:55 <xelxebar    > next4th: buildpc.fs relevant to your issue?
2023-07-29 04:17:43 <next4th     > xelxebar: yes, that's where i set numheads and secpertrk, it have comments about it for floppies, but seems apply too for my harddisk.
2023-07-29 04:57:07 <xelxebar    > next4th: Cool. So DuskOS is running successfully on your t5000?
2023-07-29 04:57:20 <next4th     > yes, it run fine
2023-07-29 04:58:10 <next4th     > and the said t500 i bought with $7 include shiping lol
2023-07-29 05:02:39 <next4th     > i'm thinking about port Glulx (to play text games like advent, zork) https://www.eblong.com/zarf/glulx/ to DuskOS..
2023-07-29 05:24:59 <xelxebar    > Congrats! Glulx looks fun. The uxn also has lots of games right? Would be fun to take them for a spin on DuskOS.
2023-07-29 05:26:47 <next4th     > yes, uxn now is very slow on DuskOS, i don't know / have the skills to improve that..
2023-07-29 05:30:30 <next4th     > maybe after an ASM port of uxn to kolibrios ^:)
2023-07-29 05:32:23 <next4th     > okay, i should do a understand of SmithForth first...
2023-07-29 05:41:53 <xelxebar    > Hahaha! KolibriOS. I also run that in a VM. Our hobbies overlap way too much :D
2023-07-29 05:42:26 <xelxebar    > I think you've successfully convinced me to get hardware for dusk.
2023-07-29 05:56:18 <next4th     > yeah, old and cheap hardware work better for those things.
2023-07-29 06:10:39 <xelxebar    > next4th: BTW, for x86 opcodes, if you can just remember the order ADD OR ADC SBB AND SUB XOR CMP, it will makes remembering a good portion of the opcodes very easy.
2023-07-29 06:12:27 <xelxebar    > Also, byte-width operands variants in a group always seem to come before the full-width ones.
2023-07-29 06:13:19 <xelxebar    > And then `OP r/m, reg` variant comes before the `OP reg, r/m` one.
2023-07-29 06:15:12 <xelxebar    > With that parameterization, you can immediately read everything from 0x00 to 0x3F. The 0x40~0x4F family is the REX prefix, and 0x50~0x5F is `push reg` and `pop reg` (in that order).
2023-07-29 06:15:41 <xelxebar    > So it's really easy to just *know* opcodes 0x00~0x5F.
2023-07-29 06:19:57 <xelxebar    > Still trying to figure out better mnemonics for later ranges, but B0~B8 are byte-width `mov r/m, imm` and B9~BF are full-width `mov r/m, imm`, which is easy. And then E8~EA cover the `mov r/m, reg` and `mov reg, r/m` variants.
2023-07-29 06:20:49 <xelxebar    > Then 0x70~0x7F are all jumps, which requires memorizing the order of flags that they check.
2023-07-29 06:21:20 <xelxebar    > Well, those are the immediate jumps.
2023-07-29 06:21:36 <next4th     > xelxebar: thanks for the tips, which sounds promsing.  i copy them to a note.txt, have to start it!
2023-07-29 06:22:52 <next4th     > 
ACTION open the scary intel manual...

2023-07-29 06:24:17 <xelxebar    > 
ACTION :D

2023-07-29 06:24:31 <xelxebar    > Also, check out http://ref.x86asm.net/geek64.html.
2023-07-29 06:24:59 <xelxebar    > You're right. It's all pretty intimidating at first, but I'm happy to try helping as much as possible. Still learning myself, though.
2023-07-29 06:25:53 <next4th     > thx, that's very helpful!
2023-07-29 06:30:30 <xelxebar    > BTW, it's most fun to ignore the comments of smithforth, so I ran `xxd -g 1 -p sforth` and am decompiling from that.
2023-07-29 06:30:57 <xelxebar    > Did cheat, however, by looking at the dictionary header and memory layout formats.
2023-07-29 06:32:40 <next4th     > i'm thinking about port it to openbsd, but well i should first figure out how to read the geek64.html lol
2023-07-29 06:35:20 <next4th     > my guix machine is working to death building qtwebengine, so i turn on an openbsd machine for SmithForth
2023-07-29 07:04:26 <xelxebar    > Ouch. You turn off substitutes?
2023-07-29 07:07:16 <xelxebar    > Yeah, geek64 is a bit overwhelming at first. At first, you can just focus on the flds colmn and slowly get familiar with the memory and operand codes.
2023-07-29 07:07:35 <xelxebar    > Most of the codes are rare, so you can just slowly learn them as you go.
2023-07-29 07:40:30 <next4th     > re guix, i'm reviewing/working on z572's kde updates patches, and add my own.
2023-07-29 07:44:19 <next4th     > i think i just start to understand what '0x00c1 -> add cl, al' means.  primary-op: 00, op1(Eb) op2(Gb) both in modr/m, E means in r/m, and G means in reg, b for 8bit..
2023-07-29 07:53:01 <xelxebar    > next4th: Yeah! You're reading geek64 perfectly.
2023-07-29 07:57:04 <xelxebar    > Most opcodes you encounter will have the ModR/M byte after them, so you'll get good at decomposing hex into the mod,reg,r/m fields in your head.
2023-07-29 08:05:50 <next4th     > that means table-2.2: 32-Bit Address forms with the ModR/M byte right?  got it..
2023-07-29 08:45:25 <KipIngram   > I spent a weekend a while back sweating out a code generator for x64; it covers a good bit of territory.  It'll do all the mov and binary operation operations, and supports reg/reg, [reg]/reg, reg,[reg], and also optional offsets on the indirect references.
2023-07-29 08:48:12 <KipIngram   > An example might be rax rcx 8 d[i] .add
2023-07-29 08:48:25 <KipIngram   > That would be "add [rax+8], rcx
2023-07-29 08:49:14 <KipIngram   > My big problem was that I couldn't figure out how to validate it in any exhaustive way.  Everything I checked seemed right, though.
2023-07-29 08:50:08 <KipIngram   > That fit in about 1600 bytes of source code.
2023-07-29 08:53:58 <xelxebar    > next4th: Yup! The REX byte pops up a lot, too, so we need to grok that as well. Byte order is like [REX] [OP] [ModR/M] [Disp].
2023-07-29 08:55:36 <xelxebar    > REX byte takes up the entire range 0x40~0x4F, and the bottom nibble gives extra bits to ModR/M so it can refer to full 64-bit registers and/or the R9~R15 GPRs
2023-07-29 08:57:25 <xelxebar    > The bottom nibble of the byte is 4 bits labeled WRXB, and so REX.W means the W bit is 1, REX.B means the B bit is 1, etc. So that's what those sections of table 2.2 are referring to.
2023-07-29 09:00:47 <next4th     > xelxebar: oh, thanks for pointing out the road, sounds promising!
2023-07-29 09:04:32 <next4th     > KipIngram: sounds great!  which would take me years to learn..   for validate my bruece force idea is to write a disassembler, and disassemble the whole valid insts then assemble again to check..
2023-07-29 09:08:36 <xelxebar    > KipIngram: There's Intel's encoder/decoder library (https://intelxed.github.io/), which makes it feasible to test against a de facto spec.
2023-07-29 09:14:35 <xelxebar    > I actually have a patch in there to make it build reproducibly.
2023-07-29 09:18:42 <xelxebar    > next4th: Actually, it might be useful. Check out the intel-xed guix package. `xed -64 -d 'xx xx xx'` will decode the bytes for you.
2023-07-29 09:21:40 <next4th     > xelxebar: cool, will do (i'm using rz-asm from rizin for that useage now)
2023-07-29 09:22:07 <xelxebar    > Ah, okay. You're already flying fast!
2023-07-29 09:22:45 <next4th     > not fast, just a little start.  taking a break now lol
2023-07-29 09:23:02 <KipIngram   > A nice thing about Forth is that it doesn't really need a "complete" assembler instruction set.  There's a small subset of instructions which will be like 99% of what you need to write your  Forth primitives.
2023-07-29 09:23:32 <KipIngram   > Well, I dropped that elf file onto the little board.  It "did something" but reported a transfer failure, so something's not right yet.
2023-07-29 09:24:03 <KipIngram   > At least I didn't brick it - it still presents the drive when I plug it in.
2023-07-29 09:25:42 <xelxebar    > next4th: BTW, where are you located? It seems like we're in similar timezones.
2023-07-29 09:25:53 <xelxebar    > If you don't mind saying.
2023-07-29 09:27:29 <next4th     > i'm at China
2023-07-29 09:27:42 <next4th     > TZ is UTC+8
2023-07-29 09:29:35 <next4th     > i did brick some boards, and have dozen ones collecting dust 🥲
2023-07-29 09:31:58 <xelxebar    > Ah, okay. I'm UTC+9.
2023-07-29 09:32:47 <next4th     > that's great to hear
2023-07-29 09:32:49 <xelxebar    > Haha. You're a fun person. Do you do hardware work for a living or something?
2023-07-29 09:33:51 <next4th     > no, i'm doing boring devops or automated testing for some years
2023-07-29 09:35:00 <next4th     > having absolute no hardware/lowlevel knowleages 2 years ago..
2023-07-29 09:38:02 <next4th     > work$ had made me stupid and not funny, i think those hardware/forth things could recovery me lol
2023-07-29 09:44:01 <DKordic     > I've been on 4KiB Forth a day for years now... I'm still struggling with absorption.
2023-07-29 09:47:03 <xelxebar    > DKordic: Whoa. You mean Forth is the primary system you're using day to day?
2023-07-29 09:47:48 <next4th     > why not use a larger Forth?  that should have better chance against the absorption (i don't know what this actually means :*)
2023-07-29 09:48:08 <xelxebar    > next4th: Holy crap. We're like the same person. I'm doing infra, devops, sre, etc. but trying to migrate to other interesting things now.
2023-07-29 09:48:35 <next4th     > oh, that's holy cool!
2023-07-29 09:48:54 <DKordic     > No.  Not yet.  Thanks for the DuskOS and intel-xed links.
2023-07-29 09:50:32 <KipIngram   > DKordic: I'm also wondering what you mean by "absorption."
2023-07-29 09:51:56 <DKordic     > I tryed to make a joke by analogy with drugs: KiB for mg and not all of the pill eneters the bloodstream.
2023-07-29 09:51:57 <KipIngram   > next4th: Many years ago I used to do totally stimulating embedded deveopment all day every day.  But things change over the years and I've wound up at IBM where I do performance testing on solid state drives.  It pays the bills but it's not nearly as "invigorating."
2023-07-29 09:52:10 <KipIngram   > Ah, I see.  :-)
2023-07-29 09:53:06 <KipIngram   > For a long time I knew all about implementing Forth but never WROTE much Forth.  I feel like I've rectified that these days, though - I've now got a good bit of code under my belt.
2023-07-29 09:53:32 <KipIngram   > It definitely takes some time to get fluid with it.
2023-07-29 09:57:08 <next4th     > that's great to hear.   honestly i don't work at corp anymore, but well still have to pay for food/rent lol
2023-07-29 09:57:25 <next4th     > i don't want work..
2023-07-29 10:02:17 <next4th     > 
ACTION prepare to sleep now, AFK

2023-07-29 10:02:29 <xelxebar    > 
ACTION waves good night

2023-07-29 10:03:37 <KipIngram   > Yeah, that rent/mortgage has a way of coming back around.  :-)
2023-07-29 10:05:28 <DKordic     > ' [ dfn ( compose M.2 M.1 A )  ( M.2 ( M.1 A ) ) ] call it ""Forth!"" if You like.  I should be able to compose Factors as conveniently as I can mulltiply numbers.  ' ( = nop ( compose dup drop ) ) or with different names ' ( is id ( compose same always ) ) .
2023-07-29 10:05:28 <DKordic     > KipIngram: What do You think about ' ( is ( always True ) ( same is ) ) ?
2023-07-29 10:15:28 <KipIngram   > I don't really follow that at all.
2023-07-29 10:20:31 <DKordic     > [ dfn ( same M A )  ( M A A ) ] [ dfn ( always R A )  R ]
2023-07-29 10:26:01 <DKordic     > : Law-of-Identity  dup = ;
2023-07-29 10:27:24 <joe9        > any notes on Chuck Moore's opinions on dynamic memory allocation in programming?
2023-07-29 10:27:39 <joe9        > A lot of bugs seem to stem from it.
2023-07-29 10:29:32 <KipIngram   > DKordic: That didn't really clarify anything for me.
2023-07-29 10:29:48 <KipIngram   > I don't seem to know what language you're speaking there.
2023-07-29 10:38:02 <xelxebar    > I find it funny that SmithForth words can contain ascii DEL
2023-07-29 10:40:59 <KipIngram   > xelxebar: Yeah - you can do some funny things.  I completely ignore characters below ASCII space in my WORD, except for the enter key.
2023-07-29 10:43:13 <KipIngram   > It also knows how to skip over ANSI escape sequences, so if I have those in my source for color and so forth that works fine.
2023-07-29 10:43:27 <KipIngram   > TYPE sees then - WORD doesn't.
2023-07-29 10:45:45 <xelxebar    > Oh cool. That's what SmithForth seems to be doing so far, AFAICT. It explicitly checks for LF when getting the next line of input, but for word parsing it seems to just treat everything above space as a word char and everything else as "space".
2023-07-29 10:56:36 <KipIngram   > That's slightly different - I IGNORE sub-32 chars; don't treat them as spaces.
2023-07-29 10:57:10 <KipIngram   > My reasoning was that if I can't see it, neither should WORD.
2023-07-29 11:08:50 <xelxebar    > Okay, you're thinking more holistically than I am. I'm just myopically lasering in on some word defs, trying to grok them. So far it looks like "finding the beginning of next word" corresponds to "skipping over every character BL and below".
2023-07-29 11:19:45 <KipIngram   > Yeah, that's certainly a valid way to do it.
2023-07-29 11:22:18 <KipIngram   > I terminate words on space, enter, or null.
2023-07-29 11:22:32 <KipIngram   > Null is special in my system.  WORD will not advance past it.
2023-07-29 11:23:05 <KipIngram   > If it has already accumulated some characters into a word name and it finds null, that terminates the word, and that null is not part of the word.
2023-07-29 11:23:29 <KipIngram   > If it has not found any characters yet, and it sees null, then WORD returns the null string itself as the word.
2023-07-29 11:23:53 <KipIngram   > That word is in my dictionary - it's immediate and it causes INTERPRET to break out of its otherwise infinite loop.
2023-07-29 11:24:46 <KipIngram   > Basicall in my system that's just
2023-07-29 11:25:27 <KipIngram   > : '\0'  ;; ;
2023-07-29 11:25:50 <KipIngram   > Sorry - just
2023-07-29 11:25:55 <KipIngram   > : '\0'  ;;
2023-07-29 11:26:45 <KipIngram   > And I don't actutally have the name written like that; if I typed that the ' chars and the \ would just be part of the name.  That was just to convey the idea.
2023-07-29 11:27:39 <KipIngram   > It doesn't have to be that way, of course - INTERPRET could have had explicit code to check for a null.
2023-07-29 11:32:20 <xelxebar    > Interesting. Can't say I fully grok what you're sharing, but I hope to dive into your codebase some day, when it's all ready and polished :D
2023-07-29 11:36:28 <xelxebar    > Oh!! Finally. So SmithForth has these early-defined words, seek PARSE and pname. Took me forever to figure out what they do.
2023-07-29 11:36:46 <xelxebar    > Are these standard forth words?
2023-07-29 11:38:18 <thrig       > PARSE is defined in ANS, but who knows if it's the same
2023-07-29 11:45:24 <xelxebar    > You give PARSE a range in [cl, dl) and it moves TIB, and >IN to the next character in that range. Then rbp contains the old TIB and rax the length of the "parsed" string.
2023-07-29 11:51:46 <thrig       > https://forth-standard.org/standard/core/PARSE
2023-07-29 12:07:57 <xelxebar    > Close I guess. Still haven't gotten far enough that we have a stack yet. Just futzing with registers right now.
2023-07-29 12:08:22 <xelxebar    > Okay, so [ and ] simply set STATE to interpreting and compiling, respectively.
2023-07-29 12:18:47 <DKordic     > xelxebar: IMHO it is a very crude Array Literal: [ First , ... Last , ] !  Including ""Comma Assembler"": [ args ins, ... ] .
2023-07-29 12:20:03 <DKordic     > Implement nested Arrays.
2023-07-29 12:29:40 <KipIngram   > xelxebar: It's a fairly simple idea.  INTERPRET is the Forth word that interprets a string - looks each word up in the dictionary and executes it.  If you have a null terminated string, then if you wrote that in C you'd probably have your C code watch out for that null at the end and terminate the function when it's seen.
2023-07-29 12:30:12 <KipIngram   > But that's not how my code works.  My code is written as an infinite loop, that just parses words and executes them forever.  It does not look for a terminating null.  It has no stop criterion whatsoever.
2023-07-29 12:30:23 <KipIngram   > but, I am executing words that are specified by the string data itself.
2023-07-29 12:30:47 <KipIngram   > I've just arranged for null to be a word.  It's immediate, so it gets executed when it's parsed out whether we're compiling or interpreting.
2023-07-29 12:31:09 <KipIngram   > And when it executes, it doctors the return stack to force us to return from INTERPRET.
2023-07-29 12:33:11 <KipIngram   > Ok, my little JTAG debugger came.  I installed drivers for it, and downloaded the company's "embedded development studio."
2023-07-29 12:33:33 <KipIngram   > That went RIGHT IN with no muss or fuss, and a sample project in there actually seems to be doing something to the 32655 board.
2023-07-29 12:33:58 <KipIngram   > I got the hello world to run, but the data showed up in the studio window instead of in my screen /dev/ttyACM) 115200 window.
2023-07-29 12:34:07 <thrig       > it's amazing how low one might set standards for software
2023-07-29 12:34:19 <KipIngram   > But it feels like progress.  If I "turn on debugging" I see lights flash on the board and a window with register values pops up.
2023-07-29 12:34:33 <KipIngram   > So - I think I'm on at least some kind of track here.
2023-07-29 12:35:11 <KipIngram   > It reported success flashing the part and showed me a tiny amount of RAM and flash consumed.
2023-07-29 12:35:22 <KipIngram   > No error messages at any point, so the software at least felt happy.
2023-07-29 16:05:03 <KipIngram   > Wow, guys - I highly recommend this Segger Embedded Studio.  It's quite complete.  That and the fact that it just RAN with no muss or fuss kind of "stand it out."
2023-07-29 23:32:44 <KipIngram   > Looks like this software supports just about every micro we've talked about in the past.  At least almost all of them.
2023-07-29 23:32:58 <KipIngram   > I saw the SAMD51 in the list too.
2023-07-29 23:33:43 <KipIngram   > Also saw Nordic mentioned.  I didn't check to see if the specific one we talked about the last few weeks was on the list, but I'd be surprised if it's not.