Altirra 2.90 released

[phaeron]

The CPU tracer maintains a context stack based on stack operations that occur and uses that to deduce the deferred VBI. To be specific, a deferred VBI is deduced when the I flag is cleared in an immediate VBI context. I suspect the reason for the false positive is the stack switching your multitasking kernel is doing. I'd have to take a look at whether the logic can be tweaked; this logic originally came from the existing profiler, which is constrained to produce a properly nested scope tree, but this might not have to.

 

The shaded area is indeed the vertical blank period. The frame boundary lines within the shaded areas correspond to Y=0.

 

Manual markers are possible but first I need to get the detailed CPU execution trace integrated. Capturing the trace is already done, but the hard part is factoring out the tree view code in the history pane. That code is really complex due to the call and loop detection and also because it's integrated into a custom tree view control, which was needed because the standard tree view control in the OS keeled over and died on 150K tree nodes.

[Heaven/TQA]

NRV... so any chance you work further on your Wolf?

[flashjazzcat]

The CPU tracer maintains a context stack based on stack operations that occur and uses that to deduce the deferred VBI. To be specific, a deferred VBI is deduced when the I flag is cleared in an immediate VBI context. I suspect the reason for the false positive is the stack switching your multitasking kernel is doing. I'd have to take a look at whether the logic can be tweaked; this logic originally came from the existing profiler, which is constrained to produce a properly nested scope tree, but this might not have to.

The VBI does test the I bit on the stack in a similar manner to the OS VBI code (though for a different reason: to establish whether mainline execution is currently in the kernel); not sure if that's used in a heuristic manner. I'll be changing that anyway since disabling IRQs inside the kernel isn't the best method of ensuring it's atomic.

[Faicuai]

CRASH REPORT (SCRAM does not work):

 

