Search the Community

Version 4.00 of my emulator Altirra is out at the usual place: https://www.virtualdub.org/altirra.html As usual, thanks to everyone who tried the releases or just chimed in on just about anything during the 4.00-test series. Never thought I'd been working on it this long, but here's the highlights (it's been about a year since 3.90): Tape: New turbo support, tape editor, and support for loading raw tapes directly from .flac files. Disk: Atari 815 emulation, 8" disk geometry support, Disk Explorer can now access files in Indus CP/M images, many full disk drive emulation fixes. Display: Palette solver, monochrome mode, HDR display support, ANTIC fixes. Sound: Improved audio filtering, automatic output switching when using WASAPI output, POKEY fixes. Input: Preset template generator for making input maps, low-latency paddle option, retuned trackball speeds, 5200 fixes. Devices: Percom AT88-SPD, SIDE 3, 1090 80-column board, Bit 3, virtual FAT16/FAT32/SDFS hard disk; modem, XEP80 and Rapidus fixes. UI: Improved dark mode theme support. Debugger: Memory window upgraded with variable width, type, and graphics decoding support; improved speed, more banked cartridge debugging support, improved 65C816 native mode support, more timestamped logging options, and more verifier options. As usual, 4.00 final is essentially the same as 4.00-test43, except for version number changes and using the release check-update channel. (Previous thread for 3.90/4.00-test) Note that starting with 4.00, Altirra requires at least Windows 7. For Windows XP and Vista users, there is also a 3.91 maintenance release at the above link, which contains backported changes from 4.00 of critical bug fixes and the latest version of AltirraOS. And, per tradition, starting off the 4.10-test series: https://www.virtualdub.org/beta/Altirra-4.10-test1.zip https://www.virtualdub.org/beta/Altirra-4.10-test1-src.7z The device tree now better preserves selection when adding or removing devices. AltirraOS updated to 3.32 with fixes for a couple of compatibility issues with the math pack, so B-Graph and House of Usher now work. Fixes to the docking UI to reduce glitching when switching layouts or toggling full screen mode, due to panes becoming visible too soon and drawing in weird places before being moved to their final location. Fixed a few timing bugs in the standard disk emulator. 810s now produce the head bump sound, the timeout was too short for Record Not Found (RNF) errors, and with long retries the idle timeout was sometimes kicking in too soon. Happy 810 and 1050 now have retuned receive rates. The standard disk emulator now attempts to emulate track buffering for the Happy 810, 1050, and Speedy 1050 profiles, where the drive will burst transmit sectors from memory after reading in new tracks. This makes timing closer to the default modes for those drives. The Happy 1050 commands for toggling track buffering are now also support.

A.R.T.I. (Archaeological Rescue Team International) LATEST DEMO IS AVAILABLE HERE Play on JS7800 HERE A.R.T.I. was released in limited numbers at PRGE2023 and is also available in the VCS store. A.R.T.I. is available in the AtariAge store now! A.R.T.I. is also available on the VCS store for the VCS and a digital version is available A.R.T.I. is inspired by the classic 2600/C64/A8 game H.E.R.O. by Jon Van Ryzin. H.E.R.O. Objective You are Arty's new apprentice. A bunch of explorers and adventurers have got themselves lost in South America and you need to go and rescue them. There are additional on-ROM instructions accessible from the title page. Controls Left & Right - Run / fly left and right. Up - Activate the jetpack Fire 1- Laser Fire 2- Dynamite A.R.T.I. supports SNES2Atari and MEGA7800 to give addition control options and the ability to pause from the controller. Scoring Rescuing a lost explorer or adventurer will earn you 1,000 points. Destroying a wall is worth 75 points Killing any critters or beasties is worth 50 points Bonus points are awarded for each stick of dynamite remaining and for remaining power, when making a rescue. An extra life is awarded at 20,000 points Demo A 10 level demo is available below. Please note the demo is currently designed for NTSC machines and is not fully optimised for PAL machines yet- there may be speed glitches etc. Regular version - Works on real hardware, MiSTer, Dragonfly, BUP, A7800, 7800GD A.R.T.I. Compatibility A.R.T.I. is tested and working great with Dragonfly, GD7800, MiSTer, A7800 V5.2 or better and JS7800 & 7800DS Emulators A.R.T.I works with most Emulators but has some issues with BUP System (Some POKEY notes are off key) and Legacy ProSystem based emulators (some graphical glitches and POKEY notes are off). Plans All done! Credits & Thanks @sramirez2008 @-^CrossBow^- @Trebor for their testing and feedback - fantastic as always! @RevEng for help with compression and answering my never ending stream of questions! @Synthpopalooza for some Pokey Perfection @mksmith for helping to get the tunes into the game! @ZeroPage Homebrew for showing the demo on the stream Media

