Jump to content
IGNORED

Concerto firmware thread


batari

Recommended Posts

On 7/2/2022 at 4:23 PM, Feinsveur said:

Well, think of menu navigation with the 2nd port as adding better compatability to the 5 or so light gun games. ?

In the meantime, you could try adding a DB9 Y-cable to port #1... keep a controller + gun hooked to it and see how that works out. Probably be fine for the games that ask if you're using a gun or controller... not sure about the auto-detect games like Alien Brigade though. Still, might be worth a try if hot swapping bugs so much. I always use an extension cord myself anymore, which makes it easier to handle and reduces wear at the console of course.

Link to comment
Share on other sites

1 hour ago, Feinsveur said:

@save2600

I'll try that Y adapter out, which should do the job thinking about it. The hot swapping isn't so much an inconvenience doing, I'm just scared of ESD frying any IC's in these old consoles. Not sure about the 7800, but the C64 and Colecovision are pretty susceptible to it.

Cool, let us know how it works out!  ?

Link to comment
Share on other sites

All issues with the firmware build environment have now been sorted out, and finally I can much more easily add features or make improvements to the firmware. In the past it was exceedingly difficult to add features which is why you didn't see improvements coming as quickly as expected.

 

The firmware build with the newest compiler is much shorter and more efficient, which may also lead to stability improvements

 

