OrganGrinder

hi boris technically 4 2*40 lcd is possible, see http://www.ucapps.de/mbhp_lcd.html remember for each additional LCD after the first, you will need one additional pin on the core so that each LCD can be differentiated from the rest (something to do with the LCD communication specs) also to get it to work you will need to customise the application you are using as this configuration of LCDs as it probably is not currently supported in the code. OrganGrinder

hi atom have you checked that the optcoupler is oriented the right way? i noticed on the schematic and with smashtv's cores that the optcoupler is oriented in the opposite direction to the pic (i'm going by the direction of the orientation notch on the chips) hope this helps OrganGrinder

yea, any nerd worth his/her salt knows of the water drip torture. 8)

Hi dcreatorx Smash has placed the parts correctly, its just that the pic and the 6n138 are oriented in opposite directions. if you view the core on SmashTV's site http://www.avishowtech.com/mbhp/mbhp_coreR4.html you will see that the orientation notch of the pic is to the left, while the orientation notch of the 6n138 is to the right. i only mentioned this because i caught myself assuming that the notch on both chips where to be facing the same way. i don't know what would have happened if i did this and turned the power on (probably just blow the 6n138). i will reiterate, i do not know of any mistakes done by SmashTV in the design of his boards. OrganGrinder

HI i know this is a silly question, but is the 6n138 oriented the right way. I noticed that SmashTV's Core_R4 (which is what i'm using) has the 6n138 oriented "upside down" in relation to the pic. also (and this seems silly too) have you tried swapping the M+ and M- wires on either midi in or midi out (assuming you are not using a pcd mounted 5pin din on the core), i found that i needed to use a crossover connection with the core's midi out to a casemount 5pin din. if you have a close look at the tracks for the midi out on the core_r4 you will see why the crossover is needed. i believe this was done so that when connecting 2 cores directly to each other, a crossover wire would not be needed. and please, my reference to a crossover wire is NOT in reference to a standard midi connection wire, but the connection between a core and a non-pcb mount 5pin din socket. OrganGrinder

Hi for a 2x16 blue lcd try www.futurelec.com they have branches world wide and sell for a good price and shipping is cheap. they also sell almost anything we would need for midibox. OrganGrinder

hi what are you asking? what do you mean by valid? everything i have read on this forum says that the use of LCD screens is very important in the development of a midibox project, even if the final product dosen't use one. OrganGrinder PS if asking a question like this, please give details, otherwise the people who know may just ignore it.

hi back to the original discussion i also had the problem of about 1/2 the voltage when testing a core, i thought it was a problem with the voltage regulator. turned out that i had not soldered the bridge rectifier properly, a resolder and the it core tested perfectly. hope this helped OrganGrinder

Hi guys ok the week is over, and i am closing the offer. for those who thought the price was too high, work out for yourselves how much it would be to import unused ymf262's and yac512's. OrganGrinder

hi all tel3 mentioned a site selling for us$5. that is the site i approached and they quoted us$6 each, add shipping (from usa to oz) and take exchange rate into account and it works out to be about au$11.50 each. i forgot to mention before that these are reputed to be virgin chips, never used before. now if this is too expensive, compare the going price for sid chips from commodore 64's - look up the midibox sid forum - they are selling for much more and for a chip with less capability. and of course if you are confident with desoldering - you can take used chips from disused sound blaster cards, which would be cheaper still. now as i said before, the current going rate is au$11.50 (that is how much per chip it will be costing me so far) and if it works out cheaper, i will directly pass the saving on. just thought it would be best to have everyone informed. OrganGrinder

hey stride i know the price i gave is a little steep, but i am not making any profit on this (it will cost me the same per chip). with a larger order, hopefully the per item costs will go down and we will all save. as i said before, i will pay my fair share and plan the break even with the everyone elses orders. when i make the order, i will let eveyone who put dibs in know how much it will cost them. the postage is intended to use the prepaid 500g satchels @ au$4.90 from australia post. i have plenty of tubes and electrobags so i don't see any other costs.

