Altirra 3.90 released

[HiassofT]

I think I found a bug:

 

The 512k MegaCart flash cartridge seems to be emulated with 4096k MegaCart flash banking (255 16k pages, $FF disables cart) instead of standard 512k MegaCart banking (bits 0-4 select one of 32 16k banks, bit 7 disables cart).

 

Info about that cart can be found here: http://www.abbuc.de/~bernd/neue-module---new-cartridge/index.html

 

I noticed that when testing my old diskcart/diskwriter software (see here http://www.abbuc.de/~bernd/downloads/diskcart.zip) which uses $80 to disable the cart and crashes in Altirra immediately at the start when it tries to run code at $BB00 (which should be RAM).

 

.bank indicates that the internal cart address follows 4MB MegaCart banking, only $FF disables it and the address increases up to 4MB (minus 16k). The flash chip (29F040) seems to be emulated correctly though.

 

This bug has probably been present from the beginning, I went back to 3.00 and got the same crash (didn't go back further in time).

 

so long,

 

Hias

[Wrathchild]

@HiassofT

Are you using a 512KB length binary or a CAR file as there seems to be two 512K models, kATCartridgeMode_MegaCart_512K and kATCartridgeMode_MegaCart_512K_3, the latter having the behaviour you describe and the former the behaviour you want?

 

So the mapping in the CAR header could be wrong.

Edited September 23, 2020 by Wrathchild

[HiassofT]

I've mainly tested with "Attach special cartridge->Empty 512k MegaCart flash cartridge", and also tried with a plain 512k ROM file selecting the MegaCart 512K (3) type.

 

The 512k flash MegaCart doesn't have a cart type number assigned in Atari800's CART.txt, so probably packing that into a CAR file will be a bit tricky (well, banking is identical to normal 512k MegaCart but one would need to flag to the emulator that it has a flash chip).

 

so long,

 

Hias

[ijor]

On 9/16/2020 at 5:22 AM, phaeron said:

Yeah, I'm basically ignoring this since the backing store is decoded data, so you can freely exchange disk images with the other drive types in ways that wouldn't work with a real 815. However, I don't think anyone has use for ATRs that have inverted data.

Beg to differ but, personally I would like this to be configurable. I do realize the convenience of sharing ATR images with the other Atari drives. But, IMHO, this makes the emulation less accurate. A disk that works on the USD should not work in the 815 and vice versa. Conceivable, somebody could make a program to convert 815 disks by inverting the data, and this would fail under emulation. I agree that these are extreme cases and you can say I'm playing the devil's advocate. A slightly (just slightly) more realistic case, though, would be when dumping a real 815 disk to ATR. Or writing back an ATR to use on a real 815 drive. It would fail in both cases with this scheme.

 

Again, this is very exotic I can perfectly understand that the whole thing might not be worth to implement a configuration option. I just thought I should mention the issue.

[ijor]

On 9/15/2020 at 4:47 AM, Nezgar said:

This is further evidence that Percom never had their hands on an 815 as an example, otherwise they may have mirrored the 815's 16:1 interleave, and non-inverted sectors for DD operation for compatibility...

Did you hear to the Atari podcast interview with Charles Marslett who wrote the Percom firmware? If I understand correctly, according to him Percom did have a prototype and a copy of the DD DOS. Actually he mentions that the whole idea of Percom developing a DD drive was precisely because Atari killed their own DD project. Mr Marslett also mentions an issue with the boot sectors being single density that doesn't make much sense to me, but otherwise he seem to remember things quite well.

[+Nezgar]

20 hours ago, ijor said:

Did you hear to the Atari podcast interview with Charles Marslett who wrote the Percom firmware?

Charles Marslett wrote the Percom firmware? Wow. No, I haven't listened to that one yet, which I must do! Without listening, re single density boot sectors, maybe he's mis-attributing the format behaviour of the 1050 Duplicator...

[ijor]

6 hours ago, Nezgar said:

Without listening, re single density boot sectors, maybe he's mis-attributing the format behaviour of the 1050 Duplicator...

I doubt it. But even then, it still wouldn't make much sense because he claims that he had to modify DOS for that reason ... listen to the interview, it's worth

[matosimi]

@phaeron would it be possible (worth) exposing altirra console over network, so it works be possible to control the emulator over telnet.

So there could be eventually an external sw able to control the emulator like stop the   emulation , get values from addresses (or address range), set values and resume the emulation.

This way it would be possible to create external guis for tools, AI controlled second player (in games where only human players can play), central (cloud) cheats tool, central (cloud) high score tool and some more.

 

Maybe it is to much to ask, I'm just wondering if this have crossed your mind.

[drac030]

I think there may be something wrong with the debugger's interpretation of 65C816 code in the disassembler window. Here is what happens:

 

1) we have the debugger stopped at $0027F4:

 

 

2) we step through REP #$20 and stop at next instruction, the view changes (to the correct one):

 

 

