Altirra 4.20 released

[jenorton]

23 minutes ago, MrFish said:

The ghosts are more aggressive in the 5200 version than in the 8-bit computer version of Atari Pac-Man. As far as I know, there is no way to change the difficulty.

 

OK.

 

I get it.  I found a scan of the manual and it says to press "Game Level", but, I'm not sure which key that corresponds to in Altirra in the 5200 mode only using the keyboard.

 

Thanks!

[+MrFish]

7 minutes ago, jenorton said:

OK.

 

I get it.  I found a scan of the manual and it says to press "Game Level", but, I'm not sure which key that corresponds to in Altirra in the 5200 mode only using the keyboard.

 

Thanks!

According to the overlay, the <"#"> key is game level button; but that's to change from cherries to strawberries etc., not to change the difficulty for any given level. Obviously, the difficulty changes as you change levels, but that's not the same thing.

 

[yetanothertroll]

Hey, I think I found an audio issue in /x64 4.20 at least in Windows 10.0.19045.3930 (this month's update damned near bricked my Dell, soo...) and emulating an 800 OS-B NTSC / 48K. After too many Windows hibernate cycles, the audio cuts out in the emulator. Sound from Windows messageboxes is OK, and sound is still recorded properly to video and audio recordings. Sound from diskette access, cassette access, and the Logo TOOT command are affected. I'll try BASIC in the next couple of days once my current Logo program completes   (Sometimes Logo doesn't like having its state saved and reloaded, but it doesn't get along with Colleen either, so I guess it's just finicky?) Switching the Windows system audio between devices doesn't fix it, if that info helps

[phaeron]

4 hours ago, yetanothertroll said:

Hey, I think I found an audio issue in /x64 4.20 at least in Windows 10.0.19045.3930 (this month's update damned near bricked my Dell, soo...) and emulating an 800 OS-B NTSC / 48K. After too many Windows hibernate cycles, the audio cuts out in the emulator. Sound from Windows messageboxes is OK, and sound is still recorded properly to video and audio recordings. Sound from diskette access, cassette access, and the Logo TOOT command are affected. I'll try BASIC in the next couple of days once my current Logo program completes   (Sometimes Logo doesn't like having its state saved and reloaded, but it doesn't get along with Colleen either, so I guess it's just finicky?) Switching the Windows system audio between devices doesn't fix it, if that info helps

My guess is that something during the hibernation cycle is causing the default audio device to drop out and be recreated. Generally the Windows audio system covers for this, but sometimes it results in hiccups that cause applications to lose the audio device. Altirra is playing a continuous audio stream from the start, so it doesn't benefit from the inherent reset that occurs when playing one-shot sounds like the messagebox does. The fact that you can record sound but not hear it implies that it's an audio API issue since the emulator's audio mixing pipeline is still working.

 

One thing you can try is switching the default audio API from to WASAPI if it is not already that or Auto. This setting is under System > Configure System > Audio > Host audio options... > Audio API. In particular, it may be set to WaveOut, which is generally reliable but also pretty old. WASAPI is the newer API and also Altirra directly sees audio output change events when using it, so it's more likely to be able to recover from the audio device dropping out. The default being WaveOut is historical and I'll probably switch it over now that Windows XP is no longer supported.

 

[yetanothertroll]

Also in x64 4.20, if I have a modified tape loaded, Boot Image... will warn me about it but Recently Booted will simply discard the tape. Thanks again for listening to tape boy lol

[scotty]

Question on the lost Atari models....  So I created a virtual 1450XLD for the first time, even though it has been available for a few months now.  Too many other projects going on.    Anyhow...  WHen I use the 1450 TONG controller it gives me a message "Please Insert Disk, and close drive latch  Or if you do not want disks, press return".  OK, so the obvious question, is there a switch, or key combination to close the latch?  I was thinking it might be under console switches, but nothing there.

 

2nd question....This is going WAAAAAY back...  I vaguely remember reading that the disk controller in the 1450XLD was a lot faster than a 1050 drive.  Trying the other 1450 disc controller, I really do not notice a speed difference.  Sure, I could click on the SIO handler, and get the near instant load times, but I want to play with a system close to the original.   I also noticed the regular controller does not have the loading beeps.  Is this normal??

[Ricky Spanish]

Hi,

Please forgive my ignorance but I can't get the 1400XL aspect working.

I applied the 1400xl bin (found somewhere on this site), yet can't get

it to show under 'operating system'.

Here's a screenshot. Any help would be greatly appreciated. Thank-you.

 

[phaeron]

22 hours ago, scotty said:

Question on the lost Atari models....  So I created a virtual 1450XLD for the first time, even though it has been available for a few months now.  Too many other projects going on.    Anyhow...  WHen I use the 1450 TONG controller it gives me a message "Please Insert Disk, and close drive latch  Or if you do not want disks, press return".  OK, so the obvious question, is there a switch, or key combination to close the latch?  I was thinking it might be under console switches, but nothing there.

The drive latch is just the lever that closes the disk drive mechanism, like on the 1050. It's connected to the "ready" input on the disk controller chip. To close it in Altirra you just need to mount a disk image.

 

22 hours ago, scotty said:

2nd question....This is going WAAAAAY back...  I vaguely remember reading that the disk controller in the 1450XLD was a lot faster than a 1050 drive.  Trying the other 1450 disc controller, I really do not notice a speed difference.  Sure, I could click on the SIO handler, and get the near instant load times, but I want to play with a system close to the original.   I also noticed the regular controller does not have the loading beeps.  Is this normal??

The 1450XLD disk controller could be a lot faster than the 1050, but since it has no track buffer, it's only as fast as the sector interleave order on the disk. This means that if you take a standard disk formatted by a 1050 and stick it in a 1450XLD, it can't run any faster -- the computer will read each sector super-quick, only to just wait longer for the next sector to arrive under the head. Unfortunately the 1450XLD controller also has no provision for formatting with a fast skew, so disks that it formats don't read any faster than normal. If anyone has seen a real 1450XLD reading a standard interleaved disk fast, I'd be interested as it's hard for the controller to do so when it has neither prefetch nor any memory or code to buffer a track.

 

You can format a disk with a faster skew on another disk drive, though, and that will read a lot faster. The fastest that the 1450XLD can read single density is 2:1 interleave, which is still half of max throughput but way faster than any SIO-based disk drive. The issue in emulation is that ATR images don't encode sector order, so whenever you mount an ATR, it'll always use standard interleave. You can either save disks in ATX format after formatting on a drive that can do fast sector skew, or use the built-in option to reinterleave the disk:

 

 

6 hours ago, Ricky Spanish said:

Hi,

Please forgive my ignorance but I can't get the 1400XL aspect working.

I applied the 1400xl bin (found somewhere on this site), yet can't get

it to show under 'operating system'.

Here's a screenshot. Any help would be greatly appreciated. Thank-you.

 

You have three problems in that screenshot:

• The 1400XLOS.BIN you have is set to the wrong ROM image type. It needs to be set as an XL/XE OS image, not a 1400XL/XLD Handler ROM. You can change this by double-clicking the entry or choosing Settings... and changing the ROM image type.
• The label on that 1400XLOS.BIN image indicates that Altirra has auto-detected it by CRC32 as the same as the bog-standard v2 ATARIXL.ROM image that everyone uses for XL/XE machines. You can use it for 1400XL/1450XLD emulation, but there is nothing 1400/1450 specific about it and using it over any other regular XL/XE OS will not give any special 1400XL behavior.
• You don't have the handler ROM for the 1400XL built-in voice and modem devices, which is part of what does make the 1400XL different than a plain 800XL. This is a separate 4K ROM than the OS ROM and you can't use an OS ROM for it. Note that Altirra does not emulate the voice device; the voice handler will run with simulated times, but it does not generate audio output.

 

[scotty]

12 hours ago, phaeron said:

The drive latch is just the lever that closes the disk drive mechanism, like on the 1050. It's connected to the "ready" input on the disk controller chip. To close it in Altirra you just need to mount a disk image.

 

The 1450XLD disk controller could be a lot faster than the 1050, but since it has no track buffer, it's only as fast as the sector interleave order on the disk. This means that if you take a standard disk formatted by a 1050 and stick it in a 1450XLD, it can't run any faster -- the computer will read each sector super-quick, only to just wait longer for the next sector to arrive under the head. Unfortunately the 1450XLD controller also has no provision for formatting with a fast skew, so disks that it formats don't read any faster than normal. If anyone has seen a real 1450XLD reading a standard interleaved disk fast, I'd be interested as it's hard for the controller to do so when it has neither prefetch nor any memory or code to buffer a track.

 

You can format a disk with a faster skew on another disk drive, though, and that will read a lot faster. The fastest that the 1450XLD can read single density is 2:1 interleave, which is still half of max throughput but way faster than any SIO-based disk drive. The issue in emulation is that ATR images don't encode sector order, so whenever you mount an ATR, it'll always use standard interleave. You can either save disks in ATX format after formatting on a drive that can do fast sector skew, or use the built-in option to reinterleave the disk:

 

 

You have three problems in that screenshot:

• The 1400XLOS.BIN you have is set to the wrong ROM image type. It needs to be set as an XL/XE OS image, not a 1400XL/XLD Handler ROM. You can change this by double-clicking the entry or choosing Settings... and changing the ROM image type.
• The label on that 1400XLOS.BIN image indicates that Altirra has auto-detected it by CRC32 as the same as the bog-standard v2 ATARIXL.ROM image that everyone uses for XL/XE machines. You can use it for 1400XL/1450XLD emulation, but there is nothing 1400/1450 specific about it and using it over any other regular XL/XE OS will not give any special 1400XL behavior.
• You don't have the handler ROM for the 1400XL built-in voice and modem devices, which is part of what does make the 1400XL different than a plain 800XL. This is a separate 4K ROM than the OS ROM and you can't use an OS ROM for it. Note that Altirra does not emulate the voice device; the voice handler will run with simulated times, but it does not generate audio output.

 

Thank you for the clarification.
 

[Ricky Spanish]

On 12/29/2023 at 6:04 PM, phaeron said:

https://www.virtualdub.org/altirra.html

Hi. Not complaining, but on page 36 under GRAPHICS in the manual it states:

 

Table 2: Graphics modes Modes 9-15 are only available on the 600XL, 800XL, 800XE, 65XE, 130XE, and XEGS. The 400, 800, and 1200XL only support modes 0-8 with the standard OS.

 

The 1200XL supports GR. MODES 9-15 as well. 

[phaeron]

1 hour ago, Ricky Spanish said:

Hi. Not complaining, but on page 36 under GRAPHICS in the manual it states:

 

Table 2: Graphics modes Modes 9-15 are only available on the 600XL, 800XL, 800XE, 65XE, 130XE, and XEGS. The 400, 800, and 1200XL only support modes 0-8 with the standard OS.

 

The 1200XL supports GR. MODES 9-15 as well. 

Ah, in the Altirra BASIC manual? Yeah, that's wrong, I'll fix it.

[bigfriendly]

I tinkered with this thing for a long time yesterday and I finally started to figure things out when it comes to mapping the controller. I wanted to use my regular CX-40 with 5200 games and map the other buttons to the keyboard. On games that are simple like Joust and Berzerk when you only need a joystick and one button to play I figured those out. However, Star Raiders is a totally different beast altogether. I haven't played Star Raiders in probably about 40 years so I have been looking at the manual online to try to figure things out. When I start my game I can't get to the point where I turn on my shields, attack computer etc. All of the number keys just change the speed that your engines are running when you first start the game. I noticed when I looked at the joystick insert that the engine speed 1-9 and all of the other ship commands are on the number pad so there must be a button in the game that switches from the engines to the other options on the controller so you can power up your computer, shields etc. I must be missing something and damn it I'm going to figure it out. As you can tell I'm not a techie type so it takes me a bit longer but this emulator does seem pretty deep and kick ass. Has anybody ever used this to emulate the 7800 before? 

Edited March 4 by bigfriendly

[phaeron]

6 hours ago, bigfriendly said:

I tinkered with this thing for a long time yesterday and I finally started to figure things out when it comes to mapping the controller. I wanted to use my regular CX-40 with 5200 games and map the other buttons to the keyboard. On games that are simple like Joust and Berzerk when you only need a joystick and one button to play I figured those out. However, Star Raiders is a totally different beast altogether. I haven't played Star Raiders in probably about 40 years so I have been looking at the manual online to try to figure things out. When I start my game I can't get to the point where I turn on my shields, attack computer etc. All of the number keys just change the speed that your engines are running when you first start the game. I noticed when I looked at the joystick insert that the engine speed 1-9 and all of the other ship commands are on the number pad so there must be a button in the game that switches from the engines to the other options on the controller so you can power up your computer, shields etc.

The asterisk (*) button is used to toggle between speed and non-speed controls. The default keyboard mapping in Altirra maps this to the - key, next to 0. You'll probably want to come up with a more ergonomic mapping for the game, probably using the keypad (if you have one!). You can detach the cartridge and use the controller test that appears to verify the mapping to the original 5200 controllers.

6 hours ago, bigfriendly said:

Has anybody ever used this to emulate the 7800 before?

Altirra doesn't emulate the 7800, it's a completely different architecture. The 7800 is a 2600 duct-taped to a Jaguar predecessor.

[bigfriendly]

7 hours ago, phaeron said:

The asterisk (*) button is used to toggle between speed and non-speed controls. The default keyboard mapping in Altirra maps this to the - key, next to 0.

Thanks for your response. OK, in the attached pics if I'm reading it correctly the # aka the pound key on the bottom right is the button to press to select control mode in the game. When I do this in the emulator the game freezes up. I've tried mapping it to different keys on my keyboard and the game always locks up. Now it works when you first boot the game up because you also use that key to select the difficulty level novice, pilot etc. But after you start the game when you press it, it just freezes the screen. Could this be a bug or glitch in the program? I'm using Windows 11.

[Alfred]

I've run into an odd quirk in 65816 mode with regards to the stack. Code is simplified here for the example.

 

; IN NATIVE 8/8 MODE

3C50  JSR $A809  ->> leads to A8D3 via JMP 

        ......

 

 

; ACC IS 16 BIT HERE
A8D3 PLA
        STA $A9BB

A9BB  $3152      ?? 

 

Should be at least $3Cxx, should it not ? This is 4.30 test6.

[drac030]

1 hour ago, Alfred said:

Should be at least $3Cxx, should it not ? This is 4.30 test6.

It should be $3C52, but it is $3152. So the question is: is acc really 16-bit at $A8D3? Especially if the JSR is being done "IN NATIVE 8/8 MODE"...

Edited March 5 by drac030

[Alfred]

20 minutes ago, drac030 said:

It should be $3C52, but it is $3152. So the question is: is acc really 16-bit at $A8D3? Especially if the JSR is being done "IN NATIVE 8/8 MODE"...

It really is, I've left out the various SEP/REP and other instructions to simplify the example.

 

The full code is:

 

ABEND    PHP                 SAVE CALLER STATE          
;                                                       
         .ALLW                                          
;                                                       
; SAVE ALL REGS AS WORD SIZE                            
;                                                       
         STA SAVEA                                      
         STX SAVEX                                      
         STY SAVEY                                      
;                                                       
; PUT CALLER'S JSR ADDRESS INTO TERCOD.                 
;                                                       
;        TSX                   X = STKREG.              
;        LDA $101,X            LOW BYTE.                
         PLA                   PULL CALLER RETURN       
         STA CALLER            PUT IN LSB POSITION.     
;                                                       
         .ALLB                                          
;                                                       
         PLA                                            
         STA PSTATUS   PROCESSOR STATUS                 
;                                                       
         PHK                                            
         PLA                                            
         STA CALLER+2    CALLER'S BANK                  
------------------------------------------

 

I was getting $0303 using the stack extract, so I changed it to the PLA version and it's still wonky. I need to play with it some more to try and understand what's going on with the stack pointer.

Edit: yes, I understand the PHK isn't really the caller's bank, it just is in this case.

Edited March 5 by Alfred

[drac030]

Does .ALLW imply/execute REP #$30 and .ALLB - SEP #$30?

 

If so, then you are first pushing the P register status onto the stack (PHP in the first line), then you are pulling "CALLER RETURN", but in fact you are pulling the P byte + a part of the return address with that? Then the next PLA gets the other byte of the return address instead of the P register byte. These need to be swapped, PLA-byte first to get the P register status, then PLA-word next to get the return address, no?

[Alfred]

1 hour ago, drac030 said:

Does .ALLW imply/execute REP #$30 and .ALLB - SEP #$30?

 

If so, then you are first pushing the P register status onto the stack (PHP in the first line), then you are pulling "CALLER RETURN", but in fact you are pulling the P byte + a part of the return address with that? Then the next PLA gets the other byte of the return address instead of the P register byte. These need to be swapped, PLA-byte first to get the P register status, then PLA-word next to get the return address, no?

You're absolutely right. I figured it had to be my code but I wasn't seeing it. Thanks.

[Alfred]

Ok, so the PLA version works, but when I change the sequence back to the stack version:

 

; all regs 16 bit

    TSX

    LDA $0102,X

    STA CALLER

 

I get $0000  in CALLER. $0100,X should be the next free stack byte, $0101,X is the PHP byte, so $0102,X ought to be the first byte of the return address. What am I missing here K, why am I not seeing $3C52 in the stack version ?

 

edit: NM, in changing the code up I made a mistake about the stack. Both versions work correctly now.

Edited March 6 by Alfred
found error

[phaeron]

15 hours ago, bigfriendly said:

Thanks for your response. OK, in the attached pics if I'm reading it correctly the # aka the pound key on the bottom right is the button to press to select control mode in the game. When I do this in the emulator the game freezes up. I've tried mapping it to different keys on my keyboard and the game always locks up. Now it works when you first boot the game up because you also use that key to select the difficulty level novice, pilot etc. But after you start the game when you press it, it just freezes the screen. Could this be a bug or glitch in the program? I'm using Windows 11.

If you are using Altirra 4.20, there is a regression in that version that causes this lockup; it's a bug in that version of the emulator that interacts with another bug in the game (Star Raiders 5200 accesses a nonexistent PIA chip). I'm going to be releasing a 4.21 release to address this and a few other bugs, but in the meantime the latest 4.30-test release also has the fix. You can find the test releases either further up in this thread, or by using the Help > Check For Updates menu option with the update channel changed from Release to Test (which will just link back to the latest relevant post in this thread).

[baktra]

On 2/13/2024 at 1:40 PM, w1k said:

Hi, Phaeron

I know Altirra know playing czechoslovakia TURBO 2000 tape system, i want ask if you plan add support Slovak rare TURBO D/DNM ? i have audio files, and technical infos (but only in slovak language)

 

On 2/14/2024 at 7:25 PM, baktra said:

Well, you will not expect Phaeron to go through the documentation in Slovak language (and mostly scans that are not so easy to translate) and come up with support for a rare system out of the blue, won't you? That would be naive.

 

I believe such request must come on a silver plate with the following information:

1. What is the modulation style (how the 0 and 1 are translated to the electric signal and back)
2. How the data recorder is switched to turbo mode (if it is applicable)
3. How the signal goes to the computer (SIO, Joystick Port, etc.)
4. Sample recording
5. Sample loader and instructions on how to use it.

This is the bare minimum. It still doesn't guarantee that a request would be granted.

It also very much depends on how much work it would require, how it would fit in the current code that supports turbo systems. And last, but not least, the business value of the enhancement must be taken into account.

 

Let me do some digging first. If I collect sufficient information, we can get back to this matter.

I am getting back to the matter of Turbo D.

I have answers to the questions above.

1. The modulation is the same as for the other "Turbo" systems. Wide and Narrow rectangular pulses are used to encode 1s and 0s
2. There is no explicit switching to turbo mode, because a "non-standard" input path is used (like Turbo 6000 and Rambit)
3. The signal goes to the computer through joystick port #2, pin 1 (joystick up). The loader is polling the joystick port as follows: LDA #$10 : BIT PORTA : BEQ/BNE <address>, when DMA and interrupts are off.
   It is the same as the existing (Joystick Port 2;KSO Turbo 2000) decoder, except a different pin of the joystick port is used. The loader expects certain polarity of pulses. Motor is controlled normally, using MOTOR CTRL.

@phaeron, if you would be interested in adding support for Turbo D to Altirra, I can provide a sample recording, loader and instructions on how to use them (#4 and #5). Be advised, the user base of Turbo D is 2–3 users only. Some indication of the business value. On the other hand, I do not believe that the user base of the already supported turbo systems is much larger.

 

Thank you

[bigfriendly]

18 hours ago, phaeron said:

If you are using Altirra 4.20, there is a regression in that version that causes this lockup; it's a bug in that version of the emulator that interacts with another bug in the game (Star Raiders 5200 accesses a nonexistent PIA chip). I'm going to be releasing a 4.21 release to address this and a few other bugs, but in the meantime the latest 4.30-test release also has the fix. You can find the test releases either further up in this thread, or by using the Help > Check For Updates menu option with the update channel changed from Release to Test (which will just link back to the latest relevant post in this thread).

Unfortunately, I got the same result when using 4.30😞

[phaeron]

2 hours ago, bigfriendly said:

Unfortunately, I got the same result when using 4.30😞

4.30-test4 is old and predates the fix, latest is 4.30-test7:

 

[drpeter]

@phaeron

 

While messing about with wide playfields recently, I noticed something I didn't expect:

 

When horizontally scrolling a 48 byte wide playfield, the 4 bits of 'garbage' at the extreme right border that show up on extended overscan scroll out of view when HSCROL is 2,3,6,7,10,11,14, or 15.

 

This gives a usable playfield width without 'garbage' of 178 rather than 176 color clocks.

 

I've been unable to confirm this behaviour on real hardware because I have no monitor that will show extended overscan.

 

Is this correct?

 

I ask in particular because there's been discussion recently of making use of these 2 'garbage' color clocks in static images by ensuring predictable data on the bus at the critical moment, using DLI or screen kernel techniques. Just scrolling the relevant mode lines 10 color clocks (10 rather than 6 or 2 so as to to minimise 6502 cycles 'stolen' by DMA) would seem a very much simpler means to the same end...

Edited April 4 by drpeter