Altirra 3.10 released

[Mclaneinc]

 

The reason I added the auto-detection was that I was tired of needing to see a crash to figure out if a tape had a BASIC program or not. It works the other way too, it'll pull BASIC if the tape doesn't need it. I'll probably rewrite the hook though as pushing keys is less reliable and it can't do the follow-up RUN right now.

 

I have to be the person who loved the Auto Basic tape detection and then waited for 1 second to see if it typed RUN for me (Seriously, I did) and then thought, I wish Phaeron had added that

 

So its kind of jokey to read that you will at some point maybe rewrite it to do that

 

That self game play AI just keeps getting closer

 

All jokes aside, its a really handy (not handle as I wrote before??) little thing and greatly appreciated.....

[ascrnet]

Hi phaeron,

 

I have a doubt altirra supports this 256k memory expansion for 800xl made by Claus Buchholz?

 

http://atariage.com/forums/topic/122470-ram-upgrade-applications/?p=1481893

 

regards

[phaeron]

I have a doubt altirra supports this 256k memory expansion for 800xl made by Claus Buchholz?

 

http://atariage.com/forums/topic/122470-ram-upgrade-applications/?p=1481893

 

Maybe I'm missing something, but this looks the same as the 256K RAMBO expansion mode that is already supported, which uses 2, 3, 5, 6 mapping with ANTIC+CPU switched together and aliases the first four banks to main memory.

[Alfred]

 

Maybe I'm missing something, but this looks the same as the 256K RAMBO expansion mode that is already supported, which uses 2, 3, 5, 6 mapping with ANTIC+CPU switched together and aliases the first four banks to main memory.

 

It banks the whole lower 32K, 0-$7FFF, not just the XE window at $4000-7FFF. It was the first mod I ever built, and I learned assembler to write the ramdisk for it.

 

Edit: The original article is for the 32K bank. He revised it a while later to match the XE machines.

Edited April 3, 2019 by Alfred

[phaeron]

Have to wait for ascrnet to indicate which one he was interested in, I guess. The 32K banked version is missing the asm listings from the article but seems to use PB3-PB5 for bank switching. Works, though inconvenient since it bank switches pages 0-3.

[ascrnet]

 

Maybe I'm missing something, but this looks the same as the 256K RAMBO expansion mode that is already supported, which uses 2, 3, 5, 6 mapping with ANTIC+CPU switched together and aliases the first four banks to main memory.

perfect, this modification was very famous where the chip is replaced by others of higher capacity and apply a few connections.

 

Have to wait for ascrnet to indicate which one he was interested in, I guess. The 32K banked version is missing the asm listings from the article but seems to use PB3-PB5 for bank switching. Works, though inconvenient since it bank switches pages 0-3.

I have only seen this expansion in 800xl leaving 64KB as main memory and the rest 192k for banks of 16KB in what I understand from the documentation

 

regards

[Kyle22]

Claus will say otherwise.

 

Facts Trump Fiction.

[ascrnet]

Hi phaeron,

I found another thing that does not work like the original equipment XL-XE, is when I want to make a JMP $C598 (boot disk) but if I use the JMP $C680 (cassette boot) if it works.

 

I hope you can review, when you have time.

regards

[phaeron]

Hi phaeron,

 

I found another thing that does not work like the original equipment XL-XE, is when I want to make a JMP $C598 (boot disk) but if I use the JMP $C680 (cassette boot) if it works.

diskboot.png

 

I hope you can review, when you have time.

regards

 

This isn't an emulator issue, but a bug in your code.

 

Neither $C598 nor $C680 is a valid entry point into the OS, so this will only work if you have the exact Atari OS that has internal routines at those addresses. If you are getting crashes with either then you either have the wrong OS selected or some OS variables aren't set up the way those routines expect. Version 1 of the Atari XL/XE OS, for instance, has the disk boot routine at $C5A6 instead of $C598, and any of the OS-B derived OSes like Omniview will have it somewhere within $E400-FFFF instead of $C000-CFFF. As far as I know there are no official vector addresses that point to the boot routines.

[ascrnet]

 

This isn't an emulator issue, but a bug in your code.

 

