Help desperately needed: streamlining the CIN code

[Help desperately needed: streamlining the CIN code]

I know this is a pain, but I would like to convert the G2F code in the same manner as we did for the CIN code: OS ROM enabled, and only DLIs running.

Flash, could you possibly do this for me? Please, please, please, pretty please! (see attached, g2f.a65)

Atari-G2F.zip

demo.xex

[Help desperately needed: streamlining the CIN code]

I have a quick (and important) question: does anyone know how to read MCPP files?
Atari Interlace does not import ASM files for this format, only xex (see attached)

MCPP.xex

[Help desperately needed: streamlining the CIN code]

Thanks for the input Irgend. I am going to mull over this the next couple of days, and see if it can get me progressing a little faster (I have already consummed 4 weeks of my entire freetime on this PMG/GFX stuff).

Meanwhile, if some generous soul could look into ways to accelerate the CIN rendering, I would be very grateful.

[Help desperately needed: streamlining the CIN code]

• especially if this is your first Atari project: keep it simple!
• like said: CIN is (for most users) unacceptable for a game in PAL land. So reducing the CPU load isn't the only problem...
• I did a very quick and rough conversion of the C64 graphics you've attached. No DLIs (yet), plain ANTIC 4. Maybe this is already sufficient.

Hmmm, not that bad actually... though clearly not as good as C64 equivalent.

When I stumbled on CIN, my hope was that I could achieve equivalent (or better) GFX.

 

In the end, gameplay matters more, so perhaps in the shorterm I could latch onto this.

Could you tell me how you produce the image and code to display it?

 

P.S: the game uses pixel color to determine speed. Grey/Yellow for the track (full speed), Purple for walls (0), and everywhere else slow speed.

[Help desperately needed: streamlining the CIN code]

In order to help veterans understand better my problems, I am attaching here the sources of a cross-platform tech demo for C64/A8.

The D64 in VICE gets 32 FPS, whereas the ATR in Altirra gets 12 FPS.

 

Could the vets (Flash? Rybags? Popmilo? Phaeron? Irgend? Schlortt?) help me improve the file /include/Atari/CIN.a65 as follows:

(1) Use IRQs instead of DLI vector, to speed up the code.

(2) Add refresh for timer/keyboard/joystick, so the OS ROM can be disabled? (I badly need the memory to run the full game).

 

Many thanks in advance guyz!

sources.zip

demo.atr

demo.d64.zip

[Help desperately needed: streamlining the CIN code]

Sorry can't help at the moment either (only a few more months, please god), but love the idea. Totally agree with Level42.

You're going to need a proper collaborator if you're going to use cycle sucking modes such as CIN for a few more colours, unless you want to spend a lot more time learning 6502 and the platform. As you know better than most, these vastly different 8 bit systems don't play well with generic code!

 

I wish I could use one the built-in gaphics modes, but they absolutely suck. I am attaching below a comparison of original track (256 colors), converted to CIN and G10, to make the point (there is also the C64 version thrown in).

 

If someone with the needed skills could hook up with me, I would really appreciate it. Ideally, I want to run IRQs (instead of DLIs), and switch off the ROM while still having the necessary functions for the game (timers, keyboard, file reading).

[Help desperately needed: streamlining the CIN code]

1) the intro screen. Do we really want those muddy C64 colors ? A8 can do so much better, look at the Rastaconverter pictures.....or am I missing something about the intro screen that is special ?

2) I watched the C64 youtube video. I'm sure you have other issues now but.....that sound.......seriously drove me crazy after one minute.....I'm sure POKEY can do a lot better recreating some engine sounds....

3) be absolutely sure to support Atari's driving control. This is the only thing that can emulate the feel of the arcade games which have proper steering wheels. This would make a great game a brilliant game IMHO.

4) It's brilliant that it will support online cross platform play....how will that work on real hardware or will this be emulator only ?

Please ignore that video, it is very old and not representative of the current status of the game.

The C64 version is ready, and got much better FPS than shown on that old video. The sounds are also improved, etc...

I have original C64 and XE at home, with ethernet cards (DragonCart in case of A8). So I am testing the game at each step on actual hardware as well as emulators.

[Help desperately needed: streamlining the CIN code]

Altirra debugger can also be of help, you can set traps then single-step and have a visual of what's going on, esp scanline position of current instruction.

 

You'll probably benefit more by using a Pokey timer, but would best be served there by maximum optimization of the IRQ entry, ie use the system vector @ $FFFE.

Could you point me to an existing example of such programming method? I have no idea where to start with implementing this. :-S

