Writes to BPLxPTL and BPLxPTH

[dirkwhoffmann]

With bplpt1 and bplpt2, I have added two new test cases to the vAmigaTS repo and need the help of somebody with a real Amiga.

https://github.com/dirkwhoffmann/vAmigaTS/tree/master/Denise/BPLPTR

Both tests utilize the Copper to modify BPLxPTL at varying trigger coordinates in the middle of a raster line. bplpt1 modifies BPL1PTL and bblpt2 modifies BPL2PTL.

My reference pictures (recorded with SAE) look as follows:

Since vAmiga has improved quite a bit over the last weeks, it is now capable of reproducing those images 😎:

Here comes the tricky part (I quote from the SAE / UAE source code):

/* chipset feature: 
 * BPLxPTL write and next cycle doing DMA fetch using same pointer register ->
 * next DMA cycle uses old value.
 * (Multiscroll / Cult)
 *
 * If following cycle is not BPL DMA: written value is lost
 *
 * last fetch block does not have this side-effect, probably due to modulo adds.
 * Also it seems only plane 0 fetches have this feature (because of above reason!)
 * (MoreNewStuffy / PlasmaForce)
 */
 /* only detect copper accesses to prevent too fast CPU mode glitches */

        In SAE, some conditions are disabled, though:

 /*#if 0
 if (num == 0 && plf_state >= plf_passed_stop) {
 // modulo adds use old value! Argh! (This is wrong and disabled)

In vAmiga, I implemented it that way:

bool
Agnus::skipBPLxPT(int x, uint16_t value)
{
/* If a new value is written into BPLxPTL or BPLxPTH, this usually happens
 * as described in the left scenario:
 *
 * 88888888888888889999999999999999      88888888888888889999999999999999
 * 0123456789ABCDEF0123456789ABCDEF      0123456789ABCDEF0123456789ABCDEF
 * .4.2.351.4.2.351.4.2.351.4.2.351      .4.2.351.4.2.351.4.2.351.4.2.351
 *     ^ ^                                     ^ ^
 *     | |                                     | |
 *     | Change takes effect here              | New value is lost
 *     Write to BPLxPT                         Write to BPL1PT
 *
 * The right scenario shows that the new value can get lost under certain
 * circumstances. The following must hold:
 *
 *     (1) There is a Lx or Hx event once cycle after the BPL1PT write.
 *     (2) There is no DMA going on when the write would happen.
 *
 * According to the UAE documentation, the following conditions must
 * probably hold, too. They are not checked in the SAE source code though.
 * TODO: Check test cases bplpt1 and bplpt2 on a real Amiga.
 *
 *     (3) The write does not happen in the last fetch unit.
 *     (4) The write is to BPL0PTL or BPL0PTH.
 */

if (isBplxEvent(dmaEvent[pos.h + 1], x)) {     // (1)
    if (dmaEvent[pos.h + 2] == EVENT_NONE) {   // (2)
        if (true) { // }(!inLastFetchUnit(pos.h + 2)) { // (3)
            debug(BPL_DEBUG, "Value is lost\n");
            return true;
        }
    }
}

return false;

}

As you can see, conditions (3) and (4) are neither implemented in SAE nor vAmiga (otherwise, I can’t reproduce the reference picture in vAmiga). It would be interesting to see how the test case looks like on a real machine.

@mithrendal, if you manage to get a serial cable, it would be great if you run the test case on your A1000 (amazing that is still works!).

There is one caveat though: I did hard cod the values that are written into BPLxPTL which might not work if the real Amiga uses a different hardware configuration (memory locations can change then). I recorded the reference images with the following SAE settings: Amiga 500, OCS, 512 KB Chip, 0 KB Slow, 0 KB Fast. If the image looks completely different on a real Amiga, I need to modify my test case.

I’ve CC’ed @naTmeg to this post. As a real Amiga expert and author of my so important reference emulator (👍), he might know more details about the exact timing of the BPLxPT registers.

[mithrendal]

Yesterday the thing came. One day earlier as the delivery forecast. But I bought a cheap chinese adapter USB ->db 9 -> db25 . Therefore ;-) I had some trouble to set this puppy up in VirtualBox on my Mac. It was not recognized by XP in the windows device manager. Installing the WinXP Driver did not changed anything. In the end I managed it. But only in a way that I wanted to avoid. I had to install the mac driver and via virtualBox port settings I forwarded this hostadapter to the guest system. And also I have to plug the cable into the USB port otherwise the guest does not startup (because it complained that it otherwise cannot map it). But now XP happily sees the mapped serial connection, in the XP device manager I can alter connection parameters and Amiga Explorer is also happy that it now has a COM1. In the evening I want to connect the other end of the cable to the Amiga1000. So stay tuned for amazing pictures...

I will write your bplpt1.adf and bplpt2.adf with the help of AmigaExplorer to a real disk and insert it into an Amiga 1000 from 1986 with 512KB Chip.

[dirkwhoffmann]

Awesome 🤤

[mithrendal]

transfering bplpt1 now... hold on 10% 20% ... and be prepared for your test on a real hardware

[mithrendal]

[mithrendal]

some impressions... same test bplpt1

[mithrendal]

Bplpt2

[mithrendal]

my spotted differences so far 1.) Line on real hardware/composite output is dotted not solid as the emulation. What you have to know is, that this is not the clean rgb cable output. The monitors/tvs nowadays can not sync to the RGB signal of the Amiga. So I took the composite output from the Amiga (the yellow chinch cable) and connected that to the monitor. I am sorry that it produces not so crisp/clean images.
2.) in real hardware via composite out there are no red lines on the right side of both tests.

[dirkwhoffmann]

Hi Mithrendal,

awesome to see the “color bar art” on a real A1000. Great work!!!

