Switching BASIC OFF Automatically and Graceful Exit

[baktra]

I am just curious...

 

If you develop a new software for the 8-bit Atari computers and your software requires the BASIC ROM to be switched off, do you prefer to add the code that switches it off automatically (at least on the XL/XE modules), or is it something you prefer to leave in the hands of the user?

 

And one more question. Do you intentionally take any measures that will allow your program to be exited gracefully (that means the user is at least capable of initiating a proper cold start) without forcing the user to switch the computer off.

 

Developers, state your opinion in the poll.

Users, state yours by answering the 3rd question of the poll.

 

Opinions and notes are welcome too.

 

 

 

Edited April 11, 2018 by baktra

[+CharlieChaplin]

Well,

 

I am preparing the software/diskettes for Abbuc Software competition, for Return Magazine and Proc Atari Magazine and errmm, I do have a computer more than 30 years old. So YES, I like programs that automatically switch off Basic and do a coldstart (reboot) when Reset is pressed. Since many coders do not add such code in their programs (or me as a non-coder does not see this), I manually add one of the following segments almost everytime:

 

Blkscr.COM: switches off Basic, clears RAM under Basic, gives a black screen, Reset is set to coldstart (Poke 580,1)

 

Scroff.COM: switches off Basic, clears RAM under Basic, gives a blank screen (screen off!), Reset is set to coldstart

 

ClearZP.COM: switches off Basic, clears RAM under Basic, clears Zero Page, Reset is set to coldstart, either has black screen or blank screen

 

Allthough these routines do make use of Page 4, this is only to switch off Basic and other stuff. Right after this has been done, Page 4 is fully available again for any program that uses it. Reset is set to coldstart via Poke 580,1 (or LDA $0244), alas, there are many ways to trap Reset and/or make your program reset-proof and thus this coldstart does not always work.

 

Personally I would like to see more (all) programmers to switch off Basic automatically and to allow for a coldstart (reboot) of the system, so there is no need to power off and back on your 30 to 40 year old Atari computer...

 

 

P.S.: These routines were done by Fandal and HiasSoft for me, so all cudos to them !

BLKSCR.XEX

SCROFF.XEX

CLEARZP.XEX

Edited March 30, 2018 by CharlieChaplin

[flashjazzcat]

Of course in those situations where it's possible to load the software from DOS, the facility to invoke a JMP ($0A) is the preferable "graceful exit". In those circumstances, I think forcing a reboot on Reset isn't a good idea, since Reset will normally simply return the user to DOS so that they may launch the next program. If the software in question has already obliterated everything else in RAM upon loading, however, then it hardly matters.

 

Programs like AtariWriter Plus which assumed the only way one would wish to leave the application was via the power switch were always a source of irritation to me. Since it was reset protected, one could not even return to DOS via the Reset key.

[+therealbountybob]

If I can do it anyone can - my assembler games disable basic and reboot when reset is pressed...

now if only the rest of the code worked so well !

[baktra]

Programs like AtariWriter Plus which assumed the only way one would wish to leave the application was via the power switch were always a source of irritation to me. Since it was reset protected, one could not even return to DOS via the Reset key.

 

Yeah, I don't like software that forces the computer to be switched off.

 

A cartridge with a button (I always had one) was my salvation. It allowed to exit pretty much any software. I also believe QMEG allows for hard reset with just SELECT+RESET. There also existed a fake cartridge without any ROM, just with the button to do just the same.

 

