#Turbo-Amiga
7 messages in this thread
Bela, you're right, its not too difficult to convert AmigaBASIC to
TurboBASIC (68020/68881 AmigaBASIC). I've done all the mods and
re-arranged the code so it all fits in a small block of AmigaBASIC's
main code hunk. I'll upload a file showing how this can be done along
with the replacement code — I'm not promising when I'll do this though,
only that I will do it as soon as possible. I'm spending most of my
time in an attempt to make TurboBASIC work properly at 14.32 MHz with
32-bit memory since (once accomplished) this would make TurboBASIC a
truly outstanding product.
I've been tracing in detail the code thats executed to do 'print time$'
and 'print date$' in an attempt to figure out what goes awry when
using CSA's extended 32-bit memory. A 'print time$' will give '18:10:30'
,for example, with the program in the 'normal' Amiga memory space, but
it prints '[[[[[[[[' when the program is in CSA's 32-bit extended
memory. I haven't found the problem source yet but I have modified the
code to use the 68881 for the DateStamp time and date conversions. I'm
a bit frustrated because I have a feeling the problem is simple but I
just haven't been able to find it.
Till Later …. Al Aburto
So AmigaBASIC does run on the Turbo-Amiga at 14.32MHz, but screen output is
wrong? Is it possible that AmigaBASIC is using the high byte of certain
addresses to store related data (i.e. assuming that it's running on a 24-bit
address bus)? I'd expect a guru from that, though, or at least more
spectacular symptoms. Are all print statements affected or only time$/date$?
>Bela<
Bela, All the print outputs do the same thing. Also AmigaBASIC can't
find files from CSA's memory location. It does wierd things but it doesn't
crash. It just seems lost.
Al Aburto
Bela, yes AmigaBASIC does work in CSA's memory ($7F000000 and above),
it just doesn't work properly. All the 'print' command outputs are
messed up although characters typed into the BASIC or EDIT windows
are Ok. Also any commands that deal with disk files won't work ('files',
'save','load' all result in AmigaBASIC reporting an error of some kind
like 'file not found'). I can type in a test program and it 'appears'
to run Ok but I can't save it and the printouts are not meaningful. These
are pretty serious problems which make AmigaBASIC nearly useless on
the Turbo-Amiga. True Basic doesn't work with the Turbo-Amiga either, but
thats another story.
There is some code like: ANDI.L #$00FFFFFF,D0 and MOVEA.L D0,A0
which I thought was highly suspicious but when I changed it, all it
accomplished was to make AmigaBASIC's 'Beep' a couple of octaves lower.
This kind of stuff is Ok as a safeguard because Amiga's Operating System
is after all in the memory range $00FC0000 to $00FFFFFF. Perhaps
Microsoft is using the upper 8 bits of the address registers to hold
program information but I haven't seen any signs of this — at least
not yet. I hope they don't do this sort of thing!
Till Later …. Al Aburto
ANDI.L #$00FFFFFF,D0 / MOVEA.L D0,A0 is, as you say, >highly< suspicious. Have
you traced through to that point to see if the contents of D0 before that
operation had something other than 0 in the high byte? That would seem to
indicate their use of the high part of the address for other information, which
would certainly screw up the CSA board! That's if they're making the
assumption that the high 8 bits don't matter. The alternative is that they're
using them for something but they >do< think they matter, which is why they
mask them off with the above code. Have you searched AmigaBASIC for further
occurrences of the bytes 00 FF FF FF? Maybe the problem is that it's
overzealously zeroing the high byte of addresses that really are validly above
$00FFFFFF. Removing the AND probably won't entirely fix the problem because
they are doing that AND for a reason — probably using the high byte for
something else — and you have to fix that code to use some other storage for
that information. Ugh. Good luck! >Bela<
Gosh Bela, thanks! I'll check D0's contents prior to its being AND'ed
with $00FFFFFF — that should tell me something! I kinda think now
that your suspicions are correct though. I'll know for sure shortly.
I did locate the routine that does the actual printing to the BASIC
window. A bunch of BSR's and then finally a JSR to _LVOSendIO(A6) I
believe. It won't be long before I know why its messing up in CSA's
extended memory.
Thanks Bela.
Till Later …. Al Aburto
Al, I just a few minutes ago (in response to Bela's message) loaded in a new
FileZap program (should be in DL 9 by tomorrow), and did a quick search on $00
FF FF FF. Found about 7 or 8 of them, and one was on an odd boundary. Probably
nothing, but you never know.
Regards, Larry.