video segment: where is it?

[riq]

Hi,

I'm porting a program I did for the Tandy (video mode 320x200 x 16colors) to the PCJr.
Since it uses 32k of video ram, I cannot use b800, since the PCJr only maps 16k (is this correct?).

So, I installed jrconfig.sys with `/v32` and when it boots it says that the video segment is at 0x1800.
Does it mean that I should write my graphics to 1800:0000 (instead of b800:0000). should it work like in the Tandy now ?

Is there a way to know in runtime where the gfx segment is? I noticed if I used `/v64` the segment will be at 0x1000 instead (which kind of makes sense).

Also, I noticed that if I use BIOS call:
mov ah,0x9
int 0x10 ; write char

when in 320x200 x 16 colors mode, I see nothing (regardless of where is the video segment).
Is this the expected behavior? should I change something in jrconfig.sys ?

Is there anything that I'm missing?

Thanks!

[riq]

self:

So, yes, I've just did a smaller test and it works Ok writing directly to 0x1800:0000... but only for 32k video modes... didn't work for 16k video modes.
And BIOS calls works Ok.
At least tested with jrconfig.sys /v32

I must be doing something wrong on my "big test".


Question still un-answered:
is there a way to detect the video segment in runtime?
does jrconfig.sys provides an API for this? (and is there a way to detect that jrconfig.sys is installed?)

Thanks!

[Brutman]

B800:0000 is always an alias to somewhere in the first 128K of RAM. By default (no device drivers) it lands at 1C00:0000 when using a 16K buffer.

I can't remember the location for a 32K buffer off the top of my head but it needs to be in the VGA registers because it is programmable. The technical reference has all of the details in section 2, including how the pixels land in memory for the different video modes.

[riq]

The technical reference has all of the details in section 2, including how the pixels land in memory for the different video modes.

Thanks! I'll read it.

[riq]

a ha!

PCJr:

The Video Gate Array is located at I/O address hex 3DA, and is programmed by first writing a register address to port hex 3DA and then writing the data to port hex 3DA

Tandy 1000:

The following registers can be accessed by writing their Hex Address to 3DA and their Data to 3DE

That explains why nothing works when porting my Tandy 1000 code to PCJr.

[Trixter]

Just a quick note that the VGA page registers give you the freedom to do anything you want, so you can use B800 as a window to any 16KB page in the first 128KB of RAM. You can also set whether that window accesses a visible page or a hidden page.

