fujidude

It's long gone my friend.

Unfortunately I no longer use actual hardware. I had water damage at my home and that ended my run with the real iron. And now, even if I had the space (which I don't because it's been reallocated, you might say like sectors in a file system LOL) pricing and availability are not the greatest either. But I digress... to answer your question directly; I know of no actual hardware case where high/linear RAM has a battery backup option. So I guess I see your point if you are interested strictly in emulating real/legit/actual hardware that may be out there. I must say though that such a hardware solution would be just as worthwhile as it is for extended memory, for the same reasons and likewise for emulation of such solutions as well. For me, Altirra substitutes for actual hardware, so the idea of enhancements or new features excites me just as it would on real hardware, and even if it is exclusive to a software Atari. In short, I think it would be useful regardless if such a feature is actually available for real hardware or not. I think it would be cool!

As always, great work on the emulator and it's much appreciated. Any chance for a "preserve high memory on cold reset" option. I typically emulate a 65C816 and set up a RAMDISK with the high memory.

Thanks to user E474 for bringing an issue to my attention. He got an error when trying to use the nix script. After looking into it, Ironically the issue was that the script had DOS/Windows style line endings instead of Unix style ones. I must have been working in Windows when I put that out before, and forgot to change to nix style EOLs. I'm attaching an updated version where I made sure the script and all plain text files have Unix style EOLs. aac_v1.1_nix_script_edition.tar

Yep there is that and it's great. But also within a "single" Altirra configuration you can have endless setups and easily choose between them from within Altirra itself too.

I'm running Altirra 3.0 under WINE with excellent results.

Take your Atari outside for about 15 minutes. Bring it back in and plug it in and turn it on. If it's shorted out, then it's probably raining outside.

I've discovered a possible bug in XLESS from the toolkit, SDX 4.49c. I noticed a lot of text based files I was trying to view with it would go bonkers. That is to say not display correctly, and even get caught in some kind of endless loop. I'll attach an .ATR with a couple of examples. Note, that the LESS program has no trouble properly displaying the same files. xlessbug.atr

Not to mention the fact that actual parsed commands are allowed to have leading spaces, and in fact the manual and disk based code examples are rife with such examples. Since the parser has no problems doing that, it would seem that it could function very well to just look for anything valid (pre spacing or not), and then just ignore the rest once a ; is found. I guess that's how I was thinking it was intended to work but maybe not. I'm not complaining here. I'm put it forward because I thought DLT probably didn't intend for that behavior. If they did/do, then no harm either. I can easily work around by keeping semi-colons in the 1st column and just indenting the rest of the comments.

Perhaps.. I would have to test it. But even so I would consider that somewhat in the insect realm because code indenting is generally supported otherwise.

Doh. I should have read further before replying as you covered it.

F9 is used as a breakpoint toggle... when you are in the debugger. When in the main display it is pause. Check out TOOLS --> KEYBOARD SHORTCUTS There you can not only quickly see (and search) what is currently set, but also customize it as well.

Huston, I think we may have a bug. See the example code below. echo off ; Bug test of SDX 4.49c ; File for loop fails to ignore comment ; lines and attempts to execute them. for %f in -s *.* ; comment 1 ; comment 2 echo $%f$ next %f ; Now without comments for %f in -s *.* echo $%f$ next %f

I got to thinking about that... when paused with F9, Altirra displays a PAUSED notice over itself. If that cramps your screen shot style, I have another idea. Use the OS's take management to stop the program and then start it again when done.

F9 pauses.

Of course they can be modified and I'm happy to hear that they are. I encourage it. That's what I had in mind back when I posted the RUNPACK.BAT and mentioned the "walkdir" (along with a task of course) procedure could be adapted to do any number of useful things. Long live SpartaDOS!

