What could Atari have done better with the ST?

No topic. Everything you want to speak about. Please just stay courteous.

Moderators: Mug UK, Silver Surfer, Moderator Team

Locked
User avatar
Frank B
Atari God
Atari God
Posts: 1029
Joined: Wed Jan 04, 2006 1:28 am
Location: Boston

Re: What could Atari have done better with the ST?

Post by Frank B »

dlfrsilver wrote:
As an experiment DFRsilver. Try the following on both machines in user mode.

On the ST: move.w #0,$ff8240
On the Amiga: move.w #0,$dff180

One will barf and one won't. Which behaviour is better?
So what ? The amiga palette color 00 register $DFF180 is a user mode instruction. And that's unrelated to user/supervisor mode of the 68000 processor.

You're comparing apples and oranges. Both hardware are different.
You're really not getting it. Let me try and explain for you again.
$dff180 is a chip register location on the Amiga. Its analog on the ST is $ff8240.

The ST has a form of memory protection where user mode programs (think of them as non root) cannot corrupt them.
Both the vector table and the chip locations are protected from user mode access on the ST. User mode programs can't trap a trap handler or CPU exception handler. User mode programs can't crap all over IO registers. They have to either be in supervisor mode or access them via the OS.

The Amiga has no such protection mechanism. Any process can crap all over the machine. The ST is far better in this regard.
User avatar
Cyprian
10 GOTO 10
10 GOTO 10
Posts: 1949
Joined: Fri Oct 04, 2002 11:23 am
Location: Warsaw, Poland

Re: What could Atari have done better with the ST?

Post by Cyprian »

please decide whether:
dlfrsilver wrote:The amiga palette color 00 register $DFF180 is a user mode instruction. And that's unrelated to user/supervisor mode of the 68000 processor.
or
dlfrsilver wrote:It's clearly stated in the Amiga bible that you can't have full access to the hardware without activating Supervisor mode.
Portfolio / Lynx II / Jaguar / TT030 / Mega STe / 800 XL / 1040 STe / Falcon030 / 65 XE / 520 STm / SM124 / SC1435
SDrive / PAK68/3 / Lynx Multi Card / LDW Super 2000 / XCA12 / SkunkBoard / CosmosEx / SatanDisk / UltraSatan / USB Floppy Drive Emulator / Eiffel / SIO2PC / Crazy Dots / PAM Net
Hatari / Steem SSE / Aranym / Saint
http://260ste.appspot.com/
User avatar
shoggoth
Nature
Nature
Posts: 1014
Joined: Tue Aug 01, 2006 9:21 am
Location: Halmstad, Sweden
Contact:

Re: What could Atari have done better with the ST?

Post by shoggoth »

dlfrsilver wrote:
As an experiment DFRsilver. Try the following on both machines in user mode.

On the ST: move.w #0,$ff8240
On the Amiga: move.w #0,$dff180

One will barf and one won't. Which behaviour is better?
So what ? The amiga palette color 00 register $DFF180 is a user mode instruction. And that's unrelated to user/supervisor mode of the 68000 processor.

You're comparing apples and oranges. Both hardware are different.
Nah, it's not unrelated, since the 68k CPU allows you to have privilege levels assigned to different memory regions. You're right when it comes to the fact that AmigaOS partly runs in supervisor mode, the opposite wouldn't be possible since exceptions for obvious reasons end up in supervisor mode, and certain instructions require supervisor privilege. After all, the Amiga does have a 68k CPU. We all know that, no need to go teenage about it.

AmigaOS and the Amiga does however not exploit supervisor mode beyond that, and that's the point certain posters made.
Ain't no space like PeP-space.
joska
Hardware Guru
Hardware Guru
Posts: 4724
Joined: Tue Oct 30, 2007 2:55 pm
Location: Florø, Norway
Contact:

Re: What could Atari have done better with the ST?

Post by joska »

AtariZoll wrote:Well, then it is just subroutine call, done in some slow fashion, it seems. And why APP must look in tables instead OS ? Seems not much wise.
Exactly, it's a subroutine. I think it's rather clever. It also means that Workbench can load further libraries and treat these exactly like the system libraries. The Amiga has used clever (and clean) system extensions like this since day one.
AtariZoll wrote:Fastest way would be something like: reading OS routine address from some defined system variable or ROM address to a0, putting parameters in data registers - as much as needed, and perform jsr (a0) . Short code, no stack usage for parameters.
This is pretty much what you do on the Amiga (although not sure about parameter passing). Something like this (from memory, as I said I haven't done this since the late 80's...):

