Trying to run the game on OSI C1P emulator about cross-lib HOT 6 CLOSED

Ohio Scientific Challenger 1P is not officially supported because I myself have not tested it.
I am also trying to run the game on the Ohi Scientific Challenger but I could not figure out which emulator and how to use it. Could you please send me a link of the version of the emulator used?

from cross-lib.

I'm aware of the following emulators:

• The WinOSI Emulator. Use the newest version OsiEmu15.zip.
• The web-based C1Pjs emulator.

Note that output of cc65 "osic1p" target cannot be loaded directly, neither into an emulator nor on a real machine. The cc65 executable must first be converted with the "srec_cat" program from the SRecord 1.64 tool collection into a format that can be uploaded via the serial port (see http://cc65.github.io/doc/osi.html#toc3 and http://srecord.sourceforge.net/).

I used the following Makefile target to build a file that can be loaded into an emulator or into a real machine:

osic1p:
    $(CC65_PATH)$(MYCC65) --start-addr 0x200 -Wl -D,__HIMEM__=0x8000 -O -t osic1p -DFULL_GAME $(SOURCE_PATH)/display_macros.c  $(SOURCE_PATH)/enemy.c $(SOURCE_PATH)/invincible_enemy.c $(SOURCE_PATH)/level.c $(SOURCE_PATH)/character.c $(SOURCE_PATH)/text.c $(SOURCE_PATH)/missile.c $(SOURCE_PATH)/strategy.c $(SOURCE_PATH)/input_macros.c $(SOURCE_PATH)/main.c  -o $(BUILD_PATH)/FULL_osic1p.lod
    srec_cat $(BUILD_PATH)/FULL_osic1p.lod -binary -offset 0x200 -o $(BUILD_PATH)/FULL_osic1p.c1p -Ohio_Scientific -execution-start-address=0x200

To load the file into the WinOSI emulator, proceed as follows:

• Start the WinOSI executable.
• Under "Options" select "System Configuration...".
• Select "OSI C1P / Superboard II (600 BOard)" as machine type.
• On the "System ROMs" tab under "Specify ROM Type" select SYN600.
• Press "OK"
• Under "File" select "Attach Serial Input File...".
• Select the file "FULL_osic1p.c1p".
• In the emulator window you should see the "D/C/W/M" prompt. Press "M" to run the monitor. You then should see the "0000 00" prompt of the machine monitor.
• Press "l" (lowercase L). This will load the program and start it.

To load the file into the C1Pjs emulator, do the following:

• Open the 32kB OSI C1P machine in your browser.
• Click the "BREAK" button. The "D/C/W/M" prompt appears.
• Press "M" to enter the monitor. You should see the "0000 00" prompt of the machine monitor.
• Click the "Select file" (or language-dependent equivalent) button and select the file "FULL_osic1p.c1p".
• Click the "Mount" button. The program is loaded and starts.

I was the author of the "osic1p" cc65 target including the conio implementation. It is not extensively tested, therefore there may certainly be bugs in it. The c1pctest repository contains some test programs for the "osic1p" cc65 target. I have attached the loadable file misctest.c1p (renamed to "misctest.c1p.txt" for being able to attach it here) for the misctest.c source so you can test the above loading procedures with a working program.

from cross-lib.

Thanks a lot! I am going to test the game!

from cross-lib.

Thanks a LOT for your report!

The problem is the kbhit/cgetc implementation for the OSIC1P target:
it does not detect key-presses or wait for the input locking the computer.
Maybe the problem is kbhit consuming the key press it is only supposed to detect and not consume.

If I remove WAIT_PRESS, you get the game "sort of working" in a turned-based version, i.e., no action game because it waits for the next key press.
If you take the latest version from my GitHub repo, you can play the game.
My makefile can compile three versions (TINY, LIGHT and FULL) for the Ohio Scientific 1P to cover different ram configurations.

Could you please fix kbhit and cgetc and have them behave as in the other targets:
kbhit should just test whether a key is pressed WITHOUT consuming the key press (cgetc should still be able to read it)
cgetc should read the pressed key

from cross-lib.

I have opened an issue for you
cc65/cc65#511

from cross-lib.

@smuehlst I am closing this issue because the root cause is in the implementation of kbhit and maybe cgetc for the OSIC C!P target, which is not functionally corret.
We can follow this in cc65/cc65#511.

from cross-lib.