[Step 4 - 2 Line Kernel]

@Elijah - check the comment just after PrepScoreForDisplay:

 

PrepScoreForDisplay:
    ; for testing purposes, set Score to Humanoid Y and Timer to Box Y
        lda ObjectY
        sta Score
        lda ObjectY+1
        sta Timer
        

 

[step 14 - add animation]

I don't know if there's a simple way or not.

 

MiniDig has a disassembly for Adventure, I suggest taking a look at it to see how it processes register CXBLPF, which is a collision between the ball and playfield.

[Harp Twins and Volfgang Twins]

13 hours ago, thanatos said:

They have played at MGC the past 2 years, music is awesome and they also are super nice people.  Too bad their tour doesn't include it this year!

 

I'd noticed them at the Houston Arcade Expo before, last year was the first time I watched them. During the performance the Harp Twins mentioned they were from northern Illinois, so MGC's not far from where they live.

 

Looks like a scheduling conflict, they'll be in Texas the weekend of MGC at the San Antonio Highland Games & Celtic Music Festival.

 

 

 

 

Helotes is on the northwest side of the San Antonio metro, been there many times as it's on the way to Bandera where we have family.

[Warlords fix for XRGB-mini]

You're welcome @mario64!

 

I don't recall on Defender.  I searched my hard drive and found those files in ~Projects/Atari/Helping Others/ScottWhite/

 

The other directories I have under Helping Others are mostly AtariAge user names, so I checked AtariAge for a Defender related post by user ScottWhite, but that username does not exist. Usernames can be changed on AtariAge, so it's possible Scott's now using a different username.

 

Anyway I've added the source to the blog entry.  It was created by Stella and my changes are:

 

 

; set to 1 for VSYNC fix, set to 0 for original
VSYNCFIX    = 1

VBLANKFIX  = 1

...

;---------------------------------------
 if VSYNCFIX = 1
    lda #$36
    ldy #$00
    ldx #$7f
    sta WSYNC
    sty VSYNC
    sta TIM64T
    sty PF0
;    stx VBLANK
 else
    sta     WSYNC                   ;3   =   3
;---------------------------------------
    lda     #$36                    ;2        
    sta     TIM64T                  ;4        
    ldy     #$00                    ;2        
    sty     PF0                     ;3        
    sty     VSYNC                   ;3        
    ldx     #$7f                    ;2        
    stx     VBLANK                  ;3
 endif

...

 if VBLANKFIX = 1
    lda     #$26                    ;2        
    sta     TIM64T                  ;4
;    sta WSYNC
    sta VBLANK
 else
    lda     #$26                    ;2        
    sta     TIM64T                  ;4
 endif    

 

[Mac Studio]

Looking at the statistics I realized that using the average speed in fps would be a good way to review the results:

 

 

Being able to run 4 concurrent conversions improved throughput by on the Mac Pro by 45% and 126% on the Mac Studio.

 

I was surprised to see that the size of the resulting file was not consistent as every test run was done using episode 1 of season 7.  There must be some randomization in the compression process.

[Mac Studio]

4 concurrent took 2:39:57 on the Pro

 

 

 

 

 

 

CPU was pegged

 

[Mac Studio]

3 concurrent took 2:02:55 on the Pro

 

 

 

 

CPU activity is pegged

 

 

Test with 4 underway.

[Mac Studio]

For the Pro it was initially 58:27 to convert 1 video.   Briefly converted 1 again to get the CPU activity:

 

 

So there is some unused capacity.  The Pro has a 6 core CPU with hyperthreading.  

 

Cancelled the 1, then fired off 2 concurrent conversions which took 1:27:51

 

 

 

CPU activity:

 

Test with 3 underway.

[Mac Studio]

Runtime increased to 28:00 for 4 at once.

 

 

 

 

 

 

All but 1 core was pegged:

 

 

So I can now convert 8+ episodes in the time I used to do 1.  

 

Of course I never tried that setting on the Pro, so I currently have a test with 2 running on it right now. About 17 minutes remain.

[Mac Studio]

Runtime increased to 22:04, but 3 were converted.

 

 

 

 

Cores were busier.

 

 

Test going with 4.

 

 

[Mac Studio]

Runtime increased to 17:51 but during that time 2 videos were converted, not 1.

 

 

 

Cores were noticeably busier.

 

 

Test going with it set to 3.

 

[Mac Studio]

Just a few seconds faster this morning:

 

 

I did notice that not all cores are active:

 

 

