Jump to content
IGNORED

Altirra 2.30 released


phaeron

Recommended Posts

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.

Link to comment
Share on other sites

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.

  • Like 1
Link to comment
Share on other sites

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.)

  • Like 2
Link to comment
Share on other sites

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?

Link to comment
Share on other sites

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 by morelenmir
Link to comment
Share on other sites

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.

  • Like 2
Link to comment
Share on other sites

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?

Link to comment
Share on other sites

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?

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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??

Link to comment
Share on other sites

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 by serj
Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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 by morelenmir
Link to comment
Share on other sites

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!

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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 by drac030
Link to comment
Share on other sites

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.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...