• Please review our updated Terms and Rules here

VGA MODE X help....

I think the most efficient way in mode X may be to exploit the latches. This way you can read/write 4 bytes for every byte you address with the CPU.
This has two drawbacks though:
1) All sprites must be stored in videomemory before you can use the latches
2) Because of the memory layout, you can only address in blocks of 4 aligned pixels at a time. This means that for every sprite you need to have 4 different copies copies, displaced by 0, 1, 2 and 3 pixels, to be able to have pixel-exact sprite positioning on screen.
 
I think the most efficient way in mode X may be to exploit the latches. This way you can read/write 4 bytes for every byte you address with the CPU.
This has two drawbacks though:
1) All sprites must be stored in videomemory before you can use the latches
2) Because of the memory layout, you can only address in blocks of 4 aligned pixels at a time. This means that for every sprite you need to have 4 different copies copies, displaced by 0, 1, 2 and 3 pixels, to be able to have pixel-exact sprite positioning on screen.

!!

oh!!


https://github.com/sparky4/16/blob/master/planarNotes.txt

my friend made a planar buffer system

it just load images and not render them....
 
This has two drawbacks though
THREE. You missed one.

If you use the 1 byte to 4 by turning all planes on at once, all four pixels you write have to be the same colour.

This is handy for blanking and routines like hline or vline, but not as much for things like blitting sprites to memory since rarely are sprites a uniform colour in a 256 color mode... unless it's something like a font.

Font blitting by storing the font as a plane mask instead of as the bitmap can rock in mode X. An 8 pixel wide font being at minimum a 2 byte per scanline write, at worst 3 bytes. My preferred method of using kerned variable width characters ranging from 5 to 7 pixels wide can quite often result in aligned font characters being a one byte write, and rarely going past that second byte when not aligned. (the letters M, W, X, Y and.. uhm, yeah).

As I said ages ago on another forums, I often wished that the planar mode had 8 planes, just for the purpose of dealing with aligned fonts... but again planar mode is more a side effect of the EGA style 4 bit modes and wasn't really ever meant to be used with 8 bit colour depth; that it works at all on most every VGA implementation is more a happy coincidence than by plan.

I've actually been playing with the 320x240 mode X myself both for a fun little side project I've been playing with for quite a long time, and to make a new font implementation. Was thinking on adding the 360 modes (I used to program the 360x480 one all the time) but that * 90 of "<< 6 + << 4 + << 3 + << 1" is a real PITA compared to a simple << 6 + << 4. I could probably just use lookup tables, but I'm not a big fan of that.

Though there are times I wish to blazes you could set an "overscan" area in memory to not be shown, to make sprite clipping easier. You end up stuck either making your own software buffer at which point why bother setting up mode X for page flipping in the first place, or making the sprite routines so complex you lose any speed bonus hardware paging would have given you quickly taking what should be an 286/6 project into 386/40 territory.

... at which point grab go32v2 or some other DOS extender, drop into 32 bit mode and go to town on it.
 
If you use the 1 byte to 4 by turning all planes on at once, all four pixels you write have to be the same colour.

No they don't.
Each plane has its own latch in the ALU. So if you do a 1-byte read from video memory, you read a byte from all 4 planes, into their respective latches.
If you then do a 1-byte write to all 4 planes, you write all 4 latches to their respective planes.

Though there are times I wish to blazes you could set an "overscan" area in memory to not be shown

This is actually possible on EGA/VGA.
Vertical overscan is doable even on CGA, by simply adjusting the start offset of the screen, and reducing the number of visible scanlines (the DeLorean part in 8088 MPH does this).
EGA/VGA also allows horizontal overscan because you can specify a 'logical width' of the scanlines, allowing you to have extra space between scanlines in memory.
See the 'offset register': http://www.osdever.net/FreeVGA/vga/crtcreg.htm#13
The downside of course is that the "overscan area" still takes up actual video memory, of which you don't have all that much to begin with.
 
Last edited:
No they don't.
Each plane has its own latch in the ALU. So if you do a 1-byte read from video memory, you read a byte from all 4 planes, into their respective latches.
If you then do a 1-byte write to all 4 planes, you write all 4 latches to their respective planes.
Oh, that's what you meant... I never really understood the point of that is how is dicking around setting those latches any more efficient than simply writing to memory -- it's MORE work and more time, not less...

Well, unless you're copying from video memory to video memory, then it's not bad. Good for scrolling, good for duplicating one page to another, useless for sprites (typically) -- unless you waste that limited amount of video memory on sprite storage instead of page flipping. Between the extra memory consumed by mode x, the extra pre-shifted copies, animations and multiple sprites, there's not a lot of room left for doing that.

That or I'm missing something obvious about it. Never understood how that entire latching crap was actually useful in 8 bit modes apart from masking before write, and even then you end up writing each plane individually with your sprite data in mode 13/mode X eliminating that advantage. 4 bit colour modes, sure -- useful as all git since the planes are colour... 8 bit modes not so much since the planes are horizontally interlaced columns of pixels.

