Messages

31

General Discussion / Re: N64 gaming over the internet

« on: August 30, 2017, 04:38:30 PM »

Yep that is the traditional way to do netplay.  This other way would be an alternative for folks who don't own any games to be able to play legally (assuming it is).  It could potentially be extended to serving single player games via a server owned by an individual who owns those games (though even murkier legal situation there)

32

General Discussion / N64 gaming over the internet

« on: August 29, 2017, 08:31:21 AM »

I have been toying around with an idea for a while.  While in practice it may not be feasible (from a speed perspective), it is an interesting question.

The basic idea would be a "core" library which merely does networking.  It would hook up to normal audio, video, and rsp plugins, but would not actually be emulating the core or have a copy of the game ROM.  This library would run on a "client" device.

Then there would be an extension of a normal core library that would run on a "server" device and transmit state information to the client.

The question is whether or not it would be legal to use a system like this for users (on the "server" device) who legally own a ROM to plan games over the network with another user (on the "client" device) who does not own the game.

Obviously nobody here is a lawyer, just thought it would be an interesting topic to discuss.  Probably not even feasible (perhaps more realistic on an emulator for a lower-spec device like the NES).

33

Support / Re: Need help finding a compatible version

« on: August 27, 2017, 07:57:21 PM »

The problem is related to the fact that the Pandigital Novel uses onboard memory as storage.  IO operations that normally work with an external SD card fail.  This can usually be handled by using the getExternalStorageDirectory() function, which version 2.1.3 was already doing ( see https://github.com/mupen64plus-ae/mupen64plus-ae/blob/2.1.3/src/paulscode/android/mupen64plusae/persistent/AppData.java#L189 ).  However I recall that there were some devices that this didn't work on.  I can't recall if we were able to resolve this in a later version of the app, or if onboard memory was just better supported in later versions of Android.

34

Miscellaneous / Re: Problem with computer, help

« on: July 31, 2017, 07:34:52 AM »

Could you provide some more technical detail?  Describe the various programs that you are using and the setup of your network?

35

Other Support / Re: SoundEngine loop stream sound

« on: July 24, 2017, 01:26:18 PM »

I think a better way to handle this would be for the stream thread to place an entry into the command queue, so that it is synchronized with other commands.  Sorry, I've been busy with projects around the house and haven't had a lot of time for programming.  I'll try and make some time to work on this.

36

Other Support / Re: SoundEngine loop stream sound

« on: June 29, 2017, 12:11:53 PM »

Good catch.  I'll play around with it to see if I can find the synchronization issue.  I have a feeling it is a race condition between the streaming thread and command queue thread.

37

General Discussion / Re: N64dd

« on: June 27, 2017, 05:31:39 PM »

Thanks, I'll take a crack at porting it.  Can't promise anything though

38

General Discussion / Re: N64dd

« on: June 26, 2017, 04:38:58 PM »

Anyone know where the libretro-mupen64plus code is for dd?  Did a quick scan on GitHub but didn't see anything obvious in commit history either.

39

Other Support / Re: SoundEngine loop stream sound

« on: June 21, 2017, 08:15:41 AM »

No problem with uploading modified code.. the license is basically a "do whatever you want" license (only restriction really is that if you happen to give me attribution, be sure to mention the website here).

40

Other Support / Re: SoundEngine loop stream sound

« on: June 19, 2017, 11:05:21 PM »

Do you know what specifically is null when that exception is thrown?  If lucky, a null check might fix the problem.  Besides a thread issue, possibly other causes might be an empty buffer or index out of bounds problem (i.e. some corner case in the read process).  Maybe try updating JOrbis if there is a more recent version.

If you can't solve it, setting end of stream should be fine I think.

41

General Discussion / Re: Tsumi to Batsu (Sin and Punishment)- No artwork

« on: May 25, 2017, 06:01:48 AM »

@fzurita, I have set up an account in cPanel, but my host has some weird security restrictions so can't connect with it yet.  I opened up a ticket and will let you know what to do to connect.

42

General Discussion / Re: Tsumi to Batsu (Sin and Punishment)- No artwork

« on: May 23, 2017, 04:38:28 PM »

Sure, I can give you FTP access to that folder.  Sorry for not getting to these updates..

43

Other Support / Re: SoundEngine loop stream sound

« on: May 23, 2017, 12:27:07 PM »

Thanks, I''ll look into this when I get a chance.

Yes, you can increase the number of streaming channels using something like:

Code: [Select]

SoundSystemConfig.setNumberStreamingChannels( 11 );
SoundSystemConfig.setNumberNormalChannels( 21 );

Just have the total number add up to 32.  You'll need to do this before you instantiate the SoundSystem.  The logic for streaming channels has to be a bit more responsive than for normal channels, so depending on the speed of your system and what all else you have going on, you might start hearing gaps in the streams if it can't keep up with the number of channels you have set.

44

Other Support / Re: SoundEngine loop stream sound

« on: May 22, 2017, 12:28:54 PM »

Do you have some sample code for the simplest test case you can simulate the behavior?  In particular playing() returning false when the source is actually playing.

Off hand I'm thinking one issue might be the library running out of available channels.  Typically the sum of streaming and normal channels adds up to 32.  By default I think 4 are reserved for streaming channels and the rest for normal channels if I recall correctly.  If you play more sources than the limit, it will stop a playing channel and replace the source that was playing on it with the newest source.  The old one would show playing() false and the new one true.

Sounds like there may be other issues though, since you mentioned playing() returning false for 1-4 seconds, which is much higher than I have experienced.  Maybe something is broken in newer Java versions (the library is quite out dated at this point).

45

Paul's Projects / 32bit Docker on Tiny Core Linux

« on: May 21, 2017, 08:51:32 PM »

One of the system requirements listed for running Docker is a 64bit host.  I decided to conduct an experiment this weekend to see if I could build a 32bit version of Docker and have it run on 32bit Tiny Core Linux.  If it works, this could in theory be combined with an x86 emulator like QEMU to run docker containers from your Android phone..

The first step was to build a 32bit version of Docker Daemon and Docker Client.  I found a nice recipe for doing this HERE.  I had to tweak it a bit (require checking out tag 17.04.0-ce, and using this revision of the Dockerfile).

Then I installed Tiny Core Linux 8.0 x86 in Virtual Box, and after a lot of tinkering, came up with the following recipe to get the Docker Daemon to run without crashing:

Code: [Select]

tce-load -wi bash git procps xz ca-certificates iptables net-bridging-4.8.17-tinycore

sudo ln -s /usr/local/etc/ssl /etc/ssl

sudo addgroup docker
sudo addgroup tc docker

sudo mkdir /mnt/sda1/docker
sudo mkdir /mnt/sda1/docker/run
sudo mkdir /mnt/sda1/docker/lib
sudo chown -R root:docker /mnt/sda1/docker
sudo chmod -R 770 /mnt/sda1/docker
sudo ln -s /mnt/sda1/docker/run /var/run/docker
sudo ln -s /mnt/sda1/docker/lib /var/lib/docker

echo "etc/passwd" >> /opt/.filetool.lst
echo "etc/group" >> /opt/.filetool.lst
echo "etc/shadow" >> /opt/.filetool.lst
echo "etc/gshadow" >> /opt/.filetool.lst
echo "etc/profile.d" >> /opt/.filetool.lst
echo "etc/ssl" >> /opt/.filetool.lst
echo "etc/os-release" >> /opt/.filetool.lst
echo "var/lib/docker" >> /opt/.filetool.lst
echo "var/run/docker" >> /opt/.filetool.lst

echo "#!/bin/bash" >> /etc/profile.d/paths.sh
echo "export PATH=\$PATH:/home/tc/dockerd:/home/tc/docker" >> /etc/profile.d/paths.sh
chmod 755 /etc/profile.d/paths.sh

sudo touch /etc/os-release
sudo chown root:staff /etc/os-release
sudo chmod 664 /etc/os-release
echo "NAME=\"Tiny Core Linux\"" >> /etc/os-release
echo "ID=tinycore" >> /etc/os-release
echo "VERSION_ID=\"8.0\"" >> /etc/os-release
echo "PRETTY_NAME=\"Tiny Core Linux v8.0 x86\"" >> /etc/os-release
echo "HOME_URL=\"http://tinycorelinux.net/\"" >> /etc/os-release
echo "BUG_REPORT_URL=\"http://forum.tinycorelinux.net\"" >> /etc/os-release

cd ~
mkdir dockerd
mkdir docker

cd ~/dockerd
wget http://www.paulscode.com/downloads/dockerd.zip
unzip dockerd.zip

wget https://raw.githubusercontent.com/tianon/cgroupfs-mount/master/cgroupfs-mount
chmod 755 cgroupfs-mount

cd ~/docker
wget http://www.paulscode.com/downloads/docker.zip
unzip docker.zip

Then after a reboot:

Code: [Select]

sudo su
export DOCKER_RAMDISK=true
ulimit -Hn 65535
ulimit -Sn 65535
cgroupfs-mount
dockerd

However, when I ran a test of Docker Client, it failed with an error message about insufficient disk space.  This was related to a message from the Docker Daemon complaining that the kernel didn't support the "overlay" filesystem.  I ended up having to rebuild the Tiny Core kernel, setting flags "CONFIG_OVERLAY_FS" and "CONFIG_CFS_BANDWIDTH"

Code: [Select]

wget http://tinycorelinux.net/8.x/x86/release/src/kernel/linux-4.8.17-patched.txz
wget http://tinycorelinux.net/8.x/x86/release/src/kernel/config-4.8.17-tinycore
tar -xvf linux-4.8.17-patched.txz
cp config-4.8.17-tinycore linux-4.8.17/.config
cd linux-4.8.17

gedit .config
    CONFIG_OVERLAY_FS=y
    CONFIG_CFS_BANDWIDTH=y

make bzImage
Then I put the generated bzImage into the boot directory at /mnt/sda1/tce/boot, and and updated the bootloader:

Code: [Select]

DEFAULT bzim
LABEL core
KERNEL /tce/boot/vmlinuz
INITRD /tce/boot/core.gz
APPEND quiet  waitusb=5:UUID="fee3c2ac-3bf2-4aa1-ae8e-73fa95f4ea2c" tce=UUID="fee3c2ac-3bf2-4aa1-ae8e-73fa95f4ea2c"
LABEL bzim
KERNEL /tce/boot/bzImage
INITRD /tce/boot/core.gz
APPEND quiet  waitusb=5:UUID="fee3c2ac-3bf2-4aa1-ae8e-73fa95f4ea2c" tce=UUID="fee3c2ac-3bf2-4aa1-ae8e-73fa95f4ea2c"

Finally, after a reboot, I am able to successfully run Docker containers in 32bit