[Help desperately needed: streamlining the CIN code]

Another timesaving hint for DLIs - instead of WSync you can pad out with NOPs to get a delay. You have to allow for jitter though.

Also preload registers for colour changes etc. though if you're using WSync there's usually not a lot of time to do stuff.

I tried adding 20 nops at the beginning of the loop. The image still displays correctly (20 is the max, at 21 sync is lost).

However, the FPS of the game does not improve.

loop:
	nop
	nop
	nop
	nop
	nop
	nop
	nop
	nop
	nop
	nop
	nop
	nop
	nop
	nop
	nop
	nop
	nop
	nop
	nop
	nop
	eor #$c0
	sta wsync
	sta prior
	dex
	bne loop

[Help desperately needed: streamlining the CIN code]

 

Trying to do this kind of mode through a DLI per scanline is not effective, because DLIs trigger at the start of a scanline while the change needs to occur at the end, so the DLIs will eat almost all the CPU in STA WSYNC anyway. To get significant CPU back requires using an IRQ instead, as Rybags notes.

Hey Phaeron,

Flash helped me a lot getting the OS ROM functioning again, by following your instructions. I have attached the resulting code.

But as you predicted, there is not a lot of CPU time left for anything, so FPS on my actual game is very low (3 times lower than C64).

If I wanted to use IRQ, would it be a lot of effort modifying again the code?

Atari-CIN.zip

[Converting MADS assembly to CC65 assembly]

 

Happy to dig out and share if you feel that's an easier path.

 

 

That would be awesome! :-)

[Converting MADS assembly to CC65 assembly]

Most of the code is straight forward, but there are some sections that cannot easily be converted, like this piece of the CIN code:

dlist0:	dta d'pp',$70+$80
		dta $4e,a(buf0)
		:50 dta $f,$e
		dta $f
		dta $4e,0,h(buf0+$1000)
		:44 dta $f,$e
		dta $f
		dta $41,a(dlist0)

dlist1:	dta d'pp',$70+$80
		dta $4f,a(buf1)
		:50 dta $e,$f
		dta $e
		dta $4f,0,h(buf1+$1000)
		:44 dta $e,$f
		dta $e
		dta $41,a(dlist1)

Furthermore, I am also using the RMT player which is a huge amount of code.
Maybe I should compile with MADS, and use a dissasembler....

[Help desperately needed: streamlining the CIN code]

P.S: I fixed the PMG, I was still writing to hardware registers as needed for the original CIN code.
Now that the OS is back on, I need to write to the shadow registers...

[Help desperately needed: streamlining the CIN code]

To get rid of the CIN mode, open the screen editor:

 

http://atariki.krap.pl/index.php/Otwarcie_ekranu_w_trybie_konsoli_%28GRAPHICS_0%29

 

 

Hey Flash!

I tried to insert the code you recommended, but all I get is a yellowed screen and crash (See attached):

.proc StopCIN
	jsr waitvbl
	mva	#$40	nmien
gr0    
	ldx #$00        ;zamkniecie IOCB #0
	lda #$0c        ;CLOSE
	jsr ?xcio

	lda #<ename
	sta icbufa,x
	lda #>ename
	sta icbufa+1,x
	lda #$0c        ;READ/WRITE
	sta icax1,x
	lda #$00
	sta icax2,x
	lda #$03        ;OPEN
?xcio  
	sta iccmd,x
	jmp ciov
	rts
.endp

Trying to figure out the PMG issue meanwhile...

[Converting MADS assembly to CC65 assembly]

Hey guyz,

 

I have a program mainly written in CC65, and currently I jump from my main program to sub-progs written in MADS for RMT and CIN support.

I would like to do everything in CC65, but it only supports 6502 opcodes (MADS macro are not recognized).

 

I have seen that MADS can export header files to CC65, but can it somehow convert an assembly file containing macros to one containing only 6502 opcodes?

 

Thanks in advance!!!

[Help desperately needed: streamlining the CIN code]

WOW, this worked!!! Thanks so much Flash, you have really helped me a lot!

 

I have integrated your latest code in my demonstration and attached the sources (press space bar to go through the various screens).

 

I only have two little remaining issues:

(1) When stopping the CIN code, the screen remains stuck in graphic mode 10, do you know how I can return to default text mode?

(2) The sprites are all screwed up (black and occupying the entire screen), would you know how I can fix that?

 

I have also attached the C64 version (which can be opened in VICE), to show how the demonstration should look like.

sources.zip

demo.atr

demo.zip

