@LiveForIt

Quote:

Yes I read about that. Didn't know about the EFM. I wonder how much "pure" data is 16 bit? With the modulation and what not. Especially since not all CD rips are equal. The data can change.

Quote:

At that point the damage is done. Bit advanced for a Paula emulator. In fact given it controls mixing using AHI no distortion should occur on the output.

Quote:

I suppose 2 bits isn't much to lose or recreate from existing bits.

If you want to deconstruct the signal then you need to get into FFTs, breaking it down into frequency components, then resynthesise it to reconstruct it back.

Given Paula is synthesised to begin with that might not be so far fetched.

Quote:

Lol. To be honest I can't even tell the difference anymore. Maybe I need to hear the real thing but to me a real Amiga playing a module sounds like just my X1000 playing a module with digital mixing.

Quote:

Depends on the DAC. Paula synthesizes it so it's not a pure basic DAC. It can take a staircase and the result will be smooth. It also has the analogue filters.

The max output frequency will be half of the sample rate as per the Nyquist theorem. I used to think it was because Paula had the sound in sample pairs so needed two samples for one difference. Meaning it could only output half the frequency at any time. But it wasn't related to the hardware implementation at all.

The same happened when I read about the magic 4489 MFM floppy sync number. I recall first reading about it an an Amiga document. It may have been a technical guide included with X-Copy. Now it said something about the smart people coming up with 4489. Because it was an Amiga document I thought the smart people were the Amiga designers. Nope, as it turns out it didn't relate to the Amjga at all, and the smart people thought of it before the Amiga came along. It was only to do with how the floppy is encoded.

Quote:

They are simple in principle. Split each 16 bit channel into upper and lower 8 bits. IIRC it plays the upper 8 bit sample on one channel pair at volume 64, scales the lower 8 bits into a 6 bit sample, and plays that on the other channel pair at volume 1. This has the effect of outputting 14 bit resolution. It somewhat simulates what would happen if it was volume modulated. Since a 6 bit sample matches volume resolution. Technically, it could just play the lower 8 bits in full at also volume 1, but apparently it's noisy as that's above what the volume does. I don't know if the 14 bit is a digital 14 bit or the 14 bit is some kind of analogue equivalent.

I've looked into using AM to do it in hardware. But there are some limitations. I forgot what they are. Needing to use CPU to write values is too much. I also theorised that 15 bit was possible a number of years ago when I did the math on it.

There is also 9 bit as used by Symphonie. This is a real possibility and unlike 14 bit can provide a real dynamic range of 9 bits digital without simulation tricks. And at full volume.

What I'm interested in is if anyone has scanned it with an oscillator? Fan boys going on about the Amiga doing 14 bit is all
well and good amongst themselves but I want to see some real results. Could be a good activity for my club.

Could be hard to quantify as an Amiga 16 bit sound card playing a 14 bit sample, to compare with as a baseline, won't be exactly what Paula would output with it's different DAC synthesis.

Quote:

Oh I understand. Yes, well, the idea wasn't suitable for the real thing anyway. So, this PUH thing uses the MMU to intercept Paula writes, diverts it to the AHI driver, which then directly writes it to Paula. Am I missing something?

The other advanced ideas don't make too much sense because it has Paula hardware. So, there really is no practical point apart from a proof of concept, unless someone is wanting to divert it to a 16 bit sound card.

On OS4 the idea makes sense. On the AmigaOne anyway. Since it has no Paula hardware. But it wasn't done as cleanly. It doesn't program the MMU. It overrides the DSI vector so it's kinda hacky. But, they didn't help in providing any other way, and when I enquired they refused to provide support for any program that wanted to add a hook to catch custom access cleanly. I'm still interested in if the MMU interface can do it in a cleaner fashion.

Quote:

Yes, it does a lot more, but it's also a fully integrated solution. So I think it's easier for it do do all that. Something like PUH has to intercept live calls to audio registers and deal with it in an instant.

