Jump to content
IGNORED

Altirra 2.60 released


phaeron

Recommended Posts

I've just released version 2.60 final of my emulator, Altirra:

 

http://virtualdub.org/altirra.html

 

This is nearly identical to the last 2.60-test release and supercedes all such test releases. Those who have been following the test releases already know what's in it, but highlights since 2.50:

  • UI: New full-screen UI (double click on the left side), new device tree UI, new firmware image UI, and improved high DPI support. Support for rotating disk images between drives and quick-cycling input maps from the keyboard.
  • Display: Vertical overscan can now be controlled independently, full screen mode is saved, improved quality of NTSC antialiasing modes, and improved vsync lock when running in windowed mode.
  • Firmware: Many bug fixes to built-in OS and BASIC.
  • Devices: New device infrastructure allowing for much better device extensibility internally. Added emulation support for BlackBox, MIO, SX212 modem, MidiMate, clock devices, and 820 printer. Enhanced 1030 modem emulation support with full software T: handler and bootstrap support. Added new Additions disk containing supporting software. Extended write support to more disk image formats.
  • Emulation: NTSC-50/PAL-60 support, more realistic power-on DRAM patterns, CPU/ANTIC/POKEY/GTIA emulation fixes, HLE acceleration fixes. HLE devices like H: can now be hot-added or removed without requiring a system reset.
  • Debugger: Added one-shot breakpoints, return tracepoints, temporary variables, new memory randomization modes to detect uninitialized memory access bugs, and new BASIC commands.

Now that 2.60 final is out, I can also start the 2.70 test release line:

 

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

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

  • Rewritten SIO burst I/O implementation. Burst writes are now supported, and there is no longer a need for separate interrupt-driven and polled burst modes.
  • Display optimizations. Fixed a rather dumb unnecessary framebuffer clearing bug, and optimized the NTSC artifacting routine. NTSC artifacting should now have minimal CPU cost.
  • Veronica cartridge emulation. Note that debugger support for this is pretty minimal -- you will need to use the ~0s and ~1s commands to switch CPUs and most commands do not support the alternate CPU yet. Disassembly and register dumping works, but there is no support for breakpoints, execution control, or history yet.

As usual, thanks to everyone for the testing, suggestions, bug reports, and support.

 

  • Like 25
Link to comment
Share on other sites

Super. Thank you so much for all of your time and effort. Due to your hard work, more people are on the scene because so many people cannot get to real hardware.

 

The quality of your product is top notch and when there are issues, you correct them quickly.

 

You are what I term an "enabler". You do the hard work to enable others to do their work. People like yourself are vital on the Atari scene and if I was a rich man, I'd send you some of my wealth.

  • Like 5
Link to comment
Share on other sites

Clicking on the Altirra icon is like flipping the power switch on my old (and long gone) 400/800. In many respects it is better because I don't have to maintain it or allocate loads of physical real-world space for it and all the other consoles I enjoy through the magic of emulation. All I have to do is maintain 1 machine - the host. And all the emulated ones fall into place. If one works, all work!

 

Going through the options menus is akin to swapping hardware and trying new features on different machines. The faster processors, the add-on boards, the drives..

 

And organizing all the disk, tape, and cart images is not unlike filling wallspace with holders and cubbyholes and shelves.

 

Emulation is indeed magic, there's enough mystery (to me) that I can enjoy it like a kid would.

  • Like 3
Link to comment
Share on other sites

Avery, thanks for the new version of best emulator.

 

I found a mistake that leads to the collapse of the emulator.

run the emulator, go to the settings

 

Tools ---> Disk Explorer

 

in the window "disk explorer" press the right mouse button.

  • Like 1
Link to comment
Share on other sites

BRK is a two-byte opcode. Change it to what and for why?

 

Yes, that had me thinking as well, I'm no coding genius but I looked at the request and a virtual question mark appeared on top of my head, I thought I'd missed some basic coding?

Link to comment
Share on other sites

Just a huge thank you to Avery, played around with the Veronica cart and its amazing that you were just able to emulate it so quickly, you have done this with so many other devices..Superb work.

 

I read the Veronica thread and just said wow to myself, your knowledge of all things computer / electronics is just PHENOMENAL...

 

You don't fancy rewriting MAME so it runs more recent games at a decent speed :)

 

I jest of course..

 

