craigthomas / coco3java Goto Github PK

With certain graphics modes, NTSC artifacts generate more colors than were actually available on the Color Computer series. This is the case for the G6R mode, where only two color choices were available - black and white. With NTSC displays, the timing of the screen refresh led to certain pixel combinations of alternating black and white patterns to be displayed as red and blue instead. The emulator currently supports displaying NTSC artifacts when in this mode as a fat pixel approximation of how they would appear. However, it is possible to turn this behavior off entirely so that only the black and white pixels are displayed. The purpose of this feature request is to add a control to the emulator window that will allow the user to switch this behavior.

The emulator currently takes a fat pixel approach to emulating artifact colors. It performs a very rough approximation of whether to draw a red or blue pixel depending on the alternating patterns of black or white. While this does the job of incorporating colors into the display for artifact color modes, it appears blurry (the transition between colors in a true NTSC display would be more gradual with better gradation between pixels). The purpose of this enhancement is to generate a better drawing method that takes into account how NTSC artifacting works.

The emulator currently counts the number of ticks that each instruction takes when it is executed by the CPU. However, the number of operations per second are in no way limited to the number of operations that could be executed by an actual physical Color Computer 3. The purpose of this issue is to add an instruction execution rate limiter that would temporarily halt executing CPU instructions if the number of ticks surpasses what a real hardware CPU would be able to execute in the same time frame.

The way to achieve this goal is as follows:

• Create a new variable in the Emulator class called remainingTicks that keeps track of how many ticks can be executed for the duration of the cycle.
• Create a new function called refreshTicks in the Emulator class that restores remainingTicks to the correct number of ticks that can be run in a given cycle.
• Run the refreshTicks function within the TimerTask.
• In the main Emulator.run() method, a check should be performed before executing an instruction. If remainingTicks is greater than 0, then the instruction can be executed. If not, skip executing the instruction.

Other emulators have a handy status bar near the bottom of the emulated window that display helpful status information such as CPU clock rate, mounted disk images, mounted tape images, and others. This would be a useful addition to the emulator as it would let you see at a glance what configuration is currently in use.

When a cartridge is configured in the cartridgeROM option for the configuration file, it does not automatically start when the emulator is started.

In a PSHU and PULU, the U register is pushed or pulled instead of the S register. This is causing strange behavior with any applications or games that make use of PSHU and PULU where the S register is meant to be saved instead of the U register.

Now that there is a mechanism to limit the CPU clock cycles, it should be tied to the proper IO address in memory so that the high-speed pokes will work with the emulator. The following IO address ranges control clock cycles:

• $FFD9 - poking a value here will set the clock rate to 1.78 MHz
• $FFD8 - poking a value here will set the clock rate to 0.895 MHz