itaych

Here's a couple more ideas: Selective mute for each of the four audio channels (or 8 in stereo). Selective hide for the 4 players and 4 missiles. This would just prevent their rendering (display), collision detection etc. should remain unaffected. The idea behind this is that making some players not appear allows insight into how many games and demos achieve their displays. Muting some audio channels is interesting for those who want to silence a game's background music, or isolate a single instrument in a multichannel song, etc. Thanks

I thought I explained myself well enough in my original post. I grew up with the 800 and always disliked how the later models omitted the console speaker and mixed it into the general audio output. The 800's keyclick was quiet and pleasant and came from where it was supposed to - inside the keyboard. With the later models, coming from the TV speaker it sounded out of place, disproportionately loud and harsh to my ears. If you give the option to redirect the console audio to a separate device, the user could set things up such that the console clicks would come from a laptop's built in speaker while the rest of the audio would be played through external speakers, more closely emulating the feel of the original. (I know this is technically possible, for example the old Google Talk application is able to play ringtones through the laptop speaker even when headphones are plugged in.) So yeah, it's an odd request, but I'd consider this on par with the oddness of, say, the extreme artifacting simulation (which also simulates TV ghosting and blurring) - it is also arguably a pretty odd feature but you put it in there anyway If you think the GUI for such a feature would be cumbersome to implement and use, I'd be happy enough if this were a command line only option. See Squeezelite as an example of a CLI program that allows you to list available audio output devices and lets you specify the desired device by name. Thanks!

@phaeron, odd little request here. Would it be possible to add an option to redirect the Atari's console speaker output (generated by GTIA's CONSOL register) to a different output device than the regular POKEY sound? Remember that the Atari 800 (and 400 too I believe) had an physical internal speaker for console sounds, and this could be emulated by e.g. setting CONSOL to the laptop's internal speaker while POKEY outputs to external speakers. Thanks

Also, a question about the R: device STATUS call. After performing it I expect to find the number of pending characters in a 16-bit counter at $2eb-$2ec. Can you please put the real value there instead of just 0 for empty or 1 for nonempty? If you're concerned about software that may only read the low byte, it's fine if you cap the value at 255. Thank you!

Hey Avery, I get a crash when trying to remove any breakpoint in the debugger. Run Altirra, F8, Disassembly, F9, F9, boom.

When I set Altirra to D3D11 as you do, the behavior is reproduced - no lock screen problem, but stuttering animation. Do you see the lock screen problem if only D3D9 is selected? Do all problems go away if only OpenGL is selected?

Well, the desktop has an Nvidia Geforce 8400 GS card and the laptop has an Intel HD Graphics 3000. I still believe I've seen this problem on other machines on which I've installed Altirra in the past (at work, etc). In any case, in experimenting with the display settings, I've found that checking OpenGL and unchecking everything else, eliminates both problems I've mentioned, on both machines, while leaving the filtering functionality intact. Now, there is nothing in common between the two machines (desktop/laptop, 32/64 bit, older/newer, my install/factory OS, different OS flavors) except that the OS is Windows 7 on both. In fact I think all the machines I've encountered this problem on were Windows 7. My desktop machine happens to have a dual boot install; I booted in Windows XP and the problem does not occur. If your development machine is not Windows 7, can you find a Win7 machine and try to reproduce this? Thanks again

Hi Phaeron, I think this may have been mentioned in an earlier thread. In Windows 7 I get strange behavior if the user locks, then unlocks the computer. What happens is that Altirra's output appears frozen even though the emulator is working. Switching to full screen unfreezes it which is somewhat OK as a workaround, but (a) it looks weird - something is different in the scaling algorithm - and (b) on subsequent switches to full screen I get a black screen with the image in its windowed size, on the upper left corner. Second question: I get fluid, stutter-free 60 fps animations in full screen but never in windowed mode. (Try the game Getaway for a quick example of smooth scrolling.) Is there a reason for this? These were both checked on a 32-bit desktop and 64-bit laptop, both with decent specs (nothing ancient) with CPU nowhere near saturation. Latest version of Altirra with settings reset to default. Thank you! -itay

Hi, what year is this? I guess it's time to address these requests. Here is the long awaited alpha 7 PORTB bit 0 is no longer modified by Ice-T, fixing compatibility with systems that enable OS RAM, such as MyBIOS. Macros. To use macros, note the new menu entry Options > Macros. It will display 12 empty 'slots', each of which can be set to a letter or number of your choice and then filled with a macro of up to 64 characters of text. The text entry field accepts only plain text, but special characters may be encoded within the macro as follows: To insert a control code, the percent symbol '%' can be used. The character immediately after '%' will be sent stripped of its upper 3 bits, so %X or %x will send Ctrl-X (ASCII code 24) and %[ will send Esc (ASCII code 27). To send the percent sign use '%%'. To insert an arbitrary byte use '$' followed by 2 case-insensitive hex digits. To send the dollar sign use '$$'. To activate a macro in Terminal mode, hold down START and type the corresponding key. Note that in previous versions the START button caused plain key codes to be prepended with Esc (so pressing START-C would transmit Esc c), mimicking the Meta key that was present on keyboards of some old terminals. This feature remains available for any key that is not assigned to a macro. Enjoy! And as always let me know if there are any problems. icet_280_alpha7.xex

Thanks, I guess I'll keep all three in the distribution while recommending the 850Express version (in the docs, which no one reads anyway ).

Not even with a different name? I made up the "HND" names, it would have been difficult to have 5 or more files named RS232.SYS on the same disk...

