Jump to content
IGNORED

Altirra 2.40 Final out..


Mclaneinc

Recommended Posts

Thanks for the final, hoping to see some nice additions to the new version and maybe some of those silly throw away ideas :)

 

As said, thank you Avery / Phaeron for this wonderful emulator...

 

http://virtualdub.org/altirra.html

 

Previous links failed to allow download away from page.(cheers Miker)

 

[features added]

65C816: Optimized mode switches.
Audio: Added drive sound volume level option.
Cartridge: Added support for .CAR types 53-59 (2K, 4K, right-as-left 8K, right slot 4K, 128-512K SIC!).
CPU: Preliminary support for accelerated 65C816 operation.
Debugger: Added .dmabuf command.
Debugger: Added %e, %f, and %g formats to .printf command.
Debugger: Verifier can now detect 64K address space index wrapping and abnormal DMA conditions.
Debugger: Added fbx (fill bytes with expression) command.
Debugger: r (register) command now allows access to 65C816 registers.
Disk: Added "Extract Boot Sectors" command to disk dialog for use with bootable virtual disks.
LLE: Added PBI device interrupt support.
MMU: High (65C816) memory can now be adjusted from 0KB-4032KB.
Profiler: Added 65C816 support.
Recorder: Added .WAV file audio recording.
Recorder: Added option for encoding duplicate frames as full frames.
UI: Added on-screen indicators for console buttons held on startup.
UI: Added on-screen indication for some view mode changes.
UI: Added support for per-monitor DPI scaling in Windows 8.1.
UI: Added custom debug font dialog for half point sizes.
UI: File > Exit now confirms if there are modified images.
XEP80: Initial support.

[bugs fixed]

5200: Floating data bus is now enabled in 5200 mode.
65C816: Fixed cycle timing for JMP (abs) instruction.
65C816: Fixed cycle timing for TXY instruction.
65C816: Fixed TYX instruction.
65C816: INX was checking M bit instead of X bit.
65C816: Read/modify/write instructions now do read/write/write in emulation mode.
65C816: Fixed (dp), (dp,X), and (dp,Y) behavior with DP!=0.
ANTIC: Disabling playfield DMA after playfield start now reads bus data into the line buffer.
ANTIC: Abnormal playfield DMA is now emulated.
ANTIC: Improved precision of CHACTL changes.
Cartridge: Fixed $BFxx reading with 5200 64K cartridge type.
CPU: Illegal instruction option now saves correctly.
Debugger: Display float (df) command displays all ten significant digits.
Debugger: Fixed LLE kernel ROM auto-reload and symbol load option.
Debugger: UI panels are now more consistent with debugger commands in numeric base handling.
Debugger: Fixed incorrect disassembly on step when running from high banks.
GTIA: Fixed bug with VDELAY on missiles.
GTIA: Fixed regression with hires player-playfield collisions (since 2.30).
LLE: Fixes and optimizations to math pack.
LLE: Decimal flag is now cleared before dispatching IRQs.
LLE: Fixed BRK handler to handle stack wrapping.
LLE: 5200 BIOS now strobes NMIRES for DLIs.
LLE: Fixed CIOINV timing so that emulated CIO hooks work.
LLE: Corrected K: debounce logic and E: AUX2 open handling (fixes Action! with LLE firmware).
HLE: Fixes to math pack acceleration.
HLE: Added partial fix for CDTMA1 during accelerated disk reads (fixes Ankh with SIO patch enabled).
IDE: Fixed value of Sector Count register after READ SECTOR and WRITE SECTOR commands.
MMU: Fixed aliasing of high memory banks.
POKEY: SKSTAT bit 1 is now emulated.
Printer: Emulated P: device now supports the PUT CHARS command with len=0.
Serial: Emulated R: device supports break interrupts.
UI: Fixed GDI handle leak in text editor.
UI: Added workaround for set file associations dialog not appearing on Windows 8.
UI: Fixed ANTIC DMA visualization mode with extended PAL height.
UI: Fixed PCLink indicator not updating.
U1MB: Fixed PIA read decoding to only respond to $D300-D37F (unfixes Bounty Bob Strikes Back!).

