Digital C SE Foibles on QPC2

Anything QL Software or Programming Related.
User avatar
NormanDunbar
Forum Moderator
Posts: 2251
Joined: Tue Dec 14, 2010 9:04 am
Location: Leeds, West Yorkshire, UK
Contact:

Digital C SE Foibles on QPC2

Post by NormanDunbar »

This may not be a problem with QPC2 of course!


I've got Digital C Special Edition on my win1_ drive, under QPC II 4.0.5. It's acting weirdly.

I've reduced myself to a plain old test file:

Code: Select all

int main() {
	puts("Hello World!");
}
It's the example from the manual after all.

so, I have configured cc and cg to have ram1_ as the default device. I have my sources on ram2_. Ram1_ contains all of the files from the installation of Digital C SE.

This works and generates ram2_test_obj file as expected:

Code: Select all

ex ram1_cc ; 'ram2_test_c -m -p'
This then works and generates the ram2_test executable:

Code: Select all

ex ram1_cg ; 'ram2_test ram2_test_obj -nc -d/ram1_''
I need the default device switched back to ram1_ temporarily as that's where cg expects to find the std_lib and mc_obj files.

Executing ram2_test gives absolutely nothing. EW shows no errors but there is no output or anything. I am, somewhat perplexed. I even tried wrapping the one executable line in a for loop to print the message 999 times. Nothing.

Now I accept that Digital C is, like me, old, but C68 is older still and works!

As ever, all clues gratefully accepted. Thanks. I was hoping to have a play with bwinkel67's ZXSimulator code, but I got distracted down this damned rabbit hole of stuff not working, having to read the manual - after god only knows how many years - and failing in my quest! (There's probably an adventure game in there somewhere!)


Cheers,
Norm.


Why do they put lightning conductors on churches?
Author of Arduino Software Internals
Author of Arduino Interrupts

No longer on Twitter, find me on https://mastodon.scot/@NormanDunbar.
User avatar
bwinkel67
QL Wafer Drive
Posts: 1187
Joined: Thu Oct 03, 2019 2:09 am

Re: Digital C SE Foibles on QPC2

Post by bwinkel67 »

So if you've set everything to ram1_ as default and copied all of Digital 'C' SE onto ram1_ and have your source on ram1_ as well, this should work:

Code: Select all

exec ram1_cc;"-p -m ram1_test_c"
exec ram1_cg;"ram1_test ram1_test -nc"
If that doesn't work it has to do with maybe the fact that Digital 'C' SE is weird about directories. I haven't been able to run it off of win8_ on QLAY2 but I'm assuming it was QLAY2's problem. So here is how I've been doing it, using mdv2_ and mdv3_ under QLAY2. Note that with a lot of copying and deleting mdv2_ gets screwed up so every now and again I delete it and add a completely blank MDV file in its place. I keep the Digital 'C' SE source on my win8_ drive for quick copying, and I transfer my source code to that drive as well and use qlayt to add it to the directory (before starting the emulator). If you are using a real QL you won't have some of my issues.

So here are the two MDV configurations that have worked for me on QLAY2:

mdv2_

Code: Select all

cc
mc_obj
std_lib
test_c
mdv3_ (default for all executables)

Code: Select all

cg
config
lg
mc_obj
stdio_h
std_lib
I then type the following:

Code: Select all

exec mdv2_cc;"-p -m mdv2_test_c"
delete mdv2_cc
delete mdv2_test_c
copy mdv3_test_obj to mdv2_test_obj
delete mdv3_test_obj
exec mdv3_cg;"mdv2_test mdv2_test -nc"
Note that other than deleting cc form mdv2_ the others may not be needed unless your source and resulting executable are large enough to run out of space on the 128K mdv2_. So I have just gotten used to doing this so everything works quickly. Got tired of weird directory issues and sitting their waiting for cc to finish. When it works it does it pretty quickly but hen using win8_ directly, for instance, QLAY2 just freaks out after a few minutes and my whole desktop gets screwed up. So that is why I switched to mdv2_ and mdv3_.

I also should be able to compile with multiple source files but gave up and just concatenated it all into one huge one. Back when I used floppies and mdv's on my QL in the 90's it worked but I haven't chosen to recreate that environment just now. In reality I should be able to compile them individually and cg should combine them but that hasn't worked for me yet. I keep thinking it's a QLAY2 issue or the NFA add-on.


User avatar
NormanDunbar
Forum Moderator
Posts: 2251
Joined: Tue Dec 14, 2010 9:04 am
Location: Leeds, West Yorkshire, UK
Contact:

Re: Digital C SE Foibles on QPC2

Post by NormanDunbar »

Thank.

I'm not having problems compiling and generating code - that appears to work. The executable runs but produces no output at all, and no errors.

I feel a dissassembly coming on. :?

Cheers,
Norm.


Why do they put lightning conductors on churches?
Author of Arduino Software Internals
Author of Arduino Interrupts

No longer on Twitter, find me on https://mastodon.scot/@NormanDunbar.
User avatar
bwinkel67
QL Wafer Drive
Posts: 1187
Joined: Thu Oct 03, 2019 2:09 am

