Small-C help needed

[TFM]

Can somebody transfer that into Small-C please?
 
for x=1 to 100
 
draw(x,y);
 
next
 
 
 
Or does anybody have a serious manual of the set of commands of Small-C (not SDCC)?
 
Any kind of help appreciated.
 

[mr_lou]

I don't know Small-C, but surely if it's called anything with C, then a for-loop looks like this:

for(int x=1;x<=100;x++) {
draw(x,y);
}

Or, define x first:
int x;
for (x=0;x<=100;x++) {
draw(x,y);
}

Or, if Small-C doesn't have ints because it's small, then try:
unsigned short x; // or maybe even unsigned char x;
for (x=0;x<=100;x++) {
 draw(x,y);
 }

[TFM]

Slowly I got the impression that Small-C has no for() command.... I try to try it using while...
 
Edit:
 
This routine shall plot 100 * 100 dots, to check the speed of the routine. But it doesn't work. Any idea why?
 

Code: [Select]

/*

FPLOT2.C - 18.12.2011 - 54 Lines

FPLOT.C is a simple benchmark for the PLOT command
of the FIOLIB for Small-C (Amstrad CPC & FutureOS).

compile (under CP/M):
  A>cc -M fplot
  A>zmac fplot=fplot
  A>zlink fplot=fiolib,fplot,printf1
  A>comfu fplot
COMFU.COM converts FPLOT.COM to FPLOT.SMC
by appending an 128 byte FutureOS file header.
*/

#include fiolib.h
#include printf1.h
int x,y;
main()
{;
 mode(2);
 pen2(1);
 printf("Let's PLOT 100 * 100 dots...\n\n");
 x=0;
 y=0;
 while (y<=100);
 {
     while (x<=100);
     {
         plot(x,y);
         x++;
     }
     x=0;
     y++;
 }
 printf("Well, that's the END for today...\n\n");
 byebye();
}
 
[nocode]
 
 

[mr_lou]

The only thing that looks odd to me, is the pen2(1) line. Shouldn't it just say pen(1);?

Being small, it's probably also possible that the definitions of x and y should be placed inside main() instead of outside.

Otherwise I don't know either.

[Morn]

Isn't it supposed to be

#include <fiolib.h>
#include <printf1.h>

or

#include "fiolib.h"
#include "printf1.h"

??

Z88Dk is based on Small-C and with the exception of multidimenionsal arrays, it supports all normal C features, including "for" loops.

Which compiler are you using, TFM?

[TFM]

The only thing that looks odd to me, is the pen2(1) line. Shouldn't it just say pen(1);?

The command may be a bit misleading. It changes the text style.
 
pen2(n)
int n;
Selects character attributes for SCREEN MODE 2. Integer n must be between 0
and 4. So you can use normal, italics, underlined, inverted and streaked out
character attributes.
Only the character-attributes for MODE 2 are changed!!! The PEN's for Mode 0
and 1 aren't changed!

Being small, it's probably also possible that the definitions of x and y should be placed inside main() instead of outside.

Tried it, doesn't change it. Must be something else. I try a debugger now ;-)
 
 

Isn't it supposed to be

#include <fiolib.h>
#include <printf1.h>

or

#include "fiolib.h"
#include "printf1.h"

??

Z88Dk is based on Small-C and with the exception of multidimenionsal arrays, it supports all normal C features, including "for" loops.

The including works fine, no errors in compilation (or elsewhere).
 
 

Which compiler are you using, TFM?

Small-C for Z80. See here: http://www.colorado-boys-muenchen.de/users/futureos/files/FIO.zip
 
 
Thanks' for the help guys, it must be something I don't know now. Time to use a debugger, that's assembler, and nothing can stop me there ;-)
 

[AMSDOS]

Hope nobody minds me reusing this old thread   

I was checking out Juergen Weber's CPCIOLIB and was trying to find some documentation for it when I found another Small-C library which was written back in 1985 called AMS.LIB by J.M.H.Hill, which had it's own little Documentation. Both libraries look pretty good with AMS.LIB having the edge cause it's got a Random Number Generator included with it. JWs doesn't appear to have this which is a shame because it looks as if it's easier to add routines to CPCIOLIB if one needs to.  Has anyone used these or built similar libraries to include extra stuff?

