Jump to content

drac030

Members
  • Content Count

    2,574
  • Joined

  • Last visited

  • Days Won

    1

Everything posted by drac030

  1. I see, so nevermind. Anyway, the binary he posted is messed as it can be seen above, but the first problem is that it overwrites the very code that is loading the program (in DOS 2.0s and 2.5 - under any other DOS it overwrites God knows what) . And the OP seems fixated at the idea that what is there "shouldn't be needed by a cc65 program", and is unable to connect the fact that he is overwriting a part of the OS with the fact that his program crashes in the middle of loading. What a mess.
  2. Not that I figured out, how to use that program under MS-DOS (I am still lost here), but, relying on the fact that this is supposed to be something similar to what the "New" option makes in Windows, I guess what it is supposed to do. Namely, it probably "creates new files" (i.e. stubs, or empty files, of the type desired by the user) in current directory, "from old files", i.e. templates stored in some central template database. It is like when I want to create a new ODT document in Windows, I right-click on the desktop background or a desktop window, then, from the menu that appears, I select "New", then "OpenOffice Writer document". Then in the place where I had clicked an empty ODT file is created. In DOS it could be done similarly, e.g. with a command like NEW or CREATE or whatever. E.g. the user types NEW FOOBAR.BAS, then the program invoked copies an empty BASIC program (stub) from its database to the current directory, and names it as the user wanted (FOOBAR.BAS in this case). Then the user can open the file in a BASIC editor and start editing. The new file created does not necessarily need to be empty, e.g. a C stub could already contain #include <stdio.h>, int main() { return 0; } or whatever of this type. So the idea might be not bad in itself.
  3. But I do: IT OVERWRITES DOS. The addresses listed there for the area $0700-$1FFF are only valid for DOS 2.0s, which means that they are not "contractual", as they say. But even for DOS 2.0s, as it was already said to you, Mapping the Atari gets the address $15A4 wrong: it is not a procedure of "loading MEM.SAV if it exists". It is the binary loader.
  4. Examples? To create what files? What results? To what programs and why? What do you mean by "module"? As in the "C language source module"? Why do I need the TmpCreat to reuse it? How? No and it never will until you provide at least one real-life example on how it can be used, also demonstrating why it is superior to the systems without that solution.
  5. 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.
  6. 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?
  7. 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.
  8. 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?
  9. 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.
  10. 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.
  11. 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.
  12. How it is possible that cc65 compiler/linker/whatever can produce invalid binaries without even a warning?
  13. Here you go: http://atariki.krap.pl/index.php/Dostęp_do_plików Polish, but an automated translator should get this sorted out.
  14. 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!
  15. 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?
  16. 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.
  17. 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.
  18. 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
  19. 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.
  20. 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.
  21. 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
  22. What about building something smaller first, but actually working?
  23. 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.
  24. 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.
×
×
  • Create New...