Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Topics - Jubatian

Pages: [1] 2 3
1
Announcements / Specification 00.018.000 is up, with binaries
« on: October 01, 2015, 09:53:19 PM »
The 00.018.000 version is basically a milestone within a larger set of changes, so some further work will come.

What makes it noteworthy is that I finally updated the binary downloads on the front page along with it, carrying a proper set of example programs. So the examples are no longer in a state of mess after the jump from 00.009.002 to 00.010.000 a year ago (when the memory paging was gone, breaking several of them).

An important change still on the horizon is revising the application binary format, adapting a blocking concept to make it more robust and easier to handle. It won't have any CRC or hash code with that, in contexts necessary, a separate SHA-256 may easily be provided with an app. file.

Otherwise the user library is mostly in focus, currently to build support functions for the audio subsystem, for mixing.

2
Forum and Web site / Processwiring on the horizon?
« on: March 12, 2015, 10:55:21 PM »
Well, I have to admit, this place is a mess as it stands. Some sloppy front page with a default theme Simple Machines forum, look inviting, eh? Never got the time and guts to start some real design here...

Recently I was researching on what I could do in this term if I wanted a robust, expandable site in the longer run which won't just fall apart. I had experiences with Drupal in the past, and not good ones. I checked Drupal 8, and while it is definitely better, it still smells like I won't want it here. Symphony CMS (the thing powering my personal site, http://jubatian.com), despite that I like it, just won't work out too well: it is quite limited asking for a hell of work for my needs with this place. I also looked at Joomla, and just a glimpse at WordPress, after reading someone coining the term "Drumlapress", which I think somewhat accurately describes how these things are the same bloated mess from the point of someone who would like to fine-tune how his site should behave.

Then came ProcessWire, which pretty much feels like what will be the solution here. I like it's approach, kind of similar to Symphony CMS, just with PHP for building up the look and feel of the site, and seems quite evolved already, such as having a concept of users which I need here. Of course the real decision is farther down on the trail of experimenting, but at least I now have something promising.

Of course then this stuff here will be ditched altogether... So despite I would like to have people here, maybe it's just not a great idea until I put together the core of a new site. This will likely come after the release of 00.017.000, which will likely be the version which would worth more attention.

3
Announcements / Specification 00.016.000 is up with printf
« on: March 12, 2015, 10:39:01 PM »
Finally one big thing accomplished: RRPGE now has text output features!


This version of the specification took quite long time and lots of effort, however incremental effort this time. So many things changed, tuned, by little steps, observing results as they went. The major part behind was the printf implementation, and the related character reader and writer facilities, along with producing basic UTF support. The realized architecture is quite flexible: it allows for inserting user modules at either the source or the target, so for example printf could operate on whatever character writer the user desires (including for example writing text back in the RAM instead of outputting on the screen).

Important changes meanwhile were the fine-tuning of the CPU by the experiences so far, along with some tweaks on the Accelerator and Mixer behaviors so they are more useful.

This version however won't live for too long, I just needed to have a milestone here to polish things together to keep things reasonably tidy. 00.017.000 will likely come next, with even more changes on different fields, such as introducing some audio features and polishing the filesystem concepts including the application binary to serve better the likely needs.

However, with these, the examples might at last catch up, by that I can weed out the remaining stuff from the 00.009.000 specification (memory banking), which will allow for a proper binary release. Likely getting nearer to eventual stability, as well.

4
Current status / User Library plans for 00.016.000
« on: February 01, 2015, 05:44:58 PM »
Well, "large changes" again, this time the User Library is what will undergo some reforming.

From specification 00.013.000 to today (00.015.003) basically the User Library was introduced and incrementally developed along with some very basic testing, and fixing various bugs in the RRPGE emulator code (a lot less than expected). The User Library is basically an API for game & application developers, which is placed on top of the core RRPGE implementation (either emulator or physical hardware) as a binary image in the upper end of the application code space. As of now, it provides basic convenience functions, a sprite system, and support for realizing tile maps.

The most important thing which became apparent that a large part of the User Library is actually object oriented (it was intentional), with some parts introducing a sloppy interface concept (unintentional). The changes will aim to fix this problem by defining a simple interface concept which should provide an adequate general purpose solution. By this, a lot of User Library functions will change more or less.

The User Library will also be extended to 8 KWords (instead of 4 KWords as of now). A fully functional printf with the concepts I want to introduce with it (character readers, writers, UTF support) just doesn't fit already, and there are still a few components which could be useful in this library (like some common uses of the Accelerator and some API for sound and music).

5
Announcements / User Library work in progress, specification stabilizing
« on: November 29, 2014, 07:04:39 PM »
Just some work-in-progress reports.

The RRPGE system's core is stabilizing, changes there are very unlikely. So 13 turned out not to be some unlucky number, actually so far this revision of the specification endured the most torture as I am developing the User Library. However soon an increment will happen as changing the Accelerator's register layout is on my TODO list since a while.

Developing the User Library going well, I have some definite image where it should eventually arrive. To summarize it the shortest possible way: to be able to say something like printf("Hello World!") in a sensible manner. Under the hood this implies developing a properly working tile system (backed by the Accelerator), useful for most old-style games as playfield. Basic text output could then use this tile system like an old character mode display. The "printf" part would be accomplished to be able to target arbitrary buffers (not just a tile map), and would work in a similar manner to the C language's printf function (format strings, variable number of arguments). In this form it can be very useful for any type of text generation.



Recently an interesting pass was developing a 32 bit divider for the User Library. This is not an easy task with a 16 bit processor! I did some research on the matter, going into Newton-Raphson division and likes until building up a very complex, but quite fast (within the constraints of RRPGE) divider. This was also about the first thing which received some systematic in-depth testing, also exercising lots of components in the RRPGE CPU's ALU. No bugs found in there, though!

A screenshot not showing too much is below:


What is going on on that nice green field? It is a test of the 32 bit reciprocal function, it's source can be found within the User Library (GitHub). It simply outputs a green dot for a successful calculation, a red dot for a failed calculation, and a white dot every second. Since obviously there are no errors here (I fixed those before taking shots), let's see the white dots.


This test ran with the source used as-is, so testing the first 256K values for their reciprocals, where the most expensive Newton-Raphson searches occur. The pixel distances between the green dots tell how many calculations could be performed in every second, the image above shows two of these. Since there are about 10M cycles useful for the application (20% is taken by the kernel which the emulator faithfully emulates in randomized batches), this indicates that at about 590 cycles are taken for one calculation. Of course this is not just the reciprocal, but also the check (several multiplies), and the glue logic to run the test. Anyway, in short, this reinforces that neither the cycle budget of the reciprocal search was miscalculated.



But when will I pack new binaries?

On the main RRPGE site still only the old binaries from August may be accessed. Why I apparently don't care is that the example pack is still not complete, and as those are also used for testing, this means that the missing examples also indicate some serious holes in there: particularly too little of the Accelerator, and nothing of the Mixer (or even sound output) was tested this far. Of course even completing those are very far from adequate tests, but if I wrote tests, just nothing would ever be completed... Eh, famous last words: "I will test it when it is complete!". But honestly, my case this approach usually does not end in a disaster! :)

6
Current status / 00.012.000 might be final for binary compatibility
« on: October 28, 2014, 08:10:37 PM »
Specification 00.012.000 for which the toolset currently comes alive might very likely be the final version by binary compatibility.

This does not mean there will be no changes from now, there will, even major ones, as I will explain below, however binary compatibility is very likely to stay from now.

A bit of history first, to summarize the development process:
  • On 1st April, version 00.000.000 was opened. This was functional, but obviously had it's problems. Some application development tests followed, while mostly working on the specification in a binary compatible manner, up until and including specification 00.005.000.
  • Specification 00.006.000 and 00.007.000 focused on redesigning the graphics subsystem, which in this respect broke backwards compatibility, so all graphics related experiments had to be redone. The core system was not touched significantly, carrying over it's inherent problems (paging system).
  • Specification 00.010.000 to 00.012.000 focused on going down to the core, by the previous experiences re-designing it to correct the discovered problems. The most important was the removal of paging, however many minor changes followed all around. While the graphic subsystem didn't change significantly, due to the modified core, everything has to be redone.
The process of evolving the line started with 00.010.000 is mostly complete by now, that is I am now writing applications, testing this system to find remaining bugs in the implementations and whatever minor leftovers which might have stayed in the specification. Like with the previous versions, some iterations mostly concentrating on fixes will likely come.

While I am quite confident in that this system will be OK to last, I also have to admit I simply wouldn't want to redo things again from ground-up. So this will likely stay, that is, applications written to it will likely work further on without too many modifications. Of course, the more distant plan is to have a robust locked system (that's a primary goal of RRPGE, to give a system which would last, so games and stuff never have to be recompiled or otherwise tampered with to keep them functional), however here it is still alpha, the stage where the system should be evolved to live up to the expectations.