Of course, they also let you access any 16KB page in the first 128KB, which means if you set it wrong, you'll stomp all over DOS, the interrupt vector table, etc. so you need to be careful. Also, there's no way to tell how much video memory the user set aside with jrconfig.sys (ie. there's no way to tell if the user specified /v16, /v32, or /v64) so you'll just have to assume your pages begin at 128KB-16KB, 128KB-32KB, or 128KB-64KB respectively and hope the user configured config.sys how you asked them to.

It is ok to request the user specify /v64 so that you get two 320x200x16 graphics screens, one visible, one hidden. Any PCjr you come across these days is likely to be upgraded to the full 640KB and burning an additional 32KB of RAM is not going to make or break your application.

[riq]

It is ok to request the user specify /v64 so that you get two 320x200x16 graphics screens, one visible, one hidden.

Thanks. double-buffer, yay!


Re. Tandy vs. PCJr., I found more differences:

* Does the PCJr have horizontal retrace? I couldn't find it in the documentation.
* 0x3da mode control 0 is on "reg 0" on PCJr. and on "reg 3" on Tandy.
* 0x3da on PCJr has 2 additional modes: "mode control 2" and "reset"
* similar to the original Tandy 1000 (not the HX), changing the palette disables video... an "out 0x3da,0" is needed to re-enable it.
* documentation says PCJr has the keyboard on the NMI... is the NMI hooked directly to Int 0x9?

and... is there a PCJr. emulator? dosbox-x seems to support Tandy very good, but very bad for PCJr.


Thanks!

[riq]

self answer:

* Does the PCJr have horizontal retrace? I couldn't find it in the documentation.

Apparently 0x3da bit 0 works as horizontal retrace... but for some reason, sometimes hangs in part of my code (should double why)

* documentation says PCJr has the keyboard on the NMI... is the NMI hooked directly to Int 0x9?

NMI (int 2) handles the IR code, then calls int 0x48 which places the data in the keyboard buffer (40:1e)
Not sure if/when int 9 gets called. I guess when the keyboard is connected with a cable.

and... is there a PCJr. emulator? dosbox-x seems to support Tandy very good, but very bad for PCJr.

shame on me... I was using doxbox with "machine=tandy" instead of "machine=pcjr".
I seems that the pcjr emulation is not as complete as the tandy emulation but works for me.

[Trixter]

NMI (int 2) handles the IR code, then calls int 0x48 which places the data in the keyboard buffer (40:1e)
Not sure if/when int 9 gets called. I guess when the keyboard is connected with a cable.

Int9 is emulated by the NMI. It functions normally as it would on a PC, but the NMI is responsible for doing the work, not the keyboard controller (as there is no keyboard controller on a PCjr).

I seems that the pcjr emulation is not as complete as the tandy emulation but works for me.

It's good enough for testing. I'm not sure it supports everything 100%, like the 160x100 video mode I invented, but it should work for basic purposes.

As for changing the pallette, you wrote "changing the palette disables video" -- Yes, this was an unwelcome surprise when I was writing introJR. Here's my code for doing raster bars on PCjr:

Code: Select all

{$IFDEF PCJR}
procedure DoCopper(coplist:coplisttype); assembler;
asm
  push    ds
  push    bp
  cld
  mov     dx,m6845_status;
  mov     cx,coppersize {number of lines to set}
  lds     si,coplist
  xor     ax,ax
  mov     bh,c_display_enable
  mov     ah,bh           {so that when we xchg, BH will stay same}
  mov     bp,ax           {so that we have an AL=0 ready later}
  cli              {shut off interrupts (entering time-critical part)}
@loop:
  xchg    bp,ax    {put things back}
  lodsb            {load our color from the list of scanline colors}
  mov     di,ax    {save it for right when we need it}
  mov     bl,$10   {palette index 0 select, we'll need this too}
@w:
  in      al,dx
  test    al,bh
  jnz     @w       {loop if in horizontal retrace (just in case we're already in the middle of it}
@r:
  in      al,dx
  test    al,bh
  jz      @r       {loop if NOT in horizontal retrace -- when loop ends, we are in horizontal retrace}
  xchg    bx,ax    {select palette index to change...}
  out     dx,al    {tell VGA changing an index}
  xchg    di,ax    {get our color back into al...}
  out     dx,al    {...so we can change the color}
  xchg    bp,ax    {set val 0; need to reset VGA or else we see garbage}
  out     dx,al    {reset it}
(*
  in      al,dx    {reset VGA to home state}
  disabled, takes too long, will do at end of routine since we have control
*)
  loop    @loop    {loop for the rest of the scanlines}

  in      al,dx    {reset VGA to home state}
  sti              {done with critical part}
  pop     bp
  pop     ds
end;
{$ENDIF}



[riq]

It's good enough for testing. I'm not sure it supports everything 100%, like the 160x100 video mode I invented, but it should work for basic purposes.

Interesting. Did you document the video mode that you discovered somewhere? I would like to try it in the future.

As for changing the pallette, you wrote "changing the palette disables video" -- Yes, this was an unwelcome surprise when I was writing introJR. Here's my code for doing raster bars on PCjr:

Thanks. I'm doing something similar (here: https://github.com/c64scene-ar/tandy64/ ... o.asm#L302).
but for some reason my code is hanging the machine so I should double-check it compare it with yours.

Thanks!