Neither $C598 nor $C680 is a valid entry point into the OS, so this will only work if you have the exact Atari OS that has internal routines at those addresses. If you are getting crashes with either then you either have the wrong OS selected or some OS variables aren't set up the way those routines expect. Version 1 of the Atari XL/XE OS, for instance, has the disk boot routine at $C5A6 instead of $C598, and any of the OS-B derived OSes like Omniview will have it somewhere within $E400-FFFF instead of $C000-CFFF. As far as I know there are no official vector addresses that point to the boot routines.

Thank you very much for answering, I was actually doing something wrong in my code. These memory addresses are not documented but they work in altirra. I attached an example where they use them.

 

infinite life charger.zip

 

regards

[Mclaneinc]

I think you are missing the point, saying it works in Altirra isn't that simple. The way you say it makes it sound like Altirra is a universal OS when in fact it can use a vast selection of dumped OS's which also may have been user modified, the Altirra user then individually selects as which one he or she will use. It can also use its own built in OS.

 

The point is that your program may work on one dumped OS but if the OS vectors have been modified then it limits severely which other OS's it will work on.......It many cases, no others..

 

ALways best to mention if you think there's a bug WHICH OS you are using..

[Fred_M]

@ultrasteve and I found something weird in version 3.10. It is a bit similar to the problems Farb is describing.

 

Steve has dumped the cassette tape of Pole Position by Datasoft and converted it to cas with a8cas. The tape has a "introduction" beep for the first stage of 16 seconds. The resulting cas-file works perfectly in Altirra 2.90 (XL/XE OS ver.2/PAL/64k/No basic/C-acceleration off). But in Altirra 3.10 (XL/XE OS ver.2/PAL/64k/No basic/C-acceleration off) the cas-file does not load. You can hear that the lenght of the introduction beep is suddenly too long and when Altirra 3.10 tries to load the first block, you can hear the error sounds.

 

So we tested this on 2 computers and I have tested 2 versions of Altirra (2.90 and 3.10) on my laptop with exactly the same rom files.

 

To confirm our findings Steve has created a cas-file with a introduction beep of just 10 seconds. As we hoped, the cas-file loads perfectly now in Altirra 3.10. So Altirra 2.90 accepts a normal length of the introduction beep and version 3.10 does not. I am afraid that 10 seconds is too short for real hardware.

 

But now the stranger part, this tape has 3 stages. We did not change the length of the introduction beep of the second stage, which is 19 seconds, and it loads normally. Also the third stage has a introduction beep of 19 seconds and it loads normally. It seems that only the first introduction beep must be shorter in Altirra 3.10.

 

When C:acceleration is on all files load perfectly on every version. We found this problem only when C:acceleration is off.

 

I have included both cas-files (the one with the original beep length, and the cas-file with the shortened beep lenght). I hope someone can see what is happening here

PP_steve.zip

Edited April 7, 2019 by Fred_M

[Mclaneinc]

Fred, is the introduction beep on the first tape being artificially created / does if differ from the actual original tape...What length of beep is the original tape?

 

If its being artificially made then perhaps the tighter tape control on a later Altirra is picking up the anomaly?

 

Also I'd guess the intro beep is just a thing to start off a load process rather than ignored as the tape progresses on to other parts unless its a true 3 part load ie the programs loads a bit and then runs and then initiates its own OS load for the other parts.

 

Just guess work, I'm sure Baktra or Avery will give the proper explanation.

Edited April 7, 2019 by Mclaneinc

[Fred_M]

Fred, is the introduction beep on the first tape being artificially created / does if differ from the actual original tape...

 

 

No, ofcourse not There is only 1 tape and 1 recording. The original length is 16 seconds and for the Altirra 3.10 test we have cut 6 seconds off the introduction beep. The tape is all original and not tampered with. I hope Phaeron can take a look at this. I think this is not a tape problem, but a difference between Altirra 2.90 and 3.10.

Edited April 7, 2019 by Fred_M

[phaeron]

There's a lot of things going on here.

 

