Has anyone...

GFA, ASM, STOS, ...

Moderators: exxos, simonsunnyboy, Mug UK, Zorro 2, Moderator Team

Nev (Orbital Software)
Obsessive compulsive Atari behavior
Obsessive compulsive Atari behavior
Posts: 128
Joined: Thu Nov 25, 2004 8:50 pm
Location: Basingstoke (ex Birmingham)
Contact:

Has anyone...

Postby Nev (Orbital Software) » Mon Jan 17, 2005 1:28 am

...ever coded a Low/Med/Hi resolution overscan for anything useful other than demo screens?

The reason I ask is that plenty of people know how to do them, but no-one seems to have used an overscan to create a bigger useful workspace for an application? Not that i'm aware of anyway.

Imagine your desktop in Med-res if you had no borders, imagine all that extra workspace. The potential for full screens/or just top & bottom border removal has never really been put to anything useful other than to show off routines in demos etc.

I'm interested to know peoples views on this(from both a technical coders view and anyone elses points).

After some thought on this, the only border removal i've seen that is used to good effect is on Trackers like Protracker where the bottom border is removed which is a big help in creating less clutter on screen.

Also, what is stopping anyone from creating a routine to remove any(if not all) borders on a standard ST/E desktop?

Discuss.

:D

Peace...
-=0rB17@l 50f7w@R3=-

havoc
Captain Atari
Captain Atari
Posts: 213
Joined: Sun Jul 11, 2004 9:05 am

Postby havoc » Mon Jan 17, 2005 6:45 am

some diskmags use borders for the control section, so do some paintprogs... but these are all application-specific solutions which quite often don't work on all imagineable hardware.

besides that, i guess the main reasons why software overscan never got really popular are that it takes cpu time by the truckload while there is a (relatively) cheap and effective hardware solution for the same problem (by the oh-so imaginative name "OverScan").

User avatar
unseenmenace
Atari God
Atari God
Posts: 1961
Joined: Tue Sep 21, 2004 9:33 pm
Location: Margate, Kent, UK
Contact:

Postby unseenmenace » Mon Jan 17, 2005 8:52 am

A friend of mine is currently hacking apart TOS and GEM with a view to he and I adding some enhancements. One of which will almost certainly be top and bottom border removal in GEM. Other planned enhancements are:-

Possibly full overscan in GEM depending on how well we can optimise other parts of GEM, i.e if we can make it run fast enough to be useable

Super fast optimised GEM drawing routines for all 3 ST resolutions

Ability to switch from Colour to Mono in the same way you would switch from Low to Med res without rebooting

User defined icons, fonts and mouse pointers

Interlace support built into GEM desktop (probably STE only as its really easy to do on an STE)

Movable dialogues and alert boxes

Enhanced File Selector (along the lines of UIS III)


Feel free to post or email any questions or suggestions
UNSEEN MENACE
Several STFM's, 4MB STE, 2MB TT with 1.2GB Hard Drive and 14MB Falcon with 540MB Hard Drive,
Lynx 2 and Jaguar with JagCD
Member of GamebaseST and AtariLegend team
Check out my website at http://unseenmenace.110mb.com

User avatar
Nyh
Atari God
Atari God
Posts: 1496
Joined: Tue Oct 12, 2004 2:25 pm
Location: Netherlands

Re: Has anyone...

Postby Nyh » Mon Jan 17, 2005 10:31 am

Nev (Orbital Software) wrote:...ever coded a Low/Med/Hi resolution overscan for anything useful other than demo screens?

Imagine your desktop in Med-res if you had no borders, imagine all that extra workspace. The potential for full screens/or just top & bottom border removal has never really been put to anything useful other than to show off routines in demos etc.

After some thought on this, the only border removal i've seen that is used to good effect is on Trackers like Protracker where the bottom border is removed which is a big help in creating less clutter on screen.

Also, what is stopping anyone from creating a routine to remove any(if not all) borders on a standard ST/E desktop?


