Jump to content

Wrathchild

Members
  • Content Count

    2,924
  • Joined

  • Last visited

Posts posted by Wrathchild


  1. Here you go...

     

    The 'characters.c' file was used to generate the A8 data statements for inclusion within an assembler file. You could rewrite it to output the bytes directly to another file if you like and use 'incbin', or some equivalent command, in your project to include the data.

     

    Note that I included the raw data within the original C file, I think this was because the hex editor I was using let me copy to the clipboard as data statements. :idea: This could be better achieved by opening a file, moving to a specific offset and then reading a given length of data (plus closing the file). These details could be passed as arguments on the command line.

     

    The 'chars.s' assembler file gives an example of this kind of output being used. In this case, letting the user see the graphics by selecting one of 4 screens using the joystick.

     

    Note: this was built using the CC65 tools (CA65 to assemble and LD65 to link) and the linker was passed the 'generic.cfg' file to override the default Atari memory map.

     

    If anyone fancies animating these little guys it shouldn't be too tricky.

    The images in the original ROM provided 4 states per character. These are: down (1), up (1), left (1) and left(2). As the animation of walking in a direction only has two states, the missing images achieved in the NES via hardware flipping. So: down (2) = down (1) flipped horizontally, up (2) = up (1) flipped horizontally and right (1) and right (2) are flips of left (1&2). To perform the flipping on the A8, use the 256 byte lookup table provided in 'flip_table.s'.

     

    Enjoy,

    Mark

    nes2a8.zip


  2. We are working on it. But it might take a year or more to finish a driver for USB Stroage.
    Is a problem here that you effectively have to write you're own FAT handler in order to manage the filesystem? Or do these devices sometimes contain their own micros that do that work for you?

     

    Similarly, some of the networking devices such as http://www.zonetusa.com/DispProduct.asp?ProductID=130 could be used, but again, how much work is the device going to do for you?

     

    Studying linux device driver code could help in some instances, as trying to get help from the manufacturers isn't always fruitful. :(

     

    Regards,

    Mark


  3. I was doing something like this with Combat, however

    I would say that a direct port of say a games kernel

    (primarily the screen drawing part) is not always feasible

    and you better off mapping the ideas of a game to the

    A8 specific ways of doing something.

     

    Examples of problems are:

    2600 supports playfield reflection, this can be done

    in the vertical though custom Dlists, but in the

    horizontal this means you need to write this in software

    to compensate. Not always used though in 2600 games.

    2600 sprites can be flipped and also 'cloned' (e.g. the planes

    in combat) by hardware. Although the expansion of a sprite

    is similar, this means you need to use some of the other A8

    players and missiles to provide this... more overhead.

    Therefore you end up doing the sprite graphic prepartion work

    when screen drawing is outside of the display areas (e.g. VBI)

    rather than on-the-fly as a 2600 game typically does.

    2600 sound - slightly different random generators used for

    the noise, but doesn't look too tricky to translate this.


  4. Certainly does :)

    Dave Murray is one of the main reasons why I still strive

    to play the guitar (after about 20 years now)!

     

    As for tutorials, not really, but I help out where I can ;)

     

    From what I can remember of my early experiences

    of learning 6502, the main thing was to keep experimenting

    and work through the crashes! Set yourself small targets

    and then build from there.

     

    Later I found that disassembling or working out how a

    game does something that you like helped see how other

    programmers did things diferently, i.e. their 'style'.

    An example of that was 'Elite', which showed me for the

    first time the use of the 'BIT' command to effectively ignore

    a the next two bytes of code, here's an example:

     

    loc_0_9019:

    CMP #$3B

    BEQ loc_0_902B

    CMP #$3A

    BEQ loc_0_9028

    CMP #$3D

    BNE loc_0_9030

    LDX #3

    .BYTE $2C

    loc_0_9028:

    LDX #2

    .BYTE $2C

    loc_0_902B:

    LDX #1

    JMP ChangeView

     

    Good luck in your projects!


  5. also I don't understand,

     

    for 'of' read 'to make'

     

    could you clarify for a NOOB?

     

    No problem,

     

    "effectively an AND of the lower half of the address"

     

    should have read:

     

    "effectively an AND to make the lower half of the address"

     

    Say I want to set the Display List to point to (hex) address $7F20

     

    The AND makes the lower half of the address by masking only the

    lower 8 bits of this address, i.e. $20

     

    as 256 is 2^8, dividing this address by 256 gives us the value $7F

     

    So we can poke address $230 with the (lo) value $20

    and address $231 with the (hi) value $7F, e.g.

     

    SDLSTL=$230

    SDLSTH=$231

    my_dlist = $7F20

     

    LDA #my_dlist*255

    LDX #my_dlist/256

    STA SDLSTL

    STX SDLSTH

     

    Alternatively many assemblers let you use '<' for lo and '>' for hi:

     

    LDA #

    LDX #>my_dlist

    STA SDLSTL

    STX SDLSTH

     

    Hope that helps :wink:


  6. ... but requests to help with the disassembly and porting of the games logic code from the C64 (I assume) didn't gain any significant response
    I did disassembly the whole game for them using IDAPro and offered to help but not much came from that :sad:

     

    From my experiences (Elite/Bard's Tale/World Class Leaderboard and others) there are some games that lend themselves nicely to porting and others that don't. The A8 can manage a similar bitmapped type screen layout (i.e. Antic 4) but at a slightly higher mem usage and with not such a great control over the colour palette. A game with heavy sprite usage typically needs that portion completely rewritten and again you often lose out due to colour (having to use software rather than hardware sprites) or resolution (e.g. Mission Impossible bloke)

     

    If you want a recommendation from me... go for Rock'n'Bolt.

    Simple graphics and nice gameplay, topped with a basic tune.

     

    Regards,

    Mark


  7. There was another type-in but I can't recall its name?

    I think you had a Shamus like guy who had to get keys to unlock gold

    (or doors to get to the gold) on a fixed screen map. The striking thing  

    was the colorful graphics of which it used an animated charset to rotate

    the walls/flash jewels etc.

     

    I've recalled that the game may have been called 'Swag'

    but I'm not 100% certain... it didn't show up on XL-Search.

    Does it ring any bells with somebody?

     

    Thanks,

    Mark


  8. We can improve that routine by getting rid of the Y register
    Eh? You've changed its functionlity?

     

    That routine was a bit pair swapper, yours is for single bits.

    The Combat code was:

     

    CreateFlipTable:
    
    LDX     #0
    
    @1:
    
    TXA     
    
    LDY     #7
    
    @2:
    
    ASL     A
    
    ROR     $80
    
    DEY     
    
    BPL     @2
    
    LDA     $80
    
    STA     $600,X
    
    INX     
    
    BNE     @1
    
    RTS

    So yes, you do save on that ;)

     

    I did think to change the bit pair version to not use the zero page temp register.

     

    CreateFlipTable: 
    
      LDX     #1 
    
    @1:
    
      TXA      
    
      LDY     #3 
    
    @2:
    
      ASL     A 
    
      PHP      
    
      ASL     A 
    
      ROR     FlipTable 
    
      PLP      
    
      ROR     FlipTable 
    
      DEY      
    
      BPL     @2 
    
      LDA     FlipTable 
    
      STA     FlipTable,X 
    
      INX      
    
      BNE     @1
    
      STX     FlipTable
    
      RTS


  9. Many appologies to all, I did just send the demo and not the

    code because I thought I should finish it first before doing so :D

     

    Here's the Kernel based code anyway... I had decided that

    this wasn't going to quite work because of the extra cycles

    wasted to A8 things, so I have recoded it here with a more

    VBI based approach. As happens, everything is now broken

    and work stopped as my daytime and evening work has been

    taking up too much of my time. :(

     

    Still - my MyIDE board is now built and so next Monday it gets

    fitted and I should be trying it out next week. How long does

    a 12gig drive take to format :ponder: :roll: :)

     

    Regards,

    Mark

     

    BTW, there was a similar routine to create a flip table in the

    Barbarian demo I did. You'd use this for 4 colour bit patterns.

     

    CreateFlipTable:
    
    LDX     #0
    
    @1:	TXA     
    
    LDY     #3
    
    @2:	ASL     A
    
    PHP     
    
    ASL     A
    
    ROR     byte_0_A8
    
    PLP     
    
    ROR     byte_0_A8
    
    DEY     
    
    BPL     @2
    
    LDA     byte_0_A8
    
    STA     FlipTable,X
    
    INX     
    
    BNE     @1
    
    RTS     

    combat.zip

×
×
  • Create New...