I cannot find where I put my bit right now, but I am sure other people have posted the same solution.
All you do is make the shaft part a little longer by grinding away the hex part. Then cut a groove in the top of the hex part, because to get out the deep screws, the socket on the driver will hit the case, so you cut a notch so that you can use a flat-head or fillips screwdriver instead of the socket driver.
Hopefully this all makes sense, if not then search for it, I know someone has to have posted pictures.
Anyway, it is non-destructive, so you can use it normally for everything except the deep sockets.
Ideally you could spin it on a lathe to take off the material. I used a table sander. The bare minimum would be a file and do it by hand.
The TI calculators allow you to use arrays. You could start learning about them by trying to implement them on your calculator. And better yet, the book that came with your calculator should tell you how to program with arrays.
DogP, I understand your point. I just didn’t like how many solutions were being suggested when such an elegant solution existed!
And after reviewing my earlier post, I realize I came off as a jerk, sorry!
DogP wrote:
Fwirt wrote:
You know, now that you bring that up, why do you even need to mask it and check for equality when you could just do:
if (turn & 0x01)
Heh, I was gonna point that out too
Basically, it is a good habit to always use a relational or equality operator in every if/while/for statement to make sure your intentions are properly implemented and easily understood by others. I think it is even a MISRA rule, but I am not 100% sure and don’t have a copy handy.
So I used the “== 0x01” style for clarity, and let the compiler optimize out unnecessary C code. “((turn & 0x01) == 0x01)” will automagically be converted to “(turn & 0x01)” by the compiler. But by writing it with the “== 0x01” my code should have been more readable, especially being it follows the same pattern as a multi-bit mask would.
Okay, seriously, you guys are all making way too big a deal over figuring out if it is the computer or human turn. The quickest and easiest way is to use a mask…
if (turn & 0x01 == 0x01) {
/* Player A turn */
} else {
/* Player B turn */
}
DaVince, your code seemed to be missing stuff. Looking at the code, it looks like the y distance would increase by 1 acceleration unit whenever speed = 0. I think this would work better.
while (loop_condition == TRUE) {
if(y_dist == 0) {
/* We are on the floor, so check if a jump is requested */
if ((keys & jump_key) == jump_key) {
/* Only checks if key is pressed when on the floor */
y_speed = max_jump_velocity;
y_dist = y_speed;
} else {
/* No jump requested, make velocity equal to 0 */
y_speed = 0;
}
} else {
/* Middle of a jump, update speed, calculate distance */
y_speed -= accel;
y_dist += y_speed;
}
}
Once again, untested code.
Could be beneficial to check to make sure y_dist is within range for the original if statement. If you are outside of the possible range a y could be, then you have to error handle. But this was intentionally left out.
This code assumes ground is 0, and you jump in the positive y direction.
A more realistic feel would include checking how long the button was held for to adjust the length of the jump, which is not included in the above code.
I have not looked at the game’s C code either, or even tried out the game. I will get around to it sometime, just been busy.
I can assure you nobody who does development for the VB is in it for any compensation.
So the problem is you have a small community, which means a really small dev community, and I would say that the majority of the small dev community works full time, and quite possibly in grad school or an equivalent time drain.
For me, the past month has been like this…
Monday thru Thursday: leave house at 8AM for work, go straight from work to school, get home between 10 PM and 12 midnight.
Friday: Leave house at 8AM, get home around 6 to 6:30 PM. Fall asleep watching TV.
Saturday: Get up around noon, try to get caught up on school stuff, end up staying up until 3 or so working.
Sunday: Same as Saturday.
So you can see I didn’t even have time for my personal life. Everything was put on hold because I just didn’t have time.
Fortunately I am now done with school for this semester, but that doesn’t stop the large time drain called work. And the backlog of stuff I have put off. So by the time I get caught up with everything, I am sure school will be starting again.
I do plan on having a game out within the next few months. Will it happen? I don’t know, only time will tell. But I want to do it right so that I can release a complete game with fully commented source code along with state machine diagrams and such in order to show the full dev cycle.
Does that answer your question?
And the only reason a competition sparks a bunch of releases is because it gives a deadline, and without deadlines you will never get anything done.
TheForce81 wrote:
Thank you for your research and experimenting on this technique! I fixed my second VB with this method and it is VERY easy compared to other methods in my opinion!
I’m glad you got it to work! I would feel pretty lousy if I recommended a way that did not work!
DogP’s method really does provide a better quality result, but it is my belief that my method is good enough. And really, both do the same thing, remove the film and solder the copper to the pcb traces.
And for anyone trying this, just a few recap notes. Yes, I did use too much solder. But if you don’t have or don’t want to use additional flux, then once the solder stops rolling around, add more solder. But I am in a way glad that the only video I took showed me being wasteful with solder to show anyone how sloppy you can be while doing smt soldering. And you do have to be careful with overheating. I had my soldering iron set to my normal soldering temperature (sorry, I do not have a nice soldering station so I do not know what temperature this is), but DogP has reported that it is easy to damage the cable if it gets too hot (which is why he continued to experiment for a better way).
I don’t claim to be a PCB expert by any means… but that looks like a pretty dinky ground… Plus the more copper you use, the more environmentally friendly 😉 (remember, PCB making is a subtractive process)
And you read the FRAM data sheet, right? The stuff I bought won’t work with the VB because of what you have to do when you write to it.
And autoroute probably won’t work too well for something like this. I assume you are using it because the vias are randomly sprayed about. Don’t forget that just because the data pin says it is data 0 or data 1 or whatever doesn’t mean you have to connect it to that one on the VB cart! Same with some of the address lines. Might make the routing easier.
And no, no switch on my design. Just a huge flash cart.
You could probably fit 7 of that package, but you would need a 4 layer pcb, and well I just don’t see the point. It would cost more than it would be worth. If something like that was going to be attempted, it seems like it would make more sense to try to use an FPGA and fewer flash chips. Or make a cart that actually has game save capabilities.
I should say, I have a physical pcb in hand with everything soldered in place, but I have no programmer yet. So I am using the above chip, but I don’t know for sure it will actually work.
Anyway, I use a voltage regulator to power the chip at the appropriate voltage (I think I am using a 3V regulator).
Then I also tie the 5V from the VB to VCCQ, the output power supply. This allows my data output to reach logic level 1 for the VB.
And if you look at page 9, it says address and control lines can take up to 5.5V, and data lines can take VCCQ + 0.6V and output VCCQ – 0.1V.
It runs at 2.7V, but it was made to work with 5V systems as well. I have not been able to verify that it works, but according to the spec system it should. You still need a voltage regulator, but it can handle 5V inputs and should output 5V as well (you put whatever voltage you want the outputs to be on one of the pins)
You can get larger ones in the same pin config, which is the reason I went with this one. Don’t have time to look up the other chips, but I don’t think the bigger ones are too much more expensive.
So SD would be cheaper for a lot of memory, but I mean, flash seems cheap enough to me.
SD and such would be more convenient, but it is much easier than that to make a multi cart.
Three options I see…
1. Use dip switches that are hardwired to the upper few address lines of your large rom/flash chip (or to the CEs of a few smaller ones). Advantage is it is real easy, disadvantage is you have to allow for each game to be the max size any game ever was, and have to hack your cart up.
2. Use a uc that is connected to the EXT lines. Then, put in your own program somewhere on the main ROM that runs your code. Once you select the game you want to play, the micro will control the upper address lines just like the dip switch did. It will be told what to do based on the info it gets over the EXT lines. Advantages are you don’t have to hack your cart up, it looks more professional, and you can have different sized games all on one cart. Disadvantages are harder to implement.
3. Put an FPGA inside that would convert real addresses to virtual addresses. Would work by getting instructions on the mapping in a similar way as the uc. By using an FPGA, you could make a cart that would let you load games at any spot you want on the rom.
I put them in order of my initial guess of complexity.
A few things I thought of, maybe these pins can be sourced by themselves in a crimp on format? Or at the very least, they can be pulled out of USB cables. Then they can be put in your own thing.
Another thing you could do is get a Card Edge / Edgeboard connector. May take some hacking to get it to fit in, but could be pretty cool.
Edit: Err, you said that in your last post, nevermind!
If you could find anywhere to buy the connector, then a lot of people would be happy. Well maybe not a lot. But regardless, I have had no luck finding anything with that spacing and to the best of my knowledge nobody else hase either.
And it would be possible to make the connector, sure, but that would be a lot of work, and I think the mold might break pretty quickly.
I do still plan on making the cartridge shell, but have not gotten arond to it yet. I have half the mold done, but I don’t think it will work. It is kind of expensive, what I have found as a general rule is if you can buy the part, then don’t make it yourself.
Umm… it will if you go with surface mount and then get a custom made PCB… I got 2 made for about $40 (flat cost of $25 then $3 per sq inch of PCB), and then my flash chip was $5 or $6, then the voltage regulator was $2 or something, cant remember. I have one board assembled but not tested yet, I don’t have my programmer made yet (got lazy). I have a 16 bit flash chip, so I either need to get a 16 bit flasher or make my own, so I decided to make my own.
The method DogP did was really the easiest and cheapest, even if it does mean cutting up a cartridge.
I really should get back to work on my flasher, but 13 hour days slow me down a bit! Plus it is my first USB project, so I still need to get that part sorted.
Ok, so the seller seems legit, not trying to pull a fast one. And so assuming everything the seller said was correct, the game is most likely from America. So I am going to go ahead and lock in my answer of the American Virtual League Baseball.
Because of the quality of the game, I think it is either Virtual League Baseball or Japanese Mario Tennis. It wouldn’t be the US Mario Tennis because this looks like a cartridge that was never really used. Of course, with no label, the two are identical 😉
But being it looks so good, it could be something rare, like a demo that would have been used once at a show like CES or something. But those seem like they would have gotten beaten up.
You should just lie to us and tell us it is the 007 game or something. You know, lie enough so we know you are fibbing but not enough that you could be telling the truth. That way we will get a quick thrill before we realize you are joking!
