Altirra 4.20 released

[reifsnyderb]

1 hour ago, phaeron said:

You're hitting a bug in the Atari OS. The cassette handler has an issue where there is a small chance with every block that it will miscompute the baud rate, causing the next block read to fail. The chance for this in NTSC is about 1-in-3000. Which doesn't sound so bad, until you realize that this snowballs -- it's a 5% total chance to fail with 150 blocks and a 15% chance to fail with 500.

 

The issue is also known in PAL land as well:

http://www.atari.org.pl/forum/viewtopic.php?id=9188

 

The cause of the issue is a timing bug in the OS code that measures the baud rate: it tries to take before and after timestamps as pairs of (RTCLOK, VCOUNT) values, but has an issue with ambiguous timestamps around the vertical blank interrupt (VCOUNT=124). If the start or the end of the block sync falls within this window, POKEY is configured with an erroneous baud rate and the read fails. This affects all versions of the Atari OS.

 

There are a few ways to work around this. SIO 😄 patch in an emulator will avoid it, and I also put in extra logic in AltirraOS's cassette handler to avoid it. But Altirra also has a hack option to make the Atari OS work:

 

This option fudges the SIO input bit in SKSTAT around the VBI when the cassette is active to prevent the Atari OS from seeing a transition in the vulnerable timing window.

 

This sounds like a possible explanation as to why long programs (i.e. 30k) have a high failure rate when loading.

[oo7]

@phaeron In the ui altirra lists xbox 360 controllers. Xbox one xbox x and xbox s controllers speak and behave the same way. Maybe drop the 360 part?

[+yetanothertroll]

On 8/3/2024 at 11:37 PM, reifsnyderb said:

This sounds like a possible explanation as to why long programs (i.e. 30k) have a high failure rate when loading.

How high is "high"? I'm usually able to read two or three very long tapes (2900 blocks and up) before the bug hits me. Admittedly I've only been using Altirra, without the workarounds or other speedups, but I'm investigating workarounds of my own (a "save/reload game" option before reading/rereading a tape/file?) just in case my little statistical analysis program (11KB .XEX, or 16KB cart for 16KB 400 people, and still growing) ever sees bare silicon

[reifsnyderb]

2 minutes ago, yetanothertroll said:

How high is "high"? I'm usually able to read two or three very long tapes (2900 blocks and up) before the bug hits me. Admittedly I've only been using Altirra, without the workarounds or other speedups, but I'm investigating workarounds of my own (a "save/reload game" option before reading/rereading a tape/file?) just in case my little statistical analysis program (11KB .XEX, or 16KB cart for 16KB 400 people, and still growing) ever sees bare silicon

I'd say a save and load has worked about 25% of the time.  This is using real hardware with a 1010.  I replaced the belts on the 1010, so those are good.  Saving and loading short files (a few k or so) works fine.

[+yetanothertroll]

5 minutes ago, reifsnyderb said:

I'd say a save and load has worked about 25% of the time.  This is using real hardware with a 1010.  I replaced the belts on the 1010, so those are good.  Saving and loading short files (a few k or so) works fine.

A failure rate of 75% is way too high. I don't recall my 410 back in the day failing anywhere near that much, unless the Dorsett educational system tapes were insanely fault tolerant, but a quick review of the eduencode library source indicates nothing like redundancy or advanced ECC going on, although if the Educational System master cartridge was instead doing its own POKEY bit bashing at 300-450 baud, hmm...

[phaeron]

6 hours ago, oo7 said:

@phaeron In the ui altirra lists xbox 360 controllers. Xbox one xbox x and xbox s controllers speak and behave the same way. Maybe drop the 360 part?

There's a simple reason for this: the Xbox 360 wired controller is the only one I've tested it against. Never bothered getting a newer Xbox, and for that matter the dust is getting pretty thick on the PS4....

 

Shouldn't be any issue other than the name, though, as it's just designed for any XInput controller and the XInput detection should work for other similar devices. What controller have you tested it against? Certainly could simplify the name.

[phaeron]

1 hour ago, yetanothertroll said:

A failure rate of 75% is way too high. I don't recall my 410 back in the day failing anywhere near that much, unless the Dorsett educational system tapes were insanely fault tolerant, but a quick review of the eduencode library source indicates nothing like redundancy or advanced ECC going on, although if the Educational System master cartridge was instead doing its own POKEY bit bashing at 300-450 baud, hmm...

