jbrandwood / liberis Goto Github PK

In the examples/fxpad example, when this runs on a real machine, the pad type appears as "NONE" when FX-PAD is attached, or when mouse is attached. This is because the return value of eris_pad_type is always 0 on a real machine.

On Mednafen, eris_pad_type() returns values which match the input type - but this is not the same behaviour as on a real PC-FX.

There's an example in examples/scsi_dma that is supposed to show a 16-colors picture on screen streamed from the CD drive.
This is what it's supposed to do :
https://www.youtube.com/watch?v=qOoQivbpcZQ

Instead however, this happens

I'm gonna get a PC-FX soon i hope but he said before it was working on Mednafen. It's entirely possible however that they broke it since then.
Or the code pushed out to bitbucket never worked in the first place.

I also tried the older GCC with his older code and it behaves pretty much the same on Mednafen.

Virtually all games need some form of randomness; a pseudo-random number generator would be handy.

It tooks me some times to understand why examples were compilable.

1/ V810 GCC /bin must be on the PATH (see https://github.com/jbrandwood/v810-gcc)
2/ pcfx tools must be on the PATH (see https://github.com/jbrandwood/pcfxtools)
3/ V810GCC var must be defined (export V810GCC='<your path to v810 -gcc folder (not bin)>')
4/ make
5/ make install
6/ make example_cds

I missed step 3 and 5 ;)

perhaps you could add

ifeq ("$(V810GCC)","")
$(error V810GCC undefined)
#export V810GCC=<path to your sdk/bin/v810-gcc>
endif

on makefile ;)

Most (or possibly all) of the examples are creating an exception condition on the Mednafen console output:

Exception: ffffffb0 ffbe

I have determined that this happens because the program reaches the return(0); or exit(0); statement at the end of the main{} section.

The examples should be updated to end in an infinite loop rather than reaching then end of the main() function.

This is actually 2 issues:

1. include/eris/tetsu.h has a typo - "TETSU_DOTCLOCK_7MHz" is actually defined as "TETUS_DOTCLOCK_7MHz" in the enum.

2. Even when that is corrected, the "Hello World" example doesn't display any differently... so I question whether the eris_tetsu_set_video_mode() function is working properly (or conversely, whether there are other issues in the example code).

The System Function Vector (0xFFF00008) has interfaces into the BIOS for some purposes.
One such purpose is related to backup memory, and this is documented by Mednafen's SYSLOG trace to "SYSCALL" functions.

For example, starting "Chip Chan Kick" will log various functions such as:
fsys_init()
fsys_ctrl()
fsys_chdir()
fsys_getfsys()
fsys_mkdir()
fsys_diskfree()
fsys_open()
fsys_read()
fsys_write()
fsys_close()

Based on this existing (partial) documentation of the existing API, we should be able to create examples which are safer than a FAT filesystem implementation we build ourselves.

Instead of 'eris_' prefixing all functions, the functions should be descriptive of the subsystem they refer to.

Examples:
vdc_
king_
etc.

Hey there, looking into tinkering with some PC-FX game making. I am not very knowledgeable about compilers or the toolchain so I could be doing something very dumb.

I have v810-gcc built, it's in my path and same with pcfxtools (I did build this after I was getting my error though). When I run make examples, it fails when trying to build the first example. Here's the output:

c/v810-gcc//v810/lib/crt0.o hello.o -leris -lc -lsim -lgcc -o hello.elf -Map hello.map v810-ld: cannot find -lgcc make[2]: *** [../example.mk:41: hello.elf] Error 1 make[2]: Leaving directory '/home/laconic/projects/liberis/examples/hello' make[1]: *** [Makefile:29: cd] Error 2 make[1]: Leaving directory '/home/laconic/projects/liberis/examples' make: *** [Makefile:42: example_cds] Error 2

Someone previously raised an issue about the linker but I'm not sure what I'm supposed to do to fix it. Thanks.

In the top-level Makefile, line 11 is:
CFLAGS = -O3 -I include