And the major change which will likely even enforce this compatibility:

Even with the previous take (the 00.007.000 line) I was starting to develop a generic user library which is meant to complement the currently existing base system. The base system has to be emulated with native code (or realized in hardware once), and, to be honest, the interface it provides is not very friendly. Developers would like to have the capability of doing some common tasks included in the system (such as a tile & sprite system for games, or some text output features, such as even some "printf" equivalent for faster construction, debugging, and tools where aesthetic is not critical). The user library is meant to fulfill this role.

This library will be a part of the final system. It is a nice addition on that term that it does not increase emulator (or hardware) complexity at all, since it is pure software running on RRPGE. The way it will be added to the current system matches the way how some initial data is provided: simply the high end of the code memory will be populated with the user library with a well defined entry point table. If an application does not want to use it, it does not need to, it may even override it (by having larger code than fitting under the user library).

Creating this library simply mandates binary compatibility, since otherwise this task would never be finished. The next versions after some leftover testing and example construction will mostly cover the development of this component.

7
Announcements / Switching to temporary RRPGE License
« on: October 19, 2014, 01:33:45 PM »
With new releases I will switch over to the Temporary RRPGE License.

The reasons behind this may be read in this topic.

This license is basically GPL, with a trademark term and permissions relating to switching to the finalized version of the RRPGE License included. So until the debates about licensing start up and settle, this basically mandates the use of GPL for any release (if you are interested in something else, please read the linked topic, and give some feedback).