It's important to note that this issue only pertains to the built-in OS cassette tape routines reading the standard block format, as it's in that code's baud rate detection routine. Custom tape formats don't necessarily have this issue because they either don't measure baud rate or do it differently without the same bug. The Dorsett software appears to fall under the latter.

 

It's also related to the number of blocks read, so a custom loader still using the OS routines to read 1K blocks through SIOV will encounter the issue less often than with 128 byte blocks.

[oo7]

6 hours ago, phaeron said:

There's a simple reason for this: the Xbox 360 wired controller is the only one I've tested it against. Never bothered getting a newer Xbox, and for that matter the dust is getting pretty thick on the PS4....

 

Shouldn't be any issue other than the name, though, as it's just designed for any XInput controller and the XInput detection should work for other similar devices. What controller have you tested it against? Certainly could simplify the name.

Ive used it with several xbox controllers. Currently in living room with xbox wireless adapter and xbox series s/x controllers, on my laptop im using it with wired pdp xbox one controllers and at the cottage we have it running with a Xbox wireless adapter and xbox one controllers.

 

 

in the past ive used wired and wireless xbox360 and logitech f310 and f710

 

Im pretty sure all xinput controllers would work.

 

ive also used it in the past with a usb atari cx-40 i bought years ago but not that often and also with the arcade joystick i built but these last two are d-input

[ijor]

14 hours ago, yetanothertroll said:

A failure rate of 75% is way too high. I don't recall my 410 back in the day failing anywhere near that much,

I agree. Back in the day, when I was developing my turbo system (STAC), I tested lots and lots of original tapes in different tape recorders. Of course that the whole Atari tape system is not the most reliable, that's why I developed the auto correcting system in the first place, but certainly is not that bad, especially not with high quality factory recordings. And I tested some very looong titles, Kennedy Approach and Zorro come to mind.

 

12 hours ago, phaeron said:

It's important to note that this issue only pertains to the built-in OS cassette tape routines reading the standard block format, as it's in that code's baud rate detection routine. Custom tape formats don't necessarily have this issue because they either don't measure baud rate or do it differently without the same bug. The Dorsett software appears to fall under the latter.

 

It's also related to the number of blocks read, so a custom loader still using the OS routines to read 1K blocks through SIOV will encounter the issue less often than with 128 byte blocks.

 

Most original US tapes back in the day didn't use any custom routines or blocks.

Edited August 10 by ijor

[phaeron]

8 hours ago, ijor said:

Most original US tapes back in the day didn't use any custom routines or blocks.

I'd say they were more common in the specific case of educational tapes, such as Atari's programming and language series. They only used very simple markers during the voice segments, so only the program loads were subject to the baud rate detection bug.

 

 

[phaeron]

https://www.virtualdub.org/beta/Altirra-4.30-test19.zip
https://www.virtualdub.org/beta/Altirra-4.30-test19-src.7z

• Fixed P/M graphics sometimes not rendering properly when loading a save state.
• Debugger: DISKEMU and FDC channels are now disabled by default.
• Fixed DCart keyhole access when flash is in autoselect mode.
• Added adjustable PAL phase (high artifacting mode only).
• Reworked bloom algorithm.

Bloom has been reworked in this version from a gaussian blur to a blur pyramid. This gives better control over the shape of the bloom so it has more of a long tail. It is supported in both D3D9 and D3D11, though the D3D11 version is somewhat faster. A simple tone mapping curve with a soft shoulder has also been added to soften the clamping at the high end (disabled when HDR is active).

 

[_The Doctor__]

heh, bloom could have been a dirty screen, clean that glass!

[reifsnyderb]

On 8/4/2024 at 1:35 AM, phaeron said:

You're hitting a bug in the Atari OS. The cassette handler has an issue where there is a small chance with every block that it will miscompute the baud rate, causing the next block read to fail. The chance for this in NTSC is about 1-in-3000. Which doesn't sound so bad, until you realize that this snowballs -- it's a 5% total chance to fail with 150 blocks and a 15% chance to fail with 500.

 

The issue is also known in PAL land as well:

http://www.atari.org.pl/forum/viewtopic.php?id=9188

 

