Thread: [Atari800-users] Altirra OS and Altirra BASIC are now built-in, can we remove EmuOS?
Brought to you by:
joy
Menu
▾
▴
atari800-users
|
From: Tomasz K. <tom...@in...> - 2018-06-04 06:52:33
|
Hi, When fixing the build of the Android port, I noticed that the implementation of the Altirra OS as built in the emulator, was somewhat sub-optimal - it only provided a single OS ROM for both the 400/800 and XL/XE modes, while in actual Altirra two separate OS ROMs are used in these circumstances; and it didn't include the free BASIC replacement, also available from Altirra. I decided to upgrade this feature. Now there a four ROMs from Altirra built in Atari800 (all placed in src/roms/): - AltirraOS for the Atari 400/800, - AltirraOS for the Atari XL/XE, - Altirra replacement BIOS for the 5200, - Altirra BASIC. It is now possible to use the emulator without providing the Atari system ROMs at all. The four Altirra ROMs are used automatically when the user has not provided any OS ROMs by himself. They can also be selected in "System settings" even when the original Atari ROMs are available. Given that the Altirra ROMs make the old 2KB "EmuOS" redundant, I would like to suggest complete removal of the EmuOS functionality. Building Atari800 without the Altirra ROMs using --disable-altirra_bios (I guess this might be useful for some embedded purposes) would still be possible. In this case, the user would have to provide the necessary OS ROMs or he would be unable to start emulation. Any thoughts? Regards, --Tomek |
|
From: Petr S. <pst...@so...> - 2018-06-04 09:25:17
|
Tomasz Krasuski píše v Po 04. 06. 2018 v 08:52 +0200: > I decided to upgrade this feature. Now there a four ROMs from Altirra > built in Atari800 (all placed in src/roms/): > - AltirraOS for the Atari 400/800, > - AltirraOS for the Atari XL/XE, > - Altirra replacement BIOS for the 5200, > - Altirra BASIC. > > It is now possible to use the emulator without providing the Atari > system ROMs at all. Great! > Given that the Altirra ROMs make the old 2KB "EmuOS" redundant, I > would like to suggest complete removal of the EmuOS functionality. I agree. Is there something else someone wants to get fixed before next release? Petr |
|
From: Petr S. <pst...@so...> - 2018-10-10 11:03:24
|
Miro Kropáček píše v St 10. 10. 2018 v 12:51 +0200: > > I am happy that for the first time in twenty+ years we can > > distribute a working emulator thanks to the Altirra ROM - returning > > back is not a good idea. > Well, at least as far as the built-in BASIC goes, doesn't look very > working to me. After thinking about it a bit more I believe we should add a message that would appear before Altirra starts booting. The message would warn users that a replacement OS is booting and that getting the original ROMs might be a better idea. On a fast host this message would just blink (so it wouldn't bother), on a slower host it would stay there longer (so users would realize what to do). When I get some spare time I might look into updating the Altirra OS with such message. Sometime in 2039. Petr |
|
From: Daniel S. <dse...@gm...> - 2018-10-11 19:22:45
|
Hi! El Wed, Oct 10, 2018 at 01:03:08PM +0200, Petr Stehlík escribio: > Miro Kropáček píše v St 10. 10. 2018 v 12:51 +0200: > > > > I am happy that for the first time in twenty+ years we can > > > distribute a working emulator thanks to the Altirra ROM - returning > > > back is not a good idea. > > Well, at least as far as the built-in BASIC goes, doesn't look very > > working to me. > > After thinking about it a bit more I believe we should add a message > that would appear before Altirra starts booting. The message would warn > users that a replacement OS is booting and that getting the original > ROMs might be a better idea. > > On a fast host this message would just blink (so it wouldn't bother), > on a slower host it would stay there longer (so users would realize > what to do). > Something must be wrong with the OP setup, as I just measured in an NTSC setup: - With standard XL-OS ROM: 70 frames (1.2s) up to first graphics-0 (blue) screen. - With Altirra OS ROM: 22 frames (0.4s) up to first graphics-0 screen. So, Altirra OS is 3 times faster to show information on screen, just after 0.4 seconds in a real Atari. If the OP says his boot takes 15 seconds, it means the Atari is at less than 3% standard speed, certainly unusable! |
|
From: B W. <ya...@gm...> - 2018-06-04 09:36:05
|
On 6/4/18, Petr Stehlík <pst...@so...> wrote: >> Given that the Altirra ROMs make the old 2KB "EmuOS" redundant, I >> would like to suggest complete removal of the EmuOS functionality. > > I agree. EmuOS was only ever useful for running diagnostic carts. Basketball and Star Raiders, IIRC. Can't imagine anyone missing it. > Is there something else someone wants to get fixed before next release? I've got a pile of commits for the monitor. They got put on hold because the hard drive they were on had issues, I recovered them but they've been sitting long enough that I'll probably have to do some massaging to get them to apply cleanly to the current git. To get them into the repo, would it be OK to fork atari800 on my own git server, and have you (or whoever) pull from it? I'm still not creating a github account (and I'm glad I was stubborn about it, if Microsoft really is buying Github)... and posting patches to the mailing list is maybe more work than either of us want to do. |
|
From: Petr S. <pst...@so...> - 2018-06-04 09:44:51
|
B Watson píše v Po 04. 06. 2018 v 05:35 -0400: > I've got a pile of commits for the monitor. Go ahead with them :) > would it be OK to fork atari800 on my own git server, and have you > (or whoever) pull from it? I think it would make more sense to use Github for this kind of collaboration - that was actually one of the main reasons for moving the whole project from SF.net to Github.com. In Github it takes just one or two mouse clicks to merge your changes, I believe. > I'm still not creating a github account (and I'm glad I was stubborn > about it, if Microsoft really is buying Github) what's wrong with creating a github account, even if it is owned by Microsoft? You can always use fake email and other credentials if you care about your privacy. If you insisted on using your github server then yes, it would still be better than a bunch of patches in the mailing list. Petr |
|
From: Tomasz K. <tom...@in...> - 2018-06-21 23:30:02
|
On Mon, 2018-06-04 at 05:35 -0400, B Watson wrote: > On 6/4/18, Petr Stehlík <pst...@so...> wrote: > > Is there something else someone wants to get fixed before next > > release? > > I've got a pile of commits for the monitor. They got put on hold > because > the hard drive they were on had issues, I recovered them but they've > been sitting long enough that I'll probably have to do some massaging > to get them to apply cleanly to the current git. Please test your changes with various configure options (most importantly --enable-monitor*). Last time the project did not build with --disable-monitorhints. Regards, --Tomek |
|
From: Tomasz K. <tom...@in...> - 2018-06-22 01:31:17
|
On Mon, 2018-06-04 at 08:52 +0200, Tomasz Krasuski wrote: > Given that the Altirra ROMs make the old 2KB "EmuOS" redundant, I > would > like to suggest complete removal of the EmuOS functionality. Building > Atari800 without the Altirra ROMs using --disable-altirra_bios (I > guess > this might be useful for some embedded purposes) would still be > possible. In this case, the user would have to provide the necessary > OS > ROMs or he would be unable to start emulation. > > Any thoughts? So, I am in the middle of removing EmuOS. The current state is in the "remove-emuos" branch, if anyone wishes to look. The ability to build Atari800 without any built-in OS is possible by configuring with --disable-altirra_bios. When the user builds with --disable-altirra_bios, and does not provide any OS ROMs in cofiguration or command line, the currently-implemented behaviour is to fill the OS ROM memory with zeroes and run emulation anyway. The result will be the emulator displaying blank screen while it executes BRK (=$00) instructions infinitely. The user may then go F1 to menu as usual, and configure OS ROMs as he wishes. Alternatively, they can open the monitor and READ an OS ROM from external file. I'm wondering if the above behaviour is enough. I suppose we could be more user-friendly and for example disallow starting emulation when no OS ROM has been provided, but I don't think it would be necessary. After all, a user who chooses to --disable-altirra_bios for some reason, probably understands the consequences and won't be surprised that the emulator loops infinitely without warning. Any comments/suggestions? Regards, --Tomek > |
|
From: Petr S. <pst...@so...> - 2018-06-25 11:01:48
|
Tomasz Krasuski píše v Pá 22. 06. 2018 v 03:16 +0200: > When the user builds with --disable-altirra_bios, and does not > provide any OS ROMs in cofiguration or command line, the currently- > implemented behaviour is to fill the OS ROM memory with zeroes and > run emulation anyway. The result will be the emulator displaying > blank screen while it executes BRK (=$00) instructions infinitely. I'm perfectly fine with that. > I'm wondering if the above behaviour is enough. yes. Remember that such build without any embedded Atari bios will not be distributed widely so the risk of surprised users is zero. Petr |
|
From: Tomasz K. <tom...@in...> - 2018-06-28 22:19:17
|
On Mon, 2018-06-25 at 13:01 +0200, Petr Stehlík wrote: > Tomasz Krasuski píše v Pá 22. 06. 2018 v 03:16 +0200: > > When the user builds with --disable-altirra_bios, and does not > > provide any OS ROMs in cofiguration or command line, the currently- > > implemented behaviour is to fill the OS ROM memory with zeroes and > > run emulation anyway. The result will be the emulator displaying > > blank screen while it executes BRK (=$00) instructions infinitely. > > I'm perfectly fine with that. Okay then, EmuOS removal is now merged into master. --Tomek |
|
From: Miro K. <mir...@gm...> - 2018-10-09 15:21:43
|
On Mon, 4 Jun 2018 at 11:36, B Watson <ya...@gm...> wrote: > EmuOS was only ever useful for running diagnostic carts. Basketball > and Star Raiders, IIRC. Can't imagine anyone missing it. > A bit late to the party but there is actually quite important factor we (I) had missed - and that is the impact on the slow(er) machines. After several months I could finally get back to Atari800 for the Falcon and I couldn't believe my eyes -- the emulator starts with the typical "booting to basic/self test" screen and goes on and on and on and on.... It actually takes about 15 seconds to boot on my fastest setup and then it shows that stupid Altirra animation while still loading something from this every few seconds. Comparing to almost instant message "man, get the ROMs and reboot" I can't really welcome this change at all. 15 seconds to show that ROMs haven't been found, oh my. >From an user perspective, it actually looked totally broken, like BASIC ended up in sort of infite loop or something. And yes, I'm aware of the alternative, showing a black screen with no message at all. Can't say this is any better. -- MiKRO / Mystic Bytes http://mikro.atari.org |
|
From: Miro K. <mir...@gm...> - 2018-10-09 15:26:47
|
On Tue, 9 Oct 2018 at 17:21, Miro Kropáček <mir...@gm...> wrote: > It actually takes about 15 seconds to boot on my fastest setup and then it > shows that stupid Altirra animation while still loading something from this > every few seconds. Comparing to almost instant message "man, get the ROMs > and reboot" I can't really welcome this change at all. 15 seconds to show > that ROMs haven't been found, oh my. > Out of curiosity I tried to enable BASIC (which is disabled by default), played a bit in there, DIR, BYE, F5, a few commands, bam, frozen and then ended up in Atari800 monitor. Really, really not happy with the change. -- MiKRO / Mystic Bytes http://mikro.atari.org |
|
From: Miro K. <mir...@gm...> - 2018-10-11 20:41:24
|
Hi, On Thu, 11 Oct 2018 at 21:23, Daniel Serpell <dse...@gm...> wrote: > So, Altirra OS is 3 times faster to show information on screen, just > after 0.4 seconds in a real Atari. > Maybe on a real Atari but in Atari800 emulator it looks like this: https://photos.app.goo.gl/kcJftBAykwq9US4HA ... this is my AMD Ryzen 7 CPU at 3.2 GHz, having stock rom vs altirra rom executed at the same time (sorry for the quality, recorded in a hurry). Now try to imagine the difference on a 66+ MHz machine. If the OP says his boot takes 15 seconds, it means the Atari is at less > than 3% standard speed, certainly unusable! > As said before, this has nothing to do with emulation speed. It's about the code which loads bytes from the rom image. -- MiKRO / Mystic Bytes http://mikro.atari.org |
|
From: Daniel S. <dse...@gm...> - 2018-10-11 21:33:17
|
Hi! El Thu, Oct 11, 2018 at 10:41:05PM +0200, Miro Kropáček escribio: > Hi, > > On Thu, 11 Oct 2018 at 21:23, Daniel Serpell <dse...@gm...> wrote: > > > So, Altirra OS is 3 times faster to show information on screen, just > > after 0.4 seconds in a real Atari. > > > Maybe on a real Atari but in Atari800 emulator it looks like this: > https://photos.app.goo.gl/kcJftBAykwq9US4HA ... this is my AMD Ryzen 7 CPU > at 3.2 GHz, having stock rom vs altirra rom executed at the same time > (sorry for the quality, recorded in a hurry). Now try to imagine the > difference on a 66+ MHz machine. Your vide shows exactly what I said: Altirra OS boots to the blue screen a lot faster than the standard XL OS. Afterwards, your image shows the effect of Atari800 disk acceleration: the boot (that in a standard atary takes about 5 seconds retrying access to a missing disk drive) stops at once and the self-test is shown. The problem in your video is that you don't have enabled the SIO patch in the Altirra OS case, so you are seeing a "realistic" boot. As the default is SIO patch enabled, I don't know why you are seeing this. Regards, Daniel. |
|
From: Petr S. <pst...@so...> - 2018-10-10 08:05:01
|
Miro Kropáček píše v Út 09. 10. 2018 v 17:21 +0200: > A bit late to the party but there is actually quite important factor > we (I) had missed - and that is the impact on the slow(er) machines. how much slower? > It actually takes about 15 seconds to boot on my fastest setup how long does the Altirra boot take on a 100% speed of the original Atari? > From an user perspective, it actually looked totally broken, like > BASIC ended up in sort of infite loop or something. I'd think that the alternate/Altirra OS should not boot longer than the stock OS. That is under 1 second, right? Petr |
|
From: Miro K. <mir...@gm...> - 2018-10-10 08:16:14
|
On Wed, 10 Oct 2018 at 10:05, Petr Stehlík <pst...@so...> wrote: > how long does the Altirra boot take on a 100% speed of the original Atari? This has nothing to do with emulation speed. On the Falcon I also have 100% but I/O performance (or whatever it is) is simply slower. On my Linux it is a bit quicker - about 4.5 seconds (still pretty horrible if you ask me). I'd think that the alternate/Altirra OS should not boot longer than > the stock OS. That is under 1 second, right? > If you refer to the Self Test (which is booted by default when ROMs are present) then yes, it's a couple of seconds even on the Falcon. And as mentioned, the previous EmuOS (booted when ROMs are not present) was really nearly instant. On Linux - everything instant. So the slowdown is noticable also on faster platforms but on slower machines it simply doesn't make sense. Plus, Altirra BASIC is broken (see my report on github). -- MiKRO / Mystic Bytes http://mikro.atari.org |
|
From: Miro K. <mir...@gm...> - 2018-10-12 06:39:07
|
Hi, Your vide shows exactly what I said: Altirra OS boots to the blue screen a > lot faster than the standard XL OS. > I would choose short black screen against long blue screen anytime. ;-) The problem in your video is that you don't have enabled the SIO patch in > the Altirra OS case, so you are seeing a "realistic" boot. > I have enabled or disabled whatever default is. Both instances were started with a plain, new from scratch, configuration file. The only difference was the ROM configuration. But yes, I see "ENABLE_SIO_PATCH=1" in both configuration files. As the default is SIO patch enabled, I don't know why you are seeing this. > Are you sure this is related to SIO? I mean, it's a ROM, not a disk image, right? Anyways, if it is somehow related to SIO and it's slow because of that, well, it only marks my point - it makes booting much longer. And since it's not local only to my slow Atari Falcon, I'd say something should be done about it. -- MiKRO / Mystic Bytes http://mikro.atari.org |
|
From: Daniel S. <dse...@gm...> - 2018-10-12 23:48:32
Attachments:
patch-default-rom.patch
|
Hi!
El Fri, Oct 12, 2018 at 08:38:46AM +0200, Miro Kropáček escribio:
> Hi,
>
> Your vide shows exactly what I said: Altirra OS boots to the blue screen a
> > lot faster than the standard XL OS.
> >
> I would choose short black screen against long blue screen anytime. ;-)
>
> The problem in your video is that you don't have enabled the SIO patch in
> > the Altirra OS case, so you are seeing a "realistic" boot.
> >
> I have enabled or disabled whatever default is. Both instances were started
> with a plain, new from scratch, configuration file. The only difference was
> the ROM configuration. But yes, I see "ENABLE_SIO_PATCH=1" in both
> configuration files.
>
> As the default is SIO patch enabled, I don't know why you are seeing this.
> >
> Are you sure this is related to SIO? I mean, it's a ROM, not a disk image,
> right? Anyways, if it is somehow related to SIO and it's slow because of
> that, well, it only marks my point - it makes booting much longer. And
> since it's not local only to my slow Atari Falcon, I'd say something should
> be done about it.
Ok, I see the problem now. We are not applying the SIO patch in the
default Altirra OS rom.
Try the attached patch to the 4.0 sources, with it the boot under
Altirra OS is much faster than on real OS.
Regards,
Daniel.
|
|
From: Petr S. <pst...@so...> - 2018-10-10 09:14:29
|
Miro Kropáček píše v St 10. 10. 2018 v 10:15 +0200: > > > how long does the Altirra boot take on a 100% speed of the original > > Atari? > This has nothing to do with emulation speed. how long does it boot on the real hardware then? > And as mentioned, the previous EmuOS (booted when ROMs are not > present) was really nearly instant. On Linux - everything instant. you cannot really compare time of a full operating system boot with just a message hardcoded in videoram. What I am trying to say is that the Altirra OS should not boot longer than stock ROM. > So the slowdown is noticable also on faster platforms but on slower > machines it simply doesn't make sense. if Altirra BASIC/ROM/OS is slow then you can go ahead and speed it up, I guess? I hope it's open source. Perhaps there are some timeouts waiting for various peripherals that could be shortened? Just guessing.. > Plus, Altirra BASIC is broken (see my report on github). So the github issue is about broken Altirra BASIC? I was afraid it's about a bug in our emulator. If it's in Altirra then better report it to its author :) Petr |
|
From: Miro K. <mir...@gm...> - 2018-10-10 09:23:46
|
On Wed, 10 Oct 2018 at 11:14, Petr Stehlík <pst...@so...> wrote: > how long does it boot on the real hardware then? > I don't know. I have no way to verify Altirra ROM on real hardware. you cannot really compare time of a full operating system boot with > just a message hardcoded in videoram. What I am trying to say is that > the Altirra OS should not boot longer than stock ROM. > You have cut off my comparison with the Self Test (which stock ROM is). There you can get a fair comparison: Self Test - from a couple of seconds (Falcon) to instant (Linux). Compare with 15s (Falcon) to 4.5s (Linux). if Altirra BASIC/ROM/OS is slow then you can go ahead and speed it up, > I guess? I hope it's open source. Perhaps there are some timeouts > waiting for various peripherals that could be shortened? Just > guessing.. > Certainly someone can do that but it wouldn't be me. So the github issue is about broken Altirra BASIC? I was afraid it's > about a bug in our emulator. If it's in Altirra then better report it > to its author :) > I'm not 100% sure whos fault it is. This is what I saw, didn't happen with EmuOS and certainly didn't happen with stock ROM BASIC. All I'm saying that this feature has caused me a lot of pain, I must disable it and add a note in INSTALL.falcon that we are sorry but for the Falcon port we had to replace the simple, plain, clear message about installing ROMs with a black screen. -- MiKRO / Mystic Bytes http://mikro.atari.org |
|
From: Miro K. <mir...@gm...> - 2018-10-13 08:11:49
|
Hi, On Sat, 13 Oct 2018 at 01:48, Daniel Serpell <dse...@gm...> wrote: > Try the attached patch to the 4.0 sources, with it the boot under Altirra > OS is much faster than on real OS. > can you supply a patch suitable for current source tree? We are doing already some patching there (although quite different <https://github.com/atari800/atari800/blob/master/src/esc.c#L213>) plus your patch seems incomplete at last - how changing from UBYTE to UWORD helps if we are comparing byte values later anyway? -- MiKRO / Mystic Bytes http://mikro.atari.org |
|
From: Petr S. <pst...@so...> - 2018-10-10 10:39:46
|
Miro Kropáček píše v St 10. 10. 2018 v 11:23 +0200: > All I'm saying that this feature has caused me a lot of pain, I must > disable it and add a note in INSTALL.falcon that we are sorry but for > the Falcon port we had to replace the simple, plain, clear message > about installing ROMs with a black screen. I don't agree with such "solution". Even if we didn't speed the Altirra boot up then whoever cannot wait 15 seconds can go ahead and install the original ROM files. I am happy that for the first time in twenty+ years we can distribute a working emulator thanks to the Altirra ROM - returning back is not a good idea. The simple, plain and clear message about installing ROM is in the documentation, after all. Petr |
|
From: Daniel S. <dse...@gm...> - 2018-10-13 15:15:26
|
Hi! El Sat, Oct 13, 2018 at 10:11:29AM +0200, Miro Kropáček escribio: > Hi, > > On Sat, 13 Oct 2018 at 01:48, Daniel Serpell <dse...@gm...> wrote: > > > Try the attached patch to the 4.0 sources, with it the boot under Altirra > > OS is much faster than on real OS. > > > can you supply a patch suitable for current source tree? We are doing > already some patching there (although quite different > <https://github.com/atari800/atari800/blob/master/src/esc.c#L213>) plus > your patch seems incomplete at last - how changing from UBYTE to UWORD > helps if we are comparing byte values later anyway? > Current code does not seems to need the patch, as Altirra OS is already handled in the switch statement. I modified the variables to UWORD to avoid adding a flag like the current code ("int altirra = FALSE;"), this was to disable patching the cassette handler but allowing patching the SIOV handle. Are you sure that current GIT version waits on SIO with Altirra OS? Regards, Daniel. |
|
From: Daniel S. <dse...@gm...> - 2018-10-13 15:31:13
Attachments:
0001-Fixes-typo-in-EMUOS_ALTIRRA-defines.patch
|
Hi! El Sat, Oct 13, 2018 at 12:15:11PM -0300, Daniel Serpell escribio: > Hi! > > El Sat, Oct 13, 2018 at 10:11:29AM +0200, Miro Kropáček escribio: > > Hi, > > > > On Sat, 13 Oct 2018 at 01:48, Daniel Serpell <dse...@gm...> wrote: > > > > > Try the attached patch to the 4.0 sources, with it the boot under Altirra > > > OS is much faster than on real OS. > > > > > can you supply a patch suitable for current source tree? We are doing > > already some patching there (although quite different > > <https://github.com/atari800/atari800/blob/master/src/esc.c#L213>) plus > > your patch seems incomplete at last - how changing from UBYTE to UWORD > > helps if we are comparing byte values later anyway? > > > > Current code does not seems to need the patch, as Altirra OS is already > handled in the switch statement. > > I modified the variables to UWORD to avoid adding a flag like the > current code ("int altirra = FALSE;"), this was to disable patching the > cassette handler but allowing patching the SIOV handle. > > Are you sure that current GIT version waits on SIO with Altirra OS? > Ok, mystery solved. There is a type ni the EMUOS defines! Apply attached patch. Regards, Daniel. |
|
From: Miro K. <mir...@gm...> - 2018-10-13 16:33:00
|
Hi Daniel, On Sat, 13 Oct 2018 at 17:31, Daniel Serpell <dse...@gm...> wrote: > Ok, mystery solved. There is a type ni the EMUOS defines! > That definitely helped, now the Altirra-based Atari boots within a couple of seconds, too. :-) (yes, even on the Atari Falcon!) I find it quite amusing that it was the Falcon port which uncovered this bug, what would you do without it? ;-) Thank you for your persistence, without your belief that there's no way Altirra behaves like that I would totally write it off as unusable. -- MiKRO / Mystic Bytes http://mikro.atari.org |