Hopefully people will support Veronica and VBXE a little more in the future, they offer good programmers such amazing possibilities it would be a shame to see them so under used. Maybe a VBXE / Veronica coding competition would be useful. Obviously I say this with next to no coding ability and zero free time myself so its only a suggestion that would be nice to see happen at some point.

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

Avery, Thank you for this awesome emulator.

 

Question: The new OS ROM management, version 2.6 won't load the Omniview OS, just a black screen. Same ROM image has worked fine on all previous versions of Altirra. Is there some CRC issue, maybe something it won't recognize?

  • Like 1
Link to comment
Share on other sites

Hello phaeron,

 

Thanks for the final release 2,60 and all so the beta 2,70 i like altirra from begin , the number 1 of (the best) of the world.

 

Greetings Marco

 

 

 

I have checked the error disk explore right mouse pressed when no file is selected this is happen from altirra 2.60 test 32 to the latest version you can check this from the link: http://www.virtualdub.org/beta/Altirra-2.60-test31.zip

 

2.60 test 31 works fine.

 

Maybe this wil help phaeron seach the error.

Edited by marcokitt2000
Link to comment
Share on other sites

Since 2.70 is in the early stages already, what do you think about adding 3 things to the user interface?

 

1- The ability to "load" various iterations of the altirra.ini file from within the emulator? This would allow for in-emulator changing of the configuration. By default the emulator would need to be reset and start from the beginning when a configuration is selected or changed. That's a given. Like we don't pull ram boards out of powered-up machines! There would be 10 or 20 slots, and each slot would be pointing to a custom configuration (stored in the altirra-x.ini) with user-definable text for a name. Like so:

 

1- Boot into Star Raiders 400/800 (altirra1.ini)

2- Boot into MemoPad (altirra2.ini)

3- Basic cartridge only, no disk drive (altirra3.ini)

4- 600xl/800xl + 2 810 drives + stereo pokey (altirra4.ini)

 

Sort of like a built-in ini.file manager and configuration selector!

 

I would also like the ability (by using the above-described configuration selector) to load incomplete altirra.ini files. For example you'd have your main configuration, and you could just load the input maps or some of the settings or some of the color options. In otherwords, just make the changes that are described in the incomplete altirra.ini file. Don't check that it's 100% complete. This would be the equivalent of using an existing & complex configuration and just adding on a disk drive.

 

I can gain this functionality more or less by adding things to the registry piecemeal. And by having a selection of altirra.ini files at the ready. But maybe not everyone wants operate that way.

 

 

