ALWAYS test your code on real hardware!!

[h0ffman]

So closing stages now for the music disk project which I started just under a year ago. All the loading bugs are fixed, solid as a rock now, you can even take the disk out the drive while its loading and it still recovers!!!....

However, I now have a bug in a hidden part!

Its a dead basic music selector using F keys. Tried it in all manner of WinUAE configs and works every time. Run it on real hardware and it allows me to select one tune then BAM!... gone!

Anyone ever experienced this kinda sh*t before!

----

I suppose it's worth mentioning that when it's running the system has been killed. Hardware is a stock A1200

[NovaCoder]

The reason I got a real Amiga again was because you don't get any real idea of performance using WinUAE. The only way to see how my code would run on an AGA 030 was to buy one myself.

[Amiga Forever]

The reason I got a real Amiga again was because you don't get any real idea of performance using WinUAE. The only way to see how my code would run on an AGA 030 was to buy one myself.

Good Points

[thomas]

Mungwall and [winuae]enforcer exist for a reason...

[pmc]

@ h0ffman - yes, is the short answer.

I've experienced differences with code running on the emulator versus the real thing several times.

First blitter line draw routine I did worked fine in the emulator, but glitched *one* and *only one* 3d object when run on the real thing. Very odd, never found out what the problem was - just recoded the line draw routine!

Also have (very) slight glitches on my Kefratraz bars routine when run on the real thing but they work totally fine in the emu.

The moral is just what you said - always test on the real thing before releasing anything cos you never know 100% if it'll work right or not.

[Toni Wilen]

It is important to note that features that can only do bad things (causing glitches or crashes for example) are not usually emulated because no one can use them for anything useful and are only accidentally triggered. This is the main "problem" (by design!) when developing under emulation.

Keyboard hanging and using own keyboard routine: 99.9% it is keyboard handshake bug.

Keyboard handshake emulation does not care about delay time (real keyboard does, some work even if it is very short, some need much longer handshake delay. Your code may even work perfectly fine on some other real hardware configuration.) because it will simply fix all quite common bad cpu loop keyboard handshake routines that would always break if cpu is too fast (68020+).

No one wants to have freezing keyboard = this does not need accurate emulation and won't cause programs to fail. (Or does someone really want to have keyboard type selection in configuration? )

btw, testing on single real hardware configuration only means it works 100% on _that_ real hardware configuration

[NovaCoder]

WinUAE also comes in very handy for RTG development as I don't have an RTG Amiga

[pmc]

I should add that what I posted was in no way a criticism of WinUAE - I accept 100% that there will be differences under the emulator versus my hardware configuration for exactly the reasons Toni stated.

These differences won't stop me developing in WinUAE though cos, for me at least, it's a hell of a lot faster and easier to do so.

[Asman]

Hi,

@h0ffman
about keyboard handling in your code:
Did you use PORTS int ?

Regards

[h0ffman]

This is the code block..

Selecta	moveq	#0,d0
	move.b	$bfec01,d0
	cmp.b	#$4d,d0
	blo.b	.quit
	cmp.b	#$5f,d0
	bgt.b	.quit
	btst	#0,d0
	beq.b	.quit
	
	sub.b	#$4d,d0
	add.w	d0,d0

;	jsr	P61_End

	lea	TuneList(pc),a0
	add.l	d0,a0
	move.l	(a0),a0
	lea	$0,a1
	moveq	#1,d0
	jsr	P61_Init

.quit	rts

TuneList	dc.l	_m10,_m09,_m08,_m07,_m06,_m05,_m04,_m03,_m02,_m01

[Toni Wilen]

That code is completely broken, sorry
Reading keyboard correctly isn't that simple. (Unfortunately proper way has never been officially documented anywhere)

Check that CIA-A serial port (SP) interrupt is set (or use ports interrupt), if set, read SDR, then set bit 6 in CIA-A CRA, wait at least ~70us, clear bit 6. (this is one method to handle handshake, there is also another one)

This tells keyboard micro controller that key code has been read and new code can be send.

EDIT: this works in emulation because it decides that program is stupid and lets next keycode through if handshake does not come soon enough.

[Asman]

Hi

@h0ffman

I guess that you can set PORTS int ($68) in proper way If not then give me a sign. Then int routine which I used for example to fix RollingThunder keyboard is