move.l a6,-(sp)
lea librarybase,a6
jsr function(a6)
move.l (sp)+,a6
AtariZoll wrote:And as "greatest" benefit: CPU must not enter supervisor mode :mrgreen:
Simpler would be with some trap. Maybe Amiga just wanted to do everything different than usual ways ?
Why would a trap be simpler? Yes, on the ST this may be true because many OS-functions needs to go to supervisor-mode to access hw anyway. But as others have pointed out this is not necessary on the Amiga. A simple jsr is quicker than a trap too.

A nice sideeffect of this strategy is that the OS *has* to be cleanly written, as the OS itself will be pre-empted. So everything must be thread-safe. Which is something no TOS has ever been remotely close to be.
Jo Even

VanillaMiNT - Firebee - Falcon060 - Milan060 - Falcon040 - MIST - Mega ST - STM - STE - Amiga 600 - Sharp MZ700 - MSX - Amstrad CPC - C64
AtariZoll
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2978
Joined: Mon Feb 20, 2012 4:42 pm
Contact:

Re: What could Atari have done better with the ST?

Post by AtariZoll »

Joska: you said: "you have an array of function pointers, look up the correct one for the function you want to call and JSR to it."
Look up the correct one - that means in computer terminology to use table and calculate which value to choice. Then you come with: lea librarybase,a6
jsr function(a6) - what is pretty much different - just using constant displacement. Now, that librarybase must be on some constant loc, and that would be ROM only then, so it was not exactly like that. Especially if it should be expandable. So, pointers must be in RAM.
Trap was not invented by Atari or Digital Research. That's 68000 design in purpose. Trap is just not slower than picking some address from somewhere and perform jsr . Idea with trap was not to use it in supervisor mode because access to HW registers (which must be not always privileged - in Falcon for instance) . Lot of GEMDOS traps accessing no any HW registers. It is just way to use short opcode (2 bytes) instead 6 byte jsr (or even more if must pick address from somewhere) and in RAM placed vector, according to current location of OS or expansion code. C64 has lot of jumptables to allow ROM subrutine calls even if change their address in later revisions. Trap is more advanced way for that, indeed.
All it has nothing with cleanness. We need efficiency - this is not kitchen or garden :D What is not clean in OS running in supervisor mode ? Can CPU be interrupted when is in supervisor mode ? So, OS function can be preempted too. I see here lot of confusion in opinions about. And app can run in supervisor too more or less time - what has nothing with thread safety. Safety is discussed here already - memory protection in first place.

I'm thinking about why Desktop accessories were not more used as some main applications - for instance word processing or similar. With that, you could easily switch between apps, without closing any. There is even way of data exchange in AES. Probably it's because not well solved loading of accessories. User needs to place all them in ROOT of disk, and restart - so pretty much not flexible way. DR should solve it better - maybe just adding function to place APPs title in Desktop menu and exit to Desktop - but leaving it in RAM. Then could run other APP, or go back to some already "menuized" one. Of course, there should be option to exit and remove APP completely.
Famous Schrodinger's cat hypothetical experiment says that cat is dead or alive until we open box and see condition of poor animal, which deserved better logic. Cat is always in some certain state - regardless from is observer able or not to see what the state is.
User avatar
shoggoth
Nature
Nature
Posts: 1014
Joined: Tue Aug 01, 2006 9:21 am
Location: Halmstad, Sweden
Contact:

Re: What could Atari have done better with the ST?

Post by shoggoth »

It's fairly obvious that a trap + switch to supervisor mode is slower than a function call, AtariZoll. It needs at ~3 times as many bus accesses, and on the other side is there's the function dispatcher which I can guarantee you is fairly ugly compared to the AmigaOS calling convention, adding even more. It does however mean we got the supervisor switch, which would otherwise have to be added on the "other" side of the call.
Ain't no space like PeP-space.
AtariZoll
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2978
Joined: Mon Feb 20, 2012 4:42 pm
Contact:

