search

shokre / orao-cc65

cc65 runtime for Orao
zlib License
1 stars 0 forks source link

[feature] Could you please integrate this in official CC65? #1

Open Fabrizio-Caruso opened 1 year ago

Fabrizio-Caruso commented 1 year ago

Hi, I would like to use your work in my project (https://github.com/Fabrizio-Caruso/CROSS-LIB), which uses the very latest versions of CC65. Since Cross-Lib supports the most up to date CC65 versions, it would be more convenient for me to use the official CC65 versions.

Could you please integrate your work in CC65?

shokre commented 1 year ago

Thank you for your interest in this project.

I plan to integrate this project into CC65 at some point in the future, but as of now, I'm afraid it's not yet stable enough.

Original documentation for ORAO is severely lacking in details and has a lot of errors, so I've resorted to disassembling ROM images, and mapping entrypoints, which is a slow and tedious process.

ORAO has 2 different ROMs v.102 and v.103 which are incompatible (routines have different addresses). I'm not sure how popular is v.102, because company (PEL Varaždin) offered free replacement to v.103.

ORAO has no graphics chips, so all graphics and text drawing routines are implemented in software.

All ORAO text routines expect 0x04 at the end of string, while C uses 0x00. (puts.s) I've solved this by writing _orao_puts in C which uses 0x00 as terminating character, but calls original ORAO_SYS_PUTC in ROM.

Upon inspection of ROM disassembly of drawing routines, I've found that they are unoptimized and slow (character drawing inner loop even contains noops??). But I don't have access to real hardware, so I cannot exclude that these noops are really necessary because of some hardware timing issue.

At this point I'm not sure which route to take:

  1. Write a minimal runtime that calls ORAO ROM routines (slow but small runtime, works only on one version of ROM)
  2. Write optimized runtime (fast but bigger runtime, works with any version of ROM)
Fabrizio-Caruso commented 1 year ago

@shokre I understand your point. I would suggest that you do not wait for the perfect work because if you ever integrate your work into CC65, I would be able (after some work on how to do input/output) to compile all my Cross-Lib games (currently 6 + 1 to be released soon) for the ORAO and more people would be interested into trying it out on possibly the real hardware.

Fabrizio-Caruso commented 5 months ago

Hi again @shokre, I invite you again to integrate a very minimal version into cc65. cc65 already contains targets with a minimal library with almost no input/output routines (e.g. Supervision, Atari 2600, etc.) and other people have been motivated to improve/debug them. In any case, you will probably get feed-back from other people. For instance I would be able to use it more easily because I am already using cc65 and I am not sure how to use standard cc65 with your fork at the same time in my Cross-Lib project.

shokre commented 5 months ago

I agree. It seems that I should integrate a minimum viable implementation. I just need to get myself familiar with cc65 requirements for a platform merge request.

As to your question on how to use it with existing cc65: this is not actually a fork of cc65 - this works alongside existing cc65 install by using custom config and orao.lib binary to link against (see: https://github.com/shokre/orao-cc65/blob/master/examples/shared.mk)

Custom config is also tailored for creating .prg files which can be used (and only used, AFAICT) by my modified Orao emulator: https://github.com/shokre/OraoPy

Fabrizio-Caruso commented 1 month ago

Hi again! If this already works with the latest cc65, what makes the full integration hard to implement?