Edited by Mclaneinc
  • Like 5
Link to comment
Share on other sites

I reported the news on websites emucr.com and t2e.pl
but here I did not spread the news, I thought that Avery appears and report as always.

 

in any case, thanks for updating the best Atari emulator, Avery.
and thank you, paul for what was ahead of me.

Edited by serj
Link to comment
Share on other sites

I knew you had added it to emucr.com as you mentioned it before, I just added it because avery rarely posts about a final, keep warm where you are Sergey, I bet its a bit cold there :)

 

Either way its out and been seen...

 

Now lets hope all our silly bits are added :)

Edited by Mclaneinc
Link to comment
Share on other sites

Well, time to start the 2.50 test series, then I guess:

 

http://www.virtualdub.org/beta/Altirra-2.50-test1.zip

http://www.virtualdub.org/beta/Altirra-2.50-test1-src.zip

 

Contains more 65C816 fixes, a POKEY pot emulation fix, improvements to input handling, some debugger additions, and DragonCart support.

 

Note that the DragonCart support is currently pretty raw. For various reasons, Altirra runs a gateway on the emulation network that does NAT, so incoming connections and pings don't work. The built-in TCP/IP stack is also still incomplete and is missing some features like IP fragment handling and TCP urgent data. However, there is built-in tcpdump-style logging.

  • Like 4
Link to comment
Share on other sites

Shift+F8 PAL crash fixed:

http://www.virtualdub.org/beta/Altirra-2.50-test2.zip

http://www.virtualdub.org/beta/Altirra-2.50-test2-src.zip

 

The DragonCart emulation does support DHCP, but there is a gotcha: you can't use it if there is a cartridge conflict. In particular, it won't work if you boot SpartaDOS X from a MaxFlash cartridge because the MaxFlash banking registers conflict with the DragonCart registers. Cartridges with SDX 64K/128K banking should work, as well as using a non-cartridge based DOS like Atari DOS or SpartaDOS 3.2. Assuming everything is set up, DHCPTEST.COM should work successfully:

 

post-16457-0-34230800-1384029571_thumb.png

 

Note that the network address set up in the DragonCart emulation configuration should not be the same as your real network address. This subset is for an emulated network that is bridged onto your real network. If they are the same, you will not be able to connect to any machines on your real local network. The emulated gateway is always at the x.x.x.1 address, which is 192.168.0.1 with the default 192.168.0.0/255.255.255.0 settings. If you have services running on your local computer, they can be accessed by connecting to the gateway as those will be redirected to localhost, except for DNS which is redirected to your primary DNS server.

 

If everything is set up correctly, you should then be able to telnet out, which will give traffic log messages like this in the debugger:

