drac030

Probably a provisional code, which stayed, because they saw (I am guessing) that it worked well. And it did - as long as the caches were big enough. I remember that when I first saw that - listing a long ARC archive - I thought that the ARC implementation was doing something wrong. Just when I wrote TAR, which used the seeking and on longer archives behaved the same way, I understood that the DOS itself was to blame.

There is some progress:

The text you have pasted does not seem to come from the SpartaDOS X source code: $(================================================== Set Absolute position within file --------------------------------- in: addpos = file position $) and a bit below: lda chain ; set to initial sector map sta smsec lda chain+1 sta smsec+1

I agree that the FAT scan in FATFS should not take this long, it is definitely and suspiciously too slow (about 5 KB/s). I will take a look at that today, thanks for reminding me. Many other things happen and the time passes by. While posting today about the SDX seek function, I was surprised to see that it was fixed nearly 17 years ago, I would swear that it was about 10 years ago maximum. Yes, sorry, I was preoccupied with many other things. Anyway, FATFS is a plugin to SPARTA.SYS (just as ATARIDOS.SYS, it is not an independent driver) and developing it needs thorough knowledge of SPARTA.SYS internals. I am slowly describing all that for the Programming Manual, but for now I am inside the kernel drivers, and about the SPARTA.SYS file system driver interface there is not a word yet.

The other reason is to get users become used to it, as this behaviour in inherent to FAT16. So that there would be no bad surprise when/if the driver becomes read/write.

The problem with the original SEEK function (or POINT, if you prefer) in SDX was that it was badly implemented: whatever new position you wanted to set within the file, the DOS always started from the beginning of the file. I.e. if your current position was 16777210 and you wanted to set it forward to 16777215 for example (or few bytes back, no matter), the DOS at the outset was setting the position 0, and then went all the way through all the sector maps to the position you wanted. This worked smoothly as long as all the sector maps needed fit in the cache. But if they did not, the DOS at every seek had to re-read the entire sector map chain leading to the new position. In a longer file it was a disaster, and the problem was visible already while listing the contents of a 500k ARC archive (it may be visible earlier, if the cache is declared smaller). I guess anyone still can check how 4.2 behaves in this case. The correct solution to that was not supermaps, but that what has been applied 27 September 2006: seeking not from the beginning of the file, but calculating the new position relative to the current one.

Format the FAT disk so that it has a smaller number of larger clusters.

There is a minor glitch in the disassembler: It seems limited to that one instruction (I did not check PER, though).

There seems to be a problem with the console display regarding PEI - the extra leading digit:

I have some code that works on real Atari, but crashes on Altirra. The crash is due to stack corruption, and the reason for the stack corruption is here: The code is first executed in the native mode, with 16-bit X/Y registers. Then it switches to the emulation mode for a moment, then again to the native one. The problem is that the X bit in the CPU register apparently survives all this without being forced back to 1 while the CPU is in the emulation mode: XCE at $0010dd evidently sets both bits to %11, but PLP at $fe6131 right away restores %10, as pushed by the emulation mode PHP at $0010db. The datasheet, chapter 2.8, says: "The M and X flags are always equal to one in Emulation mode", and it is so on the hardware CPUs, so I think that this is a bug. While investigating that I also discovered another problem: namely PLB and PLD should both set NZ flags according to the data pulled (as per the datasheet), and this indeed happens on real hardware, but on Altirra it does not:

I looked there again and I am afraid that you are a little bit too concerned with possible assumptions software is making while testing/accessing extended banks. There is no place for particular assumptions, a program has a procedure to count the banks, it then uses (or tries to) the banks it found and it is basically all. The usual procedure consist of a loop which tries out all the possible combinations of the relevant bits of PORTB. SpartaDOS X is no exception. The procedure goes less or more thus: 1) bits 2,3,4 in PORTB are set to 0. 2) the remaining 4 bits (7,6,5,1) count from $0 to $F 3) each iteration checks if there is a new bank banked in 4) if so, it marks it as "seen", increases the bank counter and goes back to p. 2. 5) if not, it just goes to p. 2 6) after the 16th iteration the procedure quits. As you can see, there is no special case for 192k, or anything else. It just increases the counter, writes PORTB and looks if anything changed. And it might be worth checking, how many banks this procedure can see in your case. Just use the config above, start SDX in 64k mode, then do MEM /X at the DOS prompt (which will tell you the number of banks the system saw) and PEEK COMTAB+1C (for 192k the mask should be $5C, I think).

