drac030
-
Posts
2,770 -
Joined
-
Last visited
-
Days Won
1
Content Type
Profiles
Forums
Blogs
Gallery
Events
Store
Posts posted by drac030
-
-
There is some progress:
-
2
-
1
-
-
29 minutes ago, Alfred said:
That's not entirely true, it did make a bit of an attempt to see if where it was was closer than starting over:
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-
1
-
-
33 minutes ago, flashjazzcat said:
even a FAT 128K in size (the largest possible) can be traversed in some 2-3 seconds
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.
50 minutes ago, Peri Noid said:Which seems to never happen
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.
32 minutes ago, flashjazzcat said:I offered to help complete the driver in any way I could last year, but never receieved a response to the offer.
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.
-
4
-
1
-
-
1 hour ago, Peri Noid said:
The only reason to know it is to display this info when DIR is issued. But anyway - pointless.
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.
-
2
-
-
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.
-
1
-
-
5 hours ago, videofx said:
The issue is this: Once I load the FATFS.SYS driver and do a DIR, it takes 35 seconds before I get the directory listing.
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:
-
1
-
-
4 hours ago, reifsnyderb said:
Sorry, I've got the symptoms on page 16 of this thread from Tuesday at 10:46PM to Wednesday at 10:56PM.
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).
-
3
-
-
I guess it may be this:
The solution is in post 7.
-
9 hours ago, reifsnyderb said:
Without knowing what SpartaDOS-X is doing when the system crashes, I am not sure as to where to go from here.
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.
-
2
-
-
6 hours ago, phaeron said:
a difference between the 'o' command and F10
Not sure if this helps, but here there is (functionally) none.
-
On 2/22/2023 at 6:17 AM, phaeron said:
Debugger: (dp), (dp,X), and (dp),Y addressing modes now also suppress symbol lookup for non-zero D register, and there is now an option in the Disassembly window to control this behavior.
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.
-
3
-
-
6 hours ago, phaeron said:
The history frame is currently full and doesn't have room for another 16-bit data field.
I see. Well, so we will have to live with it as it is, I guess.
6 hours ago, phaeron said:Just tried it here and was able to step over MVN 0,0 even with interrupts. What are you seeing in your case, is it executing only one round or is it doing more before stopping?
It behaves as if I was pressing 't', i.e. stops after every iteration:
QuoteAltirra> o
(1222: 46, 51) A=31F3 X=4C3E Y=865F S=01E3 P=01 ( C) 3F:136F: 8B PHB
B=3F D=01E4
Altirra> o
(1222: 46, 51) A=31F3 X=4C3E Y=865F S=01E2 P=01 ( C) 3F:1370: 44 22 1E MVP $1E,$22
B=3F D=01E4
Altirra> o
(1222: 46, 51) A=31F2 X=4C3D Y=865E S=01E2 P=01 ( C) 3F:1370: 44 22 1E MVP $1E,$22
B=22 D=01E4
Altirra> o
(1222: 46, 52) A=31F1 X=4C3C Y=865D S=01E2 P=01 ( C) 3F:1370: 44 22 1E MVP $1E,$22
B=22 D=01E4
Altirra> o
(1222: 46, 53) A=31F0 X=4C3B Y=865C S=01E2 P=01 ( C) 3F:1370: 44 22 1E MVP $1E,$22
B=22 D=01E4
Altirra> o
(1222: 46, 53) A=31EF X=4C3A Y=865B S=01E2 P=01 ( C) 3F:1370: 44 22 1E MVP $1E,$22
B=22 D=01E4
Altirra> o
(1222: 46, 54) A=31EE X=4C39 Y=865A S=01E2 P=01 ( C) 3F:1370: 44 22 1E MVP $1E,$22
B=22 D=01E4
Altirra> o
(1222: 46, 54) A=31ED X=4C38 Y=8659 S=01E2 P=01 ( C) 3F:1370: 44 22 1E MVP $1E,$22
B=22 D=01E4
Altirra> o
(1222: 46, 55) A=31EC X=4C37 Y=8658 S=01E2 P=01 ( C) 3F:1370: 44 22 1E MVP $1E,$22
B=22 D=01E4
Altirra> o
(1222: 46, 56) A=31EB X=4C36 Y=8657 S=01E2 P=01 ( C) 3F:1370: 44 22 1E MVP $1E,$22
B=22 D=01E4Interrupts are on.
6 hours ago, phaeron said:I could potentially have the disassembly monitor the current D state and refresh the disassembly whenever it changes between zero and non-zero.
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.
-
On 2/19/2023 at 7:43 AM, phaeron said:
PEI (dp) no longer shows deref value.
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.
On 2/19/2023 at 1:46 AM, phaeron said:This unfortunately is more difficult as the CPU history stream doesn't contain the read values, it only contains the effective address. The deferenced values shown are generated by the disassembler, which is why history doesn't show it.
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.
On 2/5/2023 at 10:38 PM, flashjazzcat said:RWCRC - can't be 'spoofed' with SD ID bytes, since when it senses them, it calls the kernel (for formatted numeric output?), and quite understandably crashes
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.
-
1
-
-
On 1/16/2023 at 8:33 PM, flashjazzcat said:
The only way I can get RWTEST to not present that prompt under my FATFMS DOS, for example, is to spoof the SpartaDOS ID and version bytes at $70x, although this can have unwelcome side-effects if the program then thinks it can call the SDX kernel, etc.
Fixed, I think.
-
2
-
1
-
-
On 1/15/2023 at 5:40 PM, Paul Hocker said:
Apologies if this was discussed before but I am hoping that someone knows if there is an option to remove the "--- Press SPACE when done ---" from happening everytime I do something with SC? I looked in the SC.INI file, but nothing stood out to me to control this. Perhaps it is not documented?
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.
On 1/16/2023 at 8:33 PM, flashjazzcat said:The only way I can get RWTEST to not present that prompt under my FATFMS DOS, for example, is to spoof the SpartaDOS ID and version bytes at $70x, although this can have unwelcome side-effects if the program then thinks it can call the SDX kernel, etc.
Oups. Indeed. I will have to fix that.
-
3
-
-
32 minutes ago, mysterymath said:
I'm pleased to announce the first official release (v0.1.0) of the LLVM-MOS compiler toolchain for the 6502
What about the support for the more advanced versions, i.e. 65C02 and 65C816?
-
On 2/24/2022 at 7:22 PM, Larry said:
Would the Rev E issue as you explain it also apply when using with MyDos?
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.
-
18 minutes ago, Larry said:
For instance, on my Rev E, it would not keep settings unless powered separately after the Atari was shut down.
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.
On 2/23/2022 at 1:33 AM, Peter Rabitt said:FAT 16 formatted on my PC an I added files to it but went back to the IDE and the FAT16 drive has unknown file system??? Using sdx 4.49
SDX does not support FAT16 natively, you have to load an external FAT16 driver (FATFS.SYS) to access a FAT16 partition.
-
1
-
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
SpartaDOS X "Super" Sector Maps
in Atari 8-Bit Computers
Posted · Edited by 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.