Of course, the most graceful exit is return to DOS (shouldn't a simple RTS do the trick?). But as you pointed out, some software has no choice but to obliterate all RAM, so cold start is good enough for them.

Edited March 30, 2018 by baktra

[flashjazzcat]

Like QMeg, several patched operating systems include a forced coldstart facility (usually called by SELECT+RESET), and Ultimate 1MB includes such functionality (either by jumping into the BIOS setup menu or - when the newer firmware is used - pressing SELECT+RESET regardless of the choice of operating system).

 

RTS will exit to DOS if the state of the stack was preserved and you return at the exact same call level as you started, but if that's not the case (or if the application is reset-protected), a JMP ($0A) is necessary.

Edited March 30, 2018 by flashjazzcat

[Rybags]

IMO no reason at all not to cater for switching off Basic. It's about 8 bytes extra programming (including setting the flag which tells the OS to disable it on warmstart).

 

Graceful exit - back in the day I'd actually spend hours getting software to not do a coldstart but in the modern day requirements have changed. We have Ramdisks that we want preserved and we don't want the extra wear and tear that power cycling brings. So it's a good idea to cater for that need, though if you've got Ulimate 1 Meg, IDE +2 or certain other custom OSes you can initiate coldstart on demand.

 

Exit to Dos - it's desirable but a lot of effort quarantining a program such that it can preserve that environment.

[+JAC!]

If program requires the space under the BASIC ROM is should make sure the BASIC ROMis disabled.

I find programs that require the user to remeber OPTION or sometimes not very annyoing.

In fact oftentimes the reason is that programmers use modfied OSes with reverted OPTION logic.

Therefore the do not even realize that regular users are annoyed.

 

General tips to make the program work in diffent contexts

https://www.wudsn.com/index.php/productions-atari800/tutorials/tips

[baktra]

It seems the convenience of switching the BASIC off and graceful exit is neither unfamiliar nor unused. And that is good.

On the other hand, leaving those in the capable hands of the users is nothing bad too.

 

JAC!, thank you for the tips. You seem to be a supporter of keeping DOS. I only wish some of my software doesn't need memory from 2048-8192 :-)

 

I would have one question to the re-opening of the screen editor (E: device) in the routine that switches the BASIC off.

Do you think it is OK to close the E: device first?

 

It occured to me that there is also one situation that prevents switching the BASIC off automatically - a cassette boot file that boots to the area "under BASIC". Of course a pre-loader or a binary loader for cassette solves this.

Edited April 6, 2018 by baktra

[+JAC!]

>You seem to be a supporter of keeping DOS. I only wish some of my software doesn't need memory from 2048-8192 :-)

If there is a way to keep DOS intact you should to it. This way the user has to wait less when pressing RESET.

I rely on that a lot for example for the demo compilation I create (Silly Packs). And I patch lots of the entry to ensure that.

The opposite is also important: If there is no way to keep DOS (because you really need all the memory), then make sure the systems performs a coldstart on reset.

Often people miss that and then the machine locks up and you have to switch it off again.

 

>I would have one question to the re-opening of the screen editor (E: device) in the routine that switches the BASIC off. Do you think it is OK to close the E: device first?

In fact if you go through the regular CIOV must close it first, before you can reopen it.

The way used in my sample code uses the handler table entry directly and bypasses that part of the CIOV.

Still my code is compatible, because the handler table entries are also official vectors.

 

>It occured to me that there is also one situation that prevents switching the BASIC off automatically - a cassette boot file that boots to the area "under BASIC". Of course a pre-loader or a binary loader for cassette solves this.

Cassette boots give you 39k ($480-$9FFF) free space to load. That is really a lot. In the early days, people just put the code into that space. Nowadays you would/should always use a packer like EXOMIZER, DEFALTE and such. It reduces size and hence loading time and you an safely assume that 48k can be packed to less than 39k for any regular program. And the unpacker would disable BASIC etc. as required.

[Rybags]

Just reopening E: isn't sufficient - you'd first need to change the memory size variables at $6A and $2E4 - RAMTOP @ $6A tells the OS where to put the screen behind.

 

CLOSE of an IOCB is extra coding - for devices like E: where there's not EOF processing required you can just set the ICHID byte to $FF (it's used as an index to the device table, $FF flags an unused IOCB).

[phaeron]

Technically, you would need to close E: if fine scrolling were enabled, though good luck finding anything using that feature. It's only five more bytes to close E: the right way.

[Rybags]

This should cater for switch out Basic, test if the 8K exists, set memory pointers and reopen E:

If the Ram size test is unwanted then remove the lda $b000 through beq not48k and the not48k label.

Some labels not declared, if standard equates were used then they'd be there anyway.

  ldx #$ff
  stx portb ; $d301
  stx basicen ; $3f8
  lda $b000
  inc $b000
  cmp $b000
  beq not48k
  lda #$c0
  sta ramtop ; $6A
  sta ramsiz ; $2E4 set correct Ram size
not48k
  inx ; X=00
  lda #$c ; close
  sta $342
  jsr $e456
  lda #<editor
  ldy #>editor
  sta $344
  sty $345 ; buffer address
  lda #3 ; open
  sta $342 ; command
  lda #$c
  sta $34a ; aux1
  stx $34b ; aux2
  jsr $e456 ; Open E:
  rts
editor .byte "E:",$9B

[baktra]

Hmm. My software does not adjust the RAMSIZ, an omission, of course.

But, my software also doesn't use the E: device anyway (just closes it, sets up a custom DL, and then "paints" with memcpy() and *ptr=...). But I will keep this in my mind.

[Rybags]

It would probably never matter. Very few games bother to check even if enough Ram is installed, let alone looking at the OS managed aspect of it.

[+JAC!]

Hmm. My software does not adjust the RAMSIZ, an omission, of course.

