Altirra 4.00 released

[jindroush]

12 hours ago, baktra said:

The settings available under System>Configure System>Ease of use will help you to prevent cold start when changing cartridge. To be honest, there are so many settings in the dialog that a settings search box (like in the Eclipse IDE) could be useful. But anyway, the life before the Configure System dialog was much harder than today.

Thx, that setting should be sufficient for the simple button cartridges, which is enough.
And you're right - but still - if you don't know that there is a setting even the search won't help. The only way (which is by far most error prone and tedious) is to offer setting toggle/info when the action is done. In this case, on first detach, the dialog would ask what to do: Don't detach / Detach & Cold boot / Only detach [ ] remember action. But as I said, this is quite tedious to implement correctly.

[tmp]

according to https://github.com/dmlloyd/atari800/blob/master/DOC/cart.txt, phoenix/blizzard cart types are disabled by access to cctl area (that should mean both read and write), altirra seems to disable only on write

 

there's also a schematic and it doesn't use /rw line

https://web.archive.org/web/20051225154144/http://www.serious-dial.atari.pl/Serious/S13/A18.html

[8bit-Dude]

Thanks for this Phaeron! Awesome work!

 

By the way, I am trying to implement an emulated device for my 8bit-Hub. 

I started by duplicating the 4 Joyticks Dongle Code, and got the PIA I/O working fine.

 

However, I cannot for the life of me figure out how to trigger the Joyport 2 button from within the ATDevice Class.
The simulator.cpp code contains references to a Joystick manager, but I could not find where actual setting of the $D011 register occurs.

 

Is there a simple way to trigger the Joyport 2 button from an ATDevice? (It is used by 8bit-Hub as an ACKNOW flag).

[+CharlieChaplin]

1 hour ago, rsh said:

FYI: I just tried BrushupV40 in Altirra 4.0 and the drawing editor (key detects) work fine, but the menu's outside of the editor are extremely slow to pick up a key press.  Altirra 3.20 works correctly like the real hardware 130xe.  Not sure what is causing this, maybe a Bug with Altirra4.0 or new setting/compatibility check is required.  

[Mclaneinc]

Have you tried changing the way keys are read / decoded or whatever in Configure system / keyboard?

[snicklin]

A feature request here, sorry if it has been asked before.

 

I will start with my problem.

 

I program on and off and may go months between programming on the Atari, juggling with PC projects.

 

I really love the power of the Altirra debugger, but do not find it particularly user friendly. As I am a sporadic Atari programmer, I forget what the commands are and their syntax each time and I have to relearn them. This means that I often do not get to use the more powerful features as I have spent a lot of time relearning the basics.

 

At least for the most useful features, like stepping through the code, running from a place, moving the current program counter, setting a byte or word to a value, can there be an icon in the UI that I can click on? It would really help me to work quicker.

 

As we all have to juggle life and our passions, I suspect a lot of people will enjoy such a set of features.

[phaeron]

On 1/17/2022 at 2:12 PM, CharlieChaplin said:

FYI: I just tried BrushupV40 in Altirra 4.0 and the drawing editor (key detects) work fine, but the menu's outside of the editor are extremely slow to pick up a key press.  Altirra 3.20 works correctly like the real hardware 130xe.  Not sure what is causing this, maybe a Bug with Altirra4.0 or new setting/compatibility check is required.  

This is an issue specific to when running under AltirraOS due to a compatibility issue with the way KEYDEL is handled, I'll fix it.

 

BTW, the link to the original post didn't come through -- in the future if you could make sure that is linked, it'd be helpful in tracking down the details and program to test against.

 

On 1/18/2022 at 4:30 PM, snicklin said:

I really love the power of the Altirra debugger, but do not find it particularly user friendly. As I am a sporadic Atari programmer, I forget what the commands are and their syntax each time and I have to relearn them. This means that I often do not get to use the more powerful features as I have spent a lot of time relearning the basics.

 

At least for the most useful features, like stepping through the code, running from a place, moving the current program counter, setting a byte or word to a value, can there be an icon in the UI that I can click on? It would really help me to work quicker.

I'll readily confess that I'm not much in favor of toolbars for debugging -- first thing I do to a Visual Studio installation is to remove the majority of the toolbars to reduce clutter. But I do see where you're coming from. A few of the commands that are contextual, such as set PC, are available on context menus. I've thought about adding support for customizable toolbars / quick bars, but it'd require finding a solution for scalable art as toolbars need icons to be reasonably compact, and a lot more than I've previously done.

 

As a reminder, you can always get a list of commands in the debugger with the .help command, and specify the name of a command after .help to get specific help for that command.

 

[snicklin]

On 1/20/2022 at 1:48 PM, phaeron said:

I'll readily confess that I'm not much in favor of toolbars for debugging -- first thing I do to a Visual Studio installation is to remove the majority of the toolbars to reduce clutter. But I do see where you're coming from. A few of the commands that are contextual, such as set PC, are available on context menus. I've thought about adding support for customizable toolbars / quick bars, but it'd require finding a solution for scalable art as toolbars need icons to be reasonably compact, and a lot more than I've previously done.

 

