I'm writing this with the low quality Fast Basic built-in assembler... There are so many bugs that you must avoid, eg if you want to write something like "MOVEM.W addr(PC),D0-D4" then you must write "MOVEM.W addr-2(PC),D0-D4" to compensate for. the bug (I found that out the hard way!). Plus you can't do EXG R1,R2 if R1 or R2 is an address reg, you can't use absolute short address mode at all (annoying for those often-occurring raster interrupts), there is no optimising of BSR/BRA to BSR.S/BRA.S, and the Fast Basic program itself takes up about 300-400K! (I've just had to reboot after some of these lines were erased because of memory shortage, AND my ST has 1MB AND I don't use any desk accessories! Mind you, this prog needs 480K running space reserved). The crappy GEM windows and boxes style environment doesn't help, its so slow with the lame ROM screen redraws. All these faults even in my version which was one of the last ever made (the software house quit the ST scene). Despite this, I wouldn't buy DEVPAC 2, because it's so useful to have BASIC and assembly languages available at the same time. For example, if I want to make a sine table, I just write 3 lines of BASIC to put one wherever I want in my program, no messing about with loading other languages and saving files etc... also DEVPAC is too dear! Hi to everyone (anyone?) reading this message which has turned out to be quite long. I got a bit carried away! Why are you looking at this program anyway? Maybe you are wanting to know how to use the bottom border? I did the same! Or maybe you just like looking for hidden messages like this! If so, then if you hadn't thought of this already, try using the search feature on whatever you're using to look at this, and searching for the string "he" and "HE" in programs. That way, you'll find messages like this because "HE" is a common thing ("tHE", "tHEre", etc.) Well, I really better not strain my 1MB of memory any more - I've still to put the save feature in... Bye - C.E. No, that's not the end! I'm now writing this bit about 4 weeks later. What a disaster happened a couple of weeks back - see where it says that I had still to put the save in, well the disaster had something to do with that. The story goes like this... I had just written the save routine and so I decided to test it. What an idiot - I tested the save on the disk that I was working with... and because to routine was bugged, the disk died!!! To make matters ten times worse, I didn't know that there was a bug, because it seemed to save correctly at the time, and I went and ruined another disk (that my other programs are stored on) So that's 2 disks ruined, including the one that stored this very program. What's more, the last backup copy I had made was about 2 weeks old, and I had added a great deal since then. So I decided that I would have to salvage what I could from the trashed disk. I'll spare you the details, but it took a solid week's work to recover the program (I got about 99% of it back), and another few days to sort it out and make it runnable, cos it was a bit messed up. There's two valuable lessons there - make frequent backups and always test a save routine on a blank disk. Anyway, dry your tears because that's all in the past, and the program is practically finished now. It's the first really big program I've written, and I hope you like it. I also hope that you got this program off an ST Format or ST User cover disk, because that means that they decided to include it, and therefore paid me some money! If not, then you must have got this program from PD, because that's where I'll have to send it if none of the magazines want it. JESUS!!!!!! - I've just realised how much garbage I've written here. Congratulations if you actually read it all. I must go now, definitely.
lp wrote:I found the file and it certainly looks like handed coded assembler to me. My guess is he may of wrote it and debugged it in fast basic, then compiled it with some assm package in the end. Typically higher level languages don't have data segments in the middle of text segments, and there is nothing in there that looks like lib calls or standard startup sequences.
lp wrote:Yes, I am very familiar with GFA. As a matter of fact GFA's Compiler groups all the Inlines and every single line of text neatly at the end of the binary. Which is exactly my point about compiled basic. You generally have very little control over the resulting binary at all. Also basic compilers tend to leave distinctive marks like vdi or aes init sections, or some very basic starup code of some kind that is rather generic that you cannot stop it from inserting.
If phraqtal was compiled fast basic, it is the most advanced/flexible basic compiler I have ever seen. Having looked at a disassembly of phraqtal, that is my conclusion anyway.
lp wrote:I have found several reviews of all available basic's, they even go as far as saying that Fast Basic has the disavantage of not having a compiler.
When was phraqtal released? Because the reviews I read are dated around 1991, Fast Basic is reviewed right alone side of GFA which in the same review has the gfa v3 compiler and is thus rated as "alot faster".
Users browsing this forum: No registered users and 2 guests