Jump to content

Wrathchild

Members
  • Content Count

    2,611
  • Joined

  • Last visited

Community Reputation

1,338 Excellent

About Wrathchild

  • Rank
    River Patroller

Contact / Social Media

Profile Information

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

Recent Profile Visitors

23,395 profile views
  1. The 128KByte/1Mbit CART has one plcc socket for the am29f010 chip and the 1MByte/8Mbit cart has 2 sockets, each for the 512KByte/4Mbit am29f040 chips. So yes, use the larger cart and make a single large binary to program it with by repeating the image in a single file.
  2. WSYNC - if you are working on DLIs then you will know what that is
  3. USB to 9-pin ST mouse adaptor - for use on ST & A8 machines
  4. Whilst the sentiment is agreed with, lets be clear here that the .car images are the basis for people replacing the PROMs on existing cartridge boards so that they can be played on XL/XE based h/w. They could indeed be placed on a modern cart such as The!Cart, AVGCart and UNO/Ultimate cart and run on those, these are titles that already had xex/atr versions patched to play equally as well on XL/XE machines. So whilst the target audience is limited, kudos to @Atari_Ace for enjoying and sharing the journey!
  5. Perhaps use a page of memory and store the pointers there? table_lo = $600 table_hi = $680 maketable: ldy #0 ;loop through the characters value (0-127) loop: tax ;save character in X-reg and #%01100000 ;isolate the hi bits asl ;shift left ensuring carry is clear rol rol ;rotate the bits to be in bits 0 & 1 rol adc change_font+2 ;add bits to hi-byte (MSB) sta table_hi,Y ;store the resulting value txa ;Get character value back from X into A asl asl ;3 asl = multiply by 8 asl sta table_lo+1 ;store the result in lo-byte (LSB) iny bpl loop rts Then use this as follows: lda character and #127 tax lda table_lo,x sta change_bck+1 lda table_hi,x sta change_bck+2 [EDIT] ah, I was too slow, others have done similar
  6. @vbc take a look at this thread (and the link to the cc65 site within it) for details on the reserving of graphics memory the move to $2000 would be for the default, presumably this could be overridden in the command line if needed? This is not only for DOSes, many of the multi-carts utilise their own binary executable bootstrap loader that is typically loaded in this lower memory area. With both those and a DOS, the coder if free to trash that area and reuse it for anything else if the code/data there is not going to be used after.
  7. I would think it depends on what you are calling within the vbi and hence if that is using/trashing any of the shared variables?
  8. 5. By completely ignoring posts 45 and 46 and citing two disks you know to exploit serial timings and custom SIO code you make a nonsense point. FJC (and others) have not claimed that the SIDE3 can run all disk images, from what I can see it hasn't set out with that objective. For someone who purposely excludes 400/800 users from running their productions you're speaking from very loose foundations. Someone wants to play an ATX then they have the option of one of the DjayBee/Farb or existing cracks and in the case of The Eidolon a cartridge image.
  9. Having experienced what can be done with an UNO Cart in terms of getting the STM32F4 micro to do stuff for you (Gameboy VRAM emulation / 3D world projection) I've still a lot of potential to exploit there but wonder if the SIDE3 can be extended in a similar way? AVG remains propriety AFAIK so I haven't gone down that path as I'm happy to run 8MB flash cart images on physical AtariMax carts and most else on the UNO.
  10. Having done a disassembly and looking at the heat-map produced within Altirra, I'd now conclude that a port probably wouldn't be possible without a lot of work, even if using the SRAM hybrid mode of the cart. heatmap.txt a8_wg_src.zip
  11. On the A8 it seems to use pretty much all of the 48K RAM but the screen display is based on multiple Antic-4 fonts based at $4000 and so code and data would certainly need relocating so not a straightforward port but I would think do-able.
  12. Different targets will use different methods to load an xex file, typically by placing a bootstrapping loader into memory, so it would sound like your game is potentially not initialising/clearing memory but assuming it is clear?
  13. .NET Core targets Windows/Linux/OS-X so saying don't use C# because of bloat is akin to telling @JAC! he shouldn't have used Eclipse and Java for WUDSN Most Dev's machines are not going to bat an eyelid at the overheads
  14. You'd use the Inform v6.34 compiler and build your sources that utilise their library and target z3 as the output. Then, as described elsewhere on the forum, splice that onto an existing A8 z-code interpreter and you should be good to go. I'm guessing it will still miss out on being able to use z4 and above commands so until we make the z4 & z5 capable interpreters for the A8 then we'll have to live with that.
  15. @Phlod I think this was covered earlier in the thread but as the game is accessing code & data from cartridge banks there is little/no gain from utilising the extended RAM. Effectively, in the original that is used as a disk cache along with some of the memory under the OS. As Wilheim forces the game to think there is just the 48K RAM, this permits the routines to handle the replacement ROM & virtual disk access code to use the RAM above 48K.
×
×
  • Create New...