P96 3.0.0 (and later) news and support

[Thomas Richter]

Maybe back to topic:

As already said, the TMS34010 does not have directly addressable video RAM, but the strange auto-increment VRAM ports through which you can push words to its memory, the IO registers or to the RAMDAC. That's quite unlike what conventional SuperVGA chips did. It seems I wasn't the only one that complained about this strange design. TI fixed that with the follow-up TMS34020 which does provide access to its memory. It also includes a FPU and supports some (elementary) 3D graphics and 3D rendering. Unfortunately, it was not very fast.

The TMS "TIGA" CPUs had a quite orthogonal, though odd design. It features two register sets of 15 32-bit registers, and features risc-type instructions. Move to-from memory with addressing modes that look quite what 68K can do: register, indirect, post-increment, pre-decrement, indrect with offset, and the usual add/sub/mul/div/or/and/shift/rol instructions. In addition, it has "fill" and "pixblt" instructions, a "line" instruction for drawing lines, pixel-plot, and a "plot-and-increment" instruction one can use for line drawing or circle drawing.

So far, so good. What is odd is that it uses "bit addressing", that is every bit in the system has its own address. The "move" instruction thus does not read words or longs, but bit-fields of variable size, potentially sign-extending the read field. Bits are numbered from 0 to 15 within a word, with 0 the LSB and 15 the MSB. The LSB of the next word is then bit
#16 and so on.

This makes the TMS neither big nor little endian, but little-endian word-addressed as higher addresses contain most-significant bits. Conclusively, the DMA logic outside the TMS on the A2410 (for accessing 68K memory from TMS space) contains a logic to swap bytes.

That is, however, not the only thing that needs swapping. The Video RAM also shifts pixels out LSB first, such that the leftmost pixel is the least-significant (and not most-significant, as on the Amiga) bit. For chunky (8-bit) pixels, this does not matter as the RAMDAC data bus can just be swapped. The VideoRAM on the Visiona and GVP 110 had the same issue, but solved the problem in a different way: The color-lookup entries performed the bit-swapping, i.e. entry 128 (binary 1000 0000) is the value of pixel value 1 (binary 0000 0001).

Anyhow, this means that also the bits on the sprite-plane are bit-reversed, and the driver has to reverse the bits before uploading the sprite image.

Concerning RAM, the chip does not use conventional DRAM as you know it, but video RAM. Video-RAM is dual ported: On one end, it contains a data and address port such that the TMS can read and write data as you know it. But it also includes a "shift register" which is the size of an entire row of RAM cells. With a special sequence, the entire "row" of the RAM is loaded into the shift register, and the shift register is then clocked out by the pixel speed, forming the (digital) image. Thus, the RAM (and not the video chip) generates the signal.

This design was not so unconventional on early video boards, i.e. offloading parts of the logic to the RAM. The GVP EGS 110 and the Visiona had a similar design. The advantage is that by this you can reach higher pixel speeds - the GVP could do truecolor in 1280x1024, something quite extraordinary at its time.

The odd part about this is that each line on the screen is represented by one row of the RAM, and thus the stride of the bitmap (what the Amiga would call the "modulo") is fixed to what the RAM can do. On the A2410, the RAM row contains 1024 pixels, but spread out to 8 chips. As the stride is 1024 pixels fixed, an 800x600 screen takes actually 1024x600 bytes memory, and not 800x600. This means in particular that two 800x600 screens do not fit into the video RAM simultaneously, as there is only 1MB memory in total.

[alexh]

Slightly off topic but could this description be used to make a WinUAE emulated gfx card of this type? Would there be a use for one (AMIX?)

[Thomas Richter]

Originally Posted by alexh

Slightly off topic but could this description be used to make a WinUAE emulated gfx card of this type? Would there be a use for one (AMIX?)

Actually, there is WinUAE emulation for the A2410. At this point, it is not fully functional and there are some issues, but I did keep Toni in the loop during development. One problem is that the P96 driver (as I have it right now) depends on DMA access to 68K Zorro memory, and its emulation has currently a defect (one signal is inverted). I believe Toni should have fixed that in the meantime. There is another defect such that emulation of the TMS side hangs if no native or UAE screen is open, and the screen update of the TMS screen output is not working quite right. Anyhow, I believe these issues will be ironed out. The TMS emulation actually comes from another emulator.

[ProfPlum]

Thomas,

The newly released P96Prefs on Aminet mentions P96 3.4.0 in the release notes.
Is v3.4.0 available from the IC downloads?

