@Gunnar

Quote:

Yes the sample each are Byte, and the DMA reads always 2 samples = one word. The two Bytes in the word need be in bigendian order as in the AIFF audio format.

When read in as DMA it would be in order. Two wholes as one part. Would have been convenient for a 16 bit update to Paula since the chipset is 16 bit oriented.

And big endian for AIFF until Apple hacked x86 into it.

Quote:

While on PC and WAV format their byte order is swapped.

The 8-bit WAV is normal. Except for the format that copies the hardware. I've heard comments that PC users think the Amiga sample format is weird. That's only because the PC users are weird in thinking a custom sample format is normal. Even some Amiga users wanted AHI to accept the unsigned WAV format.

But the Amiga (and AHI) signed 8 bit format is perfectly natural. It's signed so in standard format and good for maths. Aside from being a hardware format, WAV is in non standard format so needs extra work converting it if CPU needs to perform maths on it. 16 bit WAV being in backwards bytes.

@Hypex

Just an assumption that using floats or doubles can be better for mixing,

There is also the idea that actual endianness conversion can be better done in an external routine, because it can be optimized in a better way, instead of many individuals, attempts to do it, efficient.
naturally you have one library that’s also optimized for AltiVec, swap out these routines and get most out of your hardware.

68K AmigaOS has lot of lot of c2p routines as libraries, or linkable objects, it’s the same approach.

On PPC AmigaOS we need fast p2c routines, for emulation and legacy software, this can also be optimized.

Fast copy routines, I believe utility library has a few of this, optimized for different CPU models.

_________________
http://lifeofliveforit.blogspot.no/
Facebook::LiveForIt Software for AmigaOS

@Karlos

Quote:

It does somewhat depend on whether or not you regard the data as being organised or pixels of 32-bit words or as interleaved channel data in bytes. Don't forget there's RGBA and ABGR too. Just for the added torment.

Yes, RGBA, kind of like a PDP-11 in a hybrid kind of endian format. Mask of the alpha and then the RGB is oddly in the top bytes.

I got stuck on this lately when finding colours for a UI theme. So I'm using an API that was returning ARGB for colour keys. Then I used it to draw a box on screen and it was slightly wrong. I tried masking off the alpha channel to no avail. Turns out in this case, that the colour stored in the theme is a signed integer in the native format and it must be converted into a BGR for API drawing functions.

This was strange as I'm using a PC laptop, so expect it to be stored as BGRA, but natively it was stored as ARGB. I'm using Linux so don't know if Linux uses one specific format. But I tend to think one standard should be used in the API that is stored in theme files. And if needs converting it should be done behind the scenes and be hidden. I'm using one API to do it so expected all the functions to be compatible but they aren't. This needed another function to convert it. But it gets worse as screen dimensions differ in Linux and Windows so the OS needs to be checked.

So, ARGB, backwards to BGRA, it does matter!

Quote:

I tend to think of them in terms of 32-bit words purely because it's the most efficient way to read and write VRAM on an RTG card. Conceptually though, there's no real "natural order" to the bytes. Just convention.

You can read and write it and result is the same any where.

@Bosanac
Quote:

I don't know whether to laugh or cry at this! :facepalm:

Laugh now. Cry later.

_________________
Doing stupid things for fun...

@cdimauro

Quote:

Clearly no. That's why I've written first Amiga and then AmigaOne: to distinguish / separate them.

Yes, of course, as I do but some Amiga people are slightly parental about it and don't like Amiga being there at all. Some ask why it can't be another name and don't think Amiga should be associated with it at all, as if it had no relation at all. By comparison, not even the Vampire in standalone form has Amiga in it, nor did they call it Vamigapire or something like Vamiga. I would have called the AmigaOne series the Amigos. A reference to where it comes from being Amiga inspired and how it focuses on the OS, Too late now.

@Karlos

Quote:

My A1 died just as it was getting interesting. I had a selection of expansion cards I was working on drivers for, then poof.