3) then we make several steps further to reach SEP #$20 at $002800:

 

 

4) then we step through this instruction, and then the view changes back to the initial mess:

 

 

Note that there are no instructions between $27F4 and $2800 loading immediate data to accumulator, and the X bit does not change, so there seems to be no reason for the changes of the interpretation shown above.

 

Edited October 6, 2020 by drac030

[phaeron]

On 10/3/2020 at 11:54 PM, matosimi said:

@phaeron would it be possible (worth) exposing altirra console over network, so it works be possible to control the emulator over telnet.

So there could be eventually an external sw able to control the emulator like stop the   emulation , get values from addresses (or address range), set values and resume the emulation.

This way it would be possible to create external guis for tools, AI controlled second player (in games where only human players can play), central (cloud) cheats tool, central (cloud) high score tool and some more.

 

Maybe it is to much to ask, I'm just wondering if this have crossed your mind.

It has, but I haven't done much on this for a couple of reasons. Creating and maintaining such an interface would take some effort, and also create a support dependency with other projects. I haven't been able to justify the complexity and cost of this. These functions are available internally but they're not interfaces that have to remain stable.

 

Another reason is that I'm not very interested in making it too easy to integrate Altirra as part of another product. I've had some mediocre experiences with this on another project where this created some support nightmares, because I would get contacted for issues caused by the way my program was being driven by another program, and the authors of that program did nothing to mitigate this while using packaging that often bypassed any instructions I had and/or violating the license.

 

Some of this can be done through a custom device, however. You cannot control the emulation but you can interact with it, particularly with controllers, and it does support a network connection. It's mostly oriented toward features that an actual device could provide, so it doesn't provide access to things like the video output or main memory.

 

6 hours ago, drac030 said:

I think there may be something wrong with the debugger's interpretation of 65C816 code in the disassembler window. Here is what happens:

 

1) we have the debugger stopped at $0027F4:

2) we step through REP #$20 and stop at next instruction, the view changes (to the correct one):

3) then we make several steps further to reach SEP #$20 at $002800:

4) then we step through this instruction, and then the view changes back to the initial mess:

 

Note that there are no instructions between $27F4 and $2800 loading immediate data to accumulator, and the X bit does not change, so there seems to be no reason for the changes of the interpretation shown above.

 

This looks like an issue with M/X mode prediction that may be difficult to solve. The way the disassembly view works in 65C816 mode is that it uses the current M/X/E bits as a starting point and then predicts the M/X mode forward while disassembling instructions. In particular, it watches for REP, SEP, CLC, SEC, and XCE instructions. This allows it, for instance, to disassemble this sequence:

01:0001: C2 20     REP #$20
01:0003: A9 00 00  LDA #$0000
01:0006: E2 20     SEP #$20
01:0008: A9 00     LDA #$00
01:000A: 4C 00 00  JMP $0000

