01:40 <tabemann> yay - got the disassembly of BL working!

02:20 <tp> tabemann, great news~

03:09 <tabemann> tp: and it's working even better now (but there are still bugs)

04:21 <tabemann> tp: take a look at zeptoforth now!

04:22 <tp> okies ")

04:22 <tabemann> I don't promise that that the disassembler is bug free, as I have not done exhaustive testing of it, but it seems to be working pretty good now

04:23 <tabemann> and btw, reload the binary first, since I made some kernel changes (I found that a 32-bit instruction was being used which I hadn't implemented in the disassembler, so I replaced it with an equivalent (and smaller) 16-bit instruction)

04:23 <tp> excellent, flashing now

04:25 <tabemann> note that you use the disassembler with <start> <end> disassemble

04:25 <tabemann> I haven't implemented a SEE word because there currently is no reliable way to tell the end of a word implemented in the kernel

04:29 <tabemann> it's still surprising seeing just how much the code churns the stack, even though of course I expected this

04:32 <tp> Welcome to zeptoforth ok

04:33 <tp> if the program cant tell the end of a word implemented in the kernel, ho do I ?

04:34 <tabemann> choose a length, and if you haven't seen a bx lr or pop {pc} in the code, you haven't gone far enough - but the problem is some words contain more than one of these

04:36 <tp> lol

04:37 <tp> Mecrisp-Stellaris looks for a bx or lr to determine the end of a word

04:37 <tp> iirc

04:40 <tabemann> in words meant to be inlined I put a special token after the bx lr, movs r7, r7, which I don't put anywhere else, and I put this after Forth words as well

04:54 <tabemann> okay, I've gotta head off to bed

04:55 <tp> cya

23:14 <crest> tp: https://www.ftdichip.com/Support/FAQs.htm#HwGen3 .oO( stupid hardware you had *ONE* job )

23:15 <crest> the hardware flow control takes up to 3 bytes to stop the transmitter on ftdi232 chips