Re: What could Atari have done better with the ST?

Post by AtariZoll »

shoggoth wrote:It's fairly obvious that a trap + switch to supervisor mode is slower than a function call, AtariZoll. It needs at ~3 times as many bus accesses, and on the other side is there's the function dispatcher which I can guarantee you is fairly ugly compared to the AmigaOS calling convention, adding even more. It does however mean we got the supervisor switch, which would otherwise have to be added on the "other" side of the call.
Trap # takes 36 cycles. jsr takes 20 . That self is not 3:1 . And if you add cycles to get subroutine address then trap will be faster. I will not go here in how good is solved function dispatcher switch in TOS - we talk about Amiga so called (by some, I really have no opinion about it) multitasking :D
Famous Schrodinger's cat hypothetical experiment says that cat is dead or alive until we open box and see condition of poor animal, which deserved better logic. Cat is always in some certain state - regardless from is observer able or not to see what the state is.
User avatar
galax
Captain Atari
Captain Atari
Posts: 208
Joined: Tue May 27, 2014 5:47 pm
Location: Toronto, Canada

Re: What could Atari have done better with the ST?

Post by galax »

AtariZoll wrote:I'm thinking about why Desktop accessories were not more used as some main applications - for instance word processing or similar. With that, you could easily switch between apps, without closing any.
Multidesk later allowed desk accessories to be loaded and unloaded on the fly, releasing the precious RAM they used, a big deal for many of us before 2MB and 4MB upgrades became more common. If this ability had been there from day 1 they would probably have been used a lot more for suites of applications.
User avatar
shoggoth
Nature
Nature
Posts: 1014
Joined: Tue Aug 01, 2006 9:21 am
Location: Halmstad, Sweden
Contact:

Re: What could Atari have done better with the ST?

Post by shoggoth »

AtariZoll wrote:
shoggoth wrote:It's fairly obvious that a trap + switch to supervisor mode is slower than a function call, AtariZoll. It needs at ~3 times as many bus accesses, and on the other side is there's the function dispatcher which I can guarantee you is fairly ugly compared to the AmigaOS calling convention, adding even more. It does however mean we got the supervisor switch, which would otherwise have to be added on the "other" side of the call.
Trap # takes 36 cycles. jsr takes 20 . That self is not 3:1 . And if you add cycles to get subroutine address then trap will be faster.
You have an additional function dispatcher *after* the trap - which is a subroutine. Which is larger: [subroutine] or [subroutine + trap]?
I will not go here in how good is solved function dispatcher switch in TOS - we talk about Amiga so called (by some, I really have no opinion about it) multitasking :D
EDIT: Oops. I answered your post before reading that last sentence properly. Happy trigger finger.
Last edited by shoggoth on Sun Aug 23, 2015 12:41 pm, edited 1 time in total.
Ain't no space like PeP-space.
User avatar
shoggoth
Nature
Nature
Posts: 1014
Joined: Tue Aug 01, 2006 9:21 am
Location: Halmstad, Sweden
Contact:

Re: What could Atari have done better with the ST?

Post by shoggoth »

EDIT: double post.
Ain't no space like PeP-space.
AtariZoll
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2978
Joined: Mon Feb 20, 2012 4:42 pm
Contact:

Re: What could Atari have done better with the ST?

Post by AtariZoll »

shoggoth wrote: You have an additional function dispatcher *after* the trap - which is a subroutine. Which is larger: [subroutine] or [subroutine + trap]?
...
What comes after trap or jsr depends from how OS is solved, and how much subfunctions should that OS call to serve. But all this hunt for couple cycles and talk what is faster has no sense, really. Such calls are not performed so often, that it will affect speed of running SW. OS is there to perform execution of frequent tasks, and should provide simple and low RAM using way for calling them. And trap is what can it best. If APP needs to seek adress in some tables and similar, that's not good way. This is how I see good OS. Talking about some cleanness, and need for user mode is really not argumented here. Especially in case of Amiga without mainboard support for memory protection in user mode.
Famous Schrodinger's cat hypothetical experiment says that cat is dead or alive until we open box and see condition of poor animal, which deserved better logic. Cat is always in some certain state - regardless from is observer able or not to see what the state is.
joska
Hardware Guru
Hardware Guru
Posts: 4724
Joined: Tue Oct 30, 2007 2:55 pm
Location: Florø, Norway
Contact:

Re: What could Atari have done better with the ST?

Post by joska »

AtariZoll wrote:Joska: you said: "you have an array of function pointers, look up the correct one for the function you want to call and JSR to it."
Look up the correct one - that means in computer terminology to use table and calculate which value to choice. Then you come with: lea librarybase,a6
jsr function(a6) - what is pretty much different - just using constant displacement. Now, that librarybase must be on some constant loc, and that would be ROM only then, so it was not exactly like that. Especially if it should be expandable. So, pointers must be in RAM.
I'm not going to argue about semantics (ref. your definition of "look up"), just point out that I was trying to explain why Workbench' OS functions are not running in Supervisor mode as one poster pointed out. Sure, you could probably TRAP instead of JSR, but why? It doesn't matter if you're in supervisor mode or not, so why force it? And why add a trap handler with a function dispatcher if you don't have to?

Amiga OS function calling is very simple.
AtariZoll wrote:And app can run in supervisor too more or less time - what has nothing with thread safety. Safety is discussed here already - memory protection in first place.
Please start reading more carefully before you post. I have never said that thread-safe has anything to do with supervisor or not. Of course it hasn't. Read again - Workbench can pre-empt any process, even when the process is in the middle of running some OS library function. So the OS library functions must be thread-safe. And this is A Good Thing.
AtariZoll wrote:I'm thinking about why Desktop accessories were not more used as some main applications - for instance word processing or similar.
Desk accessories can't be unloaded, can't have a menu, can't allocate memory (well, you can but won't be freed until a reset) and only works when the main application is waiting inside some evnt_-loop. Nevertheless there were a lot of accessories that tried to replace "proper" applications. The biggest problem was that in a time where the majority of users had 512 or 1024kb you really couldn't multitask anyway. And this is partially why the A500 was such a pain to work with. I have an A600 with 6Mb RAM and a harddrive, now Workbench starts to make sense. Even though the UI is still quite horrible you can atleast work efficiently with multitasking.
Jo Even

VanillaMiNT - Firebee - Falcon060 - Milan060 - Falcon040 - MIST - Mega ST - STM - STE - Amiga 600 - Sharp MZ700 - MSX - Amstrad CPC - C64
User avatar
AdamK
Captain Atari
Captain Atari
Posts: 327
Joined: Wed Aug 21, 2013 8:44 am

Re: What could Atari have done better with the ST?

Post by AdamK »

shoggoth wrote:
AtariZoll wrote:
shoggoth wrote:It's fairly obvious that a trap + switch to supervisor mode is slower than a function call, AtariZoll. It needs at ~3 times as many bus accesses, and on the other side is there's the function dispatcher which I can guarantee you is fairly ugly compared to the AmigaOS calling convention, adding even more. It does however mean we got the supervisor switch, which would otherwise have to be added on the "other" side of the call.
Trap # takes 36 cycles. jsr takes 20 . That self is not 3:1 . And if you add cycles to get subroutine address then trap will be faster.
You have an additional function dispatcher *after* the trap - which is a subroutine. Which is larger: [subroutine] or [subroutine + trap]?
Dispatcher could be implemented as a simple jumptable (it is a jumptable in FreeMiNT) which is not very expensive. There are much more expensive things on OS entry / OS exit to do, so really, TRAP vs. JSR is not the important thing to argue.

The problem (I see) in AmigaOS JSR method, is that, other then Exec, there is no guarantee that a library will be available at the same offset. Some usually are and were, but that changed later on, and some software did not work on more modern AmigaOS versions, because of that, and required patching.

