vAmigaWeb

[mithrendal]

cool stuff 😀

when putting it into https://vAmigaWeb.github.io

I see during animation every second frame or so that it changes from this

to this

is this effect

normal and intended ?

BTW: I activated the activity monitor with this symbol

and indeed no write access. I see only bitplane DMA

[nicodex]

Before blaming vAmiga I'll try to grab the screen with a RGBtoHDMI on real hardware, as soon as my spare time allows. My interlaced handling just might be wrong...

At least I noticed no problems on real hardware (A500 without DRAM, CIAs, and Paula). I added a photo from a live hardware demo on a retro meeting last weekend, see https://github.com/nicodex/amiga-ocs-cpubltro/commit/f2a00badf2b02e38b870ec8d37bc436e0aeb7e6c

[mithrendal]

yeah, maybe it looks so because vAmigaWeb uses no shader to emulate CRT blurring

[mithrendal]

hmm its not the shader CRT thing, I think.

In @dirkwhoffmann 's original vAmiga for Mac which supports various kinds of fancy settings to emulate a CRT monitor

I played with the settings.

Above settings makes it look like this below.

Not always but every n_th frame... it looks like that

I suppose the shadow effect for the red squares on the ball should be always like this maybe ?

aboves picture which looks correct to me, shows up every m_th frame.

The remaining ROM space allows us to include 11/256K animation frames.

where 0< m ... n < 11

or in words some of the frames render like a beautiful amiga ball 😀 others show some artefacts...

[nicodex]

The 256K ROM has 11 images, the 512K ROM has 22 images. No RAM, no fancy stuff, just fullscreen image data. For the live demo I hacked the animation logic together with the assumtion that a PAL frame starts with a long field, followed by a short field. The negated LOF flag is or-ed into the field counter, which is shifted right as image index. This should result in the same image for the first/long and the second/short field. However, this is interlaced - after the long field you see half of two images. So this 'problem' is expected. As soon as I have the time, I will have a look at it. Maybe the effect can be avoided... but this is a hardware related demo in the first place :-)

[mithrendal]

However, this is interlaced - after the long field you see half of two images. So this 'problem' is expected.

Ah I see it now too 🤓. The "artefacts" are because of interlace mode... which mixes half pictures together. During animation we see then on every second frame one half picture which is still old ...

Impressive. The Amiga needs less ram for this demo (0KB) then the VCS2600 with its small 128 Bytes of RAM. Really cool 😎.

[nicodex]

A PAL Amiga has a 28.37516 MHz crystal oscillator. Divide this by 8 to get the Amiga CCK of 3,546895 MHz (Amiga CCK * 5 / 4 = 4.43361875 MHz PAL color subcarrier). A PAL frame (two fields) has 625 lines. Every line has 227 Amiga CCKs. Depending on the LOF bit the Amiga counts/generates 313 or 312 lines. Enabling the LACE bit in the chipset just toggles the LOF bit. Therefore we have three different field frequencies on PAL Amigas:

• 2 / (227 (313 + 312) 3.546895 MHz) = 50.000282 Hz (interlaced)
• 2 / (227 (312 + 312) 3.546895 MHz) = 50.080411 Hz (non-laced short)
• 2 / (227 (313 + 313) 3.546895 MHz) = 49.920409 Hz (non-laced long) (nice to know: the AmigaOS explicitly sets the LOF bit for non-laced modes)

So the interlaced mode is closer to the PAL spec (that's the main reason why I'm using it).

However, there is no such thing as a non-laced/progressive mode for the 15 kHz Amiga display modes. We always have to generate/fill the color data for every odd and even field. In theory it does not matter when the animation is advanced. Switching the image every field would be fine - but the animation would be really fast. So I decided to display a single image for two fields. It even does not matter if the next image starts in the even or the odd field, only every other display line will be updated. It makes a difference for display devices that convert from 50i into 25p - only for them it is important that the first and the second field contain the same image.

If all my assumptions are correct (and LOF bit is set for the first PAL field), this issue will be a wontfix :-)

[mithrendal]

Yes its not an issue 😅. Lets close. Brilliant. Thanks for in depth explanation.

[dirkwhoffmann]

I've added the fingerprints of the two ROMs (the 512 KB and the 256 KB versions) to vAmiga's ROM database so they can be installed simply via drag and drop in the next release:

Please let me know if the Roms should be displayed with a different text in the ROM config panel.

Very cool demo, btw. Based on what the activity monitors tell us, the machine looks dead but apparently, it is still alive:

[nicodex]

I've added the fingerprints of the two ROMs

Many thanks for making it more accessible :)

Please let me know if the Roms should be displayed with a different text in the ROM config panel.

I have no preferences. The name 'cpubltro' is somewhat unwieldy, but that's how the project started :)

[nicodex]

PAL field/line numbering is odd (pun intended). Reopened until I have a better understanding of the Amiga interlaced mode versus PAL signals. Recent discussion on Discord indicates that I'm wrong about the PAL field order.

[dirkwhoffmann]

Recent discussion on Discord indicates that I'm wrong about the PAL field order.

Is the PAL field order really relevant? At some point, you need to switch to a texture showing the ball at a different position, and as your demo runs in interlace mode, the other half of the image will still show the ball where it was before. Thus, if I am not missing something fundamental, the stripes should be unavoidable, shouldn't they?

[nicodex]

Is the PAL field order really relevant?

Not really, except for my innermost need to understand how it works. I'm still quite new to the Amiga hardware. Back in the days I did not care how a CRT works, but now I'm interested in breaking down how the Agnus and the Denise work together to generate the signals. So I'll hack some code together and see how it looks on my ancient Amiga 1081 monitor, an old TV, and a modern TFT - just to actually see the differences, if there are any :)