VOGONS


Question about code and PCjr and svga_s3

Topic actions

  • This topic is locked. You cannot reply or edit posts.

First post, by Greenchili

User metadata
Rank Newbie
Rank
Newbie

Been working on updating some dosbox code and I'm having a weird issue where games run to fast when setting the machine type to PCJR.

I'm currently updating from some post v0.74 code where the small TLB code was re-worked. I don't have the exact revision number on me at the moment.

Does anyone know which source files are most likely to affect the speed when running in PCJR mode?

My second question is related to the svga_s3.cpp code. I noticed it can handle memory configurations of 512k, 1m, 2m, and 4m? I'm just wondering what, if any, advantages using the higher memory configs provide or if using a lower amount (like 512k) will affect any games in any particular fashion?

Thanks

Reply 1 of 30, by ripsaw8080

User metadata
Rank DOSBox Author
Rank
DOSBox Author

I'm having a weird issue where games run to fast when setting the machine type to PCJR.

You mean too fast compared to other machine types at the same amount of cycles? The PCjr's 4.77 MHz 8088 dedicates every 4th clock cycle to RAM refresh, so the effective CPU speed is around three-fourths of the rated speed. Many games that have specific support for PCjr use shorter timing loops to compensate for its slower speed; however, DOSBox doesn't emulate the RAM refresh, so you have to reduce the amount of cycles for those games. DOSBox counts instructions, not clock cycles, so the three-fourths doesn't correspond exactly, but you can use it as a starting point.

I'm just wondering what, if any, advantages using the higher memory configs provide

Well, there's the obvious: more pages and higher resolutions with higher color depths.

Reply 2 of 30, by Greenchili

User metadata
Rank Newbie
Rank
Newbie

ok. Thanks for the response. I suspected that was the case regarding the s3 memory configs. It has just been a long time and I kinda forget some of these things. It's been years since I messed with old DOS games and my S3 video cards.

As for the PCJR. It was too fast relative to the speed these games ran before I updated the code. So I think I missed something somewhere. But thanks for the tech info.. maybe that will be enough for me to figure out where to look. Unless someone else has some suggestions.

The two games I've been testing in PCJR mode are "Ghost Busters" and "Pitfall II".

Edit:

ok.. I think I might know what it is. But I will not be able to test for a few hours. More info later.

Reply 3 of 30, by Scali

User metadata
Rank l33t
Rank
l33t
ripsaw8080 wrote:

The PCjr's 4.77 MHz 8088 dedicates every 4th clock cycle to RAM refresh

That's not entirely correct.
The PCjr shares its first 128 KB between the CPU and the graphics chip. Like with CGA memory, the video output circuitry will constantly read bytes for output to the monitor. This means that there are waitstates when the CPU wants to access the videomemory: it can only access the memory on cycles where the video output is not reading memory.
Since on PCjr the system memory *is* the videomemory, these waitstates apply on all memory accesses, including executing any code (the same would happen on a normal PC if you placed code in CGA memory and jumped to it).

Because of the memory accesses, the memory also gets refreshed automatically, but that is a side-effect rather than the reason.

http://scalibq.wordpress.com/just-keeping-it- … ro-programming/

Reply 4 of 30, by ripsaw8080

User metadata
Rank DOSBox Author
Rank
DOSBox Author

Perhaps you'd like to correct the Wikipedia article for the PCjr to reflect your view on the matter:
http://en.wikipedia.org/wiki/IBM_PCjr

The PCjr's 4.77 MHz Intel 8088 CPU is faster than that of other computers that were aimed at the home market at the time, though the PCjr does not run at the full rated 4.77 MHz because every 4th clock cycle of the 8088 CPU is designated to refresh the PCjr's dynamic RAM as it has no dedicated memory controller; the computer's effective clockspeed is therefore 3.58 MHz.

Reply 5 of 30, by Scali

User metadata
Rank l33t
Rank
l33t
ripsaw8080 wrote:

Perhaps you'd like to correct the Wikipedia article for the PCjr to reflect your view on the matter:

Nah, wikipedia is pointless. Someone else won't agree, and will just undo your edits again.

