P96 3.0.0 (and later) news and support

[Thomas Richter]

Please write him an email, he may be snowed under by work. Happens at time.

[mfilos]

Originally Posted by Thomas Richter

Please write him an email, he may be snowed under by work. Happens at time.

Ok I just did and here's hoping...

[mfilos]

Ok just got a reply from Jens with a beta version of rtg.library 43.524 (18/04/2023).

I tested it under WinUAE (as I'm @ work atm) and seems to correct BOTH problemsL
1. GuiGfx.library issues with iGame) and
2. Error with IconEditor application (by Paul E. Bloedel written on Hollywood)
Edit: This version also fixes a problem with scrolling playlist on HippoPlayer (due to ClearEOL function) - http://eab.abime.net/showthread.php?...78#post1609178

Will try them once I get home under my A600 (V2-600) and my V4SA and will report back.
Edit: I got home and tried and it works just fine as well \o/

Thanks again ThoR

[my_pc_is_amiga]

I'm cross-posting here -- this is with AmigaOS3.2.2 and P96 3.3.3

https://forum.icomp.de/index.php?thr...-in-multiview/

With a P96 workbench screen, please open "DoggieBackground.lace" picture in Multiview and then use Multiview's menu item to open it up in a separate screen. I get a MuForce hit "doglace.txt" and graphic corruption. The picture file can be download in the IComp forums.


I'm not 100% certain if coming from P96 but seems like it could be since if I do the same from a workbench screen that is set to a native NTSC screen mode there is no issue.

Also, if a P96 Workbench screen is 32 colors, then when picture is loaded on its own screen, then no issue. If Workbench screen is 256 , then see the issue. I haven't tried other color modes.


The best way to reproduce is to make sure a P96 driver is loaded in monitor drivers and boot into a 256 color wb screen and then load picture in multiview and switch full screen mode.

[Thomas Richter]

I cannot reproduce this here, but this is not the ilbm.datatype and picture.datatype from 3.2, but those from 3.1.4. If you have a 3.1.4 available, please test with those versions. Thank you.

[my_pc_is_amiga]

Thanks Thomas. I tried ilbm.datatype 45.3 and picture.datatype 47.19 and this is working. It opens up native Amiga screen and I don't see the crash anymore.

If I go to the 3.1.4 version of both picture.datatype 46.13 and ilbm.datatype 45.3 then the behavior is different. It uses P96 screen instead of native amiga screen. Also, in this case I did not see crash.

So something to do with 47.6 ilbm.datatype I suppose or interaction with P96?

[Thomas Richter]

This means it is time to report a bug to the Os team, but not to P96.

[Thomas Richter]

A little bit of preview what is coming up next (hopefully) in P96, and that is a driver (or the best approximation of it) of the rather "unique" A2410 graphics card. It is the only graphics card offered by CBM directly, and its primary purpose was in the AMIX system, a unix clone on Amiga systems. The technical capabilities of this card are not exactly stunning: 800x600 or 1024x768 in 256 colors, no high-color, no true-color.

What makes this card interesting (or, more precisely, challenging) is its interface. The A2410 is based on the TI TMS34010 graphics processor, a rather exotic and special design, and a less unique, but still interesting RAM-DAC, the Bt548. The RAM-DAC is the chip that takes the data stream (this time directly from the video RAM) and converts it to analog video.

The easy part: The RAM-DAC is special in the sense that it offers an overlay plane. Usually, these chips just convert chunky or direct-color data to an analog signal, some offer an additional hardware sprite that is then used as a mouse pointer, but this chip has instead a "mouse plane", that is, a "sprite" that is technically the same size as the video mode but can be defined independently. Thus, if the mouse pointer is to be moved, it has to be erased at its old position, and redrawn at the new position as the overlay does not have a position, but exceeds over the entire frame.

The TMS34010 is now a very special beast. It is a direct descendent of the TMS9929 which already did its duty (not to say "damage") in the TI 99/4(A) home computer series. "Damage" because the TI 99/4A had a quite powerful 16 bit CPU, but only 256 bytes (yes, bytes, not kbytes) of RAM. Everything else was the frame buffer of the VDP, the TMS9929 processor. Unfortunately, its video RAM is not directly addressable by the CPU. If you want to read a byte (or a word), you write the address of the byte or word into a register of the VDP, and on another port you get the data you wanted to read, or put the data you want to write. Thus, you cannot put a program into the VDP RAM and execute it from there.