hi slorrin just recieved my order of sids thanks OrganGrinder

hi all i am planning to make an order for some ymf262 and yac512 chips in about a week. problem is that the seller wants a minimum order which is much more than i require. anyone in Australia want to join in, please reply with their requests. at the moment i estimate the price to be: au$11.50 per chip (either ymf262 or yac512) plus au$5 for postage to anywhere in Australia (parcelpost). if there is enough interest, maybe the seller will give a bulk discount. OrganGrinder

and i agree with most of the rest of what you said. i as a software developer, also have the problems you are talking about but on the other side of the fence. convincing the software owner/contractor to put the money and resources in so that we can eliminate the bugs. it is amazing how much software is out there with known bugs, but the contractor says it is good enough. please understand that it is vurtually impossible to make large software projects bug free, the amount of time and resources to do so would make the software prohibitively expensive (think $50,000 instead of $50) and with all the variability with computers - trust me it's too much for your brain to imagine. now for a relatively simple system say a pacemaker, you can do the testing necessary, but once it is on a general computer (PC, Mac etc) forget it. also, unless the contractor keeps the development team unbroken and available, it will probably be different people working on finding and fixing any post release bugs (and your wouldn't believe how much documentation needs to be read to do so). so in the end, there is a limit in how much can be assured before the product goes to market. and don't blame the developers, but the people who decide when the software is released - they are rarely involved with the day to day hands on development. case in point, if you examine computer games, the reason why they tend not be be buggy anymore is that the software (commonly refered to as the game engine) is normally finished 1-2 years before release and can be checked thoroughly, the extra time is needed for developing the 3d environments and all that sort of stuff (the creativety of a software developer is not the same kind of creativity for a graphic designer). OrganGrinder

hi i just send a new order to scientific solutions, this time taking ixox suggestion about minimum order into account. i hope they reply this time, i think i will start bugging them if they don't OrganGrinder

hi bill i suppose that flukes solution might work, but it would be harder for you to read (and understand) later on. i would stay with the temporary variable, but you would limit the context by enclosing within braces {} int x,y; ... { int tmp; tmp = x; x = 7; y = tmp; } this way the compiler has the option of what to do with the tmp variable, it may only use it in that part of code, or it may initialise it at the beginning of the function. as i said, its the compilers choice.

hi thomas your point 1 makes sense about creating overhead to perform pointer arithmatic. in point 2, stryde is inquiring about a the use of multiplie dimension arrays, and i brought forward the idea of used an advanced data structures. firstly, because the number of elements is unknown, and from what i was able to gather from his earlier posts, a means which did not require random access. the conclusion i came up with was linked lists because they meet the needs that were mentioned and are fairly easy to use once you know what is happening. now i acknowledge that a linked list has a small memory overhead (1 pointer in addition to the data), also binary trees and two way linked lists have a larger overhead (2 pointers in addition to the data). but stryde has mentioned that the data is at least 16 bytes in size, so this overhead is fairly low. of course not as low as an array (1 pointer total plus the data). in regard to processing overhead, stryde has said that his project will require random searching, and editing of data, but minimal adding and removing data elements. as mentioned earlier, linked lists are hopeless with random searches, but search a sorted and balanced binary tree is faster than searching a sorted array (btree just follows the pointers, while an array has to calculate where to search next). the big difference is that the binary tree does the sorting when the data element is inserted into the binary tree which has some overhead, and possibly some overhead if the tree needs to be rebalanced if an element is added or removed. point 3, about the difference between the efficiency of a multiply function as opposed to an adding loop. care needs to be taken, firstly occurding to microchip all assembly commands take 1 cycle except branches which take 2. now your loop has overhead in creating the loop and the branch with each iteration. any idea how this compares to how it is done on the chip? maybe the pic does exactly the same thing, or maybe something else... a comparison would be useful, i presume the pic's method works reasonably well for all potential values. but if you can guarentee that you multipying values are small, and you code is faster, go ahead and use it - its a good idea if you need to squeeze a little more speed out of your code, but i suggest getting the code to work first before optimizing. (and document what you are doing so people reading it will understand why) point 4, what are you getting at here? people who are new to programming are overwelmed by c, trying to keeping everything together and doing what it is supposed to do. making them read the assembly derived from their code (problably without documentation) at best will scare them, or even drive them away. let beginner programmers write their code, get it to work and be confident about it. then if they wish, they can examine what their code means to the computer (assembly is only 1/2 step above the actual machine code, C is at the top of the staircase). after all this, lets not forget way we are posting on this topic - stryde needs some help in organising the data for his program. from previous posts, i believe stryde requires a data structure where most changes to the data structure itself is at the beginning of the program, and then the structure is relatively stable requiring random searches and edits of the data elements themselves (this does not effect the data structure), and finally removal of the data structure when the program is finished. additionally it seems that stryde would like to go beyond the 256 element limit which appears to affect arrays with the c compiler being used for the pic (it is an 8 bit processor afterall). thanks for your input, its got me to revisit and think about issues i havn't visited in a while. OrganGrinder