So wondered if I could make Handbrake convert multiple videos at once. Found this setting, which can be increased to 2, 3, or 4:

 

 

Have a test running with it set to 2.

 

[Step 1 - Generate a Stable Display]

On 7/21/2023 at 11:09 PM, KainXavier said:

Thank you for the tutorials!

 

You're welcome!

 

On 7/21/2023 at 11:09 PM, KainXavier said:

You made a comment in your code about how the last six bytes / three words were reserved for the 6507 interrupt vectors, but what exactly are those?

 

The documentation to look at for those 6 bytes is for the 6507 processor.  The 6507 is a member of the 6500 family of CPUs, so you can find that at 6502.org.

1. Click on Documents in the top-right corner
2. Click on Books
3. Download mcs6500_family_hardware_manual.pd
4. Download mcs6500_family_programming_manual.pdf

The documentation is quite detailed, so I'll try to summarize it.

 

If an external event occurs the CPU needs to be informed about it so the event can be handled. An example would be if you were calling a BBS with a modem.  The chip that talks to the modem, known as a UART, had limited resources so after it receives a byte of data it must hand it over to the CPU right away before the next byte comes in. It does this by flagging an interrupt to the CPU. Some chips in the system can have a timer, such as RIOT in the 2600.  When the timer runs out an interrupt will be flagged so the CPU knows about it.

 

FFFA-FFFB = NMI vector

 

These 2 bytes point to the routine that handles a Non-Maskable Interrupt. The CPU cannot ignore an NMI, you'd use this for the UART because if the CPU ignored the byte of data it could be lost by being overwritten by the next byte that's received. When an NMI occurs your program is temporarily halted while the CPU runs the NMI routine.

 

FFFC-FFFD = RESET vector

 

These 2 bytes point to the routine that handles a Reset. This occurs when the system is initially powered on because the state of the hardware will be unknown, such as the Accumulator in the CPU will contain a random value between 0-255. The reset routine is used to initialize everything to a known state. The reset can also be triggered on systems that have a dedicated reset button^*

 

FFFE-FFFF = IRQ vector

 

These 2 bytes point to the routine that handles Interrupt ReQuest. The CPU can ignore an IRQ, you'd use this for things like the timer as it's not critical that the timer is handled right away because the CPU can check if the timer ran out at any time.  When an IRQ occurs your program is temporarily halted while the CPU runs the IRQ routine.  This can also be triggered by your program via a BRK instruction.

 

 

The 6507 is a 6502 that's put into a reduced package, it only has 28 pins instead of 40. This reduces the cost of the CPU. Some of the missing pins include those needed to signal the NMI and the IRQ, so those cannot be triggered on the 2600 by external events.  The IRQ can still be triggered by a BRK instruction as that happens inside the CPU. I had that occur on accident in Medieval Mayhem.  BRK can be used as a space saving way to call subroutines, though this is an advanced technique. @Thomas Jentzsch explained this in the old Stella mailing list.

 

 

 

^* the red button on my Mega-Cart is an example of a reset button.  After playing a game I can press that button to reset my VIC20. This lets me select a different game to play without having to power cycle my VIC-20.

 

 

 

[Announcing Draconian]

 

Draconian final ROM is in this blog post.

 

By this:

 

22 hours ago, johannesmutlu said:

wooden stylish atari handheld

 

I assume you mean the Flashback Portable? Draconian uses an ARM in the cartridge as a coprocessor, I don't think the Flashback supports that.

 

 

The Harmony Cart has an ARM processor in it and supports running Draconian on a real Atari.  To see what version of the firmware you have hit FIRE on the line at the top with [.] 

 

that'll take you to a credits screen which displays the firmware version at the top.  Mine is running v1.06:

 

 

You need to have at least v1.05 for Draconian to work.  If your Harmony is lower then go here for the latest firmware and instructions.

[Crash Fix: Nintendo 3DS XL - Black Screens with only Blue LED lit]

I recently dusted off my 3DS as well

 

 

 

 

 

 

 

Info in this topic if you're interested in installing emulators on your 3DS. This reply is for installing an FTP server on the 3DS - I don't have to remove the SD card anymore.

 

 

 

 

[As long as it looks good on a shelf]

On 9/4/2022 at 3:39 AM, Nathan Strum said:

The time is apparently lost forever (which is annoying, since blogs are effectively snapshots of time, and I happen to like to know when I posted something originally).

When I was adding categories I had some blog entries, that were originally posted on the same day, change order because of the time issue.  I took a break from doing that as I went out of town for a couple weeks (foreshadowing for the Tesla Club). 

 

