07 September 2011, 00:16 | #1 |
Registered User
Join Date: Aug 2008
Location: Salisbury
Posts: 744
|
ALWAYS test your code on real hardware!!
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 Last edited by h0ffman; 07 September 2011 at 00:17. Reason: more info |
07 September 2011, 01:24 | #2 |
Registered User
Join Date: Sep 2007
Location: Melbourne/Australia
Posts: 4,400
|
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.
|
07 September 2011, 01:35 | #3 | |
Registered User
Join Date: Jan 2010
Location: UK
Posts: 228
|
Quote:
|
|
07 September 2011, 07:24 | #4 |
Registered User
Join Date: Jan 2002
Location: Germany
Posts: 6,987
|
Mungwall and [winuae]enforcer exist for a reason...
|
07 September 2011, 08:08 | #5 |
gone
Join Date: Apr 2007
Location: completely gone
Posts: 1,596
|
@ 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. |
07 September 2011, 08:36 | #6 |
WinUAE developer
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 49
Posts: 26,510
|
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 |
07 September 2011, 08:44 | #7 |
Registered User
Join Date: Sep 2007
Location: Melbourne/Australia
Posts: 4,400
|
WinUAE also comes in very handy for RTG development as I don't have an RTG Amiga
|
07 September 2011, 08:53 | #8 |
gone
Join Date: Apr 2007
Location: completely gone
Posts: 1,596
|
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. |
07 September 2011, 09:49 | #9 |
68k
Join Date: Sep 2005
Location: Somewhere
Posts: 828
|
Hi,
@h0ffman about keyboard handling in your code: Did you use PORTS int ? Regards |
07 September 2011, 10:01 | #10 |
Registered User
Join Date: Aug 2008
Location: Salisbury
Posts: 744
|
This is the code block..
Code:
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 |
07 September 2011, 10:13 | #11 |
WinUAE developer
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 49
Posts: 26,510
|
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. Last edited by Toni Wilen; 07 September 2011 at 10:57. |
07 September 2011, 10:45 | #12 |
68k
Join Date: Sep 2005
Location: Somewhere
Posts: 828
|
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 Code:
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 Code:
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 Regards Last edited by Asman; 07 September 2011 at 10:49. Reason: change comment a bit (68020 --> 68020+ ) |
07 September 2011, 11:22 | #13 |
Registered User
Join Date: Aug 2008
Location: Salisbury
Posts: 744
|
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 |
07 September 2011, 14:20 | #14 |
Registered User
Join Date: Aug 2008
Location: Salisbury
Posts: 744
|
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 |
07 September 2011, 16:54 | #15 |
Registered User
Join Date: Mar 2008
Location: Las Vegas/Nevada
Posts: 103
|
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. |
07 September 2011, 19:59 | #16 |
Registered User
Join Date: Aug 2008
Location: Salisbury
Posts: 744
|
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!! |
17 September 2011, 17:25 | #17 | |
Join Date: Jul 2008
Location: Sweden
Posts: 2,269
|
Quote:
|
|
17 September 2011, 19:01 | #18 | |
WinUAE developer
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 49
Posts: 26,510
|
There is none, I remembered wrong.. again.
Quote:
|
|
17 September 2011, 22:57 | #19 |
Join Date: Jul 2008
Location: Sweden
Posts: 2,269
|
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.
|
18 September 2011, 09:08 | #20 |
WinUAE developer
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 49
Posts: 26,510
|
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
|
Currently Active Users Viewing This Thread: 1 (0 members and 1 guests) | |
Thread Tools | |
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
Netplay on real Amiga hardware? | lesta_smsc | support.Hardware | 3 | 04 December 2018 08:03 |
Mediator A1200 "Hardware ID code missing..." | Bamiga2002 | support.Hardware | 63 | 28 June 2013 20:30 |
Ambermoon Arcade - speed test (real hardware) | viddi | project.Amiga Game Factory | 26 | 18 November 2009 17:06 |
NTSC minimg question, test on a real Amiga required ! | FrenchShark | Coders. General | 5 | 25 December 2007 17:54 |
Problems with some installed games on real hardware | Daniel | support.Games | 0 | 20 February 2006 14:05 |
|
|