Altirra 4.10 released

[phaeron]

Just now, ldelsarte said:

Dear @phaeron,
Can I respectfully ask what you think about my suggestion (see previous message, above) to add actual keyboard sounds in Altirra?
Thank you

I don't think it's a bad idea, but I'd have to do some tests to see what it would sound like. It may be a bit dubious if you can't hear it over the default OS keyclick sound, which you would then need to disable.

[ldelsarte]

3 minutes ago, phaeron said:

I don't think it's a bad idea, but I'd have to do some tests to see what it would sound like. It may be a bit dubious if you can't hear it over the default OS keyclick sound, which you would then need to disable.

Thanks a lot for considering the option.

It might sound great to have this real/authentic experience.

Because, "back in those days" we could hear both the physical keyboard sound PLUS the Atari OS keyclick sound...

Don't hesitate to tell if I can help with sound samples. I'll be happy to.

[Keatah]

If this does become a feature. It might be useful for it to have its own volume/mixer control. Various setups would have different acoustic characteristics. And the TV volume wouldn't always be set at the same level anyways. So the ratio would have to be user-adjustable to best match what they had/remember from back in the day.

 

If you're going to go into this level of detail, might as well make it feature-complete and customizable.

[www.atarimania.com]

On 2/22/2023 at 6:17 AM, phaeron said:

Added emulation support for the Chalk Board PowerPad controller.

I never realized how complex it would be to emulate the device so a big thank you for taking the time to do things right! 

[drac030]

On 2/22/2023 at 6:17 AM, phaeron said:

Debugger: (dp), (dp,X), and (dp),Y addressing modes now also suppress symbol lookup for non-zero D register, and there is now an option in the Disassembly window to control this behavior.

This seems to work, thanks. What about the MVN/MVP issue? Not reproducible? Not fixable? Later?

[phaeron]

4 hours ago, drac030 said:

This seems to work, thanks. What about the MVN/MVP issue? Not reproducible? Not fixable? Later?

I suspect it's somehow a difference between the 'o' command and F10 but haven't had a chance to look into it yet.

 

[drac030]

6 hours ago, phaeron said:

a difference between the 'o' command and F10

Not sure if this helps, but here there is (functionally) none.

Edited February 24, 2023 by drac030

[drac030]

I have some code that works on real Atari, but crashes on Altirra. The crash is due to stack corruption, and the reason for the stack corruption is here:

 

The code is first executed in the native mode, with 16-bit X/Y registers. Then it switches to the emulation mode for a moment, then again to the native one. The problem is that the X bit in the CPU register apparently survives all this without being forced back to 1 while the CPU is in the emulation mode: XCE at $0010dd evidently sets both bits to %11, but PLP at $fe6131 right away restores %10, as pushed by the emulation mode PHP at $0010db.

 

The datasheet, chapter 2.8, says: "The M and X flags are always equal to one in Emulation mode", and it is so on the hardware CPUs, so I think that this is a bug.

 

While investigating that I also discovered another problem: namely PLB and PLD should both set NZ flags according to the data pulled (as per the datasheet), and this indeed happens on real hardware, but on Altirra it does not:

 

 

Edited March 2, 2023 by drac030

[Alfred]

Is it expected that if running Altirra on a remote machine and viewing it through Remote Desktop the screen is just solid gray ? It looks find on my local machine but if I run it in a vm, I can hear it booting, but the screen is just plain grey, and fiddling with options changes nothing.

 

Edit: switching to full-screen makes the screen visible, which is a good enough workaround.

Edited March 3, 2023 by Alfred

[phaeron]

30 minutes ago, Alfred said:

Is it expected that if running Altirra on a remote machine and viewing it through Remote Desktop the screen is just solid gray ? It looks find on my local machine but if I run it in a vm, I can hear it booting, but the screen is just plain grey, and fiddling with options changes nothing.

 

