Recent Posts

Pages: 1 [2] 3 4
Experimental / Suggested calling convention
« Last post by Jubatian 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
Announcements / Version 00.008.000 up: Parallel execution and Sprites
« Last post by Jubatian 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.
Current status / Re: Larger changes on the horizon
« Last post by Jubatian on June 29, 2014, 07:18:46 PM »
A fresh implementation went up right a few minutes ago, of course alongside the appropriate specification. No examples yet, probably many bugs, but basic tests show it is functional.

An even further step was accomplished. The original post referred to the specification 00.006.000, which never got fully implemented to the end. I changed the Graphics Display Generator, advancing to 00.007.000, and the current implementation reflects this.

What's new with this Graphics Display Generator?

Well, most importantly, a kind of sprite support actually made it's way in RRPGE. Truly the rigid layered construct was changed to something more flexible, a line by line real time renderer, which can collect it's sources from line oriented command lists (still referred to as display lists). It can use up all the cycles on the bus previously available for the layered concept to fetch sources for the line and combine them onto an internal line buffer.

It is still not a sprite system, however, since it is line based, that is every display line has it's own configuration. It is however a lot faster to fill in these line configurations than working on display data, so it may well provide for a sprite system for who needs this, and many other things for other types of graphics generation.

I guess the graphics components are mostly complete with these, but further testing will of course show how it fares.
Current status / Larger changes on the horizon
« Last post by Jubatian 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.
Announcements / The implementation finally meets the specification
« Last post by Jubatian 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?
Games / The Cheetaan Legacy project
« Last post by Jubatian 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)
Announcements / Going more generic, and a revised license
« Last post by Jubatian on May 04, 2014, 01:36:39 PM »
In the past month I was exploring mostly the graphics features of the system, designing engines, game ideas, and by this certain things occurred to me, which direction is getting realized with the current updates.
  • First the most important is that not only games, tools also could suffer from bit-rot, and may be desirable to be built on RRPGE (and not with some host-specific messing, especially if that messing would require reproducing features of RRPGE). So to get these possible, the system undergone changes to become more computer-like than console.
  • Currently the changes covered parts which were not implemented yet anyway (the input and the file system interface). These were the major problems, but meanwhile smaller things (like supporting changes between 4 bit and 8 bit modes) also occurred on my TODO list. Next updates will cover these alongside fixing up the current prototype emulator.
  • The audio system will encounter some changes: the Mixer will stay as-is, but an interface providing more freedom will be realized (the hows are already settled, implementing this into the specification and the emulator needs work), which will also narrow the host interface slightly (which is good). The changes will give more freedom to designing timing sensitive graphics engines.
  • I am also thinking about giving the system a console or logging support. Maybe I will rather discard this at the end as non-critical.
The RRPGE License also undergone some changes. These are rather only clarifications, to give a more definitive meaning to certain cases (primarily about Creative Commons licenses), but as an other goal I also restricted the rights gained with the RRPGE Developer Agreement. It is just not right to let that offer a huge gaping hole in the thing, no matter whether the Agreement is under my control or not.

With the changes a larger plan also starts to form: It is a necessity to build an user-friendly maker for the system to make it useful to the general public. This maker will be done within RRPGE. I would attempt to make it in a generic way in that respect that it should support outputting intermediate results (such as sprite sheets, mapping and such) so it stays useful for assembly programming as well. It is also easier and more motivating to work on it this way (that I can also use it in my projects such as Cheetaan Legacy as well).
Specification / Additional hardware details
« Last post by Jubatian on April 23, 2014, 03:34:18 PM »
The specification only defines the upper layers of the RRPGE system, the parts necessary to make it appearing consistent for the user (the application developer).

Although I am not a hardware engineer, I do have some insight to these matters. The specifications did not came from thin-air, I actually sketched up some internal concepts of the system, such as how the CPU's pipeline may be composed. To put it short, these exist, I just had no time yet to add them to the appropriate supplementary section of the RRPGE specification.

Of course later I will do. It would be interesting how the system actually fared in hardware, which probably may be explored later with the help of VHDL and an FPGA. Of course it is a quite large job to get there, something which certainly won't be done by me.
Current status / System status, 2014.04.23
« Last post by Jubatian on April 23, 2014, 03:17:31 PM »
So what got locked, what may still change?

  • The RRPGE CPU is likely settled. It was completed long before the public alpha opening, and no changes were necessary ever since.
  • The Graphics Accelerator's functionalities are likely mostly complete, however while designing some experimental graphics engines, I am still applying minor tweaks on it, changing the interface from times to times. Major changes are very unlikely.
  • The Mixer is something I think complete, it is rather simple and functional. However I have no proficiency in music, so I can't know for sure. If you are interested, experiment and feed back.
  • The constant and initialization data is likely complete, but minor tweaks in the RRPGE Incremental palette's first 32 colours may happen, and the colours including and above index 64 might be drastically shuffled around.
  • Parts which currently have no completed implementation in the RRPGE Minimal library are still work in progress, most notably the input interface.

If interested, just ask here. Locking one or another part of the RRPGE specification may be brought forth or delayed depending on interest: mostly there are no cross dependencies, so if interested in a part, just note, and I may shift work towards completing that.

The general plan now is working on game mockups which will settle the graphics subsystem, and later the input system. As I feel necessary I might bring forth matters regarding filesystem I/O (to produce tools), so that part might also be nearer, but likely after the input devices.
Announcements / Changed to Simple Machines forum
« Last post by Jubatian on April 23, 2014, 03:01:37 PM »
I changed over to Simple Machines forum. Well, alpha stage, everything is possible.

The problem with Vanilla was a flood of spam which I couldn't manage to work around in any way leaving the registration (even with admin approval) open. A severe deficiency of that system I think is that no matter which way registration works, the user profiles are accessible for editing, and these edits even show in the Activity tab. Requiring e-mail verification even made matters worse (the spambots then even could get over not even showing for approval, making even more cumbersome deleting these floods of users). Based on the access logs I got to see those bots "check" the profiles and the Activity tab (probably to verify their actions are visible).

Hopefully now things will straighten out. As of now it looks like without approval no content can be added to the forum, so at least even if the flood continues, at least it is only going to bother me as admin.

If it was time to change, I also did some re-organizing, hopefully making the layout of the forum more user-friendly.
Pages: 1 [2] 3 4