phaeron Posted May 25, 2013 Author Share Posted May 25, 2013 Hmm... not sure what to make of that. Definitely a missing byte, but not sure why. Do you have a test case I can look at? Otherwise, can you dump out ANTIC and display list state after this happens? This is done through the .antic and .dlhistory commands. I want to see if there is any DMA happening from that region. Quote Link to comment Share on other sites More sharing options...
willyvmm Posted May 25, 2013 Share Posted May 25, 2013 I prepared test case. Inside the rar file You will find everything that is neccessary to replicate bug. Please read test.txt to replicate bug. altirrabug.rar Quote Link to comment Share on other sites More sharing options...
phaeron Posted May 25, 2013 Author Share Posted May 25, 2013 This is indeed caused by a runaway display list pointing ANTIC into the $D5xx region. The missing byte was eaten by playfield DMA: Altirra> .dumpdlist BDEF: mode 9 @ 00CF BDF2: x13 blank 1 BDFF: mode.h 9 @ C900 BE02: mode.i F @ D500 BE05: mode.i F @ C900 BE08: x2 blank 1 BE0A: mode.i B @ 00D5 BE0D: blank.i 1 BE0E: mode.i.h 9 @ C900 BE11: mode.i F @ 5900 BE14: mode.i.h 9 @ 5642 BE17: mode.i 9 @ 00CF BE1A: x13 blank 1 BE27: mode.i.h 5 @ 4CD5 BE2A: mode B @ D5D5 BE2D: mode.i.h 5 @ D5D5 BE30: x2 mode.i.h 5 @ 4CD5 BE36: x2 mode B @ 4CD5 BE3C: mode B @ D5D5 BE3F: mode C @ 004B BE42: x454 blank 1 The reason for this appears to be a problem in the SIDE Loader's initialization prior to loading the executable. The program itself has an OK load pattern for its first segment: EXE: Loading program 0006-006F to BDD7-BE40 EXE: Loading program 0074-0078 to 02C4-02C8 EXE: Loading program 007D-0080 to B000-B003 EXE: Loading program 0085-0088 to 02E0-02E3 EXE: Jumping to B000 It overwrites part of the OS screen but does not overwrite the display list. The SIDE Loader, however, clears the entire screen area at $BC00-$BFFF without disabling display list DMA, causing the display list to cycle around that region; since the I flag is set, VBI stage 2 cannot reset the display list address back to SDLSTL/SDLSTH. This then allows ANTIC to start reading into the areas that the program has overwritten and then execute bogus LMS instructions to hit the IDE hardware. My recommendation would be to clear only up to MEMTOP after reopening Gr.0. This allows Lasermania to load with the SIDE Loader. 1 Quote Link to comment Share on other sites More sharing options...
willyvmm Posted May 26, 2013 Share Posted May 26, 2013 Thanks for explanation. That makes sense now Quote Link to comment Share on other sites More sharing options...
phaeron Posted May 29, 2013 Author Share Posted May 29, 2013 Small update with a number of fixes to floating-point handling: http://www.virtualdub.org/beta/Altirra-2.40-test4.zip http://www.virtualdub.org/beta/Altirra-2.40-test4-src.zip This fixes a couple of issues with the floating-point acceleration feature and a lot of issues with the LLE OS's mathpack, enough to get the Ahl benchmark working. (Researching accurate series expansions for LOG and EXP sucks, btw.) 2 Quote Link to comment Share on other sites More sharing options...
Xuel Posted May 29, 2013 Share Posted May 29, 2013 phaeron, any chance you could fix the alignment of the ANTIC visualization (Shift-F8) when Extended PAL Height is enabled? Quote Link to comment Share on other sites More sharing options...
morelenmir Posted May 30, 2013 Share Posted May 30, 2013 Would it be possible to have the H7-H9 host device deal with the unicode BOM in text files? In fact, I have never considered before how Altirra handles utf8 input! Presumably it doesn't? Quote Link to comment Share on other sites More sharing options...
drac030 Posted May 30, 2013 Share Posted May 30, 2013 Many bug fixes to 65C816 emulation. In particular, cross-bank indexing is now emulated, which is a major cause of 65C816-incompatible code that uses only legal 6502 opcodes. I can see that enabling 65C816 emulation also enables a 256k "linear" RAM space. It seems to me that this amount is fixed an cannot be changed. If so, could you make this configurable or at least enlarge the fixed amount to 1 MB? Quote Link to comment Share on other sites More sharing options...
morelenmir Posted May 31, 2013 Share Posted May 31, 2013 (edited) I have a - reasonable I think! - feature request for Avery, Could you please make read-only/read-write to be 'per drive' in the 'Host Device' settings. I have now twice accidentally overwritten a text source it has taken me over an hour to type in. Being able to set the individual drives as read-only would make this carelessness on my part impossible. A maybe less reasonable request is that Altirra remember the size of its window.when in debugging mode My reason for this is to remove the moderately irritating necessity to drag up the main window when the extra debugging panels are present and then 'Adjust Window Size' it back down when you are finished. Not world shattering, but definitely a 4 on the irritometer! Edited May 31, 2013 by morelenmir Quote Link to comment Share on other sites More sharing options...
phaeron Posted May 31, 2013 Author Share Posted May 31, 2013 Turned out there was an ugly bug in the MMU that caused all of the 65C816 high pages to alias together, so here's a fixed and more configurable version: http://www.virtualdub.org/beta/Altirra-2.40-test5.zip http://www.virtualdub.org/beta/Altirra-2.40-test5-src.zip I've also fixed the ANTIC visualization. Having a UTF-8 BOM in a file you're exchanging via H: is odd, as there's no point in writing a BOM for a file that's 7-bit clean, and anything that's non-ASCII had better be ATASCII or it's just going to be garbage to the Atari. Altirra currently doesn't deal with Unicode in files on H: at all and simply passes through all bytes except for EOL bytes, which are translated if on H6-H9:. I'm not sure I want to deal with whether the code point U+25E2 should map to Ctrl+H. You can undock all of the debugger panes from the main window to achieve something similar to what you're looking for. The main restriction is that you cannot stack undocked panes. 2 Quote Link to comment Share on other sites More sharing options...
drac030 Posted May 31, 2013 Share Posted May 31, 2013 Thanks a lot. In meantime I found a bug in 65C816 CPU emulation: Altirra thinks that TYX (opcode $BB) is an illegal instruction. Quote Link to comment Share on other sites More sharing options...
morelenmir Posted May 31, 2013 Share Posted May 31, 2013 Fair enough. I have used unicode for all my text files since quite a few years now - but I think I see what you mean Avery, Basically if a text file does not contain any characters above the standard ASCII set then it doesn't need a BOM. I think the reason I have been getting one is because I have set EditPad to include one by default. It is easy to overcome this however and I have now set assembler source to be windows 1252 encoded. Is the per drive RO/RW settings a possible though? Quote Link to comment Share on other sites More sharing options...
serj Posted May 31, 2013 Share Posted May 31, 2013 Thanks for the update, Avery. glad that the emulator is getting better and better. I want to ask what kind of compatibility with processors "6502C" and "65C816"? I have noticed that some games refuse to work under the processor "65C816". such as playing "River raid" refuses to run. and in the game "Alley cat" on the screen c rubbish bins is distorted and fuzzy images. this is the way it should be or is it an error in emulation? Quote Link to comment Share on other sites More sharing options...
drac030 Posted May 31, 2013 Share Posted May 31, 2013 The compatibility is good as long as programs are cleanly written, i.e. without the use of illegal 6502 opcodes. Surprisingly, the vast majority of Atari programs are clean in this respect. Some list is here: http://drac030.krap.pl/en-kompatybilnosc.php Since this list has been put together, some programs listed as incompatible have been revindicated to the proper side and are now running on 65C816. These are: 1) http://drac030.krap.pl/alley_cat_816.zip Alley Cat (of course, also runs on 6502) 2) http://drac030.krap.pl/open-inspektor-updated.arc Inspektor River Raid works on 65C816 here. Quote Link to comment Share on other sites More sharing options...
serj Posted May 31, 2013 Share Posted May 31, 2013 (edited) and even so, is not working correctly. apparently this is a bug in the emulator. See the video: Edited May 31, 2013 by serj 1 Quote Link to comment Share on other sites More sharing options...
phaeron Posted June 1, 2013 Author Share Posted June 1, 2013 65C816 fixes: http://www.virtualdub.org/beta/Altirra-2.40-test6.zip http://www.virtualdub.org/beta/Altirra-2.40-test6-src.zip The issue with Alley Cat was that the JMP (abs) instruction was running too fast in 65C816 mode, which caused one of the DLIs to hit HSCROL too early. Interestingly, this means that while this particular build of Alley Cat is 65C816 compatible, it isn't accelerator compatible. Re: individual read/write on H: devices -- sorry, leaning no at the moment since it's a lot of UI work. Also, why are you assembling in emulation instead of cross assembling?? Quote Link to comment Share on other sites More sharing options...
Shannon Posted June 1, 2013 Share Posted June 1, 2013 Got a question about frame blending... Is it essentially some form of filter? Or is it blending two frames into one (thus half the normal updates per second)? Hope my question makes sense... Quote Link to comment Share on other sites More sharing options...
serj Posted June 1, 2013 Share Posted June 1, 2013 (edited) not disappear from the screen explosions in the game "Gyruss", the effect is observed only when "65C816". when choosing processor "6502C" this effect is not observed. error in the emulation. Edited June 1, 2013 by serj Quote Link to comment Share on other sites More sharing options...
phaeron Posted June 1, 2013 Author Share Posted June 1, 2013 Frame blending blends current frame with previous. You still get 50/60 fps, but with blur between frames. If a frame drop occurs, display doesn't resume until two frames later so you never see an unblended frame. Tried Gyruss in both 6502 and 65C816 modes, and I'm afraid I can't see a difference -- you'll have to describe in more detail or post a screenshot. The game also doesn't appear to use any undocumented 6502 instructions. Quote Link to comment Share on other sites More sharing options...
serj Posted June 1, 2013 Share Posted June 1, 2013 (edited) Video of the current display error. and a screenshot of the error. Edited June 1, 2013 by serj Quote Link to comment Share on other sites More sharing options...
morelenmir Posted June 1, 2013 Share Posted June 1, 2013 (edited) Because I don't actually know what 'cross-assembling' means!! I take your point about the ui work... I can sort of envisage what would be required, but that sort of thing can be fiddly. And as a general point to anyone interested. I have FINALLY worked out how to clear the printer screen. Assign 'Toggle Debugger' to an easy to reach F key and then just a quick double press before each print. A clean page each time! An update - Ahhhh... Cross assembling is to use a native windows tool that will produce object code that can be used inside Altirra. Certainly interesting! A quick look at a few assemblers for 6502 seems to find mainly DOS ones though. I don't suppose anyone has translated the assembler editor into a windows binart have they? That would be cool. Edited June 1, 2013 by morelenmir Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted June 1, 2013 Share Posted June 1, 2013 You could set up an IDE which transparently calls the assembler (which by nature will usually be command line based). I use Eclipse and WUDSN with the MADS assembler, and it's easy to set up. Quote Link to comment Share on other sites More sharing options...
morelenmir Posted June 1, 2013 Share Posted June 1, 2013 ATasm sounds a likely cross-assembler, although I have studiously avoided the mac/65 assembler!!! In 'Atari Roots' it managed to sound simultaneously very complicated AND cheating to use .SBYTE! Is ATasm what most people recommend? I was joking earlier when I suggested a windows version of 'Assembler Editor' but I don't suppose there actually is one by any chance? Has anyone put together a tutorial document for using Altirra's built-in debugger? I would prefer to use it rather than 'BUG', but got a little lost in the help file! Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted June 1, 2013 Share Posted June 1, 2013 Atasm has the annoying quirk of stopping on the first error so it can be a monumental pain clearing out compilation errors on a newly imported project. For that reason alone I can't recommend it. MADS is only complex when you need it to be. No cheating in use of .SBYTE, either... Directives like those are valuable tools. Quote Link to comment Share on other sites More sharing options...
drac030 Posted June 1, 2013 Share Posted June 1, 2013 (edited) There seems to be a problem with 16-bit X register in native mode. This code: clc xce rep #$10 .iw ldx #$0000 loop: inx bpl loop stx $0600 sep #$10 .ib sec xce rts stores $0080 instead of $8000 at $0600, i.e. the loop stops after 128 iterations instead of going up to 32768 iterations. When the Y register is used instead, the result seems correct. Edited June 1, 2013 by drac030 Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.