First, about the gap. The Atari OS cassette handler enforces a minimum leader length before it will read blocks from tape. On write, a 20 second leader of mark tone is written, and on read, 10 seconds of leader are ignored. The cassette handler does not read anything at all from this leader, it simply waits 10 seconds before resetting POKEY and beginning to look for a sync mark. Anything encoded on the tape during that time is just ignored. This means that any leaders shorter than 10 seconds will not work on real hardware unless you cheat by pressing Play late after the OS thinks you've done so (by pressing a key at the tone). If the leader is short, the OS will skip part of the first block before starting and then fail.

 

The problem with this is that many CAS files have too short of a leader, and depending on how the emulator handles the file it may or may not work. If the emulator routes the bytes directly to SERIN without timing delays then it will happen to work, because the tape will effectively be held back until the cassette handler is ready to receive it. In Altirra, this doesn't work because it will advance the tape during the 10 second wait like happens on real hardware. Therefore, to make these tapes work, the emulator checks if first block is a data block with a gap that is too short and extends the gap to 10 seconds if needed.

 

This brings us to the next part of the puzzle. Note that I said "if the first block is a data block." Starting in Altirra 2.50, I added support for the FSK block type, which encodes raw bit data that can't be encoded in a regular data block. Crucially, this is only produced by newer tape decoders, notably a8cas. The tape images don't have clean leaders, they have small glitches that are encoded as FSK:

PP_steve.cas:
CASIMAGE: FSK block @   0:08.327: 8327ms gap, 1 transition (0.2 ms)
CASIMAGE: FSK block @   0:10.506: 2179ms gap, 1 transition (0.1 ms)
CASIMAGE: FSK block @   0:10.941: 435ms gap, 1 transition (0.2 ms)
CASIMAGE: Data block @   0:10.941: 6047ms gap, 132 data bytes @ 600 baud

PP_steve_10secpeep.cas:
CASIMAGE: FSK block @   0:01.191: 1191ms gap, 1 transition (0.2 ms)
CASIMAGE: FSK block @   0:03.370: 2179ms gap, 1 transition (0.1 ms)
CASIMAGE: FSK block @   0:03.805: 435ms gap, 1 transition (0.3 ms)
CASIMAGE: FSK block @   0:05.124: 1318ms gap, 1 transition (0.1 ms)
CASIMAGE: Data block @   0:05.124: 4729ms gap, 132 data bytes @ 600 baud

In both cases, because the first block is an FSK block, the 10 second extension doesn't occur, and the tape blocks are used with their original timing. In the first case, the leader is 16 seconds, and crucially, two of the FSK-encoded glitches are after the 10 second mark. The OS cassette handler picks one of these up as a start bit and then runs its sync mark code, computing a bogus baud rate and reading garbage. With the shortened leader, the glitches are all before the 10 second mark, and thus simply ignored by the cassette handler, so it loads.

 

When C: acceleration is on, the OS cassette handler is bypassed and the emulator handles the leader delay and the sync mark measurement. Crucially, the emulator's decoder has false start bit detection, so when it doesn't see a valid train of pulses after the start bit it resets the state machine and continues looking for the actual sync mark.

 

That brings us to the difference between Altirra 2.90 and 3.10. This has to do with the width of the glitch. In Altirra 3.00, I increased the precision of the internal tape data stream from 16KHz to 32KHz to better support high baud rates. In 2.90, the glitch is too small to be picked up, but in 3.00+ there is enough precision for it to be picked in SKSTAT, which then causes the OS cassette handler to see the false start bit. Increasing the width of the SKSTAT filter would make the tape load again, but this reduces the maximum data rate that could be loaded -- and there are already problems with people encoding CAS images at data rates that are difficult or impossible to encode in FSK, such as 2000-6000 baud.

 

So, ultimately, the issue is the glitches in the CAS image. If you don't need FSK encoding I would recommend turning it off during the tape decode, as this is only necessary for tapes that use non-standard blocks. There is a question about whether a 0.2ms pulse can actually be decoded with a standard 410/1010 FSK decoder with 4KHz/5.3KHz tones. I would argue that these probably should be filtered out in the encoding process, but that would require some validation against the real hardware.

 

 

[phaeron]

http://www.virtualdub.org/beta/Altirra-3.20-test22.zip

http://www.virtualdub.org/beta/Altirra-3.20-test22-src.zip

 

