Hi Eric, On at 2025-07-20 01:25:47 +0200, Eric Auer via Freedos-user <freedos-user@lists.sourceforge.net> wrote: > >Hi ECM, > >> I added XMS support (Extended Memory that isn't lockable, >> HMA with A20 always enabled, and UMBs) to 8086tiny. > >I do not understand. 8086 only has address lines A0 to A19, >how can XMS, HMA and A20 exist on 8086 hardware at all?
8086tiny is an emulator. It doesn't have *any* "address lines" or indeed a bus, because it emulates all memory accesses to an internal memory area. I simply added the XMS driver interface for accessing the HMA. I believe I didn't have to alter the emulator at all to allow usage of the HMA, the RAM_SIZE already was set to be 1088 KiB minus 16 Byte (ie, Real 86 Mode addressable memory including the HMA): https://github.com/ecm-pushbx/8086tiny/blob/a010490ec58d33ce2b88480377464782339e6da3/8086tiny.c#L56 Like I mentioned, the Extended Memory isn't lockable. That is it cannot be accessed by the CPU, because it isn't addressable in Real 86 Mode. All accesses to the Extended Memory happen in the driver + underlying emulator interfaces, which are not limited to what the CPU can address using 8086/186 machine code. As for A20, there is no way to mask it on my 8086tiny fork. It simply always acts as if A20 is enabled. Again, this behaves like a 286 in Real 86 Mode (minus the chipset's A20 toggle) but this is simply a consequence of how the emulator deals with segmented addresses. >In theory, you could implement something which copies around >memory between the first 640k of memory and the last 384k of >the first megabyte, but most of that will be in use for BIOS >and graphics, or simply not have any usable RAM installed? It isn't difficult for an emulator to provide usable RAM in the UMA. The driver indeed only deals in providing XMS interface access to some hardcoded UMBs, the emulator simply has some writable memory already mapped there. >> I found that at the time FreeCOM expected to run on a 186 >> or 286 when using XMS. (The 286 instructions unrelated to >> Protected Mode are all present on the 186 already.) > >That makes perfect sense to me. FreeCOM is welcome to make >use of 286 optimizations given that PC which have sensible >amounts of XMS available must be PC which have 286+ CPU. That is precisely why I mentioned this. Traditional implementations of XMS (ie, using the CPU to address memory beyond 1024 KiB) may be expected to require a 286 or higher CPU. But the XMS v2 interface doesn't actually *require* a 286. For emulators, or indeed the XMS by means of EMS option, it is perfectly possible to provide XMS on a machine running an 8086 or 186 CPU. >> This may have been fixed since, after I reported it in 2019: >> https://github.com/FDOS/freecom/issues/15 >> Just something to consider when you implement XMS on an 8086. As I mentioned there, I added all 186 instructions to 8086tiny eventually, which made the unpatched FreeCOM work again, as all non-PM 286 instructions are supported by the 186. >Regards, Eric Regards, ecm
_______________________________________________ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user