drac030

There are also background applications, like TD Line, which run on interrupts. So e.g. under SDX this loads into the ext RAM (normal PORTB expansion, RAMBO or Compy). So, the "system" which knows about the expanded addressing saves PORTB, switches to a bank outside PORTB range, but then VBL kicks in. PORTB byte gets saved, banks get switched withing PORTB range, TD Line runs, then restores PORTB and returns from the interrupt. And everything crashes, because the interrupt is unable to restore the original extension state. You say that the state of the banks can be saved/restored, but how? Am I missing something?

1) Any practical example of the code that uses this banking scheme? 2) Again, any practical example on how do you save the current bank configuration to restore it later?

4.30-test6, the generic disk emulation seems to work as XF-551, i.e. under SDX it automatically syncs as one (at 38400) or can be set manually: Is this intended?

Bad GTIA, type 2: http://atariki.krap.pl/index.php/GTIA#Wadliwe_GTIA

Actually, on VBXE 1 it is rather easy to take the RGB output out, just write a $00 to any byte at $D6C0-$D6FF, and voila. On VBXE2 these addresses may be somewhere else, but it is still possible. The original designers have not protected these ports in any way, even if this issue raised its head pretty early and they were told about it. So, how much money was that?

SpartaDOS X allocates the ext banks starting at the other end, i.e. the most remote bank first, and 130XE banks last. So, as long as there are at least 4 banks free, you can be sure that 130XE banks are among them. This of course assuming that the BlackBox is really using the four 130XE banks only and not whatever it finds there. Yuo can use the MEMINFO utility to see which banks are allocated and which are free. Banks 4,5,6,7 are the 130XE banks.

And 4.49e is dated 1 Feb. 2021 - over three years ago. And no report. Oh well. Anyway, the diagnosis: The MIO firmware ROM does something it IMHO should not, namely, while executing its code it has hooked onto the SIO the usual PBI way, it writes to the CRITIC variable ($42). I did not trace whether it does it always or only sometimes, but it does. Especially, it can clear it out. This is most probably just a bug, because CRITIC belongs to the overlaying OS and PBI drivers should not touch it, leaving its management to the said OS. Anyways, the SDX did not expect that a call to the PBI may return with CRITIC=0. The code used a pair of INC/DEC to set and unset the CRITIC, so when MIO cleared the variable, the subsequent DEC set it to $FF. This blocks the second phase of the VBL, including the keyboard auto-repetition. The cure: Please get the SDX Imager from the SDX website (the most recent version), or use the web-based version, to replace the relevant files in 4.49g with the revisions attached below. When replaced, set +h attribute for both. Save the new image. Reflash. Then please report back, if it helped. sio0.ovl sio1.ovl

If someone provides me with MIO firmware ROM images, I will be then able to setup it under emulation and see what is going on there. EDIT: NVM, found one. I have no idea what you are talking about. What is "the entry problem"? Is there also any problem with the DLT flasher? You need to be a bit more specific. I use the real hardware, just do not have a MIO (they are rare in Europe, as far as I know). And otherwise everything works fine. Basically. When not using DOSKEY, the plain E: handler is being used for console input and output. When using DOSKEY the input is handled by the OS's K: handler via a wrapper provided by the library (U_GETKEY).

Cannot reproduce: https://youtu.be/0Im5t6f32-s Yes, as explained above. The clip above was recorded with a freshly downloaded ROM image. Attached. Although, as I said, 4.49g is the same as f minus the DOSKEY crashing in the latter. SDX449f_supercart.rom

4.49g is literally 4.49f with one fix related to TAB handling in DOSKEY. Everything else is identical. Also, there have been no substantial changes in KEY.COM since 2014. I cannot reproduce the problem here either, so more information may be needed. If you have more random problems with 4.49g - as I understand "hit or miss", though I am not really sure what this means - then it can be a case of a bad flash. If the problems persist after reflashing, report them here.

The system handles without a problem a 2.5-inch hard drive, which draws something like 700mA when spinning up. I doubt if a fan could draw more.

The DOSKEY aliases are loaded to the history buffer at startup time. So, unless there are only 4 banks of ext (or less) at that very moment, I doubt if it can interfere with BXE. A known problem with BXE is of somewhat different nature. Namely, CAR.COM, when exiting from a cartridge to DOS, will dump what it considers the cart's memory to the file being pointed to by the $CAR variable. However, this dump contains pages 4,5,6 and everything from memlo to memtop - but not the ext RAM banks or the RAM residing under the ROM or under the cartridge. Thus one of the things not being dumped is the BXE Extension code. Therefore, when you execute the BXE for the first time (or by doing CAR /I), the extensions are loaded. When you quit to DOS, the basic memory gets dumped. When you get back to BXE, CAR loads the dump, and BXE is warm-started, thus not loading the extensions again. All is fine as long as you do not power-cycle or do something else that destroys the extension code in memory. Typing CAR then loads the dump, and BXE is warm started thinking that the extensions are loaded. But they are not, so no wonder, why it can hang etc. To cure that, either undefine the $CAR (effectively disabling the dump) or - better - run BXE always with CAR /I (especially after a power cycle). This will of course obliterate any program which was saved in the dump, but for now I do not know any better method.