For overscan on the desktop we have Autoswitch Overscan hardware (http://www.stcarchiv.de/stc1990/07_overscan.php). It extends resolutions to 400x280 low, 816x280 med and 720x480 high. For most stuff it is of little or no use because lots of programs assume the standard resolutions (that's why it is autoswitch: it switches back to non overscan on programs that don't work). For well writen GEM programs it is great. I have used it for years while programming with Pure C. I almost never used in in medium or low res (I used lowres for games, demo's and drawing only, all other stuf I did in ST high, even demo and game coding: the game or demo switches to ST low at the initialisation and back to ST high at the end, no need for changing plugs with a switchbox, my monitors didn't die from wrong signals, they just didn't produce a picture).

You might get fullscreen in GEM by giving the processor free during the VBL and only responding to interrupts (keyboard!) during screendisplay time. But you wouldn't get a usefull system. (In an other thread I did give you a calculation for time needed for a fullscreen on interrupts basis, for GEM programs you have to assume worst case timings for instructions (158 for a div) and because of the worst case timing resyncing gets a bit harder too!

Removing the lowerborder is possible in GEM but even that is hard to get stable (disk access will kill it).

Maybe we should add autoswitch overscan hardware to a ST emulator.

But first of all Nev, open the border yourself and try to understand the problems that go with it. (I more and more get the feeling that my prejudice against STOS coders isn't just a prejudice.)

Nyh

Nev (Orbital Software)
Obsessive compulsive Atari behavior
Obsessive compulsive Atari behavior
Posts: 128
Joined: Thu Nov 25, 2004 8:50 pm
Location: Basingstoke (ex Birmingham)
Contact:

Re: Has anyone...

Postby Nev (Orbital Software) » Mon Jan 17, 2005 3:08 pm

Nyh wrote:
Nev (Orbital Software) wrote:...ever coded a Low/Med/Hi resolution overscan for anything useful other than demo screens?

Imagine your desktop in Med-res if you had no borders, imagine all that extra workspace. The potential for full screens/or just top & bottom border removal has never really been put to anything useful other than to show off routines in demos etc.

After some thought on this, the only border removal i've seen that is used to good effect is on Trackers like Protracker where the bottom border is removed which is a big help in creating less clutter on screen.

Also, what is stopping anyone from creating a routine to remove any(if not all) borders on a standard ST/E desktop?


For overscan on the desktop we have Autoswitch Overscan hardware (http://www.stcarchiv.de/stc1990/07_overscan.php). It extends resolutions to 400x280 low, 816x280 med and 720x480 high. For most stuff it is of little or no use because lots of programs assume the standard resolutions (that's why it is autoswitch: it switches back to non overscan on programs that don't work). For well writen GEM programs it is great. I have used it for years while programming with Pure C. I almost never used in in medium or low res (I used lowres for games, demo's and drawing only, all other stuf I did in ST high, even demo and game coding: the game or demo switches to ST low at the initialisation and back to ST high at the end, no need for changing plugs with a switchbox, my monitors didn't die from wrong signals, they just didn't produce a picture).

You might get fullscreen in GEM by giving the processor free during the VBL and only responding to interrupts (keyboard!) during screendisplay time. But you wouldn't get a usefull system. (In an other thread I did give you a calculation for time needed for a fullscreen on interrupts basis, for GEM programs you have to assume worst case timings for instructions (158 for a div) and because of the worst case timing resyncing gets a bit harder too!

Removing the lowerborder is possible in GEM but even that is hard to get stable (disk access will kill it).

Maybe we should add autoswitch overscan hardware to a ST emulator.

But first of all Nev, open the border yourself and try to understand the problems that go with it. (I more and more get the feeling that my prejudice against STOS coders isn't just a prejudice.)

Nyh


Fair points, i'm just curious about all aspects of Border removal at the moment, this is nothing to do with coding, more a case of why people never used the border removal technique for anything constructive(bar the odd exceptions) and wanted a full breakdown of the reasons.

I understand the principals of how it works quite easily(it's not rocket science), it's getting it actually working thats the difficult part. I'm gonna have a crack at it when i've got a reasonable knowledge of ASM(only just starting to learn it(again)). Hopefully i'll have something running in a few months.

The reason I ask so many questions about it is simply for the fact that if I can't do what I want to do in a fullscreen then there is no point in me trying to code one in the first place. Knowledge is power and the more knowledge I can collate the better position I will be in when it comes to coding. Thats just being sensible and doing my research.

Also, my above post was nothing to do with "ME" coding, it was purely for curiosity puposes, but your comments and points are useful and have added them to all the other fullscreen topics for when I do come to coding one. Remember, I used to code a little assembly in 94/5, but that was it. The only thing my ST has done between 1996-2004 is watch demos and use Tracker software as part of my studio. I've only just started getting back into things(hence my forum joining date).

Oh and for the record, it was me who wrote "THE" extension for top & bottom border removal in STOS. :wink: At the time(1995) it was the left & right borders that baffled me.

Quit with the STOS comments though, sure you can't substitue ASM code, but if I can do what I need to do with a Basic language then why bother learning something else? As it goes, it's only fullscreen and tracker routines that I want to do that just can't be done(properly) in Stos.

I'm not having a go, we all love coding, but if people are gonna be prejudist against other languages then it's just going to fragment what is left of the Atari scene(or any other scene for that matter).

Appriciate your technical information, thanks.

:D

Peace...
-=0rB17@l 50f7w@R3=-

Nev (Orbital Software)
Obsessive compulsive Atari behavior
Obsessive compulsive Atari behavior
Posts: 128
Joined: Thu Nov 25, 2004 8:50 pm
Location: Basingstoke (ex Birmingham)
Contact:

Postby Nev (Orbital Software) » Mon Jan 17, 2005 3:36 pm

unseenmenace wrote:A friend of mine is currently hacking apart TOS and GEM with a view to he and I adding some enhancements. One of which will almost certainly be top and bottom border removal in GEM. Other planned enhancements are:-

Possibly full overscan in GEM depending on how well we can optimise other parts of GEM, i.e if we can make it run fast enough to be useable

Super fast optimised GEM drawing routines for all 3 ST resolutions

Ability to switch from Colour to Mono in the same way you would switch from Low to Med res without rebooting

User defined icons, fonts and mouse pointers

Interlace support built into GEM desktop (probably STE only as its really easy to do on an STE)

Movable dialogues and alert boxes

Enhanced File Selector (along the lines of UIS III)


Feel free to post or email any questions or suggestions


Sounds good(actually it sounds damn good). :D Let's face it, anything would be an improvement to the standard GEM interface, but the above has started making me drool a bit. I hope it works and I look forward to seeing it in action.

:D

Peace...
-=0rB17@l 50f7w@R3=-

havoc
Captain Atari
Captain Atari
Posts: 213
Joined: Sun Jul 11, 2004 9:05 am

Postby havoc » Mon Jan 17, 2005 4:16 pm

I'm not having a go, we all love coding, but if people are gonna be prejudist against other languages then it's just going to fragment what is left of the Atari scene(or any other scene for that matter).

Hmm- you really oughta re-read Mr. Ni!'s message imho- he quite clearly states he has a *prejudice* about STOS coders. If he had claimed an informed opinion, things might have been different, but for now I don't think you have much to worry about. ;)

Nev (Orbital Software)
Obsessive compulsive Atari behavior
Obsessive compulsive Atari behavior
Posts: 128
Joined: Thu Nov 25, 2004 8:50 pm
Location: Basingstoke (ex Birmingham)
Contact:

Postby Nev (Orbital Software) » Mon Jan 17, 2005 4:40 pm

havoc wrote:
I'm not having a go, we all love coding, but if people are gonna be prejudist against other languages then it's just going to fragment what is left of the Atari scene(or any other scene for that matter).

Hmm- you really oughta re-read Mr. Ni!'s message imho- he quite clearly states he has a *prejudice* about STOS coders. If he had claimed an informed opinion, things might have been different, but for now I don't think you have much to worry about. ;)


Oh I did read it correctly, but i'm just replying in such a way that doesn't cause any offence back. I just don't want to get banned from such an excellent forum.

:)

Peace...
-=0rB17@l 50f7w@R3=-

Gunstick
Captain Atari
Captain Atari
Posts: 258
Joined: Thu Jun 20, 2002 6:49 pm
Location: Luxembourg
Contact:

BigY

Postby Gunstick » Mon Jan 17, 2005 9:06 pm

and here comes ULM to the rescue presenting you....


BIG-Y


An lower border removal for GEM (color mode)

Works absolutely fine. Just throw it in AUTO

Georges
PS: full overscan is not possible without hardware on a real ST because the floppy routine steals clock cyles and desynchronizes everything.

PPS: Attachment error: "The Extension prg is not allowed" so just forget it. Change the BBS to work for atari world and I will upload it here.

User avatar
unseenmenace
Atari God
Atari God
Posts: 1961
Joined: Tue Sep 21, 2004 9:33 pm
Location: Margate, Kent, UK
Contact:

Postby unseenmenace » Mon Jan 17, 2005 10:03 pm

Gunstick wrote:PS: full overscan is not possible without hardware on a real ST because the floppy routine steals clock cyles and desynchronizes everything.

What if we were to rewrite the GEM disk access routines do you think it might be possible with a bit of tinkering. I wasn't holding out much hope for this anyway but definitely want to try top and bottom borders in GEM. Is there anywhere else I can get that AUTO folder prog from so I can have a look at it?
UNSEEN MENACE
Several STFM's, 4MB STE, 2MB TT with 1.2GB Hard Drive and 14MB Falcon with 540MB Hard Drive,
Lynx 2 and Jaguar with JagCD
Member of GamebaseST and AtariLegend team
Check out my website at http://unseenmenace.110mb.com

User avatar
Nyh
Atari God
Atari God
Posts: 1496
Joined: Tue Oct 12, 2004 2:25 pm
Location: Netherlands

Re: Has anyone...

Postby Nyh » Mon Jan 17, 2005 11:51 pm

Mozes kriebel! Hoe dom kan een mens zijn? Waarom kan ik het niet laten? Het is toch vreselijk onverstandig om dit antwoord te schrijven... Mompel!
:-P

Nev (Orbital Software) wrote:Quit with the STOS comments though, sure you can't substitue ASM code, but if I can do what I need to do with a Basic language then why bother learning something else? As it goes, it's only fullscreen and tracker routines that I want to do that just can't be done(properly) in Stos.

I'm not having a go, we all love coding, but if people are gonna be prejudist against other languages then it's just going to fragment what is left of the Atari scene(or any other scene for that matter).

Appriciate your technical information, thanks.


Hi Nev,

I have got nothing against STOS basic. But to me it seems to me some of the users have a problem. I am sorry to say you are an example of them. No doubt you have a lot of fun with STOS. No doubt you can do great things with it. Let me try to explain it to you. I am quite sure you won't like it. Maybe I am plain wrong.

In my view the problem is as soon as you leave STOS you are quite clueless. To me you are like a script kiddie. Pasting together pieces of code to do great things but with only a faint idea how things are working. Oh boy, the Sart extension isn't working, so no stars for me! (code stars yourself). I need fullscreen with MOD support, why hasn't someone written an extension for me?

Wanting to learn is fine with me. But please pay attention and learn! Just a few days after I did a very optimistic calculation on interrupt driven fullscreens (keep some registers free, don't use expensive instructions) you start this thread about how nice it would be to have them running under GEM. Wondering why someone hadn't done it... (Looks like you are desperate needing the fullscreen without the pain.)

You don't need assembly to open all borders. It can (almost) be done in Omikron basic (not perfectly, it is to slow to close the right border, that is why the fullcreen is hidden in my demo). I don't know much about STOS basic but I am quite sure that if you can disable the interrupts you can do it even in STOS without the help of extensions, especially on a STe (hint: blitter comes to the rescue, forget to close the right border for starters).

Try to code effects in STOS without using any extensions. Just go bare bones to the machine. Do the starfield in basic like you would do it in assembly (note: there is no PLOT(x,y) instruction for the 68000). There are only variables, hardware registers, loops (for...next, repeat...until), jumps(goto), conditional code (IF...THEN...ELSE) and ofcourse direct memory access (POKE, PEEK and family). As a bonus you may use a memory move command too (MEMORY_MOVE(source, dest, length) or something like that). Play around with those basic instructions, use them to open borders, display sprites and stars.

Ofcourse, it won't be fast, depending on the compiler but I doubt the STOS compiler will be any better as the Omikron compiler and that one isn't too good (the best compiler I have seen on the ST is the Pure C compiler, it knows how to use data and adres registers for variables). This way transition to assembly will be a lot easier because now you know how things are working. The only thing you still have to do is writing it in assembly (and that is hard enough).

There are lot of things which are easier done in something else as assembly like diskaccess, game logic, string handling and overall framework code. There is no need to do stuff like that in assembly, any programming language with a good interface to assembly is suitable for that (the whole Heartland2000 framework and game logic is in C but all real time consuming stuff like generating the playfield and drawing the sprite are done in assembly).

Hope you can understand my reservations about STOS coders. It is up to you to prove me wrong.

Nyh

User avatar
Nyh
Atari God
Atari God
Posts: 1496
Joined: Tue Oct 12, 2004 2:25 pm
Location: Netherlands

Postby Nyh » Mon Jan 17, 2005 11:59 pm

havoc wrote:Hmm- you really oughta re-read Mr. Ni!'s message imho- he quite clearly states he has a *prejudice* about STOS coders. If he had claimed an informed opinion, things might have been different, but for now I don't think you have much to worry about. ;)


The problem is only the bad examples stay in mind. You don't notice the STOS coders who know what they are doing or those who know they don't know anything. (Whoops, I think I am going to make a lot of new friends today ;-) )

Nyh

User avatar
Nyh
Atari God
Atari God
Posts: 1496
Joined: Tue Oct 12, 2004 2:25 pm
Location: Netherlands

Postby Nyh » Tue Jan 18, 2005 12:49 am

unseenmenace wrote:
Gunstick wrote:PS: full overscan is not possible without hardware on a real ST because the floppy routine steals clock cyles and desynchronizes everything.

What if we were to rewrite the GEM disk access routines do you think it might be possible with a bit of tinkering. I wasn't holding out much hope for this anyway but definitely want to try top and bottom borders in GEM. Is there anywhere else I can get that AUTO folder prog from so I can have a look at it?


An other STOS coder? Hasn't got a clue, that's for sure.

Your problem is the DMA unit. Just like the shifter it shares the adres bus with the CPU, graps it when it needs to read or write data. Deadly for your synchronisation. And because a floppydisk is very slow you can't read (a part of) a sector in VBL time. Rewriting the floppy routines is a good idea because the implementation in TOS is not very smart (do nothing until data has been read).

And now I am in a nasty mode: there is no use 'optimise other parts of GEM' to make it fast enough for fullscreens. GEM is userland. You cannot control how other programs are written so you have to code for the worst case instructions (158 cycles for DIV). Where and how do you want to handle the other interupts (200 Hz timer, keyboard, RS232)? Running the OS only during VBL time is not an option.

I assume you will release each component of your great new TOS for testing as soon as it is ready? We don't have to wait for you reprogramming the AES to test the new file selector, resolution switch routine, or all other great things you are dreaming about. As we have seen with NVDI, UIS III and desktop replacements it is very easy to replace parts of the OS with new improved routines.

Nyh

Nev (Orbital Software)
Obsessive compulsive Atari behavior
Obsessive compulsive Atari behavior
Posts: 128
Joined: Thu Nov 25, 2004 8:50 pm
Location: Basingstoke (ex Birmingham)
Contact:

Re: Has anyone...

Postby Nev (Orbital Software) » Tue Jan 18, 2005 8:06 am

Nyh wrote:Mozes kriebel! Hoe dom kan een mens zijn? Waarom kan ik het niet laten? Het is toch vreselijk onverstandig om dit antwoord te schrijven... Mompel!
:-P

Nev (Orbital Software) wrote:Quit with the STOS comments though, sure you can't substitue ASM code, but if I can do what I need to do with a Basic language then why bother learning something else? As it goes, it's only fullscreen and tracker routines that I want to do that just can't be done(properly) in Stos.

I'm not having a go, we all love coding, but if people are gonna be prejudist against other languages then it's just going to fragment what is left of the Atari scene(or any other scene for that matter).

Appriciate your technical information, thanks.


Hi Nev,

I have got nothing against STOS basic. But to me it seems to me some of the users have a problem. I am sorry to say you are an example of them. No doubt you have a lot of fun with STOS. No doubt you can do great things with it. Let me try to explain it to you. I am quite sure you won't like it. Maybe I am plain wrong.

In my view the problem is as soon as you leave STOS you are quite clueless. To me you are like a script kiddie. Pasting together pieces of code to do great things but with only a faint idea how things are working. Oh boy, the Sart extension isn't working, so no stars for me! (code stars yourself). I need fullscreen with MOD support, why hasn't someone written an extension for me?

Wanting to learn is fine with me. But please pay attention and learn! Just a few days after I did a very optimistic calculation on interrupt driven fullscreens (keep some registers free, don't use expensive instructions) you start this thread about how nice it would be to have them running under GEM. Wondering why someone hadn't done it... (Looks like you are desperate needing the fullscreen without the pain.)

You don't need assembly to open all borders. It can (almost) be done in Omikron basic (not perfectly, it is to slow to close the right border, that is why the fullcreen is hidden in my demo). I don't know much about STOS basic but I am quite sure that if you can disable the interrupts you can do it even in STOS without the help of extensions, especially on a STe (hint: blitter comes to the rescue, forget to close the right border for starters).

Try to code effects in STOS without using any extensions. Just go bare bones to the machine. Do the starfield in basic like you would do it in assembly (note: there is no PLOT(x,y) instruction for the 68000). There are only variables, hardware registers, loops (for...next, repeat...until), jumps(goto), conditional code (IF...THEN...ELSE) and ofcourse direct memory access (POKE, PEEK and family). As a bonus you may use a memory move command too (MEMORY_MOVE(source, dest, length) or something like that). Play around with those basic instructions, use them to open borders, display sprites and stars.

Ofcourse, it won't be fast, depending on the compiler but I doubt the STOS compiler will be any better as the Omikron compiler and that one isn't too good (the best compiler I have seen on the ST is the Pure C compiler, it knows how to use data and adres registers for variables). This way transition to assembly will be a lot easier because now you know how things are working. The only thing you still have to do is writing it in assembly (and that is hard enough).

There are lot of things which are easier done in something else as assembly like diskaccess, game logic, string handling and overall framework code. There is no need to do stuff like that in assembly, any programming language with a good interface to assembly is suitable for that (the whole Heartland2000 framework and game logic is in C but all real time consuming stuff like generating the playfield and drawing the sprite are done in assembly).

Hope you can understand my reservations about STOS coders. It is up to you to prove me wrong.

Nyh


Your sort of correct on a couple of minor points, but your totally wrong on most of you comments towards myself. You don't know me or my code or the reason for wanting to use the stars extension instead of my own routines(and yes I do have my own stars routine almost running(havn't finished it yet)) so...

