Jump to content

Omegamatrix

+AtariAge Subscriber
  • Content Count

    6,690
  • Joined

  • Last visited

  • Days Won

    2

Posts posted by Omegamatrix


  1. I played this a lot as a kid on the Colecovision, and gave the 2600 version a go. At first it seemed very stripped down, but after playing it for a while I started to enjoy it a more. What do you all think of 2600 Venture?


  2. You shouldn't strobe HMCLR immediately after HMOVE. You should leave the HMxx and RESxx registers alone after HMOVE for a certain amount of cycles. I forget how many exactly but it was  ~ 24 or so. 

     

    Now there are times that you don't do that for trickery, but for normal positioning you leave them alone.

     

    Also, if you are using a 48 pixel display routine then you also have to adjust when you update GRP0 and GRP1 inside of it.

    • Like 1

  3. I've reached 36 characters, but if you want simple re-usable on stock hardware then I would stick with Eshu's 32 character routine.

     

    Interestingly enough ZackAttack worked out a full 160 pixel bitmap using bus stuffing. I proved it out with a non-bus stuffing test rom that turned a single pixel off at a time using his routine.

     

    IMHO Zack's 160 pixel bitmap was the #1 technical achievement for the 2600 in 2018.


  4. I think the last solution might be optimal. I would love to see some other ideas though.

     

    One thing I should mention is that I don't trust ASR anymore. I had problems with it before on an Jr. Otherwise it would be a quick way to save 2 cycles and 1 byte to just ASR #$F0. It is actually would be a very useful opcode if it was stable.

     

    Others have also noted the same problems that I had with ASR.


  5. Went with 2 temps instead of a single temp and and an index register. This version saves 1 byte and 3 cycles over the BCDtoBin4 routine in post #5 above.

     

    ; BCD value $0 - $99 is in A. Returns binary number 0-99 in A
    BCDtoBin6:
        sta Temp
        and #$F0
        lsr
        sta Temp2
        lsr
        lsr
        adc Temp
        sec
        sbc Temp2
        rts

     

    • Like 3

  6. I'll post a table version. It is 5 cycles faster than the last version, but uses 6 bytes more. It is only useful if you need the speed.

     

    ; BCD value $0 - $99 is in A. Returns binary number 0-99 in A
    BCDtoBin5:
        tax
        lsr
        lsr
        lsr
        lsr
        tay
        txa
        sec
        sbc SixTable,Y
        rts
        
    SixTable:
        .byte 6*0
        .byte 6*1
        .byte 6*2
        .byte 6*3
        .byte 6*4
        .byte 6*5
        .byte 6*6
        .byte 6*7
        .byte 6*8
        .byte 6*9

     

    • Like 1

  7. I had a thought, and made a new routine. It is 2 cycles faster, and 2 bytes less than the previous.

     

        tax
        and #$F0
        lsr
        lsr
        sta Temp
        lsr
        adc Temp
        sta Temp
        txa
        sec
        sbc Temp
        rts

    In one byte BCD number the high nibble is a base 10 value stored as a base 16. To convert subtract a value of 6 * (high nibble >> 4) from the original value.


  8. On 7/26/2019 at 12:35 PM, alex_79 said:

    Just like the "Fathom" rom posted in the old thread, the banks are in reverse order compared to the original F8 versions. Anyway, with these new dumps we have confirmation that they are actually arranged in that way in the eprom (as they were dumped directly from the chip).

    So $2A0 is the hotspot for the lower 4k of the rom, while $2c0 is the one for the upper one.

    The "Mickey"(sorcerer's apprentice) rom in the old post has the banks in the same order as the F8 version, and the hotspots are swapped. This might mean that it was dumped incorrectly (by setting the hotspots in the wrong order to dump each bank) or that both variations of this scheme exist (which is likely: it's just  a matter of swapping two address lines to invert the behaviour).

     

     

    Nice! So it is a new bankswitching then.

     

    If I read your post correctly then the roms the original poster had for Fathon was correct, but Mickey needs the banks reversed?


  9. On 8/5/2019 at 9:41 AM, RevEng said:

    Complaining that various downloaded releases of bB have delivered various updated releases of dasm as being evidence of "a bad thing"... I'm really at a bit of a loss for words on that. No good deed goes unpunished, I guess? In retrospect it was a mistake to point to one of the recent bundles in my response to this thread, since it's another non-official source of dasm that you guys are taking issue with.

     

    I provide all source code with my stuff. My dasm versioning includes the original dillon dasm tree it was based on, so changes are trivial to find. (which is why the base version doesn't change, Dionoid, but the date part of the version does) If anybody finds my bundled dasm objectionable, harmful, or bad, they're more than welcome to take on the dillon source and merge in fixes to reestablish the authority of that tree. I have very little hobby time these days, and I already have a large share of active projects encouraging programming on 6502-based platforms.

     

     

    I appreciate your efforts! If you hadn't made the fixes then probably nobody would have...

    • Like 1
    • Thanks 1

  10. Neat!

     

    There might be a few different routines out there but I don't know of any.

     

    You could also do this to compress your routine further:

     

    ; BCD value $0 - $99 is in A. Returns binary number 0-99 in A
    BCDtoBin2:
        sta Temp
        and #$0F
        tax
        eor Temp
        lsr
        sta Temp
        lsr
        lsr
        adc Temp
        stx Temp
        adc Temp
        rts

     

    • Thanks 1

  11. I tried installing a few different types of 32 bit linux using VirtualBox about a month ago but couldn't get anything to work. From what I read it might be a problem with my graphic drivers. I tried several things to make it work, but none were sucessful.

     

    I'm interested in if you can use the 64 bit builds now and not have problems with compiling code for the ARM. If that will work I will try a newer version of linux, and worst case buy a different PC (which I need).


  12. I'm not much of a programmer so I don't know if this is even possible, but one of the things that annoys me about older 2600 games is that you need the manual handy so you can check the Game Selection Matrix to see what each variation does. Towards the end of the 2600's life they started adding real menus to the title screen of each game, making selecting various options a lot easier. My question is, is it possible to graft such a title screen and menu onto older games to help select options? I know you can't put something like that into the games original kernel since there's not going to be any room, but could you make the menu a separate program that once all the options are selected starts the original game's kernel but automatically advances to the correct game variation?

     

    For example, take something like Breakout. There are three options: Steerable, Catch, and Invisible. Could you make a menu that said:

     

    Game Type: Breakout/Timed/Breakthru

    Steerable: Yes/No

    Catch: Yes/No

    Invisible: Yes/No

     

    Then say the person selected Game Type: Timed, Steerable: Yes, Catch: No, Invisible: No. Could you then start Breakout but automatically advance to variation number 6 which is the Timed Breakout game with a Steerable ball? This would make many of the older games much more playable for me since I never have the manual around when I need it. Just and idea, and like I said I have no idea how feasible something like this is.

    This is a superb idea to breathe new life into these games. Truthfully, I never have a manual around, and I usually just play the default version.

     

    Converting games that have a lot of variations is a huge improvement. Maybe I will look into Video Olympics because there are 50 variations. I'm pretty sure I have not tried a lot of them.

     

    Paddle games are more involved to make a menu screen, but certainly workable. Standard joystick games though would be easier to bang out.


  13. i was wondering if the technovison stone age in this thread

     

    http://atariage.com/forums/topic/67442-stone-age-cce/page-2

     

    had ever been conevred to left joystick port- it is right, like original wizzard of wor- thx!

    Yes it has! Actually a few of the roms in the thread you posted has this conversion.

     

    But the rom you probably want is in the link below. It has the most work done to it.

     

    http://atariage.com/forums/topic/67442-stone-age-cce/?p=2909578


  14. That's exactly what CloneSpy does.

    I was talking about doing disassemblies to see the exact differences, and grouping the roms that way.

     

    From the Missile Command output for Clonespy you posted can you say which hacks were built from the no-initial rom, and which were built from the initial rom? It's easy to determine that from a disassembly that can compile into each version. Ultimately though I'm trying to make a simple relationship diagram like this:

     

    post-7074-0-91393000-1555269066_thumb.jpg

     

    I did that for Challege about 11 years ago.

×
×
  • Create New...