drac030
-
Posts
2,695 -
Joined
-
Last visited
-
Days Won
1
Content Type
Profiles
Forums
Blogs
Gallery
Events
Store
Community Map
Posts posted by drac030
-
-
13 hours ago, DrVenkman said:
This may be user-error, however, or a misunderstanding on my part. I have my VBXE installed in a PAL machine but I would *like* to be able to have the NTSC colors that I am used to.
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.
3 hours ago, mmoec said:when the machine goes into the screen saver mode, only the border colors change, the foreground and background colors remain the same
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.
-
1
-
-
16 hours ago, pcrow said:
Yup, that has most of the information, but was missing a few bits that I've now filled in above.
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).
-
3 hours ago, Pab said:
CompyShop 576K works but RAMBO 320K doesn't.
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).
-
2
-
-
-
18 hours ago, Pab said:
Also not really something that's easily fixable
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.
-
1
-
-
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.
-
1
-
-
14 minutes ago, DrVenkman said:
Can't you simply set the text and background colors from the SDX command line or via a batch file?
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.
-
1
-
2
-
-
On 8/30/2023 at 7:31 AM, woj said:
That's what I (unfortunately) do, you are welcome! It's the third on my list (this, one in Altirra (wait.. technically two), and one in the Sophia plugin, though the last one Jon found first, I just didn't know) during this game development.
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).
On 8/30/2023 at 7:31 AM, woj said:RESET does just fine
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?
On 8/30/2023 at 7:31 AM, woj said:I would speculate that this is because 90% of your users still have the bad habit of torturing the computer with the on-off switch ("I will just power-cycle it to make sure it really has no garbage left in there") instead of RESET.
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.
-
1
-
-
On 8/28/2023 at 3:49 PM, woj said:
Great! But the problem is it is an extremely blunt fix and surely it has some side effect, and perhaps also the whole thing needs a totally different (re-)initialization approach.
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.
-
3
-
3
-
-
1 hour ago, woj said:
This still does not allow S_VBXE.SYS to "wake up" after exit to DOS, but I do get a working SDX prompt.
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.
-
23 minutes ago, patjomki said:
Hope you find the source code.
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.
-
4
-
-
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).
-
2
-
-
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.
-
2
-
-
1 hour ago, patjomki said:
After step two the computer resets automatically without giving any information that flashing was succesful. I found this very irritating but it works that way.
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.
-
1
-
-
12 hours ago, woj said:
essentially wipe out the whole of VBXE memory, so it might not even be technically possible without full reinitialization/reloading of S_VBXE, don't know...
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.
-
2
-
-
On 6/25/2023 at 6:35 AM, Faicuai said:
How come they run THAT fast while somehow being copied to RAM first? That is quite a feat, there.
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.
-
2
-
-
> What does XEP80 display look like?
Awful. But at least it is very slow.
-
3
-
-
32 minutes ago, flashjazzcat said:
does the open function perform filename matching in-situ (ROM), or first copy the directory data to a buffer and then perform the filename match?
The open function first opens and reads the directory, so the file name matching is performed in the RAM buffer.
-
1
-
1
-
-
33 minutes ago, flashjazzcat said:
Currently the server is geared towards DOS 2.x compatibles, and I can't intuit much from a string comprising the filename and a sector count.
I see. That is bad indeed.
-
1 hour ago, Zolaerla said:
If a future emulator or device doesn't support what so many other people have done already for their games, they are shooting themselves in the foot causing compatibility problems.
According to this logic, you are shooting yourself in the foot (causing compatibility problems). Just as I said above.
1 hour ago, Zolaerla said:However, considering the Atari 8-bit does not have much of a future (for the last 35 years, TBH), I don't think it matters if I support some newer way of running software than what just about everything else does already.
"Newer", i.e. 40 years old?
-
12 minutes ago, _The Doctor__ said:
sadly very little does that, this is why so many devices in order to be successful must emulate and provide paths for ATR, CAR, BIN, CAS
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
-
1
-
-
7 minutes ago, Zolaerla said:
in the world of Atari gaming, nobody passes around actual HDD images.
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.
-
1
-
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
SDX Question
in Atari 8-Bit Computers
Posted
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).