CS8900AN: Sending 292 byte frame: 00:00:36:00:00:01 > FF:FF:FF:FF:FF:FF | ipv4 0.0.0.0:68 > 255.255.255.255:67 udp len 257
CS8900AN: Receiving 301 byte frame: 02:00:00:00:00:01 > FF:FF:FF:FF:FF:FF | ipv4 255.255.255.255:67 > 255.255.255.255:68 udp len 279
CS8900AN: Sending 298 byte frame: 00:00:36:00:00:01 > FF:FF:FF:FF:FF:FF | ipv4 192.168.0.101:68 > 255.255.255.255:67 udp len 264
CS8900AN: Receiving 271 byte frame: 02:00:00:00:00:01 > 00:00:00:00:00:00 | ipv4 255.255.255.255:67 > 0.0.0.0:68 udp len 249
CS8900AN: Sending 42 byte frame: 00:00:36:00:00:01 > FF:FF:FF:FF:FF:FF | arp where is 192.168.0.1
CS8900AN: Receiving 30 byte frame: 02:00:00:00:00:01 > 00:00:36:00:00:01 | arp 192.168.0.1 is at 02:00:00:00:00:01
CS8900AN: Sending 72 byte frame: 00:00:36:00:00:01 > 02:00:00:00:00:01 | ipv4 192.168.0.101:24885 > 192.168.0.1:53 udp len 37
CS8900AN: Receiving 75 byte frame: 02:00:00:00:00:01 > 00:00:36:00:00:01 | ipv4 192.168.0.1:53 > 192.168.0.101:24885 udp len 53
CS8900AN: Sending 54 byte frame: 00:00:36:00:00:01 > 02:00:00:00:00:01 | ipv4 192.168.0.101:14615 > 93.184.216.119:80 tcp S 1277165568:1277165568(0) win 4096
CS8900AN: Receiving 42 byte frame: 02:00:00:00:00:01 > 00:00:36:00:00:01 | ipv4 93.184.216.119:80 > 192.168.0.101:14615 tcp S 1:1(0) ack 1277165569 win 32768
CS8900AN: Sending 54 byte frame: 00:00:36:00:00:01 > 02:00:00:00:00:01 | ipv4 192.168.0.101:14615 > 93.184.216.119:80 tcp . 0:0(0) ack 2 win 4096
CS8900AN: Sending 54 byte frame: 00:00:36:00:00:01 > 02:00:00:00:00:01 | ipv4 192.168.0.101:14615 > 93.184.216.119:80 tcp . 1277165569:1277165569(0) ack 2 win 4096
CS8900AN: Sending 56 byte frame: 00:00:36:00:00:01 > 02:00:00:00:00:01 | ipv4 192.168.0.101:14615 > 93.184.216.119:80 tcp P 1277165569:1277165570(1) ack 2 win 4096
CS8900AN: Receiving 42 byte frame: 02:00:00:00:00:01 > 00:00:36:00:00:01 | ipv4 93.184.216.119:80 > 192.168.0.101:14615 tcp . 2:2(0) ack 1277165570 win 32768
CS8900AN: Sending 56 byte frame: 00:00:36:00:00:01 > 02:00:00:00:00:01 | ipv4 192.168.0.101:14615 > 93.184.216.119:80 tcp P 1277165570:1277165571(1) ack 2 win 4096
CS8900AN: Receiving 42 byte frame: 02:00:00:00:00:01 > 00:00:36:00:00:01 | ipv4 93.184.216.119:80 > 192.168.0.101:14615 tcp . 2:2(0) ack 1277165571 win 32768
CS8900AN: Sending 56 byte frame: 00:00:36:00:00:01 > 02:00:00:00:00:01 | ipv4 192.168.0.101:14615 > 93.184.216.119:80 tcp P 1277165571:1277165572(1) ack 2 win 4096
CS8900AN: Receiving 42 byte frame: 02:00:00:00:00:01 > 00:00:36:00:00:01 | ipv4 93.184.216.119:80 > 192.168.0.101:14615 tcp . 2:2(0) ack 1277165572 win 32768
CS8900AN: Receiving 151 byte frame: 02:00:00:00:00:01 > 00:00:36:00:00:01 | ipv4 93.184.216.119:80 > 192.168.0.101:14615 tcp F 2:111(109) ack 1277165572 win 32768
CS8900AN: Sending 54 byte frame: 00:00:36:00:00:01 > 02:00:00:00:00:01 | ipv4 192.168.0.101:14615 > 93.184.216.119:80 tcp . 1277165572:1277165572(0) ack 111 win 4096
CS8900AN: Sending 56 byte frame: 00:00:36:00:00:01 > 02:00:00:00:00:01 | ipv4 192.168.0.101:14615 > 93.184.216.119:80 tcp P 1277165572:1277165573(1) ack 111 win 4096
CS8900AN: Receiving 42 byte frame: 02:00:00:00:00:01 > 00:00:36:00:00:01 | ipv4 93.184.216.119:80 > 192.168.0.101:14615 tcp . 112:112(0) ack 1277165573 win 32768
CS8900AN: Sending 54 byte frame: 00:00:36:00:00:01 > 02:00:00:00:00:01 | ipv4 192.168.0.101:14615 > 93.184.216.119:80 tcp . 1277165573:1277165573(0) ack 111 win 4096
CS8900AN: Receiving 42 byte frame: 02:00:00:00:00:01 > 00:00:36:00:00:01 | ipv4 93.184.216.119:80 > 192.168.0.101:14615 tcp F 111:111(0) ack 1277165573 win 32768
CS8900AN: Sending 54 byte frame: 00:00:36:00:00:01 > 02:00:00:00:00:01 | ipv4 192.168.0.101:14615 > 93.184.216.119:80 tcp . 1277165573:1277165573(0) ack 112 win 4096
CS8900AN: Receiving 42 byte frame: 02:00:00:00:00:01 > 00:00:36:00:00:01 | ipv4 93.184.216.119:80 > 192.168.0.101:14615 tcp . 112:112(0) ack 1277165573 win 32768