...YOU ASSUME too much without knowing the facts! I've got to go to work in a minute so i'll give you a full reply to your post when I get home later.

Have a nice day.

:)

Peace...
-=0rB17@l 50f7w@R3=-

User avatar
unseenmenace
Atari God
Atari God
Posts: 1961
Joined: Tue Sep 21, 2004 9:33 pm
Location: Margate, Kent, UK
Contact:

Postby unseenmenace » Tue Jan 18, 2005 9:05 am

Following on from Nevs response to Nyh's comments, you have made assumptions about me too.

Firstly I was once a STOS coder but I have been coding in assemler for about 10 years now. I may not know all there is to know but I think the phrase "Hasn't got a clue" is both wrong and totally uncalled for.

Secondly I realise that the disk system will interfere with synchronisation but I was wondering if it would be possible to rewrite the disk routs so that they are totally inactive during the visible part of the VBL only doing anything in between the screen redraws. I confess that the ST's disk system is not an area I know much about which is why I was asking for input from others.

Thirdly I realise that using timers for all the left and right border removals would mean accounting for worst case instructions in between. I figured that a lot of GEM app's such as word processors are not very CPU hungry and you could probably do the fullscreen in the usual synchronised block and run user code below the bottom border with OS routines that normally run on Timer C or on the VBL being inserted in gaps in the fullscreen where possible. But like I said I didn't hold much hope for fullscreen in GEM and was just theorising at this stage.