However, this can fail if REP/SEP instructions are picked up from adjacent routines not connected to the code flow leading to the current instruction. Another factor is that the disassembly view only regenerates the view whenever the focus address (PC) gets too far out of the view or the mode changes, both for efficiency and to avoid resetting the selection and scroll position of the view. You can see this by the location of the "reverse disassembly mismatch" notes, since that appears at the location where the view was originally centered. Due to previous control flow, your first image is actually using a higher address for view anchor than the second, as mode change from the REP reset the view anchor. My guess is that there was a REP/SEP instruction that just barely shifted into the view range after the REP instruction and then shifted out after the SEP.

 

In theory, the disassembler should be able to do a better job here as the previous instructions have straight-line flow to the PC and thus should share the X bit mode as the current state, which can then be projected backwards. This is tricky for the reverse disassembler, though, which has to try to disassemble backwards to get to a reasonable state for the start of the disassembly, above the PC. For instance, given a view anchor of $1080, the reverse disassembler's job is to try to find a starting point around $1000 or so that leads to a clean disassembly through $1080. Right now it simply assumes the current M/X/E bits for 65C816, and to do a better job with context-sensitive decoding it would need to follow multiple control flows backwards with independent states. This is also made harder by the 65C816 having no invalid opcodes. I'd have to think about this and try some approaches -- I'm not sure it would work out better than manual override or history-sensitive decoding.

 

[drac030]

On 10/7/2020 at 5:55 AM, phaeron said:

My guess is that there was a REP/SEP instruction that just barely shifted into the view range after the REP instruction and then shifted out after the SEP

If this helps, in the code listed above, there is indeed REP/SEP in the end of a subroutine which is located immediately before that one in the memory: REP #$10 at $27E7 and SEP #$23 at $27EE.

[phaeron]

http://www.virtualdub.org/beta/Altirra-4.00-test16.zip

http://www.virtualdub.org/beta/Altirra-4.00-test16-src.zip

• AltirraOS bumped to 3.29: NOCLIK is now implemented in XL/XE mode.
• Megacart (3) 512K banking fixed to only use bit 7 for disable.
• Fixed a crash that could occur if somehow a disk image got persisted in settings with an empty path.
• The Wine64 on macOS bug workaround has now been enabled by default -- it activates on the x64 build whenever a bad TEB pointer is detected and the program is running under Wine.
• Debugger: .diskreadsec command now always uses the virtual sector size, for consistency with .diskwritesec.
• Removed an unnecessary stat call in most file open paths and fixed some cases of poorly buffered disk image I/O.
• Fixed bug where some portions of the emulator like the Disk Explorer could not write to double-density boot sectors when formatted by a full drive emulator.
• Fixed bug where XFD image files were always completely rewritten on the first write instead of being incrementally updated.
• Fixed the FDC to use proper write track limits for 300 and 360 RPM disk drives. Removed a hack that had been put in to make the 1050 work, as it now properly runs the FDC in 8" mode as the real drive does.
• Fixed an FDC issue preventing the 1050 Duplicator firmware from formatting disks (waiting too long for initial byte write).
• ATX: Sectors are now properly sorted by ascending position when writing.
• ATX: Fixed bug where an unmatched extra sector info chunk would cause the parser to hang.
• ATX: Added experimental support for double density images. The specification for this is not yet finalized, so this is gated in Tools > Advanced Configuration > image.disk.atx.full_sector_support.

[Mclaneinc]

Blooming false positives, Windows said it can't download it securely....I disagreed and took it anyway...Wonder if I'm the only one..Not my av, windows own stuff.. 

 

All unzipped fine, no warnings, just the initial download restriction..

Edited October 9, 2020 by Mclaneinc

[Wilheim]

One observation I could see from at least version 3.90.

 

In Spiky Harold, I can see that the intro scrolling moves erraticaly, sometimes goes backwards every 4 frames. Instead, on real hardware it move smoothly.

 

Is there something I'm configuring wrong on Altirra?

[Mclaneinc]

Confirmed, tried numerous versions, silky smooth on real machine....Altirra properly setup..Tried many setups...

[flashjazzcat]

3 hours ago, Mclaneinc said:

Windows said it can't download it securely

Same here but I assumed this was because it's not an authenticated server.

