[resizable ball]

I should have pointed this out before you rewrote all of the kernels yesterday!

 

One final suggestion is to move the HMP1/ENAM1 writes to the end to free up the Y register and 3 more cycles:

 

lda #<DS_HMP1_ENAM1     ; 2 71
sta HMP1                ; 3 74
sta HMOVE               ; 3 1
sta ENAM1               ; 3 4
stx ENAM0               ; 3 7
lda #<DS_GRP1           ; 2 9
sta GRP1                ; 3 12
jmp (Next)              ; 5 17

Chris

[resizable ball]

I would be tempted to inline the R76 code in ever single kernel. Also, the few kernels that are really tight for cycles could probably go in the same bank as the JMP table and avoid the initial JMP?

 

Trying to find you enough cycles to do digital audio during the kernel

 

Chris

[resizable ball]

I guess this won't work because the HMMx need to come before the HMOVE and the ENAMx need to come after.

 

I wonder if you could do something like this instead to eliminate the LSRs and allow the GRP1 to be a fast fetch:

 

        
        lda #<DS_HMP0
        sta HMP0
        tax
        lda #<DS_HMP1
        sta HMP1
        tay
        lda #<DS_HMMB
        sta HMBL
        sta ENABL
        ...
        lda #<DS_GRP1
        sta HMOVE
        sta GRP1
        stx ENAM0
        sty ENAM1

Chris

[resizable ball]

I see this pattern a lot:

 

  
  lda #<DS_HMMB           ; 2 58 <- just to keep stream in sync        
  lda #<DS_M1M0BL         ; 2 60        
  sta ENABL               ; 3 63 <- on VDEL, for next scanline       
  lsr                     ; 2 65       
  tay                     ; 2 67 <- Y has enable for M0        
  lsr                     ; 2 69 <- A has enable for M1        
  ldx DS_GRP1             ; 4 73        
  jmp R76                 ; 3 76

Could you use the DS_HMMB fetch to eliminate an LSR and save 2 cycles, e.g:

  lda #<DS_HMMB           ; 2 58 <- just to keep stream in sync        
  tay                     ; 2 60
  lda #<DS_M1M0BL         ; 2 62        
  sta ENABL               ; 3 65 <- on VDEL, for next scanline       
  lsr                     ; 2 67 <- A has enable for M1        
  ldx DS_GRP1             ; 4 71
  jmp R76                 ; 3 74

Even where the HMMB value is used, I think you can still use this trick. It looks like the Y value is only used for ENAM0, which won't overlap with the bits needed for HMBL, i.e:

 

  lda #<DS_HMMB
  sta HMBL
  tay
  ...
  sty ENAM0

Or even better if you can put the HMBL and ENAM0 together you could free up the Y register entirely:

 

  lda #<DS_HMMB
  sta HMBL
  sta ENAM0

You could possible combine one of the other HMMx values with ENAM1 and save a fecther ...

 

Chris

[Progress on game screen]

Thanks for the explanation - I played with some ideas for the score kernel but I'm not getting anywhere. Using RESPx doesn't work because P0 and P1 need to overlap. The only way would be to display on alternate frames with flicker, but I suspect you don't want that. Given a choice of chunky PF text or flicker, I'd go with the chunky PF text.

 

Chris

[Progress on game screen]

The console detection is cool - I never expected it to work

 

I'm not keen on the chunky PF text at the bottom - it is probably possible to do better using RESPx tricks. What are the constraints, i.e. how many digits do you need for the score & lives, and what is the width of the scanner?

 

Chris

[Revenge of the Homebreviews]

I'm looking forward to your review comparing the two versions of Starcastle!

[Dreamcast dreaming]

The dreamcast battery is rechargeable - try leaving your console switched on for a while.

 

I highly recommend a GDEmu device (SD card adaptor for the dreamcast) - a bit expensive, but you won't need to open any sealed games:

https://gdemu.wordpress.com/

They are only sold periodically, so you need to keep checking the site.

 

Chris

[4K Installed]

What is the LifeSpan box - is your desk above a treadmill?

Chris

[Real Arcade Play: Achieved!]

Nice - the vectrex is a great system!

 

I have one too, and it seems made for a Juno First port

 

Chris

 

 

[DPC+ARM - Part 7, 6507/ARM Exchange of Information]

Perfect timing - I was just thinking about doing a small DPC+ARM project to get back into 2600 programming and I was struggling to remember how it all fitted together - thanks!

 

Chris

[Chetiry]

Thanks for posting the link - that is a really thorough analysis of Tetris! I did attempt to duplicate the gameboy timings and distributions for Chetiry, but there are probably lots of subtle differences. I haven't seen such obsession with the game since I saw this video:

 

Cheers,

Chris

[Slick Kernel]

For Chetiry, I used a customized version of the DCP+ fast fetchers to update the audio in 5 cycles, i.e:

 

lda #<AUD0
sta AUDV0

However, if you are already getting tight for cycles it is probably best to save them for the actual game

 

Chris

[Slick Kernel]

I suppose you could use the extra 5 cycles for digital music or SFX?

 

Chris

[Slick Kernel]

The cycle 23 one could do the jmp a bit later , i.e. shift a bit more code into the bank containing the kernel entry point?

 

Chris

[Slick Kernel]

Nice work - this has to be for a Robotron kernel

It feels like it might be possible to optimise further by removing the following two lines:

 

lda #<DS_JUMP ; 2 30
sta NextKernel+1 ; 3 33

 

If you could arrange all the kernel entry points to be in the same bank, and repurposed the cycles for the jmp R76, i.e.:

 

KernelEntry1:
   jmp ActualKernel1
 
ActualKernel1:
  ...
  jmp (NextKernel)

 

But those 5 extra cycles are probably not enough to update the PF or anything useful ...

 

Chris

[Missile driver rewritten]

Nice work - I like the vblank and overscan counters. How much work remains to turn this into the full game?

 

Chris

[Homebrew Art, part 3 - The Krokodile Cart]

I never registered that the Krokodile was a flasher - I just thought he was selling dodgy merchandise out of his coat

 

Any idea why it was called the "Krokodile" cart - perhaps Armin just likes crocodiles?

 

Chris

[Homebrew Art, part 1 - Climber 5 contest entries]

Thanks - I really enjoy reading these. It is great to hear the story behind the artwork, not just the programmers perspective.

Chris

[Homebrew Art - The Index]

Good idea - I read through your gallery when you first posted it up, but I had completely forgotten about it.

 

Chris

[Optimized P0 routines]

You should be able to make a good Robotron port with that kernel.

[8, 500, and other meaningless numbers]

Nice work - it is great to hear the story behind each label, although it must take a long time to write each one! I'm looking forward to reading the rest of them. My favourite is probably your Chetiry label - it captures the Soviet propaganda poster style perfectly.

 

Chris

[To-do or die!]

Can't wait to see what you and DaveD come up with for the Star Castle label - the Space Rocks one was amazing!

 

Chris

[My Vaporware]

Good to see you back on AtariAge. I'm also taking a bit of a break at the moment for family reasons.

 

I was always hoping that Delicon would return at some point with a completed Chimera cart - I guess he just lost interest. The Harmony has now been pushed to do many similar things (e.g. Space Rocks is a combined ARM/6502 game), but the Chimera had some advantages.

 

Are you planning to pick any of these projects back up? It would still be good to see the Cybertec mod improved (ideally with HDMI output), Death Derby is still an interesting project, and I hope to see [email protected] re-released at some point.

 

Chris

[Speech prep finished]

Looking forward to the next update of Frantic now that Space Rocks is done

 

Chris