Quote:

I suppose it's fully customised that way. It doesn't need to rely on AHI using the correct mixing mode or any options that avoid distortion. It can just generate the full sample stream. I can understand really. It needs to resample to one output frequency but also scale by channel volume. Paula volume is also said to be PWM based so a pedantic mixer can also take that into account. But apart from that, if output is 16 bit minimum, then volume can be used to upscale the samples to 14 bit then add to 16 bit. 6 bit volume x 8 bit sample = 14 bits. Mixed is 15 bits then upscale to 16, or upscale 14 bit to 15 bit then add. Fully mixed 16 bit result.

@LiveForIt

Quote:

No it wouldn't support 14 bit I think. I don't think I would call it half assed, it does what it's told. It detects a Paula write and sends it to AHI. AHI does all the mixing. Since that is the job of AHI.

14 bit is a specialist implementation. How would PUH know a program wants to play in 14 bit? In simple terms, one channel is full volume, while another is at 1. This could happen in a module, at one point in time, so how would it tell the difference and what the intended output desired is? It would need to interpret what is written in the registers and it may misinterpret it. Even if it could detect it another issue is a 16 bit source has been split to 14 bits, so it would still be missing the 2 lower bits, if it upscaled 14 to 16 for playback.

Quote:

Could depend on AHI mixing mode. It has a few mixing modes that usually only serve to confuse. Most AHI players I know of don't use AHI to do the mixing but do it themselves. At least on OS4. On 68K an AHI plug shouldn't do any mixing. First, AHI already provides a player interrupt feature so that should be used, and the AHI routines don't need any screen counter kludges. Don't know how AHI handles DMA wait internally. Second, an AHI player should request a proper Paula mode, so Paula does the hardware mixing.

Quote:

AM and FM support would be good in future as an exotic feature. But does anything even bother to use it? The 14 bit players don't use modulation mode directly but instead use the 64/1 volume pair trick to give the side effect of 14 bit output.

@K-L

That's more than Symphonie Player. You're running the full package! I didn't even know it worked.

I only got as far as loading it then no sounds for me. Since it obviously bypassed audio.device. Shame it's too early for AHI like a lot of the big Amiga audio programs.

@sailor

Quote:

Yes. I do. I have my main system, some extras for testing and others I've added that serve as a clean install as well as a backup of my system before it's updated.

Quote:

Yes but it's not full automatic so needs some setup. The XE is hardest as you need to combine all the Kickstarts by hand in one file and also move them into one volume. Then create a link for each volume to that Kickstart so they can be updated. It's a bit of work. And you have to make sure the loaded Kickstart matches the Workbench so BootDevice is needed. There's no tool I know of that can do it so it's all manual work. I did it again earlier this years for one extra volume on my XE and I must have rebooted five times in a row with a broken Workbench as I kept forgetting some step.

The X1000 is way easier since all the Kicklayouts are combined into one boot menu. Still have to ensure the Kickstart matches Workbench. I found after backing up my Workbench it was booting another Kickstart as it needed some CFE variable set to boot off the same one. This is almost a 20 year old problem and it should have defaulted to Workbench Kickstart was loaded off. I recall the XE had this issue and kept throwing up a screen about not finding Workbench after loading Kickstart from the same volume. It didn't make sense!

@K-L

Quote:

I didn't even know that worked!

@mbrantley

Quote:

I can give one.

Okay I can give another other than a hardware conflict in driver.

In the past people kept older version to run particular software. Like an older OS4 where DPaint actually works as they broke it later. Or even when there was better screen mode support for Amiga modes instead of everything running in a tiny 640x480 screen in the corner which isn't even an Amiga compliant size. But that's for a particular use and not a main volume with latest version. How ever there are practical reasons. Such as a user upgraded to FE on their XE then found Partition Wizard was broken. They are only using an XE so don't want to buy this third party package to fix it and why should they? So they keep an older OS4 around to run Partition Wizard which also supports writing to their JXFS volume.