That's a shame. I must be of the few people who still has a working A1. And I've broken it before. It had a G4, but I took it out to clean it with a view to "even" clocking it to 933. That turned out to be a bad idea, as I cleaned it and was carefully screwing it back in place, when somehow the screw had an imbalance and fractured the CPU!

I ended up replacing it with a G3 as I thought the G4 repair cost was too much. It was hard to be without it as it was my full time Amiga machine. I tried to use my A4000 but it didn't understand my OS4 HDD partitions so I couldn't even use it temporarily for my project work.

Years later I started getting failings. Black screen. Replaced battery to no go. Turned out my RAM went bad or just dirty. I pulled out the RAM then slotted it back in and suddenly it was working! But before then I had stripped it down. I found pulling all cards including VGA card and RAM was best way to test with so only power remained. Then hooked a serial cable in to see if UBoot was alive. It is with a good battery. Then I went from there.

Looks like you had quite a set up going there. Customised Workbench. Those were the days.

Like me, you were part of two worlds. Amiga and the One world. Given a lot of Amiga people don't see the point of these machines and for the last 15 years go on about the PC being cheaper and faster, so nothing changes really there, what was your interest in the AmigaOne and investing in it?

@Hypex

Quote:

Like me, you were part of two worlds. Amiga and the One world. Given a lot of Amiga people don't see the point of these machines and for the last 15 years go on about the PC being cheaper and faster, so nothing changes really there, what was your interest in the AmigaOne and investing in it?