The problem (I see) in TOS, is that there was no clean way to expand the system and add additional functions. This lead to the ugly XBRA standard which, while solves the problem, is an ugly hack and introduces a dispatcher after a dispatcher and so on (FreeMiNT more or less solved it for its extensions, but legacy stuff remains.
Atari: FireBee, Falcon030 + CT60e + SuperVidel + SvEthlana, TT, 520ST + 4MB ST RAM + 8MB TT RAM + CosmosEx + SC1435, 1040STFM + UltraSatan + SM124, 1040STE 4MB ST RAM + 8MB TT RAM + CosmosEx + NetUSBee + SM144 + SC1224, 65XE + U1MB + VBXE + SIDE2, Jaguar, Lynx II, 2 x Portfolio (HPC-006)

Adam Klobukowski [adamklobukowski@gmail.com]
AtariZoll
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2978
Joined: Mon Feb 20, 2012 4:42 pm
Contact:

Re: What could Atari have done better with the ST?

Post by AtariZoll »

joska wrote:[
I'm not going to argue about semantics (ref. your definition of "look up"), just point out that I was trying to explain why Workbench' OS functions are not running in Supervisor mode as one poster pointed out. Sure, you could probably TRAP instead of JSR, but why? It doesn't matter if you're in supervisor mode or not, so why force it? And why add a trap handler with a function dispatcher if you don't have to?
Amiga OS function calling is very simple....
Please start reading more carefully before you post. I have never said that thread-safe has anything to do with supervisor or not. Of course it hasn't. Read again - Workbench can pre-empt any process, even when the process is in the middle of running some OS library function. So the OS library functions must be thread-safe. And this is A Good Thing. ...
Desk accessories can't be unloaded, can't have a menu, can't allocate memory (well, you can but won't be freed until a reset) and only works when the main application is waiting inside some evnt_-loop. Nevertheless there were a lot of accessories that tried to replace "proper" applications. The biggest problem was that in a time where the majority of users had 512 or 1024kb you really couldn't multitask anyway. And this is partially why the A500 was such a pain to work with. I have an A600 with 6Mb RAM and a harddrive, now Workbench starts to make sense. Even though the UI is still quite horrible you can atleast work efficiently with multitasking.
Nothing is simpler than using trap, designed specially for that - OS function call. We talking here about supervisor mode and related. I don't see why you came at all with thread-safe issue. It has nothing with way how function call is solved.
Then, you say me that read more carefully ... and then you start blah about what Desktop ACCessories can not do :mrgreen: Read it again, and you will see that I talked about what Atari/DR should do, and there is even removal from RAM mentioned :D
I don't agree that there was no enough RAM. In 512 KB there is normally some 350 KB free space. Well done SW (ASM for instance) must not use lot of RAM. There are nice utils taking only 10-150 KB RAM.
Famous Schrodinger's cat hypothetical experiment says that cat is dead or alive until we open box and see condition of poor animal, which deserved better logic. Cat is always in some certain state - regardless from is observer able or not to see what the state is.
rabindranath72
Captain Atari
Captain Atari
Posts: 244
Joined: Tue Feb 15, 2011 3:59 pm

Re: What could Atari have done better with the ST?

Post by rabindranath72 »

AdamK wrote: The problem (I see) in AmigaOS JSR method, is that, other then Exec, there is no guarantee that a library will be available at the same offset. Some usually are and were, but that changed later on, and some software did not work on more modern AmigaOS versions, because of that, and required patching.
There's only one fixed address in AmigaOS, I think it was 0x400. All other addresses weren't guaranteed to be the same from one version to the other, but this is clearly documented IIRC. If apps didn't work anymore, the fault was of the developer who didn't follow Commodore's recommendations.
joska
Hardware Guru
Hardware Guru
Posts: 4724
Joined: Tue Oct 30, 2007 2:55 pm
Location: Florø, Norway
Contact:

Re: What could Atari have done better with the ST?

Post by joska »

AtariZoll wrote:We talking here about supervisor mode and related. I don't see why you came at all with thread-safe issue. It has nothing with way how function call is solved.
Let me quote myself:
A nice sideeffect of this strategy (pre-empt not only user code, but also the OS functions) is that the OS *has* to be cleanly written, as the OS itself will be pre-empted. So everything must be thread-safe. Which is something no TOS has ever been remotely close to be.
I had the impression that we were discussing whether Workbench was pre-emptive or not. But apparently not anymore :D

Anyway, please bear in mind that Exec is (or atleast attempts to be) a microkernel. Treating as much as possible of the OS as subroutines is exactly the point. While supervisor/user really doesn't matter much in the Amiga, it makes a difference in 68000 designs in general. And Workbench was not Commodore's invention, it's an adaption of an already existing 68000 OS.
AtariZoll wrote:Then, you say me that read more carefully ... and then you start blah about what Desktop ACCessories can not do :mrgreen: Read it again, and you will see that I talked about what Atari/DR should do, and there is even removal from RAM mentioned :D
I did not comment your suggested improvements, it was a response to this:
AtariZoll wrote:I'm thinking about why Desktop accessories were not more used as some main applications - for instance word processing or similar.
Maybe I misunderstood you. Anyway, Geneva proved already in the early 90's that GEM applications can be multitasked, even though it's "just" cooperative multitasking. Atari could have done this themselves if they had the time and resources. Or foresight!
AtariZoll wrote:I don't agree that there was no enough RAM. In 512 KB there is normally some 350 KB free space. Well done SW (ASM for instance) must not use lot of RAM. There are nice utils taking only 10-150 KB RAM.
Most software was *not* written in assembler, and a lot of software really needed most of the available megabyte for itself. It doesn't matter if the instructions are few if they handle "large" data. The Amiga suffered badly from this, together with the disk swapping *hell* when you attempted to actually multitask on a plain 500. The ST was much better in it's stock form. Yes, the OS was simpler and quite badly implemented, but it was much more usable in real life when you were a poor student with a plain 1040. However, Workbench became much better later on when users could afford RAM-expansions and mass storage. TOS really didn't improve much.

Anyway, it's refreshing to see that you've changed your mind about multitasking. Not that long ago you deemed the ST unsuitable for that :)
Jo Even