Welcome to Atari Dev Studio for designing homebrew games for the Atari 8-bit systems (Atari 2600 and 7800). Atari Dev Studio is a one-stop-shop for any programmer and includes a number of built-in features to allow you to design, develop and test games for your favourite system. Get started with batari Basic (2600) or 7800basic (7800) using easy to learn BASIC-like languages or go hard-core with assembly using dasm. During development test your creation using the Stella (2600) or A7800 (7800) emulators right from within Atari Dev Studio. Requirements Atari Dev Studio is an extension for Visual Studio Code and VSCodium and will run on the Windows, Linux and macOS platforms. The latest releases of batari Basic, 7800basic, dasm, Stella and A7800 are included so you can begin coding straight after installing the extension. Features Atari Dev Studio includes the following features: Develop your game on Windows, Linux or macOS Compile source code for your Atari 2600 or 7800 using batari Basic, 7800basic or dasm Use scripting (makefile, batch or shell script files) to build your dasm projects [preview] Optionally launch and test your game using the Stella (2600) or A7800 (7800) emulators Document outline support (batari basic, 7800basic, dasm) Peek/Go to Definition and Reference support (batari basic, 7800basic, dasm) Built-in Sprite Editor (also suitable for tiles and other objects) [preview] Manage your project using the File Explorer or version-control your source code directly with GitHub (and others) using the built-in features of the Visual Studio Code platform. Provide references to your own specific releases of each language or emulator rather than use the includes ones via the Settings. Additional features are planned for the future. At this time the focus is on the core functionality and ensuring full cross-platform support. Installing Atari Dev Studio What is Visual Studio Code? Visual Studio Code (VS Code) is a streamlined code editor with support for development operations like debugging, task running, and version control. It aims to provide just the tools a developer needs for a quick code-build-debug cycle and leaves more complex workflows to fuller featured IDEs, such as Visual Studio. Which OSs are supported? VS Code is a cross-platform application which runs on Windows, Linux and macOS. See requirements for the supported versions. Note: Linux users on 64-bit systems will be required to install the 32-bit compatibility libraries on your system to ensure everything will run as expected. Note: macOS users will require a 64-bit operating system to fully utilise all features of Atari Dev Studio and will be required to install the SDL libraries on your system to ensure the A7800 emulator will run as expected. Note: M1 based Mac users will need to install the INTEL CHIP version of VS Code before installing Atari Dev Studio. Also thanks to Scott Lahteine (thinkyhead) the current dev stack should now have compatibility with the M1 chip (ARM64) and includes most of the recent versions of bB, 7800basic, Stella and dasm. See here for further discussion around the potential issues you may encounter. Installing the extension Once you have installed VS Code (available here) or VSCodium (available here) open the program and complete the following: From the Activity Bar, click the Extensions button to display the Extensions window. From the Extensions window, type Atari into the Search box and press Enter to display the list of available extensions. From the list of available extensions, locate Atari Dev Studio and click the green Install button. Updating the extension Updates will be regularly provided and you will be notified via VS Code when one has been made available. Once an update has been installed you will generally be prompted to restart VS Code. Using Atari Dev Studio Compiling your program To display the available extension features press CTRL+SHIFT+P to display the Command Palette. From the command palette prompt type adv to short-list the available options: ads: Open the Welcome page ads: Compile source code (Shift+F5) ads: Compile source code and run in emulator (F5) ads: Kill build process ads: Open the Sprite Editor Language Selection When you load a file the initial language will be chosen based on the file extension. For example: batari Basic (.bas, .bb) [Default for .bas files] 7800basic (.bas, .78b) dasm (.dasm, .asm, .a, .h) To change a language you can click on the Status Bar Language selector and a list will be shown allowing you to choose another language. Optionally in the Settings you will be able to either let the extension choose based on the active language or set a specific language to always compile against. Build scripts [preview] Prefer using scripts to build your dasm games? If you have chosen to override the dasm compiler (select Make via the Settings) , Atari Dev Studio will scan and detect for makefile, batch (makefile.bat) or shell scripts (makefile.sh) files which are located in your root workspace folder to build your game. Note: You are totally responsible to ensure your environment is properly configured to allow you to utilise the tools and applications you will be interacting with. No support will be provided for this feature. Status Bar Apart from using the Command Palette to select compilation, there are a number of short-cut buttons on the Status Bar allowing you to: Display the extension version (might be useful at times) Open the Welcome page Open the Sprite Editor Compile source code (Shift+F5) Compile source code and run (F5) Note: The short-cut buttons on the Status Bar can be turned off via the Settings. Sprite Editor [preview] Atari Dev Studio includes a simple and easy to use Sprite Editor allowing you to create sprites, tiles and other objects for use in your projects. It has the following features: New Project wizard allowing you to select the console (2600 or 7800), size, region (NTSC or PAL palette) and total colors of your sprites Load and Save projects allowing you to save and come back to on-going work Editing features such and palette selector, zoom, pen, eraser, fill and move modes Ability to manage your sprites in a sortable list with options to copy, paste, duplicate, resize and delete Export sprites to batari Basic or assembly source code (2600) Export sprites to .png files (7800) - either selected or all (compatible with 7800basic 3+1 and 12+1 image requirements) Load and save palettes The Sprite Editor is based on Spritemate by Ingo Hinterding (GitHub) and was suggested by RandomTerrain for inclusion in Atari Dev Studio. I have customised the source to provide the required features necessary for editing sprites, tiles and objects for the Atari platforms. This work is currently in preview and will be on-going until all required features have been added. Settings There are a number of compiler, emulator and editor configuration options available in Atari Dev Studio which can be changed via the Settings (Preferences -> Settings -> Extensions -> Atari Dev Studio). Debugging the extension During the development phase of the extension I've added some developer output to assist with any issues that may appear. To view this output, open the VS Code Developer Tools by selecting Help -> Toggle Developer Tools from the menu, and in the debugger window ensure the Console tab is activated. This information may help identify the area where the extension is failing to process as expected. Known Issues There are currently no known feature issues. If you find a problem please raise an issue on GitHub or contact mksmith at the AtariAge community. Acknowledgements This extension is only available due to the great people of the AtariAge community who have created these tools to help developers build their vision. Special thanks to the following for either allowing the inclusion of their tools or for their ongoing help and encouragement: 7800basic - Mike Saarna (RevEng) batari Basic - Fred Quimby (batari) and Mike Saarna (RevEng) dasm - the many contibutors Stella emulator - Stephen Anthony (stephena) A7800 emulator - Mike Saarna (RevEng) and Robert Tuccitto (Trebor). Scott Lahteine (thinkyhead) for the M1 Mac Compatibility for bB, 7800basic, Stella, dasm (generally or close to the most recent versions) Mats Engstrom (SmallRoomLabs) The AtariAge community including Albert, CPUWiz, Random Terrain, Trebor, Synthpopalooza, sramirez2008, Defender_2600, Gemintronic, Karl G, ZeroPage Homebrew, Muddyfunster, TwentySixHundred, Lillapojkenpåön, Andrew Davie, splendidnut, andyjp, sexyUnderwriter, MikeBrownEmplas, Generation2Games, cwieland, slacker Languages Atari Dev Studio includes the following programming languages: batari Basic (release 1.7 - 20220703) batari Basic created by Fred 'batari' Quimby is a BASIC-like language used in the creation of Atari 2600 games. batari Basic is compiled to generate a binary file that can by used on actual Atari 2600 VCS hardware via cartridge (such as a Harmony or UNO cart) or by using an Atari 2600 VCS emulator such as Stella. batari Basic is an external project is kindly currently maintained by Mike Saarna (RevEng) and can be downloaded separately from here. Further information is about this release is available here at AtariAge. 7800basic (release 0.33 - 20240208) 7800basic is a BASIC-like language for creating Atari 7800 games. It is a compiled language that runs on a computer, and it creates a binary file that can be run with an Atari 7800 emulator, or the binary file may be used to make a cartridge that will operate on a real Atari 7800. 7800basic is derived from batari basic, a BASIC-like language for creating Atari 2600 games. Special thanks to the bB creator, Fred Quimby, and all of the bB contributors! 7800basic is included as part of this extension with many thanks to Mike Saarna (RevEng). 7800basic is an external project and can be downloaded separately here. Further information about this release is available here at AtariAge. dasm (release 2.20.14.1 - 20201109) dasm is a versatile macro assembler with support for several 8-bit microprocessors including MOS 6502 & 6507, Motorola 6803, 68705 & 68HC11, Hitachi HD6303 (extended Motorola 6801), and Fairchild F8. Matthew Dillon started dasm in 1987-1988. Olaf 'Rhialto' Seibert extended dasm in 1995. dasm has also been maintained by Andrew Davie (2003-2008) and Peter Froehlich (2008-2015). The DASM team has taken over maintaining and updating dasm since 2019. dasm is an external project and can be downloaded separately here. Emulation Atari Dev Studio includes the following emulators for testing purposes: Stella (release 6.7.1 - 20240116) Stella is a multi-platform Atari 2600 VCS emulator released under the GNU General Public License (GPL). Stella was originally developed for Linux by Bradford W. Mott, and is currently maintained by Stephen Anthony. Since its original release several people have joined the development team to port Stella to other operating systems such as AcornOS, AmigaOS, DOS, FreeBSD, IRIX, Linux, OS/2, MacOS, Unix, and Windows. The development team is working hard to perfect the emulator and we hope you enjoy our effort. Stella is included as part of this extension with many thanks to Stephen Anthony. Stella is an external project and can be downloaded separately here. If you enjoy using Stella place consider donating to ensure it's continued development. A7800 (release 5.2 - 20220626) A7800 is a fork of the MAME Atari 7800 driver, with several enhancements added: Support for emulation of Proline Joysticks, VCS Joysticks, Lightguns, Paddles, Driving Controllers, Keypads, Trak-Balls, Amiga Mice, and ST Mice. Support for emulation of Proline Joysticks, VCS Joysticks, Lightguns, Paddles, Driving Controllers, Keypads, Trak-Balls, Amiga Mice, and ST Mice. Maria DMA timing has been improved further, with the addition of accurate DMA hole penalties. Selectable and improved palettes with enhanced screen options. Streamlined UI including menu options to have an Atari 7800 system focus. A bug in the existing RIOT emulation has been fixed. POKEY sound emulation improvements. SALLY (CPU) and MARIA (Graphics chip) performance adjustments. Audio indication of no ROM loaded silenced. BIOS files no longer required and made optional. Implementation of XM control registers updated. Graphical register updates made mid-scanline are now displayed mid-scanline. Bankset bankswitching support added. POKEY@800 added for non-banked, supergame, and bankset formats. Machine targets a7800dev and a7800pdev added, which display DMA usage per-scanline. MAME compatibility and syntax has been maintained, to allow for the reuse of MAME configuration files and front-ends. A7800 is included as part of this extension with many thanks to Mike Saarna (RevEng). A7800 is an external project and can be downloaded separately here. Further information about this release is available here at AtariAge. A7800 Linux The following libraries may be required for Linux users: TESTED ON UBUNTU 22.04 LTS (12/07/2022) sudo apt-get install -y libsdl2-2.0-0 sudo apt-get install -y libqt5widgets5 sudo apt-get install -y libsdl2-ttf-2.0-0 Releases 20240209 - Build v0.9.6 / 20231106 - Build v0.9.5 / 20231101 - Build v0.9.4 / 20231003 - Build v0.9.3 / 20230923 - Build v0.9.2 / 20230809 - Build v0.9.1 / 20230731 - Build v0.9.0 20230703 - Build v0.8.9 / 20230702 - Build v0.8.8 / 20230518 - Build v0.8.7 / 20230302 - Build v0.8.6 / 20230209 - Build v0.8.4 / 20230104 - Build v0.8.3 / 20230102 - Build v0.8.2 / 20221107 - Build v0.8.1 / 20220730 - Build v0.8.0 20220702 - Build v0.7.8 / 20220628 - Build v0.7.7 / 20220627 - Build v0.7.6 / 20220614 - Build v0.7.5 / 20220504 - Build v0.7.4 / 20220401 - Build v0.7.3 / 20220101 - Build v0.7.2 / 20210422 - Build v0.7.1 / 20210315 - Build v0.7.0 20210305 - Build v0.6.9 / 20210216 - Build v0.6.8 / 20210210 - Build v0.6.7 / 20201124 - Build v0.6.5 / 20201008 - Build v0.6.4 / 20200917 - Build v0.6.3 / 20200915 - Build v0.6.2 / 20200912 - Build v0.6.1 / 20200901 - Build v0.6.0 20200829 - Build v0.5.9 / 20200624 - Build v0.5.8 / 20200622 - Build v0.5.7 / 20200616 - Build v0.5.5 / Build v0.5.6 / 20200608 - Build v0.5.4 / 20200518 - Build v0.5.3 / 20200508 - Build v0.5.2 / 20200429 - Build v0.5.1 / 20200427 - Build v0.5.0 Manual download

