Topic: BASIC 7 compiling question (using Blitz 128)

[ruthven]

Hey everyone.  Been a while since I've logged on here...my account must have been purged; I needed to re-register.  Though I never left in spirit!   Been side tracked by all sorts of things but I always keep coming back to the Commodore!  Hope everyone is well.

I'm back to working on my synthesizer program that many of you gave me programming advice on a few years back.  Actually, it was interesting for me to go through my old posts as I see that I've come full circle--really, I'm still interested in doing all the things that I had originally planned; incorporating the light pen as a control device and such.  Still haven't picked up any Machine Language yet--actually I was kind of daunted looking at the introduction to ML in the Programmer's Reference Guide.  So for starters, I'd like to see if compiling my BASIC 7 program will give me adequate speed.

But I'm having the same problem as I had when I tried a couple years back.  The compiled program doesn't work properly, only now I think I've narrowed the problem down.  I'm using Blitz! 128 and it will compile really simple programs just fine (like ones that just display a bunch of text on the screen using PRINT).  However, my main program that uses specialized BASIC 7 graphic commands doesn't work when compiled.  I had drawn out a panel using a combination of DRAW and BOX commands.  At the top of the screen I used a CHAR command to display some text, "please wait...loading".  In the compiled program, the text shows up at the top of the screen as it should, but no graphics.  Anyone know why this would be?  Is there another compiler I should use that would translate BASIC 7 commands into their proper ML equivalent?

[Hydrophilic]

Hi, its been a while!  I had problems with both Data Becker C128 Compiler, and with Blitz! compiler.  You can read a bit about it in this thread about game/simulation 'build a solar system'
 
I don't know if anybody has made a good BASIC compiler for the C128.  I thought about writing one myself, but sounds like a lot of work unless somebody (several somebodies) were willing to pay for it.
 
Anyway, since you tried Blitz!, you might as well try C128 Compiler (attached).  I tried a simple program that used bitmap graphics to draw a series of BOXs on the screen and it worked fine.  No gaurantee your program will work, of course!
 
The C128 P.R.G. is just terrible for teaching M.L.  Really only useful if you have M.L. experience from another type of CPU.  THere are several books you can find at bombjack about 6502 assembly that should be much more helpful.
 
The best ML book I've ever read (for any type of CPU) is by Jim Butterfield called ML for the C64 and other computers.  It might be at bombjack, but every version I've seen on-line is the original version.  For you (and all C128 programmers), I suggest the revised second edition which includes all the examples written for the C128 (and also the Plus/4 if I remember correctly).  I own that one, but the front and back covers fell off along ago due to heavy use!
 
 

[Maverick_LSC]

Personally, I like Oxford's PETspeed 128 quite a bit. I think it has the best compatibility to the 128's Basic 7.0
If you're sticking to Basic 7.0 and not dabbing into too much ML coding than I suggest you download PETspeed;

http://www.everythingcommodore.com/download.php?view.468

[Hydrophilic]

Thanks for the link.  I downloaded that to try it out and immediately was stumped by request for color codes.  Quick google search gave this document (at bombjack, naturally) which answered the questions.
 
With the compiler up and running, I let it go to work on Solar System... takes quite a while to go through 4 passes even on such a simple program.  Well at least pass 4 is quick!
 
Now to test it out... hopefully it is faster than Blitz! version...
 
It fails miserably.  The planets just go in a vertical line or jump "randomly" around the screen.
 
I was really hoping it would work... save me the trouble of writing a compiler... 
 
Anybody else have a suggestion?

[ruthven]

Thanks guys.  Had no idea it could be so trial and error with compiling BASIC 7 programs.  Is it like this for BASIC 2 as well, or are C64 BASIC compilers generally more accurate?  I'm thinking I might want to rewrite my code in C64 mode BASIC if it helps with compiling.  But first I'm definitely going to give those compilers a shot.  At first glance I'd say PETspeed 128 looks promising, though it's too bad it didn't work out for your simulation Hydrophilic (which by the way sounds amazing (downloading that later))--I'm still going to give PETspeed a shot cause you never know.  And on that note I'd like to try Data Becker C128 Compiler, only where exactly is it attached (couldn't find a link)?

