Jump to content

Photo

Flash ROM Cart


468 replies to this topic

#451 ralphb OFFLINE  

ralphb

    Dragonstomper

  • Topic Starter
  • 599 posts
  • Location:Germany

Posted Sun Jul 29, 2018 2:44 AM

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)



#452 ColorComputerStore OFFLINE  

ColorComputerStore

    Chopper Commander

  • 137 posts
  • Location:USA

Posted Fri Aug 3, 2018 6:22 AM

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

Attached Files


Edited by ColorComputerStore, Fri Aug 3, 2018 6:24 AM.


#453 arcadeshopper OFFLINE  

arcadeshopper

    River Patroller

  • 4,082 posts
  • Location:Portland, Oregon USA

Posted Fri Aug 3, 2018 4:04 PM

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

#454 ColorComputerStore OFFLINE  

ColorComputerStore

    Chopper Commander

  • 137 posts
  • Location:USA

Posted Fri Aug 3, 2018 7:41 PM

It's tight, but yes, it slides in.

#455 arcadeshopper OFFLINE  

arcadeshopper

    River Patroller

  • 4,082 posts
  • Location:Portland, Oregon USA

Posted Fri Aug 3, 2018 7:48 PM

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

#456 ColorComputerStore OFFLINE  

ColorComputerStore

    Chopper Commander

  • 137 posts
  • Location:USA

Posted Sat Aug 4, 2018 5:09 PM

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



#457 Shift838 OFFLINE  

Shift838

    River Patroller

  • 2,468 posts
  • SHIFT838
  • Location:Deer Park, Texas

Posted Sat Aug 4, 2018 8:36 PM

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



#458 ralphb OFFLINE  

ralphb

    Dragonstomper

  • Topic Starter
  • 599 posts
  • Location:Germany

Posted Sun Aug 5, 2018 2:55 AM

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.



#459 Asmusr OFFLINE  

Asmusr

    River Patroller

  • 3,007 posts
  • Location:Denmark

Posted Sun Aug 5, 2018 4:09 AM

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.



#460 ColorComputerStore OFFLINE  

ColorComputerStore

    Chopper Commander

  • 137 posts
  • Location:USA

Posted Sun Aug 5, 2018 9:29 AM

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.

#461 HOME AUTOMATION OFFLINE  

HOME AUTOMATION

    Chopper Commander

  • 249 posts
  • Location:"trapped in interspace"

Posted Mon Dec 10, 2018 11:22 PM

"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 corrupted

For instance >7000 should be >A55A but always reverts to >0000

also:
>
702F
705A
705B
7072
7073
708C
708D
708E
7096
709F
70A8
70A9
7FAE
7FAF

 

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 by HOME AUTOMATION, Mon Dec 10, 2018 11:35 PM.


#462 ralphb OFFLINE  

ralphb

    Dragonstomper

  • Topic Starter
  • 599 posts
  • Location:Germany

Posted Tue Dec 11, 2018 12:33 PM

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.



#463 ralphb OFFLINE  

ralphb

    Dragonstomper

  • Topic Starter
  • 599 posts
  • Location:Germany

Posted Mon Dec 17, 2018 11:15 AM

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.  :idea:   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.  :ponder:

 

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.  ;)



#464 HOME AUTOMATION OFFLINE  

HOME AUTOMATION

    Chopper Commander

  • 249 posts
  • Location:"trapped in interspace"

Posted Mon Dec 17, 2018 11:41 AM

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...



#465 ralphb OFFLINE  

ralphb

    Dragonstomper

  • Topic Starter
  • 599 posts
  • Location:Germany

Posted Mon Dec 17, 2018 12:08 PM

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.



#466 HOME AUTOMATION OFFLINE  

HOME AUTOMATION

    Chopper Commander

  • 249 posts
  • Location:"trapped in interspace"

Posted Mon Dec 17, 2018 12:15 PM

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... :idea: :)



#467 ralphb OFFLINE  

ralphb

    Dragonstomper

  • Topic Starter
  • 599 posts
  • Location:Germany

Posted Mon Dec 17, 2018 12:32 PM

Sure, that would also work, but as you said, it'd be quite complicated.  :)



#468 HOME AUTOMATION OFFLINE  

HOME AUTOMATION

    Chopper Commander

  • 249 posts
  • Location:"trapped in interspace"

Posted Tue Jan 1, 2019 2:24 AM

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! :party:



#469 ralphb OFFLINE  

ralphb

    Dragonstomper

  • Topic Starter
  • 599 posts
  • Location:Germany

Posted Tue Jan 1, 2019 6:08 AM

Thanks!  :)   I'll post the updates in the next few days.






0 user(s) are browsing this forum

0 members, 0 guests, 0 anonymous users