Previous thread Here's the release of Pokey Explorer v1.1. It's a tool to explore all possible combinations of Pokey registers that have an effect on the sound you hear. New: - 16-bit intervals - hold START to STOP a running sweep1 - batch processing Batch processing is for advanced users. I have included an example sweeps.s file. You can change that, or include your own source file with multiple sweeps and rebuild the batch binaries. TODO: Do a really long sweep with e.g. 20 different settings and long play times. After that, import the file in Audacity and cut-off the noise before the first countdown and everything after The Final Countdown With the correction factors mentioned in the previous thread, you can calculate exactly where each sweep starts and stops. Write a Bash script to do the calculations automatically. Cut-up the file in pieces, then run them through aubiopitch, and Bob's your uncle. Hopefully Full source is here. And the manual. 1 That's like old Windows, where you have to go to the START menu, to stop/shutdown your machine pokeyexp-batch-v1.1-ntsc.xex pokeyexp-batch-v1.1-pal.xex pokeyexp-v1.1-ntsc.xex pokeyexp-v1.1-pal.xex

Here's the release of v1.0 of Pokey Explorer! Pokey Explorer is a tool to explore all possible register combinations of the Atari 8-bit Pokey chip. Here's the source, and some kind of manual This originated in this thread, where you can see how it came to be, and why There are two binaries. One for PAL and one for NTSC, because the sweep timing is different (edit: and the tuning notes are different!) Have fun and explore Please report any bugs you find. pokeyexp-v1.0-ntsc.xex pokeyexp-v1.0-pal.xex