@kas1e

Quote:

No way man, if I was still using the Lite driver I'd be stuck on 1024x768 with no hardware acceleration. I couldn't hack that! But with no compositing it would actually work better!

In fact, it wouldn't even boot. The OS4 OEM driver on CD doesn't even support an R7 250. I don't know what it supports up to as I can find no clear list nor see any models listed in the binary.

I've got the full RadeonHD from Enhancer 1.5 Plus.

Quote:

Though it needs a crash I find a crash log is the best way to list all versions. Since it logs all module versions in system which is convenient. Be good if a tool existed that could give the same list without needing to crash and save a log.

Quote:

Yes. On the amiga.org MantisBT September last year. Report #803.

Quote:

With full RadeonHD driver yes but it was before Update 2. So it actually works! I haven't yet patched an Update 2 boot CD together yet and it's pain we can't boot from USB.

I created test volumes on my HDD with fresh install and updates with the latest RadeonHD at the time. All froze on WB. My beta volume is worse as disabling interrupts and compositing doesn't fully fix it. So when AmiUpdate runs it stalls the system. For some reason AmiUpdate is good at killing the system this way.

It's related to interrupts and compositing. Disabling them lets the system boot but it's still not fully stable. There is no crash on serial. So it's hard to tell what is going on. The last thing on serial at boot is changing the pointer sprite and then the system freezes. But, according to a serial logger active tick tool, the system is still alive with the user interface frozen.

So, just to clarify, does the latest version need beta kernel? I downloaded a recent one a few weeks ago and it ran fine. Well it did actually work for me.

Things can progress fast in the OS4 world. Maybe adding a beta and keeping the current working one would be good. So anyone who downloads the latest stable doesn't need to be a beta developer.

@LiveForIt

Quote:

The MED code would have worked on an A500 and in that case it would have waited for less lines. The off byte is strange but on the real thing the bus could have read a word then then deposited a byte in the register. The JIT translation would be just be a byte read since I doubt it checks the address. The address would be unmapped in any case and any actual address on PPC should be byte readable.

Quote:

You could but if the interrupt is generated from vertical blank then a zero vertical position could be assumed.

Quote:

I think any kind of accurate timing is too complicated. It's only used to delay code for DMA wait until the DMA sets in for Paula playback so it can set the sample loop. With AHI this isn't needed as it goes through the driver. Any loop can be set immediately after. PUH already checks for this. A length of 1 with DMA started is an implicit one shot, otherwise a loop.

It really just checks the screen counter and counts down when there is a change. On modern hardware it's redundant. There may be DMA wait code that checks actual position but in common MED and PT code it doesn't check and just looks for changes.

Another possibility I've considered is checking the name of the interrupt routine and substituting with a native AHI player. Since typical names for PT and MED can be used. Of course it needs to patch 68K AddIntServer(), with yet another patch, but would be more efficient than emulating 68K code setting off an MMU trap 80 times in a row.

Quote:

That's useful. Don't know why it needs mem-handler. Seems hacky to rely on that.

Quote:

Does DPaint play sounds?

@smf

Quote:

I am one of those people. And I don't have mixed feelings on the matter. When I found Update 2 had a hardware conflict with my video card I had to mix an older Kickstart back in. So for me it's a fact I have problems. Sure, I could put my old HD5450 back, with no 3d. But, I had bought my R7 250 new AFAIK, because I found it had 3d support. I could locate an old card but I spent time locating a new card for my X1000 system. It still wouldn't solve the issue of why Update 2 conflicts with my card. But, boy can I pick 'em!

@LiveForIt

Quote:

In particular application.library as there was an obvious error in interface 1 that every one missed.

