54 replies to this topic

[stephena]

davyK, on Sat Feb 4, 2012 2:39 PM, said:

However there is a small amount of judder on the display - almost as if the kernel is starting at different lines in different frames - don't know if its just my TV. Feedback welcome on this one to see if it needs some more work. It flickers like buggery in my version of Stella but there's none of that on the real thing on my TV. I've had this effect before with some NTSC sources but I'm not getting the same effect with other games. It's a bit odd. It small enough so it doesn't put me off playing but I'd rather it wasn't there.

It flickers in Stella because it's a 30Hz ROM, and the phosphor effect isn't enabled for it. Try pressing Alt-p for a temporary fix. And edit the ROM properties settings for a permanent fix.

BTW, you can also use Alt-f to switch to PAL60 palette.

[maiki]

Thomas Jentzsch, on Sat Feb 4, 2012 4:45 PM, said:

I could be wrong, but AFAIK the PAL version of TT is 60Hz.

Please, is it available for download? Over here there is only the NTSC version. I think.

[davyK]

stephena, on Sat Feb 4, 2012 5:10 PM, said:

davyK, on Sat Feb 4, 2012 2:39 PM, said:

However there is a small amount of judder on the display - almost as if the kernel is starting at different lines in different frames - don't know if its just my TV. Feedback welcome on this one to see if it needs some more work. It flickers like buggery in my version of Stella but there's none of that on the real thing on my TV. I've had this effect before with some NTSC sources but I'm not getting the same effect with other games. It's a bit odd. It small enough so it doesn't put me off playing but I'd rather it wasn't there.

It flickers in Stella because it's a 30Hz ROM, and the phosphor effect isn't enabled for it. Try pressing Alt-p for a temporary fix. And edit the ROM properties settings for a permanent fix.

BTW, you can also use Alt-f to switch to PAL60 palette.

cool - not really a power Stella user - it clearly has come a long way if it can simulate a TV output now..

[davyK]

PFL, on Sat Feb 4, 2012 4:43 PM, said:

Do you know if there's any difference between the PAL and NTSC versions of Beamrider? Just curious as I'm having problems with the game on my Harmony cart...

There's a disassembly of this one but its uncommented so it will take a bit of work. The NTSC version runs fine with me. Quite playable - doesn't really need any work as far as I can see as the colours are pretty close to the PAL version. Make sure you use Romhunter's files.

Edited by davyK, Sun Feb 5, 2012 7:20 AM.

[SpiceWare]

maiki, on Sat Feb 4, 2012 4:38 PM, said:

I wish there was a PAL-60 version of Stay Frosty

Hmm - we made PAL60 versions for Stella's Stocking, don't know why it's not an option in the store.

 StayFrosty_PAL.bin   16K   15 downloads

[davyK]

I'm having difficulty getting Combat converted, While it is full screen in PAL there is a small boost in speed to be had from the NTSC version so it's worth doing. However I'm getting a flickery image even with the unchanged ROM.

When I changed the value on the VBLANK wait timer (subtracted 1 from it to match values I have seen in other games) I get a stable image in all the game variations except for those with clouds - and I didn't get the expected colours in the tank pong and jet games - weird. Will keep at it.

; ------------------------------------------------------------
;
; Vertical CoNTRoL
;
; Vertical sync, basic frame-start housekeeping
;
VCNTRL INC CLOCK ; Master frame count timer
STA HMCLR ; Clear horizontal move registers.
LDA #2 ; Get this ready...
STA WSYNC ; for start of next line...
STA VBLANK ; Start vertical blank.
STA WSYNC
STA WSYNC ; and do three lines
STA WSYNC
STA VSYNC ; Now start vertical sync
STA WSYNC
STA WSYNC ; and do three lines
LDA #0 ; get this ready
STA WSYNC
STA VSYNC ; End of vertical sync pulse
LDA #43 ; And set VBLANK timer *********have been experimenting with changing this value ***********
STA TIM64T ; with 64 clock interval.
RTS

Edited by davyK, Sun Feb 5, 2012 2:19 PM.

[maiki]

[davyK]

?????

[RevEng]

davyK, on Sun Feb 5, 2012 2:12 PM, said:

I'm having difficulty getting Combat converted, While it is full screen in PAL there is a small boost in speed to be had from the NTSC version so it's worth doing. However I'm getting a flickery image even with the unchanged ROM.

It looks like Combat runs 263 lines on variations with playfield being drawn, and 262 lines on games without playfield, which is likely the cause of your inconsistency problem.

It skips a bit of code when playfields aren't being drawn, so I added a time waster there and the scanline counts are now stable on all variations...

