AlcorBIOS & AlcorPC

[Nikita]

Why not just pop ebx at the start of the function, then push ebx at the end? (Replace ebx by something else not used)

[Fizyk]

You would need to pop 2 registers (DLL functions are called using far calls, so the return address is offset+segment), but yeah, you can do it like that - except you need to document it somewhere, because that makes a different calling convention. With EBP magic, after the function returns, the arguments are still on the stack, so the caller has to increase ESP appropriately. With your system, the arguments are popped off the stack, so if the caller tries to increase ESP, something will go bad.

[Nikita]

So the current calling convention is to keep the arguments in the stack? Wouldn't that cause the stack to be flooded with forgotten arguments after a while?

[Fizyk]

If they are forgotten, yes But that's the point of increasing ESP after each call - to simulate popping the arguments from the stack, except you aren't saving the values from the stack anywhere, because it's unnecessary.

[Nikita]

So, you're using EBP stack-pointing magic to avoid removing the arguments from stack, and then you increase ESP to simulate that? What's really the point?

[Fizyk]

No, the point of EBP magic is to avoid removing the return address from the stack. As it is on top of the stack, you have two options:
1) Pop the address, pop the arguments, push the address back. The caller doesn't have to do anything to the stack, as the arguments are already popped. Disadvantage: you need a place to save the address to.
2) Use EBP magic and stack pointing to avoid popping the address and get to the arguments directly. Because after the function returns, the arguments remain on the stack, the caller has to either pop them, or make CPU think he popped them by increasing ESP. Disadvantage: it's more complicated with this EBP magic.

[Nikita]

Ah I see now. *edits code*

If I didn't forget anything, it should follow your convention now.

Edit: lol, more edits.

[Fizyk]

You forgot to pop ebp in VMselect, and you pop ebx instead in VMdraw

[Nikita]

Forgive me for this monstrocity, Fizyk :P
I know you'd rather not use unofficial elements, but here it goes.



I've attached my combined screen to the alcorPC instead of the usual console screen.

Device:
Combined screen consists of an EGP, a console screen, 4 digital screens and 2 e2s to control them. By default / on reset, the egp simply shows the console screen. It can also show images from up to 4 digital screens, overlapping as instructions go. Maybe draw some shapes like button highlights as well, but I'd rather not count on that, as it has only 40 elements and has to keep an fps of 10.

Connection:
Console screen is wired to the same spot on main address bus as it's predecessor. The rest of screens are wired to about 4 million cells at the very end of address bus network - that is, at the memory4 of device/floppy/hdd bus. Only place it could fit in actually.

Intent:
To make a fine Window system Video Master provides adequate speed for drawing stuff occasionally, but it can't quickly move things around. EGP on other hand, can't draw anything serious but it's good at quickly moving and scaling stuff which is exactly how it's used here - it re-arranges and scales the screens.

Tell me what you think about the idea Fizyk.

[Fizyk]

OMGWTF.

This is a really awesome idea This can really allow me to make a GUI, while not abandoning the console interface completely. When I have time, I'll start developing the BIOS and OS in this direction

Also, it's possible to change the memory layout a bit to give you additional 4 MB where the console screen is currently mapped.

This gave me an idea on how you could make a combined Console Screen/Digital Screen/GPU/maybe-EGP-too screen. You could just stack them on each other and add an E2 that would set alpha of the active screen to 255, and the rest to 0. It would also require some memory remapping, but that's doable too.