ghaerr
86/186 CPUs with 24/29-bit addressing modes
Continuing discussion from here. There are 86/186 CPUs that support 24/29-bit addressing without using protected mode.
- 24-bit addressing mode allowing for up to a 16Mbyte address space:
- NEC V33/V53 (186 supporting also the real mode features of 286) - extended addressing mode via
BRKXA/RETXAinstructions - NEV V55 - extended segment registers
- VAutomation Turbo86/186 1,2 - extended real mode (OpenWatcom)
- F8680 SuperState R via which can also be emulated the 286 features (including HMA and 16-bit protected mode for Win3.1)
- NEC V33/V53 (186 supporting also the real mode features of 286) - extended addressing mode via
- 29-bit addressing mode, 32 registers, VMZ instructions (kind of "32-bit protected mode competitor/alternative"): VM8600SP - 8086 supporting some 286/386 instructions
Are those something that ELKS can support?
Another interesting platform is providing full 1MB access - maybe that's more relevant for TLVC:
- SCP-300 with PHANTOM signal (disabling the BIOS after boot-up - p45) - allowing to perform "linking the linker" like Microsoft did before 386 was available.
Are those something that ELKS can support?
Well, not sure exactly what you are looking for? Do you have a real hardware or emulator platform that such enhancements could be tested on? In general, it is very important to be able to test any code submitted so that it can be well maintained.
ELKS itself currently only uses extended memory for (XMS) system buffers and/or XMS RAM disk; neither the kernel nor applications will run outside a 1MB+64k address space, because the system is designed around 16-bit segment registers and 16-bit offsets, with the exception of an addr_t/ramdesc_t type which describes a 32-bit linear address. This latter address type is only used within the buffer/ramdisk sub-systems and use the xms_fmemcpy functions to transfer data to/from XMS and main memory. This would be where enhancements for 24/29-bit addressing would used.
ELKS could probably be somewhat easily enhanced to provide support for new varieties of XMS buffer and RAM disk access; the system now operates automatically choosing the XMS access method available for a processor, which is where support for some of your 24/29-bit addressing modes could be added. The new XMS memory functions would be passed a 32-bit linear address and be automatically selected based on some additional code when determining the exact CPU during startup.
Another interesting platform is providing full 1MB access
ELKS is quite independent of underlying hardware RAM layout, we have 8018X ROM versions for instance that can run anywhere within the 20-bit address space, and use the entire 1MB+64K memory available. It can be configured now for a serial console and direct floppy FDC access, with minimal requirements for "BIOS" INT functions, for which there are usually wrapper functions available already for systems without any BIOS.
I hope this helps what you might be looking for.
Thank you!
Do you have a real hardware or emulator platform that such enhancements could be tested on?
No, unfortunately. I hope DOSbox, 86Box or MartyPC will provide such support eventually.
ROM versions for instance that can run anywhere within the 20-bit address space, and use the entire 1MB+64K memory available.
Does that mean that available memory is 1MB+64K-ROM size - or you allow PHANTOM-like remove-ROM-after-bootup to use the full 1088KB as RAM?
-
ELKS can use UMB memory https://github.com/ghaerr/elks/wiki/Access-to-UMB-memory , but it is up to the user to decide which parts of it are eventually safe to use. ELKS will use this memory as normal conventional memory.
-
HMA - You can use the 64 kb after the 1MB by enabling
hma=kernelin/bootopts -
XMS - used for disk buffers and RAM drive. Use
xms=onin/bootopts
Nothing is removed or mapped. You need to make sure the memory is physically there and you are not overwriting a ROM for example. Actually if you know that you are not going to use the VGA ROM then you can "safely" overwrite it.
In general once a memory region is marked to be used, then it is the kernel that provides this memory to the user apps (without any protection). Also the memory rests fragmented, but the kernel knows which regions to use. That is the trick.
@ghaerr might clarify better
Does that mean that available memory is 1MB+64K-ROM size - or you allow PHANTOM-like remove-ROM-after-bootup to use the full 1088KB as RAM?
Currently, available memory would be the former, as nothing is coded for phantom-like remove-rom-after-boot functionality. Adding the latter would be pretty straightforward, providing of course, that such an enhancement could be tested on an emulator or real hardware.
As @toncho11 describes, there are many options to configure a particular machine's memory layout; ELKS can use any 16-bit real mode segment value to access memory anywhere in the 20-bit address space. Adding the 384k+64k above the normal 640k limit for application use would be very straightforward, but only HMA- and UMB-style options are currently implemented.
adding on to this, there are 80C86's that technically have more addressable memory than a stock 8086 by way of the fact they emit which segment selector is generating the address on S3-S4, so you could theoretically design an MMU that provides support for programs with more than 1Mb by using the segment selector id as part of the address translation, and having different translations for CS, DS, ES, SS.
not sure if any hardware used that as by the time those 80C86s came to market you could buy a 286 for less, but it'd be interesting to see a theoretical design use it.