It started when my Apollo 1240 became too unstable some time in around 1996 or so (I can't recall the exact date). It was a very early revision - so much so the ROM was socketed and prone to working loose. It was exceptionally fussy about memory, needed patches for everything to make sure that the ROM and any libraries or devices opened by it were in Fast RAM and various other hacks.

I wanted to update to a Blizzard 1260. Then, almost out of the blue, the BlizzardPPC appeared. So, I ended up sidegrading to that. Same 68040/25MHz but it was way more stable and less dependent on hacks. I got the SCSI version, despite having no drives, as I had intended to get one of those natty adapters (TLDR, never happened, lol). The other big motivation was the prospect of a decent RTG card as Phase5 weren't exactly subtle at hinting one was in the works.

The PPC was a bit of a sideshow at the time. I enjoyed it for the benefits it gave in terms of accelerated libraries and datatypes and a few applications and games. Quake on the PPC was an eye opener at the time though. I got the BVPPC when it became available and started giving more serious attention to writing my own code that took advantage of WarpOS, RTG and Warp3D at the time.

Then MorphOS and eventually OS4 began to take shape. I got into OS4 in a large part because I'd done some driver work (that I think was never actually released at the time) for Warp3D on the P2 driver. So that led to having early access OS4 on the BlizzPPC.

A very good friend of mine at the time had invested in the A1 around that time. Like me he had a custom Frankentower A1200, full of expansion hacks. At some point he became disinterested with the A1, in part I think due to the many early issues and loaned it to me. I sourced various different expansion cards, bought 4.1 for it and worked on improving some of the existing 3D drivers and maybe some bits of the then RTG.

Generally speaking, it worked well. The day I discovered The Maestrix worked on it was an especially good one as a long time OctaMED fan.

And then, one day, after some years of stability it just died. Like so many others of its kind.

_________________
Doing stupid things for fun...

@Karlos

Quote:

I had intended to get one of those natty adapters (TLDR, never happened, lol).

There’s one IDE to SCSI adapter just sitting in a box in my office.

It’s all yours if you want it.

@Bosanac

I'm not sure the system is in a working state as it is.

_________________
Doing stupid things for fun...

@Karlos

😢

@Hypex

Quote:

Hypex wrote: @Gunnar Quote: Yes the sample each are Byte, and the DMA reads always 2 samples = one word. The two Bytes in the word need be in bigendian order as in the AIFF audio format. When read in as DMA it would be in order. Two wholes as one part. Would have been convenient for a 16 bit update to Paula since the chipset is 16 bit oriented. And big endian for AIFF until Apple hacked x86 into it. Quote: While on PC and WAV format their byte order is swapped. The 8-bit WAV is normal. Except for the format that copies the hardware. I've heard comments that PC users think the Amiga sample format is weird. That's only because the PC users are weird in thinking a custom sample format is normal. Even some Amiga users wanted AHI to accept the unsigned WAV format. But the Amiga (and AHI) signed 8 bit format is perfectly natural. It's signed so in standard format and good for maths. Aside from being a hardware format, WAV is in non standard format so needs extra work converting it if CPU needs to perform maths on it. 16 bit WAV being in backwards bytes.

I agree: I prefer the 8-bit signed standard for audio samples.

However looking at the audio samples as a sequence of bytes (as they are), little-ending was a better match (the first sample was always the lowest byte of the sequence. And so on).

@Hypex

Quote:

Hypex wrote: @cdimauro Quote: Clearly no. That's why I've written first Amiga and then AmigaOne: to distinguish / separate them. Yes, of course, as I do but some Amiga people are slightly parental about it and don't like Amiga being there at all. Some ask why it can't be another name and don't think Amiga should be associated with it at all, as if it had no relation at all. By comparison, not even the Vampire in standalone form has Amiga in it, nor did they call it Vamigapire or something like Vamiga. I would have called the AmigaOne series the Amigos. A reference to where it comes from being Amiga inspired and how it focuses on the OS, Too late now.

I think that you already know of my opinion about fanatics (coming from whatever side: Amiga, OS4, MorphOS, AROS, 68k, etc.).

@cdimauro

Last edited by kolla on 15-Oct-2022 at 09:22 PM.
Last edited by kolla on 15-Oct-2022 at 09:21 PM.

_________________
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC

@kolla: OK, but... I don't understand... :|

@cdimauro

Quote:

Strange. Check again.

Okay I checked. Well I kinda cheated as I used my UAE install but it's easier to setup from the click of a button. So looks like I've confused the WHDLoad install with the game slave install. I downloaded the latest WHDLoad and it's fairly simple with just a few commands copied to C.

I was able to install a few games. In the readme they state they need ROM1.3. A few install but when loading complain about a missing Kickstart. In particular I tested BattleChess, Swooper and Test Drive II. The Kickstart requirement is superfluous and unnecessary for these games. They all boot fine from ROM3.1 and have worked fine on my A1200. In particular BattleChess and Test Drive II have HDD installers. BattleChess runs fine from HDD so WHDLoad install is a bit overkill. Though Test Drive II can run fine from HDD it does need the floppy in drive so can benefit.

I used FS-UAE which still needs some work in floppy management. It was hard to insert a floppy as the built in floppy loader forgets disks inserted easily. Even after quitting and reloading.

Quote:

Naah. x64 is quite easy and similar to 68k in many aspects. It's much more readable compared to PowerPC. IMO. It might be because I'm used to it since years now.

Is that because of the extra R8 to R15 registers that make sense? On top of the R registers. Likely meaning Really extended. They must have ran out of the alphabet.

Quote:

Then it's better to try some of its OpenGL ports.

In that case it should use Warp3D or some 3d hardware driver. An OpenGL game using a software renderer is not exactly suitable. I could have done a Quake test which was on the cusp of hardware 3d but does have the soft renderer port.

Quote:

GLOM. No, please! Itanium was a failure, since the beginning.

It was Intels chance to break from x86. But AMD ruined it with their 64 bit extension. It's only been a few years since it dropped out of the market. Hey POWER won! It's still around! Ha! But it was complicated, being not purely RISC, not purely CISC, but some combination of both and some neither. In any case, it is what become of the HP-RISC since HP approached Intel. Like I've said before, had the Amiga survived and the Hombre been produced, it may have had an Intel inside. But it wouldn't have been an x86!

Though Intel were working on their own x86-64 designs, the x86 was still like Simple Minds and their hit Don't forget about me. Because they were most well known for it but didn't write the song. Intel produced the x86 but in the history leading up to it, coming from the 8008 ISA with which it shares similarities in design, the 8008 ISA was not designed by them but by Datapoint. I suppose it was given to them in a way by Datapoint, since they could keep the design, and after producing and refining it into x86 for so many decades it's been big business for them.

This quote from the Itanium Wikipedia page is gold:
"I looked Albert Yu [Intel's general manager for microprocessors] in the eyes and showed him we could run circles around PowerPC, that we could kill PowerPC, that we could kill the x86."

Well, he did kill the PC in a way, the PC in PowerPC, since Itanium pretty much survived while PowerPC disappeared and only POWER remains!

I don't quite see why killing PowerPC would be a big deal, was it special? And it's quite bizarre to go up to a generic manager at Intel and suggest how to kill a major product line.

In future this could become a joke if it doesn't find a solid market. Why didn't quantum computers take over the world? Because they weren't IBM compatible.

Quote:

Usually yes, but since several years "vector" is used for the variable-length extensions.

Since they group data they could also be A for array.

Complicates the encoding, but I imagine generally vector operations are variable. At least, I would take vector to imply dynamic width, where the width of each vector in a group could be variable. Working with non-N powers would be useful, but I don't know if even the latest 512 or 1024 width extensions can work that way, like with a packed data stream.

Quote:

Which length? The single lane/data length (8, 16, 32, 64-bit) ? Or the full register size (128, 256, 512, 1024)?

The single lane/data length.

Quote:

The 68k width protocol could be used for lane/data. But I've found another, more compact, solution for my NEx64T.

Interesting name.

I keep thinking back to Nintendo N64 for some reason.

Quote:

Well, there are many other letters available.

Yes it's not x86 .

I found 68000 actually does have a MOVES.

And regarding 68K conventions, at least for FPU, each instruction was prefixed with a signifying letter.

Quote:

Just extend them to 128 bit (at least)...

And match PowerPC.

Quote:

How? Mem-to-mem was only available for the general MOVE instruction. Plus there are a few arithmetic instructions with specific, fixed EA modes. So, there are no other mem-to-mem instructions on 68k.

It was. There are at least EA to FP and FP to EA for FPU ops. One way would be to encode it as a long instruction with extended codes and addresses. It would need to internally combine a few microcodes. Doing so would extend the length of encodings above the space needed for vector ops already, Convenient but not a necessary expense.

Quote:

Better to follow other ISAs and use something like PMOVE or PLOAD, etc.

Just make sure not to confuse it with MOVEP.

Quote:

Already done, unfortunately...

It's fine while in development and noticing how a better way could be used. But harder once it's released to the public to change it.

Quote:

More or less. But to me the misleading part is the .b, since this instruction only supports bytes...

That could actually be consistent with the operation.

Quote:

You don't need an account: you can get the manual by just clicking on the link (which us provided on the Apollo forum).

I mean, those links that only get shared on Discord or somewhere like it's an exclusive club.

Sometimes it is. Take SDK info for AmigaOS and autodocs. So these are easily found online. Plenty of 68K discussion. OS4 has plenty of resources and a forum. But when I was interested in looking up info on MorphOS I found the info hard to come by. The most info I found was looking up the AROS API where it shares functions with MorphOS. I once asked about Firewire debugging I had read about. Then was told I should ask on IRC. IRC? How about just making the info available.

Quote:

I agree. Sprites were too limited. Useful, since the Blitter had its own problems, but I preferred a more powerful Blitter (and system, in general).

I think we all did, even if we all didn't know all the technical details.

Quote:

ROFL

Quote:

But a much better system...

VGA or C16? Or perhaps C64?

@NutsAboutAmiga

There's a few reasons for mixing in floating point. Generally it offers 64-bit minimum so contains headroom for mixing. 32-bit float is also becoming common as a storage format which can record any distortion without chopping off the head or feet of a waveform. But the main reason would be because it works with decimal numbers. A 16 bit sample will be -32768 to 32767 in integer. But as float it will be -1.0 to 1.0 like on a graph. This also helps calculating FX and everything else. Because it wants to work with decimal values going from -1.0 to 1.0. And float can do that naturally with extra precision.

The built ins for GCC to optimise endian conversions are a good idea but they aren't optimised for PowerPC. They work well for x86 as that has BSWAP for register swap and MOVEBE for endian read/write to memory. PowerPC only has it for reverse byte loads and stores and it's really only needed for memory access in usual cases. But the GCC built in only work on parameters. This is too late. The value is read in and then converted. So it's still a shocker on PPC. It really needs a built in that directly reads it or writes to memory address. Since endian problems are with memory storage and not with internal operations. For this reason ASM can still be better. Especially for PPC when an ASM macro work best until compiler built ins are design to make use of CPU features.

C2P is a bit harder as it needs to operate on a large data size and rotate a bit matrix. Thus why we see optimised assembler routines working on as much data as possible before writing it out. And also, working with blocks of 32 pixels across, because it needs to write 32 bits out to chip ram for maximum efficiency.

I'm aware of utility library having 68020 optimised routines. Didn't know about for copies. The old Exec CopyMemQuick() still does all right.

@Hypex

I'd go a step further and say that floating point is the most natural format for audio processing. It allows things like filters and many other effects to be implemented in their most direct form, as well as oscillator functions and other synthesis techniques. I'm pretty sure the whole VST framework uses floating point. While the end playback may be suitable for quantisation, the intermediate processing can result in values far outside the eventual output range.

The only reason you'd use integer is of you don't have floating point support, or it's too slow on your target, or you are implementing it on some fixed point DSP.

_________________
Doing stupid things for fun...

@Karlos

I agree with your assessment. Before I knew about how these FX and VSTs work I wouldn't have known about it and just thought in terms like a signed 8 it or 16 sample. Although a sample is just that, a sample, it was only when I was looking at FX source codes that I could see what was happening. In particular basic filiters using sin() or cos() functions. Not that I understand them, since I haven't studied them, but after seeing the math involved I can understand why floats would be used.

Gone are the days when MED did mixing with fixed point integers simulating floating point.

@Hypex

Quote:

Hypex wrote: @Gunnar Quote: Yes the sample each are Byte, and the DMA reads always 2 samples = one word. The two Bytes in the word need be in bigendian order as in the AIFF audio format. When read in as DMA it would be in order. Two wholes as one part. Would have been convenient for a 16 bit update to Paula since the chipset is 16 bit oriented. And big endian for AIFF until Apple hacked x86 into it. Quote: While on PC and WAV format their byte order is swapped. The 8-bit WAV is normal. Except for the format that copies the hardware. I've heard comments that PC users think the Amiga sample format is weird. That's only because the PC users are weird in thinking a custom sample format is normal. Even some Amiga users wanted AHI to accept the unsigned WAV format. But the Amiga (and AHI) signed 8 bit format is perfectly natural. It's signed so in standard format and good for maths. Aside from being a hardware format, WAV is in non standard format so needs extra work converting it if CPU needs to perform maths on it. 16-bit WAV being in backwards bytes.

Qualcomm Hexagon DSP is also a little endian. Hexagon DSP is used in Qualcomm Snapdragon SoCs.

_________________
Ryzen 9 7900X, DDR5-6000 64 GB RAM, GeForce RTX 4080 16 GB
Amiga 1200 (Rev 1D1, KS 3.2, PiStorm32lite/RPi 4B 4GB/Emu68)
Amiga 500 (Rev 6A, KS 3.2, PiStorm/RPi 3a/Emu68)

@Hypex

Fixed point still has a place for a lot of audio, especially in hardware that relies on DSP type technology, where fixed point is commonplace. Floating point became the standard for software synthesis and DAW because not just because many of the algorithms used are best expressed in floating point but equally importantly are good targets for SIMD too.

_________________
Doing stupid things for fun...