Jump to content
IGNORED

Altirra 2.90 released


phaeron

Recommended Posts

When you full-screen the emulator, it's essentially a media player, so perhaps some ideas could be borrowed (auto-hiding control bar, etc). I happen to have Altirra laid out like this (occupying a whole second monitor) 99 per cent of the time:

 

post-21964-0-61008500-1501103933_thumb.png

 

I could not deal with floating palettes so I got used to docking the debugger windows in that exact arrangement and ended up sticking with it. Altirra's UI is already pretty flexible in this sense, but keeping everyone happy (or trying to) must be a headache.

 

  • Like 2
Link to comment
Share on other sites

Floating windows won't be the default -- too messy and adds new problems without actually solving existing ones. Docked or auto-hide is a much better experience.

 

Note that there is some existing drag-and-drop functionality for drives -- if you right-drop you will get a context menu to mount to specific drive slots.

 

Dialogs only work in full screen if you are using one of the less well supported display modes (GDI/DirectDraw/OpenGL) or have the borderless option enabled. This is because dialogs can't be supported in exclusive full screen mode and won't be fixed. Use borderless mode if this is a problem for you.

  • Like 6
Link to comment
Share on other sites

I've noticed an inacurracy in Altirra 2.80. When I changed DL during the display of the frame Altirra hasn't crashed but on real Atari the code crashed.
edit: unfortunatelly I cannot provide any more information, because I haven't got this bug in my files, and I can't remember what exactly was happening.

Edited by gorgh
Link to comment
Share on other sites

I've noticed an inacurracy in Altirra 2.80. When I changed DL during the display of the frame Altirra hasn't crashed but on real Atari the code crashed.

edit: unfortunatelly I cannot provide any more information, because I haven't got this bug in my files, and I can't remember what exactly was happening.

 

This is not nearly enough information to assume it is an inaccuracy in the emulator.

 

There are many reasons this can occur that are completely correct behavior. For one thing, there is a main division in the XL/XE line between models that have a floating data bus and a pulled up bus. Both are emulated, depending on whether you select 800XL or 130XE as the base hardware. If the display list fetch extends into the hardware region, this can then depend upon what hardware you have occupying the cartridge control region ($D5xx) and the PBI regions ($D6xx and $D7xx). Then, there is usage of uninitialized memory, the contents of which depends both on the type of RAM chips that you have as well as the loader that you have used to load the problem. Finally, the exact timing at which the program starts will influence when the display list is switched and exactly what garbage data ANTIC reads. Unless you are running your program directly from a cartridge, it is almost certain the program will not start at the same beam location.

 

Long story short, it is not reasonable to expect that the emulator will show you the exact same results as your physical computer in all cases, especially when it isn't configured identically. Like running on a second computer, running on the emulator in one configuration does not rule out all possible failures. However, the emulator does make it easier to try many configurations, as well as diagnostic modes that are more likely to reveal specific types of common problems.

 

Finally... this is the 2.90 thread, so if you actually did mean 2.80, it is time to upgrade.

  • Like 3
Link to comment
Share on other sites

Dialogs only work in full screen if you are using one of the less well supported display modes (GDI/DirectDraw/OpenGL) or have the borderless option enabled. This is because dialogs can't be supported in exclusive full screen mode and won't be fixed. Use borderless mode if this is a problem for you.

 

I will have to subject this to a deeper experimentation. If I select only "OpenGL" Tools->Options->Display and restart Altirra, opening a dialog kicks me from full screen. This is not a complaint. I am new to Altirra and just getting familiar with it, so I tend to miss things or ask questions that have obvious RTFM answers.

Link to comment
Share on other sites

I just ran Altira 2.90. I used 2.78 before.

 

I have a small problem now. When I want to change the Console Switches (in the system menu), all options are grey and cant be changed. Only option that is possible is "Force selve test"

 

How can i make it able to change the Console Switches (to choose to boot with SIDE2 / Spartados or just an ATR image/etc)

 

I am Using Windows 7 64bit with 16 gig memory and Intel I3-6100.

 

-- edit : I forgot to change Devices -> add - SIDE2.

 

Now SIDE2 boots on 2.90 and options "Enable Cart SDX" and "activate Cart menu button" are now black and usable.

 

I gues, my problem is solved.

Edited by Stormtrooper of Death
  • Like 2
Link to comment
Share on other sites

http://www.virtualdub.org/beta/Altirra-2.99-test5.zip