Okay. So I put together a couple of scripts (.BAT files) that I wanted for my own use but which others might find useful too. The 1st one lets you specify a path where a tree of various files are and then copy them to a few key folders that would/should be put in your system path. See the table in the actual code for an example. echo off ; TKUPDATE.BAT ; Toolkit Update by FujiDude 2018-02-19 ; This script requires the use of ENV.SYS driver and the ; PHD & PLD utilities. PHD and PLD must be in the syetm path. proc info echo .This updater recursively goes through the source and echo .copies all files of certain types to the target path echo .as indicated in the following table: echo . echo . FOLDER : EXTENSIONS echo . --------:------------------------- echo . BIN : .COM .EXE .XEX .OVL .INI echo . SCRIPTS : .BAT echo . DRIVERS : .SYS echo . MAN : .MAN .TXT .DOC echo . echo .Also, ENV.SYS must be loaded and the toolkit PHD, PLD, echo .and CDD utilities need to be in the system path. echo . echo . USAGE: -%0 SOURCE_PATH TARGET_PATH echo . Both source & target path are required. echo . EXAMPLE .SYS files will go in TARGET_PATH>DRIVERS echo . return proc task echo . echo .Processing directory $%d$ ... if exists -s *. copy *.com %2>bin> fi if exists -s *.exe copy *.exe %2>bin> fi if exists -s *.xex copy *.xex %2>bin> fi if exists -s *.ovl copy *.ovl %2>bin> fi if exists -s *.ini copy *.ini %2>bin> fi if exists -s *.bat copy *.bat %2>scripts> fi if exists -s *.sys copy *.sys %2>drivers> fi if exists -s *.man copy *.man %2>man> fi if exists -s *.txt copy *.txt %2>man> fi if exists -s *.doc copy *.doc %2>man> fi for %f in -s *.arc /N ; ARC allowes combining these but CL might get too long? ; Expermient later to combine more to improve performance. arc e $%f$ %2>bin>*.com arc e $%f$ %2>bin>*.exe arc e $%f$ %2>bin>*.xex arc e $%f$ %2>bin>*.ovl arc e $%f$ %2>bin>*.ini arc e $%f$ %2>scripts>*.bat arc e $%f$ %2>drivers>*.sys arc e $%f$ %2>man>*.man arc e $%f$ %2>man>*.txt arc e $%f$ %2>man>*.doc next %f return proc walkdir gosub task for %d in +s *.* cd $%d$ gosub walkdir cd < next %d return ; Main program load command.com seterrno 0 set %d=%1 echo .SDX Toolkit Updater by FujiDude ver. 2018-02-25. echo . ; Is a source specified? if not _11 gosub info echo *** ERROR: missing source path exit fi ; Is a target specified? if not _21 gosub info echo *** ERROR: missing target path exit fi if not exists +s %2>bin mkdir %2>bin fi if not exists +s %2>scripts mkdir %2>scripts fi if not exists +s %2>drivers mkdir %2>drivers fi if not exists +s %2>man mkdir %2>man fi phd cdd %1 echo .Updating %2 from %1 ... gosub walkdir echo . echo .Updating complete. Don't forget to ensure the following echo .are in your PATH if they aren't already: echo . %2>bin echo . %2>scripts echo . %2>drivers echo . echo .and likewise for MANPATH: echo . %2>man echo . pld load And the 2nd one just does a recursive directory sort: echo off proc task echo . echo .Processing directory $%d$ ... sortdir . return proc walkdir gosub task for %d in +s *.* cd $%d$ gosub walkdir cd < next %d return ; Main program load command.com seterrno 0 echo .SDX Recursive SORTDIR by FujiDude ver. 2018-02-25. echo . set %d=%1 phd cdd %1 gosub walkdir pld load

If there was the ability for the emulated Atari to "see" say one of the Epson NLQ dot matrix printers, and the output could be printed on whatever printer is hooked up the the host that would be pretty awesome. I think the Epsons were some of the most widely supported among Atari 8 programs (indeed, for many of the 8-bit systems of the era)?

Nahh, it's what every true computer fan should strive for!

So... it's not critical it be exact, but don't get too carried away. Is that about the size of it?

Actually... here's what I verified through research & testing: A command line is limited to 64 characters (which I should have already known before I started). Comment lines in batch files are not limited to 64 characters. The issue I posted about was indeed a CL input of greater than 64 characters, but it was an actual operable command sequence which exceeded the limit; not a comment line. I somehow was under the fog that what I had written was within the acceptable limits even though there was at least one (non comment) CL which had exceeded it. Thank you guys for your feedback so far. It's always appreciated!

Thanks I'll take a look, but I didn't think comments were subject to the command line limit given that they are ignored.

Yeah, that 600XL got hooked up to a stylish black and white TV which was like 10". Didn't even have a cassette drive for it. Luckily my joysticks from my heavy sixer worked and I did get a Star Raiders cart.

For me when I was a kid, it didn't matter how unassailable a fact or position; my parents won all arguments because there was no such thing as arguing with them. The end.

Actually it was the CoCo 3 I'm thinking of, not the 2. Sorry.