The cause of the issue is a timing bug in the OS code that measures the baud rate: it tries to take before and after timestamps as pairs of (RTCLOK, VCOUNT) values, but has an issue with ambiguous timestamps around the vertical blank interrupt (VCOUNT=124). If the start or the end of the block sync falls within this window, POKEY is configured with an erroneous baud rate and the read fails. This affects all versions of the Atari OS.

 

There are a few ways to work around this. SIO 😄 patch in an emulator will avoid it, and I also put in extra logic in AltirraOS's cassette handler to avoid it. But Altirra also has a hack option to make the Atari OS work:

 

This option fudges the SIO input bit in SKSTAT around the VBI when the cassette is active to prevent the Atari OS from seeing a transition in the vulnerable timing window.

 

When this fails, is the error "Error 138"?

 

Thanks!

 

Brian

 

[+yetanothertroll]

20 minutes ago, reifsnyderb said:

When this fails, is the error "Error 138"?

 

Thanks!

 

Brian

 

Yup, at least in Atari BASIC rev. C and OS-B

Edited August 19 by yetanothertroll
Added Atari OS ver

[phaeron]

26 minutes ago, reifsnyderb said:

When this fails, is the error "Error 138"?

A timeout is one of the errors that can result, but framing and checksum errors are also possible.

[reifsnyderb]

15 minutes ago, yetanothertroll said:

Yup, at least in Atari BASIC rev. C and OS-B

 

6 minutes ago, phaeron said:

A timeout is one of the errors that can result, but framing and checksum errors are also possible.

 