As for the res changing thing I have already written a small test program in assembler that enables the ST to instantaneously switch between colour and mono monitors either by just plugging in a mono monitor or by means of a switch. All that needs to be done is to integrate the code into GEM's normal desktop res selection so that you can select high res when in Low res and the system will wait for you to flick the switch or plug in a mono monitor and then restart GEM exactly as if you had selected Medium resolution.
UNSEEN MENACE
Several STFM's, 4MB STE, 2MB TT with 1.2GB Hard Drive and 14MB Falcon with 540MB Hard Drive,
Lynx 2 and Jaguar with JagCD
Member of GamebaseST and AtariLegend team
Check out my website at http://unseenmenace.110mb.com

havoc
Captain Atari
Captain Atari
Posts: 213
Joined: Sun Jul 11, 2004 9:05 am

Postby havoc » Tue Jan 18, 2005 9:49 am

Ach Hans, met een beetje geduld is toch niks echt onverstandig? Ik bedoel, toen ik zo'n 15 jaar terug m'n eerste assembler van jou kopieerde wist ik waarschijnlijk minder over coden dan deze jongens nu. Dat coden heb ik dan wel nooit echt goed onder de knie gekregen, maar ik kan er inmiddels tenminste normaal over meepraten. ;)

Unseenmenace, please feel free to theorize! But on the other hand, you can probably imagine that you're not the first one with this kind of plan, and there must be a reason why noone has succeeded so far. Please take the irony for what it is- it's not that I wouldn't like you to be the one to finally achieve this great hack, it's just that I'm trying to warn you about a path that most likely will lead to frustration...