[Mclaneinc]

I wondered if it was the latest Win 7 security patches released yesterday....Tried files from other places and they came down without a complaint..Good thing you could override the discard warning..

[+Eyvind Bernhardsen]

12 hours ago, phaeron said:

• The Wine64 on macOS bug workaround has now been enabled by default -- it activates on the x64 build whenever a bad TEB pointer is detected and the program is running under Wine.

Ah, nice! I can confirm that Altirra64 now runs under CrossOver.

[phaeron]

http://www.virtualdub.org/beta/Altirra-4.00-test17.zip

http://www.virtualdub.org/beta/Altirra-4.00-test17-src.zip

• Fixed horizontal scrolling issues with IR mode 3 (was caused by overdecoding).
• Added an option to invert data for the 815, to emulate the way it reads/writes data inverted from other drives.

 

[Xuel]

Feature request: Some kind of visualization for GTIA audio. Could the audio scope tap off of the audio chain after GTIA has been mixed in?

[drac030]

Debugger in 65C816 mode again:

 

 

Could something be done with it? COP seems to be interpreted twice (once as its opcode, the second time as its signature), which at first glance is pretty confusing, as the code looks like corrupted by loading error, relocation error or some other erroneous memory acccess.

[Wrathchild]

Feature request: similar to ".writemem" in the debugger, can a ".writecas" be produced that generates a cassette image file given a start address and length?

 

It would be the equivalent of the attached code which I used in addition to the some program code in order to dump it to a new tape image.

 

make_cas.s

Edited October 20, 2020 by Wrathchild

[phaeron]

On 10/17/2020 at 11:43 PM, Xuel said:

Feature request: Some kind of visualization for GTIA audio. Could the audio scope tap off of the audio chain after GTIA has been mixed in?

It's a bit tricky because of the way the GTIA audio is rendered: square waves are now rendered through a trick that fuses the integration of the square wave edges with the differentiator in the high pass filter, so there isn't actually a normally rendered version of the GTIA's audio output in the same domain that the POKEY output is currently shown in. I could tap downstream of the high pass filter but that would show different POKEY output than now (after the second high pass instead of only the first).

 

13 hours ago, drac030 said:

Debugger in 65C816 mode again:

 

 

Could something be done with it? COP seems to be interpreted twice (once as its opcode, the second time as its signature), which at first glance is pretty confusing, as the code looks like corrupted by loading error, relocation error or some other erroneous memory acccess.

Ah, yup, that's a bug in the disasm instruction length table. Fix queued for next build.

 

8 hours ago, Wrathchild said:

Feature request: similar to ".writemem" in the debugger, can a ".writecas" be produced that generates a cassette image file given a start address and length?

 

It would be the equivalent of the attached code which I used in addition to the some program code in order to dump it to a new tape image.

Well... dumping raw memory to a tape image seems like a bit of a niche. Could you elaborate on your use case?

 

[baktra]

17 hours ago, phaeron said:

It's a bit tricky because of the way the GTIA audio is rendered: square waves are now rendered through a trick that fuses the integration of the square wave edges with the differentiator in the high pass filter, so there isn't actually a normally rendered version of the GTIA's audio output in the same domain that the POKEY output is currently shown in. I could tap downstream of the high pass filter but that would show different POKEY output than now (after the second high pass instead of only the first).

 

Ah, yup, that's a bug in the disasm instruction length table. Fix queued for next build.

 

Well... dumping raw memory to a tape image seems like a bit of a niche. Could you elaborate on your use case?

 

That would interest me too. There is always the xex2cas 2.6 utility that can take the dump file created by writemem and make .cas of it. Despite its name, xex2cas can use plain file as input.

[Wrathchild]

 

38 minutes ago, baktra said:

There is always the xex2cas 2.6 utility that can take the dump file created by writemem and make .cas of it.

Yes, I had found that doing something similar via Turgen System was possible (xex->cas via 'Monolithic binary file to boot file') and that command line utility versions exists that could also be called as an extra step in the build process.