Caution: Non registered users only see threads and messages in the currently selected language, which is determined by their browser. Please create an account and log in to see all content by default. This is a limitation of the forum software.
Also users that are not logged in can not create new threads. This is a, unfortunately needed, counter measure against spam. Please create an account and log in to start new threads.
Switching the core to use a better audio DAC might help, too - the one it uses at the moment will be quite noisy in its current configuration.
I suggest to use at least 50MHz sample rate for the Delta-Sigma DAC, otherwise it'll sound weird. You probably have a 100MHz-ish clock domain for SD-Ram, so that may be a good one. The FPGA is definitely fast enough for Delta-Sigma at SD-Ram speed.
I suggest to use at least 50MHz sample rate for the Delta-Sigma DAC, otherwise it'll sound weird. You probably have a 100MHz-ish clock domain for SD-Ram, so that may be a good one. The FPGA is definitely fast enough for Delta-Sigma at SD-Ram speed.
The DAC currently runs on a 32MHz clock, but it's 2nd-order so it should be OK running slower than that. There's a tradeoff between running a sigma delta fast enough to perform well at low volume and running it so fast that imbalances between high and low pulses start to matter. I usually avoid the latter problem by using a hybrid approach - a sigma delta with a 5-bit rather than a 1-bit output, feeding a PWM. It performs measurably better on real hardware than any other DAC I've tested so far, even though it's not as good in simulation - but until recently I had absolutely no idea why! Now I believe the reason is that (unless it's saturated) the hybrid DAC produces a fixed number of rising and falling edges in any given time period, so any imbalance between them manifests as a DC offset rather than extra harmonics (for a 1st-order) or broad spectrum noise (2nd or higher order). (Here's a comparison of four DACs playing a ProTracker module at 1/64 the usual volume: https://www.youtube.com/watch?v=n3DxYie6AQo )
Hello Alastair,
after I was able to load hard disk file 0 very well from the HDD folder,
I just downloaded the new firmware from October 18, 2021 to my TC64V1.
The hard disk file is no longer loaded, although everything is displayed correctly
in the configuration (F12)... hmmm ... am I the only one with that error?
Have you changed anything in the meantime?
Of course, I also tried to re-create my STEHDD.cfg.
Cheers
SID-6581
P.S .: Have you been able to make progress with the sound problem?
The hard disk file is no longer loaded, although everything is displayed correctly
in the configuration (F12)... hmmm ... am I the only one with that error?
Have you changed anything in the meantime?
P.S .: Have you been able to make progress with the sound problem?
That's very strange - I tested it before release and it worked OK for me - and I've just tested it again, switching between configs which have different hard drive images in different directories. The are some minor framework changes from the C16 core and a build optimisation which shrinks the firmware a bit - but otherwise no changes which should affect hard disk images.
I'll give some thought to how best to debug this.
As for the sound issue, I've tinkered a little with some filtering - but I think the Chameleon's audio output already does enough that if I do more it's just going to sound muffled. Compared with a software emulator, mono mode is no more noisy than the emulator. Stereo mode isn't supposed to work with digitised samples - if you do the stereo mod on a real ST you'll get exactly the same kind of noise, so I don't think this is actually an error.
What might be an error is that the middle channel from the YM2149 is twice as loud as the other two - I haven't figured out yet whether that would be the case if you did the stereo mod on a real ST.
I haven't figured out yet whether that would be the case if you did the stereo mod on a real ST.
If you point me to a schematic, I could give an educated guess about the loudness relation.
That's very strange - I tested it before release and it worked OK for me - and I've just tested it again, switching between configs which have different hard drive images in different directories. The are some minor framework changes from the C16 core and a build optimisation which shrinks the firmware a bit - but otherwise no changes which should affect hard disk images.
I'll give some thought to how best to debug this.
Thanks for the sound info.
I apologize for my error message because it is incorrect. After copying the backup copy of my hardfile to my SD card, hardfile 0 is loaded correctly. My previous hard disk file was probably faulty. I should have checked that beforehand .... sorry.
If you point me to a schematic, I could give an educated guess about the loudness relation.
Thanks - see the ascii-art in the first post of this thread: https://www.atari-forum.com/viewtopic.php?t=1627
I *think* it'll put a 50/50 mix of channels 1 and 2 on one output, and a 50/50 mix of channel 2 and 3 on the other output - which results in channel 2 being over-represented? That's certainly consistent with the core's current stereo mode.
There's also another version linked later in the thread which has some pots for adjusting the channel mixing - I suspect they were added to address this same issue.
I apologize for my error message because it is incorrect. After copying the backup copy of my hardfile to my SD card, hardfile 0 is loaded correctly. My previous hard disk file was probably faulty. I should have checked that beforehand .... sorry.
No problem at all - your testing and bug reports are valuable and much appreciated, even if this one turned out to be a false alarm. 
I *think* it'll put a 50/50 mix of channels 1 and 2 on one output, and a 50/50 mix of channel 2 and 3 on the other output - which results in channel 2 being over-represented? That's certainly consistent with the core's current stereo mode.
That would only be the case if the three output pins are a perfect voltage source, which they aren't. They are certainly not perfect current sources either, but their behaviour is much more like a current source than a voltage source. So the base load is given with the 1k resistor to GND, and the 10k resistors will really split the available current over the two channels. I'd use:
Left=(66* Channel A + 33*Channel B)/100
Right=(66* Channel C + 33* Channel B)/100
Left=(66* Channel A + 33*Channel B)/100
Right=(66* Channel C + 33* Channel B)/100
Well that certainly makes more sense than the current situation. Of course, nothing's that simple in practice, is it?
In the stock configuration the three outputs are directly connected, and thus load each other. They also have different characteristics depending on whether they're pulling the output up or down - so the core currently employs a 3D lookup table based on measurements of a real machine when mixing the channels.
It would be easy enough, I guess, to halve the level of channel B before mixing - but I'm sure the stereo mod would invalidate those measurements anyway, so in stereo mode maybe it makes more sense to bypass the lookup and use a simple mathematical mixing?
I meant to ask, by the way, what's the approximate low-pass cutoff frequency of the Chameleon's audio outputs?
In the stock configuration the three outputs are directly connected, and thus load each other.
I believe you can safely ignore the "loading each other" part, as the load to GND is an order of magnitude higher than the series resistor that does the mixing. So the "practise" part is that you only look at the realy-high-load, and that's the 1k resistor to GND.
In the stock configuration the three outputs are directly connected, and thus load each other. They also have different characteristics depending on whether they're pulling the output up or down - so the core currently employs a 3D lookup table based on measurements of a real machine when mixing the channels.
OK, if the pins are really tied together without individual load resistors, you will need such a 3D lookup table to make things simple (if you can call that simple - even if you're only making that 6 bits deep, you'll end up with a 256k lookup table, and 8 bits would make it a whopping 16MBytes). However, I believe the individual load resistors and the "only about 20k resistor" between the individual channels (mind there's two in the path from one channel to the other) make the mixing much simpler:
so in stereo mode maybe it makes more sense to bypass the lookup and use a simple mathematical mixing?
Yes. As a first step, I'd just ignore the fact that there is a 30k Ohms connection between left and right channel. If you want to go fancy, you might as well calculate that, as it's going to be the first thing that will stand out when comparing to the original. Remember that the human ear is not linear, but logarithmic, so the seemingly-high resistance will result in a fairly small audible difference. The "third channel" part needs to be calculated with a few iterations of Kichhoff's law, which I am too lazy to do right now. The influence of the 1k pull-down resistors will be huge, so a rough guess is that only a few percent of the not-directly-mixed channel arrives on the opposite side. This might be a nice exercise for some spice-based emulator.
I meant to ask, by the way, what's the approximate low-pass cutoff frequency of the Chameleon's audio outputs?
Since it's meant for sigma-delta, it's a simple RC filter with 2k2 series resistor and 4.7nF capacitor to GND. This puts the 63%-level to roughly 100kHz. I wouldn't calculate with any more significant digits, as component stray is probably larger than that. Not perfect, as it will still produce measurable phase distortion in audible frequencies, but it'll be forgiving if you need to lower your delta-sigma frequency.
Without wishing to disturb your very interesting discussion, I would like to point out a possible mistake in the Atari ST core.
Please refer to the attached screenshot that the, in 2021 published,
"Lotus Esprit Turbo Challenge Enhanced for Atari STE".
http://www.indieretronews.com/…-challenge-ste-retro.html
has image disturbances for some time in the form of crossbars appearing again and again.
I tried different TOS versions and also different memory sizes without the error being fixed.
With the first versions of the Atari ST core, I didn't had this bug. It didn't matter which TOS version or memory size was used.
Can you reproduce this bug?
Cheers
SID-6581
With the first versions of the Atari ST core, I didn't had this bug. It didn't matter which TOS version or memory size was used.
Can you reproduce this bug?
Thanks, I haven't tested the STE Lotus remake yet - or the Metal Slug stage 1 - I want to try them both out. I can't think of any core changes that could cause this problem to appear now if it wasn't there before, but I'll see if I can reproduce it.
(Note that TOS won't notice that the amount of memory has changed unless you do a hard reset.)
OK, if the pins are really tied together without individual load resistors, you will need such a 3D lookup table to make things simple (if you can call that simple - even if you're only making that 6 bits deep, you'll end up with a 256k lookup table, and 8 bits would make it a whopping 16MBytes). However, I believe the individual load resistors and the "only about 20k resistor" between the individual channels (mind there's two in the path from one channel to the other) make the mixing much simpler:
Indeed - an unmodified machine does indeed tie the three outputs together, feeding into a single load resistor, hence the lookup table. The channels are 5-bit, but the core's LUT is currently 4x4x4 bits, so it's actually discarding one bit from each channel.
On real hardware the Stereo modification adds the individual load resistors and the 10k mixing resistors, which as you say is actually a simpler arrangement to model.
Since it's meant for sigma-delta, it's a simple RC filter with 2k2 series resistor and 4.7nF capacitor to GND. This puts the 63%-level to roughly 100kHz. I wouldn't calculate with any more significant digits, as component stray is probably larger than that. Not perfect, as it will still produce measurable phase distortion in audible frequencies, but it'll be forgiving if you need to lower your delta-sigma frequency.
Thanks - the reason I was asking is that software emulators use a split filter with two different cutoff frequencies, to model the YM2149's output (different characteristics depending on whether the output is pulling high or low). This would actually be relatively easy to add to the core, but I wanted to be sure I wouldn't need to take any built-in filtering into account. (I also need to figure out how much my PC's line-in is affecting the sound from the Chameleon, before attempting to compare it with a software emulator.)
Thanks, I haven't tested the STE Lotus remake yet - or the Metal Slug stage 1 - I want to try them both out. I can't think of any core changes that could cause this problem to appear now if it wasn't there before, but I'll see if I can reproduce it.
(Note that TOS won't notice that the amount of memory has changed unless you do a hard reset.)
So now Lotus is running flawlessly again.
The solution was actually that I had to do a hard reset after loading my STEcolor.cfg.
So far I thought that loading a config file would do the hard reset itself.
So far it has only been possible to change a TOS version by changing the TOS.IMG file. While TOS 2.06 must be used for my HDD file, TOS 1.62 is best for Lotus Enhanced Version, for example. Changing the TOS versions manually is therefore very cumbersome. Is it possible to change the TOS version on the Turbo Chameleon 64 just as easily via the menu as on the MISTer?
I'll take another look at this soon, and see if I can see what's going on.
I have also tinkered a bit with the audio. I was easy to arrange for the middle channel to be the same volume as the other two - but now I want to add a volume boost to all three channels, since stereo mode is now quieter than the lookup-table-based mono mode! (Note that sample playback will still be noisy in stereo mode - that's correct behaviour and matches real hardware.)
Nice that you have a look what you can do with the menu. I'm also happy that you made progress with the sound. Thank you for your efforts Alastair.
Hello,
The C64 keyboard is very buggy in the OSD. It's impossible to use it.
I guess we can safely ignore that post.
Hello,
The C64 keyboard is very buggy in the OSD. It's impossible to use it.
I can confirm. Everytime I hit enter and go into a submenu it just jumps back to the mainmenu automatically. Joystick works fine though
That sounds more like a proper bug report