I was really hoping it would work... save me the trouble of writing a compiler

Wow, I wouldn't ask THAT of you!  Worst case scenario, I'll just rewrite it for BASIC 2 (assuming that will work anyway if all else fails).  I'm actually thinking about doing the graphics differently now anyway--by BSAVING the result of my current program and BLOADing it in the new one.

[airship]

So I count three C128 BASIC 7.0 compilers in this discussion:

Data Becker/Abacus C128 Compiler
Skyles Blitz! 128
Oxford PETSpeed 128

Where there any others, or is that the whole list?

[tokra]

There's also Austro-Comp 128 according to http://www.pcmuseum.ca/details.asp?id=37390&type=software
I had good results back in the day with Austro-Comp for the C64, but never seen the C128 version of it

[Hydrophilic]

Ruthven, look at my first post in this thread.  Near the bottom, just above my signature you should see a D64 attached.  There is a manual on bombjack if memory serves correctly, but it is very easy to use so you shouldn't need it.  It even autoboots!  Just choose option 1 and follow the prompts.
 
Well I wouldn't write a compiler just for one request.  But I've been thinking about doing it for a while because I haven't found any good compilers... at least not good enough for me!
 
I did read the manual for PETspeed128, and although it doesn't strictly say it, it seems it should support both floating-point and integer variables.  It even has the data format the compiler uses for both floating-point and integer variables.  Based on the way it fails to animate the planets, it looks like the compiler is wrongly guessing some of the variables are integers instead of floating-point.
 
The manual says it automatically determines if a variable is floating-point or integer, even if you don't use X% to specify integer (but it will be forced to integer if you use X%).  The problem is, there is no way to force it to use floating-point!  I bet that would fix the problem...
 
If anybody has a link to Austro-Comp 128, please share.  I would like to try that one too.
 
Nice to hear from you Airship!  Compiling a list are you?  Yes, the 3 you listed, and now a 4th listed by tokra.

[RobertB]

Well I wouldn't write a compiler just for one request.

     Second request... 

          Truly,
          Robert Bernardo
          Fresno Commodore User Group
          http://videocam.net.au/fcug

[cbmguy]

Third request

Would it be worth building a x502 compiler for use in windoze, os x, linux, too?  Have a gui and select the target, then compile--make it extendable for BASIC 8 and all that?

C

[Maverick_LSC]

I'm sorry that Petspeed 128 didn't work out for you. I know that some compilers like Petspeed have certain exclusions that are not available under the compiler but are fully supported in Basic 7.0

Yeah, Petspeed can be picky. I'm sure Blitz 128 and Basic 128 have their problems too. But for myself i'm sticking to one compiler for now as I don't have the time to learn the specific intricacies of each compiler. If I focus on just one compiler, I get to learn what that particular compiler likes and dislikes in my code. 

Here's how I do it, I type a few lines of code at a time in Basic 7.0, save it, then compile it under Petspeed.

As the program becomes larger in size, I can catch the little differences between interpreted Basic 7.0 and Petspeed that introduces small errors to the program that if caught early on, I can correct them instead of leaving it to the end at the compiler stage when a compounding amount of small errors could look too difficult to debug looking like one huge pile of mess.

I don't write the whole program and debug it only in Basic 7, then leaving to test its compatibility in its compiling at the final stage. I use the compiler as a debugger as much as the interpreted basic in every error I encounter. Also once the program gets large enough it will take too long to use a real 128 to compile.

Therefore on my 128, i'm using the uIEC-SD as storage for my programs. Knowing that later as my program becomes larger I'll be switching to WinVice(x128) using warp mode to improve my workflow as the real 128 would then be too slow for compiling. But i'm still following a process that once I write a few lines of code I compile it right away onto that SD card.

After a laborious amount of time before i'm done for the night, I'll test the compiled program first in WinVice then in MESS. If it looks good I then transfer the SD card back onto my uIEC-SD that's connected to my 128 and test it once more just to be certain.

Yeah, the above method I use may seem like much. But I'm starting to think emulators are a good development environment to test compiled programs when frequent compiling is necessary since no 128 basic compiler is truly 100% compatible with Basic 7.0