When having memory config=ULTIMATE, SDX=ON and loading Altirra Basic v1.54 as executable (via SDX's x command), SCRAM crashes with error "12" in line 7xxx during its main screen init.

 

What is interesting is that:

 

1. This problem DOES NOT occur if Altirra Basic is loaded as system cartridge.

2. This problem DOES NOT happen with Turbo Basic (when also loaded from SDX command prompt via X command).

3. Basic++ also fails to run SCRAM when loaded as executable, as well.

 

(SORRY if this one had been already reported... I am not aware of it).

 

Cheers!

[+DrVenkman]

CRASH REPORT (SCRAM does not work):

 

When having memory config=ULTIMATE, SDX=ON and loading Altirra Basic v1.54 as executable (via SDX's x command), SCRAM crashes with error "12" in line 7xxx during its main screen init.

 

What is interesting is that:

 

1. This problem DOES NOT occur if Altirra Basic is loaded as system cartridge.

2. This problem DOES NOT happen with Turbo Basic (when also loaded from SDX command prompt via X command).

3. Basic++ also fails to run SCRAM when loaded as executable, as well.

 

(SORRY if this one had been already reported... I am not aware of it).

 

Cheers!

 

Just out of curiosity, have you tried to load SCRAM on real hardware running either Altirra BASIC loaded from a U1MB in one of the "BASIC" slots or with BASIC++? Could be SCRAM just isn't compatible with some alternate BASICs, which wouldn't be Altirra's fault, really.

[atx4us]

phaeron,

 

I tried out the Graphical Performance Analyzer. It is seriously cool and useful! Can you please consider adding a Horizontal Scroll Bar?

 

Thanks.

[Faicuai]

 

(...) running either Altirra BASIC loaded from a U1MB in one of the "BASIC" slots or with BASIC++? Could be SCRAM just isn't compatible with some alternate BASICs, which wouldn't be Altirra's fault, really.

 

Already addressed in my tests. In fact, you don't need Ultimate for Altirra Basic to crash on SCRAM (crashes with MyDos either, with Ultimate disabled). And if you load Altirra Basic as cartridge (Firmware option) in Altirra, SCRAM works ok!.

 

​It is the loaded-executable form of Altirra Basic the problem. And it has to do with memory usage / mapping, and what Scram expects to find on it. Turbo Basic does NOT have this problem, as it runs Scram well.

[+DrVenkman]

 

Already addressed in my tests. In fact, you don't need Ultimate for Altirra Basic to crash on SCRAM (crashes with MyDos either, with Ultimate disabled). And if you load Altirra Basic as cartridge (Firmware option) in Altirra, SCRAM works ok.

 

​It is the loaded-executable form the problem. Turbo Basic does NOT have this problem, as it runs Scram well.

 

I think you're missing the point - it sounds like a SCRAM problem, not an Altirra problem, unless you can show that Altirra is operating differently than real hardware. Altirra BASIC is NOT "Atari BASIC" and Phaeron doesn't claim that it is.

[phaeron]

SCRAM has an assembly language routine running in vertical blank that occasionally writes to the $A000-BFFF region. This corrupts the disk-loaded version of the interpreter. It works fine with the ROM version because the ROM can't be overwritten. TurboBasic works because it loads into low memory and below the OS instead of high memory.

 

The loader for the tape version also hardcodes several entry points into the Atari BASIC ROM, but it is easily bypassed by just doing CLOAD twice.

 

[wesmond]

Hi Phaeron,

 

Apologies for reporting another potential tape issue - and maybe a weird one at that. I'm on Altirra 2.90 and I've got a WAV file which fails to load if Acceleration->C: Patch (SIO) is enabled, but loads fine if that is disabled - thus taking 7 minutes or so, which is quite nostalgic. (Pressing F1 while loading non-accelerated works ok). Obviously a very low priority issue!

 

The tape is an odd one - it's Tank Commander, the Creative Sparks release; it has non-standard block lengths, non-standard gaps, and grubby noise between blocks that could be motor stop/start - maybe the master was written using code that started/stopped the tape motor when it wanted, and a similar sort of behaviour happens when it loads. (I think River Rescue is another that might have done the same, including Alternative's re-release). I've put a copy of the WAV here - http://www.teapotrecords.co.uk/tmp/tc.zip

 

On a related note - anyone have any ideas how to get a .CAS file out of this? I'm not getting anywhere close with a8cas/wav2cas...

 

Thanks,

Wes

[Faicuai]

SCRAM has an assembly language routine running in vertical blank that occasionally writes to the $A000-BFFF region. This corrupts the disk-loaded version of the interpreter. It works fine with the ROM version because the ROM can't be overwritten. TurboBasic works because it loads into low memory and below the OS instead of high memory.

 

The loader for the tape version also hardcodes several entry points into the Atari BASIC ROM, but it is easily bypassed by just doing CLOAD twice.

 

 

THANKS!

​

Any way to load and execute Altirra Basic out of $A000-$BFFF address space? (like Turbo Basic) Is it coded in a way that cannot be relocated around?

 

I really think Altirra Basic is very nice (and faster as interpreter than anything I have seen, especially with the "lights off")... and it would be great to have Atari Basic-C as the classic default basic in Incognito / Ultimate slots (I use others for Assembler, Star Raiders, etc.). Then be able to load any other basic (as needed) from SDX prompt (currently my standard operational environment).

 

Cheers!

[Keatah]

Bug report:

 

Altirra takes up too much of my time. Any forthcoming fixes or patches? Maybe a point release?

[atx4us]

phaeron,

 

I tried out the Graphical Performance Analyzer. It is seriously cool and useful! Can you please consider adding a Horizontal Scroll Bar?

 

Thanks.

Quoting myself to keep the comments together.

 

phaeron,

 

Is it also possible to add P/M Graphics information (graphics data, locations, collisions, etc.) to the Graphical Performance Analyzer?

 

Thanks.

[phaeron]

Apologies for reporting another potential tape issue - and maybe a weird one at that. I'm on Altirra 2.90 and I've got a WAV file which fails to load if Acceleration->C: Patch (SIO) is enabled, but loads fine if that is disabled - thus taking 7 minutes or so, which is quite nostalgic. (Pressing F1 while loading non-accelerated works ok). Obviously a very low priority issue!

 

The tape is an odd one - it's Tank Commander, the Creative Sparks release; it has non-standard block lengths, non-standard gaps, and grubby noise between blocks that could be motor stop/start - maybe the master was written using code that started/stopped the tape motor when it wanted, and a similar sort of behaviour happens when it loads. (I think River Rescue is another that might have done the same, including Alternative's re-release). I've put a copy of the WAV here - http://www.teapotrecords.co.uk/tmp/tc.zip

 

On a related note - anyone have any ideas how to get a .CAS file out of this? I'm not getting anywhere close with a8cas/wav2cas...

 

The noise between the blocks is indeed the problem:

 

 

The acceleration loader is picking up the noise as a sync mark by mistake. I'll have to check the IRG handling as it's possible that the accel loader isn't properly waiting for the defined IRG time. This is probably what's also confusing a8cas, which has to guess the length of blocks since it can't see the behavior of the loader.

 

Any way to load and execute Altirra Basic out of $A000-$BFFF address space? (like Turbo Basic) Is it coded in a way that cannot be relocated around?

 

I really think Altirra Basic is very nice (and faster as interpreter than anything I have seen, especially with the "lights off")... and it would be great to have Atari Basic-C as the classic default basic in Incognito / Ultimate slots (I use others for Assembler, Star Raiders, etc.). Then be able to load any other basic (as needed) from SDX prompt (currently my standard operational environment).

 

Possible, I haven't looked into it.

 

Bug report:

 

Altirra takes up too much of my time. Any forthcoming fixes or patches? Maybe a point release?

 