So, here are the things I am working on now:

  • Support for more 2600 games
    • 2k games and ARM games, and I will check other schemes to see if they need help
  • Easier firmware updates (selecting a BIOS file from the menu will be improved)
  • Improved POKEY/HOKEY support
  • Improved 7800 game support
    • 64k games, support for newer 48k, 144k or 128k+RAM games with POKEY at $0450 or $0800
  • Improved text file support
  • Minor bug fixes
    • Fix question mark in place of 9 when number of pages ends in 9
    • Prevent loading of large files from menu (loading files larger than the Concerto's memory can corrupt firmware)
  • Support for controller in left or right port
  • Improvements to the utility screen (currently it's just a placeholder)
  • Game loading speed improvements

I am sure I have missed some things, so if anyone can chime in and mention specific things I did not mention in this post, please let me know and I will add them to the list.

  • Like 13
  • Thanks 6
Link to comment
Share on other sites

20 minutes ago, batari said:

Improved 7800 game support

  • 64k games, support for newer 48k, 144k or 128k+RAM games with POKEY at $0450 or $0800

Fantastic news thanks Fred! If you need any 128k+RAM/Pokey @$450 game examples happy to help. Most of my stuff lives in that area ?

  • Like 4
Link to comment
Share on other sites

Great stuff! On this point...

  • Support for controller in left or right port

...I think you want some "jam detection" on startup, in case someone has a driving control, trackball, or mouse plugged in, since you can get odd inputs in that case. IMO using the console switches for menus is a nice get-out-of-jail when the user has 4 paddles plugged in, or whatnot. Select can cycle through the menu, and Reset can select the highlighted item.

  • Like 2
Link to comment
Share on other sites

21 minutes ago, RevEng said:

Great stuff! On this point...

  • Support for controller in left or right port

...I think you want some "jam detection" on startup, in case someone has a driving control, trackball, or mouse plugged in, since you can get odd inputs in that case. IMO using the console switches for menus is a nice get-out-of-jail when the user has 4 paddles plugged in, or whatnot. Select can cycle through the menu, and Reset can select the highlighted item.

I think that a driving, trackball, or mouse can be detected if there is up+down or left+right combination. If that is the case, I can possibly disable that port.

 

I do need to add select+reset navigation, though, that is useful.

  • Like 4
Link to comment
Share on other sites

3 minutes ago, Tempest said:

Good to hear that the new firmware is moving ahead.  Will these improvements help with 7800s that have problems with certain games like Alien Brigade?

I can add that to the list to investigate.

  • Like 3
Link to comment
Share on other sites

I was reading through the thread, and noticed a few mentions of offset/shifted graphics in 2600 games (e.g. post #149 and #217) and how this is sometimes fixed by reloading the game.


I also checked the "Smurfs" gameplay video posted on the previous page, and by comparing it to the emulated game in Stella, you can see that all the "player" objects are offset 1 pixel to the left in the video (look closely at the house, the fence and the spider web and compare their position with the playfield graphics).

 

878552112_Smurf1.thumb.jpeg.ad6051a9a6eeedf7f60063e29d8169e4.jpeg1631465832_Smurf2.thumb.jpeg.99a4842b2c24b852cff3867a079e1d24.jpeg382274698_Smurf3.thumb.jpeg.36f0692d25d3cb5fee761f6b8ff5fa99.jpeg

 

So, I wonder if maybe the TIA horizontal counter ends up being out of sync with the CPU when locking in 2600 mode (that is, the start of the scanline doesn't correspond to the start of a CPU cycle, but it's offset by 1 or 2 TIA cycles).

This could explain the gfx glitches and also some games crashing altogether, as collision detection might be messed up and the TIA "WSYNC" function can misbehave in such condition, causing the CPU to skip a byte after it resumes execution.

 

Edited by alex_79
  • Like 2
Link to comment
Share on other sites

17 hours ago, batari said:

I can add that to the list to investigate.

Please do! ALIEN BRIGADE is great fun with a light gun but on my Concerto, although the game loads, the into animation of the alien finger writing starts but then stutters and goes back to the beginning over and over again, usually before the first letter is written every time.

Link to comment
Share on other sites

4 hours ago, alex_79 said:

[...]

So, I wonder if maybe the TIA horizontal counter ends up being out of sync with the CPU when locking in 2600 mode (that is, the start of the scanline doesn't correspond to the start of a CPU cycle, but it's offset by 1 or 2 TIA cycles).

This could explain the gfx glitches and also some games crashing altogether, as collision detection might be messed up and the TIA "WSYNC" function can misbehave in such condition, causing the CPU to skip a byte after it resumes execution.

Looking at the NTSC bios assembly, it does seem to do some kind of collision sync before switching to 2600 mode...
 

Spoiler



; code executed at $0480 (RIOT RAM)

LF7D4: lda    #$00        ;
       tax                ;
       sta    INPTCTRL    ; Disable 7800 RAM
LF7D9: sta    RSYNC,X     ; Clear the TIA
       inx                ;
       cpx    #$2A        ;
       bne    LF7D9       ;
       sta    WSYNC       ; wait for sync
       lda    #$04        ;
       nop                ;
       bmi    LF80A
       ldx    #$04
LF7E9: dex
       bpl    LF7E9
       txs
       sta    $0110
       jsr    $04CB
       jsr    $04CB
       sta    RESP1
       sta    GRP0
       sta    GRP1
       sta    PF2
       nop
       sta    WSYNC
       lda    #$00
       nop
       bmi    LF80A
       bit    CXP1FB
       bmi    LF813
LF80A: lda    #$02
       sta    COLUBK
       sta    LF112
       bne    LF831
LF813: bit    CXP0FB
       bmi    LF823
       lda    #$02
       sta    COLUP0
       sta    LF118
       sta    LF460
       bne    LF831
LF823: sta    DPPH
       lda    #$08
       sta    GRP0
       jsr    $04CB
       nop  
       bit    CXP0FB
       bmi    LF80A
LF831: lda    #$FD
       sta    COLUPF
       jmp (CartResetVectorLo)        ; And use the reset vector on the cart to start
       nop                ; the 2600 game.


 

 

I think the easier route here might be for the concerto to just jump to a ram routine, and from there enable the bios, jump to ($FFFD) and then serve out the 2600 cart.

 

  • Like 1
Link to comment
Share on other sites

The same code can be found in the PAL bios.

Here's the original source code (used to be at "atarimuseum" website), which include comments:

Spoiler

; First zero out TIA without doing a TWSYNC. This must be done in a loop that
; counts up so that graphics are turned off before the collision registers are
; cleared. RSYNC should turn case C into a case A. Note also that the stores
; of zero puts the system in TIA space but does not lock it there. This code
; must all run out of 6532 RAM since the memory map will change as we change
; mode.	The 6532 RAM exists in all memory maps.
*
SYNC:
	LDA	#0
	TAX
	STA	VBLANK
ZEROLP:
	STA	RSYNC,X
	INX
	CPX	#(CXCLR-RSYNC+1)
	BNE	ZEROLP

; Test now for a possible E case. In some E cases, TWSYNCs do not work properly
; and this must be detected. In an E case failure, the LDA is prefetched and
; the 04 following it is skipped over and NOP ($EA) is loaded into A causing
; the branch on minus to be taken. If this happens the E case can now be
; corrected.	NOTE: All E cases do not get trapped here and must be handled
; latter by collisions.
	STA	TWSYNC
	LDA	#4
	NOP
	BMI	ECASE

; Position player 0 on the left side of the screen and player 1 on the right
; side of the screen so that they will overlap (or not overlap as the case may
; be) playfield 2 that has a copy on both sides of the screen.	Resets occur at
; the 38th and 65th cycle.
	LDX	#4
STALL4:
	DEX				;Stall loop
	BPL	STALL4
	TXS				;Set the stack to 0FF for stall JSRs
	STA	RESP0+$100		;38th cylce
	JSR	DUMMY+1-SYNC+$480	;12 cycle stall
	JSR	DUMMY+1-SYNC+$480	;Ditto
	STA	RESP1	;65th cycle

; Turn on graphics to cause the collisions
	STA	GRP0	;68th cycle
	STA	GRP1	;71st cycle
	STA	PF2	;74th cycle

; Stall an entire scan line to allow collisions to take place.	The E case test
; should follow all TWSYNCs to be safe.
	NOP		;76th cycle
	STA	TWSYNC	;3rd cycle
	LDA	#0
	NOP
	BMI	ECASE

; Test now for a collision between player 1 and playfield.	If there is no
; collision, we must shift the clock once. If there is a collision, we must
; do further testing.
	BIT	CXP1FB-$30
	BMI	NOCOL2

; This section shifts the clock once.	Storing a 2 switches the system into
; MARIA MODe and the following store to 0FXXX causes a clock speed-up for one
; cycle and thus shifts the clock once.
ECASE:
	LDA	#2
	STA	COLUBK	;changes to MARIA MODe
	STA	$F112
	BNE	DONE	;JMP

; Test now for a collision between player 0 and playfield.	If there is no
; collision, we must shift the clock twice. If there is a collision, we must
; do further testing.
NOCOL2:
	BIT	CXP0FB-$30
	BMI	NOCOL0

; This section shifts the clock twice.	Storing a 2 switches the system into
; MARIA MODe and the following stores to 0FXXX causes two clock speed-ups for
; one cycle and thus shifts the clock twice.
	LDA	#2
	STA	COLUP0	;changes to MARIA MODe
	STA	$F118
DUMMY:
	STA	$F460	;Note that the 060 is a RTS
	BNE	DONE

; If we've fotten to this point the only possible failure left is an E case that
; was not detected by the TWSYNC trap.	Test for this by clearing the collision
; registers, shifting the graphics for player 0 to the left one pixel by
; changing GRP0 from a 4 to an 8, and then retesting for a collision.	If there
; is still a collision between player 0 and the playfield, we have an E case,
; otherwise we are done. Be careful not to test for collisions until after they
; occur (about the 40th cycle).
NOCOL0:
	STA	CXCLR			;21st cycle
	LDA	#8			;23rd cycle - one pixel to the left
	STA	GRP0			;26th cycle
	JSR	DUMMY+1-SYNC+$480	;12 cycle stall
	NOP				;40th cycle - just to be safe
	BIT	CXP0FB-$30		;43rd cycle
	BMI	ECASE

; We are now synced and should lock ourselves into TIA mopde with the external
; cart enabled and jump to the reset vector.	Thanks for stopping by...
DONE:
	LDA	#$FD
	STA	COLUPF	;Change MODes to TIA with EXT and lock.
	JMP	($FFFC)

 

 

Edited by alex_79
  • Like 1
Link to comment
Share on other sites

1 hour ago, DrVenkman said:

Please do! ALIEN BRIGADE is great fun with a light gun but on my Concerto, although the game loads, the into animation of the alien finger writing starts but then stutters and goes back to the beginning over and over again, usually before the first letter is written every time.

Thanks, that may help pinpoint the problem. Initially I tried the game and it seemed to work, but now that you mention this, on my consoles, the alien finger comes out for a second then it just jumps to the title screen.

Link to comment
Share on other sites

1 hour ago, RevEng said:

Looking at the NTSC bios assembly, it does seem to do some kind of collision sync before switching to 2600 mode...
 

  Hide contents

 



; code executed at $0480 (RIOT RAM)

LF7D4: lda    #$00        ;
       tax                ;
       sta    INPTCTRL    ; Disable 7800 RAM
LF7D9: sta    RSYNC,X     ; Clear the TIA
       inx                ;
       cpx    #$2A        ;
       bne    LF7D9       ;
       sta    WSYNC       ; wait for sync
       lda    #$04        ;
       nop                ;
       bmi    LF80A
       ldx    #$04
LF7E9: dex
       bpl    LF7E9
       txs
       sta    $0110
       jsr    $04CB
       jsr    $04CB
       sta    RESP1
       sta    GRP0
       sta    GRP1
       sta    PF2
       nop
       sta    WSYNC
       lda    #$00
       nop
       bmi    LF80A
       bit    CXP1FB
       bmi    LF813
LF80A: lda    #$02
       sta    COLUBK
       sta    LF112
       bne    LF831
LF813: bit    CXP0FB
       bmi    LF823
       lda    #$02
       sta    COLUP0
       sta    LF118
       sta    LF460
       bne    LF831
LF823: sta    DPPH
       lda    #$08
       sta    GRP0
       jsr    $04CB
       nop  
       bit    CXP0FB
       bmi    LF80A
LF831: lda    #$FD
       sta    COLUPF
       jmp (CartResetVectorLo)        ; And use the reset vector on the cart to start
       nop                ; the 2600 game.

 

 

 

 

I think the easier route here might be for the concerto to just jump to a ram routine, and from there enable the bios, jump to ($FFFD) and then serve out the 2600 cart.

 

The menu already jumps to a short 2600 RAM routine after loading 2600 binaries, so I can just add in the above code (currently all it does is lock 2600 mode, show a rainbow screen while detecting the bankswitch type and then boot the cart. I can take out the rainbow screen as it is often just a frame or two unless there is a problem, and replace with the above code.

  • Like 3
Link to comment
Share on other sites

1 hour ago, RevEng said:

Looking at the NTSC bios assembly, it does seem to do some kind of collision sync before switching to 2600 mode...
 

  Hide contents

 



; code executed at $0480 (RIOT RAM)

LF7D4: lda    #$00        ;
       tax                ;
       sta    INPTCTRL    ; Disable 7800 RAM
LF7D9: sta    RSYNC,X     ; Clear the TIA
       inx                ;
       cpx    #$2A        ;
       bne    LF7D9       ;
       sta    WSYNC       ; wait for sync
       lda    #$04        ;
       nop                ;
       bmi    LF80A
       ldx    #$04
LF7E9: dex
       bpl    LF7E9
       txs
       sta    $0110
       jsr    $04CB
       jsr    $04CB
       sta    RESP1
       sta    GRP0
       sta    GRP1
       sta    PF2
       nop
       sta    WSYNC
       lda    #$00
       nop
       bmi    LF80A
       bit    CXP1FB
       bmi    LF813
LF80A: lda    #$02
       sta    COLUBK
       sta    LF112
       bne    LF831
LF813: bit    CXP0FB
       bmi    LF823
       lda    #$02
       sta    COLUP0
       sta    LF118
       sta    LF460
       bne    LF831
LF823: sta    DPPH
       lda    #$08
       sta    GRP0
       jsr    $04CB
       nop  
       bit    CXP0FB
       bmi    LF80A
LF831: lda    #$FD
       sta    COLUPF
       jmp (CartResetVectorLo)        ; And use the reset vector on the cart to start
       nop                ; the 2600 game.

 

 

 

 

I think the easier route here might be for the concerto to just jump to a ram routine, and from there enable the bios, jump to ($FFFD) and then serve out the 2600 cart.

 

This will work with the normal 7800 BIOSes, but is not a clean solution for Devbios and possibly other alternative BIOSes.

Link to comment
Share on other sites

57 minutes ago, batari said:

Thanks, that may help pinpoint the problem. Initially I tried the game and it seemed to work, but now that you mention this, on my consoles, the alien finger comes out for a second then it just jumps to the title screen.

I vaguely recall this same problem when playing with cycle timing in a7800. I *think* it may just be a race condition in the game, so you might play with the timing of when you're jumping to the cart, in relation to vblank.

Link to comment
Share on other sites

13 minutes ago, RevEng said:

I vaguely recall this same problem when playing with cycle timing in a7800. I *think* it may just be a race condition in the game, so you might play with the timing of when you're jumping to the cart, in relation to vblank.

In my case, on both my 7800's, the finger starts, hesitates, then restarts. I can never get past it to the title screen and start a game. 

Link to comment
Share on other sites

16 hours ago, Tempest said:

That's what happens on mine too.

Same here.

 

I wonder if this may not be somehow related to this thread:

 

 

There's at least one Synertek-made SALLY going free-range somewhere around here.  Can't get to it until the weekend, but I can try swapping it in and seeing what, if anything, changes.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   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.
×
×
  • Create New...