To my knowledge, to compile so frequently such as this you really need a fast machine and a good emulator, outside of this and a 100% Basic 7.0 compiler would be the only other option.

Btw, I'm not sure but I think Petspeed can support the Basic 8 extension, I found this in the Petspeed 128 manual;

The % directive

This directive is provided to allow Petspeed to handle extensions to
BASIC provided by commercial packages or user written machine code.

Extended statements must take the form of a keyword optionally followed
by a number of parameters. For example, suppose that an extended BASIC
package provides the command

CLEAR S,N

where S and N are expressions specifying the start and size of an area
of memory to be cleared to zero. In the normal way, Petspeed would
throw this out as a syntax error. By preceding the statement with a %
sign however, the run time system can be instructed to have that
statement alone executed under the interpreter. for example

%CLEAR b+l,a(i)       would be perfectly acceptable

Even though the Petspeed run time system does call the interpreter to
execute such commands, because Petspeed variables are held in a special
format, the arguments of extended commands are subjected to some
processing at compile time and only certain command formats are allowed.

In general commands proceeded by % must consist of an optionally
tokenised keyword followed by up to ten parameters separated by commas,
semicolons or by the BASIC words TO and ON.

Am I right in thinking that both Abacus Basic 128 and Petspeed 128 could compile the Basic 8 extension for VDC programming?

[ruthven]

Ok, got busy for a couple days there but finally got a chance to try this stuff last night.

Ruthven, look at my first post in this thread.  Near the bottom, just above my signature you should see a D64 attached.

Thanks.  I must not have been logged in when I first saw your reply--seems your signature only shows up when I'm logged in.  So I put both Data Becker and PETSpeed to disk and tried them out on my program.  Data Becker produced a working program that was at least twice as fast as the original BASIC program.    Unfortunately PETSpeed didn't work for my program.  It took a while to compile, but when finished it only produced a 4KB "SEQ" type file that wasn't executable.  Maybe it just bugged out and I should try it again--I'm not necessarily surprised that it didn't work with my program, but the BASIC program itself is 37KB so you'd think the compiled file would be more than 4K after all the compiling time/disk access.  Speaking of compiling time, that's an excellent idea using an emulator to really speed up the process.  Actually, I had no idea compiling could take so long--I had only used Blitz! 128 up to this point, and that took about 1 minute to compile my code.  Data Becker took probably about 10-15 minutes and PETSpeed even longer.  And this is a relatively small program.

Anyway, I'm just glad to have a compiler that works with my code.  And it's good to have as many compilers as possible considering how they can be finicky about different things.  Funny how out of the three main compilers mentioned, each of us has success with a different compiler and not the others!  I may find that I have to move on to another compiler as my program progresses, depending on the way I code it.  So I should learn the intricacies of each.

[Hydrophilic]

Yeah, attachments are only visible to (logged in) forum members.
 
PetSpeed is a bit different than the Data Becker and Blitz compilers.  Although it creates several temporary files on the disk, it does not write the compiled program to disk!  At the end of compilation, it is in memory ready to run (or save).  So be sure to DSAVE the compiled program, and then of course RUN to test that it works
 
Maverick_LSC, thanks for detailing your development method.  It sounds brutally painfull.  I don't have that much patience...  Using VICE (or any emulator that can run faster than real-time) sounds like a virtual requirement.  For me, if it is going to take that much effort, I might as well write it in assembly language.  Takes longer to write than interpretted BASIC, but it seems about the same time as your method for compiled BASIC.
 
CBMguy, that is what I was thinking.  A compiler written in C that could be easily ported to different platforms... and easily changed to add features or fix bugs.  It would compile really fast on modern systems without needing an emulator.  Or somebody could port it to the C128 for those who like slow compilations on the real machine 

[cbmguy]

....  A compiler written in C that could be easily ported to different platforms... and easily changed to add features or fix bugs.  It would compile really fast on modern systems without needing an emulator.  Or somebody could port it to the C128 for those who like slow compilations on the real machine 

Ya.  Since I started to read the thread I've gotten a couple of methods finished for a BASIC compiler.  It's written in Java, however.  When my students are finished with their finals next month, I'll have some time to start on it again.  I've got a manager type app for the 128's vdc that I'd like to finish up, as well.  With two solid months of summer away from teaching, I might be able to get something accomplished.

