Posts by pwsoft

Ah yes true, the data cable is the other one, duh (hint to self don't reply when sleepy ;-).

Yes you can use Chaco in cartridge mode. The cable loom has a protection diode that prevents C64 power going into the PC. Make the USB connection after you turn the C64 on for best chance of success. Disconnected the USB when you are done to prevent the PC powering the Chameleon when you switch off the C64. Yes, SDcard needs to be removed before using Chaco also in cartridge mode.

If you suspect the CIA adapter board to be the source of the trouble, you could as a test/diagnosis trying to disconnected it. The AGA mk3 should work correctly without the CIA board attached. You only lose the live-edit mode and some minor audio functions, but the picture output will be unaffected. If that fixes the issue it will confirm your suspicion that the CIA is involved.

Quote from fnord

* can someone explain to me why it would make sense to add a pullup to only one of the address lines?

If you have a burst access or in case of the Amiga a dual-cas access, multiple sequential accesses happen within the same machine cycle. For these accesses the A0 changes twice as fast compared to the other address lines. Maybe Commodore engineers decided it could do with a little help because either it is too slow at double the frequency or it has some under/overshoot that is suppressed by the pull-up. My guess is on the "get it faster" reason as often digital pins can pull to ground more strongly compared to driving high. And so a pull-up helps with shortening the rise time (A0 need to rise for the second half of a dual-cas access).

Yeah that eliminates the whole audio sample-rate discussion, the mk2 outputs DVI. So yes should not be a problem to capture that.

As you mentioned HDMI capturing, I do assume we are talking about capturing the output of an indivision AGA mk3 product specifically here. Then yes indeed that can output audio, but this is an option you can enable or disable. It doesn't cause video capture issues as such (AFAIK), but some people experienced problems when trying to capture both the audio and video directly from the digital stream. And changing the output sample rate did fix it. The recommended setting of 96 Khz is widely supported and offers the best quality, so that has been added as a option in recent firmware versions, but for some reason in some rare cases 44.1 or 48 Khz works better.

Of course there is always the option to capture the analog audio directly from the Amiga with an separate audio interface on the PC, if all else fails.

No not so easy as the VIC 20 core doesn't have a menu system like the C64 main core has. So most of the settings are set static during the compilation of the core and can't be changed by software.

Quote from robinsonb5

You have to do this every session because Quartus won't save the chain file, due to it not recognising the other device on the chain.

Actually... you can create a custom device definition for the CPLD in the Quartus programmer software and then you can save it.

Right click on the CPLD icon, select "Change Device", then add an entry for it in the "User Defined" list by pressing new and filling in a few details.

Any Hires mode is limited to maximum 16 colors on the OCS/ECS chipset. For more colors you need to have lowres, which will limit the horizontal size to approx 400 pixels wide. There is superhires in ECS chipset, doubling the horizontal resolution, but that really cuts down on the colors (both the number of colors and the color depth), IIRC the maximum number of colors for superhires screens is 4 on ECS.

So the highGFX 800x600 by 16 colors is a pretty good result for a Amiga 500, sitting in the middle of its capabilities giving 16 colors with resolutions above standard PAL.

Yeah I understand it from the "preservation" point of view. And I guess the system itself isn't that much work as it is mostly connecting blocks I already have on my harddrive. I think the biggest amount of new stuff would be to emulate the 7 seg displays so they are shown on the both the VGA and C64 screen (in cartridge mode).

However silversurfer as mass storage would mean a secondary computer of some sort, which is a bit meh.. To make it useful for more users would be the option to save to sdcard. And that basically the hurdle for a lot of those niche ports. I ran into the same issues with the vic20 and vcs2600 that there isn't a equivalent for the menu system like the one that has been developed for the main core. Although for vic20 you could connect a external drive I guess, but an emulated one would be better and make the core so much more useful. So that basically stops me from spending a evening or two to hack a kim together from random building blocks on my harddrive. Like ok, what to do with once build, it if I can't load any software.... Actually is there any software for the kim-1 available? Or was it mostly used to make your own stuff?

Audio jack is output only. So you could "SAVE" your program, but loading it back in might be slightly problematic.

Ignoring that problem for a bit the 6532 and 6502 are also in my 2600 core. So yes certainly possible to get that implemented without too much trouble, but personally don't see the really the point though, with so many other 6502 based cores already available.

Yes, once we find a way to implement this, without it breaking any of the standard drive ROM routines we will of course enable the feature. Can't give a time-frame, VIC-II and CIA emulation bugs have priority.

Some parts of the G64 emulation were turned off (from beta9i onwards), as it broke the normal floppy stuff. It wouldn't surprise me if you use a a beta-9g or beta-9h release, a few more of those G64 images will work. It is described in the change-log as "weak-bit" emulation, but pretty sure bit-wise sync interpretation is also part of that same change. And like I said, currently disabled.

Quote from iljitsch

So looks like the MK3 HDMI audio output can use a boost.

Just a quick note, that the new config tool IndivisionAGAmk3-1.9 is available on our wiki. And it includes the firmware update with improved volume levels.

Is that really TOD, or just a CIA timer interrupt (which is also not affected by CPU acceleration)? Or maybe VIC-II vertical interrupt if PAL/NTSC does make a difference? Changing TOD frequency will not help in that case.

And no there is no way to change the TOD on Chameleon, it is always linked to the video standard in use. Or in cartridge mode it uses whatever the C64 gives.

Quote from iljitsch

So looks like the MK3 HDMI audio output can use a boost.

That is correct the amplitude IS a bit low.

Quote from iljitsch

However, I think it would be good to adjust the HDMI volume to better match other sources. For this you probably don't even need integer math, just shifting everything a few bits to the left should probably do it. 1 bit = 3 dB, right? So that would be shifting by 4 or 5 bits.

I'm pretty sure on that scale 1 bit (doubling of volume) is 6 dB, I admit it has been a while I learned that stuff, so could be totally wrong.

I've been observing what is send to the HDMI encoder to see if 4 or 5 bits could be correct (and no it isn't that much). So on the retro side of things the Amiga has a volume range of 0 to 64, which is exactly 1 value too much to nicely fit into 6 bits and thus requires 7 bits, but without using the full range at all (which is 0..127). One way to get extra volume is to map 64 back to 63 and shift everything by 1 bit to the left, but I don't really want to do that as that isn't fully accurate. So have been experimenting with scaling the volume before the mixer by 1.75, which is still relative easy to do in hardware (1 + 1/2 + 1/4) and gives most of the benefit without needing to truncate the volume register values. Now I occasionally see bit 14 toggling, so any further left shifting would cause clipping. At the moment it is impossible for me to debug what happens after I give the data to the video encoder chip, it could something with the amplitude, dunno. This volume scaling fix will be included in the next firmware release.

