Update: I reworked my test code in C.
Link to repository: https://github.com/keenmaster486/BEEP6

It is working now! Sets the video mode and can draw some lines. I can move forward with this, although I still wish I could do it in C++ instead.

You should add a .gitignore to your repository, ignore obj, exe, err etc...

Someone mentioned earlier; Watcom defaults to its own calling convention where the first four parameters to a function call are passed in registers. Other compilers use the default of passing all args on the stack from right to left.

You can change this with a command line option, look at -#r or -#s. The # is the target cpu model, 0-6 for 8086 to PPro. The register convention is faster, but incompatible with libraries built with other compilers. It can be overridden in code with pragmas, but it's better to rebuild the library with Watcom, and use the same convention throughout. If I get a chance I'll look into why it's not working as C++. I'm a bit rusty, but I've been using Watcom off and on for over 20 years now, so maybe I can help.

X3J11 wrote:

You can change this with a command line option, look at -#r or -#s.

that only works for 386 and up, -3s, -3r etc. you cant do it with -0 to -2 for 8086/286 code. Since he was targeting -0, you have to do use the -ec# switches.

I'd also recommend a good resource for C programming, in particular game programming by Alex Russell.

http://www3.telus.net/alexander_russell/cours … ntroduction.htm

He programmed one of my favourite games - Spelljammer!

BloodyCactus wrote:

that only works for 386 and up, -3s, -3r etc. you cant do it with -0 to -2 for 8086/286 code. Since he was targeting -0, you have to do use the -ec# switches.

I stand corrected. 20+ years, and I learned something new. 😀. Thanks!

Although, in fairness, I really only used Watcom for its 32-bit compiler. I'm sure I did some real mode stuff back in the day, but I'll be darned if I can remember it.

gerwin wrote:

Are you sure Mode-X is the way to go? It is a hack. It is a planar mode, meaning you can't just write bytes of pixels in a straightforward manner. Many developers at the time decided to stick to mode 13h because of that, because for their projects the overhead of planar drawing negated the benefit.

I think the reason why so many games are mode 13h is mainly because of 2 reasons:
1) Mode 13h is compatible with MCGA, so lowest common denominator.
2) Mode X is unique to the PC, and quite complicated to use. Not a good target for simple ports from other platforms.

gerwin wrote:

VESA fixed it eventually: Paging combined with a proper linear frame buffer.

In theory yes. In practice VESA support was spotty initially, and not many games made use of it at all.
By the time VESA was properly standardized and was ready for mainstream use, there was Windows 95 with DirectDraw, which solved the same problem.

Aside from that, Mode X has some obvious advantages:
1) You can use the full 256k of memory, allowing you to perform scrolling on larger windows, or double-buffering wth page flipping.
2) You can perform efficient fill routines by writing to all 4 bitplanes at a time.
3) You can store sprites or game tiles in offscreen memory for efficient blitting with the ALU

These advantages are basically the same as for EGA.

gerwin wrote:

When I wrote Mode-X is a hack, it is because it was not in the normal list of modes offered by the hardware, and as such it is was not tested like those modes. Some video hardware has quirks with Mode-X, Like I can recognize mode-X on my CL VLB graphics card because it starts to give random blinking pixels. I read some cards do not scroll smoothly. I figure that when Doom got popular, hardware vendors were forced to better prepare for Mode-X and variants. But that is 486-era already.

Wolfenstein 3D also makes use of Mode X, and that was in the 286-era.
I have never seen any VGA card that cannot handle mode X. The scrolling problems are not necessarily related to mode X either. They occur in Commander Keen, which uses EGA mode 0Dh, not mode X. It's to do with timing issues.

keenmaster486 wrote:

I can move forward with this, although I still wish I could do it in C++ instead.

I would advise against using C++ on such low-end systems.
C will create more efficient, compact code, and is easier to interface with libraries and assembly code.

Scali wrote:

Wolfenstein 3D also makes use of Mode X, and that was in the 286-era.
I have never seen any VGA card that cannot handle mode X. The scrolling problems are not necessarily related to mode X either. They occur in Commander Keen, which uses EGA mode 0Dh, not mode X. It's to do with timing issues.

Yeah, Good to know. Lets retract the 'it is a hack part' of my initial reply.

Indeed properly functional VESA was late to arrive. Though I am glad it is available now, and working well on Voodoo 3, Nvidia and later S3 cards.

gerwin wrote:

Are you sure Mode-X is the way to go? It is a hack. It is a planar mode, meaning you can't just write bytes of pixels in a straightforward manner. Many developers at the time decided to stick to mode 13h because of that, because for their projects the overhead of planar drawing negated the benefit.

VESA fixed it eventually: Paging combined with a proper linear frame buffer.

See: Doom in DOS: Original vs Source Ports

Interesting!

Deksor wrote:

This doesn't seem it is mode 0x0D, is it ?

Yes it is.
I also discussed it here shortly:
ATI Graphics Solution

The purple background is scrolled in one bitplane. The blue scroller is in another bitplane (it's just one colour, but the palet […]
Show full quote

The purple background is scrolled in one bitplane.
The blue scroller is in another bitplane (it's just one colour, but the palette is changed per scanline, similar to copper tricks on Amiga).
The remaining two bitplanes are used for the scaling logo and vertical scroller.
This would give you huge headaches in VGA mode.

@Scali

I'm very much intrigued by this. I have done a fair bit of modex and unchained vga programming but never really ventured into the 16 colors modes. In vga unchained the bitplanes are simply presented as laying next to each other making columns of 4 pixels wide each plane holding an 8 bit pixel/color value and I never thought of it being different in the 16 colors modes.

Do you happen to know any programming sources on this specific technique of bitplanes overlaying each other?

pan069 wrote:

Do you happen to know any programming sources on this specific technique of bitplanes overlaying each other?

Not specifically no.
I did cover it somewhat in my blog series, but not too much in-depth I guess:
https://scalibq.wordpress.com/2011/11/23/just … ld-skool-style/

There is a diagram there (actually for the Atari ST, ignore the part about the words stored in screen memory), which should demonstrate the layout:
If you have a pixel of N bits, you split it up in N bitplanes.
Each bitplane is a 1-bit bitmap.
The N bitmaps are then OR'ed together when the pixels are output. This is why they are effectively 'overlaid'.

Because the pixels are split up into separate 1-bit bitmaps/bitplanes, you can selectively update only the bitplanes you're interested in.
So you can write text in a 1-bit font on a single bitplane, while you leave the others untouched. So the other N-1 bits are not overwritten by your text. The text will act as an 'overlay'.

Extra magic can be performed by cleverly choosing your palette.
For example, if you have 16 colours, you can eg divide it into 2*8 colours, where one bitplane selects between the two sets of 8 colours.
So eg you can have 8 normal colours, and then the same 8 colours with a blue-ish hue applied. This means that you can draw a mask into that bitplane to give certain parts a blue hue, to make it look underwater.
Or use a lighter and darker pattern for shadow effects.

Great. Thanks! I'm going to have a bit of a deep dive into this, see if I can wrap my head around this. 😀

pan069 wrote:

Great. Thanks! I'm going to have a bit of a deep dive into this, see if I can wrap my head around this. 😀

The EGA manual may help you to see what you can do with the ALU and the read/write masks:
http://minuszerodegrees.net/oa/OA%20-%20IBM%2 … s%20Adapter.pdf

This page also explains the different write modes for bitplanes, and how the shifter, mask, latches etc work together:
https://wiki.osdev.org/VGA_Hardware

This is somewhat unique to EGA/VGA... all reads/writes on video memory pass through some logic on the video card first, which allows the card to perform rotates, masks and other stuff.
So you cannot actually manipulate the bytes in the EGA's VRAM directly. You are actually reading data into the ALU's latches, and writing the latches back to the bitplanes.
This allows you to manipulate up to 4 bitplanes at a time. Other bitplane-based display systems, such as Atari ST and Amiga, don't have anything like that.

When you actually want to read back the data to the CPU, you can only read from one bitplane at a time of course. But normally that is not something you would ever need to do.

The 1991 donut I made some years ago, is also using EGA mode 0Dh:
https://scalibq.wordpress.com/2013/11/24/just … -like-its-1991/
https://scalibq.wordpress.com/2014/06/08/just … -like-its-1991/
https://scalibq.wordpress.com/2014/08/21/1991 … -final-release/

The poly filler uses the EGA ALU to render many pixels at a time.
It also uses the ALU to render the scroller. You can only address per-byte, which is 8-pixel intervals in mode 0Dh. So I use the ALU to rotate and mask each byte as it is written.
This allows me to rotate and mask the scroller into pixel-perfect position. It scrolls at a speed of 1 pixel per frame, at 60 Hz, so ultra-smooth.

@Scali

So, I did a bunch of reading and I tinkered something together. Inspired by the DoWhackaDo demo I have been trying to figure out how the logo was done (i.e. move behind and in front of the scroller) and I think I might have figured that bit out. It's basically a palette change but I'd love to hear your thoughts on it.

Here is an example. It's super rudimentary, trying to keep it as concise as possible. The only thing in there that I do not fully understand is the how the palette is set. I actually got this code (the load_palette function) from my own archives, I must have written this at least 25 years ago but I added no comments to it, so I have no idea how it actually works. Must have made sense at the time 😀 I've set the palette in mode 13h plenty of times but for some reason I do not yet understand how it works different in mode 0dh. Love your input on that, especially the first bit that sets the attribute index.

Anyhow, this is my code snippet. Use the space bar to switch the white box (substitute for the logo) behind or in front of the blue bars (substitute for the scroller). I refer to the vertical scrollers as "banner".

Also, I have attached an EXE that should work in DosBox.

1#include <conio.h>
2#include <string.h>
3
4#define VGA_INPUT_STATUS          0x3da
5#define VGA_VRETRACE              0x08
6
7#define VGA_SEQUENCER_INDEX       0x3c4
8#define VGA_MAP_MASK              0x02
9
10#define VGA_ATTRIBUTE_INDEX       0x3c0
11
12#define VGA_PALETTE_INDEX         0x3c8
13#define VGA_PALETTE_DATA          0x3c9
14
15#define VGA_CRT_INDEX             0x3d4
16#define VGA_CRT_DATA              0x3d5
17
18#define VGA_ADDRESS_HIGH          0x0c
19#define VGA_ADDRESS_LOW           0x0d
20
21#define SCREEN_WIDTH              320
22#define SCREEN_HEIGHT             200
23
24#define PLANE_0                   0x01
25#define PLANE_1                   0x02
26#define PLANE_2                   0x04
27#define PLANE_3                   0x08
28
29#define TILE_SIZE                 10
30
31#define KEY_ENTER                 0x0d
32#define KEY_SPACE                 0x20
33
34#ifndef FP_SEG
35#define FP_SEG(__p) ((unsigned)((unsigned long)(void __far*)(__p) >> 16))
36#endif
37
38#ifndef FP_OFF
39#define FP_OFF(__p) ((unsigned)(__p))
40#endif
41
42#ifndef MK_FP
43#define MK_FP(__s,__o) (((unsigned short)(__s)):>((void __near *)(__o)))
44#endif
45
46typedef struct {
47  char r;
48  char g;
49  char b;
50}
51RGB;
52
53RGB palette1[16] = {
54  {0x00 >> 2, 0x00 >> 2, 0x00 >> 2}, // 0000 - 
55  {0xff >> 2, 0x00 >> 2, 0x00 >> 2}, // 0001 - background
56
57  {0x00 >> 2, 0xff >> 2, 0x00 >> 2}, // 0010 - banner
58  {0x00 >> 2, 0xff >> 2, 0x00 >> 2}, // 0011 - banner
59
60  {0x00 >> 2, 0x00 >> 2, 0xff >> 2}, // 0100 - scroller

61  {0x00 >> 2, 0x00 >> 2, 0xff >> 2}, // 0101 - scroller
62  {0x00 >> 2, 0x00 >> 2, 0xff >> 2}, // 0110 - scroller
63  {0x00 >> 2, 0x00 >> 2, 0xff >> 2}, // 0111 - scroller
64
65  {0xff >> 2, 0xff >> 2, 0xff >> 2}, // 1000 - logo
66  {0xff >> 2, 0xff >> 2, 0xff >> 2}, // 1001 - logo
67
68  // Logo before scroller
69  {0xff >> 2, 0xff >> 2, 0xff >> 2}, // 1010 - logo
70  {0xff >> 2, 0xff >> 2, 0xff >> 2}, // 1011 - logo
71  {0xff >> 2, 0xff >> 2, 0xff >> 2}, // 1100 - logo (before scroller)
72  {0xff >> 2, 0xff >> 2, 0xff >> 2}, // 1101 - logo (before scroller)
73  {0xff >> 2, 0xff >> 2, 0xff >> 2}, // 1110 - logo (before scroller)
74  {0xff >> 2, 0xff >> 2, 0xff >> 2}, // 1111 - logo (before scroller)
75};
76
77RGB palette2[16] = {
78  {0x00 >> 2, 0x00 >> 2, 0x00 >> 2}, // 0000 - 
79  {0xff >> 2, 0x00 >> 2, 0x00 >> 2}, // 0001 - background
80
81  {0x00 >> 2, 0xff >> 2, 0x00 >> 2}, // 0010 - banner
82  {0x00 >> 2, 0xff >> 2, 0x00 >> 2}, // 0011 - banner
83
84  {0x00 >> 2, 0x00 >> 2, 0xff >> 2}, // 0100 - scroller
85  {0x00 >> 2, 0x00 >> 2, 0xff >> 2}, // 0101 - scroller
86  {0x00 >> 2, 0x00 >> 2, 0xff >> 2}, // 0110 - scroller
87  {0x00 >> 2, 0x00 >> 2, 0xff >> 2}, // 0111 - scroller
88
89  {0xff >> 2, 0xff >> 2, 0xff >> 2}, // 1000 - logo
90  {0xff >> 2, 0xff >> 2, 0xff >> 2}, // 1001 - logo
91
92  // Logo behind scroller
93  {0xff >> 2, 0xff >> 2, 0xff >> 2}, // 1010 - logo
94  {0xff >> 2, 0xff >> 2, 0xff >> 2}, // 1011 - logo
95  {0x00 >> 2, 0x00 >> 2, 0xff >> 2}, // 1100 - logo (behind scroller)
96  {0x00 >> 2, 0x00 >> 2, 0xff >> 2}, // 1101 - logo (behind scroller)
97  {0x00 >> 2, 0x00 >> 2, 0xff >> 2}, // 1110 - logo (behind scroller)
98  {0x00 >> 2, 0x00 >> 2, 0xff >> 2}, // 1111 - logo (behind scroller) 
99};
100
101unsigned char far *_video_mem = (unsigned char far*)0xA0000000L;
102
103void set_mode(unsigned short mode)
104{
105  _asm {
106    mov ax,mode
107    int 0x10
108  }
109}
110
111void load_palette(RGB *palette, int colors)
112{
113  unsigned short pal_seg = FP_SEG(palette);
114  unsigned short pal_off = FP_OFF(palette);
115  unsigned short len = colors * 3;
116
117  _asm {
118    xor     bl,bl
119  pal_loop:
120    mov     dx,VGA_INPUT_STATUS
121    in      al,dx
122
123    mov     dx,VGA_ATTRIBUTE_INDEX
124    mov     al,bl
125    out     dx,al
126    out     dx,al
127
128    inc     bl
129    cmp     bl,10h
130    jb      pal_loop
131
132    mov     dx,VGA_ATTRIBUTE_INDEX
133    mov     al,20h
134    out     dx,al
135
136    // Select color zero and write the palette data.
137
138    mov     dx,VGA_PALETTE_INDEX
139    xor     al,al
140    out     dx,al
141
142    mov     ax,pal_seg
143    mov     ds,ax
144    mov     si,pal_off
145    mov     cx,len
146
147    inc     dx
148    rep     outsb
149  }
150}
151
152void select_plane(unsigned short plane)
153{
154  outpw(VGA_SEQUENCER_INDEX, (plane << 8) + VGA_MAP_MASK);
155}
156
157void draw_rect(int x, int y, int width, int height, unsigned char pattern)
158{
159  int i;
160  int w = width >> 3;
161
162  char *video = _video_mem + (y * (SCREEN_WIDTH / 8)) + (x >> 3);
163
164  for (i = y; i < y + height; i++) {
165    memset(video, pattern, w);
166
167    video += SCREEN_WIDTH / 8;
168  }
169}
170
171void draw_background()
172{
173  int r, x, y;
174  unsigned char color;
175
176  select_plane(PLANE_0);
177
178  for (r = 0; r < SCREEN_HEIGHT / TILE_SIZE; r++) {
179    color = r % 2;
180
181    for (y = 0; y < TILE_SIZE; y++) {
182      for (x = 0; x < SCREEN_WIDTH / 8; x += 2) {
183        if (color) {
184          int o = (r * TILE_SIZE + y) * (SCREEN_WIDTH / 8) + x;
185
186          _video_mem[o + 0] = 0xff;
187          _video_mem[o + 1] = 0xff;
188        }
189
190        color ^= 1;
191      }
192    }
193  }
194}
195
196void draw_banner()
197{
198  select_plane(PLANE_1);
199
200  draw_rect(                8, 0, 32, SCREEN_HEIGHT, 0xff);
201  draw_rect(SCREEN_WIDTH - 40, 0, 32, SCREEN_HEIGHT, 0xff);
202}
203
204void draw_scroller()
205{
206  select_plane(PLANE_2);
207
208  draw_rect(0,  64, SCREEN_WIDTH, 24, 0xff);
209  draw_rect(0, 112, SCREEN_WIDTH, 24, 0xff);
210}
211
212void draw_logo()
213{
214  select_plane(PLANE_3);
215
216  draw_rect(96, 48, 128, 104, 0xff);
217
218}
219
220void main()
221{
222  int pal = 0;
223
224  set_mode(0x0d);
225
226  load_palette(&palette1, sizeof(palette1) / sizeof(RGB));
227
228  draw_background();
229  draw_banner();
230  draw_scroller();
231  draw_logo(); 
232
233  while(1) {
234    if (kbhit()) {
235      int key = getch();
236
237      if (key == 27) {
238        break;
239      }
240
241      switch (key) {
242      case KEY_SPACE:
243        pal ^= 1;
244
245        if (pal == 0) {
246          load_palette(&palette1, sizeof(palette1) / sizeof(RGB));
247        }
248        else {
249          load_palette(&palette2, sizeof(palette2) / sizeof(RGB));
250        }
251
252        break;
253      }
254    }
255  }
256
257  set_mode(0x03);
258}

Just managed to answer my own question regarding the palette code:

From Programmers Guide to the EGA/VGA and SuperVGA cards by Richard F. Ferraro:

8.1.5 Accessing the Palette Registers […]
Show full quote

8.1.5 Accessing the Palette Registers

The Palette Registers are contained in a dual-ported memory. The display memory requires access to the Palette Registers in order to refresh the display. The host requires access to the Palette Registers during read or write operations. The process of accessing the dual-ported Palette Registers is illustrated in Figure 8.8.

This dual-ported memory is accessed through a host port register at host I/O address 3C0. This port has two different functions. One is to index the Palette Registers. In this mode, it is called the Attribute Address Register. A second is to act as a portal to the Palette Registers. In this mode, it may be thought of as a data register, similar to the data registers of the other EGA/VGA register groups.

An internal hardware flip-flop is used that multiplexes this port to load either this Attribute Address Register or one of the Attribute Registers. When the flip-flop is in the clear state, data output from the host to port 3C0 hex is directed to this Attribute Address Register. When the flip-flop is in the set state, data written to this port is directed to whichever Attribute Register index is loaded into the ADR field of this register.

The flip-flop is controlled indirectly by the host. When a host assembly language input port instruction, IN, is issued to the Input Status #1 Register, the flip-flop is cleared. This register resides at port address 3BA hex for monochrome implementations or port addresses 3DA hex for color implementations. Once the flip-flop is cleared, the path is set so that outputs to this 3C0 hex port load an index that points to one of the Attribute Registers. This is equivalent to loading any of the other Address Registers. The next assembly language output port instruction written to this 3C0 hex port (OUT) will load the indexed Attribute Register. After the output occurs, the flip-flop automatically changes state. The following output will be directed once again to the Attribute Address Register.

pan069 wrote:

So, I did a bunch of reading and I tinkered something together. Inspired by the DoWhackaDo demo I have been trying to figure out how the logo was done (i.e. move behind and in front of the scroller) and I think I might have figured that bit out. It's basically a palette change but I'd love to hear your thoughts on it.

Yup, that's probably how they did it.
As said, bitplanes are combined with a logical or-combination.
So if put your background scroller on bitplane 0, that will be value 0x1
Then you put your logo on bitplane 1, that will be value 0x2

Each pixel will then be (background OR logo).
So you get three possible values:
0x1: background only
0x2: logo only
0x3: background + logo

Which means you have various options to choose colour 0x3 in your palette:
Set it to the same colour as 0x1, and the logo will be behind the background
Set it to the same colour as 0x2, and the logo will be in front of the background
Set it to a colour that is a combination of logo and background, and you create a sort of translucent effect

And some people say bitplanes are useless!

pan069 wrote:

Here is an example. It's super rudimentary, trying to keep it as concise as possible. The only thing in there that I do not fully understand is the how the palette is set. I actually got this code (the load_palette function) from my own archives, I must have written this at least 25 years ago but I added no comments to it, so I have no idea how it actually works. Must have made sense at the time 😀 I've set the palette in mode 13h plenty of times but for some reason I do not yet understand how it works different in mode 0dh. Love your input on that, especially the first bit that sets the attribute index.

I'd like to remark that palettes are a bit of a mess on PC.
That is, CGA has its own palette registers, EGA has its own palette registers and VGA has its own palette registers.

In the case of DoWhackaDo, the video mode may be EGA, but the palette used is VGA. The same goes for my 1991 Donut for example, and a game like F29 Retaliator.

The way VGA is implemented is that the legacy palettes are logically mapped to the VGA palette.
That is, CGA has 16 colours in total, which are mapped to the first 16 colours in the VGA palette.
They match the CGA colours by default. However, if you modify the VGA palette after setting a CGA mode, you basically just use the CGA memory and palette layout, with your own pick of 18-bit VGA colours.

The same goes for EGA, alhough it is a bit more complicated. That is, where CGA's colours are hardwired (except for the background colour), EGA has its own 16-colour palette, where you can choose from a total of 64 (a 2:2:2 RGB format). Again, these colours are mapped onto the VGA palette.
So with the EGA palette, you can reorder colours if you like. But I wouldn't recommend it. The VGA palette is easier to manipulate, and if you use the extra VGA colours anyway, there's no reason to bother with both palettes.

One thing that's unique to the EGA palette, is that you have to disable and re-enable it before an update works (something that emulators generally do not enforce, so a nice case where people coding for emulators will get code that breaks on real hardware). That's another reason not to use the EGA palette: it's too cumbersome. VGA palette can be set on-the-fly, without having to worry about re-enabling it.