Five clock per pixel RLE mode

Topics related to the API, programming discussions & questions, coding tips, bugs, etc. should go here.
CunningFellow
Posts: 1445
Joined: Mon Feb 11, 2013 8:08 am
Location: Brisbane, Australia

Re: Five clock per pixel RLE mode

Post by CunningFellow »

Clever is what I do :)

Sadly quick does not seem to be what I do. Been 8 months since I made much movement on this.

I started working on a new demo for this mode this morning. Should hopefully be able to drop some jaws.
User avatar
nicksen782
Posts: 714
Joined: Wed Feb 01, 2012 8:23 pm
Location: Detroit, United States
Contact:

Re: Five clock per pixel RLE mode

Post by nicksen782 »

I certainly am looking forward to it!

CUzeBox doesn't have the patch officially yet, right? Jubation mentioned integrating it into the emulator. Has that happened yet?
User avatar
Jubatian
Posts: 1560
Joined: Thu Oct 01, 2015 9:44 pm
Location: Hungary
Contact:

Re: Five clock per pixel RLE mode

Post by Jubatian »

nicksen782 wrote: Thu Aug 16, 2018 4:43 pmCUzeBox doesn't have the patch officially yet, right? Jubation mentioned integrating it into the emulator. Has that happened yet?
Sadly no. Life stuff intervened when I originally wanted to do it, and nowadays it's such a mess around me that I can't really do it, I am totally pooped.

CunningFellow: Could you fork the emulator with your patch? For now that's the best solution, so there would be a version on GitHub which you could use if you wanted to play around with the RLE mode (the patch isn't good for anything else as it only adds a crude solution to make the RLE mode work).
CunningFellow
Posts: 1445
Joined: Mon Feb 11, 2013 8:08 am
Location: Brisbane, Australia

Re: Five clock per pixel RLE mode

Post by CunningFellow »

Seeing as the forum was slow at the moment I was going to post a still picture from my current demo I am working on.

I was not ready to post the demo because from some angles the picture broke up. I thought it was a problem with hidden surface removal.

Turns out it was the Y=MX+C to RLE converters limitations interacting with the more complex scene.

I always knew the converter was basic but thought I was going to deal with that on the C side. Turns out that is a bit hard.

I have spent quite a few hours and now the Y=MX+C to RLE converter can cope with crossing lines. If two or more lines cross at the same point, the (n+1)th line becomes invisible till the next scan line which can lead to 1/M pixels of the wrong colour. No one will notice that if it does ever happen.

Anyway - here is a still shot of the new encoders results. The lime green line crosses over the blue and pink lines. In the previous version this kind of crossing would cause one line to disappear and the crossed line to bleed into the next transition.
RLE_LineCross.jpg
RLE_LineCross.jpg (34.39 KiB) Viewed 12588 times
User avatar
Jubatian
Posts: 1560
Joined: Thu Oct 01, 2015 9:44 pm
Location: Hungary
Contact:

Re: Five clock per pixel RLE mode

Post by Jubatian »

Sure this will be something wicked! Wish to see some more :)

By the way would it be possible to get rid of the UART hack if you had a kernel which doesn't use the COMPB interrupt?
CunningFellow
Posts: 1445
Joined: Mon Feb 11, 2013 8:08 am
Location: Brisbane, Australia

Re: Five clock per pixel RLE mode

Post by CunningFellow »

Sadly I am still having lines drawing where there should not be any (see the yellow engine exhaust and blue line from the nose). More debugging next weekend I guess.
1337.jpg
1337.jpg (47.08 KiB) Viewed 12569 times
Here is a HEX of that same broken picture if someone wants to see it on real hardware. It is just canned lines for this example so the fault stays visible.

I don't think I can use CompB becuase I would crash into the other interrupts code.

I have one interrupt to end a scanline and one to end a run of pixels.

See below

