Jump to content

drac030

Members
  • Content Count

    2,399
  • Joined

  • Last visited

  • Days Won

    1

drac030 last won the day on July 26 2016

drac030 had the most liked content!

Community Reputation

1,443 Excellent

4 Followers

About drac030

  • Rank
    River Patroller
  • Birthday 07/28/1970

Contact / Social Media

Profile Information

  • Gender
    Male
  • Location
    Warszawa, Poland

Recent Profile Visitors

18,431 profile views
  1. "Press joy button" - where it is said that everyone owns a joystick?
  2. I think that you are looking back to the point where the ICD programmers were standing in 1987 - and they have decided that the CIO-centered design has too much limitations (this is even hinted in the manual); I guess the planned features probably could still have been implemented in CIO - as it was already tried in SpartaDOS 3 - but all this would have been too kludgy, so they have decided to make a cut. As a result, SDX is not built around CIO. It is rather an operating system on its own which also features a backward compatibility interface plugged into the CIO, so that old programs could still work. Atari BASIC etc. is the "old programs", this is why "D:" works traditionally in it. Here is a drawing which shows schematically the internal structure of the SDX (I hope that it will be readable): Note that the "D:" is just an outpost plugged into the Atari OS to maintain the backward compatibility, as I said
  3. Note that the design you are speaking about is exactly the SpartaDOS 3. I do not think they (ICD) would decide to make an "unnecessary" decision of redesigning the whole system, if the previous design had not come to a dead end. I guess that the primary reason was to make the I/O redirection flawless: thus the decision of adding another I/O layer ("the kernel") behind the CIO level. This in turn makes it necessary to add another set of device identifiers, and whether you, doing that, follow the MS-DOS example or anything else, is finally an arbitrary decision. By the way, the name of disk 3 is not D3 nor C - it is $03. It can be visualised in different ways, but that is not very substantial. Proper name of CON: is CON:, not E:. Or in other words, CON: is E: plus I/O redirection. The SDX shell does not have a clue about CIO, though, this is why it does not allow referring to the console as to E:, and this regardless on how disks are called. DJ: - when the number of drives (originally 9) was being expanded to 15, it was not possible to name disk 10 "A" because "A" was already taken, meaning D1: from the very beginning. And since D9 was already an equivalent to I, assigning J to the next drive was quite logical. /dev/null is named NUL: It is of course not impossible to write an alternative shell which would access devices via CIO. I think, though, that it is not quite worth the effort. Happy Easter, everyone.
  4. Yeah, the author of the program can explicitly restore. What if he does not do that? Then the settings will be wrong on user's console during the program's execution. That is the point.
  5. Let us say that I set my LMARGN to 3. I want programs to display stuff on the console with that margin. But someone in, say, Polynesia writes a program to list directories, then publishes it in binary form as LISTDIR.COM. He has no idea that he has to "restore" anything before listing a directory, besides, his favourite LMARGN is 0, so he is not even able to see any problem here. But on my system his program, when executed, will list directory at column 0, because that is what crt0 does behind backs of everyone. It does not help much that the program will (also behind the backs of everyone) restore the original settings before quitting: on my system it will still print the directory at the WRONG column of the screen.
  6. None I would know of. I just checked: copied an entire directory from FAT to SDFS, no problems. I must take a look at RWCRC, this program is suspiciously indulgent... [EDIT] What version of FATFS driver you are using?
  7. Not exactly, I meant the switch when compiling a program, so that one could define in a Makefile if the "portable" behaviour is desired or not. And the switch would of course be rather for the linker to pick the proper version of crt0.o when linking everything (if this is how this works in cc65, I have no idea, TBH). I do not like the idea of "restoring", because this way still my console settings (when running the program compiled in cc65, that is) depend on whether a programmer on the other end of the world is able to know that he should restore that, or remember how to do that correctly etc. It would be best to leave this setting as is, as it was already said it is external environment which a program should accept, and modify only when there is absolute must.
  8. Might it be possible to just add a compile switch -DCRT0_OLD or so and get away with it?
  9. And who said that the margin was 2 in the first place? Maybe it was set differently by an OS variant or by the user to own liking? The point, as I understand it, is to leave the setting untouched. If I want my left margin to be 1 and setup the system so, then I certainly do not want it to be 0 or 2.
  10. You have to visit the SpartaDOS X Upgrade Project website and download the Toolkit.
  11. Just a remark, these phenomena have hardly anything to do with RAM, the weird things happening during powerup and/or reset have their origin in conflicting ROMs. I was told that this conflict is sure to occur when the three wire cable is loose or not connected where it should at the other end. Mine works with a Rambo-type RAM extension (to 320k). But in fact there may be as many Rambo RAM extensions as there are many hardware guys constructing them, and people sometimes seem to have weird ideas on how do design such thing. So I already have seen a 130XE which, after it was expanded to 1 MB, stopped to cooperate with PBI HDD (IDE+). The reason being the phi2 signal being screwed/flaky by the RAM extension having been badly designed and without paying attention to possible ill effect on the PBI bus. So, IMHO it is best to start from a stock computer, then first eliminate all possible installation issues (like loose contacts etc.) Yup, besides, as I said, a "bad" 6502 is rather responsible for various effects depending on (its) temperature. I once had a stock 130XE which ran Acid800 fine or crashed while the program was testing 6502 illegal instructions, depending on the temperature, so Also a Mexico CPU, IIRC.
  12. I assume you must have switched the ROMs because the default OS for 65C816 mode (Rapidus OS) does not contain self-test at all. But in any case, this indicates problems which communication between the CPU and the Atari motherboard. I would check the following: 1) contact between the Rapidus and the motherboard: you need precision sockets, the normal sockets which are in 800XL are too loose for the connectors Rapidus has. 2) the exact type of 6502 plays a role: some seem to change characteristics with temperature, e.g. all works stable, when the computer is cold, or the reverse, it is unstable when cold, then stabilizes (I am not sure what 6502 is used for, but I guess that it supplies Phi2 signal or something crucial like that). On mine when I insert the CPU from the (otherwise seemingly working) 800XL I have here for experiments, it stops working. This CPU is the "Mexico" type, 1987 production year. 3) check the connectivity of the 3-wire cable going from the motherboard to the Rapidus. When this one is not connected properly or pulled off, all sorts of weird things will happen. In any case, on my website (in my sig) I have a PDF document which I update from time to time, about such issues and possible solutions (it is not complete yet, I am still working on this stuff). If that above does not help, contact the vendor.
  13. Maybe it would help, if you wrote, what kind of problems that was. QA has a limitation to 512 labels, 6 characters each.
  14. ICD also highly recommended giving up SpartaDOS 1.1 already in 1988. Memory allocation variables in SpartaDOS X are pointed to by symbol H_FENCE, mainly. It is true, though, that the memory management mechanisms have a bit evolved since 4.20 and 4.47 was subject to major changes in this respect (backward compatible, though). The whole idea of symbols is however such that when they are in use, data structures and procedures pointed to by them do not need to keep the same addresses from revision to revision (which greatly facilitates development).
  15. This topic seems to be a temporary center of xepism on this forum, so I will post here: while playing with XEP I found a bug in MAE 1.3 (the macroassembler by John Harris) which (the bug) makes using MAE with XEP very painful and practically impossible. I have attempted at patching it and the result of that attempt is available for download at my website (in the "Fixes" section), if anyone is interested.
×
×
  • Create New...