http://www.virtualdub.org/beta/Altirra-2.99-test5-src.zip

 

  • Fixes 65C816 CPU reverting to emulation mode when switching speeds on the fly.
  • Fixes VBXE XDL not being halted at the beginning of vertical blank.

Also adds the initial version of a new debug feature, the performance analyzer. This records an execution trace and uses it to display a timeline of what functional units are doing. It is available at the bottom of the Debug menu. Here's a trace of the Koronis Rift custom disk loader, showing the disk read being kicked off from the VBI:

 

post-16457-0-35558300-1501913804_thumb.png

 

This is somewhat like the existing History feature, but different in several ways. It records events other than CPU execution, captures video frames, and can capture much longer traces. The tracer can also detect some types of idle loops and also the deferred VBI, as seen in this trace from Henry's House (which has an unusually long deferred VBI):

 

post-16457-0-05561400-1501914064_thumb.png

 

Here's an example of an IRQ response being held off by a DLI:

 

post-16457-0-26801200-1501914121_thumb.png

 

Here's the custom disk loader from Total Daze:

 

post-16457-0-66393800-1501915568_thumb.png

 

...and here's an example of the recently released VBXE demo underutilizing the blitter: :)

 

post-16457-0-91138200-1501914218_thumb.png

 

There are a couple of caveats. First, the trace is currently not limited, so the emulator can run out of memory if you let it run too long. The 32-bit build should be OK with ~5 minutes, though, and the 64-bit build can use all available memory, so it can still record much longer traces than History can accommodate. Second, currently the CPU history is scanned but not recorded, so you can't yet get details on what the CPU is doing.

 

 

  • Like 19
Link to comment
Share on other sites

I love all these new additions because they encourage more development because of the ability to track bugs and code more efficiently, all of this is way way way over my head in terms of usage but the fact its there just wow's me.

 

Nice one Avery, not only helping the users but also helping the producers..

 

Its all good, thank you.

  • Like 1
Link to comment
Share on other sites

It does indeed, I sort of get the gist of what its recording and I get the idea of what a programmer would be looking for but as to how you would use the data to do improvements is well beyond me :)

 

Anything little thing I programmed back then didn't take in to account cycles and VBI's etc, it was just Q&D code that did what it was meant to and nothing more, doing a disk copy util wasn't rocket science, I'd love to understand the debugger 100% but its way way way above my pay grade :)

 

My brain still works via a hamster on a treadmill powering it :)

Link to comment
Share on other sites

VBXE emulation.

1. When I disable the MEMACB window (write a 0 to $D65D) the MEMACA window is disabled too but it shouldn't.

2. After RESET (selected Coldstart option from System menu) VBXE registers aren't reset.

Could you fix please?

 

Edit: English grammar :/

Edited by mono
Link to comment
Share on other sites

That new performance analyzer tool looks great! Would it be possible to import a trace for the new performance analyzer? To debug some bugs on the Éclaire I'm capturing the data and address bus (+some other flags such as an0-2) and I was wondering if it be feasible to plug into your existing tools for analysis somehow.

  • Like 1
Link to comment
Share on other sites

VBXE emulation.

1. When I disable the MEMACB window (write a 0 to $D65D) the MEMACA window is disabled too but it shouldn't.

2. After RESET (selected Coldstart option from System menu) VBXE registers aren't reset.

Could you fix please?

 

Do you have more details? I am unable to reproduce either of these two issues on the latest 2.99-test build. The writes to the three banking registers all go through a single "Make It So" routine, so I'm not sure how this conflict can occur and I'm not seeing it in either the .vbxe or .map command outputs after writing $D65D=0.

 

@avery

 

what does the IDLE tells me in the screenshots? :D that I waste time??? :D

 

Yes :)

 

"Idle" time is time where the CPU is just looping on memory values without doing any work, where "work" is some sort of arithmetic, table lookup, or writing to memory. A loop like this would be detected as idle:

loop:
    lda  done
    bne  exit
    lda  status
    bpl  loop
exit:

...because it simply reads two variables over and over. The idle detection isn't foolproof, obviously; it can't currently detect the wait-for-key loop in the E: device because there's too much going on in it. Still, it already seems to detect a lot of simple waits here and there.

 

