65 Reply by uXe

(244 replies, posted in Nintendo Handhelds)

rvan wrote:

The code I posted earlier (p. 3), which only increments a variable in the ISR (serial is done in the work loop), demonstrates the same problem.  I also wrote an even simpler version which sends a pulse on an output pin when the clock ISR is called.  I compared the output signal with the clock signal using a DSO (which may not be entirely reliable for this application) and found that the ISR was not being triggered for most of the clock pulses.  I can post this code if you are interested.

I would be interested, yes. smile

Again, the code you posted earlier is also doing a Serial.write on every HSYNC, and I can't help but think that is eating up a lot of cycles and again would suggest to maybe try storing those values in an array or something instead, and then Serial.write them out once you've collected a certain amount to see if that has any effect on the count?

Go to forum: Nintendo Handhelds

66 Reply by uXe

(244 replies, posted in Nintendo Handhelds)

I still think it is worth trying friendofmegaman's code without the Serial.write slowing down the interrupt to see what difference it makes, as I wrote earlier:

http://chipmusic.org/forums/post/206984/#p206984

Also, using low-level AVR port manipulation commands (PORT, PIN, DDR) isn't necessarily going to speed things up on a Teensy 3.x (ARM) because they just end up going through another level of AVR to ARM emulation:

http://github.com/PaulStoffregen/cores/ … mulation.h

http://forum.pjrc.com/threads/17532

You need to actually use ARM low level commands! Grab the MK20DX256 manual here:

http://www.pjrc.com/teensy/datasheets.html

and check out Chapter 11 - Port control and interrupts (PORT) and Chapter 49 - General-Purpose Input/Output (GPIO)

Go to forum: Nintendo Handhelds

67 Topic by uXe

(1 replies, posted in Commodore Computers)

http://github.com/papawattu/SidPi

Go to forum: Commodore Computers

68 Reply by uXe

(244 replies, posted in Nintendo Handhelds)

You could take a chip like this:

http://www.digikey.com.au/product-detai … ND/2354748

which will output analog RGB video if you can get it to swallow the GameBoy's sync / clock / data signals?

Datasheet here: http://read.pudn.com/downloads122/ebook … 152007.pdf

Go to forum: Nintendo Handhelds

69 Reply by uXe

(244 replies, posted in Nintendo Handhelds)

friendofmegaman wrote:

I can only detect 70 clocks between two HSYNCs...

The sketch:

#include <avr/io.h>
#include <avr/interrupt.h>

const int pVsync = 2;
const int pClock = 3;
const int pData0 = 4;
const int pData1 = 5;
const int pHsync = 6;


volatile unsigned char pixels_in_line = 0;

void setup(){
  Serial.begin(1);
  
  pinMode(pClock, INPUT);
  pinMode(pHsync, INPUT);
  pinMode(pVsync, INPUT);
  pinMode(pData0, INPUT);
  pinMode(pData1, INPUT);

  
  attachInterrupt(pClock, readClock, FALLING);
  attachInterrupt(pHsync, readHsync, RISING);  
}

void loop() {}

void readHsync(){
   Serial.write(pixels_in_line);
   pixels_in_line = 0;
}


void readClock(){
  pixels_in_line++;
}

the Serial.write might be slowing down your interrupt - maybe try storing those values in an array or something instead, and then Serial.write them out once you've collected a certain amount to see if that has any effect on the count?

Go to forum: Nintendo Handhelds

70 Reply by uXe

(244 replies, posted in Nintendo Handhelds)

friendofmegaman wrote:

Guys, have you actually benchmarked USB serial in Teensy? I'm a bit worried because of this page http://www.pjrc.com/teensy/usb_serial.html. It doesn't show very high speed which means we might need to keep our data as small as possible.

Even the very worst case benchmark on that page of 639 kbytes/sec (654336 bytes) using your current frame size of 5760 bytes would still mean 113.6 frames per second, so what's the problem?

Go to forum: Nintendo Handhelds

71 Reply by uXe

(244 replies, posted in Nintendo Handhelds)

friendofmegaman wrote:

What else can be done to optimize the code I don't know yet sad

this might help?

http://www.seanet.com/~karllunt/bareteensy31.html

Go to forum: Nintendo Handhelds

72 Reply by uXe

(244 replies, posted in Nintendo Handhelds)

Baud Rate isn't going to change anything with a Teensy:

"Data is always transferred at full USB speed. This is merely the setting selected by the PC or Macintosh software, which is not used by USB. You do NOT need to constrain your transmission to this rate. However, many serial communication programs are coded very inefficiently because the programmer assumes "slow" data. You can easily overwhelm these programs, even when running on very fast machines, if you sustain full USB speed transfers!

Likewise, the host does not enforce this baud rate upon the software that is sending data to you. However, unlike real serial communication where you could lose data if you do not read fast enough, USB will always buffer data until you have read it. If the software does not implement timeouts, you may read at any speed and never lose a byte."

Go to forum: Nintendo Handhelds

73 Reply by uXe

(244 replies, posted in Nintendo Handhelds)

You could try ignoring HSYNC and just start a new line manually every 160 pixels? I also wanted to suggest sending the data after the 144th line where it looks like there is a nice gap in the timing, rather than on VSYNC?

Go to forum: Nintendo Handhelds

74 Reply by uXe

(59 replies, posted in Atari)

OK, download the code again, then insert a line at the very beginning of the doCC, doNote, and doNoteOff functions:

channel = channel - 1;

Go to forum: Atari

75 Reply by uXe

(59 replies, posted in Atari)

Looks like the code is referencing Channel 1 as 0 and Channel 2 as 1, so I'm suspecting the problem may be that the Teensy libraries have been updated at some point to refer to Channel 1 as 1, and Channel 2 as 2 - editing the code to reflect this may solve it?

Go to forum: Atari

76 Reply by uXe

(244 replies, posted in Nintendo Handhelds)

...if you want ease-of-use and cross-platform-compatibility on the computer side, then you could take an old PS2 EyeToy webcam which contains a OV519 camera-to-USB processor, and then use your Arduino to take the GameBoy's video data and bend it into a format that matches what the camera sensor sends into the OV519!

Go to forum: Nintendo Handhelds

77 Reply by uXe

(11 replies, posted in Trading Post)

PM'd!

Go to forum: Trading Post

78 Reply by uXe

(20 replies, posted in Other Hardware)

jackary wrote:

In regards to the LCD for the Pi - check out this project. It's super cheap for what it is!

There are a heap of compatible LCD shields and modules already available - no need to wait for a Kickstarter...

http://github.com/notro/fbtft/wiki/LCD-Shields
http://github.com/notro/fbtft/wiki/LCD-Modules

Go to forum: Other Hardware

79 Reply by uXe

(19 replies, posted in Nintendo Handhelds)

You would need to use MIDI-Yoke as a virtual 'patch cable' between FL Studio and MIDI-OX to monitor what it is sending out:

http://www.midiox.com/myoke.htm

Go to forum: Nintendo Handhelds

80 Reply by uXe

(19 replies, posted in Nintendo Handhelds)

You could try using something like http://www.midiox.com/ to look at what exactly is being output from FL Studio and Reaper, and if there is any difference in the actual MIDI commands being sent? and if so, use a little bit of scripting to make them match...

Go to forum: Nintendo Handhelds