Creating a binary file with an INIT address from MAC/65

[+slx]

This is probably very basic but still eludes me.

 

I have compiled a page 6 program in MAC/65, moved it to page 6 with DDT and used BSAVE to save it.

 

Is there a way to add an INIT address ($0601) to the file using MAC/65 or do I need an extra utility to do that (I know how to do it from BASIC by adding bytes to the end of the file but is there an easier way).

 

(AFAIK I need to add just 6 bytes at the end: $e2 $02 $e3 $02 $01 $06.)

 

Or is it easier to compile to disk and use an extra segment with *=$02e2 .byte 01 06 at the end?

 

Thanks!

[ricortes]

IMO: You are on track with compile to disk.

 

You can use DOS binary save feature as long as you as you are going there. You just feed it file name, address range, INIT, and START. It's also useful to use a MEMSAV on the disk in case you want to use an area the DUP overwrites when it loads.

[+slx]

Thanks. AFAIK the INIT option is only available in Atari DOS but not in DOS XL.

 

So I will try the compile to disk route.

[Alfred]

Don't use the $02E2 init address unless you also have a $02E0 run address. Under SpartaDos that will likely make your system crash. Always use $02E0 for run addresses unless you really need a separate init routine.

 

If you only use init, cli doses like Sparta will jump to the first byte of loaded code when the file load is complete. Not usually what you want. This is why Action! programs crash under Sparta unless you manually fix them.

[+slx]

I really need INIT only as it is supposed to install a VBLANK routine and then exit again.

The exit is via RTS as the programm is supposed to with A USR call from BASIC (with an extra PLA in front).

 

Is it possible to use a "dummy" start address at 02E0 that just exits back to DOS? And where would it have to exit to to be compatible with the maximum number of DOSes?.

[ricortes]

I argued against modding the Action cart to use START instead of INIT unsuccessfully. SD should have been modified to handle the INIT properly. The way it works is so integral to the Atari, everything from loading handlers to reserving memory, I can't see why it doesn't get more discussion/fixed. I recall a number of programs broke with it, not just Action. You would sometimes get a program unexpectedly running twice.

[Alfred]

I really need INIT only as it is supposed to install a VBLANK routine and then exit again.

The exit is via RTS as the programm is supposed to with A USR call from BASIC (with an extra PLA in front).

 

Is it possible to use a "dummy" start address at 02E0 that just exits back to DOS? And where would it have to exit to to be compatible with the maximum number of DOSes?.

 

The simplest fix is to make the first byte of your program $60.

 

I argued against modding the Action cart to use START instead of INIT unsuccessfully. SD should have been modified to handle the INIT properly. The way it works is so integral to the Atari, everything from loading handlers to reserving memory, I can't see why it doesn't get more discussion/fixed. I recall a number of programs broke with it, not just Action. You would sometimes get a program unexpectedly running twice.

 

I don't agree that Sparta is wrong; it does handle the INIT address properly. The INIT address is to allow something to execute before the main program runs, either via $02E0 or jumping to the load address. It's a design mistake in Action! to have used $02E2 as the run address, since there is no initialization required for the Action! runtime code.

[+slx]

 

The simplest fix is to make the first byte of your program $60.

 

So DOS JSRs to the START address (or the first byte) and I can return control to DOS via RTS?

 

Will SpartaDOS (and other CLI DOSes) JSR to the INIT address if there is one?

[+Stephen]

I argued against modding the Action cart to use START instead of INIT unsuccessfully. SD should have been modified to handle the INIT properly. The way it works is so integral to the Atari, everything from loading handlers to reserving memory, I can't see why it doesn't get more discussion/fixed. I recall a number of programs broke with it, not just Action. You would sometimes get a program unexpectedly running twice.

Check the docs for the latest 4.47 version. There are several different options now for the LOAD command.

[Alfred]

 

 

Will SpartaDOS (and other CLI DOSes) JSR to the INIT address if there is one?

 

Yes.

[ricortes]

 

The simplest fix is to make the first byte of your program $60.

 

 