Edit: switching to full-screen makes the screen visible, which is a good enough workaround.

No, this isn't expected, rendering over Remote Desktop can be a bit slower but otherwise will work the same as local. A VM is a bit tricky as VMs often either lack hardware 3D acceleration or have buggy implementations of it, and I have seen VM display drivers break Altirra's display in pretty significant ways. RDP on Vista+ uses WDDM redirection to render the remote display with the GPU, so it will generally show similar glitches as to if you were connected to the console. VMware's WDDM display drivers are generally the best, Parallel's has historically had some major bugs, and VirtualBox's were pretty bad the last time I tried it.

 

One thing that does generally help in these kinds of cases is to switch the display API from Direct3D 11 to Direct3D 9, as D3D9 is somewhat better supported by virtualization graphics drivers than D3D11. But in the past some VM vendors have tried a user space D3D9 to OpenGL conversion layer routed to OpenGL rendering on the host, which can cause major artifacts even with D3D9-level rendering. You can turn off both D3D9 and D3D11 to force GDI, but this is essentially software rendering and will be poor in performance / quality / functionality. Altirra is designed to run with at least basic 3D hardware acceleration at this point, it has fallbacks to be able to run without it, but the experience is limited to "enough to run."

 

[Alfred]

I will try that. This is under VMWare Workstation Pro 17. The underlying processor is an Intel 8700K, so while there is no graphics card, there is some 3D support with the Intel HD graphics. I’ll have to test it on another server which is a dual Xeon box with no graphics card, and not even HD Graphics. That’s a Server 2008 Datacenter Edition machine, and it renders the VM desktops reasonably well over RDT so it must have something. I think it’s limited to 1024x768 for the console display, VGA only.

[Alfred]

15 hours ago, phaeron said:

One thing that does generally help in these kinds of cases is to switch the display API from Direct3D 11 to Direct3D 9, as D3D9 is somewhat better supported by virtualization graphics drivers than D3D11

 

So it turns out it was using D3D9. Turning that off, as in going back to GDI, the display is fine. It also works if D3D11 is selected.

 

Edit: Strangely enough, the dual Xeon machine with just a "Standard VGA Adaptor", all three modes display fine via RDT to the vm, D9, D11 and plain GDI. Bit surprised at the D11, did that even exist back in 2010 when this machine was built ?

Edited March 3, 2023 by Alfred

[phaeron]

2 hours ago, Alfred said:

So it turns out it was using D3D9. Turning that off, as in going back to GDI, the display is fine. It also works if D3D11 is selected.

 

Edit: Strangely enough, the dual Xeon machine with just a "Standard VGA Adaptor", all three modes display fine via RDT to the vm, D9, D11 and plain GDI. Bit surprised at the D11, did that even exist back in 2010 when this machine was built ?

Altirra has auto-fallback if the selected display API isn't available -- if you have D3D11 enabled and initialization fails, it will try D3D9 if enabled, otherwise it will fall back to GDI as a failsafe. You can tell if it is resorting to GDI because in that case none of the filtering options will work. Implementing those over GDI would involve software rendering with high CPU load and would have difficulty maintaining 60 fps in most pertinent scenarios, so I haven't been concerned with trying to support this better.

 

Direct3D 11 supports limited functionality with D3D9 and D3D10 hardware through feature levels, also known as 10level9. Altirra ships with 4_0_level_9_1 drivers so it can run on D3D9-class drivers in D3D11 mode, since there are some advantages to doing this, especially on Windows 8.1 and above. True D3D9 is needed if you are running on display hardware that only supports fixed function, but that is going to be very old hardware (up to around GeForce 4 MX era, ca. 2002) and on the tail end of graphics hardware that Altirra supports. The 8700K is actually fairly modern as it is Kaby Lake based with Gen9 graphics hardware, which supports DirectX 12.1; however, I have experience with Gen9 and there are several driver versions that are extremely buggy -- my favorites being one driver version that stretched all OpenGL windows, and another one that ignored constant buffer updates through UpdateSubresource().

 