As a reminder, you can always get a list of commands in the debugger with the .help command, and specify the name of a command after .help to get specific help for that command.

Thanks for getting back to me on this one Avery.

 

Regarding clutter, if it was hidden by default unless you switch it on, this will keep people happy who don't want too much clutter.

 

With regards to scalable art, I'd be happy with text on a button if that makes it easier. I'm sure that there should be enough art in the Wingdings font (hey yes, that font can be useful!). It's your choice though, you're the one doing the work here.

 

As for the instructions in .help, I read them the first time I try something again, but sometimes I get the syntax wrong the 2nd and 3rd times until I get used to it all again. As there's a lot of text in there, potentially I should create a cheat sheet

[Mclaneinc]

 

Yes, sounds like you need a print-out to refer to.

 

I've said before that I'd love a tutorial on the debugger for people like me who understand the basics but are missing some of the features, so losing out on its abilities.

 

I do not expect Avery to write it, god knows, he's busy as it is, but I'd love a real power user to do a thread or whatever just showing the features with examples of how it works.

 

I know, it's a lot to ask..

 

Paul..

[VinsCool]

I personally don't have a great understanding of the debugger features, but I absolutely love the way it works by picking up assembly listing and labels and displays all of the things I am testing in the disassembly listing.

This has been insanely helpful for making possible all the things I have been trying to do lately, while I am slowly learning more and more advanced tricks in 6502 ASM programming

 

Setting break point, advance to next instruction, the scanline counter and the screen position of the electron beam have been so, so fantastic to use and understand as well!

 

So I can say the F8, F9 and F10-F11 keys have been very useful for me, it's great to see the things advance in a instruction by instruction pace, haha

[baktra]

Hello @phaeron,

 

I might have found a bug in support for the pwm turbo tape image chunks. Version 4.10-test5.

This is a link to a test data: https://drive.google.com/drive/folders/19SqiRH5ZzbvIcDJNZHzdwRM3ygaVBYKj?usp=sharing

The directory holds three items. A wave file, a tape image and a rom image (phoenix 8k). The wave file was generated from the tape image.

 

To re-create the problem:

0. Set the system. Emulate XL/XE with 64 KB RAM, Atari XL/XE OS, PAL. Set cassette turbo system to "SIO Command (Turbo 2000)"

1. Attach the cartridge, it will display a blue screen with options.

2. Load the .cas file as tape image

3. Press ESC to "load and run" and wait. Loading bars will be displayed briefly, but nothing will be loaded.

 

If the .wav file is used instead of the .cas file, then the game loads correctly. You can use the WAVE file to compare your interpretation of the .cas image.

 

I suspect that the problem is with processing of the pwml chunk placed right after the first pwmc chunk. I've tried another turbo system that doesn't need pwml chunk between the pilot tone and data and it worked. However, I can be wrong. The tape image works ok with the atari800-a8cas emulator.

 

I would like to kindly ask you to take a look at this.

Thank you

[phaeron]

10 hours ago, baktra said:

I suspect that the problem is with processing of the pwml chunk placed right after the first pwmc chunk. I've tried another turbo system that doesn't need pwml chunk between the pilot tone and data and it worked. However, I can be wrong. The tape image works ok with the atari800-a8cas emulator.

Confirmed, the issue is that the code processing pwml chunks isn't using the correct duration scaling, it's using the same 10k value as for FSK chunks. I'll get this fixed up for next test release.

[drac030]

Altirra debugger in 65C816 mode, history window:

 

 

It is "Timestamp format -> Show cycles". But the cycles it seems to show are slow bus cycles (aka 1.77 MHz cycles), even when the CPU is set to 20 MHz. Fixable?

 

Also: could it remember the selection?

Edited January 24, 2022 by drac030

[rsh]

 

I only noticed in version 4.0.. I have not tried other versions after 3.20.  If there is a known issue with key input/timing processing then ignore this.  If not, I can pull my code and try and make a test case.  I have tested 3.20 and real hardware and they behave the exact same.   It could be my code, but strange real hardware works fine.  I did try and go through altirra config setting to see if any new or other settings would remedy the problem, but non made a difference. 

Edited January 26, 2022 by rsh

[pajero_pn]

Thank you for the program, it's great.

 

In the debugger.

Memory windows (1-4)

 

1. It does not remember the last entered addresses, it always starts with an address equal to 0

2. Modify memory data in Console window only (e command), can't you do that in Memory window?

3. Column numbering is missing, according to the row address.

[phaeron]

https://www.virtualdub.org/beta/Altirra-4.10-test6.zip
https://www.virtualdub.org/beta/Altirra-4.10-test6-src.7z