I wrote in to AA to ask, but I a friend directed to this thread, so I might as well try to get visibility. Got my 7800GD. I formatted a 4 gig SD card as FAT32, copied Trebor's pack over and then made sure to "eject" the SD card from Windows to be sure the files were all closed and flushed. When I turn on power, I get the "Saint" boot screen, a message about firmware upgrades (press start to upgrade firmware), then I get dumped into the file explorer. I can't see the highlight bar move, and when I hit fire, all I get at the top of the screen is "./00". If I hit fire 3 times, I'll get "./00./00./00". My 7800 is not modded; the only thing I have done to it is reflow the pads around the RF modulator as they were cracked (My intent is to modify this unit for AV out at some point). I do not have a cable to try the AV out (they are pricey) from the 7800GD. I have tried Dig Dug as a standalone cart, and it boots and I can play on my 7800. I also tried playing Ballblazer on my Concerto cart with the POKEY installed, and it plays fine. I cleaned the cart port for good measure on the 7800 just in case, but no dice. The concerto is using the exact same SD Card that was intended for the 7800GD, just in the size adapter and it seems fine. Thoughts/help?

Hello, since I got back into Atari and discovered the excellent Mad Pascal compiler, I fell into programming again .. so here’s my first Atari program since Atari BASIC programs in the late eighties, also my first pascal program again after .. decades? My target is Ultima V: I was envious in the late 80ies when I saw it at my C64 owning friends - I was impressed by that open world RPG approach!; where I sat at home with my 800 XL without much access to software, fiddling around with some BASIC.. So now - decades later – I can find remedy with the power of Mad Pascal, by writing my own Ultima V port Of course port is a much too big word! It almost certainly will never reach the state of a full game. What you can do is to explore the Lands – an Seas - of Britannia; visit it’s famous towns, mighty castles & picturesque villages! Some basic interaction with the world is possible – rearrange your room, go eat out at one of the many taverns or maybe you care to play 'Stones' on the harpsichord? (See splash screen for the available commands) As I’m in PAL land, I never had the possibility of mode F artifacting on real HW, like it was done in Ultima IV. Also I think that a more colourful approach would be nice: so the idea to use ANTIC mode E for the map viewport, with a 13x10 grid - widescreen! (The original is11 x 11). A tile consist of 12x16 pixel. I converted them from the original assets – available on the net – from 16x16x4c down; and did some basic manual retouching. I’m not good at graphics, so I guess there’s great potential left in the tile design if a real pixel artist would put his hands on that. What I tried though is to make use of “PAL blending” to create a fifth color – grey - and used that for walls, rocks, mountain, .. Another future possibility is to do some PM “augmentation” to the tiles, similar like it is now done for the Avatar tile. Adding red for torches, fires and the like would be an ideal candidate, since it would even look like by design should it flicker The text and info ‘console’ is layout below the map (instead as on the right side like in the original), using mode 2. I extended the displaylist from the standard 192 to 216 scanlines to make more room.. I could only test NTSC with Altirra, where it seems usable still. The attached ATR is a 180K DD mydos disk using xBootDOS. I did not include the original .DAT files that are needed by the program, since I guess that they are still under EA copyright: You would have to copy them by yourself on the disk; I used the files from MSDOS version that GOG offers. The files currently needed are: BRIT.DAT CASTLE.DAT DWELLING.DAT KEEP.DAT TOWNE.DAT (the program will created index files at the first run and tell you if it misses a certain file) I’ll be glad to share the sources and assets if there is interest! (Just needs some clean up first as it grew in all direction while writing and learning) Big thanks to @tebe, @jac!, @gury & @xxl for their development tools that I’m using, and the whole Atariage 8-bit forum for the tons of information I’m getting from here! Thank you! So, what do you think of the idea of doing an Ultima V engine in such a layout? PS: I was looking for pokey conversions of Ultima songs, but could not find any.. maybe someone knows more about that? Music would be a great addition! ULTIMAV_WorldExplorer_v0.01.atr.7z

