Jump to content


  • Content Count

  • Joined

  • Last visited

Community Reputation

1,571 Excellent

1 Follower

About Wrathchild

  • Rank
    River Patroller

Contact / Social Media

Profile Information

  • Gender
  • Location
    Reading, UK.
  • Interests
    Porting games the A8 never had

Recent Profile Visitors

24,131 profile views
  1. A quick Google would have told you this is an Atari emulator? http://www.virtualdub.org/altirra.html Along with many topics on AtariAge, e.g.
  2. @Back2skooldaze With Side3 in Altirra you can try things out in there and when happy transfer the card image
  3. The aim of moving it to cart was to allow the game to run in 64K, hence not a high priority
  4. I did begin this but as the original is 128K and uses the $4000-$7FFF memory area for the bank swapping its a fair amount of work to jiggle this around to run from the cart bank memory areas... not impossible... just a lot of work... and I get distracted easily
  5. Responding to the OP, mine are here
  6. agreed. I was wanting to clarify that even an 8K bank with 8K-1 byte of FFs would still be written to the cart. My own background was writing the emulation code for flash writing back in 2007 so not unfamilar with the concepts, in the back of my mind I recalled the skipping of redundant banks but failed to confirm it when reviewing the code. If you can do alternative version of your board with support for the XEGS Switchable model then I'd take some of those as that's a physical board model that's currently missing aside for hacking your own I believe.
  7. Was going to write as had already concluded that the studio is stripping any 8K block that is all $FF in order to keep the effort down, so apologies there. As the example, this image is all $FF's with the last byte of each bank set to zero and so the resulting ATR is the 1027KBdummy.bindummy.bin
  8. Not quite a valid test, set the last byte of the all FF image to 0 Here's the programming loop: Program8K: ; CODE XREF: PerformReFlash+12�p JSR ShowProgress LDA #$D STA StrOutLen LDA #$54 ; 'T' LDY #$17 JSR PutText ; Program Flash LDA #0 STA CopySrc+1 LDA #$20 ; ' ' STA CopySrc+2 LDA #0 STA CopyDst+1 LDA #$A0 STA CopyDst+2 loc_0_1137: ; CODE XREF: seg000:117A�j JSR chip_1 BIT CurBank BVC cmd_program JSR chip_2 cmd_program: ; CODE XREF: seg000:113D�j JSR cmd_unlock LDA #$A0 JSR wr5555 LDX CurBank STA $D500,X CopySrc: ; DATA XREF: seg000:1125�w seg000:1157�r ... LDA $FFFF CopyDst: ; DATA XREF: seg000:112F�w seg000:1168�r ... STA $FFFF CLC LDA CopySrc+1 ADC #1 STA CopySrc+1 LDA CopySrc+2 ADC #0 STA CopySrc+2 CLC LDA CopyDst+1 ADC #1 STA CopyDst+1 LDA CopyDst+2 ADC #0 STA CopyDst+2 CMP #$C0 BNE loc_0_1137 CLC RTS
  9. What a depressing start to the day, many misleading ideas here: This title would not need use of MfCS as it is assembled directly to the binary image, hence the programmer's responsibility to setup the cart vectors correctly. MfCS is only needed to a) convert the binary to an ATR image for programming the cart on an A8 or b) program the image directly to a cart using the USB programmer. Not true, the physical cart needs two chips present other wise, in your case here, the second chip would presumably return all 'FF' or '00' and so no vectors in bank 127 seen and hence the cart would not start. So yes this would work in the bank 0 init model but not in the bank 127 model, the idea is to have an image that supports both. Changing a BIN/CAR image into an ATR image for flashing the cart with does not strip out any data and so the ATR size will not be any smaller. First half of the statement true but its not because of the latter, the flash chip will always need to be erased. From the documentation I don't think the AM29F040B has a 'intelligent controller' that would skip bytes like this. The time saving occurs as there are less (i.e. none) bit transitions from 1 to 0 to be made within those bytes. The AtariMax ATR image programming loop merely reads 8K blocks from the disk into memory at $2000 to $3FFF and after setting the cart to programming mode and the right bank these are copied to $A000->$BFFF.
  10. However the KIL fix should get further I would think although as this could mask or culminate in other issues was only a test, so again is best await the next release although does give Jon something to look at.
  11. Isn't that from 6th June and so you haven't mentioned if you've updated the side loader with the new one on this thread afterwards? [Edit] scrap that idea, the side loader is in the cart isn't it... doh
  • Create New...