flashjazzcat Posted November 14, 2022 Share Posted November 14, 2022 2 minutes ago, andyhants said: So am I right in thinking the 'Mount in Windows' option is from the <alt>D function then click on the 'play' button for a given drive & select the 'Mount folder as SpartaDOS disk' option? I would say not. It's equivalent to unmounting the VHD in the device tree, mouting it in Windows, then ejecting it in Windows, going back through the dialogues in the device tree and re-mounting it in the emulator. So Avery's new option really saves a lot of time. Quote Link to comment Share on other sites More sharing options...
andyhants Posted November 14, 2022 Share Posted November 14, 2022 (edited) 21 hours ago, phaeron said: I would, but the issue is that I currently don't have filesystem implementations of FAT16 or FAT32, only a filesystem generator. That's why I implemented the Mount in Windows option -- though admittedly this will only work for people actually running on Windows, and not through WINE. Hi Avery I'm sure I'm just being obtuse again - but please could you clarify your comment on implementing the 'Mount in Windows' option above. Ideally I'm wanting to write to FAT and / or Windows Folders under SDX - so Eg COPY D3:xxxxxxxx.yyy D6:xxxxxxxx.yyy where D3: is an APT partition & D6: is a FAT partition - thanks Edited November 14, 2022 by andyhants Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted November 14, 2022 Share Posted November 14, 2022 (edited) SDX cannot write to FAT and cannot use the host device ('H:') from the command line, and Altirra's SIO-level virtual folders are read-only. The only way SDX can write to FAT is indirectly, via the PCLink protocol (which is filesystem abstracted), and this doesn't work with FAT parititons on hard disks. Until SDX has a read/write FAT16 driver, there's no command-line copying from SDFS to FAT. Edited November 14, 2022 by flashjazzcat Quote Link to comment Share on other sites More sharing options...
phaeron Posted November 14, 2022 Author Share Posted November 14, 2022 1 hour ago, andyhants said: Hi Avery I'm sure I'm just being obtuse again - but please could you clarify your comment on implementing the 'Mount in Windows' option above. Ideally I'm wanting to write to FAT and / or Windows Folders under SDX - so Eg COPY D3:xxxxxxxx.yyy D6:xxxxxxxx.yyy where D3: is an APT partition & D6: is a FAT partition - thanks The Mount feature only exposes the FAT partition to Windows, so you can access it through Explorer. It doesn't expose the partition to SpartaDOS X, which requires an SDX driver (and as fjc noted, currently can only be done read only). Quote Link to comment Share on other sites More sharing options...
andyhants Posted November 15, 2022 Share Posted November 15, 2022 ok guys thanks for your responses. I know I've siad it before but would be really great to get the SDX FATFS driver amended so that it allows writes to FAT partitions as well. Appreciate though its easy for me to say. Has anyone else heard from the SDX dev guys about their apparent reticence to support this ? 1 Quote Link to comment Share on other sites More sharing options...
mirao Posted November 18, 2022 Share Posted November 18, 2022 I'm just playing with debugger, it's really useful tool. A suggestion for command line in debugger: It would be great to save command history so that you can invoke previous commands even after restart of Altirra. Currently history is tracked until you close debugger. Another suggestion: Allow searching in history, something like in "bash" shell - anytime you press 'Ctrl + R' and type a substring, a command is found and ready to execute again. Quote Link to comment Share on other sites More sharing options...
mirao Posted November 18, 2022 Share Posted November 18, 2022 Does anybody get working Direct3D 11 in Altirra on Linux (WINE)? I'm running Ubuntu 22.04, wine-6.0.3, Altirra 4.0.1, CPU AMD Ryzen 7 4700U, graphics Radeon RX Vega 7. Altirra with Direct3D 9: [ 0.232] HOSTDISP: VideoDisplay: Current monitor update: 0000000000000000 -> 0000000000000001. [ 0.381] HOSTDISP: VideoDisplay/DX9: Successfully created Direct3D 9 device. [ 0.381] HOSTDISP: Device: atiumdag.dll (ATI Radeon HD 5600 Series) [ 0.382] HOSTDISP: DeviceCaps: VS3.0, PS3.0, MaxTex 16384x16384, ReadScanline No, HWVP [ 0.383] HOSTDISP: VideoDisplay/DX9: Init successful on adapter 0 (\\.\DISPLAY1 / atiumdag.dll), monitor 0000000000000001. [ 0.385] HOSTDISP: VideoDisplay/DX9: Init successful for 1x1 source image (XRGB8888 -> XRGB8888); monitor=0000000000000001 ... [ 0.633] HOSTDISP: VideoDisplay/DX9: Init successful for 336x240 source image (Pal8 -> XRGB8888); monitor=0000000000000001 Altirra with Direct3D 11, I'm getting only this (Some falllback is done? Because Altirra is working) [ 0.210] HOSTDISP: VideoDisplay: Current monitor update: 0000000000000000 -> 0000000000000001. Quote Link to comment Share on other sites More sharing options...
mirao Posted November 18, 2022 Share Posted November 18, 2022 I've hit a bug when debugging a source file in single instance mode. Versions 4.0.1 and 4.10-test24 are affected. I'm running Ubuntu 22.04 and Wine. Steps to reproduce: Emulator: Create startup.atdbg with the content .sourcemode on Create "test.asm" ORG $3400 lda #1 sta $3501 lda #2 sta $3502 Assemble with MADS and run in emulator $ mads -tl test.asm && (Altirra64.exe /debug /si /debugbrkrun test.obx &) Don't close emulator. Switch back to text editor and remove the instruction sta $3501 and save ORG $3400 lda #1 lda #2 sta $3502 Assemble and run again (the same command as above) Switch to emulator Press F10 twice PC should be set to $3404 (sta $3502), but it's set to $3407 (brk) 🐞. It seems that these instructions were executed on one "F10": lda #2 sta $3502 Also position of current instruction in source file is incorrect 🐞: Note that if you press F10 on "Disassembly" tab, then it works well. Quote Link to comment Share on other sites More sharing options...
phaeron Posted November 21, 2022 Author Share Posted November 21, 2022 https://www.virtualdub.org/beta/Altirra-4.10-test25.ziphttps://www.virtualdub.org/beta/Altirra-4.10-test25-src.7z Fix for line number debug info not being refreshed properly in debugger source windows when reloading symbols. On 11/18/2022 at 2:17 AM, mirao said: Does anybody get working Direct3D 11 in Altirra on Linux (WINE)? I'm running Ubuntu 22.04, wine-6.0.3, Altirra 4.0.1, CPU AMD Ryzen 7 4700U, graphics Radeon RX Vega 7. Altirra with Direct3D 9: [ 0.232] HOSTDISP: VideoDisplay: Current monitor update: 0000000000000000 -> 0000000000000001. [ 0.381] HOSTDISP: VideoDisplay/DX9: Successfully created Direct3D 9 device. [ 0.381] HOSTDISP: Device: atiumdag.dll (ATI Radeon HD 5600 Series) [ 0.382] HOSTDISP: DeviceCaps: VS3.0, PS3.0, MaxTex 16384x16384, ReadScanline No, HWVP [ 0.383] HOSTDISP: VideoDisplay/DX9: Init successful on adapter 0 (\\.\DISPLAY1 / atiumdag.dll), monitor 0000000000000001. [ 0.385] HOSTDISP: VideoDisplay/DX9: Init successful for 1x1 source image (XRGB8888 -> XRGB8888); monitor=0000000000000001 ... [ 0.633] HOSTDISP: VideoDisplay/DX9: Init successful for 336x240 source image (Pal8 -> XRGB8888); monitor=0000000000000001 Altirra with Direct3D 11, I'm getting only this (Some falllback is done? Because Altirra is working) [ 0.210] HOSTDISP: VideoDisplay: Current monitor update: 0000000000000000 -> 0000000000000001. 4.01 doesn't output anything to the log when the D3D11 output path initializes, so this would be expected if D3D11 is used successfully. The 4.10-test releases do. That having been said, it doesn't necessarily guarantee success with WINE. WINE's Direct3D emulation is spotty at best and even broken AF in some pretty fundamental areas of the API. I just spent the afternoon debugging why basically no 2D rendering was working under WINE under a Linux VM, only to discover that WineD3D simply doesn't implement the 10Level9 feature levels properly -- shader constants are completely broken for any 9_1 to 9_3 feature level shaders under D3D11. With that particular hardware configuration, you should be running at 10.0 or higher feature level, so that shouldn't be an issue, but if you get the Sharp Bilinear filtering mode and all 2D rendering broken, that's why, and you'll need to use D3D9. There's quite a lot of other features of the API that Altirra relies on that WINE doesn't completely implement properly, so YMMV. D3D9 tends to work better in general under WINE but you can still run into problems with frame pacing, and just sheer log spam from fixmes unless you modify the WINEDEBUG environment variable. There is a fallback to GDI, as a last resort if all other enabled display modes fail. There is no message logged for this either, but the prime indicator is that image filtering and filtering options are disabled, so the display image will be pretty crispy. The emulator also attempts to fall back to D3D9 if both D3D9+D3D11 are enabled and D3D11 fails, but under WINE this may not happen as it frequently fails and doesn't tell the emulator, so in you're case you're better off enabling only the display mode you want to use. On 11/18/2022 at 10:56 AM, mirao said: I've hit a bug when debugging a source file in single instance mode. Versions 4.0.1 and 4.10-test24 are affected. I'm running Ubuntu 22.04 and Wine. This should be fixed in the test build build above, there was an issue with source windows not properly refreshing their line number lookup caches when reloading new symbols. 6 1 Quote Link to comment Share on other sites More sharing options...
mirao Posted November 21, 2022 Share Posted November 21, 2022 14 hours ago, phaeron said: https://www.virtualdub.org/beta/Altirra-4.10-test25.ziphttps://www.virtualdub.org/beta/Altirra-4.10-test25-src.7z Fix for line number debug info not being refreshed properly in debugger source windows when reloading symbols. It works well, thank you very much! 🙌 Quote 4.01 doesn't output anything to the log when the D3D11 output path initializes, so this would be expected if D3D11 is used successfully. The 4.10-test releases do. 4.10-test logs this when D3D11 only is enabled. [ 0.248] HOSTDISP: VideoDisplay: Current monitor update: 0000000000000000 -> 0000000000000001. [ 0.420] HOSTDISP: Direct3D display driver initialized using adapter: ATI Radeon HD 5600 Series [ 0.420] HOSTDISP: Caps: maxtex 16384x16384 (nonpow2), minprec(none) Then image quality is worse than with D3D9, e.g. D3D11: D3D9: So I'll keep D3D9 only enabled, it looks O.K. Quote Link to comment Share on other sites More sharing options...
baktra Posted November 21, 2022 Share Posted November 21, 2022 I might have discovered a turbo tape related problem. Version -test25, could be also others. Attached is a package with a WAV file (a tape image with Polish Turbo Blizzard records) and a .xex file with loader. When I use the old Altirra 3.90, then the following works: 0. Setup the emulated system as follows: - Plain XL/XE with 64 KB RAM, no extensions etc. - Original OS ROMs - TV System: PAL - Cassette: Turbo support == Enabled (always on). Turbo Decoder: Default option. 1. Boot the .xex file 2. Select option 4 (Blizzard Turbo 2.8) 3. Press SELECT (to run MICROLOADER) 4. Load the .WAV file as a tape image 5. Press a key to begin loading After a while, the MICROLOADER will display the file name and ask to press the 'Y' key to continue loading. The Archon game loads and runs. When I try the same with the -test25 version (after clearing all settings and re-configuration), in step 5, the MICROLOADER will not display the file name. Also the screeching sounds differently. Good to know: 1. The Turbo Blizzard works like the Turbo 2000, but switching on the turbo mode is different. Instead forcing log.0 at COMMAND, Turbo Blizzard forces log. 0 at DATA OUT. That's why I use the Enabled (always on) turbo support. A final question. When I select a different Turbo decoder in the system settings, do I need to reload the tape image? blizpak.zip Quote Link to comment Share on other sites More sharing options...
phaeron Posted November 21, 2022 Author Share Posted November 21, 2022 3 hours ago, baktra said: When I try the same with the -test25 version (after clearing all settings and re-configuration), in step 5, the MICROLOADER will not display the file name. Also the screeching sounds differently. Looks like this tape + loader combination is sensitive to small variations from the turbo decoding type. Changing the turbo decoder to Slope works. 3 hours ago, baktra said: 1. The Turbo Blizzard works like the Turbo 2000, but switching on the turbo mode is different. Instead forcing log.0 at COMMAND, Turbo Blizzard forces log. 0 at DATA OUT. That's why I use the Enabled (always on) turbo support. Hmm, that's an interesting combination, I can probably implement that. 3 hours ago, baktra said: When I select a different Turbo decoder in the system settings, do I need to reload the tape image? Yes, the turbo decoder setting only takes effect on load. Changing the turbo support mode doesn't require reloading the tape. 1 Quote Link to comment Share on other sites More sharing options...
baktra Posted November 21, 2022 Share Posted November 21, 2022 28 minutes ago, phaeron said: Looks like this tape + loader combination is sensitive to small variations from the turbo decoding type. Changing the turbo decoder to Slope works. Yes, Turbo Blizzard is somehow finicky. No surprise, the default transfer speed is very high. So "Slope" it is. 28 minutes ago, phaeron said: Hmm, that's an interesting combination, I can probably implement that. That would be nice. The point probably was to save the extra wire seen with other turbo systems. 28 minutes ago, phaeron said: Yes, the turbo decoder setting only takes effect on load. Changing the turbo support mode doesn't require reloading the tape. Believe it or not, I didn't realize that. That explains some of my problems. Thank you very much for looking into this. Quote Link to comment Share on other sites More sharing options...
Ricky Spanish Posted November 22, 2022 Share Posted November 22, 2022 Where can I get the latest Altirra basic on a .atr ? Wanna try it on my 1200Xl. Thanks ! Quote Link to comment Share on other sites More sharing options...
_The Doctor__ Posted November 22, 2022 Share Posted November 22, 2022 maybe on the additions.atr included in the download.... 1 Quote Link to comment Share on other sites More sharing options...
Mclaneinc Posted November 22, 2022 Share Posted November 22, 2022 (edited) Altirra Basic version 1.58 is built in and I think is also on the additions disk, it also can be dumped via the emulator via tools / Export rom set. But there's also Phaerons project for extended basic that gets updated from time to time, a link to the latest version is here https://forums.atariage.com/applications/core/interface/file/attachment.php?id=644389 Have fun, I think there's a PDF for the extended version in the thread I've linked to, I think.. Link to thread Edited November 22, 2022 by Mclaneinc 2 Quote Link to comment Share on other sites More sharing options...
phaeron Posted November 23, 2022 Author Share Posted November 23, 2022 https://www.virtualdub.org/beta/Altirra-4.10-test26.ziphttps://www.virtualdub.org/beta/Altirra-4.10-test26-src.7z Accuracy fix for reload timing for POKEY timers, adjusting it by one cycle to match hardware. Adds support for turbo tape control by SIO data out (Turbo Blizzard). SIO serial data output is no longer reset by initialization mode (affects two-tone mode). The last one was the result of some scope checks on the 130XE after debugging some reliability issues with a two-tone cycle test. Turns out that none of the reset mechanisms in POKEY reset the bit being sent out through the SIO data output line, so if you stop a transmission at the wrong time, POKEY will just keep holding the data output pin low continually until another byte is sent. Fun for devices waiting for command frames or if you need to use timer 1 in two-tone mode for 1.79MHz clocking. 9 1 Quote Link to comment Share on other sites More sharing options...
ijor Posted November 23, 2022 Share Posted November 23, 2022 2 hours ago, phaeron said: SIO serial data output is no longer reset by initialization mode (affects two-tone mode). The last one was the result of some scope checks on the 130XE after debugging some reliability issues with a two-tone cycle test. Turns out that none of the reset mechanisms in POKEY reset the bit being sent out through the SIO data output line, so if you stop a transmission at the wrong time, POKEY will just keep holding the data output pin low continually until another byte is sent. This is actually documented in the hardware manual, at least to some degree. See the * note about the power up behavior of SKCTL Force Break bit. Quote Link to comment Share on other sites More sharing options...
baktra Posted November 23, 2022 Share Posted November 23, 2022 12 hours ago, phaeron said: Adds support for turbo tape control by SIO data out (Turbo Blizzard). Thank you for this small convenience enhancement. I've tested this enhancement with a tape image that begins with a Turbo Blizzard loader stored as a cassette boot file followed by a Turbo Blizzard file. Booted and loaded just fine. When it comes to the decoder choice, these are my observations. These observations can help those who want to use the Altirra emulator with machine-generated turbo recordings. I believe my observations are in line with the nature of the decoders. For square waveform: The PEAK+HPF works with average bps < 3500. For higher average transfer speeds, plain SLOPE works. For sine waveform: The PEAK+HPF works with average bps < 3500. The SLOPE works with bps <2700, but nothing above. Quote Link to comment Share on other sites More sharing options...
St(r)yker Posted November 24, 2022 Share Posted November 24, 2022 (edited) Phareon - I am kindly asking if you could add SIC!+ cartridge support for 8Mbit memory to the emulator? The proper generated *.bin file is attached. Thanks in advance sic_plus_1024.bin Edited November 24, 2022 by St(r)yker 2 Quote Link to comment Share on other sites More sharing options...
phaeron Posted November 25, 2022 Author Share Posted November 25, 2022 https://www.virtualdub.org/beta/Altirra-4.10-test27.ziphttps://www.virtualdub.org/beta/Altirra-4.10-test27-src.7z Adds support for SIC+ cartridge. Fixed SIC! bugs with debugger reads, flashing, and save states. Added support for MX29F040 flash. Added advanced config vars to set CAR types for supported cartridge types that don't have an assigned CAR number. The register info in the SIC+ schematic was incorrect, so I had to reverse the GAL equations from the JED to derive the chip enables. It turned out to be pretty simple, bit 7 was repurposed from write protect to chip select. Flashing is supported, swap and recover switches currently not. I added the MX29F040 since that's the chip seen in the latest pictures of the SIC+ cartridge; however, it's virtually the same as an Am29F040B except for IDs and a slight change in sector erase timeout and there shouldn't be any software besides the flasher that would notice. Note that the SIC+ firmware images from the SDX betas will not work. Earlier versions are for a different register set than the current SIC+ design supports. The current 4.49g beta ones will work, but the pregenerated .bin image only contains the top 8K of each bank and isn't in a form that the emulator can use. However, the flasher disk can be run with a blank SIC+ cart and then that saved to a usable image. 14 2 Quote Link to comment Share on other sites More sharing options...
Mclaneinc Posted November 26, 2022 Share Posted November 26, 2022 Thanks Avery... Hey Serj, good to see you my old friend.. 1 Quote Link to comment Share on other sites More sharing options...
Mclaneinc Posted November 27, 2022 Share Posted November 27, 2022 I've read Avery's latest post re the emulation of the SIC+ cart, but when I try and dump it as a .car file it says it cannot do it and has to be saved as a raw file.Just trying to understand why, as when we double click the bin (or load as per normal) it ask's what format to load it as, and you pick SIC+. But isn't that us basically being the car header but manually telling it to load as a SIC+. I'm sure there's a perfectly normal reason, I'm just interested in finding out why? Quote Link to comment Share on other sites More sharing options...
phaeron Posted November 27, 2022 Author Share Posted November 27, 2022 5 hours ago, Mclaneinc said: I've read Avery's latest post re the emulation of the SIC+ cart, but when I try and dump it as a .car file it says it cannot do it and has to be saved as a raw file.Just trying to understand why, as when we double click the bin (or load as per normal) it ask's what format to load it as, and you pick SIC+. But isn't that us basically being the car header but manually telling it to load as a SIC+. I'm sure there's a perfectly normal reason, I'm just interested in finding out why? The issue is that the CAR header also has a value indicating what type of cart it is. SIC+ doesn't have a CAR number assigned to it, so Altirra can't set up the header. That's why I added a config variable in Advanced Configuration to allow CAR numbers to be retroactively assigned in the emulator, should one be set for SIC+ in the future. 2 Quote Link to comment Share on other sites More sharing options...
Mclaneinc Posted November 27, 2022 Share Posted November 27, 2022 Thanks Avery, I've become even more lazy with the help of the CAR system header...As always, thanks for the hard work and your time.. Paul.. Quote Link to comment Share on other sites More sharing options...
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.