I guess it may be this: The solution is in post 7.

One thing I can tell you for sure: it certainly does nothing special. It just uses the detected extension banks. To answer your question: ff SDX crashes right after showing the CP prompt, this most probably means that it crashed while attempting to read AUTOEXEC.BAT. This involves a call to the cartridge, and from there, to the kernel. The kernel switches the extension banks, then calls the FMS which is residing there (in USE BANKED mode, that is). The functions called are open file/read data/close file. In meantime much bank switching occurs, as FMS calls are going to and fro. From your config file I can see that you are loading some things to the extended RAM (ENV, CON64, DOSKEY), but succeeding on loading itself does not prove much. Out of all that, ENV and DOSKEY use their banks very little (at least initially), and CON64 must be enabled to take the control, otherwise it just sits there idly. And it is possible that by mere chance you loaded these to the good banks. Or bits occasionally flipping have escaped your notice. Quite contrary, SPARTA.SYS, when it is loaded to the extended bank, uses it very extensively: it is a large portion of actual 6502 *code*, the FMS, which is used virtually all the time. So any, even tiny memory corruption will result in a crash. By the way, how do you know that "ramdisk works"? Maybe please use this CONFIG.SYS: use osram device sparta osram device sio device side3 device ramdisk O,16 then fill up the ramdisk with files, then copy them back to another place, then compare with the originals. There are no miracles, if SPARTA.SYS crashes, the RAM must somehow screw the data written to.

Not sure if this helps, but here there is (functionally) none.

This seems to work, thanks. What about the MVN/MVP issue? Not reproducible? Not fixable? Later?

If SDX did not sense any extension, it would not hang, it would just default to plain 64k configuration. So it seems that it does detect something, but the extension does not work correctly. I of course have no idea why it does not work, but there are two things to mention, perhaps: 1) SDX scans the extended RAM not bank by bank, but in portions 64k (= 4 banks) each. The bits 2-3 of PORTB are held %00 during the scan, the remaining 4 bits get flipped. The premise is that if there is a RAM extension at all, it would consist of an integer multiple of 4 banks. 2) SDX tries to select the last banks first to load itself, leaving the 130XE-compatible banks free as long as it is possible (e.g. on a 320k RAMBO extension, SPARTA.SYS will be loaded to bank PORTB=$8F). So, if other programs work, but SDX does not, this may mean that out of the entire extension the last 64k is not functional. The mask (PBMASK) you found in the manual is of informational purpose only, its content gets setup automatically during bootup (along with other such parameters, line the number of banks etc.) EDIT: you can of course force the SDX to ignore the extension and use the 64k configuration. To do that, format a diskette (or ATR or whatever medium you use for D1) in SpartaDOS format, save a custom CONFIG.SYS file to its main directory, then bootup from there. Once you get to the DOS prompt, MEM /X will tell you how many banks the system can see. Also you can do PEEK COMTAB+$1C to see what is the extension mask. To make a custom CONFIG.SYS, it is best to copy the default one from CAR: (TYPE CAR:CONFIG.SYS >>D1:CONFIG.SYS) then edit the latter by adding USE OSRAM line at the beginning (or if there is USE BANKED there, replace BANKED with OSRAM in it). Then save and reboot.

I see. Well, so we will have to live with it as it is, I guess. It behaves as if I was pressing 't', i.e. stops after every iteration: Interrupts are on. The point is that, as I wrote, it sometimes does (or did in the previous Altirra revision I had here) that automatically. In meantime, I discovered that when I refresh the disassembly window, it shows the symbols for D=0 and numeric offsets for D!=0. Before manual refresh: After manual refresh: (It is exact same code still stopped in the same place, just the window was drawn again). So it seems that the only thing missing is the automatic redraw of the disassembly window once D changes.

