pcjs/modules/pcjs/lib
Repository files (latest commit first)
Filename Latest commit message Latest commit date
2015-05-06 16:24:28 -07:00
..
.jshintrc More 80386 instructions 2015-03-29 15:57:57 -07:00
bus.js Moved paging functions from Bus to CPU 2015-05-05 10:32:04 -07:00
chipset.js First change for v1.17.6: DeskPro 386-compatible A20 management 2015-04-19 18:19:10 -07:00
computer.js 32-bit operand fixes 2015-05-05 11:45:24 -07:00
cpu.js TBD function no longer needed 2015-04-30 14:08:10 -07:00
debugger.js Fixed 32-bit protected-mode test code 2015-05-05 18:26:19 -07:00
defines.js More PAGEBLOCKS support 2015-04-29 09:47:22 -07:00
disk.js Simplify subclassing 2015-04-01 17:20:26 -07:00
fdc.js More 80386 instructions and more 80386 Debugger support 2015-04-30 13:27:43 -07:00
hdc.js Initial scaffolding for paged memory 2015-04-28 17:45:29 -07:00
interrupts.js v1.16.5: Getting ready for 2015 2014-12-29 23:06:28 -08:00
keyboard.js Minor function signature adjustments 2015-04-02 14:30:27 -07:00
memory.js Fixed LGDT and LIDT, fixed read-only memory, and fixed mode transition tests 2015-05-06 16:24:28 -07:00
messages.js New Debugger command to dump Bus memory allocations 2015-04-08 09:45:13 -07:00
mouse.js Compaq DeskPro 386 ROM BIOS boots UNMODIFIED now 2015-04-16 17:31:40 -07:00
nodebugger.js v1.16.5: Getting ready for 2015 2014-12-29 23:06:28 -08:00
panel.js Eliminated block size constraints, added support for bit fields 2015-04-27 18:26:54 -07:00
ram.js Minor tweaks 2015-05-02 09:13:16 -07:00
README.md Cleaned up conditional jump handling 2015-05-04 19:26:06 -07:00
rom.js Fixed SGDT/SIDT (hopefully) 2015-05-03 10:11:18 -07:00
serialport.js Cleaned up DMA port handling and minor tweaks 2015-04-13 14:02:02 -07:00
state.js Compaq DeskPro 386 ROM BIOS boots UNMODIFIED now 2015-04-16 17:31:40 -07:00
video.js Initial scaffolding for paged memory 2015-04-28 17:45:29 -07:00
x86.js Cleaned up conditional jump handling 2015-05-04 19:26:06 -07:00
x86cpu.js Fixed 32-bit protected-mode test code 2015-05-05 18:26:19 -07:00
x86func.js Fixed LGDT and LIDT, fixed read-only memory, and fixed mode transition tests 2015-05-06 16:24:28 -07:00
x86modb.js Assorted 80386 and Debugger fixes 2015-05-01 14:21:23 -07:00
x86modb16.js Assorted 80386 and Debugger fixes 2015-05-01 14:21:23 -07:00
x86modb32.js Assorted 80386 and Debugger fixes 2015-05-01 14:21:23 -07:00
x86modsib.js Stack optimizations 2015-02-01 12:48:04 -08:00
x86modw.js Assorted 80386 and Debugger fixes 2015-05-01 14:21:23 -07:00
x86modw16.js Assorted 80386 and Debugger fixes 2015-05-01 14:21:23 -07:00
x86modw32.js Assorted 80386 and Debugger fixes 2015-05-01 14:21:23 -07:00
x86op0f.js 32-bit operand fixes 2015-05-05 11:45:24 -07:00
x86ops.js Fixed LGDT and LIDT, fixed read-only memory, and fixed mode transition tests 2015-05-06 16:24:28 -07:00
x86seg.js Fixed LGDT and LIDT, fixed read-only memory, and fixed mode transition tests 2015-05-06 16:24:28 -07:00

PCjs Sources

Structure

These JavaScript files divide PCjs functionality into major PC components. Most of the files are device components, implementing a specific device (or set of devices, in the case of chipset.js).

Be aware that component is an overloaded term, since Component is also the name of the shared base class in component.js used by most machine components. A few low-level components (eg, the Memory and State components, the Card class of the Video component, the Color and Rectangle classes of the Panel component, etc) do not extend Component, so don't assume that every PCjs object has access to component.js methods.

Examples of non-device components include UI components like panel.js and debugger.js, and sub-components like x86opxx.js and x86func.js that separate the CPU functionality of x86.js into more manageable pieces.

These components should always be loaded or compiled in the order listed by the pcJSFiles property in package.json, which includes all the necessary shared components as well. At the time of this writing, the recommended order is:

Some of the components can be reordered or even omitted (eg, debugger.js or embed.js), but you should observe the following:

  • component.js must be listed before any component that extends Component
  • panel.js should be loaded early to initialize the Control Panel (if any) as soon as possible
  • computer.js should be the last device component, as it supervises and notifies all the other device components

To minimize ordering requirements, the init() handlers and constructors of all components should avoid referencing other components. Device components should define an initBus() notification handler, which the Computer component will call after it has created/initialized the Bus component.

Features

[List of major existing features goes here]

BackTrack Support

The next major feature to be implemented is referred to as BackTrack Support, or simply BackTracks. When BackTracks are enabled, every memory location (at the byte level) and every general-purpose byte register may have an optional link back to its source. These links are called BackTrack indexes.

All the code that a virtual machine initially executes enters the machine either via ROM or disk sectors, and as that code executes, the machine is loading data into registers from memory locations and/or I/O ports and writing the results to other memory locations and/or I/O ports. BackTracks keep track of that data flow, allowing us to examine the history of any piece of data at any time, down to the byte level; while this feature could be extended to the bit level, it would make the feature dramatically more expensive, both in terms of size and speed.

A BackTrack index is encoded as a 32-bit value with three parts:

  • Bits 0-8: 9-bit BackTrack object offset (0-511)
  • Bits 9-15: 7-bit type and access info
  • Bits 16-30: 15-bit BackTrack object number (1-32767, 0 reserved for dynamic data)

This represents a total of 31 bits, with bit 31 reserved.

For example, look at one of the last things a ROM does during boot: loading a disk sector into RAM. It will be up to the disk controller (or DMA controller, if used) to create a BackTrack object representing the sector that was read, adding that object to the global BackTrack object array, and then associating the corresponding BackTrack index with the first byte of RAM where the sector was loaded. Subsequent bytes of RAM containing the rest of the sector will refer to the same BackTrack object, using BackTrack indexes containing offsets 1-511.