#21

I just bought a BF533 ez-kit off ebay UK, they go for super cheap, really. will continue this soon

#22

hm, well of course b700 waveform data was digitally generated and stored, but i am really not sure which synthesis operations were/werenā€™t performed in digital domain. (the ā€˜4th computerā€™ mentioned in that description might have been some bespoke collection of ICs interfacing with PROM waveform data? i really donā€™t know.) one processor ran MIDAS, one executed a sort of MARF-like control generator section. in any case it was a truly hybrid system and could not be easily emulated, in its totality, by one program.

i did quite misremember how much of the source code was indeed written in C though. the guy i was thinking of was aaron lanterman and he posted the code here: http://users.ece.gatech.edu/~lanterma/buchla700/
ā€¦ but IIRC it is mostly MIDAS code, BIOS for the editor, C libraries, &c. do let me know if you spot anything that looks like an FM calculation.

when i next get a chance i will have a look at the schematic as this thread has rewoken my curiosity about the instrument.

2 Likes
#23

@jasonw22 @alesaccoia @zebra

the 700 sounds are super amazing. and my mind has been tripping on this notion of the limits of the digital domain. I love how the 700 pushed the limits at its time with both digital and analog, would love to see/hear what instrument you guys think dose that today. maybe it would be interesting to build many many many differnt analog filters that could in groups shape many digital sourcesā€¦ I love how older snyhts had at times physical spring reverbsā€¦ just the idea that interesting sounds where and are found in many places. what would the buchla 800 (or whatever its called) next be. Im personally motivated about how unique it sounded and would love to dream of whatelse is possible.

#24

well, to put it another way, in my totally hazy memory i had a picture of the b700 voices as a collection of tiny processors working in parallel, something like this in fact: http://petermopar.blogspot.com/2015/11/24-parallel-pic-chips.html , funny how things come around. but i was 6/7 years old during its development so not really able to pay attention, the picture could be totally wrong. (if we were on a different forum iā€™m sure rick smith or someone would be correcting me by now)

analog/digital is only useful in context; here i kind of thought the context meant ā€œimplemented entirely in software; easy to copyā€ vs ā€œimplemented largely in hardware; difficult to copyā€

4 Likes
#25

wow https://www.youtube.com/watch?v=doaDD3wVw6c
Tocante Karper has an awesome resonance sound to it thats really special sounding, both strong and frail at the same time. exciting to hear new sounds that are so exotic. have you made and other stand alone instruments other then aleph is this something your interested in ?

1 Like
#26

on a tangent (since you referenced it)

is emulation of a sound module like the karper possible on aleph?

#27

Emulating all those parallel microprocessors would require some pretty intimate knowledge of how theyā€™re all working together. Is the Tocante Karper open source?

All the Ciat-Lonbarde instruments are just fascinating and brain-melty. Seems like something worthy of (directly) supporting to me!

1 Like
#28

I have a question (restarted playing around with this). I am using the BF-533 EZ-Kitā€¦ and Iā€™d like to develop some algorithms directly on it, as it has GPIO and everything I need for small self-contained projects. I am losing my hopes of using the bare metal toolchain, because I canā€™t find a way, after I have built the project, of transferring the ldr file to the flash, without using another MCU and SPI. Do you have any experience in achieving what Iā€™m trying to do? Otherwise Iā€™ll use visualDSP, butā€¦ Iā€™d definitely love to go with the open source alternative

#29

BUT REALLY

iā€™m seeing that uboot should be present by default on the EZ-KIT flash. if it hasnā€™t been bricked, you should just be able to connect with serial/network and use uboot to load your ELF.

TL/DR:

  • use JTAG if you can, but it might be hard/expensive to find a programming device that works ā€œout of the box.ā€

  • if you canā€™t, iā€™d just use an arduino or whatever for development, use SPI boot mode and stream your development LDR from the computer (same as aleph boot sequence.)

  • for ā€œproductionā€, use some kind of PROM or flash that you can write from a separate device.

OK, so if you donā€™t want another MCU in your project, youā€™ll want to boot from external flash/PROM, using either direct addressing on the SBIU bus, or SPI. the EZKIT has some flash on it but i donā€™t remember what kind. see the EE-240 app note linked above for boot mode details. (the blackfin doesnā€™t have its own flash, just the very small internal boot ROM.)