• Rewrote hook for loading BASIC tapes. It now uses CIO hooking for injecting the CLOAD and RUN commands like the BASIC program loader does, for better speed and reliability.
• Fixed a bug in the ROM validator for WarpOS 32-in-1. Haven't seen failures of this in the wild.

 

[SS]

• Fixed a bug in the ROM validator for WarpOS 32-in-1. Haven't seen failures of this in the wild.

 

OK, I am now able to detect the 32-in-1 in Firmware Manager but I cannot figure out how to enable it. It's not showing up in my Operating System selection box. What am I doing wrong?

[phaeron]

 

OK, I am now able to detect the 32-in-1 in Firmware Manager but I cannot figure out how to enable it. It's not showing up in my Operating System selection box. What am I doing wrong?

 

You have to add the 32-in-1 under Devices. Once it is enabled, it overrides the normal OS selector with its own OS soft-switching.

[Mclaneinc]

As regarding the tapes, I presume based on a logical requirement that the tape must work on real hardware if its being ran under pure hardware specs rather than patches to achieve faster loading, if those tapes would not run under that if booted on real hardware then as you say, they should be filtered out.

 

Your love of tapes must be increasing so much Phaeron

 

Oh, re 32 in 1, the ability to use the OmnimonXL rom on its menu seems to be a nil if trying to use the normal entry point, RESET and SELECT and it jumps in to the 32 in 1 menu....

 

Also booting up an OmnimonXL either as an option from 32 in 1 or just as a direct OS replacement with no disk in and no basic just sits on a blue screen BUT I can't remember if this is by design...I seem to think it is...If a disk is in it boots as it should..Pretty sure its norm to just sit on the darker blue screen. Obviously if used without the 32 in 1 the Omnimon is accessible in the normal ways..

Edited April 8, 2019 by Mclaneinc

[+Nezgar]

From my experience on real hardware, the 32-in-1 OS menu is only ever accessible from a full power cycle/off state. No combination of keys+reset, warmstart or jump to E477 coldstart after boot can ever get it otherwise. I guess that's an odd situation for the emulator, since a coldstart probably always simulates a boot from poweroff every time...

 

I think there is absolutely no code in Omnimon XE to handle a no-boot, no cartridge situation. Even just typing "BYE" from BASIC just returns you to the READY prompt. I will verify later on real hardware.

[Mclaneinc]

Just to make sure, I'm not suggesting the emu is at fault, I think its a by product of the keys used in conjunction with the keys the 32 in 1 OS uses for the menu. Basically I don't think its suited to be on the menu because of the clash. The Omnimon can be got into if you by luck you get the timing of your key press right but its so ultra tight its random..

 

Also I just noted that since that the 32 in 1 OS lists it as a test according to a post seen in another thread..ie this..

 

A APE Warp+ OS (XL/XE) APE Warp+ OS
B Atari XL/XE OS (REV A) XL/XE (REV A)
C Atari XL/XE OS (REV B) XL/XE (REV B)
D Atari XL/XE OS (REV C) XL/XE (REV C)
E Atari XEGS OS (REV D) XEGS (REV D)
F Atari 800 OS-B 800 (OS-B)
G Atari 400 OS-A 400 (OS-A,P)
H Atari 800 Compatible OS 800 Compatible
I Atari XL/XE OS w/ Reverse BASIC (REV A) XL/XE (R-A,RB)
J Atari XL/XE OS w/ Reverse BASIC (REV B) XL/XE (R-B,RB)
K Atari XL/XE OS w/ Reverse BASIC (REV C) XL/XE (R-C,RB)
L Atari XEGS OS w/ Reverse BASIC (REV D) XL/XE (R-D,RB)
M Atari 1200XL OS (REV 11) 1200XL (REV 5)
N Atari 1200XL OS (REV 10) 1200XL (REV 10)
O Atari XL/XE Arabic OS ARABIC XL/XE
P ARGS-OS (Ralf David ROM-Disk: Select+Reset) ARGS-OS
Q Atari XL/XE OS w/ Pal Mods (REV A) XL/XE (R-A,P)
R Atari XL/XE OS w/ Pal Mods (REV B) XL/XE (R-B,P)
S Atari XL/XE OS w/ Pal Mods (REV C) XL/XE (R-C,P)
T Atari XEGS OS w/ Pal Mods (REV D) XEGS (R-D,P)
U Atari XL/XE OS w/ Pal Mods + Reverse BASIC (REV A) XL/XE(R-A,P,RB)
V Atari XL/XE OS w/ Pal Mods + Reverse BASIC (REV B) XL/XE(R-B,P,RB)
W Atari XL/XE OS w/ Pal Mods + Reverse BASIC (REV C) XL/XE(R-C,P,RB)
X Atari XEGS OS w/ Pal Mods + Reverse BASIC (REV D) XEGS(R-D,P,RB)
Y QMEG OS V3 (c)87 S.Dorndorf QMEG TEST ROM
Z David Young OmnimonXL (C)1984 OMNIMON TEST
0 David Young OmnimonXL (C)1984 w/ Reverse BASIC OMNIMON R-Basic
1 David Young OmniView XE w/ Reverse BASIC OmniView 80
2 MyIDE 3.1e MyIDE 3.1e
3 MyIDE 3.1i MyIDE 3.1i
4 Warp+ OS r11 Warp+ OS r11

 

 

