TOS after 32 years - what could be done better ?

News,announcements,programming,fixes,game patches & discussions.

Moderator: Petari

Petari
Software Moderator
Software Moderator
Posts: 538
Joined: Tue Nov 28, 2017 1:32 pm

Re: TOS after 32 years - what could be done better ?

Post by Petari » Thu Dec 21, 2017 2:46 pm

I think that we should hear the other side too - what means someone from Digital Research . And that would be what Exxos meant.
Is that Mike Fulton one of DRI people ?
Anyway, that Landon writing was really great read.
There is 2 kind of people: one thinking about moving to Mars after here becomes too bad, the others thinking about how to keep this planet habitable.

User avatar
exxos
Site Admin
Site Admin
Posts: 3925
Joined: Wed Aug 16, 2017 11:19 pm
Location: UK
Contact:

Re: TOS after 32 years - what could be done better ?

Post by exxos » Thu Dec 21, 2017 2:52 pm

Petari wrote:
Thu Dec 21, 2017 2:46 pm
I think that we should hear the other side too - what means someone from Digital Research . And that would be what Exxos meant.
yes, I have sent an email..
Petari wrote:
Thu Dec 21, 2017 2:46 pm
Is that Mike Fulton one of DRI people ?
I am not sure what his background was, I think he was one of the people who worked on the Atari compendium book ?
4MB STFM 1.44 FD- VELOCE+ 020 STE - 4MB STE 32MHz - STFM 16MHz - STM - MEGA ST - Falcon 030 CT60 - Atari 2600 - Atari 7800 - Gigafile - SD Floppy Emulator - PeST - HxC - CosmosEx - Ultrasatan - various clutter

https://www.exxoshost.co.uk/atari/ All my hardware guides - mods - games - STOS
https://www.exxoshost.co.uk/atari/last/storenew/ - All my hardware mods for sale - Please help support by making a purchase.

User avatar
arf
Posts: 66
Joined: Sun Oct 29, 2017 9:30 am

Re: TOS after 32 years - what could be done better ?

Post by arf » Thu Dec 21, 2017 8:43 pm

exxos wrote:
Thu Dec 21, 2017 2:35 pm
arf wrote:
Thu Dec 21, 2017 2:30 pm
I posted the link to Landon’s web site. He’s been part of the team for TOS.
Okay thanks, I did talk to him about something a few months ago in fact...

I have not fully read all the posts yet, as I am really busy and have a lot of catching up to do yet...
His two posts (995 and 1000) are really nice to read and give an insight on how TOS was developed. Of course it is only one perspective, but as these are rare anyway, it is way better than nothing.

Also worth a read: How the Atari ST almost had Real Unix and Madmac and assemblers
--
Against signature spam!

Petari
Software Moderator
Software Moderator
Posts: 538
Joined: Tue Nov 28, 2017 1:32 pm

Re: TOS after 32 years - what could be done better ?

Post by Petari » Tue Dec 26, 2017 9:42 am

I looked for the first time little better into Hitchiker's Guide to the BIOS. There are diverse revisions online. Some are really hard even to read because bad formatting. I think that best is what is on DrCoolZic's site - there are some highlighted parts, comments. Revision 1.1 is from 1990.
Probably most interesting is right at beginning:
"For many reasons this should still be considered a preliminary document. A whole host of things remain undocumented, many GEMDOS issues have not
even been approached by our friends at Digital Research, and there are a whole lot of features we'd like to add to the software. "
And that explains a lot. It remained preliminary until Atari bankrupted - that's my guess. Yes, I know that SW is something what is never really finished. But they just never made proper documentation for existing TOS versions.
I mentioned in other thread error in ACSI code example.

Why we need detailed docs ? We even should not question it. That's elementary. An example:

"8.22.17 ICONBLK