Hey there, it's been a while since I last posted in this thread. So tonight while I was playing in some of my experimental stuff involving a MIDI controller and Raster Music Tracker, I accidentally discovered what appears to be a POKEY emulation bug involving the 16-bit timing using the AUDCTL Join Channel bits, while also outputting volume on the LSB 16-bit channel (something lovingly nicknamed Reverse-16 Output). How could I describe it and still make sense? Well to make a short description, modulating the 16-bit frequencies, while outputting the sound in the LSB channel outputs a unique kind of tone, and it does have a lot of nice musical application with enough dedication, notably, creating a harmonic tone in a pulse/distortion motion, that would also be exactly 1 octave higher than the actual 16-bit tone underneath, so this is a somewhat predictable effect, making use of the 2 pair of 16-bit channels. Well, here's when things took me by surprise: I noticed the sound output from the ch1+2 and ch3+4 pairs is very different to each others! Specifically, only the ch1+2 pair does seem to sound correct, the other would seem to output the exact same pitch that would be in the MSB 16-bit channel output, and it would also crackle a lot whenever a single POKEY register would receive new data, for some reason. I spent a bit more time earlier tonight to see if this was a normal occurrence, or if I was responsible for the bug in question, and to my surprise, this appears to be a bug present in Altirra for a really long time! I tested versions from the most recent test build, all the way back to 2.80, and as far as I could tell, the behaviour in question (that is, the ch1+2 and ch3+4 pairs having a big disparity in sound output) seems to have been introduced in version 2.90. Version 2.81, 2.80, and most likely further down, did not actually feature this difference, both pairs of channels will sound identical, but unfortunately the emulation accuracy of the Reverse-16 sound is also lower. Also, I did test the exact same setup on real hardware, using both my PAL and NTSC Atari 800xl, and they do not suffer from the disparity-- each pairs of Reverse-16 channels will always sound identical. Same for the Atari800 emulator, it sounds pretty much exactly the same as hardware, in this specific setup. TL;DR: The Reverse-16 output is most likely incorrectly emulated between channels, where CH1+2 is the only one sounding proper, while the other pair is very off. What is expected to happen is that regardless of the 16-bit pairs, the sound should be identical, as far as hardware comparisons went to confirm this was not something I caused myself earlier. --- Anyway, how to reproduce the effect in question? Written below is a simple way to hear what is going on, and this was also how I tested for the disparity going on for every version/platform I tested it, including RMT (where I initially noticed it): - Using POKEY Explorer is the fastest and easiest way to showcase the bug, so first, simply load the .xex in Altirra/hardware/etc - Next, set the 4 AUDF channels to the following frequencies, in this order: $FF, $01, $FF, $01 - Now, press the J and K keys, this will activate the Join Channels 16-bit mode to both pairs, still running in 64Khz mode Once these initial steps are complete, do the following, and you will immediately notice what I am talking about: - Firstly, increment the volume level in channel 1 using the 2 key to a audible level - Next, start decrementing the channel 1's AUDF value using the Q key - What will then happen is the Reverse-16 sound in action, and this should sound exactly as expected The pitch will go higher, while also the pulse wave will change its shape to modulate a different timbre as the frequency is being shifted. - Once you are satisfied of what was heard, lower the ch1 volume back to 0 using the W key, in order to test the ch3 for the same setup - Now, increment the ch3's volume level the same as before, using the 6 key - And just like before, lower the ch3's AUDF using the T key, and listen carefully the sound that will be output From this point onward, 2 things may happen: - The sound produced is exactly the same in either ch1+2 or ch3+4 pairs --EXPECTED Or - The sound produced in the ch3+4 pair is very garbled each time a tiny change is applied, and appears to be identical to the underneath 16-bit tone if it was output the intended way --INCORRECT The second one is exactly what happens in Every Altirra versions I tested, all the way down to the version 2.81, at this point, the 2 channels pairs will sound the same, but with lesser accuracy to what it should sound like on hardware. --- And that's about it, if reading this much text sounds a bit boring, here's the RMT capture I made when I first noticed the behaviour: simplescreenrecorder-2022-05-28_22.04.18-CUT.mp4 While it is not truly the Altirra emulator, I can say for sure this is 100% identical to what the stand alone emulator also did, before I went ahead and gave a more indepth testrun. Also, for further precision, the Altirra emulation core running through the plugins used in this recording came from the version 4.00. So yeah, like I said above, what is expected, and should happen, is that the ch1+2 and ch3+4 output must be identical, fact backed up with hardware tests a few minutes later. Thanks for reading a bit of rambling, I hope this may help tracking down why this is happening.

There's no banking. Just loading from storage for each frame. Like Phaeron's IDE video player. That's the beauty of it. ANTIC (yes ANTIC) loads the video RAM directly from the IDE device (or SD card with an IDE API emulated). The CPU just selects a different block out of 16GB every frame, and there's a new frame on your display! Yeah, I recognize the ambivalence. I accept stereo Pokey somewhat, but I am more impressed by single Pokey songs. Extra storage, okay, but where's the limit? 16GB is a Whole Lotta Bytees Co-processor on a cart was well known in the MSX, (S)NES and Sega world, but not so much in our 8-bit time just before that. Only Pokey in some 7800 carts. Wrathchild demonstrated a very cool MODE 7 implementation for the Uno Cart. Yes, I like it. I thought it was about the engine fitting in 16kB, but now I read it should run on a 16kB machine, too That's cool. I really appreciate the effort. Similarly, I made sure that Pokey Explorer runs on a 16kB machine