hi stryde if you want fast random access, consider a tree structure for what you are describing, the use of a sorted tree would be of benefit. it keeps the linked lists nature of allowing for variable amounts of data and works out to be a little slower than arrays. eg a linked list searching amount 1000 data records would take on average 500 lookups, a tree of the same size can be as good as 9 lookups on average (there are ways to keep this consistant). the problem is that trees are not for the faint hearted, they can be a pain to administer. as i said above if the tree is sorted, it makes it easier to search. additionally, if you balance the tree (this is where it can be real mind blowing, but it is not that hard to program), it will keep search times down (in theory, a tree in the worst case sinerio is essentially a linked list, but i suggest reading about trees to understand what i mean and why it happens). just as a side note, trees are commonly used in games and other virtual environments (read situation which requires extremely fast access and administration speeds) because of their flexibilty to cater to dynamic situations, have reasonable random search times and it is possible to keep associated data close together in the tree. but bear in mind that recursive algorithms are often used in these applications. (if anyone has a complaint about recursive algorithms, just remember that there are situations where recursion is more efficient than iteration and this is not the right post for a dispute on this matter.) OrganGrinder

Hi stryde well, if you already know structs, then you might be ready for advanced data structures. what i would suggest is to look up linked lists, as they have a very small maintenance cost, and very low memory requirements. if you look linked lists up, you may come across vectors (an implementation of an array with a variable size) - do not use a vector structure, the pic has a small amount of memory and we are trying to use a real time operating system, vectors are unsuitable for a midibox environment!!! you should be able to find decent tutorials about implimenting linked lists over the net, otherwise an examination of learning C books should get the information needed. i am not prepared to describe how to impliment a linked list at this time (i will have to draft and proof read it first). it may be possible that linked lists are implimented in SDCC lib, but i don't know. (thanks audiocommander for reminding me of that library) a few key points about linked lists include: a linked list is a sequential data structure which can take a variable number of elements (any number between 0 and as many as your memory can take). the memory requirement of a linked list is the data being stored plus 1 pointer per data element - this works out to be about the same as for an array due to the structure of a linked list, random access is rendered very inefficient, but sequential access is very fast. just so you know, i learned about linked lists (as well as other data structures) in 2nd semester university (we had to know how to programm first!). these data structures (including linked lists) can be confusing to some people and some care needs to taken into their implimentation and use. this should make you sufficiently curious and scared, so i will leave to draft my description on making linked lists. OrganGrinder