User avatar
Nyh
Atari God
Atari God
Posts: 1496
Joined: Tue Oct 12, 2004 2:25 pm
Location: Netherlands

Re: Has anyone...

Postby Nyh » Tue Jan 18, 2005 1:01 pm

Nev (Orbital Software) wrote:Your sort of correct on a couple of minor points, but your totally wrong on most of you comments towards myself. You don't know me or my code or the reason for wanting to use the stars extension instead of my own routines(and yes I do have my own stars routine almost running(havn't finished it yet)) so...

...YOU ASSUME too much without knowing the facts! I've got to go to work in a minute so i'll give you a full reply to your post when I get home later.


Hi Nev,

Yes, you are completely right. I don't know you nor your code. The only thing I know about you is what you did on this forum. That is all I have to work with. And the balance up till now is not very positive. Please review your contributions to this forum... The best I can say is you are a damn good Llamatron player. For the rest... lots of questions, nothing wrong with it. But please explain me why you started this thread just after you have been told overscan is not a little hard but very hard? I just tipped the scales in the wrong direction.

Nyh

Zal ik het doen? Ik kan het niet laten! Bibbidi Bobbidi Boo!

User avatar
Nyh
Atari God
Atari God
Posts: 1496
Joined: Tue Oct 12, 2004 2:25 pm
Location: Netherlands