c

[Maverick_LSC]

Hmmm, maybe this is a stupid question to ask, but could the compiler be NTSC or PAL specific?

ruthven wrote;

I'm using Blitz! 128 and it will compile really simple programs just fine (like ones that just display a bunch of text on the screen using PRINT).

So programs that use character graphics work fine. I think this wouldn't be a problem regardless of it's a NTSC or PAL C= machine.

then ruthven wrote;

However, my main program that uses specialized BASIC 7 graphic commands doesn't work when compiled.  I had drawn out a panel using a combination of DRAW and BOX commands.  At the top of the screen I used a CHAR command to display some text, "please wait...loading".  In the compiled program, the text shows up at the top of the screen as it should, but no graphics.

At my end, I'm using an NTSC machine and my graphics do compile well in Petspeed. In my thinking I assumed my copy of Petspeed was naturally supporting the NTSC commodore machines.

I didnt' ask the right question I think, is your target machine an NTSC version or PAL version?

I think that they're are versions of Blitz 128 that might be in german. Not sure, I didnt' check Blitz 128 but if they are then they should support only PAL.

Maybe the compilers are specific to ethier the NTSC or PAL machines, and not both!

Maybe a good way to test this out is to use WinVice and test your program out with both an emulated NTSC 128 and an emulated PAL 128 and see if there is indeed a difference. Perhaps your compiler is specific to one of these models.

Perhaps the Basic compilers mentioned above, some require an NTSC fix? Or PAL fix?
To fit your compiling needs.

[Hydrophilic]

Java is a good choice for portability.  No Java compiler for the C128 (AFAIK), but I'm thinking it shouldn't be hard to translate to C.  I've spent several hours simply documenting the BASIC commands on the wiki and yet I'm less than 50% finished; the thought of actually writing a complete compiler is not pleasant.  You've got some methods written already?  You're way ahead of me... I've only thought about writing code!  Good luck with that and your VDC app.
 
I don't think NTSC / PAL differences would matter for video, unless the compiler implemented a custom (split-screen) IRQ instead of using the one in ROM.  That seems like a great way to break compatibility or at least generate larger-than-neccessary code.
 
However it seems NTSC/PAL differences could show up in SOUND and PLAY statements, depending on how the compiler implements them.  I haven't run any experiments to demonstrate this, just a hunch.

[cbmguy]

Ah, I see what you're saying.  You were thinking about the compiling the compiler source, itself, on the C128.  Is that right?

[Hydrophilic]

Compiling on the C128 would be a neat option.  But just getting a good compiler on any platform should be the first step.  If it is written in a language like C or Java it would be easy to fix any bugs that crop up and easy to port to other systems.
 
Depending on how it is written, it could be a problem for the C128 itself due to the lack of file-seek in commodore dos; aka lseek().  This restriction applies to SEQ / PRG files.  Not a problem for REL files, but they operate quite different.

[ruthven]

At the end of compilation, it is in memory ready to run (or save).  So be sure to DSAVE the compiled program, and then of course RUN to test that it works

Ahh, that clears things up, thanks.  Unfortunately my code still compiles errors in PETSpeed--it gives me an error message both when trying to DSAVE or RUN.  Haven't gone through the debugging process yet to see what exactly is hanging it up.  That's ok though, I'm happy with Data Becker for now.

Hmmm, maybe this is a stupid question to ask, but could the compiler be NTSC or PAL specific?

Actually, I hadn't even thought of that...  could well be...

I didnt' ask the right question I think, is your target machine an NTSC version or PAL version?

My C128 is an NTSC machine.  My version of Blitz 128 is not German--or it's in English at least, but could still be a PAL version I suppose.  I haven't checked this in an emulator yet, mainly because it's such a pain to connect my 1541 to a PC for transfers due to my claustrophobic setup!  That's the next thing I'll try though.

However it seems NTSC/PAL differences could show up in SOUND and PLAY statements, depending on how the compiler implements them.

This is interesting to me considering the nature of my program, being a sort of GUI control for the SID.  For what I'm doing, I've found that POKEing the appropriate addresses works better than using PLAY/SOUND/etc., so hopefully I'll be fine there.