ralphb Posted July 29, 2018 Author Share Posted July 29, 2018 Yes, that HEX is the latest version (there is only one), and the HEX is the final result of all those crazy steps. You'll also find it in the repository: https://github.com/endlos99/flashrom99/blob/master/avr/flashrom.hex (use "Raw", then save) Quote Link to comment Share on other sites More sharing options...
ColorComputerStore Posted August 3, 2018 Share Posted August 3, 2018 (edited) I completed the build of my FLASH ROM cart and tested it. The results was the machine's LED didn't light up and the TI just booted to its regular screen. OH NOOOOOOOO! I need some expert help to understand what could be wrong. First, I want to share my board front and back. See attachments. I made the boards with the GIT gerbers. All solder joints look correct. I believe I purchased all the right components with the right specs. Only component I wasn't sure about was the tactile switch. I wasn't sure which orientation it should be in. I also placed some paper under the board and above the SD Card to separate them. Although I did solder the tactile switch from above and not at the bottom of the board. Is my board the issue? I obtained the HEX file (flashrom.hex) to program the ATMega from this message thread. Not sure if there is a download link for a newer version? Is my HEX version the issue? I used a TL866A to program the HEX file. I used the photo that CosmicBoy posted as a reference for my settings. See the difference in the attachment. I noticed was that he was programming a ATMEGA8515 and I was programming a ATMEGA8515L. I bought the 'L' version. Is that the issue? When I loaded the HEX file, I was given the option to load the file format as BINARY or Intel HEX. I picked HEX. The File Start Addr(Hex) and TO Buffer Start Addr (HEX) were left as 00000. That brought up an error message 'Out of Address of the device!'. I didn't think about it much so just clicked OK and proceeded. The program said it was successful. The SD Card has about 12 games on it. All in BIN format and all under 32K. I got them from an archive someone here posted with about 171 programs. To recap... I inserted the board. Turned on the TI. It went to its normal boot screen. The board's LED never came on. I am praying that the issue is just a bad programming of the ATMega8515. I appreciate everyone's help as this will be more first adventure with TI software if I can get it working. Thanks, Carlos Edited August 3, 2018 by ColorComputerStore Quote Link to comment Share on other sites More sharing options...
+arcadeshopper Posted August 3, 2018 Share Posted August 3, 2018 I completed the build of my FLASH ROM cart and tested it. The results was the machine's LED didn't light up and the TI just booted to its regular screen. OH NOOOOOOOO! I need some expert help to understand what could be wrong. First, I want to share my board front and back. See attachments. I made the boards with the GIT gerbers. All solder joints look correct. I believe I purchased all the right components with the right specs. Only component I wasn't sure about was the tactile switch. I wasn't sure which orientation it should be in. I also placed some paper under the board and above the SD Card to separate them. Although I did solder the tactile switch from above and not at the bottom of the board. Is my board the issue? I obtained the HEX file (flashrom.hex) to program the ATMega from this message thread. Not sure if there is a download link for a newer version? Is my HEX version the issue? I used a TL866A to program the HEX file. I used the photo that CosmicBoy posted as a reference for my settings. See the difference in the attachment. I noticed was that he was programming a ATMEGA8515 and I was programming a ATMEGA8515L. I bought the 'L' version. Is that the issue? When I loaded the HEX file, I was given the option to load the file format as BINARY or Intel HEX. I picked HEX. The File Start Addr(Hex) and TO Buffer Start Addr (HEX) were left as 00000. That brought up an error message 'Out of Address of the device!'. I didn't think about it much so just clicked OK and proceeded. The program said it was successful. The SD Card has about 12 games on it. All in BIN format and all under 32K. I got them from an archive someone here posted with about 171 programs. To recap... I inserted the board. Turned on the TI. It went to its normal boot screen. The board's LED never came on. I am praying that the issue is just a bad programming of the ATMega8515. I appreciate everyone's help as this will be more first adventure with TI software if I can get it working. Thanks, Carlos With those socketed front chips are you even able to insert the cartridge all the way? Sent from my LG-H872 using Tapatalk Quote Link to comment Share on other sites More sharing options...
ColorComputerStore Posted August 4, 2018 Share Posted August 4, 2018 It's tight, but yes, it slides in. 1 Quote Link to comment Share on other sites More sharing options...
+arcadeshopper Posted August 4, 2018 Share Posted August 4, 2018 It's tight, but yes, it slides in.With the cases i sell i had to solder those in to fit. Sent from my LG-H872 using Tapatalk Quote Link to comment Share on other sites More sharing options...
ColorComputerStore Posted August 4, 2018 Share Posted August 4, 2018 Right now, the lowest priority is the height of the ICs due to the sockets. This was just a test board. Anyone, one the topic of troubleshooting... Someone over on Facebook mentioned latter TIs were tweaked so that only Final GROM board will work. As I tested my board on a beige TI, I thought that might by the issue. Alas, even on a Silver TI it failed to operate. Any other advice? I think one concern was in the ATMega version I used and the settings on my programmer. As mentioned, my programmer did throw up an error. Is the original designer of this board still active on AtariAge? Cheers Quote Link to comment Share on other sites More sharing options...
Shift838 Posted August 5, 2018 Share Posted August 5, 2018 Right now, the lowest priority is the height of the ICs due to the sockets. This was just a test board. Anyone, one the topic of troubleshooting... Someone over on Facebook mentioned latter TIs were tweaked so that only Final GROM board will work. As I tested my board on a beige TI, I thought that might by the issue. Alas, even on a Silver TI it failed to operate. Any other advice? I think one concern was in the ATMega version I used and the settings on my programmer. As mentioned, my programmer did throw up an error. Is the original designer of this board still active on AtariAge? Cheers It very well could be the ATMega chip, especially if you threw an error on programming. Ralph is active on this board (Ralphb). He was just online a few days ago. Send him a PM Quote Link to comment Share on other sites More sharing options...
ralphb Posted August 5, 2018 Author Share Posted August 5, 2018 First of all, I would try using the cart without shell. For the LED, could you try to put it the other way around? I seem to remember that I had labeled or designed it the wrong way around. But I might be mistaken, as everything looks alright now. If the LED still doesn't work, there is some basic problem with the HEX file, or your power supply. Have you checked that everything gets 5V? For the ATmega, I think people used the "L" version successfully. Nominally, the non-L can run faster, but I only run it at 8 MHz, which both can handle. Quote Link to comment Share on other sites More sharing options...
Asmusr Posted August 5, 2018 Share Posted August 5, 2018 When I loaded the HEX file, I was given the option to load the file format as BINARY or Intel HEX. I picked HEX. The File Start Addr(Hex) and TO Buffer Start Addr (HEX) were left as 00000. That brought up an error message 'Out of Address of the device!'. I didn't think about it much so just clicked OK and proceeded. The program said it was successful. I would retry that step and try go get rid of that error message. 2 Quote Link to comment Share on other sites More sharing options...
ColorComputerStore Posted August 5, 2018 Share Posted August 5, 2018 Good news peeps... Working with a noted CoCo community engineer, he was able to walk me through it. Board was fine. Issue was programming MCU. Thanks all. 3 Quote Link to comment Share on other sites More sharing options...
HOME AUTOMATION Posted December 11, 2018 Share Posted December 11, 2018 (edited) "The FinalGROM 99 now can dump ROM images, GROM images, and mixed images with at most one ROM bank. This functionality is needed for the persisting Mini Memory image with SAVE option."I have this MINIMEMORY image... When I use the save option 4K RAM is saved But certain addresses in two different ranges are corruptedFor instance >7000 should be >A55A but always reverts to >0000also:>702F705A705B70727073708C708D708E7096709F70A870A97FAE7FAF I identified the bytes by using a HEX EDITOR to make a comparison of RAM files containing THE LINES DEMO and the LINE BY LINE ASSEMBLER before and after a SAVE. The addresses that are compromised and values imposed are fairly consistent. Always 16 Bytes. I relocated the GPL save routine from the middle of the GROM file and placed it in the last 2K of this file as only the first 6K were used... the remaining 2K containing a copy of the previous 2K. I also changed the menu order so that SAVE is 4 instead of 3.Little or no improvement.I considered that the SAVE routine being written in GPL... GPL might be accessing UTILWS at >7092 or USRWSP at >70B8 during the save loops execution.Perhaps there is an electronic flaw in my board. Can another user help verify these results.If I load a program using option 1 LOAD and RUN... run it... SAVE... go back to option 2 RUN... error... without even having exited the image. Edited December 11, 2018 by HOME AUTOMATION 1 Quote Link to comment Share on other sites More sharing options...
ralphb Posted December 11, 2018 Author Share Posted December 11, 2018 I can more or less confirm your observations. As far as I can see, the last two bytes seem to be modified by Minimem itself, but all the other ones are modified by the FinalGROM 99. And it's not my additional code I added to the Minimem image, but the FinalGROM code itself. If I remember correctly, I only checked that LINES would run after saving, but this was clearly not enough. Now, please allow me some time to examine this. This is quite strange, as the GROM file is also saved, but without any errors at all. 2 Quote Link to comment Share on other sites More sharing options...
ralphb Posted December 17, 2018 Author Share Posted December 17, 2018 This puzzle has been quite mysterious to me. I can reconfirm the above error, but all my other dump tests work flawlessly. I've been poring over my signals, and how the modes LOAD, RUN, SETSIZE, ... are switched. Maybe there was a tiny undefined moment during switching, where the GROM received a spurious write command and wrote some random bytes to the RAM before the switch was completed? Anyway, just now it hit me. For dumping files, the TI (i.e., Minimem) tells the FG99 uC that it wants to dump data. Just like bank switching, this is done by writing a given dump-initiating byte sequence to >70xx, where xx is the byte to send times 2. Writing to ROM for extra functionality has been done for ages, since, well, nothing happens. Except in this case we're not writing to ROM, but RAM. If you trace your bad bytes, you'll find that they spell out >99 OKFG99 >99, multiplied by 2. It's just too bad how the Mini Memory has been designed. 1 Quote Link to comment Share on other sites More sharing options...
HOME AUTOMATION Posted December 17, 2018 Share Posted December 17, 2018 Anyway, For dumping files, the TI (i.e., Minimem) tells the FG99 uC that it wants to dump data. Just like bank switching, this is done by writing a given dump-initiating byte sequence to >70xx, Hmm. I would have thought the dmp.seq write would go to 60xx or 68xx. Are you giving up on this? ... I found a way to work around this... but way to difficult... Quote Link to comment Share on other sites More sharing options...
ralphb Posted December 17, 2018 Author Share Posted December 17, 2018 Hmm. I would have thought the dmp.seq write would go to 60xx or 68xx. It also writes to >6000, as a clock. But yes, I think the >7000 line can be shifted to something else, between >6200 and like >6800. Bank switching will not be affected by this. I'll work something out. 1 Quote Link to comment Share on other sites More sharing options...
HOME AUTOMATION Posted December 17, 2018 Share Posted December 17, 2018 I was thinking... If there were a slight delay added before the FG99 starts dumping... The initiating code could first copy the original bytes... send the dumping code ">99 OKFG99 >99" then restore the original bytes before the dump starts... Quote Link to comment Share on other sites More sharing options...
ralphb Posted December 17, 2018 Author Share Posted December 17, 2018 Sure, that would also work, but as you said, it'd be quite complicated. Quote Link to comment Share on other sites More sharing options...
HOME AUTOMATION Posted January 1, 2019 Share Posted January 1, 2019 I want to thank ralphb... for the fast responses and attention to detail.This issue was cleared up for me in 2 days TOPS. Thank you and congratulations. Ha... Ha... Happy! New Year! Quote Link to comment Share on other sites More sharing options...
ralphb Posted January 1, 2019 Author Share Posted January 1, 2019 Thanks! I'll post the updates in the next few days. Quote Link to comment Share on other sites More sharing options...
R.Cade Posted March 28, 2019 Share Posted March 28, 2019 (edited) Hello all, I built my FlashROM99 from an eBay kit. Because of the strangeness of the chips not all "facing" the same way, I reversed one of the 541 chips. I realized my mistake while looking for the problem, then reversed it, but the cart still did not work. I then got a new 541 chip and it the cart comes up now. First, I ran banktest.bin, but it only showed "BANK 1: OK" and nothing else (no 2-4). So I studied the board again. I then realized my kit was missing the 68 ohm resistor, so I got one of those and now the bank test passes. However, no 32k roms will work... they load and then the screen goes blank and stays light blue. 8k roms load fine... so something else is wrong! I already tried a new SRAM chip and it does the same thing. All the rest of the solder looks fine. Any ideas where to look? Well, I take that back. Pitfall works and it's 32k (from the zip file on the Github pages). Do some of these ROMs require 32k expansion RAM? Edited March 28, 2019 by R.Cade Quote Link to comment Share on other sites More sharing options...
Omega-TI Posted March 28, 2019 Share Posted March 28, 2019 However, no 32k roms will work... they load and then the screen goes blank and stays light blue. 8k roms load fine... so something else is wrong! I hate to ask such a basic question, but do you have a 32K memory expansion on your TI? Quote Link to comment Share on other sites More sharing options...
R.Cade Posted March 28, 2019 Share Posted March 28, 2019 I hate to ask such a basic question, but do you have a 32K memory expansion on your TI? I do not, and that seems to be the issue. I downloaded a pack of BIN files known to work without 32k and they are all working fine. Quote Link to comment Share on other sites More sharing options...
+Ksarul Posted March 28, 2019 Share Posted March 28, 2019 Pretty much any file larger than 16K requires the 32K to run. As you have found a few (like Pitfall!) were designed to run from the cartridge space right from the start, but in general, a 32K BIN file won't run without 32K memory attached. 1 Quote Link to comment Share on other sites More sharing options...
ralphb Posted March 28, 2019 Author Share Posted March 28, 2019 I then realized my kit was missing the 68 ohm resistor, so I got one of those and now the bank test passes. This is interesting. The FlashROM I'm using right now also has this resistor, but I have other working FlashROMs without this resistor. In fact, when people mail me and ask why their FlashROM doesn't work, I advise them to remove the resistor, and suddenly the cart works. In your case it was the other way around. Good to know that it depends on the individual cart if a resistor is needed on not. Quote Link to comment Share on other sites More sharing options...
R.Cade Posted March 28, 2019 Share Posted March 28, 2019 This is interesting. The FlashROM I'm using right now also has this resistor, but I have other working FlashROMs without this resistor. In fact, when people mail me and ask why their FlashROM doesn't work, I advise them to remove the resistor, and suddenly the cart works. In your case it was the other way around. Good to know that it depends on the individual cart if a resistor is needed on not. The seller said they don't include it and you should just jumper over it with a wire. Does that sound correct? Mine did not work without the resistor, for sure. I didn't try a simple jumper. 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.