• Compiler changed to Visual Studio 2022.
• AltirraOS: Improved compatibility of KEYDEL handling.
• Custom Devices: Script compiler now parses and blocks ++ and -- operators to prevent them from being parsed as pairs of unary operators.
• Debugger: Fixed memory window horizontal scroll bar.
• Devices: Lifted internal PIA limit which could cause devices to break in unusual cases with too many devices connecting to the PIA inputs.
• Display: Retuned monochrome artifacting fix to high artifacting filter to restore comparable quality of color modes to 4.00.
• Display: Fixed broken text after toggling HDR on the fly.
• PCLink: Directory enumerations now report if the directory is root or a subdirectory.
• PCLink: Improve compatibility of path parsing compared to base SDX filesystem.
• Tape: C‌: SIO patch is now more flexible in handling of the transfer mode byte.
• Tape: Improved quality of tape resampler.
• Tape: Fixed incorrect rate handling of pwml chunks in CAS files.
• Tape editor: Fixed store waveform option not actually doing anything.
• Tape editor: Added Copy Decoded Data command.
• Tape editor: Restored previous version of FSK decoding so that there are both now block-oriented and freeform decoders.

Disclosure, I did some pretty heavy refactoring to the internals of the input system to make it easier for devices to drive the controller trigger and paddle inputs.

[Roydea6]

PCLINK.SYS is not installing PCL: with this test build.

 

PCLink v.0.9, dev. 6, SIO id $6F
Warning: server not ready

[baktra]

With the test-6 version, I cannot load any tape images (.cas, .wav; standard or turbo). I've completely reset the settings, but no help. E.g. I load a tape image with a cassette boot file, restart with START+OPTION, press a key and then nothing happens. The tape control dialog doesn't respond to PLAY or STOP or PAUSE. The .pia debug command shows motor on.

Edited January 31, 2022 by baktra

[Mclaneinc]

2nd for no cas stuff working...

Edited January 31, 2022 by Mclaneinc

[phaeron]

Try now:

https://www.virtualdub.org/beta/Altirra-4.10-test7.zip
https://www.virtualdub.org/beta/Altirra-4.10-test7-src.7z

 

[baktra]

I am happy to report that cassette images with pwm chunks work for all turbo systems supported by TURGEN. Cassette images with baud, data and fsk chunks work as well. The same for wave files holding both standard and turbo records.

[Mclaneinc]

Not tested the PCL, I'll let Roy do that, but so far it's all cooking on gas here..

 

Mind you did say you had made major changes, so a very rare dud release.. All good now, thanks..

[glurk]

I have a question...  I find myself using SHIFT-F8 and CTRL-F8 in Altirra a lot, to see what mode lines are in use, the colors, etc.  But I don't completely understand what it all represents, especially the DLI/DMA display.  Is this documented somewhere, what the overlays are showing?

 

[phaeron]

On 2/4/2022 at 4:08 AM, glurk said:

I have a question...  I find myself using SHIFT-F8 and CTRL-F8 in Altirra a lot, to see what mode lines are in use, the colors, etc.  But I don't completely understand what it all represents, especially the DLI/DMA display.  Is this documented somewhere, what the overlays are showing?

Nope, those overlays are very old. Here's what they do:

 

DMA Analysis shows a graphical pattern of which cycles are being used by ANTIC, and thus not available to the CPU. The catch is that the horizontal position is somewhat vague depending on what you're looking for. The displayed pattern accurately shows the order and spacing of DMA cycles. The problem is that what people actually want is to know when they need to write to a register to produce a change at a specific screen location, and that varies with each register or even which part of a register depending on where it is used in the graphics pipeline. That effect can occur up to 5 cycles away from the horizontal positioning shown this overlay. This may be a view I remove in the future.

 

Layer Analysis shows which parts of the screen are being provided by playfield or P/M graphics. The mechanism is simple: it forces the rendering palette to specific values for each layer or combination of layers. PF0-PF3 use $03/07/0B/0F, PM0-PM3 use $1A/5A/7A/9A, BAK uses $01, conflict black is $00, and some of the other blended or conflict combinations use other colors. This rendering is also active for the Color Analysis and Display List Analysis modes. Note that it does not distinguish between players and missiles, or mode 9 player colors vs. P/M graphics.

 

Color Analysis draws the color palette on each line, in the order PM0-PM3, PF0-PF3. Note that these colors are snapshotted at the end of the scanline in the order that the emulator draws them, so technically they are the colors at emulator horizontal position 0, right before missile DMA.

 

Display List Analysis draws the contents of the display list Instruction Register (IR) on each line. The left four columns are the high four bits of the IR, which correspond to DLI, LMS, vertical scrolling, and horizontal scrolling. The right two columns represent the mode in the low four bit of the IR, as the hue with luma set to 15. In the debugger, you can Alt+click to see precise info about the display list.

 

[drpeter]

16 hours ago, phaeron said:

what people actually want is to know when they need to write to a register to produce a change at a specific screen location, and that varies with each register or even which part of a register depending on where it is used in the graphics pipeline. That effect can occur up to 5 cycles away from the horizontal positioning shown this overlay. This may be a view I remove in the future.

That may be true, but this view remains a very useful educational insight into where in the raster cycle 6502 cycles are being 'stolen' by DMA.

 

I assume that at present the view is synchronised to show when DMA is occurring precisely in relation to the contemporaneous physical electron beam position?  If this is taken as the immutable baseline timeframe, known register write pipelining delays in relation to that timeframe can be counted forward from it to determine where the graphical effects of register writes will appear on screen...

Edited February 6, 2022 by drpeter