VnoT1   BIT  PF_PONG
		STA  GRP1
		;BMI  VnoPF			  ; If PF_PONG bit 7 set, don't write PF
		BMI  Vwait			  ; If PF_PONG bit 7 set, waste time and don't write PF
		LDA  (LORES),Y		  ; (this means game variation has blank
		STA  PF0				; background)
		LDA  (LORES+2),Y
		STA  PF1
		LDA  (LORES+4),Y
		STA  PF2
		jmp VnoPF
Vwait
		nop
		nop
		nop
		nop
		nop
VnoPF   INC  ScanLine		   ; One more up in the loop.

This, combined with using #42 for TIM64T should give you what you want.

[Omegamatrix]

Nukey and I did some PAL60 conversions a while back:

Raft Rider
Football
Glib
Revenge of the Beefsteak Tomatoes
Starship
Gravitar
Squeeze Box
Front Line
Halloween
Stellar Track
Pete Rose Baseball
Qbert Qubes
Tapper
Waterworld
Burgertime


They are here:

http://www.atariage....of-these-games/

I know Nukey did a PAL60 Track & Field too, somewhere. That one was a long configuration file IIRC!

[davyK]

RevEng, on Sun Feb 5, 2012 6:03 PM, said:

It looks like Combat runs 263 lines on variations with playfield being drawn, and 262 lines on games without playfield, which is likely the cause of your inconsistency problem.

It skips a bit of code when playfields aren't being drawn, so I added a time waster there and the scanline counts are now stable on all variations...

VnoT1   BIT  PF_PONG
		STA  GRP1
		;BMI  VnoPF			  ; If PF_PONG bit 7 set, don't write PF
		BMI  Vwait			  ; If PF_PONG bit 7 set, waste time and don't write PF
		LDA  (LORES),Y		  ; (this means game variation has blank
		STA  PF0				; background)
		LDA  (LORES+2),Y
		STA  PF1
		LDA  (LORES+4),Y
		STA  PF2
		jmp VnoPF
Vwait
		nop
		nop
		nop
		nop
		nop
VnoPF   INC  ScanLine		   ; One more up in the loop.

This, combined with using #42 for TIM64T should give you what you want.

you are a gent sir - thank you. Will try this out.

How were you able to figure out the number of lines? Was it just from reading the code or by using something like Stella's debugger - I'm only getting into this.

EDIT - yep it works now. I've some reading to do on how the TIA works - I read this up years ago so I have a basic knowledge but not the skills to deal with a problem like this. I take it the number of NOPs inserted is significant ?

Edited by davyK, Mon Feb 6, 2012 2:12 PM.

[RevEng]

No problem - glad to help!

The easy way to check the running line count in stella is to hit ALT+L during the regular emulation screen... if the values are ever changing too quickly to catch, you can use the debugger and step through the game a frame at a time.

As for the NOP count... I started off with enough NOPs to balance out the time between the 2 different branches exactly, but discovered there wasn't rom space available, so I just reduced the NOP count until it fit in rom. It still had the desired effect of slowing things down enough so the extra line was used, so that was good enough for me.

If I have been in a more rigorous mood I could have tried to use other opcodes to do nothing (e.g. jsr+return) and waste the correct amount of time in less space, but it works as-is, and life is short.

[davyK]

nice.

Thanks for the tips. Need to do some reading in the dev section here too.


PAL60 Combat - the PAL colours are different to the NTSC version so it wasn't a straight conversion - I've picked values so to be as close as I can get (at least to my old eyes!)

http://www.davykelly...combatPAL60.bin

Edited by davyK, Mon Feb 6, 2012 4:12 PM.

[davyK]

Almost have Demon Attack cracked - this one is well worth it - the PAL version runs like treacle compared to this.

I have used Nukey Shay's disassembly and he has fixed the wave 85 bug and also added a pause feature by using the color/bw switch which is kind of cool.

However I am having difficulty with the colour of player two's shooter which is appearing as grey instead of yellow/gold.

Here's the colour values in the code at label L1ACE (all on its own in amongst the code - took a while to find)

L1A7D:
LDA INTIM ;4
BNE L1A7D ;2
JMP L1277 ;3

L1ACE: ;2 bytes
.byte $86 ; | X X XX | $1ACE
; .byte $F8 ; |XXXXX | $1ACF
L1A85:
SED ;2 (shared)
CLC ;2
ADC.wy Score+4,Y ;4
STA.wy Score+4,Y ;5
TXA ;2
BCC L1A92 ;2
ADC #$00 ;2

Player 1's colour is at the byte just after the label L1ACE (it is changed here so its the right colour in PAL)
As far as I can figure, Player 2's colour is in the next byte (#F8 maps to grey in PAL - it should be #28 to get the correct gold/yellow colour.

It looks as if the programmer (or Nukey?) has taken advantage of the fact that the opcode for the next instruction (SED) is #F8 which just happens to be the value needed for the colour of Player 2 (in NTSC) which kind of messes me up...