to update the firmware on your device ā€œin the fieldā€ (via UART i guess, something like that) youā€™ll have to roll your own bootloader and put it at the top of your program. (or i guess you could use u-boot, the open-source bootloader, if you want to support different boot processes, uclinux, whatnot and etc.)

the easy way to bootstrap your development process (that is, develop your bootloader) would be to use a JTAG programming device and load directly into blackfin SRAM. from there you should also be able to [write the LDR to flash] (https://blackfin.uclinux.org/doku.php?id=bootloaders:u-boot:loading#programming_flash_via_jtag).

if you canā€™t get a programmer, i guess youā€™ll have to come up with some other way of flashing whatever memory is on the EZKIT using another device. or connect your own NV memory. (or, seriously, just use an AVR8 or something that can also serve as a serial->USB bridge when you inevitably want that later.)

iā€™m not at all familiar with VisualDSP, but i donā€™t think it really gives you any magic bullets for this task.

one thing to note: you might come across a lot of discussion referencing the bf537 and how to boot it over UART. but this is a different part, and unfortunately the bf533 lacks a boot-over-UART mode.

1 Like
#30

thanks, lots of information to process! where did you find read that uboot is already in the flash?
Iā€™ve found that: ā€œU-Boot does not come preloaded on the EZKit, (after all, blinking lights are so much more useful :wink: ) so, U-Boot must be loaded via hand. See the loading U-Boot document for more information.ā€

At this point I guess Iā€™ll use VDSP until I can find a programmer at a decent price, because even if I manage to get uboot in the flash, I wonā€™t have any debug facilities, and having the possibility to set a breakpoint is invaluable at this stage. Iā€™ll keep an eye open for JTAG programmers on ebay. thank you for the thorough explanation

#31

oh, ok, i just saw here
ā€œFlash memory on your development platform should come preloaded with a working Uā€‘Bootā€
but i guess doesnā€™t apply to ez-kit. sorry

anyways, i really donā€™t see how VDSP will help you compared to the open source tools. maybe i am missing something. AFAICT it gives you this proprietary flash driver (so it should be a little faster than bitbanging), but you still need a JTAG interface, and anyway those drivers have been duplicated in the GNU toolchain now.
https://blackfin.uclinux.org/doku.php?id=visualdsp:flash-programmer

1 Like
#32

I knowā€¦ but at least I can start coding something. On the EZ-KIT the JTAG is accessible through USB (ā€œthe USB connector on all EZ-Kit boardsā€ mentioned at the end of the page https://blackfin.uclinux.org/doku.php?id=hw:jtag, marked as incompatible ) and this at least gives me a way to set breakpoints.
Because in order to debug i need to have at least one sort of JTAG no? They are all either discontinued or unavailableā€¦ since I have one on the board, in the meantime Iā€™ll just use that while familiarizing with everything. Am I still missing something?

#33

ohhhh i see. i forgot about the ā€œUSB debug agentā€ and have never used it. ok then, best of luck!

#35

I had the involuntary face palmā€¦

The ā€˜wavesā€™ scripts are genius ez.

After looking at the 700 code, if I remember correctly you did something I think is interesting.

The 700 co efficients were on a slice range of even numbers,
EDIT: where I canā€™t seem to find odd harmonics in the 700 etc or lib filesā€¦unless that was omitted on GitHub.
The 700 PROM and very old components would be a pain to even attemptā€¦ Funny to find that info and now Iā€™m here.

Really would be cool to make a randomized differential equation or pi sculptor for cosine or save table synthesis.

  • With the Aleph already having midi and CV / this is a no brained for me to jump in.

Really it would be fun to have a 4 op split for osc on a ratio/interval/sync/and fixed modes , adding pitch control to osc1 only, to be fed into waves and perhaps some phasing - delay - panning and incorporation of external sources for indices between the 4operators to have env detection, random values, and even a simple mic for breath control.

Iā€™m hoping thatā€™s not too much processing for 1 scene.

It would be nice to see the 700 concept expanded upon with respect + new discoveries towards an approach like itā€¦in re explored old/new explorations.

Gcc is a pain in freeBSD for me (at least in code meant for other machinesā€¦ your Python approach on the comm is really fun and expandable!) so Iā€™m about to start Dev in debian or at least find a flow that stopa me from reformatting and just dedicate a stable OS. Linux security issues have been a pain since the 30th or so.