drac030

Address $41. And I remembered incorrectly, it is set to $00 to shut off the SIO comfort noise. Normally $03.

Perhaps the silencing could be skipped, when the I/O sounds are off (via iosnden set to nonzero, IIRC).

Under emulator, when it stops and displays the message that it only can work in NTSC, hit F8, then type this into the console: r p.z 0 g It will run then Also, it cannot be booted as an ATR from a HDD: There is also a minor typo in this message, it says "SOIAux2" which probably should be "SIOAux2".

Yes, this worked, thank you.

Just tried it: I) run Altirra II) wait for startup III) F8 IV) Debug->Window->Memory->Memory 1 *click* V) Shift+Windows+Cursor left VI) nothing happens VII) Shift+Windows+Cursor right VIII) nothing happens

If I had left a debugger window, say the "Memory 1" window, on a second monitor while last time closing the emulator, how do I call that window back to the main desktop screen, if that second monitor has been disconnected and is currently unavailable?

@dmsc Thank you very much. I must say that this update of TBXL is IMHO truly one of the best things that happened to the Atari utility software in past 38 years.

They seem to be still produced, maybe worth taking a shot at WDC https://www.westerndesigncenter.com/wdc/w65c22-chip.php

16 KB gone all the time. It is one bank of ext RAM, where there is about 380 bytes of code and the rest is the environment buffer.

Thus you are stuck with the old version forever 😜

It is generally a good idea to load ENV.SYS by default at startup, as the use of the environment variables may be sometimes pretty intensive (and thus extensive). The environment space is only 256 bytes by default, ENV.SYS enlarges that to about 15 kilobytes. More complex batch files, pseudo-pipes etc. may not work without.

I was wondering what ws going on here. Although I do not use BASIC much - mostly as a scripting language for tasks where SDX batch interpreter is not capable enough - this version of TBXL has been since two years the only one I am using. And few days ago I noticed that it shares with the original TBXL 1.5 an unfixed bug in the DEC() function. Namely, when the string given to DEC() contains lower-case letters, the conversion fails. E.g.: ? DEC("FF") gives "255", but ? DEC("ff") gives 0. @dmsc are you there? Could we hope for a fix?

Well, in theory, games/demos/whatever using the stereo should be first detecting the second Pokey. But, you know.

D is "D:", i.e. the default disk FMS device. And an entry in HATABS is only "free" when empty ($00). Thus installing anything there should begin with finding an empty slot, then taking it, if one is found. Here we apparently have a case of XDOS not taking into account that there can be any devices besides what the ROM OS installs, and installing itself blindly into a slot, which in certain configurations may be already taken (like by "H:" in emulation, additional devices in custom OS-es or in - already mentioned - PBI handlers).

From what I can see, the EXDDT under SpartaDOS X must be relocated out of the RAM banking area, i.e. definitely out of the $4000-$7FFF. If possible, I would recommend trying to relocate it to the block $8000-$9FFF, although it might not fit. Alternatively, reconfigure the DOS to USE OSRAM and do not load DOSKEY. Also, as a side note, I do not know how the disk images of EXDDT I have here are representative for what is available to everyone, but... SpartaDOS X has problems reading the directory, but it is definitely not SDX's fault: these disks are a mess.

Here is the said documentation: SDX_Progr_Guide_450_EN_1_00-preliminary.pdf The kernel drivers are described in chapter 23. This is a preliminary version of the document, so if anyone spots anything to fix, or any additional stuff that needs explaining, please let me know.

I do not quite get it: if external hardware can map-in own ROMs at $d800-$dfff, when a non-zero value is written to $d1ff, why it cannot map own math-pack when a zero is written to $d1ff? Of course, it has to be done in a clever way to avoid OS checksum failure during reset. So, maybe: 1) unmap external ROMs on Reset, 2) on the first non-zero write to $d1ff activate the math-pack mapping on $d1ff=$00. Am I missing something? Of course, a software reset would still be a problem, but you are patching the OS anyways, so you probably already have incorporated zeroing $d1ff into the procedure that zeroes all other I/O.

