English Amiga Board


Go Back   English Amiga Board > Support > support.Hardware > Hardware mods

 
 
Thread Tools
Old 29 September 2022, 17:58   #221
nonarkitten
Registered User

nonarkitten's Avatar
 
Join Date: Jun 2018
Location: Calgary/Canada
Posts: 229
You know there seem to be three kinds of trolls in the Amiga community right now.

We have the feature creeps where nothing is ever good enough because in their mind it needs to compete with a modern PC. AGA isn't good enough, they need 32-channel 16-bit sound with 3D accelerated RTG and an 8 core, 4GHz CPU to back that up. Clearly their brain trust has failed them, because what they want is a PC and can't get out of their PC-envy/hate that Amigans suffered in the day to move on.

We have the luddites who want absolutely nothing new and grumble about any new feature. AGA sucks, ECS was fine. No one needs faster floppies. Upscaling is too hard. New is bad! NEW IS BAAAD!

And the have the Pi nazis who will replace every part in their Amiga with a Pi if they could but don't get that just running UAE on a Pi would be better. Everything must be a Pi or it is no good!

I'll try and watch my language but unless you're being constructive, could you kindly find a flesh cave of your own making and shove yourself into it?

Last edited by nonarkitten; 29 September 2022 at 18:05.
nonarkitten is offline  
Old 29 September 2022, 18:24   #222
pandy71
Registered User
 
Join Date: Jun 2010
Location: PL
Posts: 2,041
Quote:
Originally Posted by nonarkitten View Post
I'll try and watch my language but unless you're being constructive, could you kindly find a flesh cave of your own making and shove yourself into it?
lol - don't need to be mean... and i'm not against these features (even if some of them with such small FPGA seem to be not so realistic), twice faster MFM can be achieved currently just by adding MFM encoder/decoder so no software encoding/decoding required - just single "POKE" to set or clear bit - if you check currently available sample rates granularity and how close you can be to industry standard (32000, 44100, 48000 and associated 16000, 22050, 24000) or to UART standard baud rates (115200) i hope you will understand what i'm trying to say (NCO is just phase accumulator so no need dedicated PLL).

Once again you and kipper2k doing great and hard work and this is very appreciated - be well and good luck.
pandy71 is offline  
Old 29 September 2022, 18:28   #223
Gorf
Registered User

Gorf's Avatar
 
Join Date: May 2017
Location: Munich/Bavaria
Posts: 1,731
Quote:
Originally Posted by nonarkitten View Post
And the have the Pi nazis who ....
... insist on Apfelstrudel?
Gorf is offline  
Old 30 September 2022, 02:39   #224
grelbfarlk
Registered User

 
Join Date: Dec 2015
Location: USA
Posts: 2,591
I was just suggesting the Waveblaster header because:
It's incredibly simple to integrate
It's totally optional, but for people who want a nice sounding midi synth this is a pretty clean way of doing it
Doesn't require any support from you and your people
It wouldn't require any significant system resources

But I get feature creep
grelbfarlk is offline  
Old 30 September 2022, 03:41   #225
QuikSanz
Registered User

QuikSanz's Avatar
 
Join Date: May 2021
Location: Los Angeles / USA
Posts: 86
Original specs look fine, leave it alone for now. Better, maybe l8r. now is good!!
QuikSanz is offline  
Old 30 September 2022, 06:18   #226
Promilus
Registered User

 
Join Date: Sep 2013
Location: Poland
Posts: 374
I'd say since initial design is done it would be best to wait a while for a "alpha test batch" to be distributed and tested. And then, eventually add feature list to "beta batch" which - at some point - might require pcb rework anyway.
Promilus is offline  
Old 30 September 2022, 06:24   #227
QuikSanz
Registered User

QuikSanz's Avatar
 
Join Date: May 2021
Location: Los Angeles / USA
Posts: 86
Works for me. Its a good start, get that and others correctly first then new stuff.

Chris
QuikSanz is offline  
Old 30 September 2022, 15:15   #228
kipper2k
Registered User

 
Join Date: Sep 2006
Location: Thunder Bay, Canada
Posts: 4,219
My thougts are to get the basics working, allow for updates via chip size usage and PCB design, Once a basic design is working then any additions wouldnt compound any errors that there may be.
kipper2k is offline  
Old 30 September 2022, 20:30   #229
Wayne123
Registered User

 
Join Date: Sep 2015
Location: So. California, USA
Age: 62
Posts: 61
I could really use one for my 3000, nice to see all the new hardware being created.
Wayne123 is offline  
Old 03 October 2022, 01:52   #230
QuikSanz
Registered User

QuikSanz's Avatar
 
Join Date: May 2021
Location: Los Angeles / USA
Posts: 86
@kipper2k,
Where should I expect the sale of new chips, your site? or another. Will keep looking.

