Comment correction
This commit is contained in:
parent
9b26da2d97
commit
cb96688e04
1 changed files with 5 additions and 4 deletions
|
|
@ -866,13 +866,14 @@ ChipSet.DIPSW[1][ChipSet.MODEL_5150][ChipSet.SWITCH_TYPE.EXPMEM] = {
|
||||||
576: 0x12
|
576: 0x12
|
||||||
/*
|
/*
|
||||||
* Obviously, more bit combinations are possible here (up to 0x1F), but assuming a minimum of 64Kb already on
|
* Obviously, more bit combinations are possible here (up to 0x1F), but assuming a minimum of 64Kb already on
|
||||||
* the motherboard, any amount of expansion memory about 576Kb would break the 640Kb barrier. If you stuck with
|
* the motherboard, any amount of expansion memory above 576Kb would break the 640Kb barrier. Yes, if you used
|
||||||
* MDA or CGA video cards, perhaps you could go as high as 704Kb in a real system. But in our happy little
|
* only MDA or CGA video cards, you could go as high as 704Kb in a real system. But in our happy little world,
|
||||||
* world, this is where we stop.
|
* this is where we stop.
|
||||||
*
|
*
|
||||||
* TODO: A value larger than 0x12 usually comes from a misconfigured machine (ie, it forgot to leave SW2[5] ON).
|
* TODO: A value larger than 0x12 usually comes from a misconfigured machine (ie, it forgot to leave SW2[5] ON).
|
||||||
* To compensate, when getDIPMemorySize() gets null back from its EXPMEM request, perhaps it should try truncating
|
* To compensate, when getDIPMemorySize() gets null back from its EXPMEM request, perhaps it should try truncating
|
||||||
* the DIP switch value.
|
* the DIP switch value. However, that would introduce a machine-specific hack into a function that's supposed
|
||||||
|
* be machine-independent now.
|
||||||
*/
|
*/
|
||||||
},
|
},
|
||||||
LABEL: "Expansion Memory (32Kb Increments)"
|
LABEL: "Expansion Memory (32Kb Increments)"
|
||||||
|
|
|
||||||
Loading…
Reference in a new issue