drac030
-
Posts
2,770 -
Joined
-
Last visited
-
Days Won
1
Content Type
Profiles
Forums
Blogs
Gallery
Events
Store
Posts posted by drac030
-
-
1 hour ago, Baer63 said:
Hope this explains a bit how big expansions can work without compatibility problems.
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?
-
17 hours ago, CharlieChaplin said:
Here is what happens on one of my Ataris when the GTIA does warm up with ACP 1.0.
Bad GTIA, type 2: http://atariki.krap.pl/index.php/GTIA#Wadliwe_GTIA
-
4
-
-
3 hours ago, woj said:
My money is on that what was really meant is Sophia 2?
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?
-
2
-
3
-
1
-
-
5 hours ago, _The Doctor__ said:
Does SpartaDOS X know when the CSS BlackBox is using XE BANKed RAM for spooling? I see no difference in size with it on or off. Using an additional 64K or 192K of XE banks only yields the same expected sizes. This leads me to wondering which way the BlackBox or SpartaDos X will clobber each other if they are un aware of who's in the XE banks. I am not sure if the usual reservation of RAMDisk banks will alleviate this if SpartaDOS X -using banks- fills the empty spots in. Is there a way to tell SpartaDOS X to USE extended memory after the first 4 banks and of course then we can already tell RAMDisk to use memory after 8 banks if we wish.
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.
-
1
-
-
34 minutes ago, _The Doctor__ said:
The problems began with 4.49e as far as I can recall.
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.
-
5
-
-
1 hour ago, _The Doctor__ said:
Remove MIO and all works well.
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.
1 hour ago, _The Doctor__ said:You fixed the flasher back then. And the entry problem before.
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.
1 hour ago, _The Doctor__ said:I am very surprised that no one is using the real hardware and such that often, as I've been the only one to look into this.
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.
1 hour ago, flashjazzcat said:Isn't the state of the machine to just use nothing but the OS keyboard interrupt handler until KEY ON is executed?
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).
-
28 minutes ago, _The Doctor__ said:
130XE with MIO and Fujinet SpartaDOS Super Cart with real time clock (aka ultimate time clock) fresh down load from SDX site.
Flash the cartridge, Broken Command line input system, won't repeat won't accept same key twice, KEY ON... oh look it works, KEY OFF key repeat is gone and pressing the same key twice results in no further input on the duplicate key press.
Cannot reproduce:
28 minutes ago, _The Doctor__ said:4.49f is not in the archive.
Yes, as explained above.
28 minutes ago, _The Doctor__ said:Only way it's a bad flash is if the source is corrupt.
The clip above was recorded with a freshly downloaded ROM image.
31 minutes ago, _The Doctor__ said:4.49f was pretty good during it's last iteration, so I thought I'd flash back to it, and couldn't find it.
Attached. Although, as I said, 4.49g is the same as f minus the DOSKEY crashing in the latter.
-
3 hours ago, _The Doctor__ said:
4.49g has a nasty problem with KEY being off, it won't key repeat and you can't delete backspace more than once in a row nor any other key repeated in a row. If you type KEY ON then it's business as usual and all is working. I normally turn KEY OFF for various reasons, and KEY OFF is the default in any event. As I muddle through 'g' it's kind of hit or miss. I'd like the very last 4.49f and then will continue testing and trying g.
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.
-
11 hours ago, x=usr(1536) said:
I'm wondering how the system would handle the inrush current when the fan starts up
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.
-
2
-
-
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.
-
1
-
-
35 minutes ago, FifthPlayer said:
Anyway, MagiC OS, being a slavish copy of the Mac GUI,
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?
-
1 hour ago, Alfred said:
Should be at least $3Cxx, should it not ? This is 4.30 test6.
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"...
-
25 minutes ago, woj said:
MEM reports $1DBB, at $2E7 you see $2B6C?!
That's COMMAND.COM which ends at $2B6C. Worry not, it gets unloaded before starting programs.
-
1
-
-
15 hours ago, woj said:
What is also surprising is that MEMLO is nowhere near what MEM reports
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.
-
1
-
-
11 hours ago, CrystalKnight said:
mine says it's a "SIDE2, pass-through"
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.
11 hours ago, CrystalKnight said:Also, how would I know if the cartridge has the ability to flash update on it, or should I just test and see?
Most today's cartridges are flashable, I cannot think of anything now, that is not.
-
1
-
-
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.
-
4
-
-
On 2/13/2024 at 4:40 AM, phaeron said:
OP is not trying to resume a previous BASIC session, but reset it so that BASIC doesn't attempt to reuse its overwritten state.
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.
On 2/13/2024 at 4:40 AM, phaeron said:An RTS (RETURN) at the end of a program will always return control to DOS.
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.
On 2/13/2024 at 4:40 AM, phaeron said:However... the problem is the behavior of non-Atari DOSes that do non-standard things like interpreting register state on return from the program or skipping/ignoring the RUN vector.
Care to exemplify?
-
2 hours ago, idk said:
I don't need to jump to the cart, DOS can return to it, a hypothetical example; if we have the binary:
2000: lda #0 sta $80 jmp ($a)
I can load that from DOS directly or BASIC using XIO 40,#7,0,0,"D1:ABOVE.XEX"
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.
-
1
-
-
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.
-
1
-
-
On 2/5/2024 at 5:00 PM, flashjazzcat said:
BTW: I am still investigating the anomalous flags you told me about a few months back (being only recently up and running again after spending several months moving house).
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.
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
512k of RAM via a PBI upgrade?
in Atari 8-Bit Computers
Posted · Edited by drac030
typo
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?