Introduction
electr...@optonline.net
My name is Tony. I began study a little 6502 in Feb. I would love to
make a cartridge for the 800xl. (I did previously make a cart for the
Nintendo NES, a very simple program that I was helped with from the
people at the NESDEV forum.
I want to learn to make programs for the Atari 800xl, make cart. I am
planning to write the code on a on 800xl and then transfer my program
to my pc using the SIO2PC and APE from AtariAge.
The one thing that is eluding me is finding a real example of 6502
assemble code for the autoboot cartridge header.
I want to be able to pop in the cart and have it boot up my program
automatically.
Could anyone refer me to any real ASM code examples? Are there other
ways of having your cart boot when plugged into the 800xl?
Thanks for any help.
Tony
Rick Cortese
It is easier then that. There are two locations in the cart that the OS
will transfer control to. Typically for an 8k cart it would be memory
mapped in the range $A000-$BFFF for the INIT would be at $BFFE=$BFFF and
START at $BFFA-$BFFB.
A good ref is http://www.atariarchives.org/mapping/
Most people just point the init to a RTS command somewhere in the cart
or OS address space. The INIT can be used but it is mainly there for
taking control of the computer early before the rest of the OS boot
routines run.
The start address is just low byte/high byte of your code start address.
i.e. if you have a program assembled to run starting at $A000 you would
have a $00 at $BFFA and an $A0 at $BFFB.
*BUT* the way you do it is up to you. I've had programs that ran from
low ram. I just put a move routine that relocated the code to low memory
then jumped to it. I've also done programs that allowed DOS boot and
transfer to DUP. I seem to recall using provisions in my EPROM
programmer to fill in the START and INIT data as well as boot flags.
For laughs and giggles since you have an XL, peek those locations to see
what they are and where they point. IIRC you can use the DUP Run from
location to transfer control to them from DUP.
Rick
Russg
will work with the Atari.
As Rick says, put the address of a RTS at
BFFE/F. Put a pointer to the run address
at BFFA/B.
Something like
10 *=$BFFE
20 .BYTE. 0,6
30 *=$BFFA
40 BYTE. 0,$a0
50 *=$600
60 RTS
70 *=$A000
80 START
90 LDA #0
100 STA $600
110 RTS
120 .END
Maybe something like that. Assemble it and
then burn it to the eprom.
Rick..... Did I get that?
electr...@optonline.net
I have a Willem programmer that I've been using to burn chips for NES
carts. Going to read these replies through and see what I can do.
Thanks very much for the info, appreciate it.
Tony
Rick Cortese
It is close for an Atari burner but after our posts Tony posted that he
is using a Willem programmer which changes things. I believe the Willem
programmer is for an IBM so it expects a binary image of a ROM and
wouldn't understand the load address header of Atari files. Segmented
files<?> are way beyond it too. Even if you do a binary load and
suppress the start/init to get rid of segmented files, you would still
put that six byte header on when you did a binary save to clean it up.
So Tony, the files created with an Atari DOS/DUP or most of the existing
carts converted to binary files will have those overhead bytes. Easy way
to clean them up on the Atari is just read the first 6 bytes of a file
and toss them, then read the rest of the bytes and save them. Another
way of doing it would be to use your EPROM burner's monitor to start
burning 6 bytes past the start of the file, i.e. something like give it
address $005 to $1005 to the range of the file to burn. I'm not familiar
with your particular burner so I don't know and am having a brain fart
this morning.
Anyway, a reasonable thing to practice with would be doing a binary save
of the built in BASIC, $A000, $BFFF and taking a look at that. The
header will be
$FF
$FF
;tells DOS binary load file so the next bytes will be
$00
$A0
;Start address of load
$FF
$1F
;$1FFF or 8191 bytes? Or should it be $00 $20? Been too long.
;from here on is the actual cart image.
Another way to insure the overhead bytes won't get into your file would
be to write it on an IBM with something like TASM. If you want the file
to run on an Atari you can set up the header bytes doing something
similar to what Russ did to place them there with the .byte directive.
electr...@optonline.net
Well, I'm really going to write the code on an 800xl and the port the
code to my pc, and then burn it to a chip using the willem
programmer.
I'll be porting the "assembled code" to my pc, (I'll be using Mac/65
assembler.)
Are there any examples of the autoboot header code on the web? I would
like to see how it looks in a real program.
Thanks again, I appreciate it.
Tony
Russg
> Are there any examples of the autoboot header code on the web? I would
> like to see how it looks in a real program.
>
> Thanks again, I appreciate it.
> Tony
The EPROM just has
the INIT and RUN locations that the OS looks
at on powerup. Disk programs have a header,
like Rick described, but that header isn't in
the Atari cart.
You have to burn to $BFFE/F and $BFFA/B
the pointers to INIT and RUN. Atari needs
no further info to function.
Writing the OBJ/COM file from Mac/65, you'd
have to simply get rid of the 6 byte header that
M65 produces, which would be easy. Can
do with a BASIC program to your .OBJ file.
eg.
10 CLOSE #1:CLOSE #2
20 OPEN #1,4,0,"D:FILE.OBJ"
22 OPEN #2,8,0,"D:OUTFILE.ROM"
30 TRAP 100
40 FOR N=1 TO 6
50 GET #1,X:REM DISCARD 6 BYTES
60 NEXT N
70 GET #1,X:REM GET REST OF FILE
80 PUT #2,X:REM WILL ERROR AT END OF FILE
90 GOTO 70
100 TRAP 40000:REM TURN OFF TRAP
110 CLOSE #1:CLOSE #2:END
electr...@optonline.net
I see. How would this above code look in assembly language?
I appreciate the help and info.
Russg
> I see. How would this above code look in assembly language?
>
> I appreciate the help and info.
I can't translate it easily, that's why BASIC is
useful. But here's a small example of Assembler
that moves the screen memory and display list
down below $A000, so that you can load
a cart into $A000-$BFFF. Just a short
example of Atari assembler.
10 CIOV=$E456
20 IOCB=$350
30 RAMTOP=$6A
32 *=$600
40 LDA #$0C
50 STA IOCB+2
52 LDX #$10
60 JSR CIOV
70 LDA #$79
80 STA RAMTOP
0110 LDA #03
0120 STA IOCB+2
0130 L1
0140 LDA EDITOR
0150 LDA L1+1
0160 STA IOCB+4
0170 LDA L1+2
0180 STA IOCB+5
0190 LDA #$08
0200 STA IOCB+$0A
0210 LDX #$10
0220 JSR CIOV
0230 LDA #$0C
0240 STA IOCB+2
0250 LDX #$10
0260 JSR CIOV
0262 LDA #$79
0264 STA $6A
0270 RTS
0280 EDITOR
0290 .BYTE "E:",155
0310 *=$2E2
0320 .BYTE 0,6
0330 .END
Rick Cortese
> On Jul 25, 11:28 am, Rick Cortese <ricor...@earthlink.net> wrote:
>
>>Russg wrote:
> Well, I'm really going to write the code on an 800xl and the port the
> code to my pc, and then burn it to a chip using the willem
> programmer.
>
> I'll be porting the "assembled code" to my pc, (I'll be using Mac/65
> assembler.)
This really helps. One more thing, are you using the cartridge or file
version that was distributed on the free version of SparatDOS?
You see if you are using the cart, it will occupy the $A000-$BFFF
address space you want your code to run from. This leaves you the option
of assembling to disk which means you would have to use a program like
Russ gave to strip the header.
I don't have a set up Atari set up at the moment: I tried to get my SDX
cart back from phantom but he doesn't respond to my emails or posts to
the newsgroup. Going from memory I used the byte directive and mem sav.
I also wrote all my code to be compatible with the Atari ASM/ED which
meant I didn't take advantage of the Mac special features. SOOOO what
should work is:
10 *=$A000; Start of cart address space
20 START; 16 bit label equal to $A000 in this case
30 RTS; OK, It doesn't do much Your LDA #0 stuff goes here.
40 INIT; Ditto except will be one byte more because of the RTS
50 RTS; Still not doing anything!
60 *=$BFFA; Move program counter to CART START address
70 .WORD START; will put the START $A000 at $BFFA-B
80 *=$BFFE; Same thing for INIT
90 .WORD INIT
You also have to set the cart flag for if you want to allow things like
DOS to boot. If you are writing a word processor for example, you would
want that to happen so you could save and load files.
Now from there what you want to do is boot w/o a cart installed, lower
ram top to under $A000, use binary load to load the file. Now do a
binary save of address space $A000-$BFFF and strip the first six bytes
like Russ showed and it should be a pure binary ready to burn.
You see if the burner were on an Atari, those extra steps would not be
necessary since when you loaded the file it would be in a contiguous
memory block with the header not taking up space. I think MAC allows you
to assemble with an offset so you can have the actual code at say $4000,
but I never used that feature.
>
> Are there any examples of the autoboot header code on the web? I would
> like to see how it looks in a real program.
>
> Thanks again, I appreciate it.
> Tony
Rick
electr...@optonline.net
Thanks. I am using the cart version of MAC/65. I will read through
this info, try to absorb and re-post.
Thanks again,
Tony
Lee
>
> - Show quoted text -
One thing you should keep in mind with MAC/65 is that it creates
heavily segmented output files. I believe there will be a file
segment every 80 bytes of actual data output and if I remember
correctly, the file segments will have full headers of their own. In
other words, within the file there will be:
FF
FF
00
30
7F
30
and then $7Fdata bytes here to be loaded from $3000 thru $307F and
then:
FF
FF
80
30
FF
30
again $7Fof data here for $3080 thru $30FF and then:
FF
FF
00
31
7F
31
again $7Fof data here for $3100 thru $317F and so until the end of
contigious code generation.
Short file headers also exist and are just as vaild, they only contain
the start and end code loading destination bytes without the double FF
"binary file type announcer" bytes.
Just something else to complicate things for you...
electr...@optonline.net
If I posted a very simple program that was assembled with mac/65 would
someone be able to add the code necessary to make a bootable eprom?
Very confused right now.
Thanks again for the info.
Tony
Rick Cortese
> On Jul 26, 4:00 am, Lee <mel...@my-deja.com> wrote:
>
>>On Jul 25, 3:57 pm, electrokr...@optonline.net wrote:
> If I posted a very simple program that was assembled with mac/65 would
> someone be able to add the code necessary to make a bootable eprom?
>
> Very confused right now.
>
> Thanks again for the info.
>
> Tony
Probably. Kind of a lot to absorb but it will become second nature after
a few looks at what goes on.
MAC/65 is a great assembler but it does have its quirks. I want you to
know that you are getting a lot of options thrown at you because there
are a lot of options for getting it done. We are kind of a liberal group
here so you may get a few but won't get a lot of 'My way or the
highway!!!' type posts.
There are even several ways to clean up the output that Lee mentioned.
There was a program published by ANALOG<?> and you can use a MEMSAV disk
which creates a file 'memory image' on your floppy so DOS and DUP don't
bump into your code when they function.
Rick
Mark Keates
<electr...@optonline.net> wrote in message
news:571c0c5a-4947-41f3...@c65g2000hsa.googlegroups.com...
> Well, I'm really going to write the code on an 800xl and the port the
> code to my pc, and then burn it to a chip using the willem
> programmer.
>
> I'll be porting the "assembled code" to my pc, (I'll be using Mac/65
> assembler.)
Wouldn't your best bet be to develop on the PC, test the cart image file
using emulation and then when happy burn this to chip and test it on a real
Atari?
You recently posted to the AtariAge forum but didn't follow-up there. Here
are two useful threads relating to cart development:
http://www.atariage.com/forums/index.php?showtopic=67762&mode=linear
http://www.atariage.com/forums/index.php?showtopic=115771&mode=linear
Elmo
news:ecSdnXKxwPdRFRLV...@posted.plusnet:
>
> <electr...@optonline.net> wrote in message
> news:571c0c5a-4947-41f3-aef0-22d19dbf31f2
@c65g2000hsa.googlegroups.com.
> ..
>> Well, I'm really going to write the code on an 800xl and the port
the
>> code to my pc, and then burn it to a chip using the willem
>> programmer.
>>
>> I'll be porting the "assembled code" to my pc, (I'll be using
Mac/65
>> assembler.)
>
> Wouldn't your best bet be to develop on the PC, test the cart image
> file using emulation and then when happy burn this to chip and test
it
> on a real Atari?
>
> You recently posted to the AtariAge forum but didn't follow-up
there.
> Here are two useful threads relating to cart development:
> http://www.atariage.com/forums/index.php?showtopic=67762&mode=linear
> http://www.atariage.com/forums/index.php?showtopic=115771
&mode=linear
>
>
>
There's a lil paperback book I found that describes in detail how to
make bootable carts and tapes.
It's called
HACKERBOOK for your atari computer, tips+tricks
by H.C.Wagner, Elcomp publishing 1983
A very handy book indeed, check Ebay!
~Mo