http://scalibq.wordpress.com/just-keeping-it- … ro-programming/

Reply 7 of 30, by mbbrutman

User metadata
Rank Member
Rank
Member
Scali wrote:

Because of the memory accesses, the memory also gets refreshed automatically, but that is a side-effect rather than the reason.

It is more than a side-effect. The PCjr does not have a DMA channel to use like the PC does so it can not use DMA to force memory refreshing. The video circuitry is specifically designed to provide the refresh capability, allowing the PCjr to do without both DMA and dedicated DRAM controllers.

(Which is also why sidecars that use DRAM provide their own DRAM controllers.)

Reply 8 of 30, by Scali

User metadata
Rank l33t
Rank
l33t
mbbrutman wrote:

It is more than a side-effect. The PCjr does not have a DMA channel to use like the PC does so it can not use DMA to force memory refreshing. The video circuitry is specifically designed to provide the refresh capability, allowing the PCjr to do without both DMA and dedicated DRAM controllers.

Yes, and it's the same for the majority of home computers out there.
The PC is the exception to the rule with its DMA refresh, not the PCjr (it mostly uses off-the-shelf parts... the chip responsible for the refresh is the Motorola 6845, which is not specific to the PCjr, and can be found in various other home computers, such as the C128 and the Amstrad CPC, and also on MDA, CGA and Hercules cards).
Doesn't change the fact that refreshing memory is a side-effect of accessing memory.

http://scalibq.wordpress.com/just-keeping-it- … ro-programming/

Reply 10 of 30, by Scali

User metadata
Rank l33t
Rank
l33t
mbbrutman wrote:

Not to be overly pedantic here, but you called it a side-effect. In the case of the PCjr it was explicitly taken advantage of; that is not a side-effect. That makes it a design feature.

Taking advantage of a side-effect doesn't make the side-effect any less of a side-effect.

Anyway, two can play the pedantic game:
The claim here was that the memory wait states were because of the refresh:
"The PCjr's 4.77 MHz 8088 dedicates every 4th clock cycle to RAM refresh"
Which is not true. You don't need to refresh the memory that often anyway. Besides, it's not the 8088 that does the refresh, it's the 6845, as I said earlier.

Also, calling something a "design feature"...? Firstly, as I say, if you want to call this a design feature at all, it is a design feature of the 6845. Which is not specifically designed for the PCjr. It is just designed like that because there's really no other way. What are you going to do? Put some refresh circuitry on there, which will randomly steal cycles, so that you will randomly not be able to read words for output to the display?
That's not going to work, so ALL display controllers are designed in a way that their memory access patterns will refresh all video memory. Not really a 'feature', but rather a necessity.

By extension, if you also use this memory for other things than graphics, as most home computers do, there will not be any special refresh required for that memory. Since this was par for the course, I don't agree with you saying it was "explicitly taken advantage of".
No, sharing video memory and system memory is just the simplest and cheapest way to design a system. It can also have various advantages (especially the Amiga exploits this to the fullest, by being able to create screens of arbitrary sizes, in arbitrary places in memory, allowing fast scrolling, blitting and other trickery).
It's just what people did in the 70s/80s. The PC is the exception to the rule, and suffered from it greatly during the 80s, with its subpar graphics performance and capabilities.

http://scalibq.wordpress.com/just-keeping-it- … ro-programming/

Reply 11 of 30, by mbbrutman

User metadata
Rank Member
Rank
Member

You are entitled to your opinion.

I have been a PCjr owner for 30+ years and I worked at IBM for nearly twenty years. I've spoken to more than a handful of the team that worked on it. I've seen the internal chatter on the machine from back when it was new. And I'm telling you that your interpretation of the refresh as a side effect was wrong; it was a design feature for the machine.

You can keep believing what you want. I think my sources are better.

Reply 12 of 30, by Scali

User metadata
Rank l33t
Rank
l33t
mbbrutman wrote:

You are entitled to your opinion.

It's not an opinion, it's all based on facts.

mbbrutman wrote:

I have been a PCjr owner for 30+ years and I worked at IBM for nearly twenty years. I've spoken to more than a handful of the team that worked on it. I've seen the internal chatter on the machine from back when it was new. And I'm telling you that your interpretation of the refresh as a side effect was wrong;

Ah, argument from authority... fallacies, gotta love 'em.

mbbrutman wrote:

it was a design feature for the machine.

Now *this* is an opinion.
As I already said, the refresh is done by the Motorola 6845, which was not designed by IBM, nor was it designed specifically for the PCjr. So if you want to stick to your opinion that this was a design feature of the PCjr, even though the chip existed long before the PCjr did, and was used in many other machines before the PCjr was designed, that's up to you.
It is my opinion that this is a rather strange view of reality.

mbbrutman wrote:

You can keep believing what you want. I think my sources are better.

It was never about your sources, it was about your interpretation of the facts.

http://scalibq.wordpress.com/just-keeping-it- … ro-programming/

Reply 13 of 30, by mbbrutman

User metadata
Rank Member
Rank
Member
Scali wrote:
Now *this* is an opinion. As I already said, the refresh is done by the Motorola 6845, which was not designed by IBM, nor was it […]
Show full quote
mbbrutman wrote:

it was a design feature for the machine.

Now *this* is an opinion.
As I already said, the refresh is done by the Motorola 6845, which was not designed by IBM, nor was it designed specifically for the PCjr. So if you want to stick to your opinion that this was a design feature of the PCjr, even though the chip existed long before the PCjr did, and was used in many other machines before the PCjr was designed, that's up to you.
It is my opinion that this is a rather strange view of reality.

I'm sorry, where did I ever say that the 6845 was designed by IBM or intended for the PCjr?

You know, I have no financial interest in this, and no reason to be engaging in this discussion other than to try to make a gentle correction on something you've got slightly wrong. We're not arguing facts; we're arguing about whether it is a design feature or a side effect, and that's clearly in the realm of opinion.

I am relaying to you that the people who designed the machine considered it a design feature. You are flat out rejecting that. I don't have a video recording of it so I can't provide any direct proof. But like I said, I was there and I've also read quite a bit of the internal discussion on the PCjr that the IBM employees had. I've talked to the designers of the circuit. You can continue to reject my assertion that the IBM engineers considered it a feature, but your opinion is contrary to what they thought of it.

This is the last time I'm going to say it - the designers at IBM who worked on the PCjr and designed the circuit, including the Video Gate Array that arbitrates between the 6845 and the 8088 CPU, considered it to be a feature, not a side effect. And they designed explicitly for it. This included having the Video Gate Array spread the address references across two banks of memory (when the 64KB card is installed).

Remember, these people conspicuously decided not to include video memory in with the system memory when they designed the CGA, MDA, and the superior EGA (which was in development at the same time the PCjr was in development.) They broke with their own design pattern to do shared memory. They also broke with their own design pattern of using DMA for memory refresh. In their minds (and in what they wrote at the time, and what they relayed to me years later), the memory refresh trick pulled off by the video controller and the Video Gate Array was a neat trick. They did not consider the 6845 to be usable by itself, hence the addition of the VGA. The VGA solves the problem by providing the arbitration between the competing 6845 and the CPU. When you don't provide arbitration or dual ported memory, you get CGA snow, which is notably absent on the PCjr because of this design.

By the time a team breaks with two established design patterns and then chooses to create a custom ASIC (the Video Gate Array), I think it's pretty clear that they considered it a design feature, not a side effect.

Back to real life now ...

Reply 14 of 30, by Scali

User metadata
Rank l33t
Rank
l33t
mbbrutman wrote:

You know, I have no financial interest in this, and no reason to be engaging in this discussion other than to try to make a gentle correction on something you've got slightly wrong.

For the last time, I don't have anything wrong.
Memory refreshing *IS* a side-effect of accessing memory. Do you know how the PC refreshes its memory with the DMA controller? Yes, by accessing it.
Clearly the primary reason for accessing memory is to read or write it, not to refresh it. Hence the fact that it refreshes is a side-effect rather than the primary effect of accessing memory.
The fact that you keep insisting that I'm wrong is an insult.

mbbrutman wrote:

