Suppress serial interrupt messages unless SERIAL messages enabled

This commit is contained in:
Jeff Parsons 2014-12-14 21:41:02 -08:00 committed by jeffpar
commit 3bbbe075d5
5 changed files with 25 additions and 22 deletions

View file

@ -58,10 +58,9 @@ if (typeof module !== 'undefined') {
* addMemory(). If the component needs something more than simple read/write storage,
* it must provide a controller with getMemoryBuffer() and getMemoryAccess() methods.
*
* By contrast, all port access operations are defined by external handlers; they
* register with us, and we manage those registrations, and we'll probably provide I/O
* breakpoints at some point, but unlike memory accesses, we're not involved with I/O
* accesses at all.
* By contrast, all port (I/O) operations are defined by external handlers; they register
* with us, and we manage those registrations, as well as support for I/O breakpoints,
* but unlike memory accesses, we're not involved with port data accesses.
*
* @constructor
* @extends Component

View file

@ -663,7 +663,7 @@ ChipSet.PPI_SW = {
* documents in /devices/pc/keyboard, as well as the following websites:
*
* http://halicery.com/8042/8042_INTERN_TXT.htm
* http://www.os2museum.com/wp/?p=589 ("IBM PC/AT 8042 Keyboard Controller Commands")
* http://www.os2museum.com/wp/ibm-pcat-8042-keyboard-controller-commands/
*/
ChipSet.KBC = {
DATA: { // this.b8042OutBuff (PPI_A on previous models, still referred to as "PORT A" by the MODEL_5170 BIOS)
@ -4844,6 +4844,8 @@ ChipSet.prototype.messageBitsIRQ = function(nIRQ)
bitsMessage |= Messages.KEYBOARD;
} else if (nIRQ == ChipSet.IRQ.SLAVE) { // IRQ 2 (MODEL_5170 and up)
bitsMessage |= Messages.CHIPSET;
} else if (nIRQ == ChipSet.IRQ.COM1 || nIRQ == ChipSet.IRQ.COM2) {
bitsMessage |= Messages.SERIAL;
} else if (nIRQ == ChipSet.IRQ.XTC) { // IRQ 5 (MODEL_5160)
bitsMessage |= Messages.HDC;
} else if (nIRQ == ChipSet.IRQ.FDC) { // IRQ 6

View file

@ -98,7 +98,7 @@ var FATARRAYS = false;
* TYPEDARRAYS enables use of typed arrays for Memory blocks. This used to be a compile-time-only option, but I've
* added Memory access functions for typed arrays (see Memory.afnTypedArray), so support can be enabled dynamically.
*
* However, TYPEDARRAYS has always been slightly slower than the original DWORDARRAYS implementation (which uses an
* However, TYPEDARRAYS has always been slightly slower than the original NUMARRAYS implementation (which uses an
* Array of numbers that stores 32 bits -- 4 consecutive bytes -- per number), so TYPEDARRAYS is completely disabled.
*
* See the Memory component for details.

View file

@ -80,17 +80,20 @@ if (typeof module !== 'undefined') {
* Because Memory blocks now allow us to have a "sparse" address space, we could choose to
* take the memory hit of allocating 4K arrays per block, where each element stores only one byte,
* instead of the more frugal but slightly slower approach of allocating arrays of 32-bit dwords
* (DWORDARRAYS) and shifting/masking bytes/words to/from dwords; in theory, byte accesses would
* (NUMARRAYS) and shifting/masking bytes/words to/from dwords; in theory, byte accesses would
* be faster and word accesses somewhat less faster.
*
* However, preliminary testing of that feature (FATARRAYS) did not yield significantly faster
* performance, so it is OFF by default to minimize our memory consumption. Using TYPEDARRAYS is
* probably best, although not all JavaScript implementations support them (IE9 is probably the
* only real outlier: it lacks typed arrays but otherwise has all the necessary HTML5 support).
* performance, so it is OFF by default to minimize our memory consumption. Using TYPEDARRAYS
* would seem best, but as discussed in defines.js, it's off by default, because it doesn't perform
* as well as NUMARRAYS; the other advantage of TYPEDARRAYS is that it should theoretically use
* about 1/2 the memory of NUMARRAYS (32-bit elements vs 64-bit numbers), but I value speed over size
* at this point. Also, not all JavaScript implementations support TYPEDARRAYS (IE9 is probably
* the only real outlier: it lacks typed arrays but otherwise has all the necessary HTML5 support).
*
* WARNING: Since Memory blocks are low-level objects that have no UI requirements,
* they do not inherit from the Component class, so you should only use class methods
* of Component, such as Component.assert(), or Debugger methods if the Debugger is available.
* WARNING: Since Memory blocks are low-level objects that have no UI requirements, they
* do not inherit from the Component class, so you should only use class methods of Component,
* such as Component.assert(), or Debugger methods if a debugger (dbg) is available.
*
* @constructor
* @param {number} addr of block (must be some multiple of bus.blockSize)

View file

@ -43,9 +43,8 @@
*
* I wasn't thrilled about replacing all "++" and "--" operators with "+= 1" and "-= 1", nor about using
* "(s || '')" instead of "(s? s : '')", because while the former may seem simpler, it is NOT more portable.
* It's not that I'm trying to write "portable JavaScript", but some of this code was ported from C code
* I'd written about 14 years earlier, and portability is good, so I see no reason to rewrite code to make
* it less portable.
* It's not that I'm trying to write "portable JavaScript", but some of this code was ported from C code I'd
* written about 14 years earlier, and portability is good, so I'm not going to rewrite if there's no need.
*
* UPDATE: I've since switched to JSHint, which seems to have more reasonable defaults.
*/
@ -228,7 +227,7 @@ Component.add = function(component)
/*
* This just generates a lot of useless noise, handy in the early days, not so much these days...
*
* Component.log("Component.add(" + component.type + "," + component.id + ")");
* if (DEBUG) Component.log("Component.add(" + component.type + "," + component.id + ")");
*/
Component.all[Component.all.length] = component;
};
@ -406,7 +405,7 @@ Component.getComponentByID = function(id, idRelated)
return Component.all[i];
}
}
Component.log('Component.getComponentByID("' + id + '"): no component found', "warning");
Component.log("Component ID '" + id + "' not found", "warning");
}
return null;
};
@ -444,7 +443,7 @@ Component.getComponentByType = function(sType, idRelated, componentPrev)
return Component.all[i];
}
}
Component.log('Component.getComponentByType("' + sType + '"): no component found', "warning");
Component.log("Component type '" + sType + "' not found", "warning");
}
return null;
};
@ -532,12 +531,12 @@ Component.bindComponentControls = function(component, element, sAppClass)
if (parms && parms['binding']) {
component.setBinding(parms['type'], parms['binding'], control);
} else {
Component.log('Component.bindComponentControls("' + component.toString() + '"): missing binding' + (parms? ' for ' + parms['type'] : ''), "warning");
Component.log("Component '" + component.toString() + "' missing binding" + (parms? " for " + parms['type'] : ""), "warning");
}
iClass = aClasses.length;
break;
default:
// Component.log("Component.bindComponentControls(" + component.toString() + "): unrecognized control class \"" + sClass + "\"", "warning");
// if (DEBUG) Component.log("Component.bindComponentControls(" + component.toString() + "): unrecognized control class \"" + sClass + "\"", "warning");
break;
}
}
@ -577,7 +576,7 @@ Component.getElementsByClass = function(element, sClass, sObjClass)
}
}
if (!ae.length) {
Component.log('no elements of class "' + sClass + '" found');
Component.log('No elements of class "' + sClass + '" found');
}
return ae;
};