Jump to content

Photo

Altirra 2.60 released

altirra emulation

948 replies to this topic

#1 phaeron OFFLINE  

phaeron

    River Patroller

  • 2,174 posts
  • Location:USA

Posted Sat Mar 21, 2015 9:51 PM

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.virtualdu...-2.70-test1.zip

http://www.virtualdu...0-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.

 



#2 snicklin OFFLINE  

snicklin

    River Patroller

  • 2,029 posts
  • Location:Australia

Posted Sun Mar 22, 2015 12:35 AM

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.



#3 Keatah ONLINE  

Keatah

    Quadrunner

  • 16,877 posts

Posted Sun Mar 22, 2015 1:08 AM

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.



#4 pajero_pn OFFLINE  

pajero_pn

    Star Raider

  • 55 posts
  • Location:Poland (Europe) / Swarzedz_City

Posted Sun Mar 22, 2015 1:16 AM

Totality: great job :thumbsup:

 

 

Question:

 

Debugging.
Selected 6502.
BRK command is a two byte?
How to change it?

Attached Thumbnails

  • BRK  two bytes.jpg


#5 w1k OFFLINE  

w1k

    Stargunner

  • 1,641 posts
  • Location:martin, slovakia

Posted Sun Mar 22, 2015 2:22 AM

nice :)

how i can save ROM from altirra emulator?:)

somewhere here i found test rom from altirra :)



#6 serj OFFLINE  

serj

    Chopper Commander

  • 200 posts
  • Location:Russia, Omsk city.

Posted Sun Mar 22, 2015 5:58 AM

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.



#7 flashjazzcat OFFLINE  

flashjazzcat

    Quadrunner

  • 12,349 posts
  • Location:United Kingdom

Posted Sun Mar 22, 2015 6:23 AM

Selected 6502.
BRK command is a two byte?
How to change it?


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

#8 Mclaneinc OFFLINE  

Mclaneinc

    River Patroller

  • 4,775 posts
  • Location:Northolt, UK

Posted Sun Mar 22, 2015 7:42 AM

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?



#9 Mclaneinc OFFLINE  

Mclaneinc

    River Patroller

  • 4,775 posts
  • Location:Northolt, UK

Posted Sun Mar 22, 2015 7:49 AM

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, Sun Mar 22, 2015 7:50 AM.


#10 snicklin OFFLINE  

snicklin

    River Patroller

  • 2,029 posts
  • Location:Australia

Posted Sun Mar 22, 2015 8:04 AM

amazing that you were just able to emulate it so quickly, you have done this with so many other devices..Superb work.

 

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

 

How is it done?



#11 ACML OFFLINE  

ACML

    Dragonstomper

  • 593 posts
  • Location:USA

Posted Sun Mar 22, 2015 8:11 AM

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?



#12 jacobus OFFLINE  

jacobus

    Dragonstomper

  • 661 posts
  • Location:Canada

Posted Sun Mar 22, 2015 9:08 AM

Thank you Avery!



#13 Keatah ONLINE  

Keatah

    Quadrunner

  • 16,877 posts

Posted Sun Mar 22, 2015 9:40 AM

Here's the mini-dump of the right click in tools>diskexplorer crash.

Attached File  AltirraCrash.zip   10.8KB   129 downloads



#14 everklear OFFLINE  

everklear

    Space Invader

  • 22 posts
  • Location:Edmonton, Alberta, Canada

Posted Sun Mar 22, 2015 10:15 AM

Thanks for this. Your work is inspiring and greatly appreciated.



#15 marcokitt2000 OFFLINE  

marcokitt2000

    Chopper Commander

  • 186 posts
  • Location:Netherlands

Posted Sun Mar 22, 2015 12:50 PM

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.virtualdu...2.60-test31.zip

 

2.60 test 31 works fine.

 

Maybe this wil help phaeron seach the error.


Edited by marcokitt2000, Sun Mar 22, 2015 1:11 PM.


#16 Keatah ONLINE  

Keatah

    Quadrunner

  • 16,877 posts

Posted Sun Mar 22, 2015 1:47 PM

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:

Altirra command-line options.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:

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



#17 xxl OFFLINE  

xxl

    Dragonstomper

  • 977 posts
  • Location:Rabka-Zdrój /Poland

Posted Sun Mar 22, 2015 2:46 PM

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

 

 

SlightSID out?

 

---

 

eh... ok: RTFM ;-)


Edited by xxl, Sun Mar 22, 2015 2:58 PM.


#18 tebe OFFLINE  

tebe

    Dragonstomper

  • 628 posts
  • Location:Poznań - Poland

Posted Sun Mar 22, 2015 3:57 PM

XXL

 

System -> Devices... -> Add -> SlightSID



#19 ACML OFFLINE  

ACML

    Dragonstomper

  • 593 posts
  • Location:USA

Posted Sun Mar 22, 2015 4:18 PM

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.



#20 Gury OFFLINE  

Gury

    Stargunner

  • 1,196 posts

Posted Sun Mar 22, 2015 4:47 PM

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?



#21 phaeron OFFLINE  

phaeron

    River Patroller

  • Topic Starter
  • 2,174 posts
  • Location:USA

Posted Sun Mar 22, 2015 6:18 PM

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



#22 flashjazzcat OFFLINE  

flashjazzcat

    Quadrunner

  • 12,349 posts
  • Location:United Kingdom

Posted Sun Mar 22, 2015 6:34 PM

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, Sun Mar 22, 2015 6:36 PM.


#23 fujidude OFFLINE  

fujidude

    River Patroller

  • 4,528 posts
  • Location:United States of America

Posted Sun Mar 22, 2015 6:40 PM

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, Sun Mar 22, 2015 7:05 PM.


#24 phaeron OFFLINE  

phaeron

    River Patroller

  • Topic Starter
  • 2,174 posts
  • Location:USA

Posted Sun Mar 22, 2015 6:44 PM

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



#25 fujidude OFFLINE  

fujidude

    River Patroller

  • 4,528 posts
  • Location:United States of America

Posted Sun Mar 22, 2015 8:25 PM

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, Sun Mar 22, 2015 8:27 PM.






Also tagged with one or more of these keywords: altirra, emulation

0 user(s) are browsing this forum

0 members, 0 guests, 0 anonymous users