In the case of the snapshot from your demo, that would be time that the CPU is waiting for the blitter to finish, and not otherwise accomplishing anything else. If you could find some way to start working on the data for the next frame while the blitter is running, then you would be able to overlap with the blitter and potentially shorten the frame time. Using the blitter IRQ is a cheap way to avoid having to poll the blitter, but you still need work to do on the 6502 that doesn't require the blitter in the meantime. That'd probably mean reworking the rest of the frame code to batch blits up a bit better so the 6502 is not constantly synchronizing with the blitter every few scanlines. The 6502 is so much slower than the blitter that just about any tradeoff to save 6502 time is worth it even if it means more work for the blitter.

 

The tricky part is that if you're syncing to vblank at some point in the frame, as it looks like you're doing here, then you aren't going to see an improvement until you shorten the frame time by an entire frame or find a way to remove that hard synchronization. Until then, the 6502 just ends up idling for a longer time until the end of the frame. Two classic ways to fix this are either to remove the synchronization -- flipping immediately and accepting tearing -- or using triple buffering so you can run an irregular frame delay pattern (2 / 2 / 2 / 3 / 2 / 2 / 2 / 3 ...). Triple buffering is not used much on the 8-bit because it takes a lot of memory and switching between three buffers can slow down addressing. VBXE's 512K of memory and flexible banked addressing mean that you can switch buffers without having to switch addresses on the 6502. You can keep the 6502-side buffer at a constant address like $6000 even if it is actually rotated between $12000, $14000, and $16000 in VBXE local memory.

 

That new performance analyzer tool looks great! Would it be possible to import a trace for the new performance analyzer? To debug some bugs on the Éclaire I'm capturing the data and address bus (+some other flags such as an0-2) and I was wondering if it be feasible to plug into your existing tools for analysis somehow.

 

Possibly, though it'd need preprocessing and of course some more inputs. The event tracing for the various units just needs markers for when events start and end along with associated timestamps, so that depends on your ability to log those events. The CPU tracing is harder; it needs a list of timestamped instructions. To derive this from the hardware side requires equivalents of A0-A15, D0-D7, R/W, SYNC, HALT, and RDY. That's enough to identify the CPU cycles, trace the instruction stream, and separate out the data accesses. The tracer also needs flags for when NMI and IRQ sequences start and stack pointer values, but I think those can be deduced from the instruction and data fetch streams.

 

An alternative that might be worth looking into is the Chrome Trace Viewer, which I only recently discovered myself. It's a similar event-based trace viewer built into Chrome that uses a generic JSON-based event format.

  • Like 2
Link to comment
Share on other sites

Thanks Avery

 

I was aware of loosing CPU but having it now visible for my eyes :)....

 

As I am polling the waitblit reg and not doing parallel work not using IRQ or sometimes even additionally waiting the frame finish lda framecounter cmp framecounter beq more is wasted....

 

But that much :D? ok... next time ;)

  • Like 1
Link to comment
Share on other sites

How is the deferred VBI deduced? Having noticed that the previous capture of the GOS made it appear there's a deferred VBI running non-stop, I made two more captures:

post-21964-0-62927900-1502372885_thumb.png

post-21964-0-14684000-1502373595_thumb.png

The first offers a rebuttal to those who assume the 6502 is running flat out when multitasking, but the second shows that constant deferred VBI present in the prior capture. Nothing changed: I simply stopped the first sample, grabbed it, then made a second one. The first trace makes complete sense: CPU mainly preoccupied with the idle task, which is simply a JMP *, IRQs triggering the mouse sampling, DLIs for mouse rendering, and VBIs for context switching.

Edited by flashjazzcat
Link to comment
Share on other sites

 

Do you have more details? I am unable to reproduce either of these two issues on the latest 2.99-test build. The writes to the three banking registers all go through a single "Make It So" routine, so I'm not sure how this conflict can occur and I'm not seeing it in either the .vbxe or .map command outputs after writing $D65D=0.

 

I want to apologise you. I have been debugged my program working with S_VBXE.SYS driver and I didn't saw VBXE RESET code sequence (in S2:) :/ Today when I wrote some testing code I saw Altirra works fine and found reason of disabling MEMACs.

Of course Altirra emulates VBXE correctly. My apologies again.

Link to comment
Share on other sites

The performance analyzer is really nice, thanks!

 

post-11240-0-61727600-1502403802_thumb.png

 

The slightly grey area is something like the vblank?

 

It would be nice, at some point, to be able to use the source listing (in mads) to set colors for specific methods and maybe have some kind of visual marker for when the logic frame really ends (or could be done automatically, but it seems there are many methods to change to the next frame, like changing the DL address, changing the DL jump or LMS instructions..).

But probably you have something better in mind.

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