2- The next thing (unless I'm missing it somehow) would be to include a list of the command-line options in the .chm file or from a pull-down within the Help menu. I just observed a noob spending time searching through the help stuff for a list of command-line commands. Didn't think to go to the command-line itself and type altirra /?

 

Come to think of it I had a similar issue a long time ago. Since I didn't see anything in the .chm I automatically assumed there was no command-line support. And lo and behold I find this:

post-4806-0-28511200-1427051086_thumb.png

 

 

3- I want to see the firmware selection box cleaned up a little. Have all the branches collapsed by default when opening the box. And the box should open up enough to display everything without the scrollbar. It's just tedious to read it the way it is now. I think that color coding would be nice. Red = inaccurate/incomplete. Green = accurate/complete. Black = not setup yet. Or even simpler, just red for indicating a problem. Something like so:

post-4806-0-39260400-1427052490_thumb.png

 

4- While I'm typing this stuff up.. Is it possible to become more efficient on the rendering of the scanlines? On a couple lower-end systems (think Pentium-M 1.7GHz) I see as much as a 50% increase in CPU time. Ohh sure it isn't an i7. So that's just a thought.

Link to comment
Share on other sites

Avery, Thank you for this awesome emulator.

 

Question: The new OS ROM management, version 2.6 won't load the Omniview OS, just a black screen. Same ROM image has worked fine on all previous versions of Altirra. Is there some CRC issue, maybe something it won't recognize?

In the immortal words of Emily Latella, "never mind". It works this afternoon. It wasn't working when I first downloaded this morning, but it now recognizes the Omniview OS.

Link to comment
Share on other sites

Thank you for the new version, really lots of improvements. I like the Altirra OS starting screen (of course, I switched to standard ROMs).

 

Disk explorer is great tool, but I miss the proper viewing of BASIC files. Can you add it to the list of new features for the next update?

Link to comment
Share on other sites

Disk explorer is great tool, but I miss the proper viewing of BASIC files. Can you add it to the list of new features for the next update?

 

Yeah, I'll get to that at some point.

 

Since 2.70 is in the early stages already, what do you think about adding 3 things to the user interface?

 

1- The ability to "load" various iterations of the altirra.ini file from within the emulator?

Been thinking about this, but it's a pretty big change as it involves a major reworking of the way settings are saved. Right now they just go into a big ball and come out as a big ball, and the emulator has no concept of profiles or classes of settings. The device refactor helped a little bit as at least now there's a consistent path for device settings, but that's only a small part.

 

2- The next thing (unless I'm missing it somehow) would be to include a list of the command-line options in the .chm file or from a pull-down within the Help menu.

Yeah, yeah... there's never enough time to write docs. Actually, it's weird that we have so many people here who apparently actually read help files. I'd thought those were an endangered species by now.

 

3- I want to see the firmware selection box cleaned up a little.

I agree, but not with your color scheme. :)

 

At one point I did have an implementation that used Vista Explorer like grouping instead with headers in a slightly bigger font, and it did generally look better, but just couldn't get the horizontal positioning right. Stupid control kept wanting to have the items farther left than the headers (WTF) and reserving space for non-existent icons.

 

One problem with trying to redesign this dialog is that it essentially has two duties -- to show you what ROM images are available and also to show what classes of images can be installed. That means, for instance, switching to a flat list doesn't work well.

 

4- While I'm typing this stuff up.. Is it possible to become more efficient on the rendering of the scanlines? On a couple lower-end systems (think Pentium-M 1.7GHz) I see as much as a 50% increase in CPU time. Ohh sure it isn't an i7. So that's just a thought.

Try 2.70-test1 if you haven't already -- it contains an SSE2 optimization for the scanlines. 50% higher on a P-M sounds like more like video overhead, though. Turning on scanlines with artifacting still off requires switching the display format from 8-bit to 32-bit, which requires more CPU. Getting it down further will probably require rendering the scanlines on the GPU, for which I don't have infrastructure yet (and will be slightly annoying, due to multiple rendering APIs).

 

I have checked the error disk explore right mouse pressed when no file is selected this is happen from altirra 2.60 test 32 to the latest version you can check this from the link: http://www.virtualdub.org/beta/Altirra-2.60-test31.zip

 

Thanks...simple issue, will be fixed in next test build.

 

I am always wondering how it is done. Surely Phaeron doesn't own all of these devices?

 

How is it done?

 

I actually do have a fair number of these devices, but not all of them. The PBI devices, for instance, were done without.

 

If I can get a functional description and software that uses the hardware, that's usually enough. For commercial hardware, that usually requires a register-level description, and sometimes schematic or firmware dump and cross-referencing with datasheets. The 1030 was one of the harder cases as I only had the software driver at first, which meant reversing that to get a functional spec and then reimplementing the functional spec. Simpler stuff like the MidiMate just requires knowing which pins which go to which chips. Once I have that info, I can "wire" up the chips in Altirra, which usually goes pretty quickly if I already have the chips emulated. A lot of the remaining time is either figuring out why the software malfunctions or optimizing the emulation to acceptable speeds.

 

Homebrew hardware is usually the same way, although I actually prefer getting the VHDL/Verilog source if possible. Hardware engineers have a habit of leaving stuff out or getting stuff wrong, and it slows things down when they tell me a bit goes one way and it actually goes the opposite way. :P

 

Past that point, having the actual hardware is usually only needed for going past functional emulation to highly accurate emulation. I just recently acquired a real 1030 modem, and one of the changes in 2.70 test-1 is that the emulator bootstrap now approximately matches the sound variations you hear when booting off a real 1030. For some reason, the firmware sends different parts of the driver and ModemLink software at different speeds, which you can hear. It's one of the weird quirks of the hardware that would be lost just working off a functional spec.

 

BRK is a two-byte opcode. Change it to what and for why?

 

Well, it sort of is and isn't. BRK takes two bytes because of the way the 6502 updates the PC, but it doesn't use the second byte. You'd have to access the second byte via a special IRQ/BRK handler, which no one does because it screws up your interrupts and takes a load of cycles. I changed this at some point to match the typical behavior, but it does screw up reverse disassembly, so I'm probably going to revert it.

 

nice :)

