When I booted the KQ1 Tandy booter while machine=pcjr, it worked in a normal speed, just like it does when machin=tandy.

Because the PCjr is a slow machine. The Tandy version of KQ1 added a frame limiter.

What's the technical difference between Tandy and PCjr anyway?

PCjr mirrors the video memory at segment 1800, Tandy doesn't (or at some other location).

they probably linked to this log
http://cvs.sourceforge.net/viewcvs.py/dosbox/ … EAD&view=markup

Nothing special about it.

1) games expect a fixed-speed computer mostly
2) because the pcjr-booter writes at the 1800 segment, which is a
non-video segment on the PCJr
3) doesn't do much harm
4) those dos versions are not compatible with the PCJr (writes
happily over the 1800 segment
5) is that important??

> PCjr mirrors the video memory at segment 1800, Tandy doesn't (or at
> some other location).

Tandy has it at the top of the conventional RAM.
Some more differences: the layout of the graphcis ports is not the same as
on Tandys, the whole keyboard handling is different, several bios functions
(graphics bios) have different specs, some IRQs are swapped for whatever
reason etc.

Thank you all for the information. Very interesting. I was always curious about the PCjr, I mean, an IBM PC that supports cartridge games (and possibly even analog cassette games?!?), that's just odd! And weirder than that, some of the PCjr's didn't even have a floppy drive, so the only way to run games on them would be to use the cartridge slots (why were two slots needed??), which means they couldn't run the main game for this machine, which was KQ1 of course, since it was too big to fit on a 64KB cartridge.

wd wrote:

3) doesn't do much harm

Of course it doesn't. However, if a real PCjr couldn't support this card, than it should be considered to remove it. But it is quite meaningless, I must admit.

wd wrote:

4) those dos versions are not compatible with the PCJr (writes
happily over the 1800 segment

Oh I see. MS-DOS 3.30 does work though.

wd wrote:

5) is that important??

Well, no, obviously. I was just wondering what's the explanation of this phenomenon.

Another thing - why does Maniac Mansion and Zak McKracken (old and new versions) run with CGA graphics when machine=pcjr? Aren't they supposed to run with Tandy graphics? (it would make sense since, for example, the Tandy booter of KQ1 works with the correct graphics when machine=pcjr)
By the way, it's really great to see that the aspect ratio of Maniac and Zak when machine=tandy is now correct.

How can you boot the cartridge images, if there is a way?

> How can you boot the cartridge images, if there is a way?

Hehe, the answer lies in your question 😉 (the "boot" part).
Should be noticed somewhere though, you're right.

> Aren't they supposed to run with Tandy graphics?

Don't have those games, but most likely they only have a tandy-detection
and no pcjr-detection, thus use CGA on the pcjr.

The boot command doesn't seem to work for *.jrc cartridge images, what am I doing wrong?

I tried Maniac Mansion on a real PCjr and it came up in CGA 4-color mode; so yeah, for whatever reason that game doesn't detect the PCjr as supporting 16 colors.

I've gotten a few .jrc games to work correctly with DosBox, but others just crash; I'm guessing there's still some incomplete emulation or a few bugs to work out...

@Great Hierophant: You have to use a recent CVS version, as it was only recently added/activated in there. You should be able to set machine=pcjr and boot a .JRC image file. Don't forget to mount the directory containing your images first!

Regards,
Ronald

> I've gotten a few .jrc games to work correctly with DosBox, but others just
> crash; I'm guessing there's still some incomplete emulation or a few bugs
> to work out...

Well i only have a tiny number of games, so there might be a lot of
flaws yet. Another problem is the memory handling, some games
expect the original 64/128k configuration and don't work otherwise,
some need a lot of memory and don't start otherwise. Most of them
are working because the .com-loading in dosbox is a bit different when
machine=pcjr (so it looks like an 128k pcjr), but some don't.

I'm blown away by this thread .. a Jr emulator!

One question about the emulation - the VGA chip (Video Gate Array) maps references from B800:0000 down to a window in the first 128K of RAM. The window can actually move - device drivers like PCJRMEM or JRCONFIG move it. Does the emulator handle this correctly?

Second - on the speed. Access to the first 128K of memory was a tug-of-war between the CPU and the VGA chip, and the VGA chip always won. Which is why the Jr feels slow compared to a 4.77Mhz PC when running in that first 128K. Does KQ feel too fast because the emulator isn't emulating the shared memory design?

Need help? I'm kind of an expert. :-)

> The window can actually move

Yeps, the window is movable (some of the graphics ports specify the window position).

>Access to the first 128K of memory was a tug-of-war between the CPU and the VGA chip

There's no slowdown implemented in dosbox for this, but setting the
cycles quite low (500 or below on my PC) should get the speed of
the games at least near something playable 😀

> Need help? I'm kind of an expert. 😀

