drac030

They are not. What files "I am using" under MS-DOS? Can this be an ATR file? What is a "group" in this context? If this asks me to select between "File type", "Template" and "Group", what is the difference? I will ask again: could you please be so kind and provide a real-life example of the use of this program? What YOU use this (or would use this) for under MS-DOS? Step by step.

The readme.txt file says: Check. Not possible, both "File type" and "Template name", when clicked, open empty lists, there is nothing to select from them. And neither option accepts keyboard input. What now?

So you basically seem to think that you are the first one to discover the cassette buffer, the LBUFF and the sixth page, and just wanted to inform us that they exist? Well, how to put it gently, we sorta already had some intuition that they are there. Second, I may be wrong, but you seem to believe that there is some other treasure of free RAM at $15A4, 348 bytes long. So let us lookup the source code of DOS 2.5: "$15A4 - the binary file loader". That is the code which loads and executes programs, incluiding your program. Overwriting it in the process probably would not help. Of course, you do not use DOS 2.5, the problem is, that we have many DOS-es on Atari, so going below $2000 with your binary file is basically guaranteed to stomp on some DOS in some setup. That is why people who want to use as much memory as possible and to avoid a conflict with a DOS employ relocators and other means to do not overwrite anything below the low memory pointer (aka MEMLO); and SDX, which has that pointer particularly low by default, even employs own binary format to be able to load programs at MEMLO and do relocation/fixing-up in place. The OS is perfectly able to load a binary block at $0400-$06FF or so. Your problem seems to be that you are not able to generate a valid binary file.

Ok, so suppose that I now have the TMPCR02 upacked and I am under MS-DOS. I ran SETUP.EXE and it said "Path/File access error creating directory. You may not be able to save new templates", but it nevertheless created a subdirectory named T. If I now want to "create a new file from an old file" using this software, what I am supposed to do? Starting TMPCREAT.EXE brings a menu called "Template creator selector" which does not seem to contain anything or make an obvious sense otherwise What now?

Uhm, VBDOS program, okay. So it is useless under plain MS-DOS? Next question, so it is useless without VBDOS and its "SaveAs" dialog, what the CBM version and the planned Atari version are supposed to do? Could you please provide a real-life example of a difficulty we encounter on Atari, that that program could solve and how? Step by step.

Maybe providing some switch or even a template to the linker could help it to detect errors in configuration, just as a sort of safety checks. Then you could say to the OP: "add --std-executable to the linker switches and see what it says". This would stop the whole process at the stage where the executable cannot be created, and not at the stage when it is executed and crashes the system. In assemblers you are on your own too, but it actually takes effort to convince an assembler to produce a messed-up binary, as the regular executable is usually the default.

I guessed that it may be adding itself to the "New" in Windows, but the question is why you did not write that in the documentation? "A utility that allows you to create a new file from an old file" means nothing, COPY also does "create new files from old files". The other question is, if it adds itself to the "New" in Windows, what does the MS-DOS version do? As far as I can tell, MS-DOS does not have any "New" menu in its shell. But maybe I am wrong.

How it is possible that cc65 compiler/linker/whatever can produce invalid binaries without even a warning?

Here you go: http://atariki.krap.pl/index.php/Dostęp_do_plików Polish, but an automated translator should get this sorted out.

There is no problem with that. The problem begins, when someone, on one hand, spends time boosting e.g. "original chipset", "original bit-by-bit OS", "no upgrades", "this upgrade makes Atari not Atari" etc. - and on the other hand the same individual(s) only use(s) a modern PC, which means no Atari chipset (but PC chipset), no Atari OS (but Windows) and no "Sally" (but Intel or alike). Dude, I could say to him, you are grumbling at people who upgraded to 65C816, whereas you have yourself "upgraded" to Intel!

Quite good.

Because this is a public thread on a public forum and I am taking advantage of the freedom of speech. Are there any possible inconveniences with that?

IMHO it would be pretty cool if it would not lead to developing things on PC "because retro computing is to stick to existing limitations" - but the existing (in fact, not "existing", but "original") limitations (aka "you cannot write a program on Atari conveniently") are unbearable, thus the switch to the PC. This is double-fold hypocrisy: a) insisting on (self-proclaimed) orthodoxy, which b) the individual is himself not able to observe. Hence the "truly retro computing" performed all on current-year PCs. Yeah, that is truly the retro computing in all its charm, indeed. IMHO it is not. Not more than adding 256 KB of memory to 65XE, when you have come to the conclusion that 64k is not enough. In 80s and 90s it was done without much thinking, the actual obstacle was the money only. Have the money? Go for it (that, besides, has done the Atari platform much more interesting than others, and more challenging in programming: you have to take into account that there is more than just one memory config, more than one OS, more than one BASIC - sometimes no BASIC - more than one disk drive etc.) Now aside of adding memory we can also add video extensions (VBXE, Sophia), audio extensions (Evie, PokeyMax), CPU accelerator boards. All this is done by the same logic as in the old days: because the computer can be made better and we want it to be better, faster, more capable. THIS is, IMHO, the true spirit of the days when the 8-bit machines were mainstream. Not the spirit of a museum. As someone once said, "for you, Atari is a vintage computer, for them [e.g. me], Atari is a current computer". That is the whole difference: no museum, but a living computer platform. I do. By the above logic, once you installed an extension, it would be pointless to not use it. Just as to get a 130XE to run 48/64k programs ONLY. With an accelerator new things are possible just as with any other extension (e.g. on 800XL you cannot replay as long a sample as on 130XE, and on a 130XE - as with an 1 MB extension - you do not see the point?). EDIT: BTW. VBXE is optional in that emulator This is what I consider cool and interesting for the developer, but otherwise pointless. Just as having a port of ZX BASIC to C64 (yes, there exists such a thing): nice toy, but you cannot even run all BASIC programs with it, because they often contain machine code subroutines. This is cool beyond discussion. But expanded hardware opens new possibilities here. This is what has always made Atari different from Spectrum/C64 - extensions. I have been an Atarian for more than 33 years now and what baffles me is this quite recent museal attitude which seems to be prevailing now. Quite contrary, I do not think that Atari 8-bit computing platform is SO COMPLETELY dead that the only thing which remains is a showcase and a display cabinet.

