Jump to content

RevEng

Members
  • Content Count

    6,849
  • Joined

  • Last visited

  • Days Won

    10

Posts posted by RevEng


  1. Yep, there's enough DMA time for that (you'd actually need multiple objects, due to the 32 byte limit) and you'll probably have gas in the tank for other objects on top. You can fill the screen with the more expensive modes, provided you're not doing it with an excessive number of objects.

     

    One thing that may help you to transfer experience between modes... The cheap modes (160A, 320A, 320D) are all equivalent in terms of DMA-used-for-%-screen-coverage, and the expensive modes (160B, 320B, 320C) are also equivalent for the same metric.

    • Like 3

  2. Very nice start! :thumbsup:

     

    On 1/21/2022 at 11:09 AM, saxmeister said:

    I probably will take your advice, @Geminitronic, and may not implement scrolling just yet. I'm also thinking of sound chip options for this since I could target TIA, POKEY, or even YM2151. The YM2151 would be closest to the arcade hardware (YM3526) but I'm worried about CPU cycles since the 7800 doesn't have a sound co-processor.

    We kinda worried about that prior to getting trackers running, but honestly the cycles involved isn't a major concern. In this demo video, the blue flashing represents the amount of CPU used by the tracker. (I turn the background blue when the tracker driver starts, and black after it's done).

     

     

    You can see it's a rather small proportion of a frame. The small bit of blue you do see flashes from frame to frame, since CPU isn't used by the driver between notes.

     

    IMO the bigger concern is the lack of YM availability for real carts or non-DF flash carts, which divides your potential audience greatly. There are some solutions for this which may be on the horizon - Rafal's passthru cart, or batari's Hokey with YM emulation - but none of those are guaranteed, nor are they imminent. Personally, I try to develop around tech that's available now or really soon, to avoid my code getting stuck on someone else's timetable. (...he said with some irony, after just showing off his tracker written for the XM)

    • Like 5

  3. 2 hours ago, Greg2600 said:

    Most of these folks are programming for the challenge/fun, it's not much of a financially beneficial hobby.  Furthermore, a good chunk are making use of copyrighted IP that thankfully they get away with in small quantities, but are technically pirating from the IP-holders.  Harrr Harrr Harr! 

    Not replying, just quoting for the sake of highlight. Homebrewers should take note that faithfully replicating decades-old IP will be justification for some players as to why you don't deserve as much (or any) recompense for your new work. No doubt your work will still be enjoyed, so keep slaving away boys. The price is right. Harr Harr Harr!

    • Like 1
    • Sad 2

  4. 1 hour ago, zzip said:

    There's no reason the rom couldn't come in a nice box either,  either as a download code or on a cheap low capacity thumb drive.   I think that might help some people feel better about their purchase rather than just downloading a rom and PDF.

    A couple days ago I was watching this RMC video on his "shop" being a MiSTer front-end, and had some similar ideas...

     

     

    ...one can easily imagine a similar implementation of software "cards". Each card could be encoded with a few redundant rom sources - QR codes, NFC, .etc. (and perhaps a unique license key one could use for manual download.)

     

    Waving/scanning the cards at your front end would launch the game locally if it's present, or otherwise download and launch the game, storing it locally for later access.

     

    For some people, these collectable cards would be a nice bridge between carts and roms. I don't doubt for others it would be annoying, but you don't need to use the interface if you don't like it.

     

    The trick is getting the functionality into your favourite emulators or front-ends. We have all of the talent needed at AA to get this done on all of the Atari platforms, but no idea about the drive. I suspect the proportion of people just wanting free roms vs those willing to pay, will make the development effort not worthwhile.

     

    • Like 2
    • Thanks 1

  5. One possible variation that anyone looking into implementing this should be aware of. The 7800 Rescue On Fractalus proto uses "mirror ram" (where each even page is mirrored to the next odd page) to draw graphics at half the vertical resolution. While a coarser resolution doesn't seem like a bonus feature, it does mean you have less screen to update, which speeds up your screen updates.

     

    a7800, concerto, and the 7800 MiSTer core all support the mirror ram header flag. Implementing mirror ram in any real-hardware cart with ram is trivial - just lift one memory chip leg and ground it.

     

    1 hour ago, Karl G said:

    It's not listed in the manual..

    Oops! I guess I have an update to make.

    • Like 3

  6. 14 hours ago, masteries said:

    Per year?   xD

     

    Really you are not aware of the humongous amount of work, a high quality 16 bit release requires.

    A very good game will require at least 2 years, working on it frequently.

    Honestly, that's not that far off the timeline for "very good" 8-bit releases.

     

    I don't doubt that higher quality assets take longer to produce, but it's not really relevant; asking how many homebrews come out in a year doesn't presume development effort in the slightest. Individual projects could take 4 years, and there could still be a large number of homebrews released each year. It just depends on the volume of homebrew activity.

     

     

    • Like 6

  7. You're welcome.

     

    Your layout file will differ - edit it and add the colour changing assembly to yours, instead of copying mine verbatim. The file contains whichever minikernels you've selected. For the code I posted, I just grabbed one of the sample files to use as an example.

    • Thanks 1

  8. 33 minutes ago, freshbrood said:

    Understood. But I would like it and I don't mind a little more complication. In the 48 image it's just a tiny couple lines of assmbly code added in, is this not feasible for the 96? For what I have in mind, even two halves of the entire background color flickering may not look terrible. 

    Sure, knock yourself out. Just add the background colour changes to titlescreen_layout.asm.

     

     ; To use a minikernel, just list it below. They'll be drawn on the screen in
     ; in the order they were listed.
     ;
     ; If a minikernel isn't listed, it won't be compiled into your program, and
     ; it won't use any rom space.
    
     MAC titlescreenlayout
    
        ; colour change before the 96 kernel.
    	lda #$22 
    	STA WSYNC
    	STA COLUBK
    
    	draw_96x2_1
        
        ; colour change after the 96 kernel.
    	LDA #0
    	STA WSYNC
    	STA COLUBK
    
    	draw_48x1_1
    	draw_48x1_2
    	draw_space 3
    	draw_gameselect
    	draw_score
     ENDM

     

    • Like 1
    • Thanks 1

  9. 4 hours ago, Karl G said:

    Now, as far as the background color goes, there's no reason why that option couldn't be added to the 96x2 kernel. I suspect it was omitted because it might end up looking weird. 

    Pretty much this. The more options added in, the more complicated using the thing is, and the more of a pain it the code is to support. In this case, it didn't seem worth the effort.

    • Like 1

  10. When I read "Atari" and "VCS" in Thomas' suggestion, I mentally added my own air quotes around both.

     

    In all seriousness, I think James should just follow his muse here. Homebrewers naturally move from technology to technology (or system to system) to keep things fresh and interesting. I wish no less for him.

     

    Even if 16-bit systems aren't your personal thing, there's a lot of inspiring stuff going on with other platforms, and it's worth peeking over the fence at least occasionally.

     

    • Like 4

  11. As far as flash carts, the best answer I have at this time is that some won't be compatible with bankset roms. It sounds like Concerto support may be split, depending on the generation. (I'm not sure if @batari has even had a chance to deeply look at it, as he has a lot of stuff on his plate) My guess is that CC2 won't be able to support it, and no idea about DF. 

     

    From a theoretical standpoint, bankset support depends on the halt line being available to the flashcart logic (PLD, FPGA, or whatever the case may be) and the cart logic needs to be able to delay bankset-switching for 2 cycles after HALT has gone low. This can be done with a simple PLD, as Fred has done, but you need enough available gates to pull it off. (side note: the bankset scheme would have been viable back in the day)

     

    A7800 emulation will support banksets. As part of the roll-out efforts, I'm going to reach out to authors on other emulation platforms (namely js7800 and MiSTer) so they have the info and test roms they need to implement support. I will also publicly release those test roms, and flesh out the bankset doc as any questions come in.

     

    This is the unfortunate side-effect of bringing new stuff to the platform, but it's unavoidable unless we allow the scene to stagnate. Gotta break a few eggs to cover new ground with tasty ground-omelettes.

     

    • Like 2
    • Thanks 1

  12. Good submission! :thumbsup:

     

    There's a problem with the solution as presented. The additional work inside the loop allows one paddle to make the resolution for the other paddle coarser, since the loop takes significantly longer when one of the the paddle position is being operated on. I'll need to find a solution without that issue, but highlighting the problem is helpful.

    • Like 1

  13. Hi All,

     

    I've written up a small doc at 7800.8bitdev.org on the new bankswitch scheme Fred (@batari) and I both devised for Petscii Robots, called "Banksets". (and by "both devised" I mean I asked if something like it could be done, and then Fred went off and did all of the hard work.)

     

    The Petscii Robots tile graphics use up more than 36k of rom, and all of that and more needs to be in address space for Maria to draw the game screen. It's not hyperbole to say the game wouldn't have been possible without banksets. I also think banksets will open the doors to other games with a higher level of graphic and code complexity.

     

    I still have a lot of ground work to do before opening the doors here... I've implemented banksets in A7800 emulation for the 2x128k rom size (with and without ram) but still need to implement some of the other sizes. 7800basic also needs a major update to support banksets, since intertwining code and graphics areas is at the 7800basic core, and that doesn't need to be done anymore with banksets. All of this will work will come soon, hopefully within the next month or two.

     

    Lastly, I need to give thanks to @TailChao, who I reached out to, hoping to see if he had insight into any sharp corners we might have ahead of us. (R+V also uses a halt-based bankswitch scheme) He was more than gracious and shared notes, diagrams, and had a bunch of useful advice. :thumbsup:

     

    Feel free to use this thread to ask questions that aren't covered at the wiki. I hope to flesh out the details there a bit, as I get input, and have time.

    • Like 13

  14. 26 minutes ago, ZylonBane said:

    Jesus, some people really don't think before they post.

    There's no reason to be so toxic. If you disagree, then state your reasons for disagreement, but there's no need to accuse the other person of idiocy. It's a cheap shot, and it says more about you than them.

    • Like 9

  15. [edit - just saw your last reply as I was in the process of editing+posting this, Bob. Figured I might as well go ahead with the post anyway, so the info is here in case you ever want to pick it up.]

     

    On 1/9/2022 at 3:10 PM, PacManPlus said:

    So, can anyone help reduce the CPU time of this routine please? It's the big CPU time hog to do for at most 42 objects on the planet (32 enemies, 10 humanoids)

    
     

    While it works, we've seen how much time it takes.  If I can reduce the CPU usage of this routine, we should be good. 🤞

     

    Here's a first-pass at a cycle-bummed version. Assuming I haven't goofed with any of my assumptions, it should save 26 cycles per object, which unfortunately only gets you down to ~75% of the original cycles. If you haven't already, you should also avoid the JSR+RTS pair per object, per Pat Brady's previous post.

     

    I've used some undocumented opcodes, but only ones that are known stable, and have been in use with the 7800 for a while. 

    ;    PUT ENEMY ON SCANNER
        LDA OBJVPOS,X                            ;TAKE VERTICAL POSITION
        ;LSR                                ;DIVIDE BY 2
        ASR #$FE ; *** AND+LSR, so we can force carry clear
        TAY                                ;MAP FROM VERTICAL POSITION ON SCREEN TO VERTICAL SCANNER POS
        ; *** -0 cycles / -0 cycles total
    
    
        ; *** with a bit of expansion we can combine both of these table lookups...
        ;LDA VPOS_TO_SCANNERV_TABLE,Y                    ;VERTICAL POSITION IN SCANNER
        ;TAY
        ;LDA SCNADDRESSL,Y                        ;INDEX INTO SCANNER RAM, VERTICALLY
        ;STA TEMP0
        ;LDA SCNADDRESSH,Y
        ;STA TEMP1
        ; *** somthing like this...
        LDA VPOS_TO_SCANNER_ADDRESSL,Y
        STA TEMP0
        LDA VPOS_TO_SCANNER_ADDRESSH,Y
        STA TEMP1
        ; *** -6 cycles / -6 cycles total
    
    
        ; *** do this once, prior to the radar enemy loop...
            ;   LDA WINDOWSTARTCOL
            ;   SEC
            ;   SBC #$36 ; $36 instead of $35, due to later carry=clear
            ;   STA WINDOWSTARTCOL_ADJUSTED
        ; *** so we can streamline this...
        ;LDA OBJHCOL,X                            ;GET HORISONTAL PLANET COLUMN OF ENEMY ($00-$7F)
        ;CLC                                ;WE NEED TO GET A STATIC COLUMN IN THE SCANNER BETWEEN THE PLANET AND THE ENEMY/HUMANOID
        ;ADC #$35                            ;I FEEL LIKE THIS SHOULD BE #$40, BUT $35 IS WHAT GIVES AN ACCURATE NUMBER
        ;SEC
        ;SBC WINDOWSTARTCOL                        ;SUBTRACT CURRENT WINDOW COLUMN TO GET COLUMN FOR SCANNER
        ; *** to this...
        LDA OBJHCOL,X                            ;GET HORISONTAL PLANET COLUMN OF ENEMY ($00-$7F)
        SBC WINDOWSTARTCOL_ADJUSTED 
        ; *** -6 cycles / -12 cycles total
    
        ;LSR                                ;DIVIDE BY 2 TO GET THE NUMBER OF X POSITIONS IN THE SCANNER
        ;AND #$3F                            ;FOR WRAPAROUND
        ASR #$7F ; *** AND+LSR
        ; *** -2 cycles / -14 cycles total
    
        ;STA TEMP5                            ;64 PIXELS IN SCANNER ($00-$3F)
        TAY ; *** save
        LSR                                ;WE NOW DIVIDE BY 4 TO GET THE BYTE INDEX INTO THE SCANNER RAM
        LSR                                ;THERE ARE 16 BYTES PER ROW OF SCANNER RAM
        STA TEMP4                            ;HORIZONTAL POSITION BYTE IN SCANNER
        ;LDA TEMP5
        TYA ; *** restore
        ; *** -2 cycles / -16 cycles total
    
    
        AND #$03                            ;GET POSITION WITHIN BYTE IN SCANNER
        ; *** TEMP5 is about to be wiped after this, so just keep the value in A
        ; STA TEMP5 
        ;LDA OBJTYPE,X                            ;GET ENEMY TYPE
        ;ASL                                ;SHIFT OVER TO CREATE AN INDEX 
        ;ASL                                ; WITHIN THE TABLE OF OBJECT TYPE / BYTE POSITION
        ;ORA TEMP5                            ;'OR' WITH DOUBLE-BIT POSITION
        ORA OBJTYPEX4,X    ; *** OBJTYPE*4 can be pre-calculated/statically-assigned
        TAY                                ;Y INDEX
        ; *** -10 cycles / -26 cycles total
    
    
        LDA NMYSCNLINE1,Y                        ;THIS GETS THE ENEMY TYPE AND POSITION WITHIN THE SCANNER BYTE
        STA TEMP5
        LDY TEMP4                            ;HORIZONTAL BYTE POSITION IN SCANNER RAM
        LDA (TEMP0),Y                            ;GET WHAT IS ALREADY THERE
        ORA TEMP5                            ;'OR' VALUE WITH NEW OBJECT
        STA (TEMP0),Y                            ;STORE TOP LINE
        INC TEMP1                            ;NEXT PAGE DOWN
        LDA (TEMP0),Y                            ;GET WHAT WAS ALREADY THERE
        ORA TEMP5                            ;'OR' VALUES WITH NEW OBJECT
        STA (TEMP0),Y

     

    I think to do much better you'll need something more algorithmic, like caching
     

    • Like 1

  16. Thanks! (I have watched it before, along with all of his other Petscii Robot videos) He says he feels one button shooting is clumsy, but he doesn't say that run-and-gun is absolutely required. I don't agree it's clumsy (any more than it is in Berzerk), but be that as it may, we have 2 optional control schemes that allow for run-and-gun, with a possible 3rd one in the works.

    • Like 7

  17. While squashing the original graphics resembles the arcade the most, it has the disadvantage of not being legible if you're not very familiar with the arcade game. I think if the game was released on the 2600 BITD, it would have gone with a more vertical pow.

     

    pow.png.34aad02e53ddc849c751d322430d5681.png

     

    (8x10)

    • Like 5

  18. When genesis gamers are finally granted their wish for a 7800 proline->genesis controller adapter, that will allow your proline to genesis to proline chain to work. ;) 

    • Haha 4
×
×
  • Create New...