Chris
QuikSanz is offline  
Old 03 October 2022, 17:56   #231
AJCopland
Registered User

 
Join Date: Sep 2013
Location: Beeston, Nottinghamshire, UK
Posts: 230
Quote:
Originally Posted by nonarkitten View Post
In 16bpp mode, chunky mode will use a 4444 RGBV mode where the high 4-bits of each channel are independently controlled and the low four bits are the same for all three channels. This produces 65536 colours with 256 gradients.
How do you get 65536 colours from 4444? I don't quite understand this one. I've used it as RGBA on console but there it give 12-bit (4096) colour with 16 steps of Alpha.

If I've understood correctly you take that 12-bit RGB and then the other 4-bits would modify it somehow to get 65536. Sorry I just didn't understand the usage of the V channel.

Since we're hypothecising about 16-bit is there any reason to not support 5551 or 565 formats? Does it just not fit with how the hardware can be made to work?

This is not criticism by the way, I'm just trying to understand the idea
AJCopland is offline  
Old 03 October 2022, 18:13   #232
lmimmfn
Registered User

 
Join Date: May 2018
Location: Ireland
Posts: 442
Quote:
Originally Posted by AJCopland View Post
How do you get 65536 colours from 4444? I don't quite understand this one. I've used it as RGBA on console but there it give 12-bit (4096) colour with 16 steps of Alpha.

If I've understood correctly you take that 12-bit RGB and then the other 4-bits would modify it somehow to get 65536. Sorry I just didn't understand the usage of the V channel.
The V is Value from HSV, or Brightness. so each colour can have its brightness changed separately, similar to half bright but allowing configurable 4 bit brightness
lmimmfn is offline  
Old 03 October 2022, 18:16   #233
Romanujan
Registered User
 
Join Date: Dec 2007
Location: Szczecin/Poland
Posts: 413
Once all these Buffee replacement chips are ready, will it be possible to create a brand new ReAmiga 1200 with brand-new (no NOS) components only?
Romanujan is offline  
Old 03 October 2022, 19:39   #234
nonarkitten
Registered User

nonarkitten's Avatar
 
Join Date: Jun 2018
Location: Calgary/Canada
Posts: 229
Quote:
Originally Posted by AJCopland View Post
How do you get 65536 colours from 4444? I don't quite understand this one. I've used it as RGBA on console but there it give 12-bit (4096) colour with 16 steps of Alpha.
The fourth component is value, not alpha.

Quote:
Originally Posted by AJCopland View Post
If I've understood correctly you take that 12-bit RGB and then the other 4-bits would modify it somehow to get 65536. Sorry I just didn't understand the usage of the V channel.
So we have four bits per component; reg, green, blue and value. For example, if we have the 12-bit RGB colour $A37, this would look like:
Code:
R G B Bit
1 0 0  3
0 0 1  2
1 1 1  1
1 1 1  0
The value component adds low bits to all three channels, so if we then had say $A375, it would look like:
Code:
R G B Bit
1 0 0  7
0 0 1  6
1 1 1  5
1 1 1  4
-----
0 0 0  3
1 1 1  2
0 0 0  1
1 1 1  0
V V V
Or in 24-bit terms, the 16-bit RGBV colour $A375 becomes $A53575. Though sometimes I wonder if interleaving the bits wouldn't be more useful. Maybe I'll make a little C# program to vet these.

Quote:
Originally Posted by AJCopland View Post
Since we're hypothecising about 16-bit is there any reason to not support 5551 or 565 formats? Does it just not fit with how the hardware can be made to work?
In 555 RGB you can produce only 32 shades; with 16-bit RGBV, you can produce 256 shades. The eye is more sensitive to luminosity changes (hence why HDMI has chroma subsampling) and RGBV leverages this. If we totally went crazy, I'd say an 8-4-4 Lab or YCbCr would be even better, but that's a little too freaky for some people.

The NEOGEO used a similar scheme with 15-bits RGB and one value bit they called the "dark bit," giving it a near 666 RGB colour range. So that's an interesting compromised between 565 RGB and a 5551 RGBV -- if that were the same bit then anything made to use 565 wouldn't look TOO wrong in 5551... hmmm.