This is actually possible on EGA/VGA.
Only ever seen that work in 16 colour modes. Mode 13 and the "Mode X" derivatives that doesn't seem to fly.

Do you have examples of either of these as what your saying doesn't match with anything I've ever seen or understood about it... certainly doesn't match up with Ferraro's book. (which is basically the go-to for EGA/VGA/SVGA particularly on register info).

I mean, one of the entire reasons mode 13 and the 200/240 mode X flavors changed PC gaming was you didn't have all that to deal with.

I'd actually LIKE to be proven wrong on this!
 
That or I'm missing something obvious about it. Never understood how that entire latching crap was actually useful in 8 bit modes apart from masking before write, and even then you end up writing each plane individually with your sprite data in mode 13/mode X eliminating that advantage. 4 bit colour modes, sure -- useful as all git since the planes are colour... 8 bit modes not so much since the planes are horizontally interlaced columns of pixels.

The problem is that mode X is somewhat of a necessary evil. You can only addresss the memory through the A000-segment, so you only have 64K of address space. So to use the full 256K of VGA memory, you have to use mode X as a sort of bank-switching system.
In mode 13h, you can't do things like page flipping, scrolling etc, because a single 320x200 screen already uses up nearly the full address range (much like on CGA, where you only get 16K of memory, so there is no backbuffer).
 
The problem is that mode X is somewhat of a necessary evil.
I get that, I'm just not seeing how the read/write latches would even work since here, well... they don't. I understand using them completely in 16 colour mode, but swtich to 256 they don't seem to work and/or serve a purpose. I get the horizontally interlaced scheme, how to use the planes, that it's bit-masked for write but value packed for read, etc, etc... The latching that is useful in 16 colour doesn't seem to exist in 256 apart from masking off the PIXEL bit-wise, since reads are ALWAYS restricted to ONE plane. Handy for masking one plane at a time in 16 colour mode, NOT so handy when you have pixel planes.

Which might be useful for blending effects, but does not end up useful for much else -- less so than I said in my last post as my thinking got muddled after what you were saying about it.

Though I've often wondered... is there some reason memory map select 00 isn't used? Does it not work? In THEORY it's supposed to open up A0000-BFFFF as addressable by the CPU and used by the video for the active graphics page. Gonna play with that as if you opened that up, you could make a second page at 0xAFFF0 and then start the vertical at that offset. (sadly the 16 bit field isn't useful for going past that in 8 bit mode).

Unless there's something horribly wrong with that setting... Like B0000..B7FFF being reclaimed by the host OS for use as a UMB... Oh, wel... Alright, that's probably why it isn't used.
 
uwaaa!!

i need help with setting up the 2nd resolution 192x144

static const word ModeX_192x144regs[] = {
0x5f00, /* Horizontal total */
0x2f01, /* horizontal display enable end */
0x5002, /* Start horizontal blanking */
0x8203, /* End horizontal blanking */
0x5404, /* Start horizontal retrace */
0x8005, /* End horizontal retrace */
0x0d06, /* vertical total */
0x3e07, /* overflow (bit 8 of vertical counts) */
0x4109, /* cell height (2 to double-scan */
0xea10, /* v sync start */
0xac11, /* v sync end and protect cr0-cr7 */
0x1f12, /* vertical displayed */
0x1813, /* offset/logical width */
0x0014, /* turn off dword mode */
0xe715, /* v blank start */
0x0616, /* v blank end */
0xe317 /* turn on byte mode */
};

here is the regesters and their values(the values on the left 2 digits and id is right 2 digits)
 
Though there are times I wish to blazes you could set an "overscan" area in memory to not be shown, to make sprite clipping easier. You end up stuck either making your own software buffer at which point why bother setting up mode X for page flipping in the first place, or making the sprite routines so complex you lose any speed bonus hardware paging would have given you quickly taking what should be an 286/6 project into 386/40 territory.

... at which point grab go32v2 or some other DOS extender, drop into 32 bit mode and go to town on it.

NO 32 BIT!!!:mad:

16 BIT ONLY!!!

the game's code name is project 16 it is supposed to RUN on 16 bit hardware with vga ^^;
 
ok Do you want me to explain what the software is going to be used for?
well...

https://github.com/sparky4/16/raw/master/test.exe

https://github.com/sparky4/16/raw/master/scroll.exe
scroll.exe requires
https://github.com/sparky4/16/raw/master/data/ptmp.pcx
https://github.com/sparky4/16/raw/master/data/ed.pcx
https://github.com/sparky4/16/raw/master/data/test.map

also a layering approch to render the graphics

for like rain, trees, obscuring objects, and of course the sprites

what is clipping?
what is blitting?

the source code of the graphical library is

https://github.com/sparky4/16/raw/master/src/lib/modex16.c
https://github.com/sparky4/16/raw/master/src/lib/modex16.h

lets not forget this~
https://raw.githubusercontent.com/sparky4/16/master/src/lib/planar.c
https://raw.githubusercontent.com/sparky4/16/master/src/lib/planar.h