I have seen cases where IP65 will mysteriously send ARP requests for addresses outside the local subnet instead of going through the gateway. If this happens, switching to another network address usually fixes it. No idea what causes this yet. PING.COM will not work yet as ICMP echo is not supported by the IP stack.

 

If you are running a stack that uses hardcoded network settings instead of DHCP, like a Contiki distribution, make sure the network/netmask settings match what Contiki was built with. If everything is set up correctly, the web browser should work. The FTP tool will not, as the NAT currently doesn't support non-passive FTP connections. I have gotten the IRC client to work, but it's a very rough experience.

 

Link to comment
Share on other sites

Altirra 2.5 Test 1 now has new descriptions on EmuCR. Yeah!

 

Before: "Altirra 2.4 Test 21 is released. Altirra is an Atari 8 bit Emulator on the Windows/DOS platform. Altirra emulates several models of the 8-bit Atari computers. This includes the the 800, 800XL, and 130XE versions. It has a lot of options, and compatibility is decent especially given the emulator's early stages. It also supports some copy protected games properly in emulation."

 

http://www.emucr.com/2013/10/altirra-24-test-21.html

 

Now: "Altirra 2.5 Test 1 is released. Altirra is an Atari 8 bit Emulator on the Windows/DOS platform. Altirra emulates several models of the 8-bit Atari computers. This includes the the 800, 800XL, and 130XE versions. Altirra is quite matured now, and IMO, the best Atari Emu currently! It also supports some copy protected games properly in emulation."

 

http://www.emucr.com/2013/11/altirra-25-test-1.html

Edited by atx4us
Link to comment
Share on other sites

I have a few bug reports..

H: handler (1): When opening a file in append mode (aux1=9) if the file doesn't exist a File Not Found error (170) is returned; the correct behavior is that a blank file should be created and no error is returned.

H: handler (2): In MyDOS, attempting to copy a file from H: to an emulated D: drive fails with Error 165. There is no problem accessing the file, I can even drop to BASIC and write a program that will copy the same file, but MyDOS won't do it.

R: handler: The R: device completely dies if you make an outbound connection then cold-start while still connected. The only workaround I've found is to quit and reopen Altirra.

 

There are also a couple of requests I made in the 2.3 thread, which I'm not sure if you've seen. I am quoting that message below.

 

Thank you once again for an incredible emulator!

Hi Phaeron,

Thanks for fixing the P: handler.

I have a couple of requests regarding the R: emulation. These are basically issues I'm running into while working on Ice-T.

If "Emulate Telnet protocol" is disabled, I expect the R: device to be able to send and receive any data transparently. However this is not the case: while the emulated Atari can receive any byte, it cannot send out a 0xFF.

As for the Telnet emulation, I wish it could be improved a bit. First, it doesn't identify as a terminal type (there ought to be a drop-down like in APE with the options "Do not identify", "VT-52", "VT-100", "VT-102", "ANSI"). As a result of this, when Telnetting to a Linux shell various programs refuse to run (such as Emacs) unless you set the terminal type manually (e.g. export TERM=vt102). See below for a reference on how this negotiation looks like.