The license text is as follows:
Code: [Select]
                               RRPGE LICENSE
                     Temporary version, 19 Oct 2014

Copyright (C) 2014 Sandor Zsuga (Jubatian) <http://jubatian.org/>
Everyone is permitted to copy and distribute verbatim copies of this license
document, but changing it is not allowed.

This license is based on version 3 of the GNU General Public License,
supplemented by the additional terms and permissions listed below.

  0. Additional Definitions.

"This License" refers to the temporary version of the RRPGE License.

"GPL" refers to any version of the GNU General Public License.

"GPLv3" refers to version 3 of the GNU General Public License.

  1. Additional Terms.

All trade names, trademarks and service marks as defined in section 7 of GPLv3
incorporated into The Program belongs to their respective owners, and shall
not be used without their permission.

The trade names, trademarks and service marks incorporated shall be listed
along with their respective owners in a text file referred as "TRADEMRK"
alongside This License in a manner their locations of incorporation is clearly
identifiable in The Program. This file must be present, but may be empty
indicating there are no such entities in The Program.

This term may be removed in accordance with section 7 of GPLv3 provided all
the trade names, trademarks and service marks are removed from The Program as
identified by the TRADEMRK file.

  2. Permission to relicense under other versions of GPL.

You are allowed to relicense The Program under version 2 or any later version
of GPL after complying with the additional terms listed in (1). No additional
permissions of This License shall survive this action. You are allowed to
include a clause allowing further relicensings under later versions of GPL.

  3. Permission to relicense under a later version of the RRPGE License

You are allowed to relicense The Program under Version 3 of the RRPGE License
once it is published by Sandor Zsuga (Jubatian).

8
Licensing model / RRPGE License v3
« on: October 07, 2014, 01:03:24 PM »
I am eliminating the need of an RRPGE Developer Agreement from the licensing model. This would help making the system more "open" in general, that is, only leaving a more clean license to comply with.

I mostly have two paths in my mind, favoring the more freedom-enforcing (that is, less permissive exceptions granted from under GPL) approach which would constrain proprietary uses better. Either approach would only give permissions for RRPGE Applications, leaving the emulator and toolset covered by GPL (version 3).

In short, the two approaches are as follows:
  • "The Free Software approach" would demand anything code (including instructions for an interpreter) released under GPL version 2 or above or the RRPGE License.
  • "The Open approach" would allow any license as long as the interface specifications are released under GPL version 2 or above or the RRPGE License.

I don't particularly like the "Open approach" since it gives too much ground for proprietary uses including patents and problems alike. This is likely the far end in relaxing the enforcement of freedom (strong copyleft) imposed by GPL which I might agree in.

The "Free Software approach" allows for proprietary by that you can use whatever license you want on the story, graphical or audible art components of your release, and in any sane game, these should be mostly what makes it sell (if you want that). Meanwhile it enforces you to contribute by releasing your code under a free license. You still have an important option for the code portion: Releasing under GPL prohibits further proprietary uses, while releasing under RRPGE License allows it.

I tried to initiate some talks with Free Software Foundation members, but by them, even the "Free Software approach" seem to be unacceptably permissive, in a manner they hardly even would give any usable response. I gave up. I don't deny the possibility of a less permissive approach, however without some sane debate, it is not very likely I would go more in this direction.

Until some decision is made, for a safeguard I created a Temporary RRPGE license (see here) which is basically GPL, and use that until this is settled.



The draft license texts are as follows:

The Open approach
Code: [Select]
                               RRPGE LICENSE
                       Version 3 (draft), ?? ??? 201?

                (THIS IS NOT AN OFFICIAL PUBLISHED VERSION)

Copyright (C) 2015 Sandor Zsuga (Jubatian) <http://jubatian.org/>
Everyone is permitted to copy and distribute verbatim copies of this license
document, but changing it is not allowed.

This license is based on version 3 of the GNU General Public License,
supplemented by the additional terms and permissions listed below.

  0. Additional Definitions.

"This License" refers to version 3 of the RRPGE License.

"GPL" refers to any version of the GNU General Public License.

"GPLv3" refers to version 3 of the GNU General Public License.

"Lesser GPLv3" refers to version 3 of the GNU Lesser General Public License.

"RRPGE Application" refers to any software designed to run under RRPGE, which
in binary form is distributable as a single stand-alone RRPGE application
binary file.

  1. Additional Terms.

All trade names, trademarks and service marks as defined in section 7 of GPLv3
incorporated into The Program belongs to their respective owners, and shall
not be used without their permission.

The trade names, trademarks and service marks incorporated shall be listed
along with their respective owners in a text file referred as "TRADEMRK"
alongside This License in a manner their locations of incorporation is clearly
identifiable in The Program. This file must be present, but may be empty
indicating there are no such entities in The Program.

This term may be removed in accordance with section 7 of GPLv3 provided all
the trade names, trademarks and service marks are removed from The Program as
identified by the TRADEMRK file.

  2. Permission to relicense under other versions of GPL.

You are allowed to relicense The Program under version 2 or any later version
of GPL after complying with the additional terms listed in (1). No additional
permissions of This License shall survive this action. You are allowed to
include a clause allowing further relicensings under later versions of GPL.

  3. Permission to relicense under later versions of the RRPGE License

You are allowed to relicense The Program under later versions of the RRPGE
License.

  4. Additional permissions for RRPGE Applications

You are allowed to make RRPGE Applications as Combined Works using The Program
under the terms and conditions of Lesser GPLv3, with the following exceptions:

    a) This permission does not apply to the specification of network
    protocols and file formats used by the Combined Work.

    b) Section 11 of GPLv3 shall remain in effect for Combined Works.

    c) The "this License" definition of the Lesser GPLv3 is to be interpreted
    as the RRPGE License. Where the Lesser GPLv3 requires accompanying the
    work with a copy of "this license document", it means the This License and
    the Lesser GPLv3 documents.

    d) Incorporating the RRPGE Application in binary form as an exact copy or
    through a generic recompiler into an another work whose primary purpose is
    executing the application shall not be considered a modification or a
    derivative work and shall be permitted, however the conveying of such
    works may be regulated by the RRPGE Application's license terms on
    conveying.

The Free Software approach
Code: [Select]
                               RRPGE LICENSE
                       Version 3 (draft), ?? ??? 201?

                (THIS IS NOT AN OFFICIAL PUBLISHED VERSION)

Copyright (C) 2015 Sandor Zsuga (Jubatian) <http://jubatian.org/>
Everyone is permitted to copy and distribute verbatim copies of this license
document, but changing it is not allowed.

This license is based on version 3 of the GNU General Public License,
supplemented by the additional terms and permissions listed below.

  0. Additional Definitions.

"This License" refers to version 3 of the RRPGE License.

"GPL" refers to any version of the GNU General Public License.

"GPLv3" refers to version 3 of the GNU General Public License.

"Lesser GPLv3" refers to version 3 of the GNU Lesser General Public License.

"RRPGE Application" refers to any software designed to run under RRPGE, which
in binary form is distributable as a single stand-alone RRPGE application
binary file.

"Turing complete" refers to the Turing completeness of a system excluding the
requirement of infinite memory.

  1. Additional Terms.

All trade names, trademarks and service marks as defined in section 7 of GPLv3
incorporated into The Program belongs to their respective owners, and shall
not be used without their permission.

The trade names, trademarks and service marks incorporated shall be listed
along with their respective owners in a text file referred as "TRADEMRK"
alongside This License in a manner their locations of incorporation is clearly
identifiable in The Program. This file must be present, but may be empty
indicating there are no such entities in The Program.

This term may be removed in accordance with section 7 of GPLv3 provided all
the trade names, trademarks and service marks are removed from The Program as
identified by the TRADEMRK file.

  2. Permission to relicense under other versions of GPL.

You are allowed to relicense The Program under version 2 or any later version
of GPL after complying with the additional terms listed in (1). No additional
permissions of This License shall survive this action. You are allowed to
include a clause allowing further relicensings under later versions of GPL.

  3. Permission to relicense under later versions of the RRPGE License