typedef struct
{
uint16_t *ib_pmask; /* Pointer to the icon mask */
uint16_t *ib_pdata; /* Pointer to the icon image */
int8_t *ib_ptext; /* Pointer to the icon text */
uint16_t ib_char; /* Character that is to appear in the
icon, as well as the foreground
and background colour of the Icon */
uint16_t ib_xchar; /* X-coordinate of the character */
uint16_t ib_ychar; /* Y-coordinate of the character */
uint16_t ib_xicon; /* X-coordinate of the icon */
uint16_t ib_yicon; /* Y-coordinate of the icon */
uint16_t ib_wicon; /* Width of the icon */
uint16_t ib_hicon; /* Height of the icon */
int16_t ib_xtext; /* X-coordinate of the text */
int16_t ib_ytext; /* Y-coordinate of the text */
uint16_t ib_wtext; /* Width of the text */
uint16_t ib_htext; /* Height of the text */
uint16_t ib_resvd; /* Reserved */
} ICONBLK; "

For good explanation about icon color It should be (after ib_text) :
byte ib_col; /* Icon and background color
byte ib_char; /* Character that is to appear in the icon
Or, if it must be word:
uint16_t ib_colchar - then exact explanation of what is there, in what exact order .

In my ProfiBuch there is no word about color of icon in ICONBLK struct. I don't know what was their source in 1987, but you may guess :D
There is 2 kind of people: one thinking about moving to Mars after here becomes too bad, the others thinking about how to keep this planet habitable.

Petari
Software Moderator
Software Moderator
Posts: 538
Joined: Tue Nov 28, 2017 1:32 pm

Re: TOS after 32 years - what could be done better ?

Post by Petari » Sun Jan 07, 2018 10:12 am

TOS is clearly divided into 2 parts:
1 - HW initialization (like RAM test ++), BIOS, XBIOS, GEMDOS and even VDI, Line-A calls, mouse, then basic font, VT52 emulator are in first part. About 90KB ,
2 - AES (GEM) and Desktop .
That may be surprise by self for some (was for me too. when I realized it), but even more surprising is that VDI, Line-A, mouse is not initialized before AES start. AUTO run SW, what want to use them must perform proper init. self. Now, that would be another case of 'who to blame for not knowing it ?' . Because there is plenty of SW, mostly games needing start from Desktop, as PRG and not TOS, just because it needs mouse or VDI. While it could work perfectly from AUTO folder, and having some 30KB more free RAM .

Wasted RAM space: TOS sets base address for usable RAM space at very early stage - before boot. That start address is actually address after AES workspace. For instance in TOS 1.04 it is $A84E, while first address after GEMDOS workspace is $611C . AUTO folder run SW will load therefore to address about $A856 in TOS 1.04, and area between $611C and $A84E is simply wasted. I see this as simply laziness of TOS coders.
That motivated me to do corrected TOS versions: viewtopic.php?f=39&t=499
It corrects one more thing, what I don't like - why PRG extension for SW in AUTO folder, when then can not run GEM (AES calling) SW ? It should be TOS.
There is 2 kind of people: one thinking about moving to Mars after here becomes too bad, the others thinking about how to keep this planet habitable.

User avatar
arf
Posts: 66
Joined: Sun Oct 29, 2017 9:30 am

Re: TOS after 32 years - what could be done better ?

Post by arf » Sun Jan 07, 2018 11:55 am

Petari wrote:
Sun Jan 07, 2018 10:12 am
TOS is clearly divided into 2 parts:
1 - HW initialization (like RAM test ++), BIOS, XBIOS, GEMDOS and even VDI, Line-A calls, mouse, then basic font, VT52 emulator are in first part. About 90KB ,
2 - AES (GEM) and Desktop .
That may be surprise by self for some (was for me too. when I realized it), but even more surprising is that VDI, Line-A, mouse is not initialized before AES start. AUTO run SW, what want to use them must perform proper init. self.
I am not sure whether I got that right – you’re saying that the VDI is only initialized when AES starts? Can’t agree here, as it is perfectly fine to use VDI without a started AES, e.g. in the AUTO folder, you just have to open your VDI workstation properly, as documented.
--
Against signature spam!

Petari
Software Moderator
Software Moderator
Posts: 538
Joined: Tue Nov 28, 2017 1:32 pm

Re: TOS after 32 years - what could be done better ?

Post by Petari » Sun Jan 07, 2018 12:45 pm

You just need to use Open Workstation (VDI 1) instead Open Virtual Workstation (VDI 100) in case of AUTO folder.
Now, how I know it ? Not because some DOC, I experienced it out.
So arf, pls. tell us in which doc it is described, and from which year it is.
There is 2 kind of people: one thinking about moving to Mars after here becomes too bad, the others thinking about how to keep this planet habitable.

User avatar
arf
Posts: 66
Joined: Sun Oct 29, 2017 9:30 am

Re: TOS after 32 years - what could be done better ?

Post by arf » Mon Jan 08, 2018 12:08 am

Petari wrote:
Sun Jan 07, 2018 12:45 pm
You just need to use Open Workstation (VDI 1) instead Open Virtual Workstation (VDI 100) in case of AUTO folder.
Now, how I know it ? Not because some DOC, I experienced it out.
So arf, pls. tell us in which doc it is described, and from which year it is.
Atari Profibuch, Jankowski / Rabich / Reschke, 11th edition [1992], section "VDI", paper page 330, PDF page 363, second paragraph:
Sollte es sich um einen Bildschirmtreiber so wird der Grafik-Modus gestartet. Im Normalfall sind es die AES, die die Bildschirm-Workstation für sich öffnen. Anwendungsprogramme müssen daher virtuelle Workstations öffnen. Nur wenn die AES noch nicht aktiv sind (während der Abarbeitung des AUTO-Ordners) ist es möglich, Bildschirm-Workstations zu öffnen.
(mach-trans:)
If it is a display driver then the graphics mode is started. Normally, it is the AES that opens the screen workstation for themselves. Application programs must therefore open virtual workstations. Only when the AES are not active (during the AUTO folder processing) is it possible to open screen workstations.
(Italic by me)

Atari Compendium, Sanders, [1992], section "VDI", section number 7.3 – not as clear as above, but also states it:
Physical Workstations
Each device must be initialized by opening its physical workstation. Opening a physical workstation causes all drawing and clipping attributes to be reset and the current page (display) to be reset to the default background color. Only one physical workstation may be opened to a single device at any given time. The screen device’s physical workstation is automatically initialized by the AES upon bootup.
GEM Programmer's Guide Volume 1: VDI 3rd Edition [Jan 1989], Appendix J, PDF page 278:
NOTE:
You may only have one physical workstation opened to the screen. But multiple physical workstations can be opened to other devices.
[…] In the case of the screen, a graf_handle call will return the currently opened AES physical workstation handle. […] An application can use this physical handle to open virtual workstations. […]
NVDI programmer’s documentation, Sven & Wilfried Behne, [1999], section 2.5.1 OPEN WORKSTATION (VDI 1):
Wichtig: Der Bildschirmtreiber wird nach Abarbeitung des AUTO-Ordners vom AES geöffnet. Anwenderprogramme müssen daher zur Bildschirmausgabe eine virtuelle Workstation (VDI 100) öffnen.
(mach-trans:)
Important: The display driver will be opened by the AES after the AUTO folder has been processed. User programs must therefore open a virtual workstation (VDI 100) for screen output.
AMC-GDOS Version 3.10 Release Notes und Dokumentation, Arnd Beissner [1987]:
Die physikalische Bildschirm-Workstation wird beim Systemstart vom AES geöffnet. […] Eine virtuelle Workstation wird immer auf ein physikalisches Gerät abgebildet. Da man virtuelle Workstations nur auf dem Bildschirm öffnen kann, handelt es sich bei dem Gerät immer um den Bildschirm. Die Benutzung des Bildschirms von mehreren Programmen gleichzeitig ist auch nur deshalb sinnvoll, weil das AES mit seinen Fenster-Verwaltungs-Mechanismen Hilfsmittel zur Verfügung stellt, die verhindern, daß auf dem Bildschirm Chaos entsteht.

Wenn man eine virtuelle Workstation öffnen möchte, muß man dem VDI *immer* mitteilen, auf welchem Gerät das geschehen soll. Dazu muß man das Handle der physikalischen Workstation kennen. Da das AES diese geöffnet hat, muß man das Handle auch beim AES erfragen. Dazu verwendet man den AES-Aufruf graf_handle.
Vom Anfänger zum GEM-Profi, Geiß & Geiß [1991], paper page 46, PDF page 45:

Code: Select all

if (device==SCREEN)
{
    if (from_desktop)
    {
        appl_init () ;
        vdi_handle =graf_handle (&i,&i,&i, &i);
        v_opnvwk (work_in, &vdi_handle, work_out); /* virt. öffnen */
        graf_mouse (M_0FF, NULL);
    }
    else
    {
        v_opnwk (work_in, &vdi_handle, work_out); /* phys. öffnen */
        v_hide_c (vdi_handle);
    } /*else*/
    screen_w = work_out [0] + 1;
    screen_h = work_out [1] + 1;
} /* if */
else
    v_opnwk (work_in, &vdi_handle, work_out);