The disadvantage of this scheme is that it makes for less saturated colours (though more useful ones). For example, if we compress this down to a simple 4-bit palette we end up with:
Code:
$000 Black
$555 Dk Grey
$00A Blue
$55F Lt Blue
$0A0 Green
$5F5 Lt Green
$0AA Dk Cyan
$5FF Lt Cyan
$A00 Red
$F55 Pink
$A0A Purple
$F5F Lavender
$AA0 Gold
$FF5 Yellow
$AAA Lt Grey
$FFF White
Which if you squint, is really close to what we got with the C64 (except we're trading cyan for orange). But you'll notice there is no "pure red" -- you have "pink" at $F55 and "red" at $A00 but not $F00.

The advantage of this is that it interrupts the Amiga hardware pipeline less. I was actually thinking of maybe even having 8-bit be a 2222 RGBV for consistency. You can think of this as a type of colourspace compression where we're favouring luminosity over saturation, that's all.

Quote:
Originally Posted by AJCopland View Post
This is not criticism by the way, I'm just trying to understand the idea
Hope this helps.
nonarkitten is offline  
Old 04 October 2022, 04:33   #235
QuikSanz
Registered User

QuikSanz's Avatar
 
Join Date: May 2021
Location: Los Angeles / USA
Posts: 86
Quote:
Originally Posted by nonarkitten View Post
We plan to have Willoe address 16MB regardless and all of this is "DMA-able", that is, it can be read or written by any of the custom chips. It is useable for video, blitter objects, sprites, audio samples, disk buffers, etc., but only the first 2MB or less is directly accessible by the CPU.

If you install Xander, then you can have up to 2MB on all systems. If you then enable 4MB or 8MB of chip, then yes, that would cut into Zorro RAM as chip RAM is always contiguous (e.g., all 8MB would need $000000 to $7FFFFF).



I'm really a rookie here but does $7FFFFF leave enough for a PicassoIV? Must have 4 Meg!



Chris
QuikSanz is offline  
Old 04 October 2022, 05:11   #236
nonarkitten
Registered User

nonarkitten's Avatar
 
Join Date: Jun 2018
Location: Calgary/Canada
Posts: 229
Quote:
Originally Posted by QuikSanz View Post
I'm really a rookie here but does $7FFFFF leave enough for a PicassoIV? Must have 4 Meg! Chris
No, you'd have to scale back to 4MB or 2MB of chip RAM.
nonarkitten is offline  
Old 04 October 2022, 05:16   #237
QuikSanz
Registered User

QuikSanz's Avatar
 
Join Date: May 2021
Location: Los Angeles / USA
Posts: 86
OK, so anything after 2 meg is in Zorro space. 4MB it is. When and where to buy?

Chris
QuikSanz is offline  
Old 05 October 2022, 01:23   #238
Bruce Abbott
Registered User

Bruce Abbott's Avatar
 
Join Date: Mar 2018
Location: Hastings, New Zealand
Posts: 1,265
Quote:
Originally Posted by pandy71 View Post
twice faster MFM can be achieved currently just by adding MFM **encoder/decoder** so no software encoding/decoding required
Yes, and it doesn't take any more bandwidth than DD MFM. But this is incompatible with trackdisk device so it would need its own driver.

I'm not a fan of HD format because the disks tend to be unreliable. We have better storage options for large files these days so the extra capacity isn't needed. With a PC floppy drive you can use HD disks in DD format by covering the HD detect hole, so the (relative) lack of DD disks isn't a problem.

Quote:
if you check currently available sample rates granularity and how close you can be to industry standard (32000, 44100, 48000 and associated 16000, 22050, 24000) or to UART standard baud rates (115200) i hope you will understand what i'm trying to say (NCO is just phase accumulator so no need dedicated PLL).
I'm against adding 'improvements' where they aren't really needed.

Paula wasn't intended to be a studio quality audio device, so slight variations in playback frequency aren't important.

But why is 22050 an 'industry standard' anyway? It's half of 44.1kHz, which was chosen because at 3 samples per line it matches both PAL and NTSC video timing. Why is this important? Because digital audio was being recorded on video cassettes using the standard line by line helical format. This frequency was then used for audio CDs, and the submultiples of 11025 and later 22050 were used in the Sound Blaster card.

So in standard screen modes an 'enhanced' Paula could get exact 22050 playback by simply locking the sample rate to the video line frequency.

But what the Amiga really needs is a way of reproducing 16 bit audio more accurately and with less overheard than the so-called 14 bit mode. It would be nice if you could produce true 16 bit output by eg. interpreting each word as a single 16 bit sample. If the DAC can't do 16 bits then even 12 bits would be better than the 10 real bits of calibrated '14 bit' mode. Other possibilities include using 8 bits for applying volume to every sample, or an exponential mapping such as u-law.

When set to 115,200 the Amiga's baud rate clock is within 0.6%, which is fine. What the serial port really needs is a multi-byte receive buffer.
Bruce Abbott is offline  
Old 05 October 2022, 07:31   #239
nonarkitten
Registered User

nonarkitten's Avatar
 
Join Date: Jun 2018
Location: Calgary/Canada
Posts: 229
Quote:
Originally Posted by Bruce Abbott View Post
I'm not a fan of HD format because the disks tend to be unreliable. We have better storage options for large files these days so the extra capacity isn't needed. With a PC floppy drive you can use HD disks in DD format by covering the HD detect hole, so the (relative) lack of DD disks isn't a problem.
That was a great way to get data errors. DD and HD don't have compatible media as SD and DD had. This is probably why it got a reputation for being "unreliable." On Mac and PC I never had an issue with HD floppies in HD drives.

Quote:
Originally Posted by Bruce Abbott View Post
I'm against adding 'improvements' where they aren't really needed.
... or supported.

Quote:
Originally Posted by Bruce Abbott View Post
Paula wasn't intended to be a studio quality audio device, so slight variations in playback frequency aren't important.
The shift from PAL to NTSC does bug me, but it's less about the note than it was the speed of music (50->60Hz is a bigger jump than 3.58MHz to 3.54MHz).

Quote:
Originally Posted by Bruce Abbott View Post
So in standard screen modes an 'enhanced' Paula could get exact 22050 playback by simply locking the sample rate to the video line frequency.
NTSC is 15.75kHz. Three scanlines would be 47.25kHz.
PAL is 15.625kHz. Three scanlines would be 46.875kHz.

Paula's timing is based on 3.5MHz ticks though (3546895 Hz PAL, 3579545 Hz NTSC) and 22050 would be 162 on NTSC making 22,096 Hz and 161 on PAL for 20,030 Hz. The shift from 22050 is probably undetectable to most people.

Quote:
Originally Posted by Bruce Abbott View Post
But what the Amiga really needs is a way of reproducing 16 bit audio more accurately and with less overheard than the so-called 14 bit mode. It would be nice if you could produce true 16 bit output by eg. interpreting each word as a single 16 bit sample. If the DAC can't do 16 bits then even 12 bits would be better than the 10 real bits of calibrated '14 bit' mode. Other possibilities include using 8 bits for applying volume to every sample, or an exponential mapping such as u-law.

When set to 115,200 the Amiga's baud rate clock is within 0.6%, which is fine. What the serial port really needs is a multi-byte receive buffer.
I agree on both points about the UART. UART is also very tolerant to clock drift, so 0.6% is fine, but the biggest show stopper to higher baud rates is the interrupt overhead for the 68000. A FIFO would be the biggest gain on UART if literally nothing else was done. Even a tiny 4-byte one.

I've been thinking about audio. Planned fixes
- three-state output now has 1.5 effective bits per cycle
- change to 13-bit accumulator to preserve sample quality
- 55kHz volume PWM is preserved for real "Amiga sound"
- pulse-density frequency is bumped from 3.5MHz to 7MHz
- LFSR added to sub-LSB for noise shaping and other fixes
- 56kHz mode without enabling Productivity Mode

There isn't a lot more we can do with Paula that will work with existing software. Anything beyond Paula is better to as something else entirely under AHI.
nonarkitten is offline  
Old 05 October 2022, 09:10   #240
Bruce Abbott
Registered User

Bruce Abbott's Avatar
 
Join Date: Mar 2018
Location: Hastings, New Zealand
Posts: 1,265
Quote:
Originally Posted by nonarkitten View Post
That was a great way to get data errors.
I have tried it and it worked fine. However I prefer to use high quality DD disks, which is why I recently bought 3 boxes of Fuji DD disks from the US via eBay. 30 disks should last me a long time.

Quote:
This is probably why it got a reputation for being "unreliable."
No. My experience with flaky HD disks was only on PC's (never needed to use them on the Amiga 'back in the day').

Quote:
NTSC is 15.75kHz. Three scanlines would be 47.25kHz.
PAL is 15.625kHz. Three scanlines would be 46.875kHz.
I wondered how they got those numbers, now I see the issue. Digital audio was recorded to videotape only during active scan lines, not during the blanking period. This gets the correct 44.1kHz, but the frame has to be buffered to get continuous playback.

Quote:
Paula's timing is based on 3.5MHz ticks though (3546895 Hz PAL, 3579545 Hz NTSC) and 22050 would be 162 on NTSC making 22,096 Hz and 161 on PAL for 20,030 Hz. The shift from 22050 is probably undetectable to most people.
Yep, close enough that it would be very hard to tell the difference (pitch change 0.2% NTSC, 0.1% PAL, much less than typical cassette tape player tolerances).

Quote:
I've been thinking about audio. Planned fixes...
'Sounds' good. I look forward to hearing a demonstration.
Bruce Abbott is offline  
 


Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)
 
Thread Tools

Similar Threads
Thread Thread Starter Forum Replies Last Post
Amiga 500 and Agnus cleaning without removing Agnus? turrican9 support.Hardware 16 26 January 2016 17:05
Universal Translator mritter0 request.Apps 2 14 June 2014 20:28
Universal Warrior Asle HOL data problems 4 10 September 2011 23:14
swap fat agnus with agnus extralife support.Hardware 12 23 July 2008 16:35

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +2. The time now is 00:25.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2022, vBulletin Solutions Inc.
Page generated in 0.10634 seconds with 14 queries