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
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
New CPU? I'm afraid that's another battle out of reach. beyond our reach. We don't have this element at our disposal, so we can't fight like this
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.
Writing a whole new CPU from scratch in FPGA is a huge project, and I'm not sure anyone has ever done the 80286. It would be months and months of hard work, and Spark2K06 doesn't seem even a little bit interested, for which I can hardly blame him. Even if I had the skill myself, I don't think I'd want to invest my time in the 80286.
Anyone on that project would also have to reimplement IRQs; they could probably re-use the same virtual chip twice, just like real ATs did, but the cascaded interrupts might be awkward to handle. In real ATs, IRQ2 connects to IRQ9; they are the same thing. All the higher interrupts, IIUC, get signaled on IRQ 2, and then the BIOS has to scan the upper interrupt controller to figure out what's going on. This is a big change from how the XT worked.
Getting that all sorted is likely to be a huge PITA, and it won't actually offer that much more software. It's not until the 80386 that you start to get into stuff that's genuinely new, and that ground is sorta covered by AO486, albeit not very well.
As mentioned upthread, if you set the XT to maximum speed, it's likely to be fast enough to play most or all games aimed at the 80286.
edit to add a later thought: it would probably be a lot easier to figure out why the XT core is stuck at 14MHz... if they could double it again to 28MHz, that should be more than fast enough to keep up with a 286, for a heck of a lot less work.
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.
This is not true. I am the author of the MCL86 who built it from the ground up...
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.
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.
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.
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.
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.
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.
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.