...but I found build errors in the examples when I used the top-level script - the 'include' directory is empty, except for the 'eris' subfolder.

Changing line 11 in the top-level Makefile to this works:
CFLAGS = -O3 -I include/eris

7up function need an overhaul:

7up library functions have a high-level and a low-level API.

1. Although there are differences in the names to ensure they are separate ("low"), one of these levels uses "7up" in the function and variable names, and the other uses "sup".

2. Also, the generated documentation only displays the functions of one of these levels.

3a) There should be macro definitions for register names, and bitfields within the registers
3b) The sole existing enumerated value used in this subsystem is defined twice - once at the high level, and once at the low level

when I try to 'make examples' it bails out with:

crt0.o: In function _main': (.text+0x64): undefined reference to _zdalimit'

as well as _zdaend, _zdabss, _zdadata, _edata

I am quite sure that all else is set up properly.
It appears to be only the v810-ld step causing this error (also when trying to compile other PC-FX projects).

Does that ring a bell? Could it be that the linker script (which mentions those) somehow doesn't do as it should?
Or something missing on my part?
Thanks you very much - any help is appreciated

As part of renaming work (later on) which will include breaking changes, put the include files into a "pcfx" subdirectory rather than "eris".

low-priority for now.

Some special effects examples should eventually be made available:

• raster effects (7up)
• rotation, tiling, scaling (King)
• combination effects (like "mode 7" on SNES is possible)

The cellophane example is interesting, but would be better if:

1. the foreground was not pseudo-random junk, and
2. if there was another layer which didn't fade.

The PSG example sounds noisy, and could benefit from some more flexibility to demonstrate its capabilities.

The sprite example uses pseudo-random data to form the display data of the sprite itself.
Because of this, it looks like something terrible happened to the build process ending in corruption.

This should be fixed to use data which looks like SOMETHING.

This also implies sufficient commenting for a user to understand:

1. What the example is actually demonstrating, and how to use it (i.e. keypresses, whether it flashes, etc.)
2. How it is accomplishing this, and calling out the relevant commands/activities.

This is a more all-encompassing issue (and may account for part of the reason that the pad_type isn't working properly).

1. The read joypad routine assumes that there is zero time between issuing a scan command and being able to read the data.
2. The control register for "data ready" is misunderstood, and should be the determining factor on whether to read the data value after issuing a read command
3. The initialize function sets the data port to "output" mode rather than input mode
4. The "clear" signal (to send a reset value on scan) is never sent, and probably completely misunderstood.

Hello,
thought i would write up for future reference what is missing and should be fixed or implemented.
Here's a non exhaustive list :

• Proper open source tools to convert Huc6272-BG format.
  For Legal and pratical reasons, we should write our own tools to convert them directly.
  I wrote this https://github.com/gameblabla/bmp2huc for converting images for the 8/16bpp color formats.
  24bpp and 4bpp are missing however.

• Provide higher-level functions for ADPCM and CD-DA and bundle them as part of liberis.
  I'm working on that here : #2 but what i didn't do for ADPCM at least was to provide them as high-level functions within liberis itself. I will do that once i can get it fully cleaned up but obviously i would need some help on that...
  So far, i've only did so for CD-DA.

• Fix issue with gamepad controls
  Oldrover was complaining about the gamepad code on real hardware not working unless it's called twice and using the high byte instead.

Unlikely to be fixed/implemented anytime soon

• MJPEG support through RAINBOW chip.
  It seems to be woefully documented sadly. This would also need either a conversion tool or a fork of libjpeg to directly support the RAINBOW variant. (which seems to be very similar)

• Aurora 3D chip.
  PC-FX GA SDK does support it but it is quite a tall order to support. Maybe we could just disassemble the proprietary libraries or make GCC support them ?

All assembly-language functions should have comments for readability/support purposes:

Minimally:

1. To define the inputs and outputs of functions (and relevant data types).
2. To explain any "magic numbers" used in the code.

And on more complex functions:

1. To give an overview/description of how the function is implemented, so that flow can be followed easily.