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?