Thanks! A lot of trial and error was involved... A lot of errors were produced during that journey But with enough dedication I managed somehow to learn C++ along the way, so It think this was worth it! Hahaha! Just wait for the next commit/version, as well as the updated POKEY plugin incorporating the most recent improvements from Altirra. Can't wait to make the "POKEY Explorer Mode" fully toggleable through the Debug Mode I have been adding to RMT ?

Version 3.90 of my emulator Altirra is out: http://www.virtualdub.org/altirra.html Thanks for everyone's continuing support, whether it be bug reports, feature requests, discussion, trying out the helper programs on real hardware, etc. 3.90 final is essentially the same as 3.90-test34, except for release changes. Although previous versions tended to be about six months apart, it's almost been a year since 3.20, so I figured I'd better hurry up. Highlights of the 3.90 release: Accuracy: 800 System Reset timing fixed, undocumented RMW and WSYNC timing fixes, several fixes to 65C816 direct page wrapping and Veronica, many fixes to FDC/RIOT/6809 for full disk drive emulation, improved POKEY two-tone mode emulation, more accurate power-up hardware state. Debugger: Improved disassembly window with automatic block separation and inline call target preview, more disassembly options, better loop detection in the history window, Alt+Shift+click to jump to history for a pixel. Disk drives: 810 Turbo, Amdek, and Percom AT-88 full emulation; easier file import/export in the Disk Explorer. Display: Improved PAL artifacting and color defaults, gamma-corrected frame blending, color setting import/export, PERITEL and monochrome monitor emulation, fixes to color correction logic (esp. with VBXE). Firmware: Updated AltirraOS 3.26 for improved compatibility with hardware addons and software, improved autodetection for custom OS ROMs. Tape: Faster emulation especially in warp mode, audio filter compensation for better turbo decoding, and enhanced debugging for tape issues. Video recording: Aspect ratio correction, scaling, and direct H.264/WMV compression support through Media Foundation. UI: Dark theme, improved audio monitor/scope, improved timing for slightly reduced latency. With 3.90 done, it's now time to start the 4.00 test series: http://www.virtualdub.org/beta/Altirra-4.00-test1.zip http://www.virtualdub.org/beta/Altirra-4.00-test1-src.zip First, there are a couple of breaking changes in 4.00: End of support for Windows XP SP3 and Vista. The new minimum operating system requirement is Windows 7 SP1. End of support for DirectDraw, which has not been native since Vista, and OpenGL, of which only old versions were used anyway (and was not enabled by default). New features and fixes: Palette solver: Matching color palettes in Altirra has been a long-standing issue, since it is unable to take .pal/.act files due to needing the generation parameters for the palette rather than the final colors for various features, and matching colors from real hardware is a difficult task. Pretty much everyone has their opinion on what "true colors" should be. Well, in 4.00-test1 there is now a solver to guess the parameters for you: You can either give it a PAL/ACT file, or you can give it a picture -- and although the picture needs to be a good one, it doesn't have to be perfectly straight as you can align it to compensate for projection by dragging the corner dots. It's compatible with any show-palette tool for the Atari that does 16 lumas across and 16 hues down. Click Match, and it'll start grinding on the parameters to try to get as close as possible, and tell you how good the match is. Or, you can have it overlay the current palette as dots over the picture to check the palette while manually tuning it. Debugger: On-screen watches now update continuously while stepping and the 'wx' command has options for hex formatting, bank-sensitive debugging is now supported for SpartaDOS X cartridges, improved handling of subdirectories when looking for source files, and the console output window is faster when flooded with output. Oh, and the Memory window has been improved with scrolling and more display options: Display: Added pure white monochrome mode, and fixed a bug in the high artifacting engine where chroma artifacts moved in the wrong direction for ascending hues. XEP-80: Fixed an emulation bug in the way that scrolling occurs, and added a couple of new toys to the Additions disk: an XEPVHOLD.COM tool to reprogram the XEP80's timing chain for a shorter display that's less likely to roll on modern displays, and a new ultra-speed ALTXEP8U.SYS driver that runs at symmetric 31.5Kbaud instead of 15.7K or 31.5K send / 15.7K receive. Tape: Added support for KSO Turbo 2000. Disks: Added emulation for the Percom AT88-SPD, and added 1791/1795 FDC selection for the AT-88. Fixed support for virtual SpartaDOS disks with directories and files whose names start with periods. Added a polling workaround option for virtual disks for environments where file change notifications don't work (some Wine environments). Audio: More accurate emulation of uneven volume bits, and rewrote cycle-level filtering emulation for improved high frequency aliasing rejection during downsampling. UI: Dark mode now has reskinned buttons. Added support for auto-hiding the menu bar. Fixed mouse wheel scrolling when the OS page-at-a-time option is on. H: device: Lifted 16MB limit for binary (untranslated) access, and fixed errors not being returned properly during burst I/O accesses. AltirraOS 3.27: Fixes to the printer handler for EOL handling, particularly for the Atari 1025, and improved compatibility of variable usage to work with Monkey Wrench II. Custom Devices: More scripting language constructs like break, while/do-while loops, and forward declaration of functions, better threading support, and more scripting methods for manipulating memory. Custom devices can now raise Parallel Bus Interface IRQs. Custom video outputs can now be created with either text or graphical output, and even support text select/copy like the emulator's built in ANTIC and XEP-80 video outputs. New sample custom devices: Bit-3 80 column, 1090 80-column, and a PBI-based metronome.