But, my software also doesn't use the E: device anyway (just closes it, sets up a custom DL, and then "paints" with memcpy() and *ptr=...). But I will keep this in my mind.

 

 

The point is that without setting the RAMTOP/SIZ, the E: screen will still be at $9cxx instead of $bcxx.

So when you actually load up to $9fff or beyond the DL and screen will garble during loading.

This can even result in the program not starting correctly in case it uses DLIs and is not coded 100% bullet proof.

 

>It's only five more bytes to close E: the right way.

Will adapt my template :-)

[phaeron]

According to the OS manual, RAMTOP and RAMSIZ hold the same value but RAMTOP is specifically the one used by the Display Handler. Setting both is the right thing to do, but existing code that only sets RAMTOP to reopen E: should be fine. RAMSIZ would be more important to set in code that could chain to another program that might use it.

[GoodByteXL]

I am just curious...

 

...

Users, state yours by answering the 3rd question of the poll.

 

Opinions and notes are welcome too.

 

It's not possible to answer as just a user.

 

Another idea: If OSS language cartridges are plugged in, disable them as well if not needed. Very few programs do that actually though it's not a big deal.

[baktra]

When I am thinking about this madness...

 

What do you think about a monolithic binary file (one normal segment, one RUN segment, thus no way to execute a code before it is loaded) that loads let us say to addresses 40145 - 49152 most likely overwriting the screen memory and display list. Can that be potentially dangerous? I assume a well-behaved binary loader keeping its mouth shut and DLIs disabled. Mess on the screen is one thing, but can this result in lockup?

 

Now I understand that binary loaders in some universal cartridges allow an option for switching the screen off (and no E: device open) before the loading begins.

I must be over-thinking this...

[flashjazzcat]

What do you think about a monolithic binary file (one normal segment, one RUN segment, thus no way to execute a code before it is loaded) that loads let us say to addresses 40145 - 49152 most likely overwriting the screen memory and display list.

Obnoxious and to be avoided if at all possible.

[FifthPlayer]

What do you think about a monolithic binary file (one normal segment, one RUN segment, thus no way to execute a code before it is loaded) that loads let us say to addresses 40145 - 49152 most likely overwriting the screen memory and display list. Can that be potentially dangerous? I assume a well-behaved binary loader keeping its mouth shut and DLIs disabled. Mess on the screen is one thing, but can this result in lockup?

 

 

Lockup or not, I would be led to believe the machine has crashed. It's a user-hostile thing to just trash the display list and leave digital garbage on screen for the user.

 

Also, how would you know DLIs are disabled if you cannot execute any code before the file is loaded?

Edited April 10, 2018 by FifthPlayer

[baktra]

 

Also, how would you know DLIs are disabled if you cannot execute any code before the file is loaded?

 

No DLIs is included in the "well-behaved" binary loader. I wouldn't expect a binary loader to mess with DLIs.

[+JAC!]

 

No DLIs is included in the "well-behaved" binary loader. I wouldn't expect a binary loader to mess with DLIs.

That is not the point. Oftentimes people rely on certain timing and when they setup their DLI/NMI vectors, NMIEN and the DL pointer and the rest of the program initialization.

What happens when you overwrite the actual DL with data is that the DL goes "anywhere" and starts triggering DLIs randomly as it comes across bytes >=$80.

This can trigger the DLI right at the moment when the rest of the program initialization is not yet completed / ready for the first DLI at all.

 

In short: Ensure the DL during loading is stable and don't crush it without a need. Plus what the others wrote about the user wondering what's wrong...

[Rybags]

The majority of code out there though it's usually Basic, just bumps down RAMTOP ($6A) based upon it's own value.

That's bad practice since reruns without pressing Reset in between mean you get a memory leak, plus potentially generating odd values which might mess the alignment of your PM or screen data (esp the 8K modes).

[phaeron]

DLI-related crashes with stomping the active display usually happens with splash screens in the program. I don't think I've seen a case of a generic binary loader itself using and keeping DLIs on during the load. Either the program overwrites its own splash screen, or tries to swap in a new screen and doesn't cleanly wait for the screen to actually swap before turning on DLIs.

 

Unfortunately, you don't need DLIs to crash when stomping the active display. It's pretty hard to do with stock hardware, but the minute you get any expansion hardware there is a lot more opportunity for mischief. In particular, letting ANTIC read random memory can result in it triggering a bank switch on a cartridge or reading and discarding bytes from an IDE device. This occurs because ANTIC reads can trigger the hardware exactly the same way as a CPU read. Both of these cases have actually caused crashes in cartridge/IDE based loaders on real hardware.