Jump to content

Photo

Altirra 2.90 released

altirra emulation

157 replies to this topic

#126 phaeron OFFLINE  

phaeron

    River Patroller

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

Posted Thu Aug 10, 2017 10:26 PM

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.



#127 Heaven/TQA ONLINE  

Heaven/TQA

    Quadrunner

  • 10,220 posts
  • Location:Baden-Württemberg, Germany

Posted Fri Aug 11, 2017 4:43 AM

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



#128 flashjazzcat OFFLINE  

flashjazzcat

    Quadrunner

  • 12,535 posts
  • Location:United Kingdom

Posted Fri Aug 11, 2017 5:06 AM

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.

#129 Faicuai OFFLINE  

Faicuai

    Dragonstomper

  • 682 posts
  • Location:Florida, U.S.A.

Posted Fri Aug 11, 2017 4:51 PM

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!



#130 DrVenkman ONLINE  

DrVenkman

    River Patroller

  • 2,133 posts
  • Back off, man! I'm a scientist.
  • Location:KMBT

Posted Fri Aug 11, 2017 5:23 PM

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.



#131 atx4us OFFLINE  

atx4us

    Moonsweeper

  • 432 posts
  • Location:Michigan, USA

Posted Fri Aug 11, 2017 6:01 PM

phaeron,

 

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

 

Thanks.



#132 Faicuai OFFLINE  

Faicuai

    Dragonstomper

  • 682 posts
  • Location:Florida, U.S.A.

Posted Fri Aug 11, 2017 6:14 PM

 

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



#133 DrVenkman ONLINE  

DrVenkman

    River Patroller

  • 2,133 posts
  • Back off, man! I'm a scientist.
  • Location:KMBT

Posted Fri Aug 11, 2017 6:16 PM

 

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.



#134 phaeron OFFLINE  

phaeron

    River Patroller

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

Posted Fri Aug 11, 2017 10:08 PM

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.

 



#135 wesmond OFFLINE  

wesmond

    Star Raider

  • 79 posts
  • Location:London, UK

Posted Sat Aug 12, 2017 1:32 PM

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



#136 Faicuai OFFLINE  

Faicuai

    Dragonstomper

  • 682 posts
  • Location:Florida, U.S.A.

Posted Sat Aug 12, 2017 1:51 PM

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!



#137 Keatah OFFLINE  

Keatah

    Quadrunner

  • 17,677 posts

Posted Sat Aug 12, 2017 1:51 PM

Bug report:

 

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



#138 atx4us OFFLINE  

atx4us

    Moonsweeper

  • 432 posts
  • Location:Michigan, USA

Posted Sat Aug 12, 2017 2:48 PM

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.



#139 phaeron OFFLINE  

phaeron

    River Patroller

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

Posted Sat Aug 12, 2017 3:18 PM

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.teapotrec...o.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:

 

dropout.png

 

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/

 



#140 Mclaneinc OFFLINE  

Mclaneinc

    River Patroller

  • 4,884 posts
  • Location:Northolt, UK

Posted Sun Aug 13, 2017 4:36 AM

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



#141 voy OFFLINE  

voy

    Chopper Commander

  • 172 posts
  • admin of ftp.pigwa.net, ASMA Team member
  • Location:Zawiszów, Poland

Posted Sun Aug 13, 2017 9:40 AM

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

 

Here you are... icon_smile.gif

Attached Files



#142 wesmond OFFLINE  

wesmond

    Star Raider

  • 79 posts
  • Location:London, UK

Posted Sun Aug 13, 2017 10:42 AM

Wow, nice work Voy!

 

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


  • voy likes this

#143 Heaven/TQA ONLINE  

Heaven/TQA

    Quadrunner

  • 10,220 posts
  • Location:Baden-Württemberg, Germany

Posted Fri Aug 18, 2017 12:46 PM

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/...p?files_id=4544

 

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


Edited by Heaven/TQA, Fri Aug 18, 2017 12:52 PM.


#144 baktra OFFLINE  

baktra

    Moonsweeper

  • 325 posts
  • Location:Czech republic

Posted Fri Aug 18, 2017 4:14 PM

 

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

 

Here you are... icon_smile.gif

 

 

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.



#145 Wrathchild OFFLINE  

Wrathchild

    Stargunner

  • 1,830 posts
  • Location:Reading, UK.

Posted Fri Aug 18, 2017 5:19 PM

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     


#146 flashjazzcat OFFLINE  

flashjazzcat

    Quadrunner

  • 12,535 posts
  • Location:United Kingdom

Posted Fri Aug 18, 2017 5:33 PM

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

#147 phaeron OFFLINE  

phaeron

    River Patroller

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

Posted Fri Aug 18, 2017 11:39 PM

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.



#148 mono OFFLINE  

mono

    Star Raider

  • 67 posts

Posted Sat Aug 19, 2017 4:41 AM

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



#149 phaeron OFFLINE  

phaeron

    River Patroller

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

Posted Sat Aug 19, 2017 4:48 AM

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.

 



#150 mono OFFLINE  

mono

    Star Raider

  • 67 posts

Posted Sat Aug 19, 2017 5:08 AM

Great feature! Thank you.







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

2 user(s) are browsing this forum

1 members, 1 guests, 0 anonymous users