You are allowed to relicense The Program under later versions of the RRPGE
License.

  4. Additional permissions for RRPGE Applications

You are allowed to make RRPGE Applications as Combined Works using The Program
under the terms and conditions of Lesser GPLv3, with the following exceptions:

    a) This permission does not apply to the RRPGE Application's code.

    b) This permission does not apply to any component of the RRPGE
    Application which consists instructions processed by a Turing complete
    system at any abstraction level.

    c) The "this License" definition of the Lesser GPLv3 is to be interpreted
    as the RRPGE License. Where the Lesser GPLv3 requires accompanying the
    work with a copy of "this license document", it means the This License and
    the Lesser GPLv3 documents.

    d) Incorporating the RRPGE Application in binary form as an exact copy or
    through a generic recompiler into an another work whose primary purpose is
    executing the application shall not be considered a modification or a
    derivative work and shall be permitted, however the conveying of such
    works may be regulated by the RRPGE Application's license terms on
    conveying.

9
Announcements / Specification version 00.010.000 is up
« on: September 16, 2014, 03:49:52 PM »
The RRPGE Specification was updated today, to alpha version 00.010.000.

Currently there is no assembler, emulator or examples for it, just the specification somewhat finished, as viewable on it's GitHub page: https://github.com/Jubatian/rrpge-spec

It changes things radically to previous versions, so I decided to release it before going through all the extra work with the implementations (which work of course is quite likely to pinpoint problems in the new specs as well, so it is almost certain that patch versions will follow).

The most important change is the removal of paging from the application's point of view. This alone was enough to turn the whole thing upside down, however solving problems many things could be simplified (both from the user's point and the implementation's point).

A change which was "in the air" since months for me which this made mandatory to get through is some redesign on the audio side which eventually grew into a separate Peripheral side combining audio, video, and 4 MBytes of RAM in one unit working independently of the CPU. Compared to the previous concept this adds a good amount of flexibility as now the whole peripheral memory may be used at will for either purpose (audio or video) unlike in the previous concepts having three distinct areas of memory (Video RAM; CPU RAM accessible to Audio; CPU RAM inaccessible to Audio).

In overall new features weren't really introduced (it is not a goal since long), just what was required to solve the problems. The primary goal was simplification, which the new specification for now seems to succeed in.

Well, if there was anyone fiddling with the system already, bad news! Now you can start over (well, not entirely, but almost)! I say your problem since you didn't feed back!

10
Current status / Alpha version 10 will change several things again!
« on: September 05, 2014, 08:09:21 PM »
Well, once again, "Larger changes on the horizon"!

The oncoming changeset will probably not be that radical like those of version 00.006.000 and 00.007.000, but nevertheless will go very deep again in the system's structure. Alongside some simplifications to "give space" for more useful features, the most important changes are to make the system more parallel, and to remove the need for excessive banking on the CPU side. A coarse outline of the plans follows below:

  • - Direct access to the Video RAM will pass away, giving way to a FIFO based filler.
  • - Most DMA memory transfers will pass away to keep the new different architecture simple.
  • - Access to banking features from the user side will pass away, the data address space will have a fixed layout, giving access to 64KWords of memory (minus address space required for memory mapped peripherals).
  • + New parallel operating component: External RAM (2 MWords) & Audio. This replaces the previous banked CPU RAM, providing a streaming interface with 4 pointers, with a capability of sub-word accessing and post-incrementing, covering the full range.
  • + Operating the Mixer DMA does not block the CPU, only the External RAM.
  • + The Mixer DMA might get a simple filter extension (low pass and high pass variants), however along changing the way it handles frequency, the possibility of FM may vanish.
  • + Minor graphics FIFO extensions to handle double buffering automatically.
  • + The CPU will get more useful NEG and NOT instructions in the place of ASL (low bit extending left shift, the would-be complementing instruction of ASR: mostly useless).
  • Some changes in the input system will also creep in, most particularly simplifying the touch device handling, removing touch areas. The capability for using a button set on a multi-touch device will be provided by different interface, in a more flexible and emulator host friendly manner.

The core of the changeset is the removal of banking from the CPU's address space (at the user's point of view; the kernel, to hide itself, and to load and set up the application still would use banking, but this is not even necessarily relevant for emulation). The realization behind is that most memory accesses are streaming, so a large external RAM providing such access capability is sufficient, and a lot simpler to handle than a paging system if handling of large data is required. Alongside this change many simplifications may be performed on the system.