I dropped the SED and brought back the byte in and changed it for PAL colours - I get the correct colour for player 2 but then my maths is screwed up and the score gets corrupted...There are no spare NOPs around for me to take out.

Tried adding 1 to each subsequent ORG and took a byte out of the spare bytes at the end but it corrupts everything (messing up word boundaries?) Tried adding 8 bytes in and adjusting for that too but the game crashes.

Can anyone (Nukey?) help me add in the extra byte? Would be nice to get the player 2 ship looking right.

Thanks..

Edited by davyK, Sun Feb 12, 2012 6:46 PM.

[davyK]

Here's the binary for what its worth. Player 2 ship colour still wrong but perfectly playable.

Had to do a bit of tracking through code to get the correct colour for the ground as it was embedded in the code.

http://www.davykelly...attackPAL60.bin

Edited by davyK, Sun Feb 12, 2012 7:36 PM.

[Andrew Davie]

davyK, on Sun Feb 12, 2012 6:03 PM, said:

Almost have Demon Attack cracked - this one is well worth it - the PAL version runs like treacle compared to this.

I have used Nukey Shay's disassembly and he has fixed the wave 85 bug and also added a pause feature by using the color/bw switch which is kind of cool.

However I am having difficulty with the colour of player two's shooter which is appearing as grey instead of yellow/gold.

Here's the colour values in the code at label L1ACE (all on its own in amongst the code - took a while to find)

L1A7D:
LDA INTIM ;4
BNE L1A7D ;2
JMP L1277 ;3

L1ACE: ;2 bytes
.byte $86 ; | X X XX | $1ACE
; .byte $F8 ; |XXXXX | $1ACF
L1A85:
SED ;2 (shared)
CLC ;2
ADC.wy Score+4,Y ;4
STA.wy Score+4,Y ;5
TXA ;2
BCC L1A92 ;2
ADC #$00 ;2

Player 1's colour is at the byte just after the label L1ACE (it is changed here so its the right colour in PAL)
As far as I can figure, Player 2's colour is in the next byte (#F8 maps to grey in PAL - it should be #28 to get the correct gold/yellow colour.

It looks as if the programmer (or Nukey?) has taken advantage of the fact that the opcode for the next instruction (SED) is #F8 which just happens to be the value needed for the colour of Player 2 (in NTSC) which kind of messes me up...

I dropped the SED and brought back the byte in and changed it for PAL colours - I get the correct colour for player 2 but then my maths is screwed up and the score gets corrupted...There are no spare NOPs around for me to take out.

Tried adding 1 to each subsequent ORG and took a byte out of the spare bytes at the end but it corrupts everything (messing up word boundaries?) Tried adding 8 bytes in and adjusting for that too but the game crashes.

Can anyone (Nukey?) help me add in the extra byte? Would be nice to get the player 2 ship looking right.

Thanks..

Removed my original post, as I misunderstood the problem.
In any case, you could remove the BCC before the adc #0.
It would be slower but probably still work, as it's just doing an overflow add for high byte.

Cheers
A

[davyK]

Tried that and it seems to work OK - what do you mean when it will be slower ? I can't say I noticed it in the gameplay - do you mean a few cycles?

Many thanks....

[davyK]

Have replaced the ROM in the link above. This has the suggested amendment from Andrew above. It seems to work OK and the player 2 ship is now the right colour. Any comments welcome re how it plays.



Here's PAL60 Space War. It looks like the PAL colour for player 2 was different from NTSC so I picked a colour to match the PAL ROM. I like this game it gets slagged off a bit but I think the combat games are great fun.
http://www.davykelly...acewarPAL60.bin

The colour data wasn't commented but was easy to find. If you search for uppercase "COL" in the file and look for STA COLxxx instructions you can usually figure out where the data is held by looking at preceeding load instructions. In this case there were indexed LDAs like this : LDA LF7C3,X. So my first guess was looking at the label LF7C3 in the disassembly and lo and behold by experimenting with changing a couple of values the first 2 bytes truned out be the p1 and p2 colour values.

The PAL60 version of River Raid is now available at the usual place. It had the same problem Pifall had in that it was written for an older version of vcs.h. I removed the -$30 offsets and it seems to work a treat. Bigger screen and faster gameplay as usual. Thanks to Thomas Jentzsch for the great disassembly.

Edited by davyK, Tue Feb 14, 2012 9:06 AM.

[davyK]

Here's another - Air Sea Battle. This one caused problems on my TV (similar to Combat) which doesn't seem to like having an odd number of scan lines (261 in this case). Commenting out a STA WSYNC at the start of the frame seems to do the trick. There is a slight kink at the end of each coloured zone in this game where the colours move up a scanline - at first I thought it was me tinkering with scan lines but the untouched NTSC ROM seems to have this effect too.