how i can save ROM from altirra emulator? :)

somewhere here i found test rom from altirra :)

 

You'd have to use a ROM saving tool for now. However, no new changes besides updating the version number -- OS is otherwise unchanged, BASIC is still 1.38. I'm planning on setting up a separate ROM pack in the future.

  • Like 2
Link to comment
Share on other sites

Well, it sort of is and isn't. BRK takes two bytes because of the way the 6502 updates the PC, but it doesn't use the second byte. You'd have to access the second byte via a special IRQ/BRK handler, which no one does because it screws up your interrupts and takes a load of cycles. I changed this at some point to match the typical behavior, but it does screw up reverse disassembly, so I'm probably going to revert it.

 

Yeah: been there and tried all the usual methods of using the BRK operand when designing the GUI kernel. I'd still expect to see the operand observed during disassembly, though. I often use BRK/.BYTE 0 just for debugging and if BRK were considered a 1-byte opcode it wouldn't disassemble well if the operand were anything but zero, and that's not to mention other uses of the instruction. So I can now see a case for making the instruction length selectable after all. Edited by flashjazzcat
Link to comment
Share on other sites

Quotes are from Keatah.

 

 

1- The ability to "load" various iterations of the altirra.ini file from within the emulator? This would allow for in-emulator changing of the configuration. By default the emulator would need to be reset and start from the beginning when a configuration is selected or changed. That's a given. Like we don't pull ram boards out of powered-up machines! There would be 10 or 20 slots,

 

I would happy with the simple option to just click in the menu and point it at a folder full of .ini files, and then just let me pick the one I want to use. I could easily know what each one is for based on the name it has, or I could even organize them in sub folder structure if I had enough of them. No limit of 10 or 20 that way either.

 

 

2- The next thing (unless I'm missing it somehow) would be to include a list of the command-line options in the .chm file or from a pull-down within the Help menu. I just observed a noob spending time searching through the help stuff for a list of command-line commands. Didn't think to go to the command-line itself and type altirra /?

 

I second that. Seems logical that it be included in the main documentation. I was a "newb" who searched for the info and had to be told to try the /? trick. I know all about /? for DOS/Win CLI stuff, and --help for Linux stuff, but I usually don't think to try it on a Windows GUI program if the documentation does not indicate the presence of CLI commands. The majority of Wi based GUI programs do not have CLI commands in my experience, so it's an easy trap to fall into.

 

 

3- I want to see the firmware selection box cleaned up a little. Have all the branches collapsed by default when opening the box. And the box should open up enough to display everything without the scrollbar. It's just tedious to read it the way it is now. I think that color coding would be nice. Red = inaccurate/incomplete. Green = accurate/complete. Black = not setup yet. Or even simpler, just red for indicating a problem. Something like so:

attachicon.gif209623743.png

 

Great suggestion here as well I think. I'll expand just a bit further on it though. It would be nice if the 'scan' button could work recursively. Also it would be nice if you could "add on" more scans of completely different places and have it build in what is found as additions to any ROMs already found via previous scans of other places.

 

Anyway, thanks for another iteration in the best A8 emulator on Windows Avery!

Edited by fujidude
  • Like 1
Link to comment
Share on other sites

Also it would be nice if you could "add on" more scans of completely different places and have it build in what is found as additions to any ROMs already found via previous scans of other places.

 

This should already work. The scan function keeps existing entries and avoids adding duplicates of the same file location (although it will add duplicates in different locations).

Link to comment
Share on other sites

Hi I just had a chance to test out both 2.60 final, and then 2.70 test 1. 2.60 final works great for me, just like 2.60 test 41 did. 2.70 test 1, however, not so much. With exactly the same kind of setup (all the same firmware files, options configurations, etc.), 2.70 doesn't see any extended RAM. I have hardware set to 65XE/130XE, though it did the same on 600XL/800XL. For memory config, I have U1MB set, which automatically ticks the 1088K RAM amount (and is immutable). The DOS is SDX447 as part of my U1MB firmware. The console switch to enable SDX is disabled. Again, this is the same as I have been doing for many previous versions without trouble.

 

Just for the heck of it, I disabled the U1MB in memory options, 1088K stayed checked (though now is mutable), and attached the 128K .car version of SDX447 as a cartridge. Now the full 1088K RAM is "seen" by the emulated machine.

 

Any thoughts?

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