hi tom i agree that you can make valid code with the use of pointer math. but now days it is considered bad programming style. there are even books on learn c which do not cover pointer mathematics. the big problem with c/c++ is that there are no checks on memory access. what can happen is that a pointer can be assigned to any location in memory, the type associated with the pointer is only used in determining the size of the memory block that is being accessed. what happens with arrays is that by using a subscript that is too large, or the use of pointer mathematics, is that a part of memory outside of the array could be accessed. the big problem with this is that when accessing memory outside of an array is normally a runtime error and is not picked up by the compiler, and may only be detected through observing "strange" results. for example int ar1[] = {1,2,3,4}; int p; int ic; p = 5; for (ic = 0; ic<= 4; ic++) { ar1[ic] = ar[ic] + 1; } printf ("%d", p); now in most compilers, memory allocation is performed sequentially so in this case ar1 would have 4 int sized blocks which is immediately followed by an int block for p and then an int block for ic. now as you can see from the code, the loop iterates five times (i=0,1,2,3,4) but the 5th time ar[ic] will actually access the memory location of p. so the value of p has been altered without even an explicit call to the value of p!!!! btw tom doing something like this is a bad idea. FIRST, you are mixing explicit values with variables. what i mean is: what will happen if you changed the declaration to say: unsigned char mem[3*4*6]. now if you go through the code and change every occurance of x*20 with relation to mem, you progam may still work, but if you miss just one it will cause a bug which would be difficult, if not impossible to find. instead if you have to do it, try this: #define memX 3 #define memY 4 #define memZ 5 unsigned char mem[memX * memY * memZ]; unsigned char calculate_offset(unsigned int x, unsigned int y, unsigned int z) { return ((x*memY*memZ) + (y*memZ) + z); } what happens here is that the precompiler will scan through your code and substitute the numerical values for the macro names (this is now c does constants). but in addition, you only need to alter one line and it will be reflected throughout your code provided you have consistently used the macro names. additionally, it will make it easier to read the code as you are reading labels which are associated with what they represent rather than some arbitrary number. SECOND, the pic is not a pentium 4. what i am getting at is that the modern pentium chips are capable of performing a integer muliply in a single clock cycle, the pic takes several cycles. therefore, the frequent use of multiply and divide will slow your code down, the only i can think of is to rework you algorithms, but in the above case, i don't think that is possible without doing some niftly stuff which will take longer than applying the multiplies. THIRD, see my comments on pointer mathematics - especially if you try to access beyond your declared array sizes oh - just reread your post, it looks like you are not advercating the use of pointer math, just offering it as an alternative if all else fails. sorry about hitting so hard, but at least i have out there why pointer math should be avoided. OrganGrinder

hi stryde i had a quick look at that book you posted in another thread i only had a quick look, but it seems as good as anything from a bookstore. if any of my above explainations are unclear, look it up in the book (ch 5). they had on payrole editors, proofreaders etc so it should be easily read. if you have any questions, post away, there are always people willing to help (this from a midibox newbe to a midibox guru ... lol) OrganGrinder

