Jump to content

Shawn Jefferson

Members
  • Posts

    2,047
  • Joined

  • Last visited

  • Days Won

    1

Posts posted by Shawn Jefferson

  1. Some guys in the Atari 8-bit form have released Z80 to 6502 de-re-compilers and many games have been ported. The problem is, as always, the custom hardware (if any), differences in display resolution and color, and the sound hardware.

     

    I briefly took a look at converting some Atari 8-bit games, and I think it's possible, but the screen size is a killer. You could probably do it easier if you scroll the screen in the horizontal, since a lot of games on the 8-bit use 160x192 resolution. I was specifically looking at Bruce Lee, I think with screen scrolling, you could even rip and res-use the graphics.

    • Like 2
  2.  

    Thanks SainT. As always you're a true gent in your support for us all here.

     

    I tried this rom, renamed it to "powerfac" to match Gadgets fantastic preview image naming convention. Same issue happens and it won't load.

    So I tried your "menu" file which checks the SD card. No problems there. Reformatted the SD card, re downloaded the menus etc. Still same problem. Weird!

    Anyways I copied the powerfactor rom across, this time without renaming it, voila it works! Ace!

    So I then rename it to "powerfac" and now it doesn't work. So I put it back to it's original name and it works again. Right I'm getting somewhere. So I change the preview name to match. The preview works but then I get the same problem as before.

     

    So basically if the preview screen loads for this game (if the rom and the preview name match) then the game itself won't load. Not a huge issue but I thought I'd better post my findings up just in case someone else encounters this issue.

     

    All the best peeps.

     

    Sort of sounds like Powerfactor may be relying on initialized state of some chunk of memory perhaps?

    • Like 1
  3. Hello Marius

     

    You might be wrong there. You might not like to pay import taxes. I don't either. (And I ordered two RT8"s too, so... :( ). But intensionally filling in a form incorrectly is considered to be fraude and therefor illegal. And asking people to do so is illegal too. You might not like the law, but that's the law.

     

    Sincerely

     

    Mathy

     

    Well, yes, exactly. I wasn't advocating one way or another, either. I was just stating those facts. Personally, I don't care much for the law regarding this and feel much the same way as ProWizard about customs charges, but I personally do not ask sellers in the US to write "gift" or zero value on anything they send me, mainly because I don't want them to feel obligated to do so, nor do I want to ask them to do something that may make them uncomfortable.

     

    Besides, the issue is with your own countries Custom regulations, take it up with your elected representatives! :)

     

    PS. I wasn't trying to call anyone out, or point fingers, just making a comment on the practice of writing "gift" on customs forms as a general topic.

     

    Here's the relevant USPS regulations:

    http://pe.usps.com/text/imm/immc1_009.htm

    http://codes.lp.findlaw.com/uscode/13/9/305

     

  4. That's crazy. I was going to post something about the irony of being able to purchase an AR-15 with almost no questions asked... but that may be straying into politics, but I guess this whole thread is about politics really. ;)

     

    PS. Asking companies and individuals to lie on their import/customs forms is very likely illegal... I wouldn't be surprised if some refuse to do so.

    • Like 1
  5. Get an 800XL. The 800 is an interesting piece of history, but there are too many drawbacks IMO with not having RAM under the OS, and not having the ability to have portb RAM upgrades-not to mention most hardware upgrades being produced today do not work in the 800. No sense limiting yourself in case you do get into the hobby in a larger way.

     

    With flashcarts (at least the Atarimax), if you want to put single-disk, or multi-disk games on them you'll need a 64k machine for instance.

  6. I believe I sent you the wardialers I had, which, IIRC, were Tuff'hacker and Lightning Hacker (could be getting that mixed up with the PC stuff we used... although I know that Fu*king Hacker was the best at that time for the PC.)

     

    I have tons of text files on phreaking and hacking, and some local phreaking/hacking BBS message logs somewhere amongst all my disks. Fun times! We did tons of war dialing here, and the calling card thing, as well as just all around getting into trouble. :) Unfortunately, our local telephone company was one of the more advanced ones. ESS was pretty much everywhere, and no one ever blew 2600 down the line on our telephone system, as it was urban legend that was begging to be arrested. Loopbacks? Nope, we didn't have them here, and we looked, a lot, since they seemed really cool.

    • Like 1
  7. Perhaps off topic, but has anyone made Atari file format conversion software to trick hardware into thinking an ATR is a cart? Or taking a game with multiple sides and disks and combining them into one file where in game, it auto-switches sides behind the scenes?

     

    You can't really "trick hardware into thinking an ATR is a cart", buy you can trick the system into thinking a cartridge is a disk, or multiple disks. That's what the AtariMax cartridge system does. First of all it patches the OS (on the XL/XE only) to make the sector read routines read a sector from the cartridge rather than the disk. This works great for single sided games (with a few caveats, see below).

     

    However, for multiple disk games you need to do some disassembly and patching of the game itself. This is how multiple disk games like Summer Games and Conan were done. Basically, the code is found that wants a disk swap, and patched to load from drive #2 (or #3, or #4, etc...) and the patched OS sector read code just reads a bit further up in the cartridge for those additional disks.

     

    Games that write to disk need some additional code and hacking. All the Ultima game conversions to AtariMax cartridge are an example of this. In those cases, the game code that writes sectors to disk needs to be taken out and code that writes to the flash in the cartridge inserted instead.

     

    Caveats: games that implement their own I/O routines instead of going through the OS I/O would need some additional hacking. Also games that try to use the RAM under the OS themselves will also cause some problems.

     

  8. Are you working with a gr.0 screen, and want to see what's at a specific location?

     

    I've used a pointer to screen RAM and just do something like:

     

    z = screen[(y*40)+x)];
    
    Of course, you then have to do your own conversion from screen code to ATASCII.

     

    When/if you start getting to the point that you want to optimize that multiply out of there, you can use lookup tables. That's pretty much what I've done with other projects, and also what I'm doing with Moria (although that is VBXE.)

     

    Some code from Moria (edited to just show the relevant parts), that does the opposite, but it's the same concept. Build a screen pointer, and then do the convert from ATASCII to screen code. VBXE has an additional attribute byte which is why I'm multiplying by 2.

    void __fastcall__ vbxe_cputcxy(unsigned char x, unsigned char y, char c, unsigned char atr) {
      vbxe_scrnptr = (unsigned char *) (vrow_lookup[y] + (x*2));
    
      if (c > 95)
        vbxe_scrnptr[0] = c;
      else if (c > 31)
        vbxe_scrnptr[0] = c - 32;
      else
        vbxe_scrnptr[0] = c + 64;
    
      vbxe_scrnptr[1] = atr;
    
      return;
    }
    
  9. But, I had to put the start address down in segments area like follows:

     

    (...)

     

    So then the program starts at $4000, and the VBI is at $6400 - and all is well.

     

    I guess that's acceptable (I'll change the actual values later)....but I'm confused as to why it's set up this way.

    I think what you are running into here is the fact that cc65 is not able to output an executable that has "holes" in the memory map by default. If you are expecting your VBI to be at $3400, and the rest of your program to start at $4000, then you need to take care of moving that yourself, or setup a special linker config to load everything into the right spot (by using "fill" and "align" keywords.)

     

    If you are going to copy the code, you want to make sure you have your "load" and "run" keywords set appropriately on your segement. Probably you don't want to do it this way however, since that will waste memory. If you are targeting a cartridge though, you'll need to do this for any code you want to relocate from cart to main memory and expect to have all the right addresses for jumps and branches.

     

    In Moria, I'm using the copy method to copy all my cartridge banking functions into lower memory (and under the OS.) The code has been compiled with a load address in a cartridge bank ($A000), and a run address in main memory.

     

    exerpts from the CFG file:

    memory:
        CART7C:   start = $A000, size = $2000, type = ro, fill = yes, fillval = $7C, file = %O;
        CART7D:   start = $A000, size = $2000, type = ro, fill = yes, fillval = $7D, file = %O;
        CART7E:   start = $A000, size = $2000, type = ro, fill = yes, fillval = $7E, file = %O;
    
        BANKRAM: start = $2B00, size = $1000, define = yes;						# start=$2B00 size=$1000
        OSRAM1:  start = $C000, size = $0FFF, define = yes;
        OSRAM2:  start = $D800, size = $27FA, define = yes;
    
    segments:
        BCODE:    load = CART7E, run = BANKRAM, type = rw, define = yes;	  # banking code in low RAM
        BCODE1:   load = CART7D, run = OSRAM1, type = rw, define = yes;	  # banking code under OS
        BCODE2:   load = CART7C, run = OSRAM2, type = rw, define = yes;	  # banking code under OS	
    
    void __fastcall__ copy_banking_code(void)
    {
      // copying banking code into low memory
      BANKCODE0BANK;
      memcpy(&_BCODE_RUN__, (unsigned char *) 0xA000, (unsigned int) &_BCODE_SIZE__);
    
      // copying banking code into memory under OS
      BANKCODE1BANK;
      memcpy(&_BCODE1_RUN__, (unsigned char *) 0xA000, (unsigned int) &_BCODE1_SIZE__);
      STARTUPBANK;
    
      BANKCODE2BANK;
      memcpy(&_BCODE2_RUN__, (unsigned char *) 0xA000, (unsigned int) &_BCODE2_SIZE__);
      STARTUPBANK;
    }
    
×
×
  • Create New...