02:00 <lispmacs> hi, I was interested in adding persistent storage support to byok, the bare metal forth. I just wanted some kind of simple block-level access to a hard drive or flash storage which I could tie into existing block memory support in byok. I am wondering if any body had any ideas on the simplest approach to this. E.g., should I try to focus on developing a AHCI driver, or an OHCI driver, or something else...?

02:01 <lispmacs> pretty much open-minded, but aiming for the simplest approach

02:02 <lispmacs> it doesn't need to be high-performance persistant storage, though I didn't really want to focus on something like PATA which is already obselete

02:03 <lispmacs> (byok is for x86)

10:00 <proteusguy> lispmacs, haven't done this in a long time. recall something like using INT 14 to access the raw drive commands.

10:00 <proteusguy> sorry int 13

10:01 <proteusguy> have never tried with more modern hard drives. I don't know if int 13 can address something that large or not.

10:02 <proteusguy> I made a tool that was for decommissioning magnetic media so it had to be as low level as possible.

10:08 <proteusguy> Yeah can only address 8.4G http://www.o3one.org/hwdocs/bios_doc/bios_specs_edd30.pdf

10:10 <proteusguy> Oh the extended calls support up to 2^64 sectors so it should be able to address any modern size.

10:16 <proteusguy> Sectors being 512 bytes typically but new drives might be 4096.

11:57 <lispmacs> proteusguy: is extended bios something still current, or replaced now by UEFI?

13:30 <veltas> UEFI has boot services for block access, no runtime services. I would assume the favoured OS approach is now to access via whatever SCSI/SATA interface can be accessed. If you can find firmware support for something similar to the old BIOS method then I would hope it's not going anywhere soon.

13:30 <veltas> Not services I mean protocols

13:31 <veltas> But the point is an OS shouldn't be allowed to use those, unless you're targeting running out of the UEFI shell or something specifically (I assume not from the name)

13:32 <veltas> i.e. if osdev tells you a way of getting basic block access then use it

14:53 <DKordic> lispmacs: I heard NVMe itself is straightforward! Meaning PCIe is not {counted,weighted}. See also ""Open-Channel SSD"", or whatever the BuzzWord might be. I haven't done it yet.

14:53 <DKordic> Forth!

14:53 <DKordic> BIOS is officially obsoleted by UEFI from 2020.

14:56 <DKordic> Every bit of BIOS, and 512 Byte Blocks are so Bugward-Compatible!!

15:42 <veltas> UEFI is not implemented well, right now you might be surprised to learn that often the "legacy" stuff is better implemented than the UEFI interfaces

15:42 <veltas> Opinions on 3drop/3dup etc, if I define those am I going wrong?

15:48 <MrMobius> define everything if you dont care about storage space or lookup time

16:41 <DKordic> veltas: How about a ""Base Pointer""?

16:43 <veltas> Not sure what you mena

16:45 <DKordic> ""swap"", for example, is no less of a variable than it's Parameters. "(swap -)"?!

16:46 <veltas> Can you show me an example of a base pointer?

16:46 <veltas> Or explain more specifically what it is?

16:46 <veltas> I'm afraid I still don't understand

16:53 <DKordic> Sorry, I meant to say ""Frame Pointer"". A Pointer to a Call Stack Frame.

16:54 <veltas> Could you show me an example of this?

16:56 <veltas> Something like this? https://users.ece.cmu.edu/~koopman/forth/rochester_90b.pdf

16:58 <DKordic> ""SP@ to FP FP 2 cells +""?

17:02 <veltas> Your punctuation doesn't make sense to me

17:02 <DKordic> W/De_Bruijn_index . Results in W/Parent_pointer_tree .

17:03 <veltas> I think I understand that though

17:03 <veltas> The code

17:04 <DKordic> ... an /n-Stack Forth/.

17:05 <veltas> If all else fails the code makes sense :P

17:10 <DKordic> Tell me Asclepius, why does the Call Stack ""Grows"" in negative direction? That is, which analogy might be found?

17:11 <veltas> So the things atop the stack can be addressed in increasing address order / increasing indices

17:12 <DKordic> Yes, LIFO.

17:13 <DKordic> At Index 0 is ToS.

17:13 <veltas> Got nothing to do with being a LIFO

17:13 <DKordic> You are right. I stand corrected.

17:13 <veltas> It's also not really a LIFO if you can read the whole thing in any order

17:14 <veltas> It's not really a normal 'stack', it's like how the 'heap' has nothing to do with a 'heap' data structure

17:14 <veltas> Just happens to share the name, similar idea

17:19 <DKordic> IMHO Call Stack is LIFO since it Grows at Index 0. Or is it Index 1?

17:33 <DKordic> If Frame Pointer is Indexed by constants, it can be reduced to 0 Bits at Run-Time.

17:40 <DKordic> By Constant Folding into the Stack Pointer Ossfets.

17:51 <lispmacs[work]> I've been doing coding on AVR with Arduino-FVM. I was wondering though if any of the other (free software) Forths for AVR have a proper XTL system.

17:55 <lispmacs[work]> just read about the XTL idea in FPH and it sounded nice

17:59 <DKordic> What is XTL?

19:09 <Zarutian_HTC> something to do with eXecution Tokens?

19:10 <lispmacs[work]> Cross Target Link

19:11 <lispmacs[work]> sounded like some systems like SwiftForth had a way to do interactive definitions and testing on the target, without having to have any of the compilation words actually loaded on the target

19:11 <Zarutian_HTC> only bit wiser, what are those?

19:11 <Zarutian_HTC> oh, I see

19:12 <lispmacs[work]> for that to work, you just need basic memory editing words on the target, but the host has to be able to correctly manage the defining remotely

19:14 <Zarutian_HTC> the tpeek, tpoke, and texec words basically

19:16 <lispmacs[work]> those words aren't listed in the book I'm reading, but sounds like the same idea

19:16 <Zarutian_HTC> but does that not give arise to the same long term tethering problems that plague compiled languages on avr?

19:17 <Zarutian_HTC> could be t@ and t! for peek and poke respectively

19:17 <lispmacs[work]> I'm not quite sure what you mean about the tethering

19:19 <Zarutian_HTC> a product, often long lived, is made. At later date some addition or change to it is requested. But the designer, her siftware developement environment, or the manifacturer is gone

19:20 <Zarutian_HTC> software*

19:21 <Zarutian_HTC> note this product mighr be expected to last 60 years with mantenance and is not some consumer crap that ends in a landfill in five years time.

19:24 <lispmacs[work]> Zarutian_HTC: well, I think I basically agree with what you are saying, but to have a full self-contained development environment on, say, a 328P, you are going to need the interpreter, the compiler, and the editor on a MC that has 32K of code space and 2K of ram

19:25 <Zarutian_HTC> yeabb, or do what one manifacturer did. Append a project zip file in an spi flash that was needed anyway

19:26 <lispmacs[work]> using Arduino-FVM, I have to have a host environment anyway, because I've got to recompile everything in the end to a firmware image

19:27 <Zarutian_HTC> or another that put an uuid on the board, if you searched the Internet archive for it, you would find the original project files

19:28 <lispmacs[work]> an XLT makes sense to me, though admittedly none of my current projects have closed to used up the full code memory

19:28 <Zarutian_HTC> (same uuid for the model number btw, not per unit made)

19:44 <MrMobius> interesting idea to use the SPI memory

19:44 <MrMobius> I wonder if the avr could use it as a buffer and flash itself

22:46 <veltas> Are pick and roll gauche?