As much as I have a bad opinion on "MagiC OS", it was not a copy (slavish or not) of the Mac GUI. It was a new implementation of GEM+GEMDOS. Buggy for sure, but, as far as I know, having nothing to do with a Mac. It is only a Mac font which is in use, which, by the way, was also used by NVDI.

As far as I can tell from the emulation, the worst problem with the 80-column board is that its firmware is utter cra.... very alpha, that is. Without thourough rewrite there is little hope that it would work reliably on broader scale.

Does .ALLW imply/execute REP #$30 and .ALLB - SEP #$30? If so, then you are first pushing the P register status onto the stack (PHP in the first line), then you are pulling "CALLER RETURN", but in fact you are pulling the P byte + a part of the return address with that? Then the next PLA gets the other byte of the return address instead of the P register byte. These need to be swapped, PLA-byte first to get the P register status, then PLA-word next to get the return address, no?

It should be $3C52, but it is $3152. So the question is: is acc really 16-bit at $A8D3? Especially if the JSR is being done "IN NATIVE 8/8 MODE"...

That's COMMAND.COM which ends at $2B6C. Worry not, it gets unloaded before starting programs.

MEMLO is where the MEM reports. What is missing in the equation, is the X.COM, which is used to load legacy binaries and which is taking up some memory too. It loads bulk of its code to ext RAM, but when there is no place there, it falls back to the main RAM, raising the memlo enormously.

It seems that there is a minor mistake in the build scripts and Supercart images are built with SIDE2 id instead of the Supercart id. But it is only a visual glitch, as the pass-through code is there, as indicated by XVER and by the fact that it works, as you say. The important part is "pass-through", as Supercart is basically a SIDE2 clone with a cart port added (and without the CF connector), so as far as the cartridge itself is concerned, they are compatible. So no, there is no need to reflash, unless you want a newer version or so. Most today's cartridges are flashable, I cannot think of anything now, that is not.

That is probably the first game ever which behaves like a productivity application. It runs from a DOS (SDX here), then cleanly exits back. I am impressed. I ran it on Rapidus - it worked without any problems. Display: PAL CRT here, no glitches, everything good. And it all looks beautifully. Congratulations.

The snippet of code I quoted suggests otherwise: JMP ($0a) when executed by XIO 40 under BASIC is supposed to exit the interpreter and return the control to the CP. An attempt to resume a BASIC session later will result with what I wrote. But in fact, there is a bug in current SDX revisions and such a JMP ($0a) will hang. I have already committed a fix. That is not true anymore for any DOS which implements XIO 40. Sure, RTS *technically* returns to "DOS". But, since a program is executed effectively by a JSR, it returns to the binary loader, and the binary loader, when invoked as XIO 40 - returns to the calling application. Whereas JMP ($0a) aborts the program and returns the control to the DOS UI itself. It also works so during loading a program: an RTS from an init segment returns to the loader and continues loading, JMP ($0a) aborts it. Care to exemplify?

Your program will ruin the BASIC state, because $80 is a part of the lomem vector, pointing to the lowest memory available to BASIC. It is a pretty essential variable. Next, under SDX, jmp ($0a) returns the control to the DOS, which normally will save (swap out) the BASIC's memory, including addresses $80-$FF, to a file pointed to by the environment variable $BASIC$. It by default points to the ramdisk. Later, when you are trying to re-enter BASIC, the memory will get swapped back in before handing the control to BASIC. Of course, it will restore the last state, in this case, the faulty one. To force a cold restart of the BASIC interpreter, do BASIC /I from the CP prompt. Also lookup the User's Manual for more details.

It seems that in IDE+ emulation the emulated ATA controller does not react correctly to the ATA command $40 (READ-VERIFY). When fed with it, it just enters the BUSY state and that is it. To reproduce, run CLX with /SV switches (scan for bad sectors / use Verify sector command). When I poke a $40 to the COMMAND register, poking something else there seems to restore normal operation (or at least clears the busy bit). However, as it is on the pic, it hangs irrecoverably and only clicking "Cold reset" in the menu gets it back to normal.

It looks like the (or a) fix was already posted here: http://www.atari.org.pl/forum/viewtopic.php?pid=291400#p291400 So it just may be a question of preparing a final revision and putting it at the URL where the SDX build scripts are fetching it from. As about the APT specs, if a section is ambiguous, one can always make a suggestion on how to rephrase (I am probably opening a can of worms here).

In fact, @flashjazzcat is one of the main authors of this specification. Yes, it was I who wrote it, but it was preceded by a quite lengthy discussion on PM among several people who had been invited to discuss the details. That was the phase of the theory, and later it was implemented in practice, i.e. in SIDE/U1MB and IDE+ (this is why there is data interchangeability between these two interfaces). Also, @flashjazzcat wrote his FDISK according to all these specifications. The phase of "asking questions" which was mentioned above was, I believe, the implementation phase, where we were clarifying any details which seemed vague then. It also resulted in multiple revisions of the text, as you can see in the PDF, the document underwent about 20 revisions. So I am genuinely curious what can be ambiguous there after all this process.