i want to render the planar buffers~
 
Last edited:
The game's code name is project 16 it is supposed to RUN on 16 bit hardware with vga ^^;
YOURS might be, doesn't mean MY project is! Though I was just saying that the complexity of certain things might force a project into that territory speed-wise.

The 192x144 is VERY unreliable across platforms, I've rarely seen displays that will sync to it.

Though... you have the CRTC values, what part are you stuck with?

Code:
; ASSUMES
;   we're free to modify all but DS
;   Mode 13 was started
;   You've unlocked the Sequencer to accept new values
	push   ds
	lds    si, ModeX_192x144regs
	mov    dx, 0x03D4
	mov    cx, 18
.loop:
	lodsw
	out    dx, al
	inc    dx
	mov    al, ah
	out    dx, al
	dec    dx
	loop   .loop
; be sure to re-lock the sequencer here

Locking/unlocking and unchainging should be no different than any other X-mode. If it's not working, it's probable the display you are dealing with can't sync to that low a horizontal resolution. Very few of the sub-320 widths work in a reliable fashion if at all.

Oh, and if you are caring about 8bit or 16 bit bus hardware aka 8088/8086, do NOT write both words as it will sometimes skip the sequencer address, particularly on 8 bit VGA cards. Take the time to write each byte to the ports individually or a good number of VGA cards will flat out ignore you. What works just fine on a diamond speedstar 24x on a 16 bit ISA bus, might not fly on a 8 bit WD Paradise88 or Trident 8800.

Though laughably with addressed registers sometimes it's the other way around, 8 bit works as the bus is forcing it to, whilst 16 bit writing both at once instead of in order fails.
 
Last edited:
what is clipping?

Clipping is 'cutting off' (not drawing) parts of an object that would fall off the edge of the screen. If you don't do that, the offscreen pixels may wrap around to the other side of the screen. Or you write outside of your framebuffer, and you may corrupt other memory.

what is blitting?

'Blit' is short for 'BLock Image Transfer', which basically means copying a block of pixels from one place to another, eg when you want to scroll something on screen, or move sprites around.
More advanced systems (eg Amiga, various SVGA cards) have hardware blitters on board.
 
YOURS might be, doesn't mean MY project is! Though I was just saying that the complexity of certain things might force a project into that territory speed-wise.

The 192x144 is VERY unreliable across platforms, I've rarely seen displays that will sync to it.

Though... you have the CRTC values, what part are you stuck with?

Code:
; ASSUMES
;   we're free to modify all but DS
;   Mode 13 was started
;   You've unlocked the Sequencer to accept new values
	push   ds
	lds    si, ModeX_192x144regs
	mov    dx, 0x03D4
	mov    cx, 18
.loop:
	lodsw
	out    dx, al
	inc    dx
	mov    al, ah
	out    dx, al
	dec    dx
	loop   .loop
; be sure to re-lock the sequencer here

Locking/unlocking and unchainging should be no different than any other X-mode. If it's not working, it's probable the display you are dealing with can't sync to that low a horizontal resolution. Very few of the sub-320 widths work in a reliable fashion if at all.

Oh, and if you are caring about 8bit or 16 bit bus hardware aka 8088/8086, do NOT write both words as it will sometimes skip the sequencer address, particularly on 8 bit VGA cards. Take the time to write each byte to the ports individually or a good number of VGA cards will flat out ignore you. What works just fine on a diamond speedstar 24x on a 16 bit ISA bus, might not fly on a 8 bit WD Paradise88 or Trident 8800.

Though laughably with addressed registers sometimes it's the other way around, 8 bit works as the bus is forcing it to, whilst 16 bit writing both at once instead of in order fails.


i noticed 192x144 is difficult to get working well

it is particularly stretching the visible screen over the over scan


thanks Scali for the info
 
p16pbd.png


yay!!

i hope it works well

https://github.com/sparky4/16/blob/master/src/lib/modex16.c
https://github.com/sparky4/16/blob/master/src/lib/planar.c

source code

strcpy dose not like 0x00 so it omitted it... wwww
 
Last edited:
Don't reinvent the wheel -- mode-x C libraries were written 2.5 decades ago. Here's a good one that works on 16-bit systems, although the optimizations require a 286: ftp://ftp.lanet.lv/pub/programming/mirror-x2ftp/xlib/xlib06.zip

If you REQUIRE 8086 compatibility you'll need to set .8086 in the assembler source and then fix anything the assembler says won't work on an 8086, which is usually easy to do but will slow things down a little.
 
Don't reinvent the wheel -- mode-x C libraries were written 2.5 decades ago. Here's a good one that works on 16-bit systems, although the optimizations require a 286: ftp://ftp.lanet.lv/pub/programming/mirror-x2ftp/xlib/xlib06.zip

If you REQUIRE 8086 compatibility you'll need to set .8086 in the assembler source and then fix anything the assembler says won't work on an 8086, which is usually easy to do but will slow things down a little.


okies!~:D
 
Back
Top