VanillaMiNT - Firebee - Falcon060 - Milan060 - Falcon040 - MIST - Mega ST - STM - STE - Amiga 600 - Sharp MZ700 - MSX - Amstrad CPC - C64
AtariZoll
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2978
Joined: Mon Feb 20, 2012 4:42 pm
Contact:

Re: What could Atari have done better with the ST?

Post by AtariZoll »

I did not say that TOS is suitable or not for multitasking. After all, they worked on MultiTOS around 1992. Things are, that I did not miss it when I worked on Atari. For programming with good development SW it was really not necessary. And I had lot of RAM already in 1988.
Actually, my idea about diverse way of using ACCessories was realized in task switchers - like Twist. But I never used it, just tried once.

After all posts about Amiga, multitasking, supervisot/user blah, let me summarize my opinion on topic:

1. HW fine scroll like in STE - so video base possible at any even address, + support for pixelwise hor. shift in range 1-15 px . That would need only some + logic and registers in shifter and MMU.

2. Universal expansion bus - with complete CPU bus, other relevant signals, so can attach RAM expansions, hard disk adapters, video cards etc ...

3. Better TOS - maybe best and not to complicated improvement would be better and easier usable load of resident SW (called Desktop ACCessories as it was done) - so it could be more of in RAM (max 6 ACCessory was possible at once) , and then could simply switch between with mouse or some hotkeys.
Concrete realization would mean that regular AES APP can be started in normal way, but there should be extra option to exit to Desktop without terminating it. And there must be point in code where reenter leads. Additionally, some hotkeys handled by OS would make APP switch even easier.
Unlike Joska, I think that it would be most useful for people without hard disks, to avoid slow floppy loads and swaps.
Famous Schrodinger's cat hypothetical experiment says that cat is dead or alive until we open box and see condition of poor animal, which deserved better logic. Cat is always in some certain state - regardless from is observer able or not to see what the state is.
AtariZoll
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2978
Joined: Mon Feb 20, 2012 4:42 pm
Contact:

Re: What could Atari have done better with the ST?

Post by AtariZoll »

This thread is so boring without some screenshots, so I feel need to post some:
ACCramfree1.png
ACCramfree2.png
ACCramfree3.png
ACCramfree4.png
Did it with TOS 2.06 just because it has opt. to show free RAM, same is in all other TOS versions. After removing RDISK (3rd pic) there is again all RAM available, and no restart was used. Someone here said: " can't have a menu, can't allocate memory (well, you can but won't be freed until a reset) "
Even about menu is wrong - I see nice menu on screenshot :D OK, Joska probably meant drop down menu. That would be little harder with ACCs, but possible. However, my point was that instead ACC could be some better system, and then every APP could have own drop down menu as usual.
You do not have the required permissions to view the files attached to this post.
Famous Schrodinger's cat hypothetical experiment says that cat is dead or alive until we open box and see condition of poor animal, which deserved better logic. Cat is always in some certain state - regardless from is observer able or not to see what the state is.
User avatar
qq1975b
Atari God
Atari God
Posts: 1111
Joined: Tue May 15, 2012 9:15 am
Location: Barcelona