[Help desperately needed: streamlining the CIN code]

The stage 2 VBI was resetting the display list pointer, upsetting the inherent display list swap. Re-enabling interrupts and waiting a couple of frames before shutting them off again fixes it.

 

Having the stage 2 VBI running while the display's on will require a different method of swapping display lists, since the OS will keep loading up the shadow register.

Yeah, the colors show up correctly in that case.

But "sei" disables interrupts again, which means the OS does not refresh timers/keyboard... :-S

[Help desperately needed: streamlining the CIN code]

EDIT: I load up the OS colour shadow registers with the colour palette and then clear the interrupt disable bit to give the stage 2 OS VBL a chance to update the colour registers.

Thx buddy. But the colours are still wrong for some reason (see my attachment above)l.

[Help desperately needed: streamlining the CIN code]

This is what it should look like.

[Help desperately needed: streamlining the CIN code]

If you're just trying to get minimal VBI functionality back to use this image as a menu screen, do this to get normal OS processing back:

• change the writes from the NMI vector at $FFFA-FFFB to just write the DLI vector into VDSLST
• change the display list write from "dlptr" (DLISTL) to the OS shadow at SDLSTL ($0230)
• move VBI writes to direct hardware registers into the OS shadow registers instead: SDMCTL ($022F) and COLOR0-COLOR4 ($02C4-02C8)
• delete the PORTB writes

This will cause the DLI to be activated by the normal OS DLI path. You won't have a lot of CPU time as the DLI will occupy the CPU during the entire image, but it'll be enough for simple menus.

 

While you're at it, might as well fix all the other lameness in the output: $D402 is DLISTL and not DLPTR, $D016-D019 is COLPF0-COLPF3 and not COLOR0-3, $D01A is COLBK and not COLBAK, $D01B is GRACTL and not GTICTL, 20 is RTCLOK+2, 764 is CH, and the STA NMIST in the VBI handler should be STA NMIRES.

 

Trying to do this kind of mode through a DLI per scanline is not effective, because DLIs trigger at the start of a scanline while the change needs to occur at the end, so the DLIs will eat almost all the CPU in STA WSYNC anyway. To get significant CPU back requires using an IRQ instead, as Rybags notes.

Hey Phaeron,

 

I think I followed your suggestion step-by-step, but I must have made a mistake somewhere, as the colours are wrong (see attached).

This is the current code:

// Atari Interlaced Studio

buf0	= $2010
buf1	= $4010

RTCLOK  = $0012
VDSLST  = $0200
SDMCTL	= $022F		;dmactl	= $d400
SDLSTL  = $0230 

COLPF0	= $02C4		;COLPF0	= $d016
COLPF1	= $02C5		;COLPF1	= $d017
COLPF2	= $02C6		;COLPF2	= $d018
COLPF3	= $02C7		;COLPF3	= $d019
COLBK	= $02C8		;COLBK	= $d01a

GRACTL	= $d01b
SKCTL	= $d20f
;PORTB	= $d301

DLISTL 	= $d402
WSYNC	= $d40a
VCOUNT	= $d40b
NMIEN	= $d40e
NMIRES	= $d40f


/*-------------------------------------------------------------------------------------------------*/

	org $80

regA	.ds 1
regX	.ds 1
regY	.ds 1
cnt	.ds 1

/*-------------------------------------------------------------------------------------------------*/

	.get 'menu.dat',-9		; palette

	org buf0
	ins 'menu.dat',0,8000

	org buf1
	ins 'menu.dat',$2800,8000

/*-------------------------------------------------------------------------------------------------*/

	.align	$100

	dlist0:	dta d'pp',$70+$80
		dta $4e,a(buf0)
		:50 dta $f,$e
		dta $f
		dta $4e,0,h(buf0+$1000)
		:44 dta $f,$e
		dta $f
		dta $41,a(dlist1)

	dlist1:	dta d'pp',$70+$80
		dta $4f,a(buf1)
		:50 dta $e,$f
		dta $e
		dta $4f,0,h(buf1+$1000)
		:44 dta $e,$f
		dta $e
		dta $41,a(dlist0)

/*-------------------------------------------------------------------------------------------------*/

main	lda:cmp:req RTCLOK+2

	;sei
	mva	#$00	NMIEN
	;mva	#$fe	PORTB

	mwa	#dlist0	SDLSTL 		;mwa	#dlist0	DLISTL 
	mwa	#dli0	vdli

	lda	#$c0
	sta	mode+1
	sta	loop+1
	
	lda	#(<dli0)	
	sta	VDSLST
	lda	#(>dli0)
	sta	VDSLST+1
	;mwa	#NMI	$fffa
	
	mva	#$c0	NMIEN
	
	lda:rne VCOUNT

