CGA 160x100x16 bidirectional scrolling

[digger]

Sticking more with the actual topic of this therad: what would also be an idea is to render such AGI games "zoomed", so without any loss of graphical detail, but with everything blown up 2x, with the monitor only showing part of the screen and using this hardware scrolling functionality to follow the playable character as the player moves them around the screen. It might pose challenges for parts of the game where a dangerous enemy appears that isn't immediately shown in the viewable part of the screen.

 

[Frenkel]

Upscaling AGI has some problems. I don't know if the same problems apply to downscaling.

 

[resman]

If they indeed expected a 160x200 resolution screen and use vector graphics, it seems like faking the vertical resolution would be the way to go. Just need a way to render a semi-legible font. I don't think scrolling would benefit a game like this very much. Since the animated graphics are of such low complexity, you could easily render this without snow.

 

[commodorejohn]

Given that the vector format is based on lines bounding flood fills, I wonder if it wouldn't work fairly well to fake 100-line "subpixel" accuracy on line drawing - essentially, where "true Y" is odd, draw on both (Y / 2) rounded up and (Y / 2) rounded down - and then flood-fill as normal.

(You'd still have to maintain a "true" image for collision purposes, but this'd be faster for drawing than proper downscaling while still looking better than missing-line rendering.)

 

[digger]

Ah yeah, AGI games used vector graphics. I didn't even consider that. Indeed, that might make for even more interesting results at 160x100.

 

[commodorejohn]

Character/object sprites are bitmapped, so you'd still have to do some downscaling, but it'd simplify the backgrounds at least.

 

[Zare]

Hello and thanks for great work on this lib.
I tried it out on real hardware which is a superset of CGA and did not expect it to work well. 8088MPH stops working after "Intel Inside" part.
Adapter is https://www.seasip.info/VintagePC/plantronics.html .

LORES does work but it only draws a portion of the view. The demos work, you can scroll smoothly, the programs respond, you can normally exit.

Can this be patched just by entering correct memory boundaries? Also is it possible to use twice the video RAM to get additional performance or colours? ColorPlus can do 320x200x16. Even on original worn down mono screen in daylight there's recognizable difference in 4/16

 

[resman]

Well, that's an interesting question if the LORES library could support the Plantronics memory layout. However in your screenshot it appears that the Plantronics doesn't like reprogramming the character cell to two scanlines (making everything look stretched vertically). I also don't know if the Plantronics wraps it's video output back around at the 32K boundary. I don't have one myself, and honestly it seems that there would be better video modes suitable for this video card.

 

[VileR]

Huh - that's weird, considering that the ColorPlus card appears to use a real 6845, and no custom video BIOS extension. I assume they had to map the chip to the same port, and couldn't play too many tricks with address decoding or with the data lines, else the normal BIOS video modes wouldn't work. So it's curious that this particular 6845 register doesn't achieve the intended result (especially since the image is otherwise full-screen and stable).

 

[Zare]

The card is not a ColorPlus. It seems to be an embedded version of Paradise Hi-Res Graphics Adapter, which supports Plantronics mode. It's 6845 together with PVC2 chip.

So my example may not actually be relevant for a ColorPlus adapter, but for Paradise chip.
For testing LORES for ColorPlus, there's emulation available in 86Box.

 

[Zare]

Well, that's an interesting question if the LORES library could support the Plantronics memory layout. However in your screenshot it appears that the Plantronics doesn't like reprogramming the character cell to two scanlines (making everything look stretched vertically). I also don't know if the Plantronics wraps it's video output back around at the 32K boundary. I don't have one myself, and honestly it seems that there would be better video modes suitable for this video card.

Huh - that's weird, considering that the ColorPlus card appears to use a real 6845, and no custom video BIOS extension. I assume they had to map the chip to the same port, and couldn't play too many tricks with address decoding or with the data lines, else the normal BIOS video modes wouldn't work. So it's curious that this particular 6845 register doesn't achieve the intended result (especially since the image is otherwise full-screen and stable).

Original ColorPlus doesn't have video BIOS but it doesn't have a secondary microcontroller either. It's just a 6845 and a ton of memory chips around it.
In M19 the secondary chip is PVC2. There is no info about PVC2 but there is a manual of PVC4 which seems to be a VLSI PVC2+6845 in a chip.

Poking around this hardware with the manual, it's definitely not a ColorPlus, but a "Paradise Hi-Res Graphics Adapter". It may be called "Olivetti Graphics Controller" because it has a proprietary video output.
It supports different modes including CGA and Plantronics. It may not support reprogramming CGA as its manual doesn't have any notion of 3D4h register. 6845 is used by PVC2 and not vice versa, as pulling out the PVC2 from the board disables the entire onboard graphics (the 6845 is soldiered).

 

[Zare]

Well, that's an interesting question if the LORES library could support the Plantronics memory layout. However in your screenshot it appears that the Plantronics doesn't like reprogramming the character cell to two scanlines (making everything look stretched vertically). I also don't know if the Plantronics wraps it's video output back around at the 32K boundary. I don't have one myself, and honestly it seems that there would be better video modes suitable for this video card.

I've found out some data about the video system of this machine meanwhile.

It has a switchable video system that either uses monochrome monitors (simulating CGA color on MDA), additionally supporting 400-line output, or colour monitor where the card behaves completely like Plantronics CGA.

Above screenshots on PX3 aren't in 320x200 16 shades but 4. My mistake. The monochrome mode has some special 6845 line doubling going on and it prohibits reprogramming the character cell.

I'd still like to be able to run LORES in machine's CGA mode - it can run Paku Paku normally, but with LORES I get scrolling issues;



Scrolling to the right a bit gives me this :



The sprite demo also has a bit of glitching, the same black line on the scroll 'border', and the smiley face sprite flickers.
If you think this can be mended by some slight code change I can provide further videos, also of the CGA_comp test if needed...

 

[resman]

I've found out some data about the video system of this machine meanwhile.

It has a switchable video system that either uses monochrome monitors (simulating CGA color on MDA), additionally supporting 400-line output, or colour monitor where the card behaves completely like Plantronics CGA.

Above screenshots on PX3 aren't in 320x200 16 shades but 4. My mistake. The monochrome mode has some special 6845 line doubling going on and it prohibits reprogramming the character cell.

I'd still like to be able to run LORES in machine's CGA mode - it can run Paku Paku normally, but with LORES I get scrolling issues;

View attachment 1299023

Scrolling to the right a bit gives me this :

View attachment 1299024

The sprite demo also has a bit of glitching, the same black line on the scroll 'border', and the smiley face sprite flickers.
If you think this can be mended by some slight code change I can provide further videos, also of the CGA_comp test if needed...

My best guess is that the additional memory is causing the weirdness. The LORES code counts on the CGA wrapping access beyond 16K, not just for video scan out, but for CPU access. A generic CGA should decode 32K of memory space but alias the first 16K in the second 16K. In the inner loops, LORES will write off the end of the first 16K into the second 16K before wrapping its address with a mask.

If this is the issue, then the software fix would be to mask the address after every access to ensure it wraps properly to the frame buffer. The next question is does the scan out wrap at 16K in the CGA modes? REPELZ has a large map that would completely fall apart if your CGA does't wrap at 16K.

So, two potential issues. One can be fixed in software (probably a noticeable performance hit) by masking the destination address in the inner loops, and the other might be worked around by using the entire 32K.

Hard to know if these are the only issues to work through, but if you want to give it a go, I can help you make the code changes.