Well, there are now three different files (of different sizes) that do the task you describe, but with different results: ATARI850.HND, PRCONN.HND (these are files from the disks that came with the 850 and PRC respectively) and now this RS232.SYS file of unknown origin from the 850Express disk, which seems to exclusively solve freetz's problem. The questions are what is the functional difference between these files, what is special about this new RS232.SYS file, and do I really need to distribute all 3 with Ice-T or would this RS232.SYS be sufficient for all use cases, superseding the other two?

I have no problem adding it to the next release, but before doing that I'd really like to know what's so special about this tiny (123 byte) file that helps in your specific case. It's too small to actually contain a handler - it probably downloads the handler from the device, just like the ATARI850.HND or PRCONN.HND. Does anyone have a clue?

Have you tried other terminal programs? In particular does FlickerTerm work for you?

Yes but you said that when you turned off the translation in the BASIC program you saw untranslated ASCII, which is exactly the expected result and what Ice-T is designed to handle. I don't know why you're not getting anything at all or garbage in Ice-T.

Another thing Frederik hasn't mentioned is that on that other thread I gave him a BASIC program that accesses the serial port in pretty much the same way Ice-T does, and that worked well for him - so I don't really know what to say.

Actually I have a better idea for you. I'm attaching SPLAT.BAS. This was the very first proof of concept I did in 1992 or so before starting Ice-T - a dead simple Atari BASIC program that opened the serial port in 300 baud and let you communicate with whatever's on the serial port (modem in my case). What you can do with it is play freely with the XIO commands, twiddle the settings and figure out what's wrong with your setup. Open the PRC manual (it's on Atarimania if you don't have it), read about the XIOs to understand the port opening sequence, and try to figure out what's wrong. I believe I enabled ATASCII/ASCII translation here so I wouldn't need to code the translation in BASIC, so try disabling that and see what happens (you'll have to press ctrl-J or ctrl-M instead of Return to send an end of line, but it should still *work*). In Ice-T this is of course disabled. Also if you change the baud rate to 9600 you will lose data but you should at least see parts of valid text. Let me know what you discover. SPLAT.BAS

Scroll up. There are people discussing problems using the PRC with a PAL machine, perhaps that's your problem too? Other than that please try other terminal software (Flickerterm for example) - do they work? Please try the latest 2.8.0 alpha and take this to the 2.76 thread. I wish it was possible to lock old threads...

What you call a "minor" release is actually the result of many months of work responding to user feedback, fixing bugs, refactoring code, adding features and updating documentation. So yes, I think it is fair to announce what I consider a milestone in a new thread each time - I doubt anyone would notice it otherwise, I don't think four threads in two years is unreasonable, and I can't edit a post once it's been replied to anyway. Now, when I release a version with new features that are not done yet, I name them 'alpha' or 'beta' (depending on how well the new features are baked, in my opinion) and post them in the thread belonging to the latest version. So, prerelease versions of 2.76 appeared in the 2.75 thread and prerelease versions of 2.8 (which has not been released and is in a bit of a freeze at the moment) appear in this thread. Sorry if this system confuses you but no one has complained so far and I think it's a pretty straightforward system, and I'm not the only one using it (see the Altirra 2.40 thread, containing dozens of 2.50 alpha versions as another example). In general for the latest 'stable' fully documented release simply grab the file from the first message of the thread with the highest version number (2.76 as of today). Then browse through the thread for the latest alpha/beta if you want to try the latest features. 2.8 alpha 6 is indeed the latest.

There are about 75 instances where these values occur in the code for setting PORTB. And then there are places where these values may be used for some other random reason. There is virtually no way for you to tell the difference without disassembling everything and you will probably miss something and break some feature. So, thanks for not posting it Of course not. Ice-T was developed under MyDOS. SDX support was added only recently, when emulators allowed me to test against it and users requested it. Ice-T doesn't do anything with the RAM under the OS, because (a) the ROM OS is still needed for handling I/O and interrupts so this would have made things more complicated than I like, (b) it would have broken all sorts of system upgrades that use this RAM. I'm surprised however that this specific problem has remained unreported for the 20 years that Ice-T has been available! I'll add it to the todo list.

Larry, your link leads to the same place I linked to. Problem solved, thanks

Ok, I think this is what you meant, thanks. http://atariage.com/forums/topic/172003-cart-copy-for-the-xlxe/?p=2131126

Hi, I'd like to run Atari BASIC on a 48K 800 machine, however the original BASIC cartridge is lost so I'm looking for a way to convert the 8K ROM file to an executable. It should be as easy as adding a binary load header to the raw data (to make it load from $a000-$c000) - would that be enough? Should the run address be set to $a000 or somewhere else? Is there any initialization code I'd need to add? Would BASIC Rev. C work on an 800 or must I use Rev. A? Does anyone have such an executable ready, so as to save me the effort of doing it myself? Thanks

The emulated 850 won't respond to SDX's RS232 just as it won't respond to the standard version, therefore I have no way of reproducing this. So, I guess use whatever workaround works for you

ProWizard, I've tried a disk-based R: handler for the P:R:Connection (which is mostly 850 compatible). Under Altirra and SDX it loaded fine, and Ice-T runs and communicates with the virtual modem, except for some harmless garbage data received when opening the serial port. Please try it yourself. Get the file PRC.ZIP from this post by russg, and try the included handler instead of RS232.COM. You're right, disabling Fast Boot did the trick. My guess was wrong though, this had no effect on SDX. The disk based handler seems an acceptable workaround though.