I am still toying with the thought of merging the graphics and the audio systems together over the external RAM (I already considered changing the audio system to operate on 32 bits data for slightly increasing the mixer's performance). This would give a simpler system on the terms of hardware and probably emulation, however it would also be slower (audio and graphics tasks would need to share, the mixer, excluding the boost possible for changing to 32 bits would have to run at half rate than now since half of the accesses are needed by the Graphics Display Generator). There are benefits as well, such as shared hardware, most particularly the RAM itself which this way may be utilized more economically.

So again I will need to rewrite the examples, and of course anyone messing with the system will need to adapt (nobody seems particularly interested, so I take it as nobody does so, and I am free to turn stuff upside down at my will).

11
Experimental / Suggested calling convention
« on: August 03, 2014, 09:43:35 PM »
After quite a while of experimenting with the RRPGE CPU, maybe it is time to determine some useful calling conventions, that is, how function calls should be formatted, and how higher level languages may work with them.

Note that the specification lists instruction timings for the CPU, which will be relied upon here. Although I did not release how I sketched up the internal operation of the processor yet, it exists (defining a weakly pipelined construction), so these timings have some ground.

How functions work on this CPU

The RRPGE CPU defines specific opcodes for function call (JFA, JFR and JSV) which all work by the same base idea. They establish a new stack frame, and may also contain up to 16 function parameters as extension to the opcode. The function entry normally takes 9 cycles, then each parameter fetch another 4 cycles. Since when establishing the new stack frame, also involving pushing the return address, the number of parameters are not known, the return address will point at the first function parameter. No problem since the parameters can be formatted as NOPs, so the CPU simply skims over them again at an 1 cycle / instruction rate. So in total normally 5 cycles are taken for each parameter, which parameters will be accessible on the stack (simply by BP relative addressing) within the function body.

There is no way to manually build up a new stack frame, no push and pop, so this is the only way to do a function call. However it leaves many things not set in stone, which should be carved out to get a functional calling convention.

Components of a calling convention to consider

The way how the function must be called is defined above, however the following further details are left to the user program to work out:

  • How to produce a return value. The RFN (return from function) opcode does not mandate anything for this.
  • Which registers should be preserved, which should be allowed to be clobbered during the execution of the function.
  • The function call opcode gives a possibility for variable number of arguments. How to exploit this in a defined manner.
  • For object-oriented high level languages, a mean for passing a "this" pointer should be defined.

Some more on the stack

After the JFL / JFA opcode, at the start of the function, the stack pointer (SP) is set up to point above the last parameter. This ensures that should anything happen (for example an interrupt using the user mode stack), the function's stack is not clobbered. When working with the stack, the stack pointer, if necessary, needs to be altered to keep this property (that it always points after the last used value).

Note that since the SP points after the last parameter on entry, it's value is the number of parameters passed to the function (SP is always to be interpreted BP relative). To acquire this value, an area is necessary to hold it, however unless clobbering something (such as one of the registers), such an area is not available. This needs to be considered when designing the calling convention. Note however that normally for fixed parameter count functions, reading the SP may not be necessary at all.

What to clobber if anything: some notes on the CPU registers

The RRPGE CPU has 8 general purpose registers, which by use may be divided in 3 groups:

  • Registers A, B and D: These registers can not be used as pointers.
  • Register C: Some operations may use it as carry, or produce a carry in it. Can not be used as pointer.
  • Registers X0, X1, X2 and X3: Only these registers may be pointers.

The role differences end here: apart from these, all 8 registers operate the same way, available in any operation the same way.

Allowing a register to be clobbered takes it away from the caller, while making the life of the function code easier (no need to save / restore it). The return value convention may also be taken in account when deciding what to permit for clobbering: obviously if the return is generated into a register, that register need not be preserved. The supervisor call specification may also be followed here which uses R3 and sometimes C for return.

Allowing clobbering C is a quite natural decision. Due to it's special purpose which only this register can fulfil, it is not very likely that it is viable to use it to hold values in long term, so the caller won't quite miss it if functions would trash it.

The pointer registers (X0 - X3) on the other hand are quite eligible for long-term uses, however their special role may also make it quite likely that they will be necessary in function bodies as well.

Should all parameters be passed in the call parameter list

As described above, a function parameter normally takes 5 cycles (4 cycles when passing, 1 cycle when skimming over after return). If the same parameter was passed in a register, it would take 3 cycles only, assuming the necessity of a simple MOV. Truly this is not a huge gain as an average instruction takes 4 cycles.

An another problem with passing parameters in registers that it potentially takes away registers from the caller, while unless a freely usable (clobber-able) register remains for the function, it would have problems with extracting the value of SP (for dealing with variable number of arguments).

Where to return

Since the management of stack frames is quite rigid by the RRPGE CPU, producing a return value on the stack is not possible. The only reasonable way to return is by using registers.

The supervisor calls are defined to use R3 and sometimes C to return. This might be followed, but may be deviated from as well. Using C for return is a quite natural choice since this register is also the easiest to miss by the caller (see above, at clobbering). However if it would be nice to give a pointer register for the function to work with (which is even necessary for supporting a high-level object-oriented language), using that for return is also something quite natural.

For returning 32 bit values, using C as the high part of the return also would work out well in function bodies if they can generate this part simply by an instruction producing a carry.


The calling convention

On the above bases I would suggest the following calling convention for general use:

  • All parameters are to be passed as part of the function call opcode, in the case of 32 bit parameters, high word first.
  • Registers C, X3 and XH3 may be clobbered by the function.
  • Register XM3 (pointer mode for X3) can be assumed to be set PTR16I (16 bit, post-incrementing) by the function, and it must preserve this (XM must not be clobbered).
  • Return value (if there is any) may be generated in X3 (16 bits), or C:X3 (32 bits, high word in C).
  • For object-oriented use, the "this" pointer is passed in X3 (and may be clobbered).

Variable number of arguments is supported by this convention, since the register C is free in the function body to store the initial value of SP (the parameter count) in it.

The object-oriented convention making the function accept the "this" pointer in X3 is optimal for most uses in that term it is not very likely that the caller would want to repeatedly call methods on the same object (so that X3 may be clobbered, or be part of the return value usually should not be an obstacle for the caller).

The 16 bit post-incrementing mode defined to be excepted by functions for X3 is usually the most useful pointer mode. It allows to walk the data sequentially. Defining it to this fixed value both allows the function to rely on it, and makes it unnecessary to save it even if the function wants to use an other pointer mode (since it can simply restore it to be 16 bit post-incrementing). In 16 bit pointer modes the appropriate XH part is not used, so by giving X3 to the functions, it is not very likely that the caller would need it's high part in XH3. So it is allowed to be used (clobbered) by the functions freely, making it somewhat easier to work with sub-word addressing.

Note: Post edited to reflect current specifications (at the time of edit, 00.015.001), where this calling convention is present

12
Announcements / Version 00.008.000 up: Parallel execution and Sprites
« on: July 04, 2014, 09:36:10 AM »
Finally binaries for the newest version were packaged and posted on the main site.

Compared to the old package these contain quite radical changes, mainly on the ground how the graphics components work. The shortest summary of these would be parallel execution and sprite support.

The parallel execution refers to the Graphics Accelerator. It was there even in the first versions, and operated in parallel with the CPU, however this was quite limited. Now using a new component (Graphics FIFO) it is possible to queue many operations for the Accelerator, so the CPU no longer needs to wait for it while generating graphics. The Accelerator also underwent some changes to be more useful for it's common tasks.

Sprites were introduced as a redesign of the Graphics Display Generator, moving away from the layered concept. There are no true sprite support, however, only a line based command list support, which can combine a line from several sources, arbitrarily positioned on the line. This can be easily used to realize hardware sprites, and also other things.

In overall this part of RRPGE went more complex, but meanwhile the actual code sizes for the emulator decreased, since the overall changes removed some features which were not quite necessary, but were quite complicated.

As of now the provided binaries might be quite unstable, needing more testing, which I will do in the next weeks while designing some generic graphics libraries. There are less working examples since I am obsoleting those which related the old concepts (This is the layerkey example using the layered Display Generator, and the sprite example showing a way to render with the old graphics concepts. Their display could be reproduced, but the intentions underneath are obsolete).

The Block Blitter part of the Graphics Accelerator might still be simplified somewhat: I might remove pixel-precise source definition from it which is quite complex to realize. This was originally introduced to support precise clipping, which became not so critical with the new Graphics Display Generator, by which clipping problems may be covered up using proper display arrangement. In the original layered concept only precise clipping could realize certain types of graphics work flows which were necessary by the original overall concepts.

13
Current status / Larger changes on the horizon
« on: June 18, 2014, 08:50:19 PM »
The next version of the RRPGE specification will introduce some quite radical changes.

I was experimenting for a while with the current system, especially with it's graphics capabilities, but also covering some other aspects. Based on these I got to get some considerably clearer image on what the system is capable to do, what makes it harder doing those, and what features are over-complicated or not quite necessary.

Based on these experiments I decided to radically trade system complexity to gain more useful properties. As of now the followings are visible:

  • - The display generator will only have two layers instead of four. The graphics accelerator if used properly is mostly capable to do what four layers would do, while this cut greatly simplifies the display side in many aspects.
  • - User side interrupt system will be removed. Further changes in the system make this unnecessary for most usual tasks, and it again simplifies the system considerably.
  • + Graphics co-processor based on a FIFO concept. This can most importantly operate the Accelerator, enabling rendering running in parallel with the CPU's other tasks. This greatly increases the performance of both rendering and CPU based tasks, even balancing the execution costs better in emulators.
  • + Line drawing mode for the Accelerator enabling creating various wireframe graphics.
  • + Simple DMA peripherals for various memory copies, both within CPU RAM and across CPU and Video RAM.
  • + Incrementing the CPU memory size from 2Mb to 4Mb. This memory size optionally enables using short (some minutes), low quality sampled audio for cheap music.
  • Smaller changes in the Accelerator for easier use, needing less calculations and register writes to perform usual blits.
  • Smaller changes in the Audio subsystem and the Mixer DMA, following the concepts applied on the graphics accelerator.

Roughly these are on the list currently making it's way into the specification. The CPU does not change, however the handling of peripherals except for the earlier finalized input system change radically, needing to rewrite most of the examples as well.

The normal usage scenarios of the graphics subsystem are getting clearer. The Accelerator is capable to perform quite well, enabling higher level double-buffered rendering contrary to the tile + sprite concepts some systems (game consoles) still used in the early 90's. I would except normally using a double buffered concept on a primary action field on the bottom layer, and using the top layer to produce a relatively static HUD for a game, this way not needing to re-render it in every pass. The Accelerator is also capable to perform well with page copying if needed, which may be useful for rendering on non-double buffered components (such as a mini-map on the HUD).

Other uses are of course also possible, such as a scrolling map with marking changes (soft sprites) for updating, or top layer sprites, but I am excepting the double-buffered concept to become the most used.

The release of this change set is still a bit away since although the specification might get finished very soon, I also need to update the emulator and the example set to go with it before letting it out.

14
Announcements / The implementation finally meets the specification
« on: May 10, 2014, 03:13:08 PM »
After a longer run on the specification and the prototype library, finally the library part of the latter came up to implement everything critical.

With this in the current stage hopefully the fundamentals are set, well established. The host part of the prototype still needs work (to expose some input controllers and a file system abstraction), but at least now it is in reach.

This is a quite important milestone since by completing it, finally it becomes viable to write tools on the RRPGE system itself, which I already planned, but put aside due to this problem. Next milestone is hopefully something what actually shows off stuff, such as some functional game map editor.

Meanwhile I also took some time to explore the state of web technologies, and the situation appears to be rather interesting! Javascript, despite it being a hideous language, seems to take off with JIT compilation, to reach somewhat nearer to native performance. First thoughts was that then, okay, need to plan out the works on bringing RRPGE onto the web itself with a functional JavaScript based emulator. Further research however showed that probably even this is rather unnecessary as even tools to compile C into JavaScript (well, JavaScript-ish) seem to surface, such as Emscripten. Maybe it is not even a far fetched dream at all?

15
Games / The Cheetaan Legacy project
« on: May 04, 2014, 02:05:00 PM »
The Cheetaan, and as game idea the Cheetaan Legacy is what primarily resulted in the birth of RRPGE. This is a rather huge idea which I plan to accomplish, probably with several years of work (I mean the coding and art-crafting, a lot of story and other material born already in the past decade).



You wake up on a wreck of bed thrown on some rusted ship, navigated by a woman in a tattered uniform. The brain is dim, the world is dim, you remember, and not, all like some dream, a not so good dream. How on the Earth you got to get there where some water pump is continuously humming, struggling with the sludge entering everywhere in that jig of hull? And... What? You fall down from the bed, to realize you see fur, and no hands. A feral, a four legged beast, you are. Why? You are sure you were supposed to be... Just what? Definitely not this. The woman. That. A human, not some animal. But how? The body feels like yours, the mind defies it. Visions go and pass, just as the wreck chugs itself nearer and nearer... To some hell of place. Skeletons, steel golems of rusted buildings scrape the skies, skies of smoke and dust of no hopes. Here, the captain yells, on to the boat, and in moments you find yourselves, or at least your supposed nurse rowing towards in the canopy of smog arching between those unwelcoming giants. Minutes later you barely see the old vessel turning to point upwards by the bow, a last reach towards the sky before she goes down to rest for an eternity. There is no turning back wherever you came from. The horizon? People by the shore, sludge and dirt, the vision of a market opens up, the square of trade where poverty exchanges from all the region. Welcome to the world of adventures!


So that's how it may start up: a computer roleplaying game in a strange futuristic world. Of course there is a lot more on it, I even posted it on places around, but the game would be the most interesting if it was truly explored.

(By the way this bright theme sure has to die a horrible death. Even more encouraging me to stand up and get a proper theme done)

Pages: [1] 2 3