Recent Posts

  • Top11 Generator comes back online

      Loads of you have discovered that among the most frequently brought-up questions about the forum is all about the loss of a single star once we get encouraged (Level upward). So, today we'll have a peek at what's really happening.   First off of, let us discuss "Promotion" (Gaining a degree) and what happens as soon as the new season starts. If at the conclusion of the prior season your club managed to set at the top 8 of this League contest, you may get a degree and your team will be encouraged to play at a greater degree League when another season strikes. II. Understanding player quality There are 3 components of this Player Quality statistic that you'll need to bear in mind along with ??? Quality pub - Full.JPG   The celebrities are only a visual representation concerning how good the player is to get the degree of the League where his Club competes.   Quality pub- Percents.JPG Twist That can be another way to judge how competent a participant is to get the present degree of this League. Additional approach to judge how competent the participant is for the present League contest.   This is the true number of this participant's Quality. This amount doesn't reduction, it may just get higher and higher.   NOTE: After you tap on the Info button a brief info-bubble will popup. Player profile card.JPG   III. The new season So what is the situation? I.e. "However, Jeeves, my heart is unworthy now!" Nope, your team is exactly the same as it had been three days past (Past season) - The illusion that your Club is unworthy now comes in the fact that because there's a fresh excellent ceiling to the League, the Star and Percentage signs have readjusted to update you about how competent your gamers are to get the new League. In actual soccer, an excellent player from the next league might just be an ordinary player in the top league in the start. The quality required for every single star is obviously greater. Case in point: If you will need a caliber of 30 on a lower level so as to acquire a third star for some player, you'll require a skill of 35 if you progress to another level. This usually means that there's room for advancement, many if not all of your fellow supervisors will continue to better their players, even some slowly and slowly, others more vigorously. This makes supervisors feel reluctant to continue to spend the effort to be able to remain aggressive, and not everybody likes this. Yet that IS exactly what it means to compete, that's the nature of what a contest is. It's a nonstop arms-race involving peers. You can not always be on peak of the foodchain if you don't set in the job. And if you do, your team will be powerful enough to conquer the resistance and you'll increase throughout the League rankings and will be encouraged. The game will not allow you to keep in exactly the exact same level simply to conquer the beginners. You are placed wherever your rightful place is. It is my hope that this explanation will be beneficial for our newer supervisors and they will not get rid of heart when they have promoted due to how well their nightclubs performed before. Anyway, if you get to the place where we found this info,  you'll get all the stuff described here. Please feel more than welcome to talk about this subject under and do discuss any hints you may have for the development of additional such official posts.   Fantastic luck in the contests guys and gals!

  • IoL4 Overview

    by Austin K. Kurahone The goals of the IoL4 project is to port the Io programing language interpreter to the L4 experimental kernel. It will run the IoVM as a single server in kernel level, allowing direct hardware access and independence from having a full blown operating system and userland. Additionally minimal to no changes should be made to the base IoVM code, to facillitate maintainability of the project. Architecture Implementation Notes Open Tasks  

  • Open Tasks

      Open Tasks IoVM

        • latest IoVM Pull in latest IoVM, clean up build process and get the changes integrated into mainline. The changes are 2 new makefiles and a bunch of ifndefs, so it should be low impact.
        • no ifndefs Work on getting rid of all the ifndefs. It's just turning off IoFile, IoDate, and parts of IoNumber because corrsponding libCLight functions aren't there.
        • L4 system call bindings This would be a good task to get familiar with the L4 architecture. All the system calls are exported as C/C++ libraries.
        • PPC port should be booted/tested. I can write the setjmp.S and crt0.S The L4 kernel requires a slightly different gcc setup (generic elf binary instead of macho). Build process is documented in the pistachio sourcetree.
        • Put in a real pager/VM subsystem. Current static allocation is stupid.
        • Get started on the HAL.
        • VGA console driver since (as the demo shows) current console support is buggy.
        • Open Firmware equivalent.
    For now I'm probably going to take pulling in the latest IoVM, the pager code, and also focus on figuring out arch and getting version control setup. Most of the tasks can be done in parallel, and my copy of the tree hasn't divereged too far so the snap I put on the web is good to work off. Things different in my tree:
      • Coroutine related fix to setjmp.h
      • sscanf in libCLight.

  • Implementation notes

    Implementation Notes

    Current development platform
        • x86 FreeBSD 4.8 under VMware.
        • L4ka::Pistachio 0.2
    Current restrictions/known issues
      • File access calls in libCLight have been stubbed out till a filesystem is implemented.
      • The rand() call will always return "23".
      • Maximum usable amount of memory is determined at compile time, must be a power of 2 due to quirks with the Sigma0 interface.
      • Assumption is made that sizeof(unsigned long) is equal to sizeof(void *). This is true on most systems. (As a side note, Linux current makes the same assumption).

  • Architecture

    IoL4 Architecture

    Components Currently IoOS/L4 is divided up into several components.
        • IoVM - Currently a stock unmodified IoVM taken from the Io programing language page.
        • libCLight - A minimalistic libc implementation. IoVM is linked against this.
        • Sigma0 - This is task that L4 spawns to handle initial memory allocation.
        • L4 - The L4 microkernel itself. In theory any L4 implementation will suffice, as long as it implements the X.2 version of the spec or later. The reference implementation, L4ka::Pistachio is being used for development.
    Memory allocation libCLight contains a copy of Dough Lea's malloc implementation, and a very simplistic implementation of sbrk and brk. As part of the initialisation process, it will request a static page contigious memory region (~16MBs) from Sigma0 for the heap backing store. This will change and will be modified to be more dynamic, and possibly support for paging will be added. Input/Output Currently the input and output routines will use services provided by the L4 kernel debugger in liew of a real console. While this will suffice in early stages of development it will be neccecary to add a real console/frame buffer interface later on. System call interface Once the IoVM port is up and running (boots and passes regression testing), a system call interface will be written to allow Io programs to make L4 system calls. As there are only 12 system calls provided by L4, and the availability of a C library "Convinence programing interface", it should be possible to implement this as a normal Io object. Hardware access It is tenatively planed that some sort of hardware abstraction layer be implemented so that it is possible to write device drivers in Io. More needs to be discussed and planned on this once the target platform(s) become more apparent. The one possible issue is that the top half interupt handlers should and most likely will be writen in C due to restrictions on what is possible at various IRQ levels, and the fact that the code is extremely speed sensitive. It might be advantageous to use TU-Dresden's Omega0 for interupt handling as it should significantly ease portability. Scheduling/Processes/Userland Extensions to the Io coroutine interface will be made to provide the ability to spawn off a new separate IoVM instance, optionally at a lower priviledge level. Current plan is to use the L4 scheduler to implement premtive multitasking between the "kernel" and "user" VMs. It is also currently under consideration if it would be worth implementing Io coroutine support as actual L4 threads, and have them also preemtivelys scheduled. (Limbo from Bell Labs uses a similar mechanism). Filesystem It is open to debate if a "real" traditional filesystem should be implmented or if it is sufficient to provide a mechanism for checkpointing IoVM state/objects. Further investigation is needed.