I don't agree that Sparta is wrong; it does handle the INIT address properly. The INIT address is to allow something to execute before the main program runs, either via $02E0 or jumping to the load address. It's a design mistake in Action! to have used $02E2 as the run address, since there is no initialization required for the Action! runtime code.

 

We will have to agree to disagree. Because of the copy with append function of DOS, you can actually load data, programs, whatever really, just by using the append function. Once the INIT was taken out of Action, you could no longer write say a handler in Action with your mainline code i.e. a terminal appended to the end like practically every other com program does. I think I have used as many as three files appended end to end to take advantage of the feature. Now that it isn't there, I would never buy the current/last version of Action. There are just too many practical uses for it like having your mainline code use the same memory location as your INIT code. It was one of the things OSS/Bill touted as ~a great feature.

 

I may be wrong on this but I think I was the guy who pointed out the flaw in SD in the newsgroup and the [$60] code block in the header as a work around maybe 25 years ago. Been a thorn in my side that got worse with the Action fix. What was a simple fix, one byte code block, became a crippling mod for some of us.

 

There's also another bug w/o consequence in Action I should point out in the other thread to JAC. I haven't looked at the code generation yet but I seem to recall it always had two RTS at the end. Something simple like there is always an implied RTS at the end of last Procedure so if you put a RETURN there you get two. Been too long to remember all the details. It may be important to save a byte or two in the CART for improvements.

[Rybags]

Sounds like an all-round clusterfuck.

 

Problems with binary file:

- they should have been supported by the OS/CIO from the onset instead of higher level Dos/custom loaders. Fair enough, CIO is device and data agnostic to a large degree but it would have been a worthwhile inclusion as a special command (throw away that useless FILL command from the S: to make some room).

- from memory there's some Doses that don't allow returning from a RUN segment.

- a loaded file shouldn't be executed from the initial load address if no RUN address is provided. Many people use binary files simply to contain data that's later loaded into place (often with other data and program files).

- a program that uses the final INIT as it's run address might be breaking the rules a bit but who cares?

[Alfred]

 

We will have to agree to disagree. Because of the copy with append function of DOS, you can actually load data, programs, whatever really, just by using the append function. Once the INIT was taken out of Action, you could no longer write say a handler in Action with your mainline code i.e. a terminal appended to the end like practically every other com program does. I think I have used as many as three files appended end to end to take advantage of the feature. Now that it isn't there, I would never buy the current/last version of Action. There are just too many practical uses for it like having your mainline code use the same memory location as your INIT code. It was one of the things OSS/Bill touted as ~a great feature.

 

I may be wrong on this but I think I was the guy who pointed out the flaw in SD in the newsgroup and the [$60] code block in the header as a work around maybe 25 years ago. Been a thorn in my side that got worse with the Action fix. What was a simple fix, one byte code block, became a crippling mod for some of us.

 

There's also another bug w/o consequence in Action I should point out in the other thread to JAC. I haven't looked at the code generation yet but I seem to recall it always had two RTS at the end. Something simple like there is always an implied RTS at the end of last Procedure so if you put a RETURN there you get two. Been too long to remember all the details. It may be important to save a byte or two in the CART for improvements.

 

Well using $02E2 in that way makes sense at least. I have almost never used the INIT address, but if you're going to use Copy/Append to bind mulitple stages together I can see it's useful. If I was Clinton I would have made it the other way around though, so that people wanting to use the INIT would have had to manually intervene, rather than the RUN people. I suppose that's my SD bigotry showing itself, lol.

 

I'm a little confused though as why you think it's gone as the use of $02E2 was never taken out of Action!, at least not that I've seen. You're right about the dual RTS at the end, the compiler does a final opcode push. I think it's to cover the possibility that you might end with a code block and left out the RTS yourself. I can't actually recall if I've ever seen only a single RTS there at the end.

[+Stephen]

Guys, with the new SDX 4.47, this should NOT be an issue. From the change log:

 