Re: What could Atari have done better with the ST?

Post by qq1975b »

Sprite controller makes sense besides the hardware scrolling?
Trying to learn...
joska
Hardware Guru
Hardware Guru
Posts: 4724
Joined: Tue Oct 30, 2007 2:55 pm
Location: Florø, Norway
Contact:

Re: What could Atari have done better with the ST?

Post by joska »

AtariZoll wrote:Did it with TOS 2.06 just because it has opt. to show free RAM, same is in all other TOS versions. After removing RDISK (3rd pic) there is again all RAM available, and no restart was used. Someone here said: " can't have a menu, can't allocate memory (well, you can but won't be freed until a reset) "
Of course, "anything" is possible if you invent your own way of doing it. A brilliant way of preventing your stuff from working with future versions of the OS.

Accessories can't be unloaded under any TOS. Yes, you can use hacks like Chameleon that does this for you. I used it for a long time.
Also, memory allocated (and by that I mean allocated properly using Malloc, not by questionable hacking) by a desk accessory is never freed under TOS < 2. If you do a resolution change that memory will be lost - a reset is required. TOS 2.x was the first TOS that handled this situation correctly.
AtariZoll wrote:Even about menu is wrong - I see nice menu on screenshot :D OK, Joska probably meant drop down menu. That would be little harder with ACCs, but possible.
Not possible to do cleanly with any currently existing TOS. Geneva, MagiC, N.AES, XaAES and (maybe?) MyAES handle accessories like any other application and might allow this. But the desk accessory concept is rather meaningless under these systems.
AtariZoll wrote:However, my point was that instead ACC could be some better system, and then every APP could have own drop down menu as usual.
Why not just do what Geneva did with great success and allow normal GEM-apps to run concurrently? Geneva proved that this is not only possible but actually works brilliantly with little RAM usage. If Atari had done this *and* bundled every ST with proper development tools it would have had great impact on this platform.
Jo Even

VanillaMiNT - Firebee - Falcon060 - Milan060 - Falcon040 - MIST - Mega ST - STM - STE - Amiga 600 - Sharp MZ700 - MSX - Amstrad CPC - C64
AtariZoll
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2978
Joined: Mon Feb 20, 2012 4:42 pm
Contact:

Re: What could Atari have done better with the ST?

Post by AtariZoll »

Joska, you forgetting about what this thread is. I just gave example for something better than existing ACC system. So, really no need to talk here about Geneva etc - they came later, so really pointless. Especially when you are wrong about some simple features.
I had TOS 1.00 when wrote that CopyACC, and used Malloc in middle of ACC to allocate RAM for RAMdisk, and of course used regular memfree by it's removal. So , ACC self can not be removed (that's TOS/AES design flaw), but allocated RAM by code in ACC can be simply removed by regular memfree.
Your first sentence is really something what you should not write - pure assumption, based on nothing. And for me it just means that you are not so good programmer as may think Not knowing some simple things well, but continue discussion instead checking it - what can be done really in short time.
I did nothing in my own way, used regular TOS and AES calls. Only floppy R/W is done via low level FDC access, because I was not happy with XBIOS 8/9 speed.
Famous Schrodinger's cat hypothetical experiment says that cat is dead or alive until we open box and see condition of poor animal, which deserved better logic. Cat is always in some certain state - regardless from is observer able or not to see what the state is.
User avatar
mfro
Atari Super Hero
Atari Super Hero
Posts: 856
Joined: Thu Aug 02, 2012 10:33 am
Location: SW Germany

Re: What could Atari have done better with the ST?

Post by mfro »

AtariZoll wrote:...I had TOS 1.00 when wrote that CopyACC, and used Malloc in middle of ACC to allocate RAM for RAMdisk, and of course used regular memfree by it's removal
That's asking for serious trouble, IMHO. In all TOS versions.

My understanding is that GEMDOS doesn't know nothing about accessories.