Standard VGA Adapter does indeed mean no 3D graphics capability, and actually not even a proper graphics driver. This also means you're running pre-Windows 8. In this scenario Altirra won't be able to initialize either D3D9 or D3D11 even if you have them enabled. On Windows 8 or higher, you would have the Microsoft Basic Display Adapter instead, and in 8.1+, the Windows Advanced Rasterization Platform (WARP) driver would be providing 3D emulation through software rendering (which would be very slow, but it would function).

 

[phaeron]

https://www.virtualdub.org/beta/Altirra-4.20-test6.zip
https://www.virtualdub.org/beta/Altirra-4.20-test6-src.7z

• Initial 1400XL/1450XLD emulation.
• Pad input area for tablet/powerpad can now be moved and resized in Configure HUD.
• 65C816 fixes for PLB/PLD flag handling, PHP bits 4/5 after returning to emulation mode, incorrect stepping outside of bank 0, and some stack wrapping bugs specific to the Veronica '816.
• Fixed XF551 write protect handling and improved FDC read/write timing.
• The Reinterleave option in the Disk Drive dialog now marks the disk as modified.
• AltirraOS updated to 3.35 with a bug fix for incorrect MEMLO handling when loading CIO handlers via type 4 polls.
• Added PHLOAD.COM to Additions disk to trigger type 4 polling and peripheral handler loads.
• Debugger: 'bta' command can now be used without a trace string; a default one is provided.

First thing to say about 1400XL/1450XLD: voice and telecomm does not work currently. The handlers will initialize, but V: does not actually play any voice and T: cannot actually dial out. I tried hooking up V: to the system speech API, but that is not amenable to just-in-time phoneme delivery. T: requires more research into the 1400XL's audio circuits as there are some unusual control bits that affect the audio routing. There is one new handler ROM for the V: and T: devices that are automatically added in 1400XL mode.

 

The 1400XL OS is not needed to use the 1400XL/1450XLD. The 1400XL is essentially just an 800XL with memory mapped at $D600-D7FF and two built-in PBI devices (V:/T:), and the regular XL/XE OS is perfectly capable of driving all of the new devices; despite some of the 1400XL OS revisions having reference to separate internal device PBI registers, the known handler ROMs are designed to work with standard $D1FF access. The 1400XL OS is rather underwhelming. The initial version has almost no real differences from the XL/XE version 2 OS that it is chronologically closest to, but is incompatible with a lot of software because of small changes that shift almost all of the routines in the $Cxxx region by 2-6 bytes, and an SIO change that also shifts some of the routines in the main EF region. The silliest changes are due to the OS having been reassembled by a newer assembler that fixed some instructions being unnecessarily assembled with absolute addressing mode instead of zero page when accessing page zero locations, e.g. STA CRITIC changing from 8D 42 00 -> 85 42. Reverting back to the rev. 2 OS for the remaining products was very much the right move.

 

The parallel disk controller is more interesting. In order to use it, you need to manually add the 1450XLD controller device, of which there are three versions: standard 1450XLD with real handler but simulated controller, 1450XLD with real handler and real controller (full emulation), and 1450XLD "TONG" with real handler and real controller (full emulation). The PBI handler ROMs are cross-compatible but the TONG and non-TONG controller ROMs are not, the TONG firmware will not work on the non-TONG hardware or vice-versa. Furthermore, the TONG controller firmware that was posted on the Atari History Museum site is NOT compatible with the TONG schematic that was posted with it; I had to reverse engineer the changes to the circuits from the 8048 disassembly. When the 1450XLD device is active, the parallel disk controller will take over D1:. It also tries to shift the SIO drives, which will not currently work as in the emulator they will fight over the D1: disk interface.

 

