Some users have reported problems that have been traced to the following cause: 1) Some of the ".ent" file programs depend on the Solos/Cutter routines to perform keyboard input. 2) Some CP/M implementations being run on Sols either configure the hardware in a way that is incompatible with Solos/Cutter or use the Solos/Cutter 1K RAM area in such a way that the keyboard routines can not function correctly. Observed behavior is that the program seems to function correctly up to the point where some keyboard input is required. Workaround: RUNENT places no restrictions on the start address specified on its command line. Use this to transfer control back to the Solos/Cutter initialization code (usually C000H). This will result in the screen being cleared and a Solos prompt '>' presented, once the ".ent" file is loaded. Then, at the Solos prompt, use the execute command "EX <address>" to run the loaded program. Example: A>RUNENT CUBIC.ENT :C000 <program load output here...> 0700: 07 EB 22 10 07 7D 93 6F 7C 9A B5 32 12 07 E1 C9 0710: 56 E4/ <screen clears, Solos prompt appears> <cubic runs normally> It is also possible that some systems may disable the Solos ROM as CP/M boots. Enabling/disabling the Solos ROM is a custom hardware modification that can be accomplished in a number of ways, so you will need some understanding of your system and of assembly level programming. You will need to write a small program at some unoccupied address range that reenables the ROM and then jumps to the ROM init address. This program will need to be converted into an ".ent" file and loaded along with the desired application (RUNENT can load two ".ent" files) and jumped to using the start address command line parameter.