Recent content by kerravon

I have a rough demo available now. https://www.bttr-software.de/forum/board_entry.php?id=22441 Thanks all for your help.

Actually, I should be able to have an assembler routine in my UEFI program to subtract whatever is required from esp to get close to a 64k boundary so that I have a full 64k on all systems. Assuming UEFI guarantees a 128k stack. I have now successfully executed a 16-bit NE executable on an x64...

It will be amusing to see people (read: me) hunting around for the x64 UEFI machine that gives the biggest stack. Sure. I am providing a starter system so that people can then do "the right thing" (according to their definition). I have committed code changes to use the 16-bit stack as above...

Thanks - that's great. And I have thought of a solution that doesn't require me to disable interrupts. Set the 16 bit stack segment to have a base address of esp bitwise and ffff0000 And whatever UEFI gives me for the last 16 bits is my defacto stack size. In fact I could make that the...

Thanks for that info. In the short term I will just disable interrupts then. But I'd like to know something else. Assuming I have a weird 16/32 hybrid, which is currently working, I have a stack that is not 8 byte aligned, nevermind 16 which is what some instructions require, I believe. Can...

Thanks for all that. I will try it all out later. But one more question - when I switch to the 16 bit stack, and it starts having 2 byte alignment, can UEFI cope with an interrupt with this unusual stack? Or do I need to disable interrupts? I think the timer interrupt will be the only thing...

Fortunately programmers speak universal languages, and now I have the actual code: https://sourceforge.net/p/pdos/gitcode/ci/master/tree/generic/shimcm32.asm This is what I was wondering whether would work: .code16 .globl test16 test16: # cli # hlt # adding "-debugcon stdio" to qemu...

Assuming that the D bit is set for a stack segment (I assume UEFI has that already), does this mean that in my 16-bit code, I can do the normal: mov bp, sp mov ax, [bp + 6] And bp is actually ebp so I don't need to change the UEFI-provided stack, so long as I am lucky enough to get a high...

I made a mistake here. It's not a pseudobios-provided int86 function. It's an OS-provided function. With the OS being PDOS/86. I believe the OS should have the right to tell the app to not insist on doing a real interrupt. Similar to how calling doscalls.dll in OS/2 1.0 gives the OS the...

Thanks for the correction. I traced the source of my misunderstanding of PM16 and have posted this to alt.os.development: On 2021-07-14 wolfgang kern wrote: https://groups.google.com/g/alt.os.development/c/0f3Ns-Q_R4M/m/9T-OwY4KBAAJ >> I assume I still have 16384 selectors, so I will...

Is that a combined GDT+LDT?

Thanks for all that info. I believe PM16 on the 80386 at least has half as many selectors available. So 4096 per table I assume. I think I have enough info to begin now.

Perhaps there is no such thing as CM16?

Thanks. Sounds like it will work. Note: My programs can run under MSDOS without implementing int 21h in CM16 so long as the app detects its environment and chooses whether to do an actual interrupt or do a callback to a pseudobios-provided int86 function. And the other point. How many...

BTW, that "mechanism" I spoke of was invented while attempting to port PDOS to the Atari and demonstrated on MVS, with this code: https://sourceforge.net/p/pdos/gitcode/ci/master/tree/generic/pdos.c #if defined(NEED_VSE) || defined(NEED_MVS) || defined(NEED_BIGFOOT) os.Xservice =...