So it seems like we have solved the BPLPTR mystery. The SAE /UAE images match the real Amiga image to 100% (or 99%, I just saw your updated post which I need to read in more detail). This means that the current implementation is most likely correct and the SAE / UAE code documentation outdated. I.e., conditions

(3) The write does not happen in the last fetch unit.
(4) The write is to BPL0PTL or BPL0PTH.

seem to be wrong and should be removed (as it was already done in the SAE code).

BTW, a surprising analogy came into my mind this morning.

Im Biology they use pictures such as

to derive sequences like

GTACCTACTTATACCGCGGTA.

We use pictures like

to derive sequences like

88888888888888889999999999999999      
0123456789ABCDEF0123456789ABCDEF      
.4.2.351.4.2.351.4.2.351.4.2.351

What we are doing here is digital DNA analysis. So cool 😎.

Even the name is similar: In Biology they do DNA sequencing. We are doing DMA sequencing 😂.

Carrying on this thought means that developing an emulator with color bar pictures is like being Frankenstein on the genetic level. So the question still is: Will it be evil when it fully awakes 😅.

[dirkwhoffmann]

1.) Line on real hardware/composite output is dotted not solid as the emulation.

I think this really is an artefact of the analog video output. BTW, the images are much crisper than I expected and definitely very very useful to verify the emulator results. I am going to upload them to the vAmigaTS repo if you don't mind.

2.) in real hardware via composite out there are no red lines on the right side of both tests.

I think the pixels are just not visible on a real monitor. Hardware-wise, these pixels already belong to the next DMA line, but the video logic displays them just before the HBLANK area. One might be able to see them if the monitor picture is shifted as far left as possible, but it might also be that they can't be seen on a real monitor at all (the area might already be outside the phosphorised area of the electron tube).

[mithrendal]

The analogy is interesting . ;-) That could obviously mean that some of this Amiga D(N/M)A gene sequences/patterns might be still in modern computers ? Another question is whether we are analysing here a line or a line of species which got already extinct in the wild (the line of mammuth which got stuck) OR in contrast an common ancestor of the evolved modern computers/smartphones we use now (the evolution line of modern elephants)...

Maybe three lines ? IBM AT => windows mobile smart phone AtariST => android smart phone Amiga => iPhone ?

no wait ... maybe I am wrong, I bet the Atari and Amiga lines are extinct in the wild, I have yet another theory: Acorn Archimedes => every smartphone because of the ARM chip... IBM-AT => Mac and PCs because of the IntelChip

Is the Amiga blitter the ancestor of modern GPUs?

Feel free to use the testcase images as you like. The other "real hardware test candidates" are coming in the next days...

[naTmeg]

Thanks for the flowers, but I'm not that of an Amiga-expert, as you might think. Most code after 0.5 is just ported from WinUAE, because I ran out of time to do the research for my own. Can't really help you with this.

Great progress btw, I'm watching this! When you follow this path of accuracy and clean code, vAmiga could become the next reference implementation for emulating the Amiga custom-chips, because *AE is a little overloaded at that part.

[dirkwhoffmann]

Hi Rupert,

but I'm not that of an Amiga-expert, as you might think.

That's OK, we are all humans. Six month ago, I didn't know anything about how the Copper or Blitter works or what an DMA cycle allocation table is. I startet vAmiga with VirtualC64 in hand and a copy of the HRM and "Amiga Intern" by Data Becker 😂.

*AE is a little overloaded

UAE shows the typical symptoms of ageing software. Im many cases, ageing software is brilliant function-wise (which *AE really is), because a lot of smart people spent a lot of time fixing bugs and adding new features. At the same time, ageing software is often miserable code-wise, because too less refactoring took place. It usually starts like this: The original programmer introduces some variable x. To add a new feature, programmer 2 (or the original programmer himself) adds x2, because x doesn't fit 100% any more. And what has happened once will happen twice and so forth. If you watch such a project over the years (which I did in industry back then), you can be almost certain that other variables will join, such as tmp_x,tmp_x2, old_x, x_real, etc. etc.. UAE is a typical example for that. There are so many different variables, e.g, for hpos or the current CPU cycle that I usually get lost after minutes when I look into the code. (OK, I am getting better over time. I now know that I have to look at hpos_old most of the time when I do my Copper experiments 😎).

Nevertheless I have become a big fan of SAE! The possibility to simply start an Amiga in a browser is really amazing. If you had asked me at the beginning of the SAE project, if a browser is fast enough to emulate such a machine, I would have replied: In no way. Don't try this project! I am still surprised how fast the browser can process the SAE JavaScript code. I also think that you can jump safely to version number 1.0. I am running SAE frequently these days and it does a great job. It really doesn't feel like a 0.x software.

[naTmeg]

You brought it to the point.

I also used the RFM at the beginning. First parts was copper-lists only, with no CPU, just to figure out html5, canvas, JS and to have some fun. I thought of a web-tool, where users could build copper-lists for demos or so. I started with simple colors and added more and more custom-registers. First simple blitter code followed. As the requirement for a CPU became obligate, I started to implement a core based one the 68000 user-manual. It's actually the only big part, which isn't ported :) I remember when the 1.x boot-hand showed up for the first time in my browser, distorted by blitter-errors and out of shape. Fun times :)

I'm not very happy with the separation of emulator-code and HTML-code. Some functions in e.g. video.js calling Browser-code in a way I don't like. There should be more abstraction. Also IPF- and zLib-support would be nice. I've started IPF-support once, but haven't finished it yet. That's why it's still 0.x :)

I'm happy to hear that SAE performs well on your machine. Only had my brothers laptop and his phone for testing on MAC back then and I don't get much feedback from that platform.

[dirkwhoffmann]

Original images are now part of the vAmigaTS repo.