Thanks! I'm currently investigating the easiest way to batch process automated sweeps. Current options I'm considering: 1. Reimplement C99 Pokey according to Altirra specs and reimplement Pokey Explorer as a native command line utility. Batch process with a shell script and aubiopitch. 2. Patch atari800 to make it possible to programatically end the emulator from within the emulated machine. Prepare a whole bunch of different .xex files with different sweep settings with a patched Pokey Explorer that does no keypresses, but sweeps immediately and exits after that. Run them all sequentially and use -pokeyrec. Pray that the sub-par emulation does not interfer too much with aubiopitch frequency detection. 3. Fix atari800's Pokey emulation and continue with step 2. 4. The same as step 2, but with (wine) Altirra. Not sure if Altirra supports a command line option to enable audio recording. Would need help from Phaeron anyway, because I don't have Windows and Visual Studio. 5. Run all the patched Pokey Explorer binaries sequentially on real hardware and record the audio ouput. Any other ideas? The easiest is #5 or #2. The most useful is #1, also for somebody who might want to write a new tracker. Another thing I have thought about was implementing a way to control atari800 through a socket connection. You run it once, but you can reset the machine, load binaries, read/write memory, et cetera. And then hope that phaeron implements the Altirra side This could be option 6. The important benefit of having a native tracker running its player code on a full blown emulator back-end, is that when the emulator improves, your sound replay improves, too.

There is a lot of misnomer but you are mostly correct, it's either squarewave or (periodic) noise. There is an actual "sawtooth" waveform that can be generated from the POKEY using the filter and 2 generators at 1.79mhz, however The Atari bass sound? that would be... a periodic noise. I know some people call it sawtooth but that's not what this looks like under an oscilloscope. Ohhh good idea, that would help for explaining, thanks for the suggestion! By far the easiest way to test sounds is by using POKEY Explorer by ivop, a really nice tool which has helped me a lot during my tests. Thank you! That's a pulse wave! this synth technique is usually called Pulse Wave Modulation, or PWM for short. This waveform is also the most characteristic sound used on the SID chip, but the POKEY has its own twist for generating it using the "high pass filter"

Sure, it is not easy. But IIRC years ago debian servers were hacked this way. And it was detected, but not before several people were breached. Sure, that's not MITM, but Man Upfront that creates malicious software in the first place. That's a matter of trust and we trust Tebe. If mads indeed was doing weird things behind our backs and it was found out, that would be the end of Tebe's imago. People also happily run FJC's U1MB firmware or my Pokey Explorer. The latter is open source though, but nobody checks if my .xex is indeed that source Trust. That sounds better. That way, the System Installer also keeps track of which files get installed and it can also be properly uninstalled if needed. That's also one of the reasons why curl|bash should not be used, but a proper package manager, which I assume the system installer is. Haha

Both NTSC and PAL tuning tables Pokey Explorer uses, are calculated by https://github.com/ivop/pokey-explorer/blob/master/util/genfreqtab.c I believe my tables are correct. How does your COMPUTE! table compare to https://github.com/ivop/pokey-explorer/blob/master/tuning-16bit-ntsc.s ?

