yupferris

chaserTest : device "Chaser Test" (0 0)
(
    primaryInterval : interval "Primary Interval (60fps)" (20 20) 60
    chaserInterval : interval "Chaser Interval (2fps)" (20 100) 2
    plasma : plasma "Plasma" (20 180) 36 4
    chaser : chaser "Chaser" (20 260)
    fadecandy : fadecandy "Fadecandy" (20 340) "127.0.0.1" 7890
	
    primaryInterval.Output -> plasma.Time
    primaryInterval.Output -> chaser.Time

yupferris

extern crate libc;

use std::mem;

struct Val {
    value: i32
}

impl Val {
    fn new(value: i32) -> Val {

yupferris

//! A basic output stream example, using an Output AudioUnit to generate a sine wave.

extern crate coreaudio_rs as coreaudio;
extern crate num;

use coreaudio::audio_unit::{AudioUnit, Type, SubType};
use num::Float;
use std::f64::consts::PI;

yupferris

//! A basic output stream example, using an Output AudioUnit to generate a sine wave.

extern crate coreaudio_rs as coreaudio;
extern crate num;

use coreaudio::audio_unit::{AudioUnit, Type, SubType};
use num::Float;
use std::f64::consts::PI;

yupferris

$ git clone git@github.com:ZachBray/FunScript.git
Cloning into 'FunScript'...
remote: Counting objects: 4780, done.
remote: Total 4780 (delta 0), reused 0 (delta 0), pack-reused 4779
Receiving objects: 100% (4780/4780), 54.45 MiB | 4.53 MiB/s, done.
Resolving deltas: 100% (2620/2620), done.
Checking connectivity... done.
$ cd FunScript/
$ chmod +x build.sh # See fix for this in pull request #194
$ ./build.sh

yupferris

$ ./ProDBG/t2-output/macosx-clang-debug-default/ProDBG.app/Contents/MacOS/prodbg 
ProDBG_create a
ProDBG_create b
ProDBG_create c
ProDBG_create d
ProDBG_create e
/Users/yupferris/dev/projects/ProDBG/src/prodbg/core/settings.cpp:252 ERROR JSON Error: data/settings.json:(-1:-1) - unable to open data/settings.json: No such file or directory
ProDBG_create f
ProDBG_create g
ProDBG_create h

yupferris

$ ./t2-output/macosx-clang-debug-default/ProDBG.app/Contents/MacOS/prodbg 
ProDBG_create
[0:00:00.003] <570f:0> Started thread 'fs_monitor' (570f) ID 400
BgfxPluginUI::create 0x0 (1024 768)
[0:00:00.018] <570f:0> Started FS event stream for: t2-output/macosx-clang-debug-default
[0:00:00.018] <570f:0> Monitoring file system: t2-output/macosx-clang-debug-default
cerated dock grid 0x0
Unable to load data/current_layout_2.json
fastOpenKey 0x4f5
toggleBreakpointKey  0x1290

yupferris

$ fuse preview
Build started: FullCompile
Configuring
(2,250.51 ms)

Parsing source code
(376.84 ms)

Compiling syntax tree
(1,423.76 ms)

yupferris

Hey, so I was thinking about yupferris/rustendo64#15, yupferris/rustendo64#20, and yupferris/rustendo64#21, and I'm starting to get the feeling that these contributions might be becoming a bit too significant if that makes any sense. The main point of this project was to document all of the thought processes and resources that went into everything, and the unfortunate part of accepting certain PR's is that we lose quite a lot of that for significant amounts of code that I can't go over on the stream. So, while I certainly appreciate the contributions (they've been great so far), and I'm super stoked you guys are excited about and interested in the project, part of me is a bit on the fence in terms of accepting these.

I can also understand that I hadn't really set a precedent for what I would/wouldn't accept early enough in the project; to be honest I didn't really anticipate receiving any contributions for quite some time. This whole t

yupferris

Generally, the emulator core should be more or less a black box, where you tell it to step and give it some sinks for audio/video, and it tells you how many clock cycles passed while stepping and it may or may not dump some data into those sinks. For the most part, the VirtualBoy struct already has this interface, along with AudioDriver and VideoDriver as sinks. However, it's a bit crap right now as the emu also relies on audio for a timing source, which means we can't really have a configuration that doesn't use that atm.

The reason we want to use audio as a timing source is because audio cards tend not to have timers that are perfectly synced to the computer's timer, esp. at weird sample rates. As a consequence, there will be periodic clicks and pops as the audio output buffers and the emulator go slightly out of sync. Relying on audio output as a timing source fixes this, but couples us to audio output.

It would be nice to have some kinds of abstractions; for example, a TimingSource abstraction,