Hex-code Hex-code TCL

16 bit mode is only interesting if there's memory or bandwidth limitations :)
I have never had any problem working with 16 bit RGB and don't know what tasks would be complicated compared with 15 bit RBG. The quality difference in natural images are very visibly though.

the ranges above are size in memory, thus what a access would get if a single read happens
  Then since we assume a byte format standard we would have 6 bits left for encoding.(okay, Amiga chipset registers are word length)
  I take it we would only need 3 bits truly for encoding, but since i already said we would assume byte size we have some spare. ;)

I have been thinking in the register there should be a bit for alpha channel and solid.(transparent and bump map functionality)
32 bit mode should be able to support RGB10 for wider color range(nice to have for some apple images mid 90's)
16 bit mode should also support the vague 444 format this allows for more alpha.

The need for 4 bits to encode which layer the bump map is on 0000 is the first layer, 1111 is all layers.

okay it's official me spewing idea's make me seem rambling again doesn't it.

First i'll writes some documentation for this feature then i'll post it back here for the mean time i need some feedback.

S - Size
M - Mode
A - Alpha bit flag
G - Genlock bit flag
B - Solid bit flag
L - Layer/plane to apply bump map to.
R - Reserved for future purpose

SSMMMMAGBLLLLRRR

Size
00 - LUT8
01 - 16 bit map
10 - 24 bit map
11 - 32 bit map

Mode
Default is 0000
For LUT8 this is clear and for 24bit this is clear.
for 16 bit the 555 format is default.
for 32 bit the 888 format should be.

All other modes should be decided by the the one implementing it.

Alpha bit flag is default 0 meaning off this includes in the 32 bit map who would be handled like a padded 24 bit map.

Genlock bit flag for compatibility reasons, if not implemented should be considered Reserved and 0.

Bump map bit flag this should enable collision detection for BOB's and sprites, uses a X bit in the bit map if the mode is correctly set for it.

Layer bump map 0000 is the first layer counting up, 1111 is all layers.
this bits will not be physically on the layer but are suppose to be considered as if on that layer.

Note: Some modes do not allow alpha and bump map at the same time due to encoding constraints.

Hope you like the encoding scheme, and i hope it has use for the Natami II.

Unless you want genlock functionality supporting 15 bit ARGB as blitter/texture map source and 16 bit RGB as destination still is better. ARGB as a display format just wastes bit(s).

Maybe for future keep endien independent.

EXTERNAL LINK 

At least the gfx system should, for true color, work in the native endianness, i.e. red in the most signficiant bits, blue in the LSBs.

Little or big endian doesn't matter really as long as we stay consistent.

Thomas Hirsch wrote:

But then, if you dont like the 3x8 byte plane mode, dont use it. I wouldnt bother if you prefere and use 16, 24 or 32bit high/true color.

Well said.

Thomas Hirsch wrote:

The second thing is as I get it we need conversion methods between planar and chunky. I think it would make sense to do that in hardware.

This is an interesting subject.

Thomas Hirsch wrote:

In the end I/we want to have a fast and well responding system. In order to achieve that I/we need to figure out what software can/should do and what is better done by hardware (or the other way around).

What you say sounds very reasonable. I hope someone can come up with good solutions the "Amiga" way.

Thomas Hirsch wrote:

Of course PC graphic cards are "fast". I know that. But display/graphic generation on the Amiga works completely different than on a PC. It is an entirely different philosophy. CGX and P96 are "software adapters" for PC graphic cards into the Amiga. And because those PC graphic cards are really really fast a P96 or CGX graphic display is faster than an original Amiga. But this does not justify making the Natami graphic system compatible to a PC graphics card that it can be adapted by CGX or P96 to the Amiga.

Only a true Amigan talks like this. I completely agree with what you say here. It seems that far too many people want to have things the "PC" way, and as far as I understand that is not the purpose of this project - thankfully. :)

A) A bit in a register is set to byte reverse reads and writes to certain addresses.
B) A copy of a little endian memory map is created where reads and writes are byte reversed.

I think it makes sense to keep the Natami gfx big endian as that is the native format. I think it would be very useful to support little endian format for compatibility. Either method A or B above could probably be used in reverse. Reads and writes on the Natami would go directly to memory instead of through a bus where the translation occurs on a gfx card. I don't know if this kind of memory translation would require a MMU on the Natami. From a software perspective, I would prefer a method similar to B above. This is nice because a base address can be provided for little endian reads and writes. The base address can be pulled from a context and then an offset to the desired data accessed. This is how 2D and 3D registers and memory are commonly accessed on the Amiga in my experience. The disadvantage of method B is the amount of address space used. The Amiga can't use memory with the upper bit set (bit 31) as general purpose memory but it could use this memory as a little endian mapping of the same memory without the upper bit set. Chip memory only could be mapped in this way if there is other needs for some of this semi-usable upper address space. If an mmu was not required, it may be possible for these methods to work on the Natami 060 which lacks fast byte reversing in the CPU.

Let's take a look at the ways the CPU can support little endian. The N68k will have the ColdFire BYTEREV instruction that will convert a value in a register to little endian. This instruction should be able to combine with a move to convert and move data in 1 cycle using 4 bytes of code. This is nearly as efficient as the PPC byte reverse instructions lwbrx and stwbrx. The N68k is potentially less efficient because the move could possibly be combined with another operation if it were not combined with the BYTEREV instead while the PPC might operate at twice the clock speed because it's doing 1/2 the work. It would be more efficient for the N68k if the byte reverse was invisible to the CPU. Also, little endian memory accesses in ported PC software would need to have a byte reverse inserted into the code everywhere a non byte memory access occurs. Memory mapped to translate little endian to big endian would be invisible to the program and require less changes to ported code. The PPC also has a bit in the Machine State Register (MSR) that causes memory accesses to be byte reversed for the current task. Initially, this looks like a good solution but this is a global setting. A library function would have to change this global state and then change it back for the calling program. While changing the state is a supervisor instruction on the PPC, I believe it could be a user state on the N68k which would significantly lower the overhead. I believe it is still poor in practice for much the same reason as the global states for the 68k FPU rounding and precision are less than efficient. Any changes to the N68k would not work for the Natami 060 and would require different drivers.

Børge Nøst wrote:

If someone wanted to be creative you could add an MMU mapping to the cpu that switches endianness for a page.

This is a good idea and has possibilities depending on if and how it could be implemented. I would choose to create a copy of an existing memory area that does the little to big endian conversion. The disadvantages would be requiring an MMU, not working on the Natami 060 and the overhead of setting up the new memory area.

Greetings,
Thomas

Huh? If I want to run PC software, and I have its sources, I recompile it, and then it works - provided the software is written properly. GNU software has been ported to manifold architectures, and is thus endian-agnostic, or at least in a state where the compiler detects the endianness and compiles the software then properly, so I do not really expect any problems from endianness.

For example, the GNU software library runs both on my PC, as well as on my old-world G3 Mac, the former being little endian, the latter being big-endian.

i386 software cannot be executed on the Natami anyhow, and thus doesn't profit from little endian support in first place - unless you emulate a i386 in software. And then little endian support is your least problem. The emulated machine will be slow anyhow, but not due to the endianness alone.

IOW, while I understand that you want to port (open source) software, endianness is surely not a problem.

But this doesn't matter IMHO as long as we are consistent.
This means it doesn't matter which endian we take as long as we use it everywhere.

this means bitmaps on a hard disk could be saved little endian easy for transfer between machines.
While internally we would operate on big endian.
While we still refer to RGB operations hardware could do BGR if the interfacing software is aware of this one could abstract the user from it.