U_LOAD and XIO 40 binary load functions are now more customizable.
  For U_LOAD this is done via the FLAG parameter, while XIO 40 uses AUX2
  for the same purpose. The following values determine the loading mode:
  0 : Load the progam using INIT and RUN vectors ($2E2, $2E0). If the program
      does not set the RUN vector, it is executed by a jump to its first
      address. This is SDX default.
  64 :Use INIT and RUN vectors only (AtariDOS compatible mode).
  128:Do not execute. No INIT/RUN vectors are used.
  192:Do not execute, but perform INITs.
  Note that previous SDX versions performed INITs regardless of the settings.

[ricortes]

I know it sounds like I am protesting a lot, it really isn't that much of a problem. The only carts that were made with RUN instead of INIT code were the last production by FTE, sold by them and CSS. I have two earlier manufacture carts so it really doesn't touch me, only people who bought one has one of the newer carts. Thanks to Alfred refreshing my memory I can make any code or suggestions to be a better fit should a problem arise.

 

@Stephen, I've really been a slug keeping up with SD updates. My whole life is following side tracks now. Once again, not complaining but enjoying it. It looks like I should be looking harder at SDX since it seems to be trying harder to maintain compatibility. I seem to recall even Atari DOS II had the option to binary load with the /N option so you could get a program memory resident w/o having it take control of the system.

 

Drift... my latest side track 'just fooling around'; started buying a bunch of the cheap Arduino boards. I'm not even sure where or what I want to do with them. Since they are ttl serial with 2k RAM and 32k ~ROM I was thinking hang one on a joystick port with the MPP handler. Completely pointless but good way to get my feet wet. Kind of like the worlds smallest bbs on a joystick port. Seems like there would be a couple of equally pointless applications like PC style keyboard interface, XE(-)P80 to VGA type interface, nothing anybody would actually use. Thing is, the knockoffs are so dirt cheap, <$5, it appeals to the skin flint in me. The Arduino crew has really done a great job of getting things turn key. If anyone were to ask what would be a good way to learn C programming I would probably point them to the Arduino. Maybe 30 minutes from getting it in my hot little hands to working working program.

[Alfred]

 

Guys, with the new SDX 4.47, this should NOT be an issue. From the change log:

U_LOAD and XIO 40 binary load functions are now more customizable.
  For U_LOAD this is done via the FLAG parameter, while XIO 40 uses AUX2
  for the same purpose. The following values determine the loading mode:
  0 : Load the progam using INIT and RUN vectors ($2E2, $2E0). If the program
      does not set the RUN vector, it is executed by a jump to its first
      address. This is SDX default.
  64 :Use INIT and RUN vectors only (AtariDOS compatible mode).
  128:Do not execute. No INIT/RUN vectors are used.
  192:Do not execute, but perform INITs.
  Note that previous SDX versions performed INITs regardless of the settings.

 

I, for one, don't use SDX. My real hardware revolves around the CSS Multiplexor, so that lets SDX out. I did buy 4.21 I think, but I found it to be a little flaky and just too slow to boot up. So for me, SD ended with 3.2D.

[flashjazzcat]

I understand that modern versions of SDX may be used with the Multiplexer: at least, support for obtaining the time (MUXTIME) is available from the SDX Upgrade project page.

[+David_P]

 

Drift... my latest side track 'just fooling around'; started buying a bunch of the cheap Arduino boards. I'm not even sure where or what I want to do with them. Since they are ttl serial with 2k RAM and 32k ~ROM I was thinking hang one on a joystick port with the MPP handler. Completely pointless but good way to get my feet wet. Kind of like the worlds smallest bbs on a joystick port. Seems like there would be a couple of equally pointless applications like PC style keyboard interface, XE(-)P80 to VGA type interface, nothing anybody would actually use. Thing is, the knockoffs are so dirt cheap, <$5, it appeals to the skin flint in me. The Arduino crew has really done a great job of getting things turn key. If anyone were to ask what would be a good way to learn C programming I would probably point them to the Arduino. Maybe 30 minutes from getting it in my hot little hands to working working program.

 

Arduino Pro Mini clones are available on Ebay for less than $2.50. At that price, a great toy to interface to an Atari... I'm hoping to wire one up to permit me to use a PS/2 keyboard on my XEGS; also looking at setting up an i2c EEPROM as a 128K SD drive; that way, when I want to hand some weird SPI device on the SIO line, the drivers can be in the same contraption.