49 Reply by yogi

(9 replies, posted in Circuit Bending)

Of the few I've messed with, really liked a 'bird clock'. Each hour it would play a clip of a different bird. Like alot of these sound circuits, you can change the playback speed by changing a timing resistor. With the bird circuit, you can really speed up and slow down the audio, till it sounded very alien. The biggest drawback is you can't control the order of the 12 clips, so for a favorite one you need to cycle through the others.
Yogi

Go to forum: Circuit Bending

50 Reply by yogi

(98 replies, posted in Other Vintage Computers & Consoles)

OK so it builds on RPi2 B+ with Raspbian Jessie \o/
From the /doc/Building on Linux
installed these:   
build-essential automake autoconf autoconf-archive libx11-dev libxext-dev libxv-dev libxxf86vm-dev libsdl1.2-dev libasound2-dev mercurial libtool

But  libxxf86misc-dev isn't in the Debian respo. So it didn't get installed.

I also went through the list of deps for this SchismTracker package:
https://packages.debian.org/stable/sound/schism
They were all up to date on my system.

Then ran
mkdir -p build && cd build && ../configure && make
../configure seemed to finish but make failed with:
...
make  all-am
make[1]: Entering directory '/home/pi/schismtracker/build'
/bin/bash: schism/.dirstamp: Permission denied
Makefile:861: recipe for target 'schism/.dirstamp' failed
make[1]: *** [schism/.dirstamp] Error 1
make[1]: Leaving directory '/home/pi/schismtracker/build'
Makefile:765: recipe for target 'all' failed
make: *** [all] Error 2

So tried changing permissions:
pi@raspberrypi:~ $ sudo chmod a+rw /home/pi/schismtracker
This didn't help. But then tried just 'sudo make' and this created a bin smile

Most of it works fine, in QjackCtl are the Midi In and Out ports; but had to go into .schism/.config and add:
[Audio]
...
  driver=alsa:default
to get sound out. So this loads the driver and plays great, but I can't have Jack open. I tried
  driver=alsa:dmix and just alsa but these didn't work. I'm not real sure if the dmix applies to Deb or I should be using some other argument.
Anyway, I still have to check out midi sync into other apps without Jack, but it's working very well at this point. I'll copy the bin to my dropbox if anyone needs it.
Yogi

Go to forum: Other Vintage Computers & Consoles

51 Reply by yogi

(98 replies, posted in Other Vintage Computers & Consoles)

sandneil wrote:

there be a new release for windows and linux

osx forthcoming... hopefully

and we are trying to sort out continuous integration so we can do more regular releases

https://github.com/schismtracker/schismtracker/releases

This is awesome! Thanks so much, I've always been torn between Schism and Milky. But with the improvements to midi sync this really tips the scales for me. AND Adlib samples, WOW smile