The design of the parallel disk controller is odd. It is essentially the SIO protocol redirected over a PBI interface, with regular command frames and data frames. This includes a bit of silliness like the SIO checksums still being computed and sent. The daughterboard version of the disk controller is quite underwhelming -- despite having a double-density controller and 256 bytes of RAM, it only implements single and enhanced density and the basic 1050 command set. The data transfer protocol is slow for a parallel interface due to handshaking, but it's still a bit faster than SIO divisor 0. The sad part is that despite the disk controller being fast enough to read at least 5:1 high-speed interleaved disks, it doesn't support formatting with a high-speed skew. Since the controller also doesn't have enough memory to do track buffering, this means that in most cases it is no faster than a 1050. Also strange is that despite the 1050 being well-established when this was made, the density reporting is incompatible, with medium density being reported in bit 5 instead of bit 7. The PBI handler ROM is pretty buggy, with the earliest Revision E handler [CRC32 E8F9C8A7] being the one that boots most reliably with the commonly available 1450XLD controller. It will actually boot many copy protected disks, but compatibility is hindered by the handler not returning sector data on a read error. Holding the SELECT button on start tells the handler to slow down disk reads to closer to 810/1050 timing, if you happen to have a faster interleaved disk.

 

The "TONG" controller is more evolved. Despite the TONG schematic showing a compatible circuit to the daughterboard, the controller ROM that's been published for it does not work on it -- it requires different chip select bits for the FDC and RAM. The controller firmware is quite a bit improved, with support for double-sided double density, 1050-compatible density reporting, fixed density detection, sector number validation, faster format, faster transfers, and more reliable ATTN/BUSY protocol handling. Of the three handler ROMs that work with it, the "U6" ROM [CRC32 29359910] appears to be the latest. However, I haven't been able to get the controller to boot double density. There is, unfortunately, a major bug in the TONG controller that wasn't in the earlier version: it always returns the current type I FDC status from the Get Status command instead of the FDC status from the last read, which alone breaks the majority of protected disks. It also still doesn't support a high-speed skew format, which is a shame given a disk interface that could out-do any SIO high-speed disk drive.

 

The 1450XLD controller shares similarities with the XF551, which is also 8048 based. It actually has a faster CPU (10MHz vs. 8.3MHz) and more RAM (256b internal + 256b external vs. just 256b internal), and runs at 288 RPM instead of 300 RPM. However, the XF551 was definitely more polished, supporting the PERCOM block commands, being more compatible, and being much more tightly coded. The two also have incompatible DSDD formats. Both write to side 2 with reversed tracks, but the XF551 also reverses the sector order.

 

[ldelsarte]

12 minutes ago, phaeron said:

Initial 1400XL/1450XLD emulation.

@phaeron Thank you SO MUCH for this!!

[serj]

guys, where i can find these 4 bios files ?

 

[Atari_Force]

I want to try it.
Where do I can find this files?:

 

"1450XLD disk controller firmware" CRC32 7773B7DD
"1450XLD \"TONG\" disk controller firmware" CRC32 03930886
"1450XLD disk handler firmware (rev. E)" CRC32 E8F9C8A7
"1450XLD disk handler firmware (rev. F)" CRC32 4BB7FA3A
"1450XLD disk handler firmware (post rev. F)" CRC32 29359910

[ldelsarte]

Hi Guys!

 

In this "ZIP" files you will find the files listed below with CRC32

I believe all the files you're looking for are there

Sorry, it should be sorted and organised properly.

There are some duplicates.

Still, I hope this helps

 

Atari 1450XLD Disk controler roms
1450tong.bin -- CRC32 -- 03930886 --> "1450XLD \"TONG\" disk controller firmware" CRC32 03930886
cnt8750.bin -- CRC32 -- 7773b7dd --> "1450XLD disk controller firmware" CRC32 7773B7DD
dskcnt6.bin -- CRC32 -- 29359910 --> "1450XLD disk handler firmware (post rev. F)" CRC32 29359910
dskcnt10.bin -- CRC32 -- 4bb7fa3a --> "1450XLD disk handler firmware (rev. F)" CRC32 4BB7FA3A

 