What really baffles me in this type of argumentation, is that it is often raised by people who only use x-GHz PC and an emulator, and still seem to consider that an Atari, eventhough there is no Atari custom chips there, no Atari hardware at all, just some kind of historical documentary real-time movie they can replay on their PC. But, on the other hand, an actual extension board for an actual Atari computer with actual 6500-line CPU on it is apparently "not Atari enough". Heh.

Just, as above, let me know, once you succeed In any case, I surely do prefer what exists to something what currently is vague wording only. "Virtualize"? I.e. run in virtual time? So, have CPU running at 400 MHz (1.773 x 225), and generate VBL 11000 times per second? And DLI accordingly faster? As I said, just have it built and coded, then we will see what we are talking about. For now, just try to lit candles and visiting churches. I recommend praying to St. Anthony at these occasions

Just let me know, when you will have this built and coded around. Most of this is already theoretically possible even now, with existing accelerators. The "only" problem is that we are not Microsoft with unlimited budget to employ enough skilled programmers full-time. Once you remove this little obstaculum, that vision will have chances to become reality. And by the way, re "faster rendition of older titles" - you probably have no idea, how much "older titles" rely on delay loops. For one example, phaeron's XEP80 driver - if it does not work at 20 MHz, you think it will at 400? Accelerating the CPU opens a can of worms most people do not expect to see creeping out. "Advanced networking" - will the TCP stack write itself? Exploring other platforms - will the support code write itself? Etc.

For me 10, 20 and 40 MHz are enough (these are the options I have now). Especially that with 16 MB flat memory you get additional gain by avoiding bank switching, you can setup code in the memory as it suits you, lookup tables, if necessary, can be 64 KB or a multiply of that etc. Long story short, once you learn to use the memory past the address $FFFF, there is no return. By the way, there is a problem finding RAMs which are fast enough to cope with 65C816 CPU running at 20 MHz. At 40 MHz even SRAMs can have a problem. And you are speaking of 400 MHz. Well, this could certainly be solved, but forget about deterministic timings and the principle that 1 clock cycle = 1 memory access; therefore also about cycling, delay loops and such old techniques.

The poll lists things which I either already have (CPU accelerator, 80-column solution, audio expansion) or can write myself (the software part) or do not need (pretty much the rest). This leaves me without options to vote for

What about building something smaller first, but actually working?

Just stick to $80-$FF and $0400-$06FF, if you really really need. Otherwise just use the regular and extended memory. By loading stuff into the OS locations you are only praying for problems. Experimenting may lead to obscure problems which will get difficult to debug in the future. Also, the golden rule: write a working program first, optimize later.

No wonder. Everything from $0349 onwards deemed "locations used by BASIC and OS but not needed by program". Including the IOCB #1 MyDOS binary loader uses, along with the MyDOS binary loader itself and the entire MyDOS.

This probably is the reason for the bizzarre behaviour you are observing: you are overwriting vital system areas then are wondering why the system does not work. Just post a binary file you are trying to run, it will probably get clear quickly, why it does not work.

132 is "BAD CIO COMMAND", your program is invoking the CIOV with an invalid I/O command code stored in the control block.

The source code presented in post #3 is an extract - in source form - from a larger program of mine, and the result of my debugging, why that program crashes badly while being loaded under SpartaDOS 3 and derivatives, whereas in the rest of the DOS-es listed it loads and runs fine. The listing pinpoints the exact code which causes the crash (in init1), and, because that code seems completely legit, the cause of the crash must be a problem inside SpartaDOS 3 binary loader, which goes bananas when an init segment is doing an OPEN call to the CIO. It may be actually very simple to fix, e.g. perhaps some internal channel number should get preserved across a call to jmp ($02e2). I know that people have teh SpartaDOS 3 source, and Real.DOS has its active developer, so this could get fixed. That is why I posted this, just as a bug report.

The "Image" in the first post is not visible (at least for me). So I am not sure what version of SDX is this. There was a problem with pathname end detection before, but it should be fixed as of 4.49e. Generally the problem is that path and file names should be EOL-terminated, but many programs neglect the termination, assuming that the DOS will be magically able to detect the end of a file name, no matter what binary garbage follows. Before 4.49e this magic sometimes led the DOS to believe that what follows is a path separator, and (consequently) that the file name given is a directory name. Thus error 150 "Path not found". As I said, the magic should get improved as of 4.49e. If it still fails, a test case would be most appreciated.