MiSTer FPGA Forum

Captain Zap wrote: ↑Tue Nov 29, 2022 11:53 am Thank you so much for implementing Tandy Grfx & Sound. As a Tandy 1000 fan and proud owner of a real Tandy 1000tx this is a delight

Here and there a little bit more oompha would be kinda nice. Of course it's the PC/XT core with 4.7 to 9.4 MHz so it's nice to have it at all with those features.

But would it be possible to juice things up a tad? Like the 1000tx?

So the Tandy 1000tx was not so much different from what I know. Mostly it was an 80286-8 CPU and a 16bit Memory Bus thrown into the previous Tandy 1000sx architecture.

I know that I don't have the skills to pull anything off like that at all

Greetz
Da Captain

As I understand it, this team didn't make the existing 8088 emulator. They took it from another project, struggled with it for awhile, and then MCL86 improved it some. They didn't do a ground-up creation, they took an existing thing, and tweaked it to work better, and even that took a lot of work.

jordi wrote: ↑Wed Nov 30, 2022 6:24 am Also the thing is that games from that era will work even in a Pentium, as they learnt to use internal timer to limit frames.

Malor wrote: ↑Wed Nov 30, 2022 7:57 am

Sorry, I knew you came along later and fixed it up to work better with the Mister, but I didn't realize you'd invented the thing in the first place!

jordi wrote: ↑Wed Nov 30, 2022 6:24 am

Also the thing is that games from that era will work even in a Pentium, as they learnt to use internal timer to limit frames.

True, but the AO486 has, er, problems. That said, fixing the bugs in that core (mostly memory related, I think) would also be probably 10x easier than writing an 80286 or 80386.

AO486 seems to have some problems with real mode. Someone debugging those problems would also fix the issues it has with some DOS4GW games and probably more.

dmckean wrote: ↑Wed Nov 30, 2022 1:55 pm

AO486 seems to have some problems with real mode. Someone debugging those problems would also fix the issues it has with some DOS4GW games and probably more.

This, DPMI specifically and something different between DOS4G (The og version that comes with most games) and DOS32a (which usually works around the problem and the game functions). It's a difficult bug to find.

I have a theory that DOS4G can't handle a large memory footprint and AO486 gives it 256MB of Memory (even if you have the core set to 16MB there is something in the bios that tells dos there is more). That's my guess. Truly limiting the core memory to what we really had in a 486 DOS machine might do the trick ( realize there were some 486 mobo that could take 256MB 72-pin sticks but those were rare). I think the limit with most versions supplied with DOS4g was 64MB.

Sorgs comment on the bug report and some testing I did with a test image supplied and repeatable steps to reproduce (2 years AGO! wow, time flies): https://github.com/MiSTer-devel/ao486_M ... -724855108

Totally a guess and very off topic.

flynnsbit wrote: ↑Wed Nov 30, 2022 2:51 pm

dmckean wrote: ↑Wed Nov 30, 2022 1:55 pm

AO486 seems to have some problems with real mode. Someone debugging those problems would also fix the issues it has with some DOS4GW games and probably more.

This, DPMI specifically and something different between DOS4G (The og version that comes with most games) and DOS32a (which usually works around the problem and the game functions). It's a difficult bug to find.

I have a theory that DOS4G can't handle a large memory footprint and AO486 gives it 256MB of Memory (even if you have the core set to 16MB there is something in the bios that tells dos there is more). That's my guess. Truly limiting the core memory to what we really had in a 486 DOS machine might do the trick ( realize there were some 486 mobo that could take 256MB 72-pin sticks but those were rare). I think the limit with most versions supplied with DOS4g was 64MB.

Sorgs comment on the bug report and some testing I did with a test image supplied and repeatable steps to reproduce (2 years AGO! wow, time flies): https://github.com/MiSTer-devel/ao486_M ... -724855108

Totally a guess and very off topic.

Ahh, I think I had not seen the response from Sorg there. I guess no one actually provided a fix? The "fix" so far has been the DOS32A workaround.

We know some games would work better with this, because a solution for some games was simply to fill up RAM above 16MB or 64MB, not sure which, using some DOS app, and that would fix it, and also using DOS32A would generally fix it.

Caldor wrote: ↑Wed Nov 30, 2022 10:23 pm

flynnsbit wrote: ↑Wed Nov 30, 2022 2:51 pm

dmckean wrote: ↑Wed Nov 30, 2022 1:55 pm

AO486 seems to have some problems with real mode. Someone debugging those problems would also fix the issues it has with some DOS4GW games and probably more.

This, DPMI specifically and something different between DOS4G (The og version that comes with most games) and DOS32a (which usually works around the problem and the game functions). It's a difficult bug to find.

I have a theory that DOS4G can't handle a large memory footprint and AO486 gives it 256MB of Memory (even if you have the core set to 16MB there is something in the bios that tells dos there is more). That's my guess. Truly limiting the core memory to what we really had in a 486 DOS machine might do the trick ( realize there were some 486 mobo that could take 256MB 72-pin sticks but those were rare). I think the limit with most versions supplied with DOS4g was 64MB.

Sorgs comment on the bug report and some testing I did with a test image supplied and repeatable steps to reproduce (2 years AGO! wow, time flies): https://github.com/MiSTer-devel/ao486_M ... -724855108

Totally a guess and very off topic.

Ahh, I think I had not seen the response from Sorg there. I guess no one actually provided a fix? The "fix" so far has been the DOS32A workaround.

We know some games would work better with this, because a solution for some games was simply to fill up RAM above 16MB or 64MB, not sure which, using some DOS app, and that would fix it, and also using DOS32A would generally fix it.

Yeah exactly, DOS32A "fixed it" but was a pain in the butt to replace every reference and script for protected games. No bios changes were ever looked at and I don't think anyone acted on Sorgs suggestion. I just wanted to comment here as there are a few more x86 minded folks now.

Yeah, sure would be nice if something was done about it. Someone said they got Lion King running at normal speed in Windows 98, but so far I have not been able to get that to work. Windows 9x has so many random crashes. It is hard to know when it might be due to the core and its memory management or when its just how things were with those old operating systems, but they used to be more stable than this at least.

DOSBox-X can run Windows with a little pain involved; it has to use a hard drive image, and can't use the normal DOSBox "map" driver. This is a big improvement from regular DOSBox, which struggles to even bring Windows 3.1 up. You can probably run Lion King without needing Windows, but playing with it might give you a better idea for how much stability to expect.

From memory, 98SE (the edition you usually want) should be reasonably stable. You should be able to get through an average 8-hour day without crashing it, under normal circumstances. It's nothing like NT, and definitely benefits from rebooting at least every day, but it's not too awful.