Thus, if you Malloc() from an accessory, the memory will be owned by the currently active foreground application.
GEMDOS will happily free that memory once that application is quit and assign it to another process that requests it later on.

You'll end up in a mess.

You might get away with blocking AES task switching (wind_update()) between Malloc() and Mfree()) and 'borrow' memory from the foreground application for a short time, but that's not what I'd call clean coding.
AtariZoll
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2978
Joined: Mon Feb 20, 2012 4:42 pm
Contact:

Re: What could Atari have done better with the ST?

Post by AtariZoll »

Yes, GEMDOS does not know about ACC. Malloc just reserves asked amount of RAM at start of available space. It is not tied to any APP or ACC . When do memfree you refer to it by simply giving it's start address.
You are probably confused by fact that when some APP is started, all free RAM is allocated to it, regardless from how big is it's bss in PRG header.
So, if I would try to install RAMdisk in CopyACC in middle of running some AES APP, which did not memshrink at start it would not work, because no free RAM then. If it performed Mshrink, then malloc will get space not after ACC, but after running APP, but that does not mean that it is tied to that APP, it is just because order of RAM allocations performed. Of course, that's not recommended way of usage, since there will be hole in RAM after exiting APP.
But that's common problem, usually in multitasking environments.
Too bad that no Simbo to add "something" here :mrgreen:
Famous Schrodinger's cat hypothetical experiment says that cat is dead or alive until we open box and see condition of poor animal, which deserved better logic. Cat is always in some certain state - regardless from is observer able or not to see what the state is.
User avatar
shoggoth
Nature
Nature
Posts: 1014
Joined: Tue Aug 01, 2006 9:21 am
Location: Halmstad, Sweden
Contact:

Re: What could Atari have done better with the ST?

Post by shoggoth »

I'm under the impression that GEMDOS memory allocated by a process, is owned by that process. When the process exists, memory allocated by that process is freed too, unless terminating using ptermres().
Ain't no space like PeP-space.
joska
Hardware Guru
Hardware Guru
Posts: 4724
Joined: Tue Oct 30, 2007 2:55 pm
Location: Florø, Norway
Contact:

Re: What could Atari have done better with the ST?

Post by joska »

AtariZoll wrote:Yes, GEMDOS does not know about ACC. Malloc just reserves asked amount of RAM at start of available space. It is not tied to any APP or ACC . When do memfree you refer to it by simply giving it's start address.
Correct. Allocated memory blocks are not "owned" by an AES process, because there is no such thing as an AES process. However, the allocated memory is owned by it's GEMDOS process. How else can TOS know which memory blocks to free when a process terminates?

In plain TOS there is only one active GEMDOS process, and that is the currently running application/program. A desk accessory is *not* a GEMDOS process. Any memory allocated by it will belong to the GEMDOS process that was active at the time of allocation. So when that process is terminated it will also free any memory allocated by accessories.
TOS 3 release notes wrote: Memory allocated by a DA is actually owned by the GEMDOS process that is running when the application (the DA) makes the Malloc call. When that process terminates, GEMDOS will free the memory. Previously, the AES was not always getting AC_CLOSE messages to DAs until after a program had already terminated, and all of its resources freed. Now, a DA can be assured that it will receive the AC_CLOSE message before the application terminates, so any memory that it has allocated will not already be invalidated at AC_CLOSE time.
(http://dev-docs.atariforge.org/files/TT ... 6-1991.pdf)

Your ramdisk is safe, as long as it allocates memory while the ROM desktop is active so it's memory will be valid as long as the desktop isn't terminated. This happens only when changing resolution. Before TOS 2 the ROM desktop was not a GEMDOS process and was never really terminated, so when the user issued a resolution change the RAM allocated by desk accessories would be "lost" when the DA got restarted.

However, if your ramdisk for some reason allocates memory while another application is running the ramdisk will be invalidated as soon as that application exits to the desktop.

Looks like we don't need Simbo...
Jo Even

VanillaMiNT - Firebee - Falcon060 - Milan060 - Falcon040 - MIST - Mega ST - STM - STE - Amiga 600 - Sharp MZ700 - MSX - Amstrad CPC - C64
Locked

Return to “Chat forum [ENG]”