And just for fun, a little technical screenshot what Amiga audio "looks" like for me during debugging.

And I guess is what happens when you take the red pill (ref The Matrix 1999)

Quote from Drewlio77

I have a quick question; where does the Indivision AGA MK III get the audio from to output over HDMI? Looking at the schematics of the A1200, I don't see any Audio inputs from the Paula chip. Is it being taken from the bus somehow?

If you look at those same schematics you see many of the custom chips sharing the same RGA and data lines. This allows us to capture data meant for the Paula while not physically sitting on the Paula chip. The rest is pixie dust, magic rituals and creative guessing and audio comes out

Just a random guess. The computer you get USB power from is connected to the same monitor as the Chameleon. And the movement of the breakout cable is causing problems with the ground connection. So in that case the ground has found a way through the VGA cable to the monitor and through a other output cable back to the computer.

Quote from Jens

Why this was only cured for you with going back to an old, then to a newer version, I can't explain, but maybe Peter can - he wrote the updater.

Nope no clue. The sequence of operations is the same for all firmware versions, it doesn't check versions before programming. Supporting the scenario where you want to overwrite the same version for some reason. And it does a full erase before writing the blocks, so it should NOT matter what was already in the flash.

Quote from air_ii

just wondering why neither 44.1 nor 48kHz seem to work.

Yeah no idea about that one either. Some devices support all of them and other monitors/capture cards it is one of them only. So that is why the option is there, initially we only had 48 Khz, but that didn't work for all devices. Lucky for you 96 Khz is actually the one providing the best audio quality.