Content deleted Content added
Matthiaspaul (talk | contribs) →Further reading: +ref |
Matthiaspaul (talk | contribs) improved refs |
||
Line 66:
In the [[home computer]] era overlays were popular because the operating system and many of the computer systems it ran on lacked virtual memory and had very little RAM by current standards: the original [[IBM PC]] had between 16K and 64K, depending on configuration. Overlays were a popular technique in [[Commodore BASIC]] to load graphics screens.<ref name="Butterfield_1986"/>
"Several [[DOS]] linkers in the 1980s supported [overlays] in a form nearly identical to that used 25 years earlier on mainframe computers."<ref name="Levine_2000"/><ref name="Elliot_2012"/> [[Binary file]]s containing memory overlays had de-facto standard extensions '''.OVL'''<ref name="Elliot_2012"/> or '''.OVR'''<ref name="Dohmen_1990"/> (but also used numerical file extensions like '''.000''', '''.001''', etc. for subsequent files<ref name="Gavin"/>). This file type was used among others by [[WordStar]],<ref name="Mabett_1985"/> [[dBase]],<ref name="Sidnam-Wright-Stevens_1990"/> and the ''Enable'' DOS office automation software package from [[Enable Software, Inc.]] [[Borland]]'s [[Turbo Pascal]]<ref name="Herschel-Dieterich_2000"/><ref name="Eßer_2009"/> and the [[GFA BASIC]] compiler were able to produce .OVL files.
== See also ==
Line 92:
<ref name="Herschel-Dieterich_2000">{{cite book |title=Turbo Pascal 7.0 |language=de |author-first1=Rudolf |author-last1=Herschel |author-first2=Ernst-Wolfgang |author-last2=Dieterich |edition=2 |publisher={{ill|R. Oldenbourg Verlag|de}} |date=2000 |isbn=3-486-25499-5 |page=249}}</ref>
<ref name="Eßer_2009">{{cite book |title=Betriebssysteme I |chapter=Chapter 6. Speicherverwaltung und Dateisysteme - Teil 5: Nicht-zusammenhängende Speicherzuordnung |language=de |author-first=Hans-Georg |author-last=Eßer |date=June 2009 |publisher=Hochschule München |___location=Munich, Germany |url=http://hm.hgesser.de/bs-ss2009/folien/bs-ss2009-esser-06e-4up.pdf |access-date=2014-02-13 |url-status=live |archive-url=https://web.archive.org/web/20220508155626/http://hm.hgesser.de/bs-ss2009/folien/bs-ss2009-esser-06e-4up.pdf |archive-date=2022-05-08}} (9 pages)</ref>
}}
==Further reading==
* {{cite book |title=IBM OS Linkage Editor and Loader - Program Numbers 360S-ED-510, 360S-ED-521, 360S-LD-547 |id=Order No. GC28-6538-9, File No. S360-31 |version=Release 21 |date=March 1972 |orig-date=January 1972 |edition=10 |publisher=[[IBM Corporation]] |publication-place=White Plains, New York, USA |work=Systems Reference Library |url=http://www.bitsavers.org/pdf/ibm/360/os/R21.0_Mar72/GC28-6538-9_OS_Linkage_Editor_and_Loader_Release_21_Jan72.pdf |url-status=live |archive-url=https://web.archive.org/web/20220710205449/http://www.bitsavers.org/pdf/ibm/360/os/R21.0_Mar72/GC28-6538-9_OS_Linkage_Editor_and_Loader_Release_21_Jan72.pdf |archive-date=2022-07-10}} (2+244+4 pages)
▲* {{cite web |author-first=John C. |author-last=Elliott |title=PRL file format |date=2012-06-05 |orig-date=2000-01-02 |website=seasip.info |url=https://www.seasip.info/Cpm/prl.html |access-date=2020-01-26 |url-status=live |archive-url=https://web.archive.org/web/20200126182027/https://www.seasip.info/Cpm/prl.html |archive-date=2020-01-26 |quote=[…] A PRL file is a [[relocation (computing)|relocatable]] binary file, used by [[MP/M]] and [[CP/M Plus]] for various modules other than [[.COM file]]s. The file format is also used for FID files on the [[Amstrad PCW]]. There are several file formats which use versions of PRL: SPR (System PRL), RSP (Resident System Process). LINK-80 can also produce OVL (overlay) files, which have a PRL header but are not relocatable. [[Graphics System Extension|GSX]] drivers are in PRL format; so are [[Resident System Extension]]s (.RSX). […]}} [https://www.seasip.info/Cpm/amsfid.html#PRL%20file%20format]
* {{cite newsgroup |title=GEOS/NDO info for RBIL62? |author-first1=Marcus |author-last1=Groeber |author-first2=Edward "Ed" |author-last2=Di Geronimo, Jr. |author-first3=Matthias R. |author-last3=Paul |date=2002-03-02 |orig-date=2002-02-24 |newsgroup=comp.os.geos.programmer |url=https://groups.google.com/d/msg/comp.os.geos.programmer/8NNPJ4VU23A/cucVV95kf9oJ |access-date=2019-04-20 |url-status=live |archive-url=https://archive.today/20190420111421/https://groups.google.com/forum/%23!msg/comp.os.geos.programmer/8NNPJ4VU23A/cucVV95kf9oJ |archive-date=2019-04-20 |quote=[…] The reason [[PC/GEOS|Geos]] needs 16 interrupts is because the scheme is used to convert inter-segment ("far") function calls into interrupts, without changing the size of the code. The reason this is done so that "something" (the kernel) can hook itself into every inter-segment call made by a Geos application and make sure that the proper code segments are loaded from [[virtual memory]] and locked down. In [[DOS]] terms, this would be comparable to an overlay loader, but one that can be added without requiring explicit support from the compiler or the application. What happens is something like this: […] 1. The real mode compiler generates an instruction like this: CALL [[segment:offset addressing (x86)|<segment>:<offset>]] -> 9A <offlow><offhigh><seglow><seghigh> with <seglow><seghigh> normally being defined as an address that must be fixed up at load time depending on the address where the code has been placed. […] 2. The Geos linker turns this into something else: INT 8xh -> CD 8x […] DB <seghigh>,<offlow>,<offhigh> […] Note that this is again five bytes, so it can be fixed up "in place". Now the problem is that an interrupt requires two bytes, while a CALL FAR instruction only needs one. As a result, the 32-bit vector (<seg><ofs>) must be [[fat pointer|compressed]] into 24 bits. […] This is achieved by two things: First, the <seg> address is encoded as a "handle" to the segment, whose lowest [[nibble]] is always zero. This saves four bits. In addition […] the remaining four bits go into the low nibble of the interrupt vector, thus creating anything from INT 80h to 8Fh. […] The interrupt handler for all those vectors is the same. It will "unpack" the address from the three-and-a-half byte notation, look up the absolute address of the segment, and forward the call, after having done its virtual memory loading thing... Return from the call will also pass through the corresponding unlocking code. […] The low nibble of the interrupt vector (80h–8Fh) holds bit 4 through 7 of the segment handle. Bit 0 to 3 of a segment handle are (by definition of a Geos handle) always 0. […] all Geos API run through the "overlay" scheme […]: when a Geos application is loaded into memory, the loader will automatically replace calls to functions in the system libraries by the corresponding INT-based calls. Anyway, these are not constant, but depend on the handle assigned to the library's code segment. […] Geos was originally intended to be converted to [[protected mode]] very early on […], with [[real mode]] only being a "legacy option" […] almost every single line of assembly code is ready for it […]}}
▲* {{cite magazine |title=Platz schaffen durch Überlagern - Overlay-Strukturen in Turbo Pascal |language=de |author-first=Norbert |author-last=Dohmen |magazine=[[mc (magazine)|mc]] |issn= |publisher= |issue=12 |volume=90 |date=1990 |pages=124-130 |url=https://guru-home.dyndns.org/Overlay.html |access-date=2022-08-04 |url-status=live |archive-url=https://web.archive.org/web/20220804163634/https://guru-home.dyndns.org/Overlay.html |archive-date=2022-08-04}} [https://web.archive.org/web/20220804163948/https://guru-home.dyndns.org/Overlay/pdf/Overlay.pdf]
▲* {{cite book |chapter=Create Program Overlays |title=Turbo Pascal |version=v3 |author-first=Bruce |author-last=Gavin |editor-first=Dave |editor-last=Pearson |page=149 |url=http://www.x-hacker.org/ng/pascal/ng19519.html |access-date=2022-08-04 |url-status=live |archive-url=https://web.archive.org/web/20220804163703/http://www.x-hacker.org/ng/pascal/ng19519.html |archive-date=2022-08-04}}
==External links==
| |||