[TFM]

Welcome to this thread! Good choice!
 
Actually I did use CPCIOLIB as base for FIOLIB.

[AMSDOS]

Welcome to this thread! Good choice!
 
Actually I did use CPCIOLIB as base for FIOLIB.

Thanks, my only regret is C isn't second nature to me and initially I only started using C after I finished school and into further education. So the teacher wasn't particularly helpful unfortunately and I think in the end they had it in for me.  :'( Later on (years ago) I made a simple demo using Small-C, which worked. So now I'm going to try write that little Star Scroller program in Small-C, so it's another box ticked for it.  Perhaps from that it could be ported to FIOLIB?

[AMSDOS]

Ok, I've got to a stage with my starscrl program in Small-C where I'm trying to redefine characters 254 & 255, so it looks like a starship, but for some reason my redefine characters are not being redefined and I cannot find what is wrong with my code, because it's coming up error free in the compilation.  :'(

The problem is I'm not sure if it's the matrix routine I made from the modified CPCIOLIB.C which is at fault, or my setup routine from my starscrl.c program (obviously I've got the data in arrays p1 & p2, which I haven't included here). I've added the oscall routine (which works fine) just as a reference.

What I've tried to do is setup pointers and have paddr1 & paddr2, the routine I'm using from the Firmware is TXT SET MATRIX (&BBA8 or 48040), which has the character in A and the Address of the Matrix is in HL, so what I've tried to do is use paddr1 to point to the address of p1[0] for example and likewise for paddr2, but the program is simply displaying the original graphic symbols for 254 & 255.  :'(

Unfortunately I'm limited in what I should be doing here and I guess if I cannot do it this way, I could try using control codes through putchar to hopefully redefine it that way.

Code: [Select]

matrix(ch,table) int ch,*table;
{
 regs[0]=ch<<8;
 regs[1]=table;
 oscall(48040,regs);
}

Code: [Select]

setup()
{
int p1[8],p2[8],paddr1,paddr2;
paddr1=&p1[0];
paddr2=&p2[0];

/* Set p1 & p2 with data for the object */

matrix(254,paddr1);
matrix(255,paddr2);
}

Code: [Select]

oscall(adr,regpack)
int adr;
int *regpack; /* af,hl,de,bc */
{
#asm
 pop bc  ; ret
 pop de  ; regs
 pop hl  ; adr
 push hl
 push de
 push bc

 ld (031h),hl  ; rst 30h: user
 ld a,0c3h
 ld (030h),a

 push de
 ex (sp),ix

 ld l,(ix+0)
 ld h,(ix+1)
 push hl
 pop af

 ld l,(ix+2)
 ld h,(ix+3)
 ld e,(ix+4)
 ld d,(ix+5)
 ld c,(ix+6)
 ld b,(ix+7)

 ex (sp),ix

 rst 30h      ; execute os-call

 ex (sp),ix

 ld (ix+2),l
 ld (ix+3),h
 push af
 pop  hl
 ld (ix+0),l
 ld (ix+1),h
 ld (ix+4),e
 ld (ix+5),d
 ld (ix+6),c
 ld (ix+7),b

 pop de
 JP  CCSXT   ;move A to HL & sign extend

#endasm
}

[AMSDOS]

Well I managed to get something to go in Small-C. I'm unsure if my problem earlier was to do with not having a matrix table setup, though after redefining a simple Matrix routine to redefine text graphics using Control Codes, it wasn't working until I made a matrix table.

[TFM]

That's pretty nice! Give it a try using FIOLIB and it's PLOT function for a speed up!
 

[AMSDOS]

That's pretty nice! Give it a try using FIOLIB and it's PLOT function for a speed up!

Hmmm, I've had a go at it and it's compiled without error, though when it comes to running the thing it resets back to BASIC. Unsure if the program is the error or if I'm running it incorrectly. The program also reserves some memory (around &4000, for the matrix table for my redefined ship), and I understand the plot is different from the firmware plot (0,0 is the top left corner), pen0 to use pen in mode 0. At the moment I had to take out the Graphics Pen cause the library doesn't appear to have one.

[TFM]

Hmmmm.... if you can post your source here, then I will try to have a look at it... Never mind, I'm not into C at all, so maybe the lib itself it the problem...

[AMSDOS]

Hmmmm.... if you can post your source here, then I will try to have a look at it... Never mind, I'm not into C at all, so maybe the lib itself it the problem...

Ok I found the problem, No Firmware. From my original Small-C program it's using TXT SET M TABLE (&BBAB) - this specifies where the table can go in memory before redefining that character set, more or less a SYMBOL AFTER 254 it does. I'm also using SCR HW ROLL (&BC4D) which rolls the screen 8 pixel rows & I'll also need to be able to do a GRA SET PEN (&BBDE) to change the Graphics Pen. I'm using control characters to redefine the symbol.

In order to make that work in FutureOS, I'll need to know what the equivalent is before I can proceed.

[TFM]

In order to make that work in FutureOS, I'll need to know what the equivalent is before I can proceed.

Hmm.... there is no directly 100% analogue thing like GRA PEN. But what exactly do you need?
 

[AMSDOS]

Hmm.... there is no directly 100% analogue thing like GRA PEN. But what exactly do you need?

To simulate the Stars and the different colours (White & Grey), I need to randomly alternate the different Pens to generate those stars. I had a look at the FTEST.C program and it looks like the PEN0,PEN1 & PEN2 commands will change that anyway as well as changing the Text (PEN) as well.

Though it looks like it will be harder to Redefine the space ship, the original program simply redefines characters 240 & 241. In the Small-C AMSDOS version I had to setup an area (equivalent to SYMBOL AFTER), to put the Redefined Graphics, though I guess there's nothing like that in FutureOS? I have made other versions which plot in the Space craft which I could probably work out the equivalent graphic positions for the Text co-ordinate positions, which should work if the plot is fast enough.

I'll also need to Scroll the Screen from Top to Bottom 8 pixel rows. If Control Codes are available I can possition the Cursor to the Top of the Line (1,1) and do a VT ( chr$(11) ), to sent the Cursor up one line.

Those are the 3 main things I'll need to be able to do to simulate that program.

[TFM]

To simulate the Stars and the different colours (White & Grey), I need to randomly alternate the different Pens to generate those stars. I had a look at the FTEST.C program and it looks like the PEN0,PEN1 & PEN2 commands will change that anyway as well as changing the Text (PEN) as well.

Yes, they use Pen 0, 1 or 2. So you select the pen by selecting the function PEN0, PEN1 or PEN2. (There is no PEN function for backgournd color).
 

Though it looks like it will be harder to Redefine the space ship, the original program simply redefines characters 240 & 241. In the Small-C AMSDOS version I had to setup an area (equivalent to SYMBOL AFTER), to put the Redefined Graphics, though I guess there's nothing like that in FutureOS? I have made other versions which plot in the Space craft which I could probably work out the equivalent graphic positions for the Text co-ordinate positions, which should work if the plot is fast enough.

Well, I have to look how FIOLOB does it. But in general you can place your own character set to address &3800 to &3FFF (this is where the character set is located in the lower ROM). And to activate the RAM character set you have to alter RAM variable RAMCHAR
 

RAMCHAR EQU &B847
RAMCHAR  ;Screen-Mode and RAM/ROM-charset selection.
;Bit 0, 1 contain the screen mode 0..3 (MODE 0 - 2 like known from Basic)
;
;Bit 3 = 0 ==> charset from lower ROM (on)
;      = 1 ==> RAM charset (lower ROM off)
 
Scrolling is another thing. Since FutureOS works page oriented, there is no scrolling planned. But you can do that in one of two ways:
- Redraw page instead of scrolling (suggested)
- Scroll by hand, means be altering the CRTC address. However that will cause troubles for printing characters.
 

[AMSDOS]

Yes, they use Pen 0, 1 or 2. So you select the pen by selecting the function PEN0, PEN1 or PEN2. (There is no PEN function for backgournd color).
 Well, I have to look how FIOLOB does it. But in general you can place your own character set to address &3800 to &3FFF (this is where the character set is located in the lower ROM). And to activate the RAM character set you have to alter RAM variable RAMCHAR
 

RAMCHAR EQU &B847
RAMCHAR  ;Screen-Mode and RAM/ROM-charset selection.
;Bit 0, 1 contain the screen mode 0..3 (MODE 0 - 2 like known from Basic)
;
;Bit 3 = 0 ==> charset from lower ROM (on)
;      = 1 ==> RAM charset (lower ROM off)
 
Scrolling is another thing. Since FutureOS works page oriented, there is no scrolling planned. But you can do that in one of two ways:
- Redraw page instead of scrolling (suggested)
- Scroll by hand, means be altering the CRTC address. However that will cause troubles for printing characters.

Does that mean that FutureOS doesn't reserve an area of memory for the screen? To simulate the effect the screen gets rolled to make it appear there's a moving starfield, perhaps scroll is the wrong terminology - so a pixel appears randomly near the top of the screen and that gets pushed to the next line and then a new pixel appears at the top, so on and so fourth until it gets to the bottom and disappears, never to return. I've made a simple LDIR routine which produces that effect, though for it to work it relies on Screen Addressing to move something from point A to B and so on, so it moves a pixel down the screen.

[TFM]

I'm not sure if I get it all right. Well, the screen RAM / Video-RAM is located between &C000 and &FFFF like unter the regular firmware too.
 

[AMSDOS]

I'm not sure if I get it all right. Well, the screen RAM / Video-RAM is located between &C000 and &FFFF like unter the regular firmware too.

I just meant that if the Screen RAM was in the same spot in FutureOS, I can use an alternative routine to make it look like the screen has rolled, this is an example of what I came up in BASIC which I made just to get an idea on what the routine would look like:

Code: [Select]

10 MODE 1:CALL &BC02:BORDER 0:GOSUB 1000:GOSUB 2000
20 a%=1
30 WHILE 1
40  TAG:MOVE (RND*320),380:PRINT"A";:TAGOFF
50  FOR b%=9 TO 200
60   CALL &4000,scr%(b%),scr%(a%)
70   a%=a%+1
80  NEXT b%
90 a%=1
100 WEND
1000 DIM scr%(200)
1010  FOR a%=1 TO 200
1020   READ a$
1030   scr%(a%)=VAL("&"+a$)
1040  NEXT a%:RETURN
1050 DATA c780,cf80,d780,df80,e780,ef80,f780,ff80
1060 DATA c730,cf30,d730,df30,e730,ef30,f730,ff30
1070 DATA c6e0,cee0,d6e0,dee0,e6e0,eee0,f6e0,fee0
1080 DATA c690,ce90,d690,de90,e690,ee90,f690,fe90
1090 DATA c640,ce40,d640,de40,e640,ee40,f640,fe40
1100 DATA c5f0,cdf0,d5f0,ddf0,e5f0,edf0,f5f0,fdf0
1110 DATA c5a0,cda0,d5a0,dda0,e5a0,eda0,f5a0,fda0
1120 DATA c550,cd50,d550,dd50,e550,ed50,f550,fd50
1130 DATA c500,cd00,d500,dd00,e500,ed00,f500,fd00
1140 DATA c4b0,ccb0,d4b0,dcb0,e4b0,ecb0,f4b0,fcb0
1150 DATA c460,cc60,d460,dc60,e460,ec60,f460,fc60
1160 DATA c410,cc10,d410,dc10,e410,ec10,f410,fc10
1170 DATA c3c0,cbc0,d3c0,dbc0,e3c0,ebc0,f3c0,fbc0
1180 DATA c370,cb70,d370,db70,e370,eb70,f370,fb70
1190 DATA c320,cb20,d320,db20,e320,eb20,f320,fb20
1200 DATA c2d0,cad0,d2d0,dad0,e2d0,ead0,f2d0,fad0
1210 DATA c280,ca80,d280,da80,e280,ea80,f280,fa80
1220 DATA c230,ca30,d230,da30,e230,ea30,f230,fa30
1230 DATA c1e0,c9e0,d1e0,d9e0,e1e0,e9e0,f1e0,f9e0
1240 DATA c190,c990,d190,d990,e190,e990,f190,f990
1250 DATA c140,c940,d140,d940,e140,e940,f140,f940
1260 DATA c0f0,c8f0,d0f0,d8f0,e0f0,e8f0,f0f0,f8f0
1270 DATA c0a0,c8a0,d0a0,d8a0,e0a0,e8a0,f0a0,f8a0
1280 DATA c050,c850,d050,d850,e050,e850,f050,f850
1290 DATA c000,c800,d000,d800,e000,e800,f000,f800
2000 FOR a%=&4000 TO &4011
2010  READ a$
2020  POKE a%,VAL("&"+a$)
2030 NEXT a%:RETURN
2040 DATA DD,5E,00
2050 DATA DD,56,01
2060 DATA DD,6E,02
2070 DATA DD,66,03
2080 DATA 01,4F,00
2090 DATA ED,B0
2100 DATA C9


[AMSDOS]

I've had a go following all the procedures for making a SmallC program using FIOLIB, though no matter what I do, the program appears to be crashing, initially I thought it might of been crashing because I wasn't preserving the registers around my scrolling routine, so I put PUSH & POP (in the correct sequence) around the routine and still got the same result and then I realised I was using the wrong program which wasn't producing the SMC file, I tried that - linking with and without the printf1 file during compilation, though have had no luck there either and program is still giving me mess. I'm unsure if it's crashing cause I using an infinite loop, or if my routine is not producing the same result, even though the screen is located between &C000-&FFFF, or if it's loading it to the wrong area of Banked Memory, something I couldn't get to grips with in CP/M Plus. Or if I'm doing things incorrectly and program would normally run, I've followed the Running of SmallC programs Video, though my FutureOS seems to be running differently from the one in the video (because it's an earlier version).

I've attached my modified Vortex Disk, to see if someone can work out what's happening cause theoretically speaking I think the program should be working, though for some reason it's not. At this stage of the program is should only be a Starfield rolling down the screen. Oh and the file is called STARSCRL.SMC

EDIT: Okay, so I've just been reading this from your FutureOS Corner which might explain what's happening in my SmallC program:

- It's not easy to manipulate the screen due to a routine that is located between &C000 and &FFFF, but you can use RAM configuration &C3 to move the screen RAM to &4000 (but &C3 works only on 6128).

So I guess my next question is does FIOLIB have one of those &C3 routines?

[AMSDOS]

Ok sorry folks I managed to nut it out myself. 

By placing some

Code: [Select]

ld bc,&7fc3
 out (c),c

and

Code: [Select]

ld bc,&7fc0
 out (c),c

around my scroller, problem solved. In order to do this though you need 128k though, which I guess isn't a problem since FutureOS needs 128k.

I'm unsure if there's a routine which can check if a key has been pressed but doesn't wait, so in order to get out of that loop a whole reset needs to be carried out (which means getting out of FutureOS as well).

[AMSDOS]

Well, I have to look how FIOLOB does it. But in general you can place your own character set to address &3800 to &3FFF (this is where the character set is located in the lower ROM). And to activate the RAM character set you have to alter RAM variable RAMCHAR
 

RAMCHAR EQU &B847
RAMCHAR  ;Screen-Mode and RAM/ROM-charset selection.
;Bit 0, 1 contain the screen mode 0..3 (MODE 0 - 2 like known from Basic)
;
;Bit 3 = 0 ==> charset from lower ROM (on)
;      = 1 ==> RAM charset (lower ROM off)

Ok, I've tried to Redefine the character set using this approach below, though I'm doing something wrong and it's not working.

Code: [Select]

ship()
{
#asm
push hl
push af
push bc

xor a
bit 0,a
bit 1,a
inc a
bit 3,a
call 0b847h
ld hl,03feah
ld a,(data)
ld b,15
craft:
ld (hl),a
inc hl
inc a
djnz craft

pop bc
pop af
pop hl

ret
data:
defb 1,1,65,67,71,127,67,1
defb 128,128,130,194,226,254,194,128
#endasm
}
So my reasoning behind this is I've set the Accumulator to 0 and set bits 0 & 1 to 0, increased the accumulator to 1 and then do a bit 3 - is this correct, or is it the "set" instruction I should be using to set bits before calling &B747. Once I've done that I'm poking the character data into the part of memory I thought it would go into - again I'm not sure if this is correct. 

[AMSDOS]

Ok, so if I read the handbook correctly, there is no character set in MODE 0, so I cannot use RAMCHAR and will have to make a graphical routine to display it as a graphic.