Will be interested in building on the RPi (there is a SchismTracker in the repo but it's 2011 01 01 ver).
Yogi

Go to forum: Other Vintage Computers & Consoles

52 Reply by yogi

(105 replies, posted in Other Vintage Computers & Consoles)

Charbot wrote:

4mhz- same as the original.    here is the exact part i used, but you can find them anywhere.       
http://www.jameco.com/z/OSC4-4-MHz-Full … 27967.html
remember full-can!

I would like to get some boards made but I have a lot on my plate right now and not a lot in the coffers....
Perhaps if there was a bit more interest.  If i knew i break even, id be much more inclined to get the ball rolling.    (I am going a head w/ the knobby controller wink   
Sorry- keep forgetting to post the eagle files to github.   will try to get to is soon.    You could prob get a 1-off from oshpark, but it would be expensive.

really home etching is not hard...  and it opens up a whole world as electronics tinkerer

I'm a big fan of OSH Park for small projects. It opens things up for DIYers at a reasonable price.  At $5 per sq inch of design it works out to ~ $1.67 per board sq inch. And finding 2 other people that want a board is easier. Where as one can get better prices with larger runs,  but as you say it's hard to judge if you can break even.
Yogi

Go to forum: Other Vintage Computers & Consoles

53 Reply by yogi

(10 replies, posted in Releases)

Love the bass line on Cell Synthesis, so good smile
Yogi

Go to forum: Releases

54 Reply by yogi

(20 replies, posted in Commodore Computers)

Peng wrote:

Awesome guys great feedback. I've gotten hold of a newer C64 with a mssiah cart so Ill start there.
What do I need extra if I want to use any other tracker?`Or any other  tips. Like is it a good idea to have a SD card reader?

YES to an SD card interface. IMO it's almost a bare essential for most retro systems to be useful now-a-days. I do respect those that want a 'full experience' with floppy drives  and data recorders and original media. But for cross development, and chip tuning with PC tools like GoatTracker, you need some (fast) way to move between the systems. Here is some basic info-
http://www.c64-wiki.com/index.php/SD2IEC
You could also go the Flash Cart route.
Yogi

Go to forum: Commodore Computers

55 Reply by yogi

(50 replies, posted in Other Hardware)

Just tried the edits, one at a time. No change in the behavior.
There is another point that I didn't fully notice yesterday. The comms start to work right  when I:

1 Select ttyAMA0
2 ****Send Note On/Off messages to editor, the first 2 or 3 key presses are silent, thereafter the synth sounds.****
3 De select ttyAMA0 or shut down the Editor.
4 Select ttyAMA0 again, now the the Editor will refresh.

I hadn't noticed that step 2 was needed but I was doing it when it worked yesterday. Just tried Select-Deselect-Select with no Note messages and that didn't.
Yogi

Go to forum: Other Hardware

56 Reply by yogi

(50 replies, posted in Other Hardware)

Great, will do!
one question-the TCIFLUSH line with the TCIOFLUSH line also or one in place of the other?

Go to forum: Other Hardware

57 Reply by yogi

(50 replies, posted in Other Hardware)

YES, success by accident! I had been testing this afternoon, trying the different setups and ideas we've been kicking around with no improvement. Then at one point, opened the ttyAMA0 com (no display update), closed the connection; THEN without closing the Editor, I re opened the ttyAMA0 connection and BOOM! full functionally smile I've repeated this after a cold boot and no test harness attached, to confirm the workaround. Not really sure if something changed with my cable but I doubt that was the issue.

In the Dropbox are the putty5.logs of the re connect; dsPIC's Tx monitored via a FTDI connection to my PC, while the OPA was connected to the Pi.   

So my guess is there is something strange in the RPi's uart handling that is outside the norm for other Linux distros. Where as the Editor using ttyUSB works almost flawlessly on the Pi. 
Yogi smile

Go to forum: Other Hardware

58 Reply by yogi

(50 replies, posted in Other Hardware)

marzacdev wrote:

If you're sure of your connections (RX and TX swapped correctly), you can try to short R5 and see if that's working better.
Also, if you do not have a scope at reach, try with an ohm-meter to check the basic conductivity of your wiring.

I'm sure with the pinning and will try shorting R5 (is it series resistance, current limiting?). After several cycles of re pinning for the two setups, I suspect the crimp-on connectors ( AMP type shell and crimp connectors). The metal 'socket' may have been deformed a little when I crimped it, just enough to have a bad connection on the carrier board header and a slightly better connection when plugged into the PC FTDI header.

I did do a continuity test across the cable: SIP header pins inserted into the Pi end socket of the cable, the other socket plugged into the header on the carrier board, and tested from the back of the board header across to the Pi end pins. Which was good, but  of course I was applying 'pressure' and flexing the cable with my meter probes. Will continue testing from OPA shield to Pi board.

Was also thinking of a another test harness- the cable between the Pi and OPA in place, but add a jumper/probe from the Rx on the PC FTDI to the OPA's Tx. Sort of a 'Y' on the line so I can log the dsPIC response and trace the signal path. My biggest concern is loading the dsPIC's pin too much. 

Yogi

Go to forum: Other Hardware

59 Reply by yogi

(50 replies, posted in Other Hardware)

Thanks so much Fred. I noticed the same byte pattern in the logs but didn't know the meaning. Of course remember that the logs are dumps of the Editor sending to the PC (in place of the OPA), Pi->PC test setup. It does confirm that the Editor is opening and using the Uart port. But the sound test, with the OPA I did last night, does show the one-way comms behavior.

The weird part is I used the same jumper cable on both tests, ~25cm of 4 conductor ribbon with a 4 pin socket on the Pi end and a 6 pin socket on the OPA end. The shield carrier board has a 6 pin header following the FTDI breakout board layout. So the OPA end of the jumper cable is pinned to match this header, plugging in instead of the FTDI board. With the Pi->PC test I just re pinned this socket, swapping Tx and Rx and removing the +5V from the socket. Then plugging it into a PC side FTDI board, set for +3.3V. This Pi->PC setup did work bidirectionally with the terminal tests.

At any rate, all signs point to a bad connection to the dsPIC Tx. Don't have access to a scope any more but I can setup my Papilio board as a Logic Analyzer. So if I can't make headway with inspecting the cable connectors, will load up the Papilio and see if that helps.

Thanks again,
Yogi

Go to forum: Other Hardware

60 Reply by yogi

(50 replies, posted in Other Hardware)

Wow, So I rechecked my cable but everything seemed right. Setup the shield and opened the Editor, and unlike with the FTDI it didn't load the default program 1 from the shield. This behavior is like I had noted before (and thought it meant the shield wasn't working), but this time I tried connecting my keyboard and played a few notes. AND HEARD the 1 OP default sound. So I Opened a patch from disk, the editor updated the display and the synth plays it.

  Testing further, seems that the Editor is not updating from the synth. Loading an Internal patch does load it on the synth but the Editor doesn't update the screen with the patch prams.  Moving controls or Opening a saved patch updates the synth and the display.

Seems like there is an issue with the dsPIC Tx -> Pi Rx connection, More checking with this cable!!!
Yogi

Go to forum: Other Hardware

61 Reply by yogi

(50 replies, posted in Other Hardware)

Ok more logs in the Dropbox folder ( here is the link to the folder) https://www.dropbox.com/sh/7ud7s5eoy30v … g8l7a?dl=0
In putty2.log and putty2.txt
I opened the Editor and after the cursor stopped spinning (trying to refresh from OPA? ) I hit the Load Internal three times (Program 1, internal 1). So the last 9 bytes of the log should be 0x0A, 0x00, 0x00, 0x0A, 0x00, 0x00, 0x0A, 0x00, 0x00 yes?
But the log shows this in HxD- 0x0E, 0x00, 0x00, 0x0E, 0x00, 0x00, 0x0E, 0x00 0x00
So this is strange. I did another run but pressed Store Internal (Program 1, internal 1)
putty3.log and putty3.txt-
Now its 0x0D, 0x00, 0x00 when it should be 0x09,0x00, 0x00
So don't know What is going on, why the bit values are off compared to the Command value in the manual. Maybe some weirdness with PuTTY or HxD or the FTDI interface or the Pi uart ?!?!
And why the Editor works with an FTDI and not with a direct connection. Judging from these tests it would seem that the shield would do Something,  even if it's the wrong command. But not seeing/hearing any signs.

Hope this helps,
Yogi
EDIT: Ok I looked into the Arduino Lib. Checked in OPA.h and see  that 

        OPA_CODE_INTERNALSTORE        = 13,
        OPA_CODE_INTERNALLOAD        = 14,

Which matches with the above logs, so... will have to recheck the cable. I also wonder if the +3.3V signals from the Pi are a problem. It Should work with the dsPIC but maybe the drive from those pins is just too low? I have some SF bi-direction Level shifter boards I can setup on the cable and test again.

Go to forum: Other Hardware

62 Reply by yogi

(50 replies, posted in Other Hardware)

Here is the PuTTY log. I started a session then started the Editor. Hit Load, then moved the Vol knob about Halfways up.
https://www.dropbox.com/s/mh0sshvwftwt5 … y.log?dl=0
Yogi
EDIT: if there is a specific command in the Editor to log let me know. Also I included a hex view from HxD as putty1.txt
https://www.dropbox.com/s/l92l1yshr1qdu … 1.txt?dl=0

Go to forum: Other Hardware

63 Reply by yogi

(50 replies, posted in Other Hardware)

marzacdev wrote:

Hi yogi,

I have been reading what you've done and I think you've found most of the problems. It should be working ok by now!
Send me a dump of the data it transmits and I will have a look.

You can actually log a putty session into a text file:
http://www.tricksguide.com/guide-how-to … ssion.html

I believe the problem might be the wiring.

Are these lines set as followed:
- DIG2 / CS1 => 0v
- DIG3 / CS2 => 0v
- DIG7 / RESET => 0v
- DIG7 / SWAP => 0v

with no jumper on the shield?

Fred

Hi Fred, I'll get a dump file for you.

As to the pins, got those set as you noted and jumpers open. Cable- Pi GND -> GND, +5v -> +5v, Pi Rx -> Rx and Pi Tx ->Tx (carrier board crosses Tx/Rx between FTDI header and Shield header ); same carrier board just replaced FTDI board  with cable to PI. Have tested on GPIO uart with and without Swap active, have a jumper block on the board. As well, I have the 'Arduino' Reset line pulled high with 10K R as per the Arduino board.

Thanks for your input, will get back to you,
Yogi

Go to forum: Other Hardware

64 Reply by yogi

(50 replies, posted in Other Hardware)

Well, been testing the RPi's uart. The shield and Editor works very well with an FTDI converter as ttyUSB0 but didn't see the Pi's uart at all, so ...
First task was to free it up for general use. Followed this guide-
http://spellfoundry.com/2016/05/29/conf … ding-pi-3/
Which is very complete. Then found a thread on StackExchange which recommends stopping Getty's access to the uart with-

   systemctl mask [email protected]

Then I changed the permissions-

   sudo chmod a+rw /dev/ttyAMA0

Everything seemed good EXCEPT the Editor didn't see the uart, ttyAMA0.
So had a poke around in the source and in rs232/rs232-linux.c found-

/** Base name for COM devices */
#if defined(__APPLE__) && defined(__MACH__)
        ...
#else
    static const char * devBases[] = {
        "ttyACM", "ttyUSB", "rfcomm", "ttyS"
    };
    static int noBases = 4;
#endif

This appears to need the Pi's uart name and after adding ttyAMA to devBases[]  and changing the total of noBase to 5, the newly compiled Editor does discover ttyAMA0.

After these changes, tested with the shield connected to the uart but it isn't responding to the Editor. Doing a PC to Pi serial test, minicom on the Pi and PuTTY on the PC both talk fine @ 57600. So the uart seems to be working. Testing PuTTY on the PC and running the Editor on the Pi shows that data is being transmitted. I assume it's corrupt/wrong but I can't tell for sure how as it's not sending ascii in the first place. Will have to see if PuTTY can dump raw bytes as hex (?).

Did double/triple checks of the cabling for the shield and I am sure it's correct; so I feel it is related to how the source is setting up the uart. There is another function in the source, 

 int comOpen(int index, int baudrate)

that is related to Mac vs Linux port configuration but I have to do more research on these bit flags.

To be honest, I don't know if the Editor was ever tested with a HW uart, as the project is meant to be hosted on an Arduino UNO (USB serial) so there may be a fundamental bug in the rs232 HW port handling. Or it may be Pi related. On my XP box the Editor does discover the mobo Serial port but I haven't tried using this.

The quest continues,
Yogi

Go to forum: Other Hardware