I am relaying to you that the people who designed the machine considered it a design feature. You are flat out rejecting that.

I'm not. I'm saying that I think it's a silly view to have, I'm not denying that they may actually think this.
And I said why it's silly: video chips have been designed in a way that their access patterns refresh all video memory, without the need for any additional refreshing for years before the PCjr arrived. And home computers have been designed to share video memory with system memory, therefore not requiring additional refresh for years before the PCjr arrived.
So if those IBM engineers are like "Wow, look at this cool feature we've just designed!", using this off-the-shelf Motorola chip which tons of people have used in the exact same manner before them, then yes, I think they're being silly.

mbbrutman wrote:

Remember, these people conspicuously decided not to include video memory in with the system memory when they designed the CGA, MDA, and the superior EGA (which was in development at the same time the PCjr was in development.) They broke with their own design pattern to do shared memory.

Yes, and likewise consoles have been using regular PC-parts for years, yet they also share videomemory with main memory while regular PCs do not.
There's a reason why the original PC didn't share memory... Big part of the reason why PCjr was such a failure: it makes the whole system slower (at least, the way they did it... A C64 for example is a completely different story. But hey, they didn't use off-the-shelf parts, you're in the big league now). For the regular PC, graphics performance wasn't very important. Heck, they even had a text-only adapter. So it wasn't a good trade-off.
PCjr was aimed more at games and such, so the trade-off would be different.

mbbrutman wrote:

By the time a team breaks with two established design patterns and then chooses to create a custom ASIC (the Video Gate Array), I think it's pretty clear that they considered it a design feature, not a side effect.

If that design was actually any good, perhaps...
But it was just a poor copy of what other computers had been doing for years already.
Those IBM 'designs' were some of the worst in the history of computing. Both the PC and the PCjr are laughable designs. But hey, if you suck that much, perhaps you think that this memory refresh solution is actually a 'cool feature'.
I mean, how many systems other than CGA even have the snow-problem at all? It's not like the PCjr is the only design to have worked around this, nor is their workaround particularly impressive.

Now please drop the arrogance, and just let it go. You're getting horribly annoying, to the point of being insulting, and I am not impressed in the least.

http://scalibq.wordpress.com/just-keeping-it- … ro-programming/

Reply 17 of 30, by Scali

User metadata
Rank l33t
Rank
l33t

I just can't stand it when people insist that I'm wrong, when I'm obviously not.
The problem is just mbbrutman's ego. He feels he's the authority on PCjr, so he has to 'prove' that I'm wrong, no matter what. Because it's inconceivable that I may actually have been right, and his 'correction' was of no relevance. Even if it is, he would never admit it.
He just underestimated my knowledge, as he underestimates everyone, given his ego.
I've seen tons of such people over the years. Overcompensating...

http://scalibq.wordpress.com/just-keeping-it- … ro-programming/

Reply 18 of 30, by mbbrutman

User metadata
Rank Member
Rank
Member

Thanks for the lecture on DRAM refresh, but I think we've already established that both of us know how it works.

I'm just merely pointing out that the point of view of the people who designed the machine is quite different than your interpretation. To them, the video controller refreshing the memory was a design feature, and they used it as such. You don't have to accept it, and clearly you don't.

My ego is not the issue here. I'm not the one who said the entire PC design was laughable:

Those IBM 'designs' were some of the worst in the history of computing. Both the PC and the PCjr are laughable designs. But hey, if you suck that much, perhaps you think that this memory refresh solution is actually a 'cool feature'.

Those are pretty bold claims. I'm sure your designs have all been better.

Somebody told me once that there is no point in wrestling with a pig; the pig enjoys it and you just get dirty. It's time for me to heed that advice.

Reply 19 of 30, by Greenchili

User metadata
Rank Newbie
Rank
Newbie

Moving along and back on topic.... 😜

I got PCJR speed corrected and since I updated the code and have access to machine type of EGA I can run EGA mode (for games like Gauntlet). However I have a similar issue with Gauntlet in EGA mode. It is running too fast. The clock (gamers health) counts down twice as fast.

Weirdness... 🙁

Any ideas on where I need to look?