Jump to content
Have You Played Atari Today?
2600|5200|7800|Lynx|Jaguar|Forums|Store  
  • entries
    650
  • comments
    2,611
  • views
    872,236

Launch Missiles

Sign in to follow this  
Followers 0
SpiceWare

Entry posted by SpiceWare ·

589 views

Just finished getting the main kernel loop revamped to support updating the missiles. To make it work I unrolled the datastreams for both left and right PF0. PF0 only uses the upper half of the byte, while the missile enable only uses one of the bits in the lower half, so I combined the data(left PF0 with Missile 0 and right PF0 with Missile 1). Due to timing issues, I load those datastreams into the X and Y registers as that gives me more flexible for timing the writes (the PF0 writes have different windows than the ENAMx writes).

 

There's only 4 cycles left in the kernel if STA WSYNC is removed, so I don't think it's going to be possible to squeeze in the ball. There's 13 TIA updates per scanline though, so not too shabby!

 

The reposition's are currently NOP'ed out as I haven't revamped those yet. Have a problem where the Harmony's crashing, but not Stella, so I'm going to have to roll back to the prior version and reimplement all the changes while making sure I test on real hardware after each small change.

blogentry-3056-0-27816600-1310686348_thumb.png

 

To make the kernel easier to understand, I made aliases for the DataFetchers.

 

DS_COLUP0	= DF0DATA
DS_GRP0		= DF1DATA
DS_COLUP1	= DF2DATA
DS_GRP1		= DF3DATA
DS_PF0L_M0	= DF0FRACDATA
DS_PF1L		= DF1FRACDATA
DS_PF2L		= DF2FRACDATA
DS_PF0R_M1	= DF3FRACDATA
DS_PF1R		= DF4FRACDATA
DS_PF2R		= DF5FRACDATA

KernelLoop:			;   70
lda #<DS_COLUP0		; 2 72
sta WSYNC		
KernelLoopNoWSYNC:
nop;beq RepositionP0	; 2  2
sta COLUP0		; 3  5 - before 25
lda #<DS_COLUP1		; 2  7
nop;beq RepositionP1	; 2  9
sta COLUP1		; 3 12 - before 25
stx ENAM0		; 3 15 - before 25	
lda #<DS_GRP0		; 2 17
sta GRP0		; 3 20 - before 25
sty ENAM1		; 3 23 - before 25
lda #<DS_PF2L		; 2 25
sta PF2			; 3 28 - before 38
lda #<DS_GRP1		; 2 30 - any
sta GRP1		; 3 33 - any
sty PF0			; 3 36 - PF0R, 28-49
lda #<DS_PF1R		; 2 38
sta PF1			; 3 41 - PF1R, 39-54
lda #<AMPLITUDE		; 2 43 - any
sta AUDV0		; 3 46 - any
lda #<DS_PF2R		; 2 48
sta PF2			; 3 51 - PF2R, 50-65	
ldy DS_PF0R_M1		; 4 55
lda #<DS_PF1L		; 2 57
ldx DS_PF0L_M0		; 4 61 - 0 triggers end-of-kernel
stx PF0			; 3 64 - PF0L, after 55
sta PF1			; 3 67 - PF1L, 66 - 28 	
bne KernelLoop		; 3 70 - 2  69 not taken
jmp KernelDone		; 3 72

Sign in to follow this  
Followers 0

7 Comments

Recommended Comments

LS_Dracon

I'm not understand DCP+ yet... But where you load Y and X for ENAMx and PF left screen data?

Are you using the 4 unused PF0 pixels?

 

Edit : And what is the AUDV0 usage in kernal?

Share this comment

Link to comment
SpiceWare

DF0FRACDATA = Right Side PF0 and Missile 0

DF3FRACDATA = Left Side PF0 and Missile 1

 

I was getting the datafetchers confused while working out the kernel, so I made aliases for them so I could better remember what each one was being used for. They're listed just before KernelLoop, the 2 relavent ones are DS_PF0L_M0 and DS_PF0R_M1 - they're DPC+ registers DF0FRACDATA and DF3FRACDATA.

 

