fujidude Posted March 28, 2015 Share Posted March 28, 2015 Don't do 5200 games in xe mode. Just configure it correctly. Should be easier than ever with the now-good .ini support. Of course this is good advice Keatah. Still, I think Jess has a valid idea there. There are some advantages of convenience in keeping them seperate. But yeah, it's not too much trouble to create your own seperation of them either. Quote Link to comment Share on other sites More sharing options...
Mclaneinc Posted March 28, 2015 Share Posted March 28, 2015 For me the only tiny annoyance of them being together is when you go back to XL mode from 5200 mode and you have to reset the ram to 64K or above by hand and it by default goes to the 5200's 16K setting... Quote Link to comment Share on other sites More sharing options...
Keatah Posted March 28, 2015 Share Posted March 28, 2015 What would some of those convenience advantages be? Personally I think that if they stay in one emulator things are better. Because any video improvements done to the computer side would automatically be available on the 5200 side for example. And seeing how the 5200 has the same video circuitry as the computers..?? We all know the 5200 is an 8-bit computer with less memory, no keyboard, and a different memory map. I would say the code would be easier to maintain if it stays together. And finally where do you stop branching? XL vs. XE vs. old 400/800 vs. XEGS? Quote Link to comment Share on other sites More sharing options...
fujidude Posted March 28, 2015 Share Posted March 28, 2015 (edited) For me the only tiny annoyance of them being together is when you go back to XL mode from 5200 mode and you have to reset the ram to 64K or above by hand and it by default goes to the 5200's 16K setting... Her's an idea... Initial setup: Make a new folder for a 5200 dedicated version of Altirra. Unzip the Altirra program into the folder. If you copy from elsewhere instead, be sure to delete any Altirra.ini that might be present here. Launch the Altirra program located within this new folder with the /portable switch. Configure Altirra appropriately and specifically for your 5200 usage. Create a shortcut to this new 5200 oriented location of Altirra. Be sure to name it appropriately so it's clear it is for 5200 emulation, and place it in the start menu, desktop, or where ever you like. Everyday use thereafter: Use the shortcut that points to your 5200 configured Altirra. Enjoy! A similar idea... Initial setup: Create a new and separate shortcut to the Altirra executable, making sure to use the /portablealt:5200.ini. Also be sure to name it so that it is understood to be for 5200 emulation. Obviously you would need to get that distinct version of the .ini built, named, and placed appropritely beforehand. I won't bother explaining how to do that as I'm sure you all probably know. Everyday use thereafter: Use the shortcut that points to your 5200 configured Altirra. Enjoy! Edited March 28, 2015 by fujidude 1 Quote Link to comment Share on other sites More sharing options...
fujidude Posted March 28, 2015 Share Posted March 28, 2015 (edited) What would some of those convenience advantages be? For one thing, for those who for whatever reason have an aversion to using .ini files, it eliminates the need to constantly change settings back and forth. Though I must admit I myself am not such a person, and it's somewhat hard for me to empathize with those who are. But anyway, another reason is it would lessen the amount of options one must consider in each particular case; thereby simplifying things somewhat. That's the user side of it. As to the developer side, I'm not sure which would ultimately be easiest. I lean towards a unified program being easier, but perhaps not actually. Personally I think that if they stay in one emulator things are better. Because any video improvements done to the computer side would automatically be available on the 5200 side for example. And seeing how the 5200 has the same video circuitry as the computers..?? I agree, but... keep in mind modular programming would more than likely allow the developer to quite easily incorporate such improvements to both programs simultaneously if the code were actually part of a common custom library. And finally where do you stop branching? XL vs. XE vs. old 400/800 vs. XEGS? I would draw the line right there at 5200 / computer line. It's not just that there are more hardware differences, my biggest reason is that software is not compatible between these two categories. Probably the vast majority of software written for the 8-bit computer line will run on any of the many computer models without modification. The same cannot be said for the 5200. The fact it needs its own version of the software makes it like any other foreign system, albeit a very similar foreign system. Edited March 28, 2015 by fujidude Quote Link to comment Share on other sites More sharing options...
Mclaneinc Posted March 29, 2015 Share Posted March 29, 2015 @Fujidude.. I'll just leave it as it is, I hate emulation clutter, in the scheme of things all I have to do is a single mouse click, to think I was too lazy to do that would make me feel rather sad Your idea is good but just not for me Cheers Paul.. Quote Link to comment Share on other sites More sharing options...
fujidude Posted March 29, 2015 Share Posted March 29, 2015 I just put it out there as a reminder to anyone who would rather keep a "separate" 5200 version of the emulator. For that matter, the same principles apply to other configs too: 400/800, XEGS, etc. I won't feel hurt if no one likes the idea, but I do appricate your compliments. Quote Link to comment Share on other sites More sharing options...
phaeron Posted March 31, 2015 Author Share Posted March 31, 2015 Up to three pages already...?! Regarding the configs... yeah, I know it's a problem. Gotta get some sort of profile system in place eventually. Update: http://www.virtualdub.org/beta/Altirra-2.70-test4.zip http://www.virtualdub.org/beta/Altirra-2.70-test4-src.zip Main fix is that I accidentally broke the built-in OS in the last build in a way that caused it to crash if you had BASIC on... derp. Also contains a bug fix for POKEY so that it no longer allows serial input if you have initialization mode on. I wouldn't have noticed this except that I accidentally tripped on this with a bug in a 1030 download test program and couldn't figure out for a while why it worked in emulation but not on real hardware. It doesn't currently emulate the strange audio you get when doing this, which appears to be related to the actual bitstream being received. ATBasic 1.39 includes a couple of compatibility fixes: Changed unary plus/minus encoding around constants. Previously, ATBasic would encode --1 as two unary minus operators and the constant 1, whereas now it encodes a single unary minus with the constant -1. This is necessary for compatibility with Atari BASIC, which only permits one unary operator but folds them into constants as shown. Found a way to address this that just required swapping around a couple of parser lines. It's also a little shorter, if you should decide to do something so odd. The FOR statement will now pop down the stack to a previous entry with the same variable. Previously it would just add a new FOR frame on the runtime stack, which would cause an overflow crash in situations where Atari BASIC would not. This will slow down the FOR...NEXT loop a little bit, but hopefully not too noticeably. Unfortunately, I don't have enough room to add proper checking on the runtime stack -- there's only 8 bytes free. atbasic.bin atbasicx.xex Quote Link to comment Share on other sites More sharing options...
mr-atari Posted March 31, 2015 Share Posted March 31, 2015 Is it possible to include the alternate MyIDE-][ CPLD-core? I know I have asked before, but it would be nice. -> D540-D57F is permanent re-mapped to D500 for IDE-access. -> Second request would be the hot-swap function. Thanks in advance! Quote Link to comment Share on other sites More sharing options...
Keatah Posted March 31, 2015 Share Posted March 31, 2015 (edited) Up to three pages already...?! There's a lot of discussion going on about managing configurations it would appear. Regarding the configs... yeah, I know it's a problem. Gotta get some sort of profile system in place eventually. If you do expand this area further, one important thing is the ability to import/export the settings - whatever format they may be. And at the same time be able to load them from the command-line or a desktop shortcut or within the emulator. All three options have to be there. The import/export function may not be apparently useful straight away. But trust me it is! This emu is small enough (a real pipsqueak) that you can have a directory for each machine. They can all share a common images folder. Or not. What I'm doing now is this: 0- With one copy of the executable in one folder.. 1- Made 1 simple default ini file. 2- Copied that ini file several times over. giving me 10 more files, all identical except for the name. 3- Made a list of virtual Ataris I want in my virtual collection. 4- Renamed each ini file to something machine descriptive like Atari 400/16K, Atari 800/48K/Disk, Atari 5200, and so on.. 5- Made a separate shortcut to each of those ini files and the emulator itself with the /portablealt:<filename> command. 6- Then I clicked on each and proceeded (like a kid in a candy store) to configure and "build" my virtual machines. 7- I then backed each ini file up for safekeeping. 8- Optionally you can lock the ini file to read-only. This sets your configuration in stone. Any settings you play with in the emulator are not updated upon exit. A good thing. To restore the ability to save again, just uncheck read-only. All I have to do now is click on the machine I want and away I go. If I break anything beyond fixing I just pull the backup. Or keep stuff set on read-only. All the system image files and software image files are the same for each configuration. In fact there are a lot of common settings. Each different machine may have only 2 or 3 options changed from one to the next. I'm happy with it. It works for me. I'm old-school - so I don't mind copying and editing and managing a buncha ini files. If a profile system is eventually worked in. I'd suggest a pulldown that can show slots with custom names. Perhaps 20. If you make this too big you have to scroll it or wrap it. This menu would then read the ini file, or database, or whatever have you.. And effect a cold start. It would display the active profile in the window's title bar. And away you go! If you make config changes you'd could then save-to-slot X. Also required is the ability to rename/create/delete a name for slot X. Maybe even write-protect a slot. A feature I like from VICE is to have the emulator either save, or not-save to the ini file when it exits. It's "Save Settings On Exit", Check or un-check it. However I can achieve the exact same functionality by making the ini file read-only.. I'm good with it! A little work with the File Explorer yields a boatload of practical versatility. These types of micro-work arounds are all over the place with classic computers and emulators Edited March 31, 2015 by Keatah Quote Link to comment Share on other sites More sharing options...
Mclaneinc Posted March 31, 2015 Share Posted March 31, 2015 Just noticed that if you start in full screen and load a CAS image it throws altirra out of full screen.. Quote Link to comment Share on other sites More sharing options...
Mclaneinc Posted March 31, 2015 Share Posted March 31, 2015 (edited) Hi Phaeron, Found a rom that semi loads but crashes, its termed a mega cart by a Spanish Pirate called Willysoft... I've searched the forums for a mention of it which there is but nothing about how it works, is it one of those odd ones that needs a button on the cart to run it? Something about bank switching seems to ring a bell but as usual I could be totally wrong. Thanks.. ATARI_8BIT - mega cartridge 9.zip Edited March 31, 2015 by Mclaneinc Quote Link to comment Share on other sites More sharing options...
serj Posted March 31, 2015 Share Posted March 31, 2015 Paul, this image cartridge works. select mapper "williams64". Quote Link to comment Share on other sites More sharing options...
Mclaneinc Posted March 31, 2015 Share Posted March 31, 2015 (edited) Are you sure...try running a game Strange, reset my settings and it works... Thanks Serj... Very odd... I must have a duff OS image in there .. Edited March 31, 2015 by Mclaneinc Quote Link to comment Share on other sites More sharing options...
gozar Posted April 1, 2015 Share Posted April 1, 2015 Phareon, does Altirra use relative or absolute paths in the .ini file? I keep my Altirra installation in Dropbox, so the path can change. I store all the support ROMS in the same folder as Altirra, and there is no path info in the .ini file, but when I start Altirra, it acts like it can't find the roms until I go into the settings and re-select them. Anything I can look for? (I'd rather not have to have multiple .ini files for each machine. :-) Quote Link to comment Share on other sites More sharing options...
phaeron Posted April 2, 2015 Author Share Posted April 2, 2015 They're stored as relative paths if within the program directory or a subdirectory below that, and absolute paths otherwise. 1 Quote Link to comment Share on other sites More sharing options...
fox Posted April 2, 2015 Share Posted April 2, 2015 Please try "New Art" from http://atarionline.pl/v01/index.php?ct=utils&sub=2.+Grafika Setup an ST mouse in port 2. Then in the editor RMB opens a menu in Atari800 Win PLus but not Altirra 2.70-test4. Quote Link to comment Share on other sites More sharing options...
fujidude Posted April 2, 2015 Share Posted April 2, 2015 They're stored as relative paths if within the program directory or a subdirectory below that, and absolute paths otherwise If they are outside the same branch as Altirra, can one simply use "..\..\ROMS" type of notation to make it work? Quote Link to comment Share on other sites More sharing options...
gozar Posted April 2, 2015 Share Posted April 2, 2015 They're stored as relative paths if within the program directory or a subdirectory below that, and absolute paths otherwise. Ok, that makes sense. I just need to move my Altirra installation to the root of my Atari8 directory, which will fix it. Thanks! Quote Link to comment Share on other sites More sharing options...
phaeron Posted April 3, 2015 Author Share Posted April 3, 2015 Please try "New Art" from http://atarionline.pl/v01/index.php?ct=utils&sub=2.+Grafika Setup an ST mouse in port 2. Then in the editor RMB opens a menu in Atari800 Win PLus but not Altirra 2.70-test4. Oops... fixed: http://www.virtualdub.org/beta/Altirra-2.70-test5.zip http://www.virtualdub.org/beta/Altirra-2.70-test5-src.zip Although... I couldn't figure out how to get the program to paint anything but black. Managed to bring up the context menu and select colors, and the program showed C:03 at the bottom, but still only black. Also, this build fixes some issues in 65C816 mode, the most serious one being that Step Over in the debugger was really, really broken. If they are outside the same branch as Altirra, can one simply use "..\..\ROMS" type of notation to make it work? Unfortunately, no. The path is always converted to a full path first in the UI, and you can't just change the path in the registry as the subkey is the hash of the path. 2 Quote Link to comment Share on other sites More sharing options...
Mclaneinc Posted April 3, 2015 Share Posted April 3, 2015 Just seen why it kicks out of full screen when a cas image is loaded, the little processing window steals the focus... Quote Link to comment Share on other sites More sharing options...
fujidude Posted April 3, 2015 Share Posted April 3, 2015 Unfortunately, no. The path is always converted to a full path first in the UI, and you can't just change the path in the registry as the subkey is the hash of the path. Slight bummer but not a huge deal. If you have other emulators, or even other separate installtion folders of Altirra for some reason, it's nice to have files that are common to all of them located somewhere common to all of them. That's my situation. Also, I run all my emulators from a flash drive in portable mode. What about using "..\.." type specs in the .ini file? I suppose I could try it and see. Quote Link to comment Share on other sites More sharing options...
1NG Posted April 4, 2015 Share Posted April 4, 2015 I love Altirra. It is a really awesome tool! I have two wishes for it: If the emulator runs already and I am coding in it, then I would like to look into another atr. But a double click just flushes my source, because the actual Altirra gets lost without any message box. I know the option to keep the actual instance and start a new one. Any attached atr seems to be cached. If I generate a new one Altirra still sees the old one. The generation of atrs with my tools has become a very common thing for me. Is there an interface available to send Altirra commands by an own program? 1 Quote Link to comment Share on other sites More sharing options...
Mclaneinc Posted April 4, 2015 Share Posted April 4, 2015 If you mean a command line interface then yes there is one, to see what commands you can send then open a command prompt where Altirra is and type Altirra /? Quote Link to comment Share on other sites More sharing options...
lemiel Posted April 7, 2015 Share Posted April 7, 2015 - there's only 8 bytes free. Discused somewhere: You can remove not described in manual ER. and PRO. - but will it be still compatible with Basic XL/XE? 6 more bytes - PROTECT and UNPROTECT change to LOCK and UNLOCK - but only tokened version will be compatible. 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.