Wonderful to hear doc! I've been busy bread-boarding and I'm about to start on test code. I just want to make sure I have full command of the cascading of the counters. I do need to adapt this design a bit. I hope to have a finished schematic this week so I can start building a board.
@circuitsoft. Those look really nice, although I have no way to work with them. I have done a bit of SMD work, but don't really have the right tools. They are a bit spendy, but could do some nice functions. I keep wanting something like this big enough for a screen buffer. That way, the prop just updates the buffer as necessary somewhat like it would update the screen. The display controller *some ?other? micro* updates the screen. We might even give the display controller it's own sd card?
I keep coming back to the idea of two props.
Lately I've been thinking about this design and have a few ideas. I still need to figure out my pic 18f devices. I will need @least one for secondary user interface. I think I can i2c prop to pic with the pins 30 -31. Not sure about this thought. The reason i need this "secondary user interface" is... My hardware is intended for professional audio equipment. This version will have 2 midi ins and outs, one on the prop, the other on the pic. The main unit *with the screen* will be rack-mounted. I want another 1 - 4 dumb screens, 2 or 4 x 20. Each of these will have 4 push-button, rotary encoders *8 if I use 4 x20 screens* The "secondary user interface" is the foot controller. Current model has 17 momentary pushbuttons, 8 leds on a hc164. A few more pins are necessary, but I have high hopes for this project. I am leaving a lot of this up in the air right now because the screen is the most important. I believe my pin for pin board would be sufficient, if slightly slow. The hardware will be expandable and configurable for different purposes and devices. I really need to pick up a couple more screens so I can work with more than one board at a time. Oh well.
So I'm writing the counter address clocking test code. I want to see what the max speed I can get my ls161's and hc161's. Not sure how to use these together. Right now I have the LS as LSB and HC as MSB. Not sure it makes much of a difference, I have to find out.
I just want to make sure I have full command of the cascading of the counters.
It shouldn't be too complicated. I copied that schematic off something I found on the internet. Connect all the clocks together. The carry goes to both the enable inputs of the next 161 as per the schematic. I think there are two inputs so you can do clever things like "divide by n" where n is any number but we don't need that. We don't need clear. So it becomes a very simple layout.
Breadboard it and see if it works.
Right now I have the LS as LSB and HC as MSB.
Yikes! LS is 5V. Ditto HCT and straight 74. I'd stick with HC.
I use HCT when interfacing from 3V to 5V as the logic levels are more reliable than HC but apart from that, if everything is 3V then keep to HC.
Yes, i realize about hc/t ls, etc.. I ordered 2 HC161's, before I realized I had LS. and now I'm stuck with what I've got until my next parts order... Which will be a while... So as a work-around for now, I have the 5v 161's, 245's and the ram as well. You can thank me being a broke college student for this. I'm sure glad this month's my birthday.
I wasn't sure if I wanted access to clear. I think it could be handy, IF I stored the draw command @ 0. something like,
I tried some breadboard stuff and it seems to work great. Still too early to say it's in the books. I am lacking the breadboard space to test the FULL design. I am also lacking the 28 pin sockets for the ram chips. Still debating on sockets for the 161's and the 245's. So off to take a walk to radioshack and get-er-done BTW, I fired up *Counter Modules v1.0.2* with slight mods and got the chips clocking VERY quickly. I'll bust out a 393 and see if I can figure out how fast I can get my current design going. I set the frequency in counter modules up to 35, and it *appeared* to work, although my simple display does not illustrate the effect properly. This WAY beats the 10Mhz limit of the screen... Looks very promising.
As for the eprom suggestion, what that would have that an SD card doesn't is S P E E D.
[edit]
Of course things can be loaded from SD into XMem. And that's obviously the way to
develop screens, controls, animations, audio, video, etc.
But once they are solid, stash them in eprom, Then - no delay to boot the images into
ram... and the SD card can be used for other stuff that is not used as often.
Joe,
I've been thinking about two props also. Or even switching to an ARM or ? as the main
processor. (heresy!) But he advantage would be software. LOTS of tools and programmers
that already know how to use them.
A second prop - running CPM - would be able to provide a mass of software - tools and apps.
But the downside is that a 4 Mhz Z80 is not all that snappy by modern standards.
Even by iPad standards.
Is there a trick here that might help that run faster?
The one thing I can think of I want is some waveform samples I can use for synthesis. This is meant for music, and I eventually want to be able to run sidcog as well as some other stuff. I kept looking at the audio stuff being developed and thinking some nice, purpose driven hardware would be nice. That and my analog board needed a controller other than my BS2. It just didn't have the guts.
I'm stuck using through hole for the moment, but when I can get into smd, I I think I will be building some nice hardware. This design has potential, in SMD it would be awesome. I keep telling my friend we should build it into a gameboy. I think, between propGCC, ZiCog and some of the other projects out there, we could do retro game emulation. I believe it can be done, but don't have the time. I wish someone else was working on that. *HINT HINT*
I've spent the morning getting a "development platform" that won't DIE in my environment. It's probably some of the most ghetto work I've ever done. Seriously ghetto, and I'm embarrassed. Ducktape and bailing wire, except replace the bailing wire with cardboard... Not pretty, not elegant, barely functional... But the best I can do on short notice. In fact the reason it has taken me so long is I kept trying to find something better. I've blown my budget for this project already. I have the "final" case, but it's not very comfortable to work with since it's rack-mount. I will be building the dev model a case soon, but that's a project for another day. Now for a walk to a store that I hate, I hate the people that work for it, and it makes me hate the town I live in for having nothing better.
*edit*
@cavelamb,
two props seems really nice to me. I want to use the PIC 18F452 for secondary UI, and the PIC 18F4620 for Midi in\out as well as the ADC and some extra, slower pins. The second prop seems like the best way to go to be honest though.
ok, here's the pix I promised. Please, laugh all you want...
Those look really nice, although I have no way to work with them. I have done a bit of SMD work, but don't really have the right tools. They are a bit spendy, but could do some nice functions. I keep wanting something like this big enough for a screen buffer. That way, the prop just updates the buffer as necessary somewhat like it would update the screen.
How much of a hurry are you in? There are certainly other synchronous SRAMs available too. If you design a circuit, and keep the parts cost under $50, I'll just do a board layout, produce one, and mail it to you. Not sure I can use it directly, but I'm curious to see what you can do with it.
The reason I pointed to the dual-port ram was because I thought it would be faster to blit with, but that may not be a necessary operation.
How much of a hurry are you in? There are certainly other synchronous SRAMs available too. If you design a circuit, and keep the parts cost under $50, I'll just do a board layout, produce one, and mail it to you. Not sure I can use it directly, but I'm curious to see what you can do with it.
The reason I pointed to the dual-port ram was because I thought it would be faster to blit with, but that may not be a necessary operation.
To be honest, I'm in a huge hurry right now. The wife is a bit upset with my expenditures and I want to produce results. I've looked through the variety of sram available and have some chips I would like to use but cost was prohibitive at the time. I'll admit, better chips are not THAT much more expensive. Still, now's not the time. I picked up the last breadboard today and after my radioshack trip, I was to angry to do much. I'm hoping the eeprom will work over about 2" of wire. That will still leave me a few breadboard pins short of what I need. I have no clue how I will solve this.
As to the offer, I would love to do a few SMD boards in the future. I would be willing to pay you for them. Don't have the money right now. I really think the best design is close. I'm leaning strongly towards two props. One to run the screen, and one to run the hardware. My ambitious project is inspired by this http://midibox.org/
I believe the prop would be a way better choice, and have been trying to figure out how to port this project over. http://www.ucapps.de/midibox_sid.html I believe it could be done, and I'm really curious how sidcog would work for this. I wonder what the overhead to run the system would be since the full version of the hardware uses 2 pic 18f's and 8 SIDs. I'm just working on the control surface now. My design is not quite as modular, but I think it could be exponentially more powerful. I believe strongly the prop has huge potential for hobbyist synth designers.
Nothing wrong with duct tape - it got the Apollo 13 astronauts back.
For those of us who don't have a midi keyboard (me, for one) but do have access to cheap leftover PC keyboards (I picked up a pile once for $3 each), I wonder if you could get some black and white markers and draw a piano keyboard? You could have two rows like some organs have. White on the zxcf row, black on the asdf row, then another line of notes above? It would be cool to tweak the attack/decay/sustain/release on the touchscreen while playing the notes. And there would be plenty of room in the ram for wavetables. We could do this with the design we have now.
Re post 121, I'm so sure average joe is onto such a cool design I just sent off to get 10 of those boards made.
As far as unemployment goes, I'm living in hell. Carson City, Nevada is a destitute wasteland. The only 3 good things here are my wife, my child, and my cat. Ok, can't forget the best friend. That's it. I'm an ITT Tech student and having trouble finding work as it is. A car wreck 2 years ago left me with a back injury and I'm unable to do the heavy lifting and repetitive bending that had been paying my bills up till then. I have been stuck in this dead end town since I was 14 and though I've escaped a few times, my 28'th birthday is 2 days away and I'm still stuck here. My son was not exactly planned but I couldn't imagine life without him. Right now, we're barely surviving on what little computer tech work I can get, and $200 a month from my awesome mom. I've been actively seeking employment for over a year and 6 months. But enough of my depressing story and on to the fun stuff.
There are several objects of interest for using the prop as a synth. I have a few ideas of my own. The first task with the new hardware will be getting the existing stuff I have translated over. Shouldn't be too much work. Then I've got to lay out a transport, Play, Stop, Pause, Rewind and Fast Forward. Get those bound to the touchscreen and play with the midi hardware. I know it should work, I just have some skepticism about my construction methods. In theory, it should work although im my world it seldom does. The ducktape is not what I'm really ashamed of. Cardboard for a motherboard tray? Leaves a lot to be desired if you ask me. I have cases I could stuff a devboard into, but having breadboards laying around my house is not going to happen.
Now, about using pc keyboards as controllers. I think this is a great idea and I've seen it done with computers before. Keyboards are not that expensive but if you're not a professional player, probably overkill. I will consider this when structuring the OS. I doubt I will develop an object for this, but I would imagine it quite easy. Take the keyboard character and look up it's midi note number. There would be no touch sensitivity, although turning a pot could mimic this. I have worked with a ridiculous number of different music creation devices and have my own opinion of the right way to do it. I HATE, repeat HATE equipment you have to dig through layers of menus to get to a commonly used setting.
I'm flattered you think it's a cool design. I see great potential for such a device. I'm still tuning the wiring of my device. Should be very close to what you have. I sure would like to make a board for the final pin to pin hardware I have. I think there is quite a bit of potential there too! After doing a bit more studying, I believe I can cut my screen draw times by half. The slowest part of drawing a screen now is the refresh. Using your font driver to draw a screen, it would draw pretty quick, but during the clear screen it would chug. Tuning the driver would help, but being able to tell the ASM portion to draw a clear screen would make the clearing of the screen nearly invisible. I will play around with this when I put my propRpm back together.
Last thing, I want to use the sp232 for my bread-boarding but the part is 5v. I've been thinking about putting a ?2.7k? resistor between the prop and chip on the receive line. Should work if I power the chip with 5v?
LOL - Call it LED Pong, It's all I could do with eight LEDs...
Just a little ditty to help learn a new language.
That's just the way I do it...
Write lots of little programs.
Try new expressions.
Get stuck.
Hopefully find help...
Checking out Carson City now. Similar lattitude to where I am, half the rainfall of where I am but you get snow instead (higher altitude?). Dry desert most of the time. Similar in size and climate to a number of towns I have worked in. Gotta make the most of where you are. Back injury from a MVA not so good. Have to use brains instead of brawn. Not sure what to suggest. I once had a patient with a back injury who was officially declared by workers compensation and a court as someone who would never work again. She got a small payout - maybe half a year's salary and in return waived her right to claim any more compensation. She then went on to get a job and within a few years became the top sales rep in her field in the whole of Australia. Free trips interstate etc. I asked her if the back still hurt and she said yes, it hurts even more now than it did 5 years ago. I found that very inspiring as I know how down and despairing she was going through the compensation process. I have another patient who injured her back while demonstrating tools at the local hardware shop (lots of heavy boxes). She retrained as a quantity surveyor. I don't even know what a quantity surveyor does but it seems to pay much better than her previous job. Actually I can think of quite a few people who have been told officially that they will never work again and who turned that negative comment into a positive success. Hopefully you can find something in your town that society values. Hmm - one of my best back pain success stories was a guy who now operates speed cameras. That pays quite well, but I am not sure how valuable it is to society?
Re board design, I just paid the nice people in China to start making the boards. Hopefully it will work. I'm getting 10 so should have some spare and I could send you one or more?
Screen refresh and screen clear should still be around 30ms. Just need the pasm code rewritten for 161 chips.
sp232 for my bread-boarding but the part is 5v.
is that like a max232? If so then 2k7 series resistors are the answer like you say.
Thanks for your words of encouragement Dr. Acula. Things are tough right now but I know the will get better. The major difficulty is there is little industry here. I had an interview for a network tech job that went quite well. I lack the "experience" needed to get anything that doesn't require heavy manual labor. Oh well.
About the board design, I'm sure it will work quite well. I would be very interested to check one out.
I have a few requirements that need a bit more help so to speak. Having the 16 bit propBUS available to do other stuff has become a priority. I have some PCM54 dacs that I would love to hook up. These chips were industry standard for 44k 16 bit audio. There are better chips to be had, but once again, the budget. Getting things bread-boarded has proved more difficult than expected. I was forced to put the EEPROM on the power supply board. Make wires to connect to the breadboard, etc. I believe I have the prop breadboard about tied up. Quite a way to go but I will keep you guys posted!
I've been doing some work on the hardware end and getting very close to firing up the new design. I believe all I'm lacking at this point is the 40 pin ribbon cable for the display. Still need to switch out the max 232 for the 2323 I'm using right now. I will be adding decoupling caps LAST.
My brother in-law gave me one of the best birthday presents, an old toshiba laptop for a project case. Still in rough stages, but way better than what I had. I'm debating about the mounting of the screen.
There's nothing "wrong" with it. I just happen to need it for my propRPM board. Much easier to put it back where I got it and use the 232 that happened to walk through my door.
I didn't think it would matter. I've fabricated my 40 pin ribbon cable for bread-boarding, now I have to grab a bunch of 2.7k resistors. I used my last 15 already. I will be ordering a couple more HC161's and some 3.3v sram chips eventually.
The counters appear to be working correctly. A visual inspection @ 10mhz looks ok? I have not run a diagnostic to check with software yet, that will be next. I'm thinking something simple like,
1. Load ram Address 0
2. Write data = address for all 32k
3. Load ram address 0 again,
4. Read data and compare to address.
I believe this should verify ram operation, and could probably be written to find max working frequency? Still thinking about the best way to do this.
After I verify ram opperation, it will be time to hook up the LCD. I'm 16 - 2.7k resistors short. Might try 3k?
Sounds good. The resistor values are not that critical. 3k would work. 1k works fine - anywhere around these values. Down the track you may not need all those resistors.
Just finished up my homework for this week, so I will have a bit of time to work this morning. I've done some searching and it looks like I'm going to be using 1k resistors for the screen. Since I'm short on breadboard space, I guess I will be soldering them to the ribbon cable. I hope I have enough solder to finish the job. I am also thinking about moving the resistors for the prop. The current layout has them grouped tightly, and I'm worried about the leads shorting. I believe the 161's will get enough of a high voltage to load data through 1k resistors.
Lately I've been thinking about controlling the screen's backlight. I think dimming would be a nice feature. Using a prop pin to do PWM seems the easiest. It also wastes a prop pin. I could use SDA of the eeprom I guess. Any thoughts?
Well it's taken me WAY longer than expected, as usual. I finished fabricating the 40-pin ribbon cable, soldering the 16 resistors to the data lines... When I realize... I was counting 1, 21, 2, 22... instead of 21, 1, 22, 2... So I started over, and ran out of solder. At this point, I decided to take a nap. When I got up I ran to the shack *i hate myself everytime* and grabbed solder. When I got home, it was dinner time. After dinner I finished the display cable and began wiring. After a few false starts, I have the screen on and drawing pixels in spin. *Pictures in a while *
So now I'm left thinking how to control the address lines. If I use the same `138 for Ram( Load, Count, WR), SD card CS, Touch CS and LCD WR *as well as 2 extras?*. I think the best way is :
1. The display/ram cog will control the 138 address lines. When the top level program needs to read from the sd card, touchscreen or other, it will request the address.
2. Either the spin program, or more likely the asm code will return if the request was successful or not.
3. The top level program then uses the cs lines if successful, and if not it can re-request.
4. When the top level program is done with the cs lines, it will call for a release. Blah blah blah.
Now the problem with this is : I can only use one device at a time. Requesting and releasing the CS line requires a bit of overhead. I'm not sure if these will be problems, but that's the reason I wanted to bread-board this first.
Also in the back of my mind I'm wondering about using more than one prop.
!!! If Drac could point Cluso to this thread, I'd like to see what he has to say about this.!!!
I need a second prop, at least, for pins and cogs. The idea right now is this controller will connect to the SoundEngine *still working this out.* The controller will be responsible for all UI, as well as getting data from the Sd card as needed... I would like to have the "file player" running on the UI, streaming "quasi-MIDI" to the SoundEngine. The controller will also handle 1x Midi In and 1x Midi Out.
The SoundEngine will run SidCog, and other prop audio generation stuff. I want to start with sidCog because that seems like the most fun. I would like to have multiple instances of sidcog running, maybe upto 8? Right now I think I will need one cog on the SoundEngine to control all the sidcogs, but way too early to know for sure.
This is the planning stage, and I have a lot to digest. The first part is obviously getting the 2 props to talk to each-other. I'm thinking? can I use the EEprom pins to do i2c between the 2 *or more?* props? Will it be fast enough to carry midi communications?
Midi: asynchronous serial communication data at 31,250 bits per second. 8-N-1 format, i.e. one start bit (must be 0), eight data bits, no parity bit and one stop bit (must be 1), is used, so up to 3,125 bytes per second can be sent.
I hate messed up notes SO... Double this to 6,250 BPS, just to be aggressively safe.
I guess I'm asking for advice on the best way to achieve this *theoretical* throughput, using the least amount of resources possible? Maybe even 1.5x midi or about 4688 bytes per second? Any advice in general would be greatly appreciated!
Here's the latest board design. It has Midi In - Midi Out, 2 audio outs, direct access to 19 pins that can be used while transferring from ram to display, 12 digital outs, an external CS and access to the eeprom pins. There are also LEDs on the programming pins and RAM / `161 voltage can be switched between 3.3 and 5v for testing purposes. The Midi I/O can be used for a PS2 for those without midi hardware.
I am debating removing the LCD resistors from the board and using a hack between the screen and controller. This could be on perfboard or resistors in the cable. I'm not sure if this would save enough space to be worth the hassle..
I'm not sure if I will breadboard this since I JUST ordered parts, or rush to boards. I'm working with OLD hardware for now.
I am finally announcing a name for the project, as long as it's not already taken. I am thinking about calling this project "PropERmidi Core V1". I did a quick google and couldn't find anything by this name.
On an unrelated note, I've been working on my propFont buttons, and have a serious bug. When program is started, the buttons are initialized on. Then on first press, all the buttons except for the one that was pressed turn off. Other than this, it works fine. Someone please help. This should not be this complicated.
I changed the hardware again. I wanted stereo outs, so I fumbled around and now SidCog is tested. I will be testing some of the other sound generators. I noticed a large transient on starting SIDcog, not sure why.
Comments
@circuitsoft. Those look really nice, although I have no way to work with them. I have done a bit of SMD work, but don't really have the right tools. They are a bit spendy, but could do some nice functions. I keep wanting something like this big enough for a screen buffer. That way, the prop just updates the buffer as necessary somewhat like it would update the screen. The display controller *some ?other? micro* updates the screen. We might even give the display controller it's own sd card?
I keep coming back to the idea of two props.
Lately I've been thinking about this design and have a few ideas. I still need to figure out my pic 18f devices. I will need @least one for secondary user interface. I think I can i2c prop to pic with the pins 30 -31. Not sure about this thought. The reason i need this "secondary user interface" is... My hardware is intended for professional audio equipment. This version will have 2 midi ins and outs, one on the prop, the other on the pic. The main unit *with the screen* will be rack-mounted. I want another 1 - 4 dumb screens, 2 or 4 x 20. Each of these will have 4 push-button, rotary encoders *8 if I use 4 x20 screens* The "secondary user interface" is the foot controller. Current model has 17 momentary pushbuttons, 8 leds on a hc164. A few more pins are necessary, but I have high hopes for this project. I am leaving a lot of this up in the air right now because the screen is the most important. I believe my pin for pin board would be sufficient, if slightly slow. The hardware will be expandable and configurable for different purposes and devices. I really need to pick up a couple more screens so I can work with more than one board at a time. Oh well.
So I'm writing the counter address clocking test code. I want to see what the max speed I can get my ls161's and hc161's. Not sure how to use these together. Right now I have the LS as LSB and HC as MSB. Not sure it makes much of a difference, I have to find out.
It shouldn't be too complicated. I copied that schematic off something I found on the internet. Connect all the clocks together. The carry goes to both the enable inputs of the next 161 as per the schematic. I think there are two inputs so you can do clever things like "divide by n" where n is any number but we don't need that. We don't need clear. So it becomes a very simple layout.
Breadboard it and see if it works.
Yikes! LS is 5V. Ditto HCT and straight 74. I'd stick with HC.
I use HCT when interfacing from 3V to 5V as the logic levels are more reliable than HC but apart from that, if everything is 3V then keep to HC.
I wasn't sure if I wanted access to clear. I think it could be handy, IF I stored the draw command @ 0. something like,
0 - Window X1 & X2
1 - Window Y1
2 - Window Y2
3 - Set XY
as I said, I'm still thinking about this.
I tried some breadboard stuff and it seems to work great. Still too early to say it's in the books. I am lacking the breadboard space to test the FULL design. I am also lacking the 28 pin sockets for the ram chips. Still debating on sockets for the 161's and the 245's. So off to take a walk to radioshack and get-er-done
wOw!
And that's using through-hole parts!
As for the eprom suggestion, what that would have that an SD card doesn't is S P E E D.
[edit]
Of course things can be loaded from SD into XMem. And that's obviously the way to
develop screens, controls, animations, audio, video, etc.
But once they are solid, stash them in eprom, Then - no delay to boot the images into
ram... and the SD card can be used for other stuff that is not used as often.
Joe,
I've been thinking about two props also. Or even switching to an ARM or ? as the main
processor. (heresy!) But he advantage would be software. LOTS of tools and programmers
that already know how to use them.
A second prop - running CPM - would be able to provide a mass of software - tools and apps.
But the downside is that a 4 Mhz Z80 is not all that snappy by modern standards.
Even by iPad standards.
Is there a trick here that might help that run faster?
I'm stuck using through hole for the moment, but when I can get into smd, I I think I will be building some nice hardware. This design has potential, in SMD it would be awesome. I keep telling my friend we should build it into a gameboy. I think, between propGCC, ZiCog and some of the other projects out there, we could do retro game emulation. I believe it can be done, but don't have the time. I wish someone else was working on that. *HINT HINT*
I've spent the morning getting a "development platform" that won't DIE in my environment. It's probably some of the most ghetto work I've ever done. Seriously ghetto, and I'm embarrassed. Ducktape and bailing wire, except replace the bailing wire with cardboard... Not pretty, not elegant, barely functional... But the best I can do on short notice. In fact the reason it has taken me so long is I kept trying to find something better. I've blown my budget for this project already. I have the "final" case, but it's not very comfortable to work with since it's rack-mount. I will be building the dev model a case soon, but that's a project for another day. Now for a walk to a store that I hate, I hate the people that work for it, and it makes me hate the town I live in for having nothing better.
*edit*
@cavelamb,
two props seems really nice to me. I want to use the PIC 18F452 for secondary UI, and the PIC 18F4620 for Midi in\out as well as the ADC and some extra, slower pins. The second prop seems like the best way to go to be honest though.
ok, here's the pix I promised. Please, laugh all you want...
Besides, MY last piece of code was PONG on the Quick Start board.
I still don't understand how this compares to pong. At least pong was an actual game.
The reason I pointed to the dual-port ram was because I thought it would be faster to blit with, but that may not be a necessary operation.
To be honest, I'm in a huge hurry right now. The wife is a bit upset with my expenditures and I want to produce results. I've looked through the variety of sram available and have some chips I would like to use but cost was prohibitive at the time. I'll admit, better chips are not THAT much more expensive. Still, now's not the time. I picked up the last breadboard today and after my radioshack trip, I was to angry to do much. I'm hoping the eeprom will work over about 2" of wire. That will still leave me a few breadboard pins short of what I need. I have no clue how I will solve this.
As to the offer, I would love to do a few SMD boards in the future. I would be willing to pay you for them. Don't have the money right now. I really think the best design is close. I'm leaning strongly towards two props. One to run the screen, and one to run the hardware. My ambitious project is inspired by this http://midibox.org/
I believe the prop would be a way better choice, and have been trying to figure out how to port this project over. http://www.ucapps.de/midibox_sid.html I believe it could be done, and I'm really curious how sidcog would work for this. I wonder what the overhead to run the system would be since the full version of the hardware uses 2 pic 18f's and 8 SIDs. I'm just working on the control surface now. My design is not quite as modular, but I think it could be exponentially more powerful. I believe strongly the prop has huge potential for hobbyist synth designers.
Hmm. Tricky.
You need to keep the good lady in the manner she has become accustomed to. But you need enough money for a hobby as well.
I'm not saying my solution is perfect, but when confronted with this problem, I took a second job. Hopefully you are not in a high unemployment area.
Re the prop acting as a synth - I think that is a fantastic idea. I'm pretty sure there are already some objects done for this.
Re In the most lighthearted way, I'm going to have to send you to this facebook page http://www.facebook.com/pages/I-used-to-think-duct-tape-was-called-duck-tape/211099849147
Nothing wrong with duct tape - it got the Apollo 13 astronauts back.
For those of us who don't have a midi keyboard (me, for one) but do have access to cheap leftover PC keyboards (I picked up a pile once for $3 each), I wonder if you could get some black and white markers and draw a piano keyboard? You could have two rows like some organs have. White on the zxcf row, black on the asdf row, then another line of notes above? It would be cool to tweak the attack/decay/sustain/release on the touchscreen while playing the notes. And there would be plenty of room in the ram for wavetables. We could do this with the design we have now.
Re post 121, I'm so sure average joe is onto such a cool design I just sent off to get 10 of those boards made.
There are several objects of interest for using the prop as a synth. I have a few ideas of my own. The first task with the new hardware will be getting the existing stuff I have translated over. Shouldn't be too much work. Then I've got to lay out a transport, Play, Stop, Pause, Rewind and Fast Forward. Get those bound to the touchscreen and play with the midi hardware. I know it should work, I just have some skepticism about my construction methods. In theory, it should work although im my world it seldom does. The ducktape is not what I'm really ashamed of. Cardboard for a motherboard tray? Leaves a lot to be desired if you ask me. I have cases I could stuff a devboard into, but having breadboards laying around my house is not going to happen.
Now, about using pc keyboards as controllers. I think this is a great idea and I've seen it done with computers before. Keyboards are not that expensive but if you're not a professional player, probably overkill. I will consider this when structuring the OS. I doubt I will develop an object for this, but I would imagine it quite easy. Take the keyboard character and look up it's midi note number. There would be no touch sensitivity, although turning a pot could mimic this. I have worked with a ridiculous number of different music creation devices and have my own opinion of the right way to do it. I HATE, repeat HATE equipment you have to dig through layers of menus to get to a commonly used setting.
I'm flattered you think it's a cool design. I see great potential for such a device. I'm still tuning the wiring of my device. Should be very close to what you have. I sure would like to make a board for the final pin to pin hardware I have. I think there is quite a bit of potential there too! After doing a bit more studying, I believe I can cut my screen draw times by half. The slowest part of drawing a screen now is the refresh. Using your font driver to draw a screen, it would draw pretty quick, but during the clear screen it would chug. Tuning the driver would help, but being able to tell the ASM portion to draw a clear screen would make the clearing of the screen nearly invisible. I will play around with this when I put my propRpm back together.
Last thing, I want to use the sp232 for my bread-boarding but the part is 5v. I've been thinking about putting a ?2.7k? resistor between the prop and chip on the receive line. Should work if I power the chip with 5v?
Just a little ditty to help learn a new language.
That's just the way I do it...
Write lots of little programs.
Try new expressions.
Get stuck.
Hopefully find help...
Re board design, I just paid the nice people in China to start making the boards. Hopefully it will work. I'm getting 10 so should have some spare and I could send you one or more?
Screen refresh and screen clear should still be around 30ms. Just need the pasm code rewritten for 161 chips.
is that like a max232? If so then 2k7 series resistors are the answer like you say.
About the board design, I'm sure it will work quite well. I would be very interested to check one out.
I have a few requirements that need a bit more help so to speak. Having the 16 bit propBUS available to do other stuff has become a priority. I have some PCM54 dacs that I would love to hook up. These chips were industry standard for 44k 16 bit audio. There are better chips to be had, but once again, the budget. Getting things bread-boarded has proved more difficult than expected. I was forced to put the EEPROM on the power supply board. Make wires to connect to the breadboard, etc. I believe I have the prop breadboard about tied up. Quite a way to go but I will keep you guys posted!
My brother in-law gave me one of the best birthday presents, an old toshiba laptop for a project case. Still in rough stages, but way better than what I had. I'm debating about the mounting of the screen.
Here's what I've got so far.
How are the counters going - all cascading correctly?
The counters appear to be working correctly. A visual inspection @ 10mhz looks ok? I have not run a diagnostic to check with software yet, that will be next. I'm thinking something simple like,
1. Load ram Address 0
2. Write data = address for all 32k
3. Load ram address 0 again,
4. Read data and compare to address.
I believe this should verify ram operation, and could probably be written to find max working frequency? Still thinking about the best way to do this.
After I verify ram opperation, it will be time to hook up the LCD. I'm 16 - 2.7k resistors short. Might try 3k?
Lately I've been thinking about controlling the screen's backlight. I think dimming would be a nice feature. Using a prop pin to do PWM seems the easiest. It also wastes a prop pin. I could use SDA of the eeprom I guess. Any thoughts?
So now I'm left thinking how to control the address lines. If I use the same `138 for Ram( Load, Count, WR), SD card CS, Touch CS and LCD WR *as well as 2 extras?*. I think the best way is :
1. The display/ram cog will control the 138 address lines. When the top level program needs to read from the sd card, touchscreen or other, it will request the address.
2. Either the spin program, or more likely the asm code will return if the request was successful or not.
3. The top level program then uses the cs lines if successful, and if not it can re-request.
4. When the top level program is done with the cs lines, it will call for a release. Blah blah blah.
Now the problem with this is : I can only use one device at a time. Requesting and releasing the CS line requires a bit of overhead. I'm not sure if these will be problems, but that's the reason I wanted to bread-board this first.
Also in the back of my mind I'm wondering about using more than one prop.
!!! If Drac could point Cluso to this thread, I'd like to see what he has to say about this.!!!
I need a second prop, at least, for pins and cogs. The idea right now is this controller will connect to the SoundEngine *still working this out.* The controller will be responsible for all UI, as well as getting data from the Sd card as needed... I would like to have the "file player" running on the UI, streaming "quasi-MIDI" to the SoundEngine. The controller will also handle 1x Midi In and 1x Midi Out.
The SoundEngine will run SidCog, and other prop audio generation stuff. I want to start with sidCog because that seems like the most fun. I would like to have multiple instances of sidcog running, maybe upto 8? Right now I think I will need one cog on the SoundEngine to control all the sidcogs, but way too early to know for sure.
This is the planning stage, and I have a lot to digest. The first part is obviously getting the 2 props to talk to each-other. I'm thinking? can I use the EEprom pins to do i2c between the 2 *or more?* props? Will it be fast enough to carry midi communications?
Midi: asynchronous serial communication data at 31,250 bits per second. 8-N-1 format, i.e. one start bit (must be 0), eight data bits, no parity bit and one stop bit (must be 1), is used, so up to 3,125 bytes per second can be sent.
I hate messed up notes
I guess I'm asking for advice on the best way to achieve this *theoretical* throughput, using the least amount of resources possible? Maybe even 1.5x midi or about 4688 bytes per second? Any advice in general would be greatly appreciated!
I am debating removing the LCD resistors from the board and using a hack between the screen and controller. This could be on perfboard or resistors in the cable. I'm not sure if this would save enough space to be worth the hassle..
I'm not sure if I will breadboard this since I JUST ordered parts, or rush to boards. I'm working with OLD hardware for now.
I am finally announcing a name for the project, as long as it's not already taken. I am thinking about calling this project "PropERmidi Core V1". I did a quick google and couldn't find anything by this name.
On an unrelated note, I've been working on my propFont buttons, and have a serious bug. When program is started, the buttons are initialized on. Then on first press, all the buttons except for the one that was pressed turn off. Other than this, it works fine. Someone please help. This should not be this complicated.
BGCOLOR = $ffd0 TXTCOLOR = $0000 Pressed = 1 NotPressed = 0 var LONG BackgroundColor, ActiveTextColor, CRbuffer WORD Button0[5], Button1[5], Button2[5], Button3[5], Button4[5], Button5[5], ButtonX, ButtonY, ButtonState, OldState pub ButtonLoop WORD NotPressedBGC,NotPressedATC,PressedBGC,PressedATC, ButtonName, ButtonReg if b <> 6 getbutton(b) !oldstate !buttonstate setbutton(b) updatebuttons PUB ButtonInit | b Button0[0] := 1 'set bit3 to disable on startup Button0[1] := 206 Button0[2] := 78 Button0[3] := 1 Button0[4] := 0 Button1[0] := 54 Button1[1] := 206 Button1[2] := 66 Button1[3] := 1 Button1[4] := 0 Button2[0] := 108 Button2[1] := 206 Button2[2] := 209 Button2[3] := 1 Button2[4] := 0 Button3[0] := 161 Button3[1] := 206 Button3[2] := 209 Button3[3] := 1 Button3[4] := 0 Button4[0] := 216 Button4[1] := 206 Button4[2] := 66 Button4[3] := 1 Button4[4] := 0 Button5[0] := 271 Button5[1] := 206 Button5[2] := 78 Button5[3] := 1 Button5[4] := 0 PUB GetButton(Button) case Button 0: ButtonX := Button0[0] ButtonY := Button0[1] ButtonName := Button0[2] ButtonState := Button0[3] OldState := Button0[4] 1: ButtonX := Button1[0] ButtonY := Button1[1] ButtonName := Button1[2] ButtonState := Button1[3] OldState := Button1[4] 2: ButtonX := Button2[0] ButtonY := Button2[1] ButtonName := Button2[2] ButtonState := Button2[3] OldState := Button2[4] 3: ButtonX := Button3[0] ButtonY := Button3[1] ButtonName := Button3[2] ButtonState := Button3[3] OldState := Button3[4] 4: ButtonX := Button4[0] ButtonY := Button4[1] ButtonName := Button4[2] ButtonState := Button4[3] OldState := Button4[4] 5: ButtonX := Button5[0] ButtonY := Button5[1] ButtonName := Button5[2] ButtonState := Button5[3] OldState := Button5[4] PUB SetButton(Button) | btn case Button 0: Button0[3] := ButtonState Button0[4] := OldState 1: Button1[3] := ButtonState Button1[4] := OldState 2: Button2[3] := ButtonState Button2[4] := OldState 3: Button3[3] := ButtonState Button3[4] := OldState 4: Button4[3] := ButtonState Button4[4] := OldState 5: Button5[3] := ButtonState Button5[4] := OldState PUB DrawButton(Button) | x, y if ButtonState == Pressed pfw.WriteActiveCr(1, ButtonY, ButtonX, 0, 0, PressedBGC, PressedATC) pfw.WriteNextActiveCr(ButtonName) pfw.WriteNextActiveCr(9) else pfw.WriteActiveCr(1, ButtonY, ButtonX, 0, 0, NotPressedBGC, NotPressedATC) pfw.WriteNextActiveCr(ButtonName) pfw.WriteNextActiveCr(9) PUB UpdateButtons | x, y, b repeat b from 0 to 5 getbutton(b) if ButtonState <> OldState OldState := ButtonState if ButtonState <> Pressed pfw.WriteActiveCr(1, ButtonY, ButtonX, 0, 0, PressedBGC, PressedATC) pfw.WriteNextActiveCr(ButtonName) pfw.WriteNextActiveCr(9) else pfw.WriteActiveCr(1, ButtonY, ButtonX, 0, 0, NotPressedBGC, NotPressedATC) pfw.WriteNextActiveCr(ButtonName) pfw.WriteNextActiveCr(9) ButtonReg := !((Button1[3]<< 5) | (Button0[3] << 4) | (Button2[3] << 3) | (Button5[3] << 2)| (Button3[3] << 1 ) | (Button4[3])) pst.clear pst.hex(buttonreg,4) SendSwitch(ButtonReg)I changed the hardware again. I wanted stereo outs, so I fumbled around and now SidCog is tested. I will be testing some of the other sound generators. I noticed a large transient on starting SIDcog, not sure why.