The original PAL version doesn't have this small defect and actually runs at full screen but doesn't have the speed of the NTSC or this PAL60 version. So it's a matter of taste if you prefer this version as this game is all about timing your shots.

Here is it anyhow...http://www.davykelly...battlePAL60.bin

Edited by davyK, Tue Feb 14, 2012 4:49 PM.

[davyK]

Found a working disassembly of Freeway - here's a PAL60 version of that. The usual improvements- full screen and bit quicker.

Was quite easy as the colour lookups were well commented.


http://www.davykelly...reewayPAL60.bin

Edited by davyK, Tue Apr 17, 2012 1:42 PM.

[PFL]

I got around to sticking your PAL60 Demon Attack ROM on my Harmony cart. It doesn't seem to work on my system. I've got a Chinese 2600jr so that's maybe the problem as I've heard of compatibility issues with that machine...

When I boot the ROM off the cart the screen distorts, goes black and white and there is a high pitched squeal. Same for River Raid...

[Thomas Jentzsch]

PFL, on Sun Apr 22, 2012 5:52 AM, said:

I got around to sticking your PAL60 Demon Attack ROM on my Harmony cart. It doesn't seem to work on my system. I've got a Chinese 2600jr so that's maybe the problem as I've heard of compatibility issues with that machine...

When I boot the ROM off the cart the screen distorts, goes black and white and there is a high pitched squeal. Same for River Raid...

Maybe bad dumps. Did you try the ROMS in an emulator?

[maiki]

That Demon Attack PAL60 ROM is not working in Stella either...

[Nukey Shay]

His binary is 5 bytes too short (4091 vs. 4096). I suggest downloading my assembly over again if you don't feel like combing through the entire file to see where it's messing up...and re-editing the color values more carefully so that no bytes are lost.

davyK, on Sun Feb 12, 2012 6:03 PM, said:

Can anyone (Nukey?) help me add in the extra byte? Would be nice to get the player 2 ship looking right.

There's plenty of bytes to be reclaimed in Demon Attack (just as with most games). You just need to look around. To reclaim the single byte needed to uncomment the byte labelled $1ACF. scroll up to this area:

;print game select
       JSR    L1C11                   ;6 clear first 2 digits
       LDA    $EA                     ;3 game selection
       JSR    L1C11                   ;6 ...use as next 2 digits
       LDA    #$AA                    ;2
       JSR    L1C11                   ;6
       JMP    L1851                   ;3

Subroutine L1C11 ends with a non-zero result in the status register...so you can change the JMP L1851 to be BNE L1851 instead. That gives you 1 free byte of ROM to uncomment the color code byte above the SED instruction at label L1A85...and be able to cange it to whatever you want.

Edited by Nukey Shay, Sun Apr 22, 2012 8:15 AM.

[davyK]

Nukey Shay, on Sun Apr 22, 2012 8:08 AM, said:

His binary is 5 bytes too short (4091 vs. 4096). I suggest downloading my assembly over again if you don't feel like combing through the entire file to see where it's messing up...and re-editing the color values more carefully so that no bytes are lost.

davyK, on Sun Feb 12, 2012 6:03 PM, said:

Can anyone (Nukey?) help me add in the extra byte? Would be nice to get the player 2 ship looking right.

There's plenty of bytes to be reclaimed in Demon Attack (just as with most games). You just need to look around. To reclaim the single byte needed to uncomment the byte labelled $1ACF. scroll up to this area:

;print game select
	   JSR	L1C11				   ;6 clear first 2 digits
	   LDA	$EA					 ;3 game selection
	   JSR	L1C11				   ;6 ...use as next 2 digits
	   LDA	#$AA					;2
	   JSR	L1C11				   ;6
	   JMP	L1851				   ;3

Subroutine L1C11 ends with a non-zero result in the status register...so you can change the JMP L1851 to be BNE L1851 instead. That gives you 1 free byte of ROM to uncomment the color code byte above the SED instruction at label L1A85...and be able to cange it to whatever you want.

Cheers Nukey - for the record these work OK as is on my PAL woody and Harmony....but I'll fix the Demon Attack one and have another look at River Raid...

Maybe I should test these in Stella as well as on the hardware....

EDIT: Oops - got my version control messed up - the ROM on my site wasn't the ROM I copied onto my Harmony - not too sure what happened as I have recreated the ROM from my ASM source and it works OK - very odd. I have replaced the ROM on my site with the working one I copied onto my Harmony - Just to be sure I've downloaded it again and tested it and it seems OK on my Harmony and Stella...

Apologies folks - I'll make the additional change as per Nukey's recommendation above. Maybe I've screwed up with River Raid the same way - will post back.

Edited by davyK, Sun Apr 22, 2012 3:09 PM.