wait	lda SKCTL			; press any key
	and #4
	bne wait

	lda:rne VCOUNT

	;mva	#$ff	PORTB
	mva	#$40	NMIEN
	;cli

	mva #$ff 764			; clear info about pressed key
	rts				; exit

/*-------------------------------------------------------------------------------------------------*/

	dli0:	sta regA
		stx regX

		ldx #192
	mode:	lda #$c0

	loop:	eor #$c0
		sta WSYNC
		sta GRACTL
		dex
		bne loop

		eor #$c0
		sta mode+1

		lda regA
		ldx regX
		rti

/*-------------------------------------------------------------------------------------------------*/

NMI	bit NMIRES
	bpl vbl

	jmp dli0
vdli	equ *-2

vbl	sta NMIRES
	phr

	mva #$22	SDMCTL

	mva #.get[0]	COLBK
	mva #.get[1]	COLPF0
	mva #.get[2]	COLPF1
	mva #.get[3]	COLPF2	

	plr
	rti

/*-------------------------------------------------------------------------------------------------*/

	run main

[Help desperately needed: streamlining the CIN code]

My problem is as follow: I can get the entire game (IP65 network code, Joystick, SFX, RMT music, PMG) working with the 4 color Graphic Mode 15.

All I want now is to replace GFX 15 with CIN, as it gives me 64 colours with the same resolution.

 

But I would like to achieve this without restructuring the entire code, because the codebase is shared between C64, A8 and Apple II.

[Help desperately needed: streamlining the CIN code]

There is a lot of good talk here, but the problem is that it is way beyond my level of understanding.

To try and make things clearer, I have attached a portion of my code.

 

In the file demo.c, I load the menu CIN image, and then have a keyboard loop.
The keyboard hit is never detected, because the OS rom is disabled.

 

If I remove the line that disables the OS rom in the CIN asm file, then the image is not displayed.
I have a real hard time understanding the connections between the various elements: OS ROM, NMI, VBI, DLI.

 

So my hope is that someone will understand what I am hoping for: something like the JAG code (see attached), that is CC65 friendly, does not jam the OS (timers/keyboard), and does not burn all CPU time.

Atari-CIN.zip

Atari-JAG.rar

[Help desperately needed: streamlining the CIN code]

P.S: Attached is an example of CIN showing the track, and just 2 players running around.

demo.atr

[Help desperately needed: streamlining the CIN code]

Guyz, thanks for the good replies already!

 

I plan to use CIN for actual gameplay, so reducing the time used by CIN is critical.
With the current code, FPS tests show my game runnning at 10-20 FPS (depend on number of players, 2-4).

If the FPS reduces dues to usage of DLIs, it is bad news....

 

Could you guyz give m specific lines of code I should use to convert this code to IRQ, while still having the OS ROM running in background for timers/keyboard/joysticks?

[Help desperately needed: streamlining the CIN code]

This is a "call to arms" for veterans.

 

I am developping a cross-platform Atari/C64 online top-down racing game (8bit-slicks).

see: http://8bit-slicks.com/ and https://github.com/8bit-Dude/8bit-Slicks

 

The C64 implementation is complete, but I have been battling the A8 for the past 3 weeks to figure out how to get good GFX/Sprites/Music/Sound.

 

I am 95% done, but there is one last thing that I am struggling mightily to achieve: streamlining the CIN code for gaming.

The CIN as ouput by Atari Interlace Studio disables: the OS ROM (mva #$fe portb), all interrupts (sei), and runs a custom NMI (mwa #NMI $fffa).

This is fine when just showing an image, but not when running a game because the timers, keyboard, joysticks... don't get updated.

 

So I would like to have the CIN code running in a way that is similar to the output of the JAG creator: One VBI to set the first line, and then switch GFX each raster line with DLIs.
Then setup the VBI like this, so that it still runs the OS VBlank code for timers, etc...:

		ldy #(<_VBI)				; install VBI
		ldx #(>_VBI)
		lda #6
		jsr SETVBV

So yeah, this is what I wanna do but I am struggling mightily to write the ASM code for it... :-(
So if one of the veterans of A8 ASM could help me achieve this, I will be soooo grateful!

 

P.S: it will be even better if the code is pure 6502 opcodes, rather than MADS macros, because then I can compile it with CC65 as part of the main program!

 

sources.zip

menu.xex