Perfect!  I think I've got the bug replicated, in Altirra, using the pre-release OS 6.2.  My plan is to replace some of Atari's Cassette Handler Code, probably around RCB, with SIOCassetteReadFrame function in the Altirra OS.  (If that's ok with @phaeron , of course.)  I need to read through the code a little more to narrow down precisely what's needed, port the code over, and test it to see if it fixes the problem.

 

Edited August 19 by reifsnyderb

[phaeron]

1 hour ago, reifsnyderb said:

Perfect!  I think I've got the bug replicated, in Altirra, using the pre-release OS 6.2.  My plan is to replace some of Atari's Cassette Handler Code, probably around RCB, with SIOCassetteReadFrame function in the Altirra OS.  (If that's ok with @phaeron , of course.)  I need to read through the code a little more to narrow down precisely what's needed, port the code over, and test it to see if it fixes the problem.

You'd be better off just adjusting the routines that sample timestamps as (RTCLOK+2, VCOUNT) pairs before and after the block sync.

 

The main issue is that the VBI is short enough with CRITIC set that VCOUNT=124 on both sides of the VBI, making (frame, 124) and (frame+1, 124) ambiguous when computing the time between the two timestamps. The solution is to just block such timestamps and repeat the measurement until VCOUNT<>124. The error introduced on the baud rate computation is negligible since the expected time difference at 600 baud is 261 line pairs, so +/-1 is minimal.

 

[reifsnyderb]

2 hours ago, phaeron said:

You'd be better off just adjusting the routines that sample timestamps as (RTCLOK+2, VCOUNT) pairs before and after the block sync.

 

The main issue is that the VBI is short enough with CRITIC set that VCOUNT=124 on both sides of the VBI, making (frame, 124) and (frame+1, 124) ambiguous when computing the time between the two timestamps. The solution is to just block such timestamps and repeat the measurement until VCOUNT<>124. The error introduced on the baud rate computation is negligible since the expected time difference at 600 baud is 261 line pairs, so +/-1 is minimal.

 

 

I think this will do it.  I "stole" the readtimer code, from sio.s, in the Altirra OS and inserted it into SBR.  It appears to work.  More testing will be required to see if it no longer fails. 

 

;**	SBR - Set Initial Baud Rate
;*
;*	INITIAL BAUD RATE MEASUREMENT -- USED TO SET THE
;*	BAUD RATE AT THE START OF A RECORD.
;*
;*	IT IS ASSUMED THAT THE FIRST TWO BYTES OF EVERY
;*	RECORD ARE $AA.
;*
;*	ENTRY	JSR	SBR
;*
;*	NOTES
;*		Problem: bytes wasted by branch around branch (SBR3). -- Fixed, BER
;*
;*	MODS
;*		Original Author Unknown
;*		1. Bring closer to Coding Standard (object unchanged).
;*		   R. K. Nordin	11/01/83
;*		2. Reading RTCLOK+2, VCOUNT will now avoid VBI
;*		  Brian E. Reifsnyder 8/19/2024

SBR	=	*		;entry

SBR1	LDA	BRKKEY
	BNE	SBR2		;if BREAK key not pressed

	JMP	PBK		;process BREAK key, return

SBR2	SEI
	LDA	TIMFLG		;timeout flag
;	BNE	SBR3		;if no timeout -- Not needed and commented out by BER

	BEQ	SBR5		;process timeout

SBR3	LDA	SKSTAT
	AND	#$10		;extract start bit
	BNE	SBR1		;if start bit

	STA	SAVIO		;save serial data in
;	LDX	VCOUNT		;vertical line counter
;	LDY	RTCLOK+2	;low byte of VBLANK clock
	JSR SBR9				; Read the Timer
	STX	TIMER1
	STY	TIMER1+1	;save initial timer value
	LDX	#1
	STX	TEMP3		;set mode flag
	LDY	#10		;10 bits

SBR4	LDA	BRKKEY
	BEQ	PBK		;if BREAK key pressed, process, return

	LDA	TIMFLG		;timeout flag
	BNE	SBR6		;if no timeout

SBR5	CLI
	JMP	ITO		;indicate timeout, return

SBR6	LDA	SKSTAT
	AND	#$10		;extract
	CMP	SAVIO		;previous serial data in
	BEQ	SBR4		;if data in not changed

	STA	SAVIO		;save serial data in
	DEY			;decrement bit counter
	BNE	SBR4		;if not done

	DEC	TEMP3		;decrement mode
	BMI	SBR7		;if done with both modes

;	LDA	VCOUNT
;	LDY	RTCLOK+2
	JSR	SBR9		; Read the timer
	TXA					; Transfer VCOUNT to A
	JSR	CBR		;compute baud rate
	LDY	#9		;9 bits
	BNE	SBR4		;set bit counter

SBR7	LDA	CBAUDL
	STA	AUDF3
	LDA	CBAUDH
	STA	AUDF4		;set POKEY baud rate
	LDA	#0
	STA	SKSTAT
	LDA	SSKCTL
	STA	SKSTAT		;initialize POKEY serial port
	LDA	#$55
	STA	(BUFRLO),Y	;first byte of buffer
	INY
	STA	(BUFRLO),Y	;second byte of buffer
	LDA	#$AA		;checksum
	STA	CHKSUM		;checksum
	CLC
	LDA	BUFRLO
	ADC	#2		;add 2
	STA	BUFRLO		;update low buffer pointer
	LDA	BUFRHI
	ADC	#0
	STA	BUFRHI		;update high buffer pointer
	CLI
	RTS			;return

; 	Code at SBR9 "borrowed" from AltirraOS sio.s readtimer
;	and modifed for use here by BER.

;	Altirra - Atari 800/800XL/5200 emulator
;	AltirraOS modular Kernel ROM - Serial Input/Output (SIO) routines
;	Copyright (C) 2008-2019 Avery Lee
;
;	Copying and distribution of this file, with or without modification,
;	are permitted in any medium without royalty provided the copyright
;	notice and this notice are preserved.  This file is offered as-is,
;	without any warranty.

; We have to be VERY careful when reading (RTCLOK+2, VCOUNT), because
; the VBI can strike in between. First, we double-check RTCLOK+2 to see
; if it has changed. If so, we retry the read. Second, we check if
; VCOUNT=124, which corresponds to lines 248/249. This can correspond to
; either before or after the VBI -- with CRITIC off the VBI ends around
; (249, 20-50) -- so we don't know which side of the frame boundary we're
; on.
SBR9
	LDY		RTCLOK+2
	LDX		VCOUNT
	CPY	RTCLOK+2
	BNE	SBR9
	CPX	#124
	BEQ	SBR9
	RTS

 

 

 

 

[rkindig]

Is there a manual available for using the emulator?  I’m new to Altirra and can’t figure out keyboard usage from a Windows keyboard.

 

thanks

[+MrFish]

16 minutes ago, rkindig said:

Is there a manual available for using the emulator?  I’m new to Altirra and can’t figure out keyboard usage from a Windows keyboard.

It's built into the application. Go to the "Help" menu.

 

 

[+yetanothertroll]

I'm seeing a weird one with Altirra/x64 4.21, OS-B NTSC 16KB, configured for compatibility and authentic experience, and Atari DOS II 2.5 obtained from the Action! github, with a FastBasic program compiled to a 16KB cart using the Windows cross-compiler reading large (~600KB, ~202 000 lines) files from a Google Drive folder mounted as a virtual DOS 2 disk. While reading the same file for the fifth time, the program gets an error 164, even though I'm doing everything through #1, retrying gets an error 170, then Altirra quits. I realize this is definitely an unusual use case 😄 It could be a Google Drive glitch and Drive restarted before I thought to check it, who knows. I'll play around with it some more and see what I can find out

 

Oh yeah, attached are the 16KB cart config files for the FastBasic cross compiler. I compiled with -t:atari-cart16-fp

 

atari-cart16-int.tgt atari-cart16-fp.tgt fastbasic-cart16.cfg

Edited August 20 by yetanothertroll
atari-cart16 config files

[phaeron]

2 hours ago, yetanothertroll said:

from a Google Drive folder mounted as a virtual DOS 2 disk

I don't recommend running any kind of live file mount off of a cloud sharing folder unless you like random I/O errors. The cloud sync programs should be using oplocks or other mechanisms to avoid taking locks on the file, but they don't, and the result is random sharing violations when trying to open files on the sharing store. The typical scenario is that a brief time after the file has been written and closed, the cloud sync program will open the file to scan it, and lock the file while doing so. This then causes sharing violations when Altirra tries to open the file at the request of the emulated program, which then turns into a read error in the disk emulation.

[+yetanothertroll]

10 minutes ago, phaeron said:

I don't recommend running any kind of live file mount off of a cloud sharing folder unless you like random I/O errors. The cloud sync programs should be using oplocks or other mechanisms to avoid taking locks on the file, but they don't, and the result is random sharing violations when trying to open files on the sharing store. The typical scenario is that a brief time after the file has been written and closed, the cloud sync program will open the file to scan it, and lock the file while doing so. This then causes sharing violations when Altirra tries to open the file at the request of the emulated program, which then turns into a read error in the disk emulation.

Actually, at some point this beast will need to be more robust in the face of random I/O errors, including the cassette bug, so I'll take the errors lol

[phaeron]

2 hours ago, yetanothertroll said:

Actually, at some point this beast will need to be more robust in the face of random I/O errors, including the cassette bug, so I'll take the errors lol

Another thing I just remembered: if you are seeking within the file (NOTE/POINT or FastBasic equivalent), that is only guaranteed to work on a virtual disk under one of two circumstances:

• You are seeking back to the first sector of the file.
• You are seeking back to within the last 643 sectors read from ANY file on the virtual disk, using POINT values that were obtained from NOTE on the same file open.

The reason for this is that virtual disk simulates a single-density disk (90K) by dynamically assigning sectors from a sector pool, and the 600K file you're reading off it vastly exceeds the size of the disk. This means that the virtual disk engine has to reuse sectors on the disk. It does this with an LRU cache, so seeking back will still work as long as the sector is still mapped within the sector pool. The first sector of each file also has a pre-assigned location and is never recycled. If you seek within last sectors still resident in the sector pool, or to the first sector that is permanently assigned, then this works. This also guarantees well-defined behavior if the total file sizes fit within the sector pool, in which case the sectors never need to be recycled once DOS discovers them. But there's no way to fit 600K worth of data sectors into a 90K disk, and thus in that case some seeks will always fail.

 

If you boot SpartaDOS X and mount a virtual SDFS disk instead, much larger files can be supported for arbitrary seeking for two reasons: the sector pool is much larger (16MB) since SpartaDOS supports arbitrary disk geometries, and the SpartaDOS file system gives the virtual disk engine better visibility into file seeks.

 

Edited August 21 by phaeron

[fox]

Feature request:

Developing Atari software using a cross-assembler or a cross-compiler requires reloading the XEX file after every compilation.
Could Altirra reboot the last selected XEX file if it changes?
I mean there would be an Altirra option to watch the last opened XEX file and reload it when it changes.