ISTR that a lot (if not all) of the early 8086/88 machines, which weren't IBM clones, could be expanded well past 640K. In fact, the more I think about it, ISTR that the PC was unusual in being limited to 640K.... I definitely recall having 896K in one of my Sirii and my Apricot Xi. TTFN - Pete.

On 21 Apr 2007 at 16:06, Chris M wrote: to off just remap what constructs impossible. Now I feel like the dopey one... I don't understand what you're asking. Care to restate it for us thick-as-a-brick folks? :-)

On 22 Apr 2007 at 8:23, Chris M wrote: My question is therefore is this practical some extremely enough I suppose it all depends if you're talking about text or graphics.

Text is pretty simple, but graphics bit- and port-level compatibility is a different matter.

Still, it's possible to search an app for video display buffer segment loads and alter them. Recall that many apps would work on both MDA/MGA and CGA and so altered which addess that was used on the fly.

Note that apps that used CGA 80x25 text may not work without more probing as a "stall" waiting for the retrace interval to avoid snow in the display was very commonly used and may well cause your application to hang without modification.

Cheers, Chuck

Like what? CGA graphics starts at C800:0. The first thing that I'd do is search the executable for 00 C8 and see what referenced it. Be aware that many early PC games used some pretty involved copy protection, which might get in the way of brute-force hacking. Otherwise, I'd just set up a TSR to examine some conventional DRAM at C800 and update the 2000 display accordingly. You might even fabricate a card that interrupts after an access to the screen buffer, latching the address and data.

I think that you'd want to map your graphics emulator from B800. Save C800 for hard disk emulators.

Writing PC emulators for incompatibles is certainly possible, but, is it worth the effort.

This is how I feel. Utilize virtual-8086 mode to alleviate alot of the dirty work. Anyone familiar enough with it?

On 22 Apr 2007 at 18:21, Chris M wrote: Thinking about this a bit more, given the the T2000 is an 8MHz 80186, it'd probably be easier just to emulate the thing entirely with a software-based emulator instead of using V86 mode. On a modern machine, the simulation would certainly still run faster than the original.

On 23 Apr 2007 at 15:51, Chris M wrote: "additions" at '186 Yes, you probably could. The big problem that I see is while the 386/486/Pentium V86 mode is close to what an 80186 does, there are differences (itemized in the V86 mode description). They may not make any difference, but if they do, you're out of luck. Plus, setting up a V86 session is pretty involved. You need to have a protected mode server for the V86 session and set up all of the IDT/GDT/LDT stuff that goes along with it. It feels like a lot of work to me, but I could be mistaken. I'm assuming that you're going to host this thing on DOS; I don't know what provisions for V86 mode are built into Linux (never had a reason to look), but maybe that might be easier.

On 26 Apr 2007 at 14:23, Chris M wrote: protected invoke correctly), Because it's easier to do than on a lot of other platforms. Consider that DPMI servers are run on a DOS base (or did you think that Windows 3.1/95 was something other than a gussied-up DPMI servier? And there's DJGPP...)

Windows NT has a V86 mode, but aside from trapping port access via a VDD, I don't know how you modify its memory map easily.

LOL LOL. Don't have any; if I need sherry to cook with, I use drinkin' sherry.

emulator built on It does, but given the complexity of Linux, I don't know how simple it would be to modify it to duplicate a T2000 environment. Cheers, Chuck Not if I can help it.

Because DOS is a known quantity running in real mode with no protections, it's simple to set up your own descriptors and gates and launch your own protected mode app than having to figure out what someone else is doing.

It's been years since I've looked at this. If EMM386 is loaded DOS is actually running in V86 mode, isn't it?

Right. But that's assuming simplistic coding/logic. What if it got real real hard?

On Sun, 22 Apr 2007, Chris M wrote: practical some extremely enough You could take the approach of the Atari Portfolio. Provide some RAM at the expected video memory address for the application to fiddle with. Then periodically scan that RAM and copy whatever is there to the screen. No, it didn't work terribly well with the Portfolio, but it did help a bit. -- roger ivie rivie at ridgenet.net

I have my PCjr shrine. The cyberspace one is at http://www.brutman.com/PCjr Most of you already know that the PCjr didn't have dedicated video RAM. The video RAM was shared with the 128K of memory on the motherboard, and there was some logic to arbitrate between the CPU and the video circuitry. The video circuitry always won, so a normal PCjr with just 128K (the original design limit) was effectively half the speed of a PC 5150, even though they had the same CPU running at the same clock speed. (The memory was not dual ported.) IBM called the video logic the 'Video Gate Array', and often abbreviated it as VGA. So when I tell people that my PCjr has a VGA, I am technically not lying. The standard PCjr has only 64K of RAM, soldered to the motherboard. Certain video modes (the enhancements to CGA) were not available unless you had a 128K machine, where the extra memory went to a dedicated slot. I believe the video circuitry treated the memory as two banks, so the extra 64K really was necessary for the enhanced modes, not for storage but for memory bandwidth. The VGA took memory references in the B8000 to BFFFF and remapped them to whatever 16K 'bank' of memory was selected in the first 128K to be the real video memory. The bank was very flexible to configure; a stock PCjr would put it at the high end of memory (112 - 128K) and grow it downwards as needed. A device driver could relocate it. And when you did add extra memory to a PCjr and wanted it usable by DOS, you absolutely needed the device driver. The #1 flaw on the PCjr (in my humble opinion) was making the assumption that memory was capped at 128K, and having the machine put the video memory at the top of memory. This required a device driver to fix things up if you had more memory. If they had designed the video memory to be shared at the top of installed memory and not assumed that 128K was the maximum, the machine would be far more usable. I think the Tandy 1000 series did it correctly. (A BIOS oddity - for a machine with a supposed 128K limit, the BIOS knows how to count to 640K.) Mike

You could take the approach of the Atari Portfolio. Provide some RAM at the expected video memory address for the application to fiddle with. Then periodically scan that RAM and copy whatever is there to the screen.

It worked much better than you would think. Even the shading to represent color worked, because each 8 color CGA pixel translated into 2 or 4 monochrome pixels.

The 640K barrier was due to the location of the memory map for CGA graphics IIRC. If you were running monochrome you could squeeze a little more ram out of the system IIRC.