its the Asylum ROM for running with WabbitEmu, not the TIOS rom.

If you want, you can toy with it and make your own OS, I done care. I referenced some but not all of the routines in the source if you look at them.

What hex2rom tool did you use?
More generally, perhaps you could reference where you got all the programs you used? (For attribution purposes, and so I can stare at the official readme)

I thought you had made this OS long ago; you mentioned all the GUI routines you had made back then.



And credit all the routines you took from elsewhere.

Well it seems all I can get it to do is to turn on and off, nothing more.
In fact, when you turn it off the first time, trying to turn it on just flashes the screen and goes right back off in the copy of WabbitEmu he provided.
But tbh, I think that is all that he has done in it at this point according to the readme, unless I read wrong.

I used Brass (cant remember where I got it), BintoIntelHex (googled bintointelhex), and OS2Tools (ticalc.org).



That was for EchoOS and used alot of the TIOS routines, so I had to rewrite them all.

Sonlen, recreating the GUI stack is a leap forward theres plenty of more routines in it if you look at the source.

*facepalm* What did I tell you about redistributing WabbitEmu without permission? And Brass, and all those other tools.

I am positive he wanted to see that a page ago, I even reminded with a quote that was apparently ignored. :/ I personally would like to see it to see how the OS itself looks.

I didnt feel like pulling everything apart

I just send the Asylum folder to a compressed folder.

For me it just displays two images, then turns off permanently.



...

it should show a splash screen for about 3sec, render a main gui, and turn off and on if you press the on key.Look into the source, its a stack, not a picture.

Looking at the source, I see that it is indeed doing something programmatic rather than simply copying an image to the gbuf. You seem to have punted on the memory issue entirely though; how does that work?

I will admit that is interesting, and in fact, from what I could tell, uses something different then the DCS GUI programming, then again, I don't really know ASM and can't really understand what it is trying to do, but I do say good luck with this project.

No, it uses almost precisely the same concepts, except he made it easier for himself by not bothering with any memory management. I'm not sure how that's going to work out.

Ahh, but here is the thing, how many ways are there that could do the same thing without the same concept though?
I know something are do-able by changing the routine (in a rough example making maps in BASIC) but still accomplish the same results in ASM?

In almost any language, there are countless different ways to do the same thing, and ASM is no exception. The fact that I decided to make my GUI stack-based is a mere convention for convenience; a different arrangement might be equally good or even better, depending on what kinds of features the coder is looking to add. It's not just changing the routines or a few commands around; most things can be achieved tons of different ways. For example, for your maps, you could be storing them in matrices, in lists, or even in strings. Strings, for example, would reduce the size of your maps by a factor of 9 in terms of bytes taken, but would make collision detection and event triggering slightly slower, and would make coordinate calculations more complex. In that case, the tradeoff is data size vs. simplicity vs. speed, with some leeway available to fudge in one of those three directions depending on the coder's skill and experience. It's a similar situation for a complex feature like a GUI system.

There was no memory management because there is no filesystem. The gui routines are basically the same as EchoOS's and DCS's except they don't use an appvar. Use an appvar, insmem for pushing stacks, and delmem for popping them and they'd work on the TIOS. The mouse shouldnt be to hard either, just start at the bottom of the stack and work your way backwards comparing the mouse coordinates with each of the objects and running a routine depending on the item type. If you come across a window type object, then you've checked all the objects in the active window and the routine has ended.

There will be 2 ways to init the stack in Asylum. First, you can call CreateGUIStack to create an external stack just like DCS does. Second, you can call OpenGUIStack and point to a structure identical the PushGUIStacks input, which will become, not copied to, to guistack. The object type $FF signifies the end of the stack, and rather than delmemming, when you use OpenGUIStack to create the stack and call PopGUIStack(s) it just changes the object type of the Last object in the stack to $FF. Ups and down? Creating the stack with Create is slower but easier because it expands and collapses upon changing the stack, creating with Open is A LOT faster, but you can't add more items to the stack (unless you appended extra unused memory to the end of you stack)

Not to be negative, but that's not how Doors CS does it at all. That would be much, much slower than what DCS does.

It looked like in your code the GUI stack had to start at a specific location in RAM, period. Was that just temporary, then?

I could also store or lookup the location of the last window object created and search forward, that'd be a bit faster. Maybe not as good as DCS, but its a working method.


No, if you take another look you'll see that that its stored at (GUIStack). When the main stack was rendered, it changed the location of the gui stack to Mainstack. hence the...

Code:

Yeah, but for example:
Code:
You're leaving the memory management to the program itself, which I generally think is a very bad idea.

That was just to get started and make sure everything is working. It'll be optimised later.