The purpose of that variable is sufficiently explained in the documentation, it was also discussed above. It is also obvious that it was designed, and not arose by accident, for programs usually do not grow on trees. Thus I take it that the question @yetanothertroll asked was a tad more intelligent, sc. if it is intentionally uninitialized so that it could serve as an I/O channel number shared between different programs being loaded and run consecutively (note therefore the Atari BASIC example is completely irrelevant, as it is up to an application program, what it does with its internal variables and mechanisms). My answer is as above.

It could work like that provided that all programs on Earth, including the operating system and DOS, are written in Action. Otherwise it is just a bug: the $b7 location is user section of the zero page, programs can use it to their liking, and the first one which does not know its special meaning in Action would ruin the entire concept. So no, I do not believe that anyone could even consider doing the I/O redirection in this manner.

In UltraSpeed you use standard commands, e.g. R ($52) for read etc. But you may want to check - using e.g. Altirra as a debugger - if your SIO code receiving data is fast enough to cope with 52 kbs. Especially the Ack bytes may arrive too fast. At 19200 you have about 920 clock cycles of interval between bytes, at 52600 it is about 1/3 of that (340 or so).

The reason is probably to prevent Atari 850 from responding to that command (where $3F=POLL). Daux1=$00 and daux1=$01 select how the 850 responds to POLL, so I guess (I did not check it myself) when daux1 is anything but $00 or $01, 850 does not respond at all. I also saw daux1=$03 used with '?' with the same justification.

The kernel driver is the correct solution. "N:" in the CP is disk drive number 14, and it is so not because CP does such a fancy translation, but because it is the proper device code for SDX kernel (device 0, i.e. DSK, unit 14). As I said somewhere else, I am slowly writing the instructions on how to write a kernel device driver for SDX, and I hope to have a preliminary version of this document soon. However, judging from the response to the previously published preliminary PDF on writing the SIO drivers (which are really simple in comparison), this would not help much. I myself do not have FujiNet. As far as I know, @trub has (or was about to have the last time we were talking about it), and he was planning to write the device driver, but what happened to these plans, I do not know. Anyway, if someone wants to know, how SDX kernel device drivers work, I recommend taking a look at the source code of SIO2BSD: http://drac030.krap.pl/en-inne-pliki.php specifically the "PC Link" section. It is basically one big function acting on the PC side as a server for the Atari acting as a client via the PCL: device driver. (Note that, contrary to a myth perpetuated e.g. by Altirra, which lists PCLink under serial devices, PCL: is de facto not a serial device per se: SIO is currently only used as a transport layer, because there is nothing else to communicate with the PC side than a SIO2PC). Here: http://atariki.krap.pl/index.php/DOS2DOS#Tabela_funkcji there is a description of the PCL: device driver functions, which are the same as the functions of the SDX kernel device driver. It is written in Polish, but the Google translator should do. The function numbers listed are reserved for the functions listed (especially 0-7 require a valid handle, others do not), but generally speaking the range of function numbers is from 0 to 255, where functions 0, 1, 7, 8 and 9 are reserved for character devices (such as NUL:, CON:, PRN: etc.), 0-31 are reserved for file system devices (DSK:, CAR:, PCL: etc.), 250-255 for internal use, 100-111 are reserved for the CLK: clock special device, and the rest is open for definition for other special devices. A kernel device driver, depending on what a device it is implementing, must define a range of these functions to be able to respond to kernel calls. In any case I can assist with the SDX side of things.

Speaking of the interesting features of Action, or Action-compiled programs, I quite recently got a bug report, that a program worked fine from SDX CP, but did not when launched from Sparta Commander. It turned out that it is an Action-compiled program, apparently linked with a library, which expects that the address $B7 would be zeroed before its execution. In other words, it features an uninitialized variable there. By chance, it apparently is the IOCB number for the console's text output, or something like that. So if this byte is not zero, a program like that cannot display anything in the screen via CIO. If it is fixed already by Action folks, please disregard.

The issue still was worth adding the supermap-kludge. Not only that, but it seems to work, too.

Scanning FAT via a general routine "get me the FAT entry for this cluster number". It still must be done this way for FAT12, but fortunately, a 12-bit FAT may never be bigger than 6k and rarely exceeds 1k, so this should not be a problem. Attached. Although please remember that it was rather superficially tested. And FAT12 was not. FAT16 seems to work, though. fatfs.sys