One thing i'd really like to know: how did DOS handle the
graphics memory in the lower memory? Especially the differences
between 64/128k systems and those with expansion cards (up to
640k). Currently this is handled in an odd way in dosbox to
support as many games as possible, as some need a lot of memory
(must be loaded into memory above 128k) and some have to be
loaded into memory below 128k (and explicitly checks for this).

Re: Speed of the first 128K

Remember the first 128K of memory is slower than any other memory because of the VGA access. So using a constant like 500 might average things out enough to be usable, but it's not going to be perfect. Perfect is actually close to impossible without knowing the memory setup .. the machine doesn't use DMA to refresh memory (because it doesn't have DMA onboard), so memory refresh is handled by each memory expansion card. Four 128K expansion cards will have four different refresh cycles, compared to one expansion card that just has 512K on it. (Another fun PCjr oddity, but that really only matters if you are crazy enough to do a cycle accurate simulator.)

Re: Memory handling.

On a vanilla system running DOS 2.1 the Jr locates the video memory as high as possible. By default that is at location 1C00:0000, which is the top 16K of memory. The BIOS will count 128K on the machine, and then tell DOS that there is only 112K available. DOS loads in the usual place in lower memory after the interrupt vectors and BIOS data areas.

If a user should make a BIOS call to increase the size of video memory from 16K to 32K (or more), the BIOS grows the memory window downward. So for a 32K buffer the memory window starts at 1800:0000. And for a 48K or 64K buffer, it keeps heading downwards. I think the most that Cartridge BASIC will allow a user to allocate is 32K, although you could do more outside of BASIC. Of course if you go too far, you start overlaying DOS and the interrupt area. Not too swift to do that ..

On an expanded machine with no device drivers the scheme is the same - BIOS will test and count up to 640K, but will lie to DOS and tell it that only 112K is available. The other memory is 'up there' on the other side of the video buffer, but DOS won't touch it.

To make a Jr usable with extra memory you need one of the device drivers. Here is where the magic comes in. The device drivers know where BIOS keeps the real memory count. (It's documented in the tech ref). The device drivers will make the calls to the BIOS or VGA chip (can't remember which - probably VGA chip directly) to move the video memory as low as possible, reserving either 16K or 32K (or whatever the user asks) for video memory. Then the device driver lies to DOS and says that memory is occupied by the device driver, forcing DOS to load above it. The device driver also alters the BIOS area where the total amount of RAM reported to DOS is stored, and sets it to the real top of memory. DOS loads higher than usual, skipping over the video buffer, and sees all of the memory.

And even better .. if you lie to DOS and tell it the first 128K is in use, DOS will load in the faster memory. And your programs will too. The customary thing to do is to reserve 16K or 32K of video memory, and use whatever is left over in the bottom 128K for a ram disk.

Forgot a few details ...

On a 64K system the setup is similar, except that the top of memory is reported to BASIC as 48K. Also, you are not allowed to grow the video buffer at all ... the special PCjr modes are not available without a 128K system. And worse, DOS 2.1 won't run on that machine. I haven't tried it, but I'll bet that it looks for a 128K machine and barfs if it doesn't find it. (An older DOS version is designed to work on smaller machines, but those versions have other problems on a Jr.)

Another thing about 64K vs. 128K machines - the VGA chip uses the two banks in parallel to get the throughput it needs to drive the video. Which is why the extended modes are not available on the 64K machines.

A 64K Jr is basically useless except for BASIC and cartridge games.

> using a constant like 500 might average things out enough to be usable,
> but it's not going to be perfect

Yes, but that's far from what dosbox tries to achieve.
The cycles are only a rough estimate and are not bound
to the cycles per instruction of a real CPU, so this'd
be hard to implement anyways.

Thank you for your detailed explanation of the memory
system, i think i got it pretty much like that of an
expanded system 😀
Yet i got a game (some Jumpman dos port, not the one
from the Jumpman Project) that checks if cs<0x2000 and
doesn't run otherwise. As far as i understood this'd
only work on a 128k system, not on an expanded one as
there DOS would load the executable above the graphics
region at 0x2000?

Yes, but that's far from what dosbox tries to achieve. The cycles are only a rough estimate and are not bound to the cycles per […]
Show full quote

Yes, but that's far from what dosbox tries to achieve.
The cycles are only a rough estimate and are not bound
to the cycles per instruction of a real CPU, so this'd
be hard to implement anyways.

Yep - I have to remember that this is an emulator, not a simulator. Simulators can be cycle accurate, but then it probably wouldn't be runnable on a common machine.

If the machine is looking to see if CS is in the first 128K then they are making an assumption that somebody didn't add a device driver to handle extra memory. Seems like an anti-social thing to do. On an PC with a RAM disk that would be a problem too.

I'm going to read all of the FAQs and try to build this .. I have enough of the real thing floating around, but emulators are useful too. (My laptop is far more portable than a PCjr & monitor combo).

Great work!

You can get one of the prebuilt dosbox CVS versions from
DOSBox SVN Builds
(windows/linux) for lazyness reasons 😀