Postby Nyh » Tue Jan 18, 2005 1:36 pm

unseenmenace wrote:Secondly I realise that the disk system will interfere with synchronisation but I was wondering if it would be possible to rewrite the disk routs so that they are totally inactive during the visible part of the VBL only doing anything in between the screen redraws. I confess that the ST's disk system is not an area I know much about which is why I was asking for input from others.


Hi Unseenmenace,

Don't you think your claims were a bit over the top? Fullscreen in GEM? To me it is very whishfull thinking. I believe in the lower border, no problem and even if you loose it it affects only the bottom of the screen. Upper boder will be a lot harder, not opening the upper border wil affect the whole screen, making it junp down and up. Bigger penalty for missing the upper border. Missing a left or a right border wil garble the rest of you screen and you have to have it right not once or twice every screen put over 200 times.

As for the no clue part... That is for the disk routines. Do some math:
floppy: 300 RPM -> max delay for a sector = 60/300 = 200 ms
duration of 'free time' (using a very moderate 240 line fullscreen) = 125x(160000-240x512) = 4.6 ms.
So floppy DMA and fullscreen are not very compatible.

Nyh

User avatar
Nyh
Atari God
Atari God
Posts: 1496
Joined: Tue Oct 12, 2004 2:25 pm
Location: Netherlands