I found even trying to use version 1 gave me compiler error. Knowing the ramifications of it when I added support for it in a project I decided only interface 2 was supported. If it failed that feature just didn't work. Since it wasn't required by the main code. I just wanted to use it for notification so no big deal if it didn't open.

@walkero

Quote:

We know how I got stuck on that one.

Before I checked I thought MediaVault was NAS manager app. LOL.

Did they say how it didn't work? Or was it an obvious version fail and error?

I tend to think support the minimum you need. I wrote a few 68K commodities back in day and the minimum I supported was OS2. Now by the time I wrote them I was fully established on OS3 so wouldn't have wanted to use them myself on anything less. But they didn't need anything more than v37 in the code so didn't require it. Even my simple installer scripts were coded to use different components depending on what version was used.

These days I prefer OS4 coding but even then I keep old stuff in just in case it runs on an older version. Since if it doesn't need a new version I don't want to demand it. For example there is a particular version of Exec where allocating memory with AllocSysObject() has a bug because it doesn't clean the memory when it should so extra tags needs to be given. I suppose it's a slight kludge as I need to check for it but it's been there for years.

So the MED player reads $DFF007 as a byte which is funny since it's in a word. That's the horizontal counter. Not much can be optimised because it counts for it to change 80 times.

OTOH some PT routines read vertical from $DFF006 but using the same method. Counting off changes. So it looks like nothing much can be done to improve it apart from increasing both at once to compensate.

The audio.device allocation issue is likely because the audio.device defers to AHI so if NallePUH is active it takes the channels. But, PUH only allocates 4 channels, so unless the mode only had 4 channels there should be more left. The audio.device may be using exclusive mode then. Also, the AHI audio.device has a bug, as the lock command is broken if it matters.

A work around is using that mode that shares channels. Used to be on Unit 0 but I forget the details. It reduces quality though. Apart from simulating only 4 channels like Paula I never saw the point of exclusive mode. Just because you used the library interface which it bizarrely refers to as low level. Because it all gets converted to device calls anyway.

@kas1e

Fair enough.

A variety of subjects is fine but they need to be in their proper places. However, most threads end up changing into off topic discussions. That's just how the conversation of discussion evolves. I wouldn't complain there as I get involved in that as well.

It does look a bit downhill when threads start to appear for the purpose of insulting others. Especially now. I can see a landslide appearing here.

Not only news but ads are broken as well. If Vox's X1000 was only advertised on AW.net you'd still be waiting to buy it! Ha.

I think people like Vox and others should be reinstated. There's people that have 10 or 20 years bans which is ridiculous. Especially given the current state of affairs.

I wasn't aware A/EON owned it. Perhaps that explains lack of maintenance. There aren't many blank pages.

Is this because of the MEGA postings?

Ok, fixed some debug output, that wasn't sourcing destination register for data. Should show increasing counter now on $DFF006. Also see a flaw in the logger, that Reaper also has, where it prints the current task but likely that task wasn't it and it was inside an interrupt but it doesn't know the difference between task code and interrupt code. CIAgent also has that problem come to think of it. But it's worse when you are trying to debug an interrupt handler as the crash logger doesn't know what an interrupt is.

Okay made some edits and did a pull request. That should do it. But I haven't tested it yet.

@LiveForIt

Yes real hardware had $DFF006 so didn't need to catch it. Then again real hardware has real Paula so the idea didn't really make sense on real thing. Useful for Amithlon.

Should be easy enough to fix. Just add $DFF006 as VHPOSR and $DFF004 as VPOSR could be good idea as well. Just keep a running counter and increase on every read. Really is simple when you know how. I knew about it. Better is knowing what values are masked out so a jumping counter based on masking would reduce hits. It could read it 40 or 80 times in a row.

Add here:
https://github.com/khval/NallePuh/blob/main/PUH.c#L659

@FlynnTheAvatar

Are you telling us that make cannot make make? Well that's just typical! We can make it so.

@walkero

If there's a Greek Adonis you must be the Amiga Adonis!