Some users have reported problems that have been traced to the
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
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