next »

[KillaMaaki]

At some point I'm gonna try and rustle up some web hosting and make a website/wiki/thingy for all of the dev info for Athena...
But anyway here's something new my friend worked out today. You use inline Athena ASM when you write functions and procedures in Apollo. Well, today that got a pretty significant improvement. Previously it just dumped your raw ASM into the generated final assembly, but now it actually has its own ASM parser and will parse your custom instructions. There's a lot of benefits to this:

1.) You can now directly refer to variable and function argument names and it will automatically translate those into the correct stack locations or warn you if it couldn't resolve that name:

Code:

function MyASMProcedure( myArg : ushort )
asm
	load r0 myArg ; "myArg" gets automatically translated into the stack location where myArg resides as an offset from the SBP register
	add r0 $0x10
	store r0 MyASMProcedure ; and just like in Pascal you assign to a "variable" named the same as the function to set the return value
end;

Still working out how this will work with arrays and structs but it already supports this for other variable types.

2.) You can use virtual registers. This means the registers you refer to of the form "r[number]" are actually "virtual" and only get mapped to hardware registers in the compilation phase. You can therefore use as many registers as you want, and the compiler will handle mapping those to hardware registers as efficiently as possible and spilling out to stack locations where necessary. It can also optimize your register usage via liveness tracking, where it keeps track of where you use registers and knows when it can reuse a register for other calculations if you don't refer to it anymore.

3.) Instruction-level optimization passes apply to your inline assembly now. I already mentioned it can optimize your register usage, but additionally it can do things like optimize redundant load/stores, perform instruction-level constant folding (if you load a constant immediate into a register and then, say, add another constant immediate value to that, the compiler will automatically fold those into a single load for you), etc.

[diegzumillo]

Neat! posting to follow as well.

What is the priority in this project, captivating limitations for the creatively inclined or technical limitations for those who love to write rasterizers for old systems and such? Or both in the same measure?

BTW, the pixel vision 8 seems to be customizable enough for 16 bit look and feel. Are you familiar with it? not quite what you want?

[KillaMaaki]

To some extent the feeling is to capture a bit of the same feeling you might get from developing homebrew software for an old console. This extends a little bit beyond just having video and audio limitations - while some of these are definitely a little arbitrary, a lot of the limitations of Athena are designed to feel "organic" for lack of a better term.

For example, Athena runs on a fixed-width 4 byte per instruction ISA designed after traditional load/store architectures, and with this your program must fit within just over 64 kilobytes (so just over 16k instructions). Why? Because 65535 is the biggest value a 16-bit number can hold, and all of Athena's registers are 16 bits wide, so that's the biggest program it can possibly index with its program counter. For the same reason, you must restrict your program to using no more than just over 65 kilobytes of RAM, because 65535 is the biggest address you can store. And finally, your entire game disk can be up to 32MB in size, because the included file system utility uses a FAT-like file system that runs on 16-bit sector indices, and with 512-byte sectors that equates to being able to index up to 32MB of disk sectors.
These should, ideally, feel like natural explainable consequences of the way Athena was designed, just like old consoles.

I've seen PV8. I wasn't aware that you could configure number of colors per sprite previously, although one thing I'm seeing unless I'm wrong is that while you can configure the number of sound channels, it still looks like you're essentially limited to simple wave generators for each channel.
Meanwhile, in Athena I definitely wanted something that sounded like it came directly out of the early 90s, so you get two 6-channel FM synthesis chips and a PCM playback chip to complement those. The idea is this should result in something that sounds very akin to the SNES and Genesis but potentially more approachable.

Another difference, though some may not care about this one as much, is that PV8 still like most fantasy consoles runs at a "high level", being scripted through either Lua or C#. Meanwhile, Athena still runs its own custom assembly and has a Pascal-like language that compiles into that assembly (and, in fact, you could absolutely target it with other custom language compilers - for example, writing a C compiler for it!)