[…]
--
Against signature spam!

Petari
Software Moderator
Software Moderator
Posts: 538
Joined: Tue Nov 28, 2017 1:32 pm

Re: TOS after 32 years - what could be done better ?

Post by Petari » Mon Jan 08, 2018 7:54 am

Well, nice long list :D Thank you for it, but really should not spend so much time with it. 1-2 would be enough.
This basically confirms what I think: official Atari docs are not detailed enough. Programmers were often in situation to figure out solutions self.
So was it with usage of VDI - some solved it via Desktop start, some figured out self what is proper way for AUTO run SW. Some were lucky, and had better literature, but that was mostly in later years.
I really think that my previous text was perfectly clear. Maybe for someone is not clear why we need to blame Atari/DRI for poor documentation now. Well, better later than never :D It is just that I never thought that it can be so bad. Now I see much better why so many SW is written with some bad solutions.
There is 2 kind of people: one thinking about moving to Mars after here becomes too bad, the others thinking about how to keep this planet habitable.

User avatar
arf
Posts: 66
Joined: Sun Oct 29, 2017 9:30 am

Re: TOS after 32 years - what could be done better ?

Post by arf » Mon Jan 08, 2018 11:19 am

Petari wrote:
Mon Jan 08, 2018 7:54 am
Well, nice long list :D Thank you for it, but really should not spend so much time with it. 1-2 would be enough.
This basically confirms what I think: official Atari docs are not detailed enough. Programmers were often in situation to figure out solutions self.
So was it with usage of VDI - some solved it via Desktop start, some figured out self what is proper way for AUTO run SW. Some were lucky, and had better literature, but that was mostly in later years.
I really think that my previous text was perfectly clear. Maybe for someone is not clear why we need to blame Atari/DRI for poor documentation now. Well, better later than never :D It is just that I never thought that it can be so bad. Now I see much better why so many SW is written with some bad solutions.
Atari is for sure to blame for incomplete documentation, I agree. But – this concrete example is actually covered by Atari documentation, as I listed it above: “GEM Programmer's Guide Volume 1: VDI 3rd Edition [Jan 1989], Appendix J, PDF page 278”, this is official Atari docs.

As a programmer, I felt never really felt 'left alone in the dark cold' back then. Sure, Atari did not deliver sufficient support (that changed over time), and I couldn’t afford the official Developer package.

But we had in two ST magazines excellent authors describing how to program in a clear, compatible way ("ST-Magazin/68000" and "ST-Computer"). “Everyone” bought the Profibuch (covering basically everything), and most of us Geiß&Geiß (mostly AES, a bit VDI), and many 'Scheibenkleister' (storage-focussed). That covered large parts until the very early 90ies. Then BBS networks popped up, and a lot of good stuff was there. TOS.HYP came up, and the Compendium.

We never really had the problem that we couldn’t get information on 'what-was-there'. Instead, we always had the problem 'it-is-not-enough-what-is-there' – in terms of solutions, not docs. As an example, friends of mine invented and implemented OLGA (Object linking for GEM applications) back then, in a 'WWDC' consisting of 6 people, to define stuff that Atari never did. OTOH, it was fun, and we could do it, so we did. And it worked.
--
Against signature spam!

Post Reply