What TI did back then for the TI 99/4A was to invent an interpretive language (TI GPL "graphics programming language", not to be confused with the open source license) for programs in the VDP memory such that the CPU loaded the p-codes from the graphics memory byte by byte, and interpreted it. Needless to say, this slowed down the nice 16bit CPU down to a crawl, and the TI 99/4A was not exactly a market success.

Because that design worked "so nicely", TI tried again and build an entire architecture of graphics processors on top, the "TIGA" system (not to be confused with the preditor cat, it is more a hippo as you will see), short for "TI graphics". They put everything in they considered useful at that time:

A very fast (50Mhz) DSP-like microprocessor with bit-addressing (every bit has its own address!) and powerful assembler instructions, 32 32bit CPU registers, blitter instructions for area fill, blitting with what we would call "minterms", including addition and subtraction, line drawing instructions, a raster interrupt to change graphics registers "on the fly", as for example to reload the address counter to implement screen-dragging or have some copper-like features... so everything you could wish for.

... and TI, in their infinite wisdom, gave this powerful processor (the TMS34010) a host interface similar to the TMS9929, which (as in the TI 99/4A) ruins the entire design. The frame buffer is not directly addressable by the CPU, but the only thing the 68k ever sees from the A2410 card are 4 16 bit registers of the TMS, and every data that goes onto the card has to go through this 4-word port. One address port where the bit-address(!) you want to modify has to go, and 1 one-word port for the data, and one control word port. Jikes! (As if the TMS9929 in the TI 99/4A worked so well...)

Thus, no directly addressable frame buffer, and no way how to render graphics on the video RAM, except by the TMS34010 itself, or through the 1-word port. Thus, not only CBM was smoking some strange weeds when making decisions, TI seemingly also did. "We are from Texas, we do it our way."

Well, the card itself was not really developed by CBM, but engineered by the University of Lowell, and they tried to mitigate these restrictions as best as they could. Thus, while the 68K cannot access video RAM on the board, ULowell built in a reverse gate such that the TMS34010 can access 68K Ram through DMA, or at least the 16MB in the Zorro-II address window.

Thus, as you can imagine, this was quite an engineering challenge to build a P96 driver for it. The P96 interface is designed for contemporary "SuperVGA" chipsets, and as such, requires a directly accessible frame buffer where it could render its graphics, exactly *not* what the TMS34010 offers.

But, we have DMA on board, we have (or I expect to have) a MMU on board, so let's see which magic we can do with this.

...to be continued...

[StevenJGore]

Originally Posted by Thomas Richter

Thus, as you can imagine, this was quite an engineering challenge to build a P96 driver for it.

Did you do it for the challenge, or due to a user request? I'm guessing not many will still be in use. Sounds very interesting, anyway.

[Thomas Richter]

Probably a bit of both. There is a thread on "loose ends in P96" at A1k, and there one suggestion was to add support for the ill-fated A2410. I would not say that I jumped on it, I was more curious about the board and so I did quite some reading and a lot of detective work to find out how it works. There are even some traces of an attempt to create an A2410 driver in the P96 source code repository - but those attempts did not last long and did not result in a working driver, they go along an entirely different direction, and a direction that could not lead to success.

As said, P96 requires its frame buffer, and this early attempt tried to offload all rendering to the TMS34010. That's not possible as P96 does not forward all possible rendering requests to the chip drivers (and cannot even do so as users may even request direct access to a frame buffer - that is not there).

[Thomas Richter]

...next chapter...

As said before, the issue is that P96 needs its frame buffer to render graphics into, even though it can off-load some operations to an on-board blitter, though not all. In particular, user applications can request direct access to the frame buffer temporarily and render graphics there themselves.

As the TMS chip does not offer direct access to its frame buffer, the driver needs to provide one itself, let's call this the "shadow frame buffer". We "just" need to keep it in sync with the real frame buffer.

One possible option for that is to check with the MMU whether any changes have been made to the shadow frame buffer, and if so, copy data over to the real frame buffer by a separate "refresh" task. That does work, but it is really a CPU hog. Actually, I believe this is how the EGS driver for the board works.

Trouble is, the CPU has to touch now every data twice. Once for rendering it into the shadow frame buffer as the TMS blitter cannot reach it there, and once more for copying (parts of) the shadow frame buffer back into memory. Probably a bit intense.

But wait, the TMS does have access to the 68K memory, at least to Zorro II memory. Thus, if the shadow frame buffer is in Z-II memory, and the MMU descriptors for the shadow frame buffer are in Z-II memory as well, then the TMS can check itself whether any parts of the shadow frame buffer have been modified by checking the MMU descriptors, and copy them over. Thus, the 68K can render whenever it likes into the shadow fb, and it will magically appear on the TMS side as its processor takes care of copying it over.

Slight problem: While the TMS can read the 68K MMU descriptors, it cannot modify them as to indicate that the refresh was done and that the corresponding MMU page is already up to date. So it would continue to update the same screen parts again and again, even though there is no difference anymore.

Why? Well, the MMU descriptors of the 68K not only sit in memory, they also sit in the 68K "address translation cache" (ATC) and the 68K side needs to flush it from its own cache before it will notice that they changed in RAM.

But that we can do: Another (a lot less active) side task on the 68K can continuously check for modifications of the MMU descriptors, check whether pages are "dirty" and fix that - only with the problem that if a page is dirty, it need to make sure that the TMS had already picked up that page and copied it back into its own frame buffer.

So what can we do? A second list of refresh (or generation) counters besides the MMU descriptors that can be both read and written from both ends, the TMS end, and the 68K end. One counter describes the state (or generation) of the data in the real frame buffer of the TMS, a second counter the generation of the shadow frame buffer data. Whenever the counters differ, the TMS picks up data per DMA from the shadow frame buffer, copies it to the real frame buffer, and then updates the generation counter. Whenever the 68K finds that one of its MMU descriptors is "dirty", it updates its side of the counter, the shadow-frame buffer generation counter, and clears the MMU "dirty" flag on its side.

That does cost some CPU time, but much less time than actually copying the entire data over, so it is rather lightweight on the 68K end.

Only drawback is that it means that it takes a while for screen updates to appear on the TMS side.

Can we do better?

...to be continued...

[mfilos]

Although I lack many of the technical knowledge, i’m still fascinated

[Thomas Richter]

Originally Posted by mfilos

Although I lack many of the technical knowledge, i’m still fascinated

The thread is mostly for entertainment. I believe everybody should be aware by now that one cannot make the A2410 a decently working graphics card, it's design is too bizarre. Actually, the only way this card (or this chip) makes sense to me is to run an X11 server, entirely in the TMS program space. This way, only minimal data needs to be exchanged between the TMS and the host system as X11 is based on rendering instructions and manages graphics objects through abstract handles. Thus, a "pixmap" handle (something you can render on) could be a pointer to a graphics object in TMS space.

[Thomas Richter]

Back to the topic.

Given the Zorro II bandwidth and the execution speed of the TMS34010, one can estimate how much time it would need for the TMS to perform an entire screen refresh. I arrive at approximately 0.3 seconds (or approximately 3fps, in terms of speed), which is not too bad, but still slow. If only parts of the screen are refreshed, then due to the MMU magic explained above, the refresh would be quicker, but there is still a noticeable delay between the CPU performing the rendering on the P96 side and the rendered graphics appearing on the screen. It just takes a while until the refresh "comes around" and the TMS picks up the new data in the shadow frame buffer.

Ok, so what can we do? We can, at least for some operations, let the TMS do the rendering upfront the refresh. Thus, if I want to draw a rectangle, I can instruct the TMS do to the drawing as this is one of the operations its blitter can perform. However, if I would just do that, the next refresh would overwrite the rectangle as the shadow frame buffer does not contain it.

It means that the rectangle has to be drawn twice: Once by the TMS in its own video RAM, and once by the 68K in the shadow frame buffer. As both processors can operate independent of each other, this will not delay operations, but it will neither improve rendering time as the 68K has to do its job anyhow. However, and that is the advantage, the rectangle appears right in time, "on spot", and not just when the next refresh comes around.

Overall, the system is more responsive, but not faster. That's a gain, but not much.

The result looks... strange. It means that every rendering that can be offloaded to the TMS appears immediately (window borders, drag bars, sliders, icon borders, text) and every other rendering is refreshed a bit later (icons on the workbench itself). Icons cannot be offloaded to the TMS since it uses another drawing primitive (convert planar to chunky) the TMS does not accelerate, and even if it would, I would to manually transmit the entire icon data to TMS space, and that's the same number of bytes it takes in chunky space during refresh.

[Thomas Richter]

Can we do better?

Well, if you think about it, potentially. While the 68K does not have access to TMS space, the TMS has access to (Zorro-II) 68K space. So in principle, drawing a rectangle into the shadow frame buffer is something the TMS could *also* do. Not just rendering it in the video buffer, but into the copy that is accessible to the 68K and serves as frame buffer for P96 and its programs.

Unfortunately, there is a catch: For that, the TMS needs to request the Zorro-II bus for the entire time of drawing the rectangle, which means that any other participant of the Zorro-II bus cannot have it. In particular, if a DMA transfer is currently running, e.g. by a DMA-capable SCSI hostadapter, the DMA hostadapter would not be able to deposit its data in the target space, and the result would be corrupt data.

Thus, the current DMA logic for the refresh is a bit tricky. The TMS requests the bus, copies 32 pixels, then releases the bus and waits a while, then checks whether everyone else wants the bus, and then goes for the next 32 pixels. Thus, whenever some DMA transfer is running, there is at least a chance that the SCSI controller (or whatever) can get the bus, and then keep the bus for the entire transfer, while TMS refresh is pausing.

So yes, one could speed up rendering, and releasing the 68K side entirely to so something more useful than updating the shadow frame buffer, but only at the price of some DMA devices no longer operating properly.

That's why I stopped thinking in this direction. Hopefully, the current DMA logic will keep such host adapters working, but I have not yet verified that.

[Magic]

I am pleased to see some interest in the 2410! I have an A3000UX and have managed to get a hold of (2) A2410 Lowell cards over the years. Even after getting Amiga Unix to install from an A3070 using a Picasso II+ as the graphics card.

The first one is a functioning early development unit with lots of stacked chips, a rather large number of patch wires, and many 74LS series logic ICs. This one is missing the back plate but does function.

The second A2410 card is the final version. This one came to me NOS in the retail box with an enormous price tag still intact. This one works as well.

I'll buy the new P96 update again (already have numerous times) as a show of appreciation for all of your work. It is priceless.

[utri007]

There are ways to speed up xPert Merlin Zorro II performance. When card has a 4mb ram, it uses only 2mb with Zorro II, with it's native RTG software ProBench it uses "not in use" 2mb as a cache, which offers nice performance boost for graphics.

xPert Merlin has it's problems, but when all the fixes has made by Ingenieurbüro Riedel it is very useable and speedy card. Though nobody should use 24bit modes, but 16bit modes are just fine.

[Thomas Richter]

Unfortunately, that is not the case. I had a Merlin here, with all fixes applied, and it still did not work correctly. Issues were wrongly received register values, pixel noise and complete hangups. The driver does its best to avoid the problems, such as verifying for most register writes whether the value written really makes it into the register by performing another read after a write, but it cannot do consistently all over the code. This card does not work correctly, despite Riedel's fixes and promises.

There seems to be some conflict on the Zorro bus with the Merlin in place, I do not know where and how, it seems to be a hardware issue. There are similar issues with the Visiona where, unlike what specs promise, you cannot write into the INMOS registers while the display is active. This must be some XPert-typical issue where they probably did not follow all corner cases of the specs throughout their product range. It would require a logic analyzer and a scope to really understand what is going on here.

Up to then: Avoid this card. It *may* work if this is the only card in the Zorro bus. Otherwise, chances are pretty high that it does not.

[utri007]

Up to then: Avoid this card. It *may* work if this is the only card in the Zorro bus. Otherwise, chances are pretty high that it does not.

I have Merlin with it Delfina and X-Surf. Seems that X-Surf causes more problems than Merlin and it limits number of Zorro cards to 3. I can add more cards if I remove X-Surf. Without a X-Surf, but with Merlin I can use also Thylacine and Buddha. This is with Amiga 1200 with Micronick Zorro II extender, but funny enough, I also have a another 68060 setup, with Elbox Zorro IV, and it has exact same situation with X-Surf.

Merlin is noticeable faster than GVP Spectrum.

But this is OT, sorry that. But as a original question, are you sure you have all the fixes made? Have you asked from mr. Riedel about your problem with Merlin? I got rid off pixel noise, when I changed PSU to new.

[Thomas Richter]

Originally Posted by utri007

But this is OT, sorry that. But as a original question, are you sure you have all the fixes made? Have you asked from mr. Riedel about your problem with Merlin? I got rid off pixel noise, when I changed PSU to new.

It wasn't my card, I only had it temporarily. But it had a set of new GALs on it, and the additional wires on the back, and its owner told me that the fixes had been made. Anyhow, I had the X-Surf successfully used with a GBA-PII, a Picasso-IV and a Multiface in the system without issues.