[PS3 as ATSC PVR?]

On 1/7/2010 at 3:33 PM, EricBall said:

Although ATSC "supports" H.264, no current HDTV does. So it's more of a future thing.

 

The future is now:

 

 

[step 11 - add the ball object]

2 hours ago, JohnGri said:

Can you elaborate on the .byte $24 trick that causes the inx to be skipped?

 

I think I explained this trick in a comment in another part of the tutorial <searching>

 

Looks like I explained it for .byte $2C which skips over 2 bytes. The concept is the same for .byte $24, except it just skips over 1 byte.

 

• .byte $2C = BIT absolute address (a 16 bit address, which is 2 bytes)
• .byte $24 = BIT zero page (an 8 bit address, which is 1 byte)

[Collect Tutorial Index]

3 hours ago, JohnGri said:

That is amazing that you wrote this when you were 15

 

Just to be clear, I didn't write the Collect tutorial when I was 15. I was writing machine language subroutines on my VIC 20, such as a screen scrolling routine for a Super Cobra type game that was written in BASIC. The scroller routine was in machine language because it was too slow in BASIC.

[Draconian final ROM]

On 8/28/2020 at 4:22 PM, Robson Zandoná said:

Does it work on the Stella emulator?
Because mine doesn't open.

 

Sorry, I missed your question until just now.

 

Yes it does, though you may need to update to a newer version of Stella.

 

Draconian uses a new bank switching scheme called CDF, which was first added in version 5.0 in 2017. Stella's CDF support has seen a seen a number of updates since then, most recently for the latest revision of CDF called CDFJ+, which supports games up to 512K in size.

 

[I give up for good.]

Bummer, it's always been interesting to see what games you've come up with.

 

Perhaps part of the problem is trying to code for so many consoles?  The phrase "jack of all trades, master of none" comes to mind.  Maybe just pick 1 or 2 consoles to create games for?

[MenuMaker 0.3]

Second beta.  Still need confirmation that this works for a newer VecMulti.

 

MenuMaker_04beta2.app.zip

[MenuMaker 0.3]

1 hour ago, Vectrexer said:

I like version option nomenclature you have listed. 

 

Suggest also checking with @Richard H. to see if another differences exist for ancient VecMulti versions.  Might as well try to cover them if there are more.

 

Thanks!  Possible other versions of VecMulti was also part of the idea behind using radio buttons.

 

16 minutes ago, NeonPeon said:

Wow, it's so simple. Apologies for the mixup. I take it you don't need me to send the .rtf file then? I have no problem doing so if you do need it; just sounds like you've got it figured out already is all. ?

 

No worries, by having the EXE I was able to confirm the ##.men ROM files followed the same convention in both versions of the VecMulti.

[MenuMaker 0.3]

4 hours ago, SpiceWare said:

The older version has ^@9 for the same number of ROMs. 9 = $39, so its ROM count is $0039 or 57.  Actual file count is still 58, so the two VecMulti menu routines differ their count by 1.

 

Turned out the last game in my Games directory was not showing up in the VecMulti menu, so this looks like it was an off-by-one bug in my port.  I don't know if that was a bug my original port, or just the recent re-port. I've fixed it and added the ability the quit the program using COMMAND-Q.

 

I partially figured out the issue with com.company.MenuMaker.plist - in MenuMaker.app/Contents/Info.plist I found this:

  <key>CFBundleIdentifier</key>
  <string>com.company.MenuMaker</string>

 

and if I change it to this

  <key>CFBundleIdentifier</key>
  <string>com.spiceware.MenuMaker</string>

 

the Preferences now get saved in com.spiceware.MenuMaker.plist

 

don't know where the initial company is coming from, but that works for now.

 

I'm thinking about changing the checkbox to 2 radio buttons:

• original VecMulti
• 2019+ VecMulti

I think that'll make usage a bit clearer.  Any feedback on this?

 

Also has anybody confirmed it works correctly for the 2019 VecMulti?

[MenuMaker 0.3]

@NeonPeon, @Nathan Strum here's a 0.4 beta version that hopefully correctly creates the menu for the new VecMulti cart.

 

MenuMaker_04beta.app.zip

 

By default it'll create a menu for the original VecMulti.  Check the new New VecMulti (2019) check box to create a menu for the new version.

 

 

I figured out how to get that checkbox saved in ~user/Library/Preferences/ so it'll remember it between runs, though for some reason the plist file it's using is com.company.MenuMaker.plist. I'm trying to find where "company" is coming from.