Postby Nyh » Tue Jan 18, 2005 3:45 pm

havoc wrote:Ach Hans, met een beetje geduld is toch niks echt onverstandig? Ik bedoel, toen ik zo'n 15 jaar terug m'n eerste assembler van jou kopieerde wist ik waarschijnlijk minder over coden dan deze jongens nu. Dat coden heb ik dan wel nooit echt goed onder de knie gekregen, maar ik kan er inmiddels tenminste normaal over meepraten. ;)

Unseenmenace, please feel free to theorize! But on the other hand, you can probably imagine that you're not the first one with this kind of plan, and there must be a reason why noone has succeeded so far. Please take the irony for what it is- it's not that I wouldn't like you to be the one to finally achieve this great hack, it's just that I'm trying to warn you about a path that most likely will lead to frustration...


Hi Havoc,

Ik heb ik helemaal nix tegen mensen die niets weten van coden en die het willen leren. Ik wil alles wel vertellen en uitleggen. Waar ik echter een beetje moe van wordt zijn personen waarin ik tijd steek en vervolgens er blijk van geven helemaal niet opgelet the hebben.

Theorizing is great. But as soon as you show op with great theories you better come up with deep understanding of the theory in the first place. The number of people who think Einstein is wrong and have themselves a better theory is huge. But the number of people who understand general relativity and still think they have a better theory is not so huge.

Nyh

Nev (Orbital Software)
Obsessive compulsive Atari behavior
Obsessive compulsive Atari behavior
Posts: 128
Joined: Thu Nov 25, 2004 8:50 pm
Location: Basingstoke (ex Birmingham)
Contact:

Postby Nev (Orbital Software) » Tue Jan 18, 2005 9:21 pm

Nyh wrote:In my view the problem is as soon as you leave STOS you are quite clueless. To me you are like a script kiddie. Pasting together pieces of code to do great things but with only a faint idea how things are working. Oh boy, the Sart extension isn't working, so no stars for me! (code stars yourself). I need fullscreen with MOD support, why hasn't someone written an extension for me?


In a word "WRONG". Just because I use Stos doesn't mean I don't know how things are working, your assuming again. I know how specific commands operate and why, what happens at 68000 level is irrelavent when i'm just coding basic things. I make a screen or a proggy for a reason, if it works then great, if it doesn't then I investigate and look into things a lot deeper and work out exactly what is going on. Why would I want to know whats happening at 68000 level when all I want to do is:

10 Print "Hello World!"
20 End

...for example.