IntLvlTwoPorts:
		movem.l	d0-d1/a0-a2,-(a7)
	
		lea	_custom,a0
		move.w	intreqr(a0),d0
		btst	#INTB_PORTS,d0
		beq	.end
		
		lea	_ciaa,a1
		btst	#CIAICRB_SP,ciaicr(a1)
		beq	.end

	;read key and store him
		move.b	ciasdr(a1),d0
		or.b	#CIACRAF_SPMODE,ciacra(a1)
		not.b	d0
		ror.b	#1,d0
		spl	d1
		and.w	#$7f,d0
		lea	keys(pc),a2
		move.b	d1,(a2,d0.w)

	;handshake
		moveq	#3-1,d1
.wait1		move.b	vhposr(a0),d0
.wait2		cmp.b	vhposr(a0),d0
		beq	.wait2
		dbf	d1,.wait1

	;set input mode
		and.b	#~(CIACRAF_SPMODE),ciacra(a1)

.end		move.w	#INTF_PORTS,intreq(a0)
		tst.w	intreqr(a0)
		movem.l	(a7)+,d0-d1/a0-a2
		rte

keys: 		dcb.b $80,0

and then you can check key 'ESC' in following manner

KEY_ESC = $45
CheckKeyESC:
		lea	keys(pc),a0
		tst.b	KEY_ESC(a0)		;on 68020+ you can do tst.b keys+KEY_ESC(pc) instead of lea and tst
		beq	.exit
		;
		;key 'ESC' was pressed, insert some code here
		;
.exit		rts

For more details, please check WHDLoad dev package and look into keyboard.s file.

Regards

[h0ffman]

Cheers guys, will check these out. Should be quicker implementing a proper keyboard routine rather than re-coding the whole music selector to use the mouse!!

Will let you know how i get on...

Cheers

[h0ffman]

New keyboard handler implemented (even if it was a touch of CTRL+C / CTRL+V!!)

Fingers crossed it works on my A1200 when I get home.

Thanks again

[Siggy999]

I test my stuff on my real amiga regularly, just to make sure I'm doing things right. I've made mistakes in the past that emulation didn't mind - or my I had my settings cranked up to play something like frontier. It's saved me some headaches.

Speaking of headaches (and I mean this in the nicest possible way) I wish you'd had this happen a fortnight ago as I spent all that time pouring over documentation and example source code trying to nut out the (not easy to find and decypher) keyboard info for a key reading routine.

I got it sorted eventually, but now there are MUCH more elegant examples to draw from (thanks guys!).

Makes my code look rather pedestrian! I still have a lot to learn.

[h0ffman]

Whoooooop!!!! Working, thanks again guys

Funny though init, just when you think you've fixed everything, you notice something else... like your blit filler not quite reaching the edge of the screen!!

[Leffmann]

Originally Posted by Toni Wilen

That code is completely broken, sorry
Reading keyboard correctly isn't that simple. (Unfortunately proper way has never been officially documented anywhere)

Check that CIA-A serial port (SP) interrupt is set (or use ports interrupt), if set, read SDR, then set bit 6 in CIA-A CRA, wait at least ~70us, clear bit 6. (this is one method to handle handshake, there is also another one)

This tells keyboard micro controller that key code has been read and new code can be send.

EDIT: this works in emulation because it decides that program is stupid and lets next keycode through if handshake does not come soon enough.

What is the other method of handshaking? And do you know if the keyboard will drop any keys if you don't handshake within a certain amount of time, or if the handshake pulse lasts too long?

[Toni Wilen]

Originally Posted by Leffmann

What is the other method of handshaking?

There is none, I remembered wrong.. again.

And do you know if the keyboard will drop any keys if you don't handshake within a certain amount of time, or if the handshake pulse lasts too long?

Keyboard controller has small buffer (10 or so key codes), if buffer becomes full (=no handshakes received quickly enough), it simply stops buffering them and following keypresses or releases will be lost.

[Leffmann]

Originally Posted by Toni Wilen

Keyboard controller has small buffer (10 or so key codes), if buffer becomes full (=no handshakes received quickly enough), it simply stops buffering them and following keypresses or releases will be lost.

I'm asking because I see that key strokes go missing here (I've only tried WinUAE 2.3.2 so far) whenever I press or release two keys at the same time and poll manually every 20ms, but if I use the level 2 interrupt instead then everything works perfectly fine.

[Toni Wilen]

Originally Posted by Leffmann

I'm asking because I see that key strokes go missing here (I've only tried WinUAE 2.3.2 so far) whenever I press or release two keys at the same time and poll manually every 20ms, but if I use the level 2 interrupt instead then everything works perfectly fine.

Explained in previous reply. (No handshake quickly enough = next key code will be received) I think I'll change this, this behavior is from very early version of UAE, this really should be emulated better today