Device IO

March 29th, 2010 by Moggen

I have implemented exec SendIO() and Clock now successfully sends a timerequest to timer.device. But I have not come to the point that Clock waits for and gets a reply. It sends the request and continue with other stuff.

The new thing for the week is that Clock seems to copy the entire RastPort structure from the window into its own data area. That seems a little strange to me at this point, but I guess it has its reasons for doing this. I hope it’ll get clearer later on.

This copy procedure meant that all attributes in the RastPort structure had to be handled so it took some time to implement this. I realize that it will be a lots of work to implement all attributes in all kinds of structures, so it will probably be worth to automate this. Building a program that parses the header files from the NDK and create mapping skeletons for all structs setting up code for endian conversion as default for all attributes. This will save lots of manual work. I will consider this more when Clock is running. I hope there will not be many more copyings like this in the rest of Clock.

Menus

March 24th, 2010 by Moggen

I have not done much coding the last week, but menus can at least be seen now!.

I’m working on some graphics showing how emumiga works internally. I’m learning how to use InkScape. Here is an example made in InkScape showing how memory mappings can be stacked in Emumiga. There will of course be some text accompanying the graphics later.

Visible results

March 15th, 2010 by Moggen

This has been a productive week, and I just got something visible!
A plain boring empty window, but to me it is a beautiful one. :-)

I have implemented tracking of the ViewPort and RastPort structures. These structures are included inside the Screen structure. This was a new thing as structures up to now have always been used and created through pointers. Either returned from a syscall, provided to a syscall or referenced via pointers in other structures.

Pointers to these new included structures are calculated by the user program from the pointer to the Screen structure. If such a pointer is provided to a syscall there will at first not exist a mapping of the specific type at that address. The standard way in this case is to create a mapping from the pointer provided.

Creating a mapping from a user virtual address will allocate memory for an underlying real object, convert the data from the virtual memory to native format and set up the mapping. But the real memory object already exists as a part of the outer structure. Detecting this problem and making it right will be messy. The easy solution is to set up the mappings for the substructures directly when the outer structure mapping is created and thus avoiding any trouble later. This needed some new constructs in the mapping system.

I also had to look over the priorities of the mappings. As substructures overlap the outer object it is important that the correct mapping functions are used for memory accesses within the substructure address range. I want the outer object to handle the access. I believe it will probably in many cases just delegate the access to the substructure standard mapping function, but it has the posibility to do something else if needed.

IORequest and polymorphism

March 7th, 2010 by Moggen

Time for a new update of what’s going on.
I have been working on my first device: timer.device. Devices are quite similar to libraries regarding to implementation. Devices use the same base structure as libraries and have system call LVOs in the same manner. The main difference is that devices are opened via an IORequest. OpenDevice() fills out this structure with the device base pointer (and some more stuff) instead of returning the pointer like OpenLibrary().
This is quite straight forward except for the IORequest object.
I recently implemented CreateIORequest() and that call takes the size of the structure as a parameter. The tricky part is that this memory area/object will be used for something that is an IORequest OR an object that is an extension to an IORequest. Many devices have their own extended version of IORequest, like polymorphism in OOP.
The problem is that the exact type of this object is unknown when CreateIORequest() is called. Some conclusions may be done based on the provided size, but I bet there is two extensions with the same structure size so I won’t use this.
The type is not completely known until this structure is passed to OpenDevice().
This means that the type/mapping will be set preliminary to a simple IORequest and will be updated later with the correct mapping.
I had not made the mapping mechanism to allow updates so I had to do some work there.
Other than this I have implemented some mappings in struct Locale for date formats, and right now I’m working on the Font property in struct Screen. It points out a struct TextAttr that needs a proper mapping. I kind of cheated in OpenFont() by not making a real mapping. Now it bites back.