drac030

Too old SDX version. The U_PATH function was introduced as of 4.49f. The program requires a screen driver like S_VBXE.SYS (if there's VBXE) or RC_GR8.SYS (if not).

The driver loaded the PAL palette, because it was running on a PAL machine. To override that (or, strictly speaking, invert the result of autodetection), you have to pass the /P switch to its (the driver's) command line. This is, by the way, written in the documentation file (S_VBXE.MAN) and in the changelog (S_VBXE.NEW), both included in the distribution archive. Color cycling is normally done by loading GTIA color registers with changing values on the VBL interrupt. When the 80-column VBXE mode is on, the only active GTIA register (apart from PM/G) is the one controlling the border. The foreground color and the background color are controlled in a completely different way by the VBXE hardware and it would be of more effort than sense to emulate that behaviour: VBXE has color attributes, each character's color is independent from any other, so it would be rather involved. So no, it is not a bug, it is expected to behave so.

Perhaps, I just posted that when I saw that you were re-inventing the hard way some bits which are already written there (like the "bytes in the last sector" being in fact an offset).

RAMBO (no matter what size) does not offer separate ANTIC/CPU access to RAM banks, thus it would not work. Compy Shop will work (no matter what size).

Perhaps this helps http://atariki.krap.pl/index.php/Format_AtariDOS_4

You could try out an extension with separate ANTIC and CPU access (vanilla 130XE or a Compy Shop 320k or 576k). If you are on an U1MB, just switch the extension type and see if it helped.

It is in fact indifferent to core. The only change is that the driver now contains an NTSC palette which is used for overlay modes while on an NTSC system. On PAL computers the PAL palette will be loaded instead (as it always has been). This only affects the palette 1, which is used for the overlay modes being managed by the driver (like 80-col text mode and so on). Palettes 0, 2, 3 are unaffected. I am not familiar with the "proper" look of the NTSC colors (PAL land here), so an NTSC-lander must take a look and say if everything is okay (or not). The palette being used is the one advertised to me as the "agreed upon" NTSC palette.

I can, but what for?

Well, and here it is: a) the regular one: svbxe111.arc b) the Rapidus one: svbxe816.arc Roughly tested, but I have no idea if the colors are correct. I can only say that when the NTSC palette is enabled, the display looks different. The console screen gets purple instead of the usual blue, for example.

This is actually normal when someone, khm, uses the software. Noone knows what enormous number of bugs we found in SpartaDOS X 4.2x once we started to actually stress it. My favourite bug of all time was probably OPEN #1,0,0,"D:FOO.BAR" - this created a file and opened it for writes, as if the icax1 was 8, but that file could not be closed later. The reason (from memory): the OPEN routine tested if the read-access bit was cleared, then if so, it was assuming that the write-access bit was set (hence $00 was opening a file for writes). But CLOSE tested the write-access bit and, if this one was cleared, it assumed read-only file, and, whatever it was doing later, it was not sufficient to close the file properly (flush buffers, update directory etc). I just wonder what you need the warm reset for. It is pretty brutal way to terminate a program (we are not CP/M), it for example forces all possible PBI devices to get reinitialized, on HDDs it forces the partition tables to be re-read, in SDX it forces all device drivers to be reset, which for example, when XEP80 is connected, involves sending some crap via joystick port and so on. Is not just GR.0 and jmp ($0a) enough? Even if so, here is the exact reverse: I usually power-up my Atari once per day and power it down many hours later. I surely sometimes just reboot it, either by the CP command or SELECT/RESET or IDE+ menu.

Well, no, that's it. I just sat at it like a half an hour ago and traced it down to the exact same issue (not reading the forum beforehand, it would have saved me the 30 minutes). The routine in question initializes the VBXE registers as well as the shadow registers (VBXEFXS). This routine was first in the main RAM, but wanting to lower the memlo I moved it to the VBXE RAM not noticing that it disables itself in the process. During init time it worked, because the "leftovers" of the driver were still in the main RAM, and later, well, just lo and behold, how often I use the reset key, if this crash was unnoticed for so long... Thanks for finding this bug, in any case, it has nothing to do with your code. s_vbxe.sys rc_vbxe.sys

Maybe, instead of using fancy XIOs, it would be enough just to reopen the screen in the console mode, i.e. do an equivalent of GR.0? CLOSE #0:OPEN #0,12,0,"E:", or http://atariki.krap.pl/index.php/Otwarcie_ekranu_w_trybie_konsoli_(GRAPHICS_0) This should automatically reset all the internal settings of the driver, reestablish XDL and such.

I found it. It has some sort of "Press a key to proceed"... commented out. I probably found the message and the additional keypress irritating. It is not a thing one is doing every day, so maybe it is enough to write the relevant information into the FLASHOS.TXT file.

As about SDX users, I could also embed the NTSC palette into the VBXE drivers (it gets reloaded at every reset/GR.0 etc.), but the problem is that I do not have the palette definition (and for PAL, I do, it is the same as in the original FX core).

Well, yes, this tool is rather crude (look at the date: 14 November 2013, early prototype stage of Rapidus). I will probably have to find the source code, but apart from adding some message beforehand and "Press a key to proceed", nothing much more can be done, I guess.

Well, this step is reflashing the ROM containing the active OS. So after it is done, all the system information in RAM (vectors for interrupts, CIO etc.) are invalid, the only thing to do is to reboot.

Yes, this is the cause. The bulk of the S_VBXE driver sits in the VBXE RAM, in the last 16k. When you wipe it, the code naturally ceases to exist. The only "clean" way out then is to reboot. XIO's are listed in the documentation (XIO.TXT or so, in the distribution archive).

Since the post above begins with "In 2023", and presents a snapshot which says "SpartaDOS X 4.45 4-11-2011" ... ... just a friendly reminder that SpartaDOS X 4.47, released in 2015 (8 years ago) was a major revision and really really really *nothing* below that revision number is supported anymore. Especially, noone can expect that programs published on the SpartaDOS X Toolkit disk could work on anything below 4.47. If you still have relics like 4.46, 4.45 or worse, please upgrade immediately to 4.49.

Sorry, I overlooked your post. The answer is that real disks (and RAM-disks too) are split into fixed-size sectors, which must be buffered. If you want to read 1 byte from a disk file, it first involves reading a sector into a sector buffer, then your byte is fetched from there and copied into your destination. Even if the data are already in the buffer (so no disk access is necessary), it is still relatively expensive. CAR:, on the other hand, is not organized into sectors, so any amount of data may be directly copied into the destination memory without any intermediate buffers and associated copying operations.

> What does XEP80 display look like? Awful. But at least it is very slow.

The open function first opens and reads the directory, so the file name matching is performed in the RAM buffer.

I see. That is bad indeed.

According to this logic, you are shooting yourself in the foot (causing compatibility problems). Just as I said above. "Newer", i.e. 40 years old?

Not true, most ATRs just work via SIOV. CAR and BIN are of course different matter, because these require a form of ROM emulation. CAS - as long as it is a program which really cannot be copied to a disk and it genuinely tied to the cassette - is an amusing example proving my point

As long as there are no games which take up 400 MB, indeed, nobody passes HDD images. But the point is somewhere else: everybody passes around ATR images, and these can be run from a HDD as long as they use the standard I/O. Tying a program to SIO, worse, to a known set of floppy drives, is impairing its possible success. And anyways, if it is worth, it will be cracked to run from any storage, and if it is not - it will be forgotten. Just saying.