Programming in C using only a real CPC : PhrozenC is out ! :)

[norecess]

I don't know what FIOLIB is. But I don't see why it could not?

[TFM]

I don't know what FIOLIB is. But I don't see why it could not?

The FIOLIB is the IO-LIB for FutureOS, take a quick look here:
http://www.cpcwiki.eu/index.php/FIOLIB

Beside the usual functions it has additional fuctions like: circle, cls, plot, draw, mode, pen, ink...

It works with Small-C, but it would be interresting to see it working with PhrozenC. Guess it could boost it, if they work together.

[AMSDOS]

I was reading that this compiler is based on Small-C, so it should work, though when I was working with Small-C I had to use COMFU to convert the COM file into a FutureOS file. I'm guessing that if the output files PhrozenC makes are different (e.g. BIN) they would need to be converted into .COM files in order to make them FutureOS if the SMC files have a different structure. Otherwise if Assembly is produced and can be compiled into a COM file that way, it would be easier to produce the SMC file.

Unfortunately I cannot seem to get a copy of PhrozenC just to see - all the links to it appear to be dead, including the one on CPCWiki.

[Munchausen]

You can still get PhrozenC, and the manual, at CPCRULEZ &#9733 CODING &#9733 CROSSDEV &#9733 PHROZEN C by NORECESS{UK}


I'd like to have a bash at this soon too. However, for bigger productions it looks like SDCC is definitely the way to go, see the awesome tutorials over at http://www.cpcmania.com/Docs/Programming/Programming.htm

[TFM]

I was reading that this compiler is based on Small-C, so it should work, though when I was working with Small-C I had to use COMFU to convert the COM file into a FutureOS file. I'm guessing that if the output files PhrozenC makes are different (e.g. BIN) they would need to be converted into .COM files in order to make them FutureOS if the SMC files have a different structure. Otherwise if Assembly is produced and can be compiled into a COM file that way, it would be easier to produce the SMC file.

Well, COMFU (like COMAM) does just one thing: It adds an 128 Byte Header to the file. Since Amsdos / FutureOS do like at .COM files like at ASCII files, then need to get a header.


If PhrozenC produces already a binary output file, then it should be possible to start it directly without the need of using COMFU or COMAM. So things would be more easy, but I never gave it a try for lack of time reasons.[nb]And sadly this nice PhrozenC seems not to be updated any longer.[/nb]

[AMSDOS]

Well, COMFU (like COMAM) does just one thing: It adds an 128 Byte Header to the file. Since Amsdos / FutureOS do like at .COM files like at ASCII files, then need to get a header.


If PhrozenC produces already a binary output file, then it should be possible to start it directly without the need of using COMFU or COMAM. So things would be more easy, but I never gave it a try for lack of time reasons.[nb]And sadly this nice PhrozenC seems not to be updated any longer.[/nb]

Ok, I wasn't sure if the Headers were structured differently in those Operating Systems, which was why I was querying about it. Earlier on when I was using Small-C to make Future-OS programs, I was using COMAM to put a header to the file, though when I was going to load it, it wasn't displaying the Small-C Program icon and displaying some funny Header blocks, even though I renamed it with the SMC extension.

[AMSDOS]

You can still get PhrozenC, and the manual, at CPCRULEZ &#9733 CODING &#9733 CROSSDEV &#9733 PHROZEN C by NORECESS{UK}


I'd like to have a bash at this soon too. However, for bigger productions it looks like SDCC is definitely the way to go, see the awesome tutorials over at http://www.cpcmania.com/Docs/Programming/Programming.htm

Well I noticed that Phrozen C supports FOR Loops, so I guess it supports WHILE loops as well (as Small-C Does), and from the manual it looks as if it's easier to incorporate C Declared Variables into Inline Assembly, which found really awkward to do from Small-C.

[Munchausen]

Well I noticed that Phrozen C supports FOR Loops, so I guess it supports WHILE loops as well (as Small-C Does), and from the manual it looks as if it's easier to incorporate C Declared Variables into Inline Assembly, which found really awkward to do from Small-C.

Did you read SDCC as small C? I think SDCC is better because it supports the full C spec (modern, not K&R), unlike Phrozen-C and Small-C, and has a full optimiser so makes much better code.


Of course, it doesn't run on the CPC so you must build your code on the PC and copy it over (though, it suddenly occurs to me that if you had enough RAM you could build SDCC for the CPC using SDCC and run it locally... madness!)

[AMSDOS]

Did you read SDCC as small C? I think SDCC is better because it supports the full C spec (modern, not K&R), unlike Phrozen-C and Small-C, and has a full optimiser so makes much better code.

No, I'm the guy that made 2 demo programs for FutureOS using Small-C & FIOLIB. 

Granted SDCC is better, though I play around with more inferior languages. 

Of course, it doesn't run on the CPC so you must build your code on the PC and copy it over (though, it suddenly occurs to me that if you had enough RAM you could build SDCC for the CPC using SDCC and run it locally... madness!)

Not to mention that if it's a PC based language, the code is optimised to strictly target specific code which is used for the program instead of just plonking in a 5-6k Library file with everything in it?

[Munchausen]

Sorry, you changed the topic from sdcc to small-c and confused me (I didn't say anything about for loops or inline assembly) 

[AMSDOS]

Sorry, you changed the topic from sdcc to small-c and confused me (I didn't say anything about for loops or inline assembly) 

Sorry I was referring to Phrozen C and some of the features it had which Small-C doesn't support and unfortunately I forgot to edit your comments about SDCC out. Though I'm sure that SDCC can do all that and more I guess. At this point of time though I'm only doing small scale C stuff.

[AMSDOS]

Hi, here my wired question again... anybody tried the FIOLIB with PhrozenC? I can't program C, only Z80, so I really don't know how to test it.

I got around to trying PhrozenC today and noticed some superficial differences from Small-C, in my test programme I had from Small-C I had to change the #include statement so the filename was in inverted commas ("") and when I got around to Assembling the resulting Source Code, assembly from the small-c include file had to be altered so hexadecimal begins with the ampersand (&), because PhrozenC uses Maxam or Winape Assembler.
I also noticed that PhrozenC has ditched the ".h" files which Small-C had and simply includes other c header files with addresses defined within. The additional library files PhrozenC uses has changed some of the routines names as well.


During todays experience I was trying to use a Library file I had from Small-C with PhrozenC, but in frustration I chucked it out and focused on the PhrozenC Libraries instead. Most of the stuff I needed was present, one of the routines I had to modify from the original Small-C 'putchar();' and I was able to include other routines to generate Random Numbers and simple Screen Scrolling using SCR HW ROLL.
The only other trouble I had was trying to Redefine Characters working and I wanted to setup a Place using an Array to hold the Matrix Data (PhrozenC's way of saying SYMBOL AFTER xxx) to cater for more Redefined Graphics. Eventually I managed to get one working with the Array by looking at how other Firmware Library routines handled it when HL & DE registers were POPed and PUSHed before CALLing their relevant routines, and all I had to do was specify from which Character Number I wanted to use and point to the Name of the Array (without specifying a specific spot).
The Generated Assembly file was 12kb in size, with a number of extra routines chucked in for the Ride, though even when I finally got the code working, I was still poking about with the Source Code, changing ints to char which didn't seen to bother PhrozenC in the context of having Integer based combining with Char byte types. Once I was happy with the final code, the resulting StarScrl Demo was just over 700 bytes in length.