Thanks. Now it displays this: The word pushed onto the stack is displayed, but what I am missing here is the effective address. Could it display something along "PEI ($85) [$00:0085] = $0003" instead? It is the dp addressing mode, so the effective address, being dependent on the value of the D register, is not very obvious. I am not sure if I can quite follow here. You are saying that the history stream is one instruction ahead of the user, so the console window fetches the values from there before the user executed an instruction? If so, how does it work for PEI then? For other things, there seems to be a problem with the debugger's command "o" (Step over). I asked once if it is possible that it could "step over" the MVN/MVP instructions, and you implemented it. But it does not seem to always work (or maybe in the test4 is stopped working at all, it just tried and it did not). Could you take a look at that? It is rather long to step through longer moves (yes, I can set a breakpoint after and let it go). Also, would you like to implement a new command in the debugger, something like "go until change of flow", i.e. until a jump (jsr, jmp, jsl, jml), return from subroutine (rts, rtl) or branch taken? EDIT: I also no not quite get the logic according to which the debugger disassembly window displays labels for zero-page locations. Like for LDA $08 it displays LDA WARMST, but when D != 0, the effective address is no longer $00:0008 or WARMST, so the debugger should not display the label but rather the numeric value of the argument instead. And it sometimes seems to do so, but sometimes it does not. Could you take a look at that? Thanks in advance.

4.20-test2, the debugger: 1) when resolving the PEI instruction, the console considers the indicated zero-page location as a pointer and dereferences it: But PEI does not work so, in this case the value being pushed to the stack is $0002, and not $00FF, showing the latter lacks sense. It is only the display thing, the instruction itself works correctly. 2) in the same circumstances, but with the RMW instructions, could the console show the value which the instruction, when executed, will load from the memory? Like here: I.e. if $00:$01F8 is $FFFF before INC, could it display "INC $14 [$00:01F8] = $FFFF"? Same for DEC, ASL, LSR, TRB, TSB and such, of course. Thanks in advance.

It depends on the OSS CLI interface having been detected or not. If it crashes, this cannot be the cause, because I cannot see the program making any SDX-specific calls under any circumstances. Besides, you can always "spoof" SpartaDOS 3. rwcrc.co_

Fixed, I think. rwtest.co_

There is no such option. SC displays the prompt you are talking about when, while reloading the SC after a program's termination, the cursor is not in the HOME position (i.e. when the cursor's X position is different than LMARGN, or the cursor's Y position is not 0). This means that the program has displayed something and SC makes it possible for the user to read (as already pointed out). Otherwise - when the cursor is in the HOME position - the SC goes on to display its panels immediately without holding the screen. The VIEW function uses LESS.COM by default. This one - and also XLESS, which can be used instead - block the screen when the file to be displayed does not entirely fit on the screen (i.e. has more than 22 lines, IIRC). Otherwise - when the text is short and does fit on the screen - both viewers do not hold the screen and return immediately to the shell. The SC has no way to know, if the screen was being held by the viewer while displaying the file, thus, when the viewer exits, the SC behaves as described above, i.e. holds the screen when the cursor is not in the HOME position etc. Oups. Indeed. I will have to fix that.

What about the support for the more advanced versions, i.e. 65C02 and 65C816?

Yes - but probably only when you go to the IDE+ configuration screen, then press RESET or power the computer down while there. So, nothing really related to MyDOS.

This may be unrelated to the power supply. Rev. E has the old V3021 RTC, which will lose the settings, if the computer gets powered down (or reset) in the middle of reading the time by the system. And programs which are constantly reading the time from the RTC are: 1) TD Line (notoriously beloved by lots of people), and 2) Sparta Commander with CLOCK=ON in SC.INI. To avoid messing the settings, one should do TD OFF and/or exit Sparta Commander before powering the computer down or pressing RESET. It is rev. F which fixes this by using a completely different RTC, not sensitive to this issue. IDE+BIOS supports both RTCs transparently. SDX does not support FAT16 natively, you have to load an external FAT16 driver (FATFS.SYS) to access a FAT16 partition.