Another problem with the Telnet emulation is that it doesn't handle escape sequences properly; for example if the host sends the sequence FF FF the Atari is supposed to receive just an FF, and if the second byte is anything else then it should be interpreted as a command (which can probably safely be ignored, but the Atari isn't supposed to receive anything). Also apparently if the Atari sends a FF it should be translated to FF FF. As a result of this problem, occasional garbage characters are received and file transfers such as Xmodem (which require 8-bit transparency) fail. I've tried other Telnet clients such as Tera Term and had no problems so this is definitely solvable at the Telnet level.

Here is a dump (with some commentary) of Altirra's and APE's initial Telnet negotiation with a Ubuntu host, where Altirra refuses to identify and APE identifies as VT100.

Telnet Negotiation on Altirra:

Ubuntu:  ff fd 18  ff fd 20  ff fd 23  ff fd 27
	Start use: term type, term speed, X location, env.option
Altirra: ff fc 18  ff fc 20  ff fc 23  ff fc 27             
	Won't use any of the above
Ubuntu:  ff fb 03  ff fd 01  ff fd 1f  ff fb 05  ff fd 21
	Will use Supress GA, Start use Echo, 1f. Will use 05, Start use 21.
Altirra: ff fd 03  ff fc 01  ff fc 1f  ff fe 05  ff fc 21
	Start use Supress GA, Won't use Echo, 1f. Stop use 05. Won't use 21.
Ubuntu:  ff fb 01                                         
	Will use Echo.
Altirra: ff fd 01            
	Start use Echo.

Telnet Negotiation on APE:

Ubuntu:  ff fd 18  ff fd 20  ff fd 23  ff fd 27            
	Start use: term type, term speed, X location, env.option
APE:     ff fb 18  ff fc 20  ff fc 23  ff fc 27                                                
	Will use term type. Won't use any of the others.
Ubuntu:  ff fa 18 01 ff f0
	Subnegotiate Term type, 1, end subnegotiation
APE:     ff fa 18 00 56 54 31 30 30 ff f0           
	Subnegotiate Term type, 0, "VT100", end subnegotiation
Ubuntu:  ff fb 03  ff fd 01  ff fd 1f  ff fb 05  ff fd 21
	Will use Supress GA, Start use Echo, 1f. Will use 05, Start use 21.
APE:     ff fd 03  ff fc 1f  ff fe 05  ff fc 21
	Start use Supress GA, Won't use 1f, Stop use 05, Won't use 21
Ubuntu:  ff fb 01                                         
	Will use Echo.
APE:     ff fd 01                                         
	Start use Echo.

Thank you!

 

Link to comment
Share on other sites

Feature Request:

When a crash is detected, an option is supplied so that error information is sent to you Phaeron. This may include a copy of all the settings, the emulator version, the programs in memory / disks loaded etc. It would need permission to send you the information, and if the net is available from the machine running the emulator, it sends all the details to you.

 

You can then filter according to the latest version and then be able to categorise the issues.

Link to comment
Share on other sites

Altirra 2.5 Test 1 now has new descriptions on EmuCR. Yeah!

 

Before: "Altirra 2.4 Test 21 is released. Altirra is an Atari 8 bit Emulator on the Windows/DOS platform. Altirra emulates several models of the 8-bit Atari computers. This includes the the 800, 800XL, and 130XE versions. It has a lot of options, and compatibility is decent especially given the emulator's early stages. It also supports some copy protected games properly in emulation."

 

http://www.emucr.com/2013/10/altirra-24-test-21.html

 

Now: "Altirra 2.5 Test 1 is released. Altirra is an Atari 8 bit Emulator on the Windows/DOS platform. Altirra emulates several models of the 8-bit Atari computers. This includes the the 800, 800XL, and 130XE versions. Altirra is quite matured now, and IMO, the best Atari Emu currently! It also supports some copy protected games properly in emulation."

 

http://www.emucr.com/2013/11/altirra-25-test-1.html

 

Is there an Atari section in that website, couldn't find atari in the category lists.

Edited by atari8warez
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...