In other news while I have been busy for the last couple days with real life stuff mainly, I still managed to find some time to work on RMT and have been able to incorporate a few improvements as well as a few bugfixes since the video preview of the other day. - Fixed the 'jumpy/unstable' playing line in "follow" mode, a bug I know was a thing since forever as far as I could tell. - Rewrote a large portion of the TRACK/SONG drawing function to allow greater flexibility in the display routines, note that currently this looks virtually identical to before, since most of the changes are internal, and intended for greater customisation later, including the "smooth scroll" code I have added in the process. - Added more tuning code that now displays accurately Distortion 4 pitches, tables coming sometime later (thanks synthpopalooza for the initial work for helping me identify the patterns I needed for calculations - Like I said above, a "debug mode" is in the work, which is mostly more infos displayed on screen, and could be toggled from settings - A "POKEY Explorer Mode", which is intended to recreate most of the functionalities of the namesake tool created by ivop, and will become incredibly helpful to track down patterns for creating new pitch calculations formulae, as well as generating new tables in the future. None of what I mentioned has been yet commited to the repository, but this will come soon, I promise this will be worth it

By the way, do you really miss the tuning feature, i.e. where you can select F#5 $Ax NTSC tuning and put in some AUDF, or put C4 $Cx 16-bit PAL tuning into one of the AUDF-pairs? I'm asking, because I'm considering calling this a v1.0 release, perhaps add 24-bit and 32-bit sweeps later (that'll still fit in 16kB), and skip adding the CTRL-T tuning page. Instead, I want to implement a new Pokey emulation, based on all the latest insights, mostly done by phaeron. In the past, I have looked into turning his Pokey emulation into a stand-alone DLL, but that turned out to be way more complicated than I expected. It's C++, it's Windows only, lots of dependencies on libraries with Japanese names that make no sense to me, and so on. As I have seen much of his code, I cannot create a Pokey emulation under 0BSD license, but I have to abide to phaeron's license, which is GPL2 IIRC. The plan is to use the Pokey datasheet and especially Phaeron's implementation as documentation, and write a new emulation in pure C99. And only the sound portions. So, the polycounters, the sampling algorithm, the proper reset delays, two-tone mode, joined channels, filters, but no POt and KEYboard routines And no SIO. After that, resample the 1.79MHz audio output to 44.1kHz (there are libraries for that) and write RAW or WAV. RAW audio could be piped to sox and played live. Once this is in place, you can batch process all sweeps! The same Pokey Explorer sweeps, but done without any other Atari emulation. Overnight, you end up with a ton of WAV files, and CSV files of all the sweeps and aubiopitch detection results. I don't see that happen with Altirra at the moment. atari800 might be easier, but its Pokey emulation is sub-par.

No, you are close to what I meant with a side channel depicting when to do predefined synchronize sequences. Possibly. Still not quite sure what emkay means by "micro programming" Yes. We can write a new player without the complex optimizations used there. A VST plugin is something that can be used by a DAW (Digital Audio Workstation). It can do MIDI, audio, or both. A Pokey VST plugin could, for example, input MIDI events from a sequencer (or a keyboard) and output Pokey audio data. Yeah, I said that, but I have postponed writing a new Pokey emulation, because I have found a different and easier way to do batch processing with Pokey Explorer I have no idea. IIRC pokey.dll is based on the atari800 emulators implementation.

I'm not advocating using this (i.e. stream frames from an IDE device, or a large cartridge like The!Cart), just pointing out it is a possibility that could work. But xxl is all about real hardware, and sizecoding, and so am I. Pokey Explorer works on a 16kb machine. 16kB for the win! Edit: just wait for xxl to release his code, and then listen to the complaints that it doesn't work on their CMOS CPU's because of "illegal" instructions

Yep, I agree with that Raster really did a good job, it's just a bit disappointing how limiting some things were implemented, because the POKEY chip can produce some really amazing sounds. Not lying here, when I did not understand the chip as much I can today, I thought many things were much more limited due to the way RMT was handling them. I assumed high pass filter muted the modulator channel, same with 16-bit, or that the notes available were the only ones possible (and I think I was able to prove there was way more possibilities using custom tuning tables!). So once I could actually know the secrets of the chip, I was pretty much facing a wall of hard coded limitations, that could be worked around manually using AUDCTL settings in instruments and manually playing the frequencies needed using commands 1 and 2, for example, or relying on Speed 1 patterns (Famitracker style!), Or custom tables, as shown by Analmux in RMT patch8, or even my own for tuning purposes, which was only intended as a personal use first but now I think there may be more stuff that could benefit from that, etc having a new tracker which handle do everything RMT could do, but better, with LZSS, means we could do nearly anything, and hopefully having more control over the sounds would make certain things much easier as well, despite being a lot more complex on the get go. note tables for example, are not an exaggeration for that alone, having support for more than 3 hardcoded tables would unlock a lot more power without relying on manually making instruments for 1 specific frequency, and would also avoid having to resort on using hacked versions as well. so if instruments could also change more things on the fly, such as distortion, or AUDCTL alone, plus having support for custom tables, would mean quite a lot of things could be done, and once the hard work is done once for a certain thing (eg, a table of notes for a special setting), that makes things much easier to do once they are available. POKEY Explorer has been incredibly useful for these experiments, so having a tracker that could let the user do nearly the same amount of stuff on the fly to make an instrument could make a huge step forward in creating really impossible sounding POKEY music, I believe

I created a sweeps directory in the Pokey Explorer repository: https://github.com/ivop/pokey-explorer/tree/master/sweeps/AUDCTL%3D%2464 NTSC I ran all the aubiopitch txt files through sed 's/ /, /g' (substitute space by comma space globally. sed is not that hard ) So now they are all CSV files that can easily be imported in a spreadsheet.

I have been thinking about this some more, as it might help with automating Pokey Explorer or any other program. Implementing the K: CIO handler that sends predefined keys won't be a problem for me. But(!) for example my Pokey Explorer checks CH (764/$2FC) to check if a key is pressed. A call to get a byte through CIO is blocking, so you can't do anything else in the mean time, like reading joystick values, pot values, CONSOL status, et cetera. I want to check for the START key, so my loop is: loop check CONSOL and act upon it if necessary check CH if a key has been pressed bne loop read key through CIO and act on it if necessary jmp loop TL;DR my idea of a "fake" K: handler can only work if Action! or any other program only uses CIO calls and not relies on CH changing on a keyboard IRQ.

One thing to keep in mind, as we all know, is that POKEY emulation on the 7800 is far from perfect. A7800 and ProSystem both have their strengths and weaknesses when it comes to certain settings. $Ax square wave settings, and standard 8-bit settings seem to work ok on both emulators, but anything else is a mixed bag. When doing music, I use the Atari 8-bit emulator Altirra to cross-develop. It has the best POKEY emulation of any emulator, bar none. There is also a tool called Pokey Explorer Tool which is very useful for seeing what certain sounds are like. http://virtualdub.org/altirra

For Pokey Explorer, the easiest way is to replace reading keys by running a predefined list of pokey and sweep settings, which I am doing at the moment (see github). But for programs of which you don't have the source, it would be nice to have a generic solution (AUTOKEYS.SYS ) Is there another way to check whether a call to CIO will block? Edit: and we want Altirra Pokey emulation during sweeps, not atari800

I don't consider that Atari either. It's nice during development, but ALL my code runs on real hardware without any enhancements. Sometimes you need 48kB or 64kB, but for example Pokey Explorer runs on an unmodified 600XL with 16kB. It was written last year. You are right in that it is more Atari than an emulator, but for me the charm to retro computing is doing things within the existing limitations. Adding high speed CPU's, even if they are the natural successor to the NMOS 6502, is stretching it IMHO. I don't see the point in running a Spectrum emulator on an Atari that basically sports SNES-like hardware (65c816 + VBXE). Running C64 BASIC and KERNAL on a stock XL (which has been done recently) I think is pretty cool. Or simulating SID on stock hardware. Etc... But each to its own. If @Faicuai wants to add a 1.6GHz ARM CPU that emulates a 6502 on 400MHZ, do not let me stop you