Don't know if this is official or not

 

Forgot to snip the poster when I scrapbooked it..

Edited April 8, 2019 by Mclaneinc

[+Nezgar]

Oh yeah that's the list I made of the OS's in my 32-in-1 ROM as received from AtariMax. So these symptoms are only on that test Omnimon, not the option 0 Omnimon? Who knows what that test OS is about... I'll test on my real hardware tonight.

[SS]

 

OK, I am now able to detect the 32-in-1 in Firmware Manager but I cannot figure out how to enable it. It's not showing up in my Operating System selection box. What am I doing wrong?

 

 

 

You have to add the 32-in-1 under Devices. Once it is enabled, it overrides the normal OS selector with its own OS soft-switching.

 

I am getting the message "Missing firmware for device".

 

 

Although the 32-in-1 shows up in my Firmware Manager.

 

 

I am obviously still doing something wrong.

[scotty]

 

 

 

I am obviously still doing something wrong.

 

That rom image is bad. This one is a known good image. ALSO..... To get to the 32-in-1 menu screen, you must hit the SELECT key as you reboot the system.

 

Here is how to use it..... Scroll to the bottom. https://www.atarimax.com/warpos/documentation/install_guides/install1200xl.php

 

 

Scotty

Another 32-in-1.BIN

Edited April 9, 2019 by scotty

[phaeron]

As regarding the tapes, I presume based on a logical requirement that the tape must work on real hardware if its being ran under pure hardware specs rather than patches to achieve faster loading, if those tapes would not run under that if booted on real hardware then as you say, they should be filtered out.

 

Your love of tapes must be increasing so much Phaeron

 

Let's see, hmm... nope, still hate tape.

 

The key in this situation is the FSK decoding of the analog tape to digital form -- that's the part that definitely won't match the "real hardware," whatever that may be in this case (410, 1010, XC12, etc). I suspect that on an unmodified tape deck that you wouldn't actually get a glitch that small, based on the filters that the tape deck would have to use. But that may not be true for all decks, and in any case filtering the FSK output on load by default to reduce the bandwidth would defeat the purpose of having that high precision capability in the FSK blocks to begin with.

 

From my experience on real hardware, the 32-in-1 OS menu is only ever accessible from a full power cycle/off state. No combination of keys+reset, warmstart or jump to E477 coldstart after boot can ever get it otherwise. I guess that's an odd situation for the emulator, since a coldstart probably always simulates a boot from poweroff every time...

 

Yes, coldstart in the emulator is a power cycle -- it's to simulate powering up a computer that's been off so long it's literally cold.

 

The interesting question is what should happen on a warm Select+Reset. Looking at the documentation again, it implies that it might just trigger a cold reset instead of bringing up the menu. The thing is, cold vs. warm reset isn't determined by the hardware on XL/XE machines, it's determined by the OS. I don't think interrupting a warm start is enough to force a cold start, so it'd have to either involve assistance from the menu OS or injecting instructions to clear the warmstart state from a hidden ROM.