From: Baltissen, GJPAA (Ruud) (ruud.baltissen_at_abp.nl)
Date: 2004-12-13 09:57:28
Hallo allemaal,
Thanks for the great response during last weekend !!!
Hallo Patryk,
> The best I have encountered on a 64 was "Basic Boss" AFAIR the name.
> Should still have both the software and the documentation somewhere.
Never heard of it but others mentioned that it is a good one. I hope you
have found it when we meet.
Hallo Groepaz,
> speedcompiler and blitz! also had their uses
If you have them and could send me a copy, I would be very greatfull !!!
"Astro compiler" just popped up in my mind. Anyone?
Hallo Steve,
> The reason is surely that float storage looks like
> .....
Needing FP I started studying the way the C64 stores them. But finding the
routines to display and convert them I didn't pay any attention to the
structure anymore. Thanks for the clarification.
> There's no real reason to use the basic routines -- which
> really aren't _kernal_ routines,
You are absolutely right.
> As you point out they will be far, far slower,
I did several "writeln"s in a row and indeed was a bit disappointed but ....
> and may even take up more memory.
.... it was just placing each char of the text into Y and calling a routine.
FYI: I handle strings myself as a) Pascal strings have another structure and
b) it allows me to handle user specific wishes regarding the format.
> :loop ApplyL LDA ;lda arg_left
> ......
> Surely something similar would work for you?
Yep. Spiros example revived some memories. When I started writing the
compiler, I generated ML with the parser. In fact my routine looked like:
loop lda addr1,X
and addr2,X
sta addr3,X
dex
bpl loop
And IIRC I even mentioned using this routine with the remark that it could
be used for more purpose by changing the operator as well on the fly (AND in
this case). But ....
To use the above subroutine I have to do this:
lda addr7
sta addr1
lda addr8
sta addr2
ldx #size
jsr Loop
lda addr3
sta addr9
The subroutine itself takes 14 bytes (incl. ldx #size), the above routine 23
!!! So its clear to forget using the subroutine as so.
This was one of the problems I faced and in fact this particular one made me
change my mind how to generate ML: not directly but through macros. The idea
was to shift the generation of ML and the optimization of it into the
future, which is now.
> I'd be happy to write something in Slang for comparison purposes too.
Thanks for the offer! I'll notify you when I'm so far that I can start
comparing things.
Hallo Spiro,
> But you can transfer anything into the FAC,.....
I use these routines at the moment:
.eq AscFloat = $BCF3
.eq Byte2Real = $B3A2
.eq ChrGot = $0079
.eq FAC2ARG = $BC0C
.eq FACplusARG = $B86A
.eq Int2Real = $B395
.eq Long2Real = $BC4F
.eq Real2Long = $BC9B ; result at $62
.eq Real2ZStr = $BDDD ; result at $0100
.eq SignFAC = $BC2B ; negative: A = $FF, pos: A
= $01
.eq ScrOut = $E716 ; out put char in A
.eq Word2Real = $BC49
> and output the string ($AB1E)
Don't use it yet, see above.
> but in general, I would prefer speed over size.
>...
> Possibly, Ruud might want to let the user decide what he prefers?
I already planned using a compiler directive for this. But my first goal is
to get the compiler running at all, then size and then speed.
> Graig wrote:
> > There's a routine to print unsigned .AX at $BDCD but it can print
> > peek(62)+256*peek(63) if you call it at $BDD1. This is in the Basic
> > ROM, so Steve's suggestion to stick with the Kernel if you're wanting
> > to write more all-around code still applies.
>
> Furthermore, that routine - as almost all other routines in BASIC, too -
> utilizes FP. It first converts the integer to FP, then it converts the
> FP to ASCII, and then it prints out the ASCII.
But when going for size, information like that is more then welcome.
--
___
/ __|__
/ / |_/ Groetjes, Ruud
\ \__|_\
\___| URL: Ruud.C64.org
=====DISCLAIMER=================================================================
De informatie in dit e-mailbericht is vertrouwelijk en uitsluitend bestemd voor de geadresseerde. Wanneer u dit bericht per abuis ontvangt, verzoeken wij u contact op te nemen met de afzender per kerende e-mail. Verder verzoeken wij u in dat geval dit e-mailbericht te vernietigen en de inhoud ervan aan niemand openbaar te maken. Wij aanvaarden geen aansprakelijkheid voor onjuiste, onvolledige dan wel ontijdige overbrenging van de inhoud van een verzonden e-mailbericht, noch voor daarbij overgebrachte virussen.
The information contained in this e-mail is confidential and may be privileged. It may be read, copied and used only by the intended recipient. If you have received it in error, please contact the sender immediately by return e-mail; please delete in this case the e-mail and do not disclose its contents to any person. We don't accept liability for any errors, omissions, delays of receipt or viruses in the contents of this message which arise as a result of e-mail transmission.
Message was sent through the cbm-hackers mailing list
Archive generated by hypermail pre-2.1.8.