When they're loaded they're being loaded for the NEXT scanline. Not show in the code extract is X and Y being initialized just before the kernel starts.

	ldy DS_PF0R_M1		; 4 55
lda #<DS_PF1L		; 2 57
ldx DS_PF0L_M0		; 4 61 - 0 triggers end-of-kernel
stx PF0			; 3 64 - PF0L, after 55
sta PF1			; 3 67 - PF1L, 66 - 28 	
jmp KernelLoop		; 3 70

 

AUDV0 is for the digital audio playback ("Intruder alert!", etc). It needs to be done every scanline. If I wasn't doing the digital audio I might be able to reconfigure things enough to squeeze in the ball, though timing would be tough (if I changed the LDA/STA AUDV0) to LDA/STA ENABL the ball would sheer as it travels across the screen due to a mid-scanline update).

Share this comment

Link to comment
SpiceWare

Time Machine to the rescue!

 

I went backwards in time to find the last Harmony compatible ROM, which turned out to be on July 9th. Much better than my last manual backup, which was posted on June 26th!

 

Now I just need to reimplement the changes and test on the Harmony after each one to find the source of the crash. Once that's found I should be able to fix it and resume work on the new kernel w/missile support.

Share this comment

Link to comment
LS_Dracon

So the speech will happens during gameplay, it's interesting. I thought only happens after leaving the room, like Berzerk VE.

 

Too bad AUDV0 uses the right nybble, otherwise the ball could be enabled using the left nybble.

 

Good luck with your kernel :)

Share this comment

Link to comment
SpiceWare

Yep - at any time. Without datafetchers it'd be very complicated to keep AUDV0 updated while also drawing the screen.

 

AUDV0 isn't using a datastream so I couldn't merge the ball enable with it. DPC+ calculates AMPLITUDE on the fly. It's using the exact same routines as for the 3-voice music, just one of the 3 waveform buffers was expanded from 32 bytes to 2048 bytes. In theory I could still use the other 2 voices to play in-game music while the speech was going on, but the reality is that would decrease my volume range from 0-15 to just 0-5 (the 3 waveforms get added together to calculate AMPLITUDE) and I don't think the speech would sound very good with such a limited range.

 

I figured out how to still be able to use the 2nd voice for sound effects when there's no speech going on, but I haven't tested it yet.

Share this comment

Link to comment
SpiceWare

I've reimplemented all but the changes to ShiftRoom(), which is used when you exit a room to shift it offscreen. When I implement those, the Harmony starts to crash. The crashes occur after hitting RESET to start a game.

 

What I think this means is one of the functions after ShiftRoom() is the problem function because ShiftRoom() is not called when RESET is hit. The change in size of the revised ShiftRoom() must be causing one of the following functions to be compiled differently for some reason.

 

I was able to confirm that by moving ShiftRoom(), without implementing the changes, to the end of the C source file. Hitting RESET to start the game results in a crash. Move ShiftRoom() back and it works fine again.

 

At this point I've got 2 things to try:

 

1) I think ARM compiler has been updated. The version under download the current release is newer than the version I have in Linux. However, I've been using an OS X build that batari created and I don't know what version he used. I'll update my Linux VM and see if the results are different.

 

2) move ShiftRoom down the source code a function at a time until the crashing occurs. That should tell me which function is causing the crash. At that point I'll probably need help from one of you ARM experts to figure out what's going on :)

Share this comment

Link to comment
carmel_andrews

Did you say you needed 'ARM' help, I have 2 arms if you need one (but me thinks you mean the arm as in 'ACORN RISC MACHINES')...nice processor, designed by the same 'woman' who also designed the original Acorn and BBC computers

Share this comment

Link to comment
Guest
Add a comment...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
×

  • Recently Browsing   0 members

    No registered users viewing this page.

AtariAge
Forums
Store
General
Follow AtariAge

Copyright ©1998-2021 AtariAge

×
×
  • Create New...