Tursi Posted June 22, 2014 Share Posted June 22, 2014 Google searches say this means you set the clock to external. Attach an external clock to the device as per the datasheet, and you should be able to program it again. I've done this on my own setup many times. It doesn't have to be overly fancy, I use a dedicated "half size clock oscillator" just dangling on three wires, and that's enough to recover when I do that. (Also, my keyboard controller needs the faster clock, so I use it there too.) 1 Quote Link to comment Share on other sites More sharing options...
CantStopClicking Posted June 23, 2014 Share Posted June 23, 2014 Well, I made a little progress this weekend! So far so good! -Dano 2 Quote Link to comment Share on other sites More sharing options...
slinkeey Posted June 23, 2014 Share Posted June 23, 2014 Ooooh GPIO and UART Test? Cart based communications? Quote Link to comment Share on other sites More sharing options...
CantStopClicking Posted June 23, 2014 Share Posted June 23, 2014 Ooooh GPIO and UART Test? Cart based communications? Think of the possibilities!?!? I'm stoked. :-))) Now, if I just knew how to program... guess it's time to start learning! -Dano Quote Link to comment Share on other sites More sharing options...
+Ksarul Posted June 23, 2014 Author Share Posted June 23, 2014 Excellent, Dano! Now we'll just have to document what you did and add that to the manual too. . . Quote Link to comment Share on other sites More sharing options...
+arcadeshopper Posted June 23, 2014 Share Posted June 23, 2014 studio.. I will try avrdude tomorrow and see where it gets me ..i have an avrispmk2 clone programmer too Avrdude can't see my burner.. it doesn't show up as a tty device..shrug got tired of messing with it, even did the udev stuff the internets say to do.. Greg Quote Link to comment Share on other sites More sharing options...
+arcadeshopper Posted June 23, 2014 Share Posted June 23, 2014 Google searches say this means you set the clock to external. Attach an external clock to the device as per the datasheet, and you should be able to program it again. I've done this on my own setup many times. It doesn't have to be overly fancy, I use a dedicated "half size clock oscillator" just dangling on three wires, and that's enough to recover when I do that. (Also, my keyboard controller needs the faster clock, so I use it there too.) CIMG1017.JPG I'll need a part number I got 4 more on their way.. but two that are unusable now, worst case i'll send them to you with return postage Greg Quote Link to comment Share on other sites More sharing options...
UKRetrogamer Posted June 24, 2014 Share Posted June 24, 2014 Avrdude can't see my burner.. it doesn't show up as a tty device..shrug got tired of messing with it, even did the udev stuff the internets say to do.. Greg I'm waiting for my cart boards to arrive but I've used Atmel's AVR Studio 6 with an AVR MKII ISP on my Windows PC to write to ATMega ICs for use with Arduino before now, so I'm reasonably accustomed to it. I also managed to get the thing working under Linux using the "udev stuff" you mentioned. I'd previously had my breadboard ISP circuit working in Windows, so I knew when it wasn't working under Linux, it HAD to be a permissions thing. You could try "sudo su" before issuing the avrdude commands. If it works, you'll know your ISP is setup correctly. If not, time to check your connections... This is how I figured out my initial AVR ISP problems when toying about with my "Shrimp-kit" Arduino boards. Other than pinouts, I'm not expecting much difference with the ICs used in these carts. ...but we'll see?! Quote Link to comment Share on other sites More sharing options...
UKRetrogamer Posted June 24, 2014 Share Posted June 24, 2014 (edited) studio.. I will try avrdude tomorrow and see where it gets me ..i have an avrispmk2 clone programmer too I bought an avrispmkii clone and found it was only recognised with Atmel's AVR Studio up to v4. In order to use the latest version, I had to buy a genuine Atmel AVR ISP MKII. Although the clone came with a fly-lead to convert from 10-pin to 6-pin, I ended up buying a small circuit board converter [http://www.ebay.co.uk/itm/like/310635615426?limghlpsr=true&hlpv=2&ops=true&viphx=1&hlpht=true&lpid=108&device=c&adtype=pla&crdt=0&ff3=1&ff11=ICEP3.0.0&ff12=67&ff13=80&ff14=108] along with one of Adafruit's ISP header kits [http://www.adafruit.com/blog/2013/08/07/new-product-adafruit-6-pin-avr-isp-breadboard-adapter-mini-kit/] to plug-into a breadboard. The beauty of the Adafruit header is the pins are labelled, so it's easy to know which wire goes where when wiring up for programming via the ISP on a breadboard. Edited June 24, 2014 by UKRetrogamer Quote Link to comment Share on other sites More sharing options...
Tursi Posted June 24, 2014 Share Posted June 24, 2014 I'll need a part number I got 4 more on their way.. but two that are unusable now, worst case i'll send them to you with return postage Well, that depends on the frequency you want, that was why I used the full search term for the part. I guess you can try this one: http://www.mouser.com/ProductDetail/ABRACON/ACHL-16000MHZ-EK/?qs=%2fha2pyFaduiQjBA%2fYc2o%252bJnfC3LvyhfQcRoMFh4Ok9w2V6HRnn0WUw%3d%3d Are you using the STK500 or similar board from Atmel? Seems to me they have a clock source on the board as well. Check your manual! Quote Link to comment Share on other sites More sharing options...
Tursi Posted June 24, 2014 Share Posted June 24, 2014 Ooooh GPIO and UART Test? Cart based communications? Yes... I demoed the UART (which is a 5v TTL device) at the Chicago TI Faire in 2010 when I released the AVR code (I showed communication with an embedded Linux board mounted inside the cartridge ). 6 GPIO pins are exposed (configurable as outputs or inputs with or without internal pull-up resistors), as well as 4 ADCs, and an independent 16-bit high-speed counter. The UART also has dedicated 256 byte RX/TX buffers to allow higher speed operation. These are new to this design. I intended it to be a design people might use to create new cartridges and new types of cartridges. As well as the 120k of GROM space, there's also 4k of EEPROM space and 12k of RAM (accessible via GROM, so you can't run CPU code from it). Everything is accessible and much is configurable over the GROM memory space. The source is (somewhat) modular, so in theory if you were a developer you would be able to add additional functionality to your AVR, things that I had in mind were co-processors (math, graphics, etc, it's a nearly 8 MIPS CPU!) and SD-card access. But, those are pipe dreams for now. Quote Link to comment Share on other sites More sharing options...
CantStopClicking Posted June 24, 2014 Share Posted June 24, 2014 Excellent, Dano! Now we'll just have to document what you did and add that to the manual too. . . Sounds like an excellent idea, except, I can't reproduce it now! It's like the AVR isn't seeing the 49f040 and won't load the "GROM TEST" menu page at all now. I can get the Easy Bug menu to show up via the space bar but the GROM TEST won't show up anymore. Tursi; is there a way to remove the "self-destruct" portion of the code? Since it self destructs after first power on (as I'm interpreting my reading - which could be wrong) if anything goes wrong the "GROM TEST" code is blown away and have to re-program the AVR again. I suspect there's some timing problem or something and the AVR isn't executing something at the right time and therefore the "GROM TEST" code gets blown away before I ever get to see it. Point is; with the self-destruct, it's incredibly hard to test. Something changes upon boot and re-flashing is the only way to get it back and now I can't even get it "back". What would really be nice is if I could flash the AVR, remove the self-destruct code, allow the EA5 files GROMTEST to run without having to rely solely on the built in "GROM TEST" menu - which sometimes shows up but, mostly not. I'm sure that all sounds confusing but I think Tursi might pick up what I'm trying to say (i'm not even sure myself). Thoughts anyone? -Dano Quote Link to comment Share on other sites More sharing options...
CantStopClicking Posted June 24, 2014 Share Posted June 24, 2014 Oh, couple more things I just thought of.... Is is possible to get a additional test in on the GROMTEST (EA5 and/or GROM Menu) to check for the 49f040? Really, really, really, would like to be able to run GROMTEST from E/A and test these things but GROMTEST (EA5 version) won't test anything, everything reports "FAIL". However, IF, the GROM menu shows up (gromdemocart2013 method) then the tests work fine. But, that "GROM TEST" menu has only showed up for me twice now, out of 20 some reprogrammings. And related to the 49F040, is there the "potential" to be able to flash the 49F040 via AVR or in-circuit? Those PLCC's are a BITCH to F*CKING remove and requires four insertion and removals per programming. TOTALLY SUCKS when shit ain't working... I realize that this one is a "future" request but I can see it running up the flag pole real quick if anyone starts actually programming PLCC's by hand. yuck... Thanks for listening! -Dano Quote Link to comment Share on other sites More sharing options...
CantStopClicking Posted June 24, 2014 Share Posted June 24, 2014 I'll need a part number I got 4 more on their way.. but two that are unusable now, worst case i'll send them to you with return postage Greg I might be able to recover those for you. I just had to do that to my second AVR, which came from the factory set completely unusable @ 128Khz internal clock rate. Took me 24hrs of messing with it to finally get the fuse settings to take. Connecting the external crystal didn't make a lick of difference in my case. I had to reduce my communication speed ridiculous low and just keep hit program until it finally set a fuse to become stable enough to take a second programming. Side note; if using AVRDude, never use "-F", unless you are ABSOLUTELY SURE. I found that parameter made my situation worse and generally does. Don't use it unless you know what you're doing, do not gamble on a chance to "see" if it fixes your problem, cuz if it doesn't, then you've got bigger problems ahead. -Dano Quote Link to comment Share on other sites More sharing options...
CantStopClicking Posted June 24, 2014 Share Posted June 24, 2014 Here's a good quick read on getting started with AVR's using AVRDude. I like it cuz it quick and dirty and shows you 'how to' on all platforms (Mac, Linux, Windows). http://www.ladyada.net/learn/avr/avrdude.html -Dano 1 Quote Link to comment Share on other sites More sharing options...
Tursi Posted June 25, 2014 Share Posted June 25, 2014 It's like the AVR isn't seeing the 49f040 The AVR can't communicate with any part of the 49F040, it doesn't have a connection to any of the lines. This also precludes it handling the programming, assuming there are no other issues. Tursi; is there a way to remove the "self-destruct" portion of the code? Since it self destructs after first power on (as I'm interpreting my reading - which could be wrong) if anything goes wrong the "GROM TEST" code is blown away and have to re-program the AVR again. No, and no. The program is blown away on first launch because testing the GROM necessitates destroying the data stored in it -- if nothing else the configuration changes many times and blows away the boot config. This was meant as a manufacturing test. However, all it does it copy to RAM and run, it is /identical/ to the EA#5 version, and part of why the 'recovery' has an EA#5 loader. This is why you don't need to re-program the AVR just to run the test program. I am not sure why you are having trouble with that. But, this is why none of this was released yet. It's not stable and we don't know which part. I had no issues till I put a ROM on my board, which is why I suspected power or something similar. I suspect there's some timing problem or something and the AVR isn't executing something at the right time and therefore the "GROM TEST" code gets blown away before I ever get to see it. It doesn't get blown away until the test menu is loaded and it prints that it is changing the configuration. If you can see the Easy Bug menu, the AVR is working 100%, because that's just GROM code being referenced and accessed. Point is; with the self-destruct, it's incredibly hard to test. Something changes upon boot and re-flashing is the only way to get it back and now I can't even get it "back". This is the price of pre-release code. But you should not be relying on that piece of code as any kind of proof of operation. use Easy Bug and Run Program File instead. allow the EA5 files GROMTEST to run without having to rely solely on the built in "GROM TEST" menu If the EA#5 version does not work then your console is not seeing the AVR GROM properly. As I noted, I have major instability issues on my own machine. Is is possible to get a additional test in on the GROMTEST (EA5 and/or GROM Menu) to check for the 49f040? Not in my code, this is a test of the AVR GROM functionality intended for my own use. But you have source code!! You can do everything you need to do to verify the 49F040 in Easy Bug, that's why THAT is present in the recovery code. Quote Link to comment Share on other sites More sharing options...
CantStopClicking Posted June 25, 2014 Share Posted June 25, 2014 The AVR can't communicate with any part of the 49F040, it doesn't have a connection to any of the lines. This also precludes it handling the programming, assuming there are no other issues. No, and no. The program is blown away on first launch because testing the GROM necessitates destroying the data stored in it -- if nothing else the configuration changes many times and blows away the boot config. This was meant as a manufacturing test. However, all it does it copy to RAM and run, it is /identical/ to the EA#5 version, and part of why the 'recovery' has an EA#5 loader. This is why you don't need to re-program the AVR just to run the test program. I am not sure why you are having trouble with that. But, this is why none of this was released yet. It's not stable and we don't know which part. I had no issues till I put a ROM on my board, which is why I suspected power or something similar. It doesn't get blown away until the test menu is loaded and it prints that it is changing the configuration. If you can see the Easy Bug menu, the AVR is working 100%, because that's just GROM code being referenced and accessed. This is the price of pre-release code. But you should not be relying on that piece of code as any kind of proof of operation. use Easy Bug and Run Program File instead. If the EA#5 version does not work then your console is not seeing the AVR GROM properly. As I noted, I have major instability issues on my own machine. Not in my code, this is a test of the AVR GROM functionality intended for my own use. But you have source code!! You can do everything you need to do to verify the 49F040 in Easy Bug, that's why THAT is present in the recovery code. Well that quote reply got mutilated. I have yet to figure out how you multi-quote here. Oh well. Thanks for the explanation. I had a brain fart and was making the 49F040 more complicated than it really was. I "get it" now. It's just the "ROM" and the AVR is the "GROM". Ok, so now that I have that under control. Your responses make complete sense in that respect. The issue that remains for me is; the AVR MUST be working if I get the Easy Bug menu? Which I do, without problem. But if I launch the GROMTEST tools from the Load and Run menu, I get a green screen instead of a blue screen and all tests fail. See pic below: So that part confuses me. If I get the Easy Bug menu then the AVR is working but the tests fail. The ONLY time the tests have passed is when the "GROM TEST" menu shows up from the 49F040 code (not launched from easy bug). Is that a scenario that should be happening? -Dano Quote Link to comment Share on other sites More sharing options...
CantStopClicking Posted June 25, 2014 Share Posted June 25, 2014 Oh, forgot to ask.... Tursi, are you willing to share your GROMTEST 9900 source code too? :-))) -Dano Quote Link to comment Share on other sites More sharing options...
Tursi Posted June 25, 2014 Share Posted June 25, 2014 The issue that remains for me is; the AVR MUST be working if I get the Easy Bug menu? Think about it -- what has to happen in order for Easy Bug to come up? Easy Bug is a GPL program, it does not use expansion RAM at all. If you can load and run Easy Bug (or "RUN PROGRAM FILE", which is the so-named GPL code from the E/A cartridge), then GROM emulation is fully functional, otherwise the program can't run! It stands to reason then, that the GROMTEST program is what's failing. (As for the screen color difference, that's just the difference in launch environment, I remember looking at it briefly when I noticed it, too.) Here's the latest copy of GROMTEST that I have -- not sure if it is the same as what you have. gromtest.zip THAT SAID... I took a quick look at the issue. This software was written to prove the functionality before I implemented the recovery mode. If you run it FROM recovery mode, it doesn't work because parts of the AVR are locked down (and so do not respond as they are supposed to ) By resetting the AVR after booting GROMTEST (AVR reset pin to ground, they are side by side on the jumper), I was able to see most of the tests pass. (Not all, though I'd have to dig into why I saw failures, but I suspect a less-than-clean reset.) If you have the AVR stable (Easy Bug works), then you should be set to move on to the next phase, rather than worrying too much about my test program. Quote Link to comment Share on other sites More sharing options...
Tursi Posted June 25, 2014 Share Posted June 25, 2014 Oh, forgot to ask.... Tursi, are you willing to share your GROMTEST 9900 source code too? :-))) -Dano It was already in the archive that I was sent, which is supposedly what others were given? gromtest.zip Good luck. Quote Link to comment Share on other sites More sharing options...
CantStopClicking Posted June 25, 2014 Share Posted June 25, 2014 Think about it -- what has to happen in order for Easy Bug to come up? Easy Bug is a GPL program, it does not use expansion RAM at all. If you can load and run Easy Bug (or "RUN PROGRAM FILE", which is the so-named GPL code from the E/A cartridge), then GROM emulation is fully functional, otherwise the program can't run! It stands to reason then, that the GROMTEST program is what's failing. (As for the screen color difference, that's just the difference in launch environment, I remember looking at it briefly when I noticed it, too.) Here's the latest copy of GROMTEST that I have -- not sure if it is the same as what you have. gromtest.zip THAT SAID... I took a quick look at the issue. This software was written to prove the functionality before I implemented the recovery mode. If you run it FROM recovery mode, it doesn't work because parts of the AVR are locked down (and so do not respond as they are supposed to ) By resetting the AVR after booting GROMTEST (AVR reset pin to ground, they are side by side on the jumper), I was able to see most of the tests pass. (Not all, though I'd have to dig into why I saw failures, but I suspect a less-than-clean reset.) If you have the AVR stable (Easy Bug works), then you should be set to move on to the next phase, rather than worrying too much about my test program. Ok, cool. I kinda figured that the AVR must be working but I didn't want to ASSume too much. This is all very new to me but I find this a very intriguing project for multiple reasons. If nothing else, to learn microprocessors a little bit better and what better way than to learn it here and for the TI. So please bare with my idiotic questions while I learn the ropes. I know this project got ahead of you Tursi so I'm not trying to pressure you into adding things to your "to do" list but rather learn a little and maybe someday even help. Thanks for reposting the gromtest file, I had a version of it (not sure if it's the same or not) but I was looking for 9900 source code and now see that it is actually within the AVR source code. Will have to think more on that one before the fog clears and I can begin to understand any of it. hehe But, it gives me something to look at and study. Thank you! Cheers! -Dano Quote Link to comment Share on other sites More sharing options...
Tursi Posted June 25, 2014 Share Posted June 25, 2014 No worries, I'm not trying to be condescending, I'm just trying to teach the questions to ask in this scenario. The source code is in C and is written for the GCC port, that's why there's no assembly code. The resulting EA#5 images were just converted to binary and linked into the appropriate space in the AVR memory image so they'd show up as GROM on first run. Quote Link to comment Share on other sites More sharing options...
CantStopClicking Posted June 25, 2014 Share Posted June 25, 2014 No problem here. I just don't want you to think I'm unappreciative of what you've done here by asking noob questions because, I absolutely positively do appreciate it! I'll be lucky if I can even figure out how to compile what you've already presented let alone create something on my own but, I'm willing to try. :-) -Dano Quote Link to comment Share on other sites More sharing options...
CantStopClicking Posted June 25, 2014 Share Posted June 25, 2014 (edited) Tursi, What do you make of this screen shot? (UberGROM with AVR with DemoCart2013 code applied) That randomly popped up when I reset the TI. I reset the TI because I had let it sit at the start menu for a looooong time (I wasn't paying attention to it) and noticed the screen had changed to green. Looked like the TI had locked up (no response), so I turned off power and back on and this showed up (the Multicart Menu). I tried option #B but it locked up with garage on the screen. Reset the TI again, and it's now gone, only TI Basic for Option 1 (normal TI menu screen) Thought that was kind of odd. Where could that possibly have come from? I'm assuming it must be part of the DemoCartEEPROM.hex or more likely the DemoCartFLASH.hex on the 49F040? Is that possibly a result of unknown state the 74LS378 is known to exhibit upon startup? Just curious... Cheers! -Dano Edited June 25, 2014 by CantStopClicking Quote Link to comment Share on other sites More sharing options...
+acadiel Posted June 25, 2014 Share Posted June 25, 2014 I think we are now at the point where we are crowd sourcing trying to fix the flakiness of the AVR and ROM together. :-) Great job getting it up, Dano! Quote Link to comment Share on other sites More sharing options...
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.