Code: Select all

	jmp		__vector_13			; TIMER1_COMPA
	jmp		__vector_14			; TIMER1_COMPB


	; ***************************************
	; ******** TIMER1_OVF interrupt *********
	; ***************************************

	in		r3, _SFR_IO_ADDR(SREG)				; Save the status register
	movw	r4, r30								; Save the Z register pair because we are about to trash them with the IJMP

	ldi		ZH, 0x00							; ZH = 0x00 so the address IJMP goes too is 0x0038, 0x0039, 0x003A or 0x003B, 0x003C

												; Get the value of TCNT1 for jitter elimination.
												; The overflow interrupt flag gets set at 0x0000 but it takes a variable amount
												; of time to get to this point.  We need to read the timer value to see how much
												; past 0x0000 it made it so we can correct for the variable latency.

	lds 	ZL,_SFR_MEM_ADDR(TCNT1L)			; The lowest value this can be is 0x08 (interrupt latency plus 3 instructions above)
												; The highest value it can be is 0x0C
	subi	ZL, -(0x30)							; Add 0x30 to the TCNT value so it is 0x38..0x3C

	ijmp										; Jump to one of 5 instructions in "Jitter_Fixer" (4x NOP and 1x SEI)

	nop											; Just a space filling NOP so that the rest of the vectors are aligned

	; The next 3 int vectors (TIMER0 COMPA, COMPB and OVF) are unusable
	; because the above code uses up their allocated space
	; If you enable these interrupts bad things will happen
	; This should be no loss as Timer0 in the Uzebox should never need an ISR

	;jmp	__bad_interrupt		; TIMER0_COMPA
	;jmp	__bad_interrupt		; TIMER0_COMPB
	;jmp	__bad_interrupt		; TIMER0_OVF
	jmp		__bad_interrupt		; SPI_STC
	jmp		__bad_interrupt		; USART0_RX
	jmp		__bad_interrupt		; USART0_UDRE


	; ***************************************
	; ********* USART0_TX interrupt *********
	; ***************************************

	nop											; waste a clock so the last pixel is correct width
	out 	_SFR_IO_ADDR(PORTC), r2				; Output a BLACK pixel for the end of the scanline (r2 is ZERO)
	rjmp	EndScanlineInt
	nop
	

	; The next int vector (ANALOG_COMP) is unusable
	; because the above code uses up its allocated space
	; If you enable this interrupt bad things will happen

	;jmp	__bad_interrupt		; ANALOG_COMP
	jmp		__bad_interrupt		; ADC
	jmp		__bad_interrupt		; EE_READY
Attachments
1337.hex
(32.52 KiB) Downloaded 610 times
User avatar
D3thAdd3r
Posts: 3175
Joined: Wed Apr 29, 2009 10:00 am
Location: Minneapolis, United States

Re: Five clock per pixel RLE mode

Post by D3thAdd3r »

Very cool, I instantly thought of the original Star Fox when I saw that!
User avatar
Jubatian
Posts: 1560
Joined: Thu Oct 01, 2015 9:44 pm
Location: Hungary
Contact:

Re: Five clock per pixel RLE mode

Post by Jubatian »

Ouch, I see, so it will eventually need resolving UART timing (for adding ESP8266 support as well which needs an UART working like an UART).

But this certainly looks great, wonder how far it could go! You have an entirely different memory budget here compared to the usual. It would be nice to see some vector or 3D stuff eventually!
User avatar
uze6666
Site Admin
Posts: 4778
Joined: Tue Aug 12, 2008 9:13 pm
Location: Montreal, Canada
Contact:

Re: Five clock per pixel RLE mode

Post by uze6666 »

Wow, seeing polygons on a Uzebox is very impressive! Any progress coming soon? (I know it's been a year :oops: )
CunningFellow
Posts: 1445
Joined: Mon Feb 11, 2013 8:08 am
Location: Brisbane, Australia

Re: Five clock per pixel RLE mode

Post by CunningFellow »

Well - there has been progress since this thread. I posted a moving polygon HEX file here

http://uzebox.org/forums/viewtopic.php? ... 402#p30402

About a month after this threads last comment.
Post Reply