Recent Posts

Pages: [1] 2 3 4
1
Announcements / Specification 00.018.000 is up, with binaries
« Last post by Jubatian 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?
« Last post by Jubatian 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
« Last post by Jubatian 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
« Last post by Jubatian 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
« Last post by Jubatian 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
« Last post by Jubatian 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
« Last post by Jubatian 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
« Last post by Jubatian 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
« Last post by Jubatian 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!
« Last post by Jubatian 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).
Pages: [1] 2 3 4