Atari 1450XLD Peripherals roms
1400.ROM -- CRC32 -- 25ea9356
1450BUSS.CTL -- CRC32 -- 7773b7dd --> "1450XLD disk controller firmware" CRC32 7773B7DD
1450VHND.LER -- CRC32 -- 5ec3ec7d
1540OS3.V0 -- CRC32 -- 0d477aa1
PDDF5 -- CRC32 -- 4bb7fa3a --> "1450XLD disk handler firmware (rev. F)" CRC32 4BB7FA3A
PDDREVE -- CRC32 -- e8f9c8a7 --> "1450XLD disk handler firmware (rev. E)" CRC32 E8F9C8A7

 

Atari 1450XLD Roms
ATA_R03X.ROM -- CRC32 -- 0d477aa1
ATA_R03Y.ROM -- CRC32 -- d425a9cf
Atari OS 1450 3.0.rom -- CRC32 -- 0d477aa1
Atari OS 1450 3.X.rom -- CRC32 -- d425a9cf

 

Atari 1400XL Stand ALone Test ROM
1400salt.bin -- CRC32 -- 10cb0520
Atari 1400XL SALT Diagnostic.rom -- CRC32 -- 10cb0520

 

Atari 1400XL System ROM
1400XL1.COM -- CRC32 -- 4c445976
1400XL1.ROM -- CRC32 -- 00c82145
1400XL2.COM -- CRC32 -- 5c6b496e
1400XL2.ROM -- CRC32 -- 57960c52
OS1400XL.COM -- CRC32 -- 6d441047

 

Atari 1400XL Telecommunicator Talking
1400tele.bin -- CRC32 -- c63d9e1c
Atari 1400XL Telecommunicator Talking Term Program.rom -- CRC32 -- c63d9e1c

roms-1400-1450.zip

[scotty]

OMG, my dreams have come true!!!! Thank you Phearon!!!

Edited March 7, 2023 by scotty

[serj]

next 65xem or 1600xl ?

[phaeron]

5 hours ago, serj said:

next 65xem or 1600xl ?

As far as I know, those hadn't progressed nearly as far as the 1400XL/1450XLD and there isn't much if anything to emulate, whereas there are multiple running 1450XLDs. The Amy chip in particular never seems to have actually ever made it into an Atari computer.

[avanze]

Which file is the 1400XL/XLD Handler ROM? Sorry if I missed something.

[Keatah]

I’m very much an early and avid 400/800 gamer, and am familiar with the other comps in the 8-but lineup. 
 

In brief, what does the 1400XL & 1450XLD bring to the table that would benefit or improve my gaming experience?

[+MrFish]

4 hours ago, Keatah said:

In brief, what does the 1400XL & 1450XLD bring to the table that would benefit or improve my gaming experience?

Nothing, out of the box; but, someone interested in programming the Votrax might add some cool voice synth to a game; Q*Bert being an obvious target for a hack.

 

[phaeron]

23 hours ago, avanze said:

Which file is the 1400XL/XLD Handler ROM? Sorry if I missed something.

4K w/ CRC32 2BA701DF and 5EC3EC7D both contain the V: and T: handlers. I don't know what the difference is between these yet.

 

Both of these appear to be for the SC-01 speech chip. I haven't seen a handler ROM that is for the SC-02/SSI263 that's in the TONG schematics.

 

23 hours ago, Keatah said:

In brief, what does the 1400XL & 1450XLD bring to the table that would benefit or improve my gaming experience?

Right now? Nothing, really.

 

Back then, if Atari had finished the disk firmware with high-speed skew, it would have been faster than most SIO-based disk drives. Even without track buffering, it can keep up with a 5:1 US Doubler high-speed interleave, and can probably go faster than that.