Re: Digital C SE Foibles on QPC2

Post by bwinkel67 »

I use:

Code: Select all

fprintf(stdout,"Hello World");
Try adding:

Code: Select all

#include stdio_h
The language has some idiosyncrasies. Like this doesn't work as expected:

Code: Select all

if (a=b*2+1 > 5) a = 0;
You instead need to do this:

Code: Select all

if ( (a=(b*2+1)) > 5) a = 0;
Not sure if you need the inner most parenthesis but you do need the outer most. I think order of operations is screwed up in that case.


User avatar
NormanDunbar
Forum Moderator
Posts: 2251
Joined: Tue Dec 14, 2010 9:04 am
Location: Leeds, West Yorkshire, UK
Contact:

Re: Digital C SE Foibles on QPC2

Post by NormanDunbar »

bwinkel67 wrote:The language has some idiosyncrasies. Like this doesn't work as expected:
How very true! So I tried your suggestion of:

Code: Select all

#include <stdio_h>
even though no such file exists. It didn't complain. However, things are now even worse:

With a clean setup, cc, cg, lg etc configured for dev1_ and this as my test file:

Code: Select all

#include <stdio_h>

int main() {
    int x;
    for (x = 0; x < 101; x++)
        fprintf(stdout, "Hello World!");
}
then I use this to compile:

Code: Select all

dev_use 1, win1_digital_c_se_
prog_use dev1_
ex cc;'ram1_test -m -p -d/ram1_'
ex cg;'ram1_test ram1_test_obj -nc -d/dev1_'
I get the test_obj file written to ram1_ by cc, I get the test executable written to ram1_ by cg, but, ram1_test is not an executable file now. It has no data space and will not EXEC.

I seem to remember having lots of problem like these when I first purchased Digital C way back when it first came out, and gave up on trying to make it work. Even the example programs don't work.

I think the time has come to reclaim the disc space and remove it completely.

Cheers,
Norm.


Why do they put lightning conductors on churches?
Author of Arduino Software Internals
Author of Arduino Interrupts

No longer on Twitter, find me on https://mastodon.scot/@NormanDunbar.
Martin_Head
Aurora
Posts: 847
Joined: Tue Dec 17, 2013 1:17 pm

Re: Digital C SE Foibles on QPC2

Post by Martin_Head »

I know nothing about C, so this might be a stupid suggestion.

What could be happening, Is that when you execute the program. A window is drawn, "Hello World!" is printed. The window is closed. Then SMSQ/E restores the background, making the window disappear. All this happening before you can see it. I know I have seen this problem before.

Can you put some kind of INPUT after the "Hello World", so the window hangs about for a while.


User avatar
NormanDunbar
Forum Moderator
Posts: 2251
Joined: Tue Dec 14, 2010 9:04 am
Location: Leeds, West Yorkshire, UK
Contact:

Re: Digital C SE Foibles on QPC2

Post by NormanDunbar »

Hi Martin,

a good question, not a stupid one.

I already thought of that and wrapped the simple "fprintf" statements in a loop to print 1000 of them (which I later reduced to 100) - so that should have worked. However, the (latest) problem is that the generated executable file is, in actual fact, not at all executable. There's no data space and it is of the wrong file_type.

It is beginning to look like Digital C SE is a steaming pile of poo, to use a very technical term.


Cheers,
Norm.


Why do they put lightning conductors on churches?
Author of Arduino Software Internals
Author of Arduino Interrupts

No longer on Twitter, find me on https://mastodon.scot/@NormanDunbar.
User avatar
Artificer
Brittle Membrane
Posts: 120
Joined: Fri Nov 24, 2017 8:43 am

Re: Digital C SE Foibles on QPC2

Post by Artificer »

Hi

Norman wrote
#include <stdio_h>
even though no such file exits
Do you mean that you don't have the studio_h file which is part of the Digital C distribution. If not then that could be why things are not working. It is a 628 byte file that contains digital C's small C definitions including assigning channel numbers to stdin, stdout and stderr. It should be I think in the same location as mc_obj and std_lib. When I have used digital C I had always place all the digital C files in the same location, usually ram1_ and output the compiled executables to flp2_.

The simple programs you are testing do compile here on a Q68 using ram1_ for everything.

Cheers


User avatar
RalfR
Aurora
Posts: 871
Joined: Fri Jun 15, 2018 8:58 pm

Re: Digital C SE Foibles on QPC2

Post by RalfR »

Digital_C.jpg


4E75 7000
User avatar
NormanDunbar
Forum Moderator
Posts: 2251
Joined: Tue Dec 14, 2010 9:04 am
Location: Leeds, West Yorkshire, UK
Contact:

Re: Digital C SE Foibles on QPC2

Post by NormanDunbar »

Afternoon Artificer,

my apologies, I looked again when I saw your reply, the file is most certainly there. It appears I am no longer able to read a directory listing!

Sorry.


Cheers,
Norm.


Why do they put lightning conductors on churches?
Author of Arduino Software Internals
Author of Arduino Interrupts

No longer on Twitter, find me on https://mastodon.scot/@NormanDunbar.
Post Reply