INB Bug solved

ozpropdev

Hi All
I think I have found the answer to the INB bug mentioned (and lost) in another thread.
It appears that the issue is caused by Pnut still transmitting after the P2 has been released after a download.
This seems to explain that inserting a delay before using INB fixed the problem.
The code below waits for 62 high to low transitions and falls through.

con
	rx_pin = 63

dat		orgh	0
		org

wait4low	testb	inb,#rx_pin wz
	if_nz	jmp	wait4low

wait4hi		testb	inb,#rx_pin wz
	if_z	jmp	wait4hi
		
		djnz	cx,wait4low

		mov	dirb,#$f	'62 or more hi2lo transitions
		mov	outb,#$f	'gets us here
me		jmp	@me

cx		long	62

Now, back to P2 coding/testing.

mindrobots

Cool! Good job, Mr. Holmes!!

Peter Jakacki

Good job, but the PNut gallery is never happy. Ya didn't tell us what was being transmitted and why

ozpropdev

Peter Jakacki wrote: »

Good job, but the PNut gallery is never happy. Ya didn't tell us what was being transmitted and why

Don't know Peter and too busy to find out!
The new syntax changes have broken my code again, so focus has shifted. (Groundhog Day!)

David Betz

It's probably a bunch of 0xF9 characters that the loader has to send to get the Propeller to send its checksum ack/nak. I've seen implementations of the Propeller loader protocol that just blast a bunch of 0xF9 bytes at the Propeller and then look for the 0xFE that acknowledges the checksum verification. Whatever ones come after the Propeller sends the 0xFE end up being seen by the loaded app.

mindrobots

ozpropdev wrote: »

Peter Jakacki wrote: »

Good job, but the PNut gallery is never happy. Ya didn't tell us what was being transmitted and why

Don't know Peter and too busy to find out!
The new syntax changes have broken my code again, so focus has shifted. (Groundhog Day!)

We're sure getting good at porting P2 code!!