i cannot answer the first part at this time. but the second part is that the extra look up does have an effect on performance. let me explain btw the times are only approximates from by experience with 80x86 assembly, if someone knows the actual times, it would be appreciated. for an ordinary variable say an int, the lookup would be 1 cycle, just recalling the value stored by the variable (at a specified memory location). for an one dimensional array, the lookup would be about 3-4 cycles lookup the pointer to the array, add the offset, and retrieve the value for a two dimensional array, the lookup would be about 6-8 cycles lookup the pointer to top level array, add the offset, retrieve pointer to second level array, add 2nd level offset, retrieve the data. for a three dimensional array, the lookup would be about 9-12 cycles lookup the pointer to top level array, add the offset, retrieve pointer to 2nd level array, add 2nd level offset, retrieve pointer to 3rd level array, add the offset, retrieve the data. as you can see, as you go deeping into a multidimensional array, the cost can become quite large if it is done frequently. this can be offset with the use of temporary variables, particularly in loops (which is where the use of arrays if often done). other advantages of multidimensional arrays include the simplification of code (i will not say easier to debug because any problems avoided by keeping related data in the multidimention array is offset by different potential bugs). lets have a look a the difference with some code: for demonstation purposes, i will show some differences between 1 and 2 dimensional arrays: 1 dimension: int do[] = {1,2,3,4,5}; int rei[] = {2,3,4,5,6}; int me[] = {0,9,8,7,6}; int i,j; for (i = 0; i < 5; i++) { for (j = 0; i < 5; j++) { do = i + j; rei = i + j; me = i + j; } } 2 dimensions: int do[] = {1,2,3,4,5}; int rei[] = {2,3,4,5,6}; int me[] = {0,9,8,7,6}; int* scale[3]; scale[0] = do; scale[1] = rei; scale[2] = me; int i,j,.k; for (i = 0; i < 5; i++) { for (j = 0; i < 5; j++) { for (k = 0; k < 3; k++) { scale[k][j] = i + j; } } } now both examples do the same task, but if you extend the number of array elements to 20, 30 or more, the first example would become large, unwieldy and bugprone as you create more arraynames and need to remember which to include in your calculations and in what order. on the other hand, the second example would only need a small amount of modification and continue to do its task. just remember that with the 18F452, every assembly opperation takes 1 clock cycle except branches (jumps) which take 2 cycles. as you can see in the examples, the first example can become unwieldy if its size increases. but the second example with slow down as more lookups and branches occur (each iteration of a loop requires a branch function in assembly). additionally you will also need to consider the speed of the processor, the 18F452 is rated at 10 MIPS (million instructions per second) so it if don't go overboard in creating large arrays and looping through them with abondon, the overall effect would be negligable. personally, i would first get my code to work correctly using deep nested arrays if necessary. then if needed, i would reexamine the code and introduce optimisations such as temporary variables and unwinding array nests in order to get the code faster. it is quite possible to double the size of your code and only improve the program speed by 5-10 percent. just remember when optimising your code - always keep backups of your code!!! that way you can discard optimisations that don't work - never hope you can undo the changes you make when you find the changes don't work. I know this was a bit verbose but i wanted to provide some of the reasons to use multidimensional arrays and some of the pitfalls. OrganGrinder

hi stryde just so you know, i have not programmed for midibox at all but i do know C what i am suggesting assumes the c compiler used with midibox will recognise the syntax with a 1 dimensional array, each element of the array is a value of the arrays type. when you use a 2 dimensional array, the first element is a pointer to the 1 dimensional array represented by the second element. ie: a 1 demension array of five elements: array1[] = { 0, 1, 2, 3, 4} a 2 demension array of 3 by 5 elements: array1[] = { pointer to array2, pointer to array3, pointer to array4} array2[] = { 0, 1, 2, 3, 4} array3[] = { 1, 2, 3, 4, 5} array4[] = { 2, 3, 4, 5, 6} so accessing array1[2][1] = 3 (remember C starts counting from 0 therefore we are looking for array1[3rd element][2nd element]) now extending the above, there is nothing limiting the 2nd level arrays (array2,array3,array4) to having the same size. these 2nd level array may be different sizes, but doing so will make the code more difficult to administer and become more bug prone as there are no checks in c to ensure you are not referencing beyond the arrays length. this information can be confirmed in any reasonable c manual or teaching textbook and i would recomend looking the subject up as i haven't touched the area of declaring arrays, i prefer c++ or java so i can avoid malloc and simplify the process with new. as a said before, i have not programmed for midibox before. if the information above dosn't help, it may be that the compiler cannot handle multiple dimension arrays (which i would find disturbing and asking what else it dosn't support). OrganGrinder

hi i sent a request for a quote for some ymfs and yacs a week ago, and they havn't replied. if you can get a bulk order going, i am interested. OrganGrinder

i agree wholeheartedly when you read a rumour, you assume it is true. of course to assume makes an ASS out of U the writer and ME the reader. ::) there is nothing stopped the internet being filled with total rot, but the efforts of conciencious people who wish everything to be right and truthful, like the moderators and most people on this forum. don't take everything on face value but test the truthfulness and make up your own mind. :o ie if you get burnt, then you have evidence that whoever is unreliable. of course there are other ways to test someones honesty, such as the testimony of someone you trust. ;) if you don't know anyone to trust, read extensively from this forum, you will work it out. ;D OrganGrinder