| Proofreaders Wanted - Aztec64 Cross-Development MKBASIC Utility Notes [message #210166] |
Mon, 12 August 2013 09:12  |
Bill Buckels
Messages: 1418
Registered: November 2012
Karma: 0
|
Senior Member |
|
|
I have again decided to come to the experts (you folks) and ask for
necessary corrections or comments about a draft document that I want to add
to the Aztec64 distribution.
One area in this document is somewhat vague, and that is what happens with
the 2 byte BASIC program header after the LOAD command strips-off the
initial 2-byte load address from a PRG. Is my assumption correct that C64
BASIC adjusts the offset by the 2 bytes used by LOAD?
Or can there be another explanation that I haven't thought of?
This MKBASIC Launcher utility can also be used with any BIN file with a load
address at $810 followed by a length field of 2 bytes (in 6502 short integer
format).
I guess I should also ask if there is some other program out there that does
the same thing this one does or similar?
Anyway, comments about errors and omissions, etc. are welcome either by PM
or posts.
Document follows below:
Regards,
Bill Buckels
x--- snip ---x
MKBASIC ReadMe - August 2013
============================
The MKBASIC Utility is an MS-DOS exe program that came with the Commodore 64
Aztec C65 cross-compiler, and is used to append a small Commodore 64 (C64)
BASIC Launcher program to the begining of an Aztec C65 BINARY machine
language program produced by the LN65 linker. The Aztec C65 Program must
have a base address of $810 (2064) after the Aztec C65 program has been
linked in order for MKBASIC to work:
i.e. ln65 $(PRG).rel FLTNAT.LIB C64NAT.LIB -b 810
Launcher Code Load Address - $0801
==================================
The Launcher Code produced by MKBASIC Loads at $0801 (2049) on the C64,
which is the lowest start address for Commodore BASIC programs. Loading a
BASIC program at the lowest possible address gives the maximum available
memory on the C64.
The first 4 bytes of the PRG file are 2 short integers with 2 values that
the C64 LOAD command uses to put a PRG into memory then to run it.
If you take a hex viewer to a PRG file after it has been produced by MKBASIC
from an Aztec C65 linked file, you will see $0801 (2049) in the first 2
bytes, which is the start address of the BASIC Launcher code (see above).
Launcher Code BASIC Program Length
==================================
The start address is followed by $080C (2060) in the next two bytes. This is
the ending address relative to the start address of the last byte of the
BASIC program in the file:
i.e. $801 + 4 byte header + length of tokenized BASIC bytes = $80C.
What actually ends-up in memory for the C64 BASIC OS to use takes place
behind the scenes, and I haven't written anything to test this, but it
appears that the initial 2 bytes (load address of $0801) are discarded
(having done their job) when the file is loaded into memory, but the next
two bytes ($080C) are used by the BASIC OS, perhaps being recalculated to
actual memory location as follows:
i.e. $801 + 2 byte header + length of tokenized BASIC bytes = $80A.
Launcher Code BASIC Program Meaning
===================================
The translation for the tokenized BASIC used by the C64 BASIC OS is as
follows:
10 sys 2064
In your hex viewer you can see the 5 byte string value " 2064"
following the BASIC token for the SYS command.
Executable C65 Machine Language Instructions - $0810
====================================================
If you compare the C65 linked program in your hex viewer to the PRG created
by MKBASIC you will see that 4 bytes (2 integers) have been removed, the
load address of $0810, and the file length of the C65 linked program,
respectively.
After that,the code is the same between both the C65 program and the MKBASIC
PRG:
C65 Length - 4 bytes + 17 bytes = MKBASIC Length
What the SYS 2064 code does:
2064 is $0810 which is the start of the Aztec C65 code. On the Commodore 64,
the SYS command is used to jump to an address in memory and start executing
machine language instructions, which is what the Aztec C65 code is: machine
language.
Comments
========
And that is the extent of my analysis on MKBASIC. I long ago lost the manual
for this compiler so have no further information to pass-on.
Bill Buckels
August 2013
|
|
|
|
| Re: Proofreaders Wanted - Aztec64 Cross-Development MKBASIC Utility Notes [message #210168 is a reply to message #210166] |
Mon, 12 August 2013 12:27  |
|
|
Originally posted by: Frank Buss
Bill Buckels wrote:
>
> One area in this document is somewhat vague, and that is what happens with
> the 2 byte BASIC program header after the LOAD command strips-off the
> initial 2-byte load address from a PRG. Is my assumption correct that C64
> BASIC adjusts the offset by the 2 bytes used by LOAD?
The offsets are absolute. See this page for a good description how a
Basic-Program looks like:
http://hkn.eecs.berkeley.edu/~mcmartin/ophis/manual/x51.html
To verify it, take a look at this Basic program:
1 A
2 B
I've entered it in Vice, then called the monitor and displayed the memory:
** Monitor 000 001
(C:$e5d4) m 0801
> C:0801 07 08 01 00 41 00 0d 08 02 00 42 00 00 00
You can see the first two bytes points to the address of the next line,
then comes the line number (all low/high format), then the
ASCII-character "A", then the 0 byte for the line ending and then the
next line the same, and the final two 0 bytes to mark the end of the
program.
I mounted a PC directory in Vice, with "Peripheral Settings->Drive 8",
selecting "Directory" and unchecking "Read/Write P00 files" (which
creates PRG files). From within Vice:
save"test",8
In a hex-editor, I changed the PRG start address to $0800 (changed the
first byte 1 to 0). When I load it like this:
load"test",8
The PRG start address is ignored and it loads it at $0801 instead of
$0800, but it doesn't adjust the pointers for the next lines. Of course,
loading this modified program with ",8,1" doesn't work anymore, unless
you insert a 0 after the first two bytes for the start address in the
program.
But it is interesting to note, that the Basic loader tries to fix wrong
Basic lines. I tried a minimal Basic-Program:
1 SYS2060
But instead of using three 0 bytes at the end (one for the end of line
marker, and one for the end of file marker), I used only two 0 bytes at
the end, and linking the next line to the two bytes, using the line end
0 byte twice (and $60, an RTS, as a sample assembler program) :
> C:0801 0a 08 01 00 9e 32 30 36 30 00 00 60
When entering this in the monitor, it works, but when trying to load
such a file, the loader adjusts the first $0a to $0b and doing other
strange things, which results in this memory dump:
> C:0801 0b 08 01 00 9e 32 30 36 30 00 11 08 00 00 ...
It creates a new empty line, with line number 0 (might be other
depending on what was in the memory previously) and overwrites the
beginning of the assembler program.
This correction even happens when you load it with ",8,1". But note:
when the first two bytes of the PRG file are "00 c0", which makes the
absolute start address $c000, and then loading it with ",8,1", it
doesn't change the bytes.
So I guess this is the shortest Basic header for assembler programs, if
you want to do a meaningful "list" and "run", too:
1 SYS2061
With this content (using the RTS again as a sample assembler program) :
01 08 0b 08 01 00 9e 32 30 36 31 00 00 00 60
Why does the MKBASIC tool use 2064, wasting 3 bytes of the precious memory?
--
Frank Buss, http://www.frank-buss.de
electronics and more: http://www.youtube.com/user/frankbuss
|
|
|
|
| Re: Proofreaders Wanted - Aztec64 Cross-Development MKBASIC Utility Notes [message #210169 is a reply to message #210168] |
Mon, 12 August 2013 13:20 |
Bill Buckels
Messages: 1418
Registered: November 2012
Karma: 0
|
Senior Member |
|
|
"Frank Buss" <fb@frank-buss.de> wrote:
> See this page for a good description how a Basic-Program looks like:
> http://hkn.eecs.berkeley.edu/~mcmartin/ophis/manual/x51.html
This is perfect Frank. I feel wiser already. I can rewrite my stuff properly
now.
> Why does the MKBASIC tool use 2064, wasting 3 bytes of the precious
> memory?
It was written in around 1983 by Manx probably to get the Commodore 64 Aztec
C65 compiler out the door... nobody around to ask anymore:)
Now that I understand exactly what this little loader is, I could set a
base address anywhere in a safe area. For now it is good to get a little
more documentation together, so thanks for all of the effort you put into
this explanation for me.
Your lesson on Vice's monitor and mounting directories was not wasted on me
either. It's been years since I last used Vice and generally my use has been
to test my Aztec C programs and nothing much more.
Pretty good analysis there fellah... my hat is off to you!
I am really pleased I asked the question instead of scouring for this info.
I am afraid I wasn't very organized this AM, but gained alot because of
that. Gotta be a little more thorough though so I don't put wrong info out
there.
Regards,
Bill
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Re: Proofreaders Wanted - Aztec64 Cross-Development MKBASIC Utility Notes [message #210199 is a reply to message #210195] |
Tue, 20 August 2013 08:47 |
dott.Piergiorgio
Messages: 166
Registered: March 2012
Karma: 0
|
Senior Member |
|
|
Il 19/08/2013 19:33, silverdr@wfmh.org.pl.remove.it ha scritto:
> Anssi Saari <as@sci.fi> wrote:
>> Frank Buss <fb@frank-buss.de> writes:
>>
>>> 2013 SYS EXP(7.64)
>>>
>>> wasting even more bytes :-)
>>
>> Just curious, but since EXP(7.64) returns 2079.74382, does that SYS jump
>> to 2079 or 2080? My guess is 2079, truncation instead of rounding.
>
> Well, you can always put $ea at 2079 ;-)
testing oneself the thing is the best answer:
81f LDA #$A9 ;trick here ! $A9= LDA imm
821 NOP
822 STA $0400 ;or whatever in the screen RAM you like
825 RTS
run with sys exp(7.64) and if a reverse paren appears, the sys lands in
2079, if appears a reverse graphic char the sys lands in 2080..
(wrote quickly under pressure of hungry cats, so I'm sure that there's
bugs, but the logic should be clear...)
of course, some more works is needed for eariler C64...
Best regards from Italy,
dott. Piergiorgio.
|
|
|
|
| Re: Proofreaders Wanted - Aztec64 Cross-Development MKBASIC Utility Notes [message #210203 is a reply to message #210199] |
Tue, 20 August 2013 12:53 |
|
|
Originally posted by: Frank Buss
dott.Piergiorgio wrote:
> testing oneself the thing is the best answer:
>
> 81f LDA #$A9 ;trick here ! $A9= LDA imm
> 821 NOP
> 822 STA $0400 ;or whatever in the screen RAM you like
> 825 RTS
>
> run with sys exp(7.64) and if a reverse paren appears, the sys lands in
> 2079, if appears a reverse graphic char the sys lands in 2080..
Nice, but this doesn't work on older C64 where the color RAM for empty
character positions is initialized with the background color from the
KERNAL ROM after reset (see the difference in kernal.901227-02.bin and
kernal.901227-03.bin on
http://www.zimmers.net/anonftp/pub/cbm/firmware/computers/c6 4/ ),
because the character could be invisible. You should set the color, too.
Another test: fill the memory from 2079 with 0 (BRK instruction, has the
same effect as run/stop-restore), call it, poke 96 (RTS) to 2079, call
it again.
--
Frank Buss, http://www.frank-buss.de
electronics and more: http://www.youtube.com/user/frankbuss
|
|
|
|
| Re: Proofreaders Wanted - Aztec64 Cross-Development MKBASIC Utility Notes [message #210205 is a reply to message #210203] |
Wed, 21 August 2013 06:38 |
dott.Piergiorgio
Messages: 166
Registered: March 2012
Karma: 0
|
Senior Member |
|
|
Il 20/08/2013 18:53, Frank Buss ha scritto:
> dott.Piergiorgio wrote:
>> testing oneself the thing is the best answer:
>>
>> 81f LDA #$A9 ;trick here ! $A9= LDA imm
>> 821 NOP
>> 822 STA $0400 ;or whatever in the screen RAM you like
>> 825 RTS
>>
>> run with sys exp(7.64) and if a reverse paren appears, the sys lands in
>> 2079, if appears a reverse graphic char the sys lands in 2080..
>
> Nice, but this doesn't work on older C64 where the color RAM for empty
> character positions is initialized with the background color from the
> KERNAL ROM after reset (see the difference in kernal.901227-02.bin and
> kernal.901227-03.bin on
> http://www.zimmers.net/anonftp/pub/cbm/firmware/computers/c6 4/ ),
> because the character could be invisible. You should set the color, too.
I known... but cats can't wait more, so I have preferred to assume that
everyone known about older firmware and leave implicit the need of one
more LDA/STA...
Best regards from Italy,
dott. Piergiorgio.
|
|
|
|
|
|
Members
Search
Help
Register
Login
Home