I find this is effective at limiting the time I spend on Altirra: https://www.factorio.com/

 

[Mclaneinc]

Nice game but it needs a brain and me and my one marble and a bit of dust in the skull would find that too much, Settlers on the Amiga was my high point of that sort of gaming

 

Happy to see you have free time for you Avery...Good on you..

[voy]

On a related note - anyone have any ideas how to get a .CAS file out of this? I'm not getting anywhere close with a8cas/wav2cas...

 

I converted this WAV to CAS using a8cas-convert by Krótki, cleaned with Notepad++, then I extracted data to binary file using Turgen System by Baktra. Finally, I added $FF $FF header with HexEdit.

 

Here you are...

Tank Commander by Creative Sparks (CAS nad XEX).zip

[wesmond]

Wow, nice work Voy!

 

Just for info - Altirra needs the C: patch disabled to load the CAS file too...

[Heaven/TQA]

Avery...maybe I am stupid but I did not managed to get Eidolon run in Altira 2.9 and 2.99 latest test...

 

http://a8.fandal.cz/detail.php?files_id=4544

 

ah what a sh..t... you have to disable to jump into debugger when BRK hit...

Edited August 18, 2017 by Heaven/TQA

[baktra]

 

I converted this WAV to CAS using a8cas-convert by Krótki, cleaned with Notepad++, then I extracted data to binary file using Turgen System by Baktra. Finally, I added $FF $FF header with HexEdit.

 

Here you are...

 

 

Good job.

THORN EMI used very impractical way of storing TANK COMMANDER to tape. Long IRGs for no reason wasting your time.

The .xex file probably needs some "polishing" My .xex analyzer reports negative segment size. Perhaps some mess close to the end of the file.

[Wrathchild]

2.99 test 5 - I wasn't expecting the break when $29A4 was written too. Is this broken?

 

Altirra> bx read=$29a4

Breakpoint 2 set on read from $29A4.

Breakpoint 2 hit

(9228: 44, 47) A=80 X=01 Y=00 S=F7 P=32 ( Z ) 1F33: B1 16 LDA (BUFADR+1),Y [$29A4] = $50

Breakpoint 2 hit

(10072: 75, 26) A=A5 X=24 Y=A4 S=FD P=F1 (NV C) 63BA: B1 82 L63BA LDA ($82),Y [$29A4] = $09

Breakpoint 2 hit

(10072: 75, 46) A=50 X=24 Y=A4 S=FD P=71 ( V C) 63C4: 91 82 STA ($82),Y [$29A4]

Breakpoint 2 hit

(10093:186,113) A=D0 X=3A Y=A4 S=FD P=B0 (N ) 63E3: B1 82 L63E3 LDA ($82),Y [$29A4] = $50

Breakpoint 0 hit

(10297:252, 66) A=00 X=01 Y=FF S=F6 P=32 ( Z ) 2799: 20 37 29 L2799 JSR $2937 [$2937] = $AD

Altirra> bl

Breakpoints:

0 PC 2799

1 PC 27CD

2 R 29A4

[flashjazzcat]

Is this not read-modify-write side-effect?

[phaeron]

STA (zp),Y does a false read:

1. Read opcode
2. Read page zero address
3. Read address low
4. Read address high
5. False read from address+Y without carry to high byte
6. Write to address+Y

The data from the false read in cycle 5 is not used, but the rest of the system can't tell the difference. For instance:

LDA #$80
STA $A0
LDA #$D5
STA $A1
LDY #$C0
LDA #0
STA ($A0),Y

This does a read from $D540 before writing to $D640. Any cartridge in the system that responds to $D5xx isn't going to know or care that this is a false read; it looks like any other read cycle and it can trip a bank switch. This is important when accessing hardware registers, particularly autoincrementing data ports -- an indexed store can double-increment the implicit address in the data port.

[mono]

Is the Altirra able to catch that false access when I set BA R D540 L1 breakpoint?

[phaeron]

Is the Altirra able to catch that false access when I set BA R D540 L1 breakpoint?

 

Yes.

 

Altirra:0> r pc 600
Altirra:0> a 600
0600: 91 A0          sta ($a0),y
0602: end
Altirra:0> r y c0
Altirra:0> ew a0 d580
Altirra:0> r
(1195:  0,  0) A=0F X=F1 Y=C0 S=F3 P=34 (   I  )  0600: 91 A0             STA ($A0),Y  [$D640]
Altirra:0> ba r d540
Breakpoint 0 set on read at D540.
Altirra:0> t
Breakpoint 0 hit
(1195:  0,  5) A=0F X=F1 Y=C0 S=F3 P=34 (   I  )  0600: 91 A0             STA ($A0),Y  [$D640]

"ba r d540", "ba r d540 L1", and "bx read=$d540" are equivalent, by the way.

 

[mono]

Great feature! Thank you.