Nyh wrote:Wanting to learn is fine with me. But please pay attention and learn! Just a few days after I did a very optimistic calculation on interrupt driven fullscreens (keep some registers free, don't use expensive instructions) you start this thread about how nice it would be to have them running under GEM. Wondering why someone hadn't done it... (Looks like you are desperate needing the fullscreen without the pain.)


I'll let you have the point about looking desperate for a fullscreen, it does look that way but i'm not desperate whatsoever. It makes no odds to me if I have one or not, but it would be nice to learn and eventually undertake such a task. All I was doing was researching into it all. And as for the Fullscreen in GEM, that was totally unrelated, I was just curious as to whether it had been done or not, and if not, why not. If you don't know or understand something then ask. Theres no shame in that. If I undertake something like a fullscreen then I don't expect to have it easy at all, I always expect and prepare for problems.

Nyh wrote:Try to code effects in STOS without using any extensions. Just go bare bones to the machine. Do the starfield in basic like you would do it in assembly (note: there is no PLOT(x,y) instruction for the 68000). There are only variables, hardware registers, loops (for...next, repeat...until), jumps(goto), conditional code (IF...THEN...ELSE) and ofcourse direct memory access (POKE, PEEK and family). As a bonus you may use a memory move command too (MEMORY_MOVE(source, dest, length) or something like that). Play around with those basic instructions, use them to open borders, display sprites and stars.


Agreed. When I code a screen(demos), I always work with the bare bones of what i've got(no extensions). If after optimisation it's still too slow or I can't quite get enough sprites on screen(etc etc) then I will substitute the normal commands for the commands given via extensions. The extensions are there and they are there for a reason, so it would be a waste of time scrapping a screen when I know it can be achieved with faster commands(via the extension/s).

Nyh wrote:Hope you can understand my reservations about STOS coders. It is up to you to prove me wrong.


I don't need to prove or justify myself to you or anyone else, but when you jump out and make comments that are blatantly incorrect and make me look like a complete idiot then you give me no option.

I wanted the Stars extension to work instead of my own routines for the following reasons:

1. It saves plenty of time which I don't have right now.
2. It's a hell of a lot faster than my own routines so I can add more things to the screen that i'm already happy with.

Your an intelligent bloke, and yes I understand your logic(just about) and yes your technical knowledge is awesome, however your arrogance and attitude leaves a lot to be desired and to be quite honest it's childish to say the least. You seem to have too much unneccesary aggression. Chill out a bit, we're not the enemy here.

Peace...
-=0rB17@l 50f7w@R3=-

Nev (Orbital Software)
Obsessive compulsive Atari behavior
Obsessive compulsive Atari behavior
Posts: 128
Joined: Thu Nov 25, 2004 8:50 pm
Location: Basingstoke (ex Birmingham)
Contact:

Re: Has anyone...

Postby Nev (Orbital Software) » Tue Jan 18, 2005 9:29 pm

Nyh wrote:But please explain me why you started this thread just after you have been told overscan is not a little hard but very hard?


...as answered in my above post...

Nev wrote:...as for the Fullscreen in GEM, that was totally unrelated, I was just curious as to whether it had been done or not, and if not, why not.


Peace...
-=0rB17@l 50f7w@R3=-

User avatar
Mug UK
Administrator
Administrator
Posts: 11231
Joined: Thu Apr 29, 2004 7:16 pm
Location: Stockport (UK)
Contact:

Postby Mug UK » Tue Jan 18, 2005 11:15 pm

Sigh .. with what's left of us, and our opinions, can we get back to the matter in hand which is having fun with our Atari - emulated or real thing.

Before this whole bulletin board runs out of space with this little match - can the moderators lock down this thread and the other one just posted about Nyh's previous work before there's a coders war on!

Or else I'll send in Mr Bush .. and you know what a mess *he* can make of things :)
My main site: http://www.mug-uk.co.uk - slowly digging up the bits from my past (and re-working a few): Atari ST, Sega 8-bit (game hacks) and NDS (Music ripping guide).

I develop a free Word (for Windows) add-in that's available for Word 2007 upwards. It's a fix-it toolbox that will allow power Word users to fix document errors. You can find it at: http://www.mikestoolbox.co.uk

User avatar
Nyh
Atari God
Atari God
Posts: 1496
Joined: Tue Oct 12, 2004 2:25 pm
Location: Netherlands

Postby Nyh » Tue Jan 18, 2005 11:32 pm

Nev (Orbital Software) wrote:Agreed. When I code a screen(demos), I always work with the bare bones of what i've got(no extensions). If after optimisation it's still too slow or I can't quite get enough sprites on screen(etc etc) then I will substitute the normal commands for the commands given via extensions. The extensions are there and they are there for a reason, so it would be a waste of time scrapping a screen when I know it can be achieved with faster commands(via the extension/s).

You seem to have too much unneccesary aggression. Chill out a bit, we're not the enemy here.


Ahh, you make me quite curious to your screen. And the remark about the agression is true. I have got a nasty cold. Couldn't do any serious training the last week. Bad for your temper. :-?

Nyh

User avatar
unseenmenace
Atari God
Atari God
Posts: 1961
Joined: Tue Sep 21, 2004 9:33 pm
Location: Margate, Kent, UK
Contact:

Postby unseenmenace » Wed Jan 19, 2005 12:42 am

Some of us have lots to learn when it comes to coding but why take such an agressive stance at people who are merely exploring ideas and looking for a bit of advice?
UNSEEN MENACE
Several STFM's, 4MB STE, 2MB TT with 1.2GB Hard Drive and 14MB Falcon with 540MB Hard Drive,
Lynx 2 and Jaguar with JagCD
Member of GamebaseST and AtariLegend team
Check out my website at http://unseenmenace.110mb.com


Social Media

     

Return to “Coding”

Who is online

Users browsing this forum: No registered users and 4 guests