[Thomas Richter]

Yes, that's kind of a spoiler, right? No, it is not yet available, but pretty soon now. My estimate is around two weeks from now.

[gdonner]

@Boing-Ball: 3.3.3 is the latest. The two posts preceding yours give the estimated time of release for 3.4.0.

[Dale423]

Originally Posted by gdonner

@Boing-Ball: 3.3.3 is the latest. The two posts preceding yours give the estimated time of release for 3.4.0.

It does, which was on July 2nd and 2 weeks have already past. The correct timeline guess should have said 2-4 weeks.

Software never cooperates. lol

[wiz12]

P96 V3.4.0 Released

Detailed changes in release 3.4.0:

• Added emulation for Extra Half Bright mode. It is enabled along with planar emulation.
• Planar emulation is now disabled if the board does not support a chunky mode required for planar emulation. This should be really rare, though.
• Allocation of bitmaps failed in case the bitmap flags still contained the magic DPaint flag that CPU blitting is necessary.
• now prevents a crash in case a driver forgot to set the pixel clock of a mode to a non-zero value.
• The CVisionPPC card driver accepts now the MEMORYCLOCK tooltype which specifies the memory clock in MHz.
• The graphics.library functions ClearEOL() and ClearScreen() have been broken in all versions of Amiga OS, including AmigaOs 3.2.2. Luckely, they are rarely used (and should probably be avoided altogether). P96 now includes a re-implementation of the functions that should be safe.
• If GRANTDIRECTACCESS is set, P96 now disables the planar mode as it requires switching the Chain4 mode and thus modifies content under the feed of a potential user of the direct access. In such cases, the planar emulation can be used.
• The installer forgot to install the Cirrus5446 driver for the PicassoIV board.
• The S3Virge driver installed a maximum horizontal resolution of 1280 for everything beyond highcolor. This limit was increased to 1440 pixels.
• P96Prefs will no longer accept to create modes that the P96 core would refuse to create if they are beyond the bounds registered by the driver.
• P96 disables screen dragging on autoscroll screens because VGA chipsets cannot pan the dragged screen below the screen split positions. The current logic for determine autoscroll screens compared the bitmap width with the width of the video mode. This is not quite correct as bitmaps on some cards may be required to be wider than the mode width. On cards using VRAM, the line size must be a multiple of the VRAM shift register size.
• The CVision3D driver now also supports horizontal resolutions wider than 1280 pixels for high-color modes.
• P96 now supports even more graphics boards. This time, the RainbowII frame buffer and the CBM A2410 was added to the list of supported boards.
• The RainbowII is not very exiting as it only supports 32bit TrueColor in either PAL or NTSC, interlace or progressive, thus modes cannot be freely defined.
• RainbowII was also marketed as FrameMaster by BSC and Elaborate Bytes, the driver supports all three boards.
• The A2410 was CBM's only graphics board, originally designed by the University of Lowell. It is based on the TI TMS34010 chipset. The chip is an oddity as it does not provide direct access to its video RAM. Thus, its driver needs to play some tricks with the MMU and requires the mmu.library. The TMS34010 chip includes blitter functionalities the driver uses when possible, though still needs to render by the CPU itself into a "mirror framebuffer". Thus, everything will be pretty slow. Again, note that you *need* the mmu.library for the A2410.
• The physical dimensions of the monitor in millimeters can now be put into the monitor icon tooltypes as MONITORWIDTH and MONITORHEIGHT. This allows P96 to compute the resolution of all modes on the monitor. Note that the tooltypes are in millimeters, not in pixels.
• The P96 distribution includes now additonal contributions: The P96Prefs program is the new style preferences editor. It replaces the Picasso96Mode if the target operating system is Os 3.2 or better.
• P96Mode did not compute the monitor limit frequency correctly, fixed.
• P96Mode did not check whether the board type as indicated in the board is correct.
• In case more than one board was installed, P96Prefs could have shown a dummy resolution of 320x200 pixels that is only for internal use.
• P96Prefs disabled modes if the requested clock frequency differed too much from the actual clock frequency. This is no longer the case.
• Additonal contributions are the Native monitor driver and the P96ScreenCX commodity.
• Updated the installer script to also install contributions and localizations.
• Again, I want to thank Samir and Javier for updating the Italian and Spanish catalogs of P96Prefs, and most of all Thomas Richter for his continued work on P96.

[Thomas Richter]

Apparently, wiz12 was faster than myself. (-: But yes, indeed, P96 3.4.0 was just released.

Maybe the highlights first. First, there is emulation for the Extra Half Bright mode on graphics cards that offer a chunky mode (thus, almost every card).

Then, we have a couple of new drivers. First, the RainbowII, which was also marketed as FrameMaster both by BSC and Elaborate Bytes. It cannot do much, only TrueColor in PAL or NTSC resolution, progressive or interlace. There are a couple of jumpers you need to set, and the tooltypes have to be set accordingly (or use P96Prefs for that).

Then, we have the A2410, CBMs one and only graphics card. This card is really an odd-ball and surprisingly hard to interface, which makes the driver slow. A working MMU and the mmu.library is required to make it work. The present driver can still do a lot more than CBMs own a2410.device. First, the resolutions are configurable and not limited to 800x600 and 1024x768. However, there are only two oscillators on the board, and thus available pixel clocks are very limited. For example, you can also use the card at 640x480 with 85Hz.

The driver supports a hardware sprite, panning and (tada!) screen dragging. The latter is however severely limited as the card has only 1MB of video RAM, and thus, only two 640x480 screens fit on the card simultaneously. It is too tiny for 2x800x600, leave alone 2x1024x768. The card has a "blitter" (sort of) which is even used, but still everything needs to be drawn twice by the CPU (sigh).

Then, my third party tools P96Prefs, P96ScreenCX and Native are part of the distribution now, so you do not have to go fishing in the Aminet. You still find them there, and they will remain to be available there as well.

We also have the option to configure the monitor dimension (in millimeters, yes, I like metric units) to set the pixel aspect ratio correctly. This is best done with P96Prefs.

Finally, I want to thank Javier and Samir for the spanish and italian translation!

There are many additional bug fixes I will probably report separately. wiz12 already provided the full list, but I may explain a bit more on this in separate posts.

[crobin]

Thanks for this downloaded just now

[kamelito]

@Thor, is P96 able to run games that are using the Gels system (sprites, Copper etc) if the screen is promoted?

[alexh]

Thanks for all your hard work.

I can see the ability of being able to use 1440 pixel screen modes (for some gfx cards) will no doubt be of benefit to anyone with a QHD (2k) monitor? Help avoid scaling?

[Thomas Richter]

Originally Posted by kamelito

@Thor, is P96 able to run games that are using the Gels system (sprites, Copper etc) if the screen is promoted?

If the GELs are actually BOBs, then yes. VSprites of course no, because the graphics cards typically only have one sprite. (Merlin has two, but only one is used, and the A2410 has "one big sprite" that is as large as the screen).

[kamelito]

I guess that sprites can be emulated using Bobs right?

[gdonner]

@Thomas Richter: If I may, just to confirm:

As far as P96 is concerned (along with DEVS:Monitors/ZZ9000) a correct ZZ9000 installation (LIBS:Picasso96) requires no ".chip" file--just emulation.library, rtg.library, and the zz9000.card files?

[Thomas Richter]

To install a third-party driver, select no graphics board in the installation. This will place a driver named "Generic" in DEVS:Monitors. Either, the installation procedure of the card then renames the monitor icon and adjusts it, or you need to do it yourself. This is easily done. Just edit the tooltypes with the workbench, there add or adjust the tooltype "BOARDTYPE" and set it the name of the driver (probably ZZ9000), then save the changes and rename the monitor icon to whatever you like.

[Thomas Richter]

Originally Posted by kamelito

I guess that sprites can be emulated using Bobs right?

Not automatically. VSprites are partially generated by the copper, they have their own colors and they do not require to save the background before drawing them. A program using vsprites will not show correctly on P96. A program using BOBs will. Actually, the workbench uses BOBs for dragged icons, and thus it works.

[Thomas Richter]

It should as the driver API did not change, but please note that I'm not maintaining its drivers. As far as I know, Elbox created these drivers, but stopped updating them long ago. Thus, while the drivers should be usable, they will not take full advantage of the features the new versions offer, such as screen dragging. What you do get are planar emulation and multi-monitor support, they are independent of the driver but features of the core system.

[Thomas Richter]

Originally Posted by Boing-Ball

Screen dragging now available on Permedia and voodo cards now? Missed that one.

The permedia lacks the screen-split register for that, so no, it cannot drag screens. The voodoo driver I have not written, that's probably another Elbox thing.

[Thomas Richter]

Yes, naturally. The P-IV is well supported, even supports mode-mixing (dragging of hi-color over chunky screens or vice versa works), and also supports memory windows (Picture-in-Picture).