Problem using Lightspeed C with Altirra.

[Geister]

I've been trying to familiarize myself with LightSpeed C by running it on the Altirra emulator. I've noticed that LightSpeed DOS does not work well on this emulator as odd things happen with screen formatting both in the DOS and the editor CEDIT. The program DIR.com is actually a demo for the language itself, but the DOS does not appear to otherwise be able to provide a list of disk contents (Maybe you have to type "LOAD $,8"?). When the DIR command is used on Altirra, it is supposed to display a two column listing of disk contents, but instead, it prints an alternating two column listing skipping lines in each column so that much of the listing scrolls off screen.

 

If you enter the editor and a similar thing seems to occur when you try to list a programs text, and it gets even worse when you return to DOS. Attempting to list the directory after exiting the editor results in garbage on the screen.

 

If I use Atari800Win Plus4.0 everything seems to work correctly.

 

I really want to like Lightspeed C, but I wish it was not hamstrung into an ecosystem with Lightspeed DOS, but maybe that's the price you pay to have a procedural language compiler that runs on an 8-bit computer. I've run into similar issues with Pascals that run on the Atari. It's hard to be down on a language that provides a floating point package for use in Action! and Mac65...but if only it worked with SpartaDOS.

[Alfred]

Have you tried it with SpartaDos 2.3 ? I never used LSC myself, but I knew someone who did. I'm not sure, but I thought he said the LSC compiler needed a really low MEMLO. Sparta 2.3 runs around $0CD9 or something, maybe it'll work.

[phaeron]

It's not a compatibility issue with the emulator itself, but the built-in OS (specifically, direct access to ICBLLZ). Switch the OS firmware from the built-in AltirraOS to the Atari OS and the issue should go away.

[Geister]

Alfred, Lightspeed C is a closed eco-system. The compiler and programs compiled with it only run under lightspeed DOS without adding a runtime. Yes, you can build applications for other DOSes, but since Lightspeed DOS only handles 2 drives + a ram disk on D4:, and doesn't recognize the H: drive, getting files on and off LSDOS disks is trickier than it needs to be.

 

Phaeron, You were exactly correct! I forgot I had switched to the Altirra OS due to Altirra crashing with another set-up using the XL OS.

[576XE]

LSC is just another attempt to create it's own universe...

 

By the way I love C and my own choice is CC8 based on ACEC (ie fast and compatible!).

 

zen

[ivop]

BITD I wrote this in Lightspeed C:

 

https://archive.org/details/a8b_UnZip_v1.13_1993_van_Poorten_Ivo_nl

 

Seems to run on MAME inside my browser. Gives you a ready prompt. Type DOS and A. The source code is also on the disk!

 

 

BTW I find it amazing this is on archive.org. Not even sure if I have it myself on a working floppy

 

edit: fixed link

Edited March 2, 2019 by ivop

[bugbear]

It's hard to be down on a language that provides a floating point package for use in Action! and Mac65...but if only it worked with SpartaDOS.

Why do you want floating point?

 

BugBear

[Geister]

The program I'm playing with uses floating point math. I'm trying to create a version of the same program in every language that I can get my hands on. This floating point package gives me the ability to try it out in Action. Lightspeed C claims to be faster than action and slower than Assembler. I want to see if the claim is real.

[Geister]

I found that there is a version that works with SpartaDOS 3.2G but that only helps slightly as SpartaDOS does not seem to want to work well with the H: drive features. But at least I'm out of LightSpeed DOS.

 

Man I wish I still had my MIO and a 20 MB hard disk. I've got an AtariMax MyIDE II cart but it's not like using a hard disk. Maybe I just need some time to get used to it.

[ricortes]

The closed environment in theory was a great idea, it just never caught on. I bought a copy of Lightspeed C when it first came out and couldn't adjust myself.

 

Brilliant idea on several levels. You write your own DOS and reuse all the code in it to make your language faster and run time smaller. Doesn't make sense to have a DOS with a DUP loaded separately to do things like parse and output to the screen. IIRC Lightspeed just used everything in the DOS so as to not duplicate things that were already present. It gave you different run times so you could do things with other DOSs but you suffered the normal penalty in performance and memory use when you went that route. It meant you had to distribute your programs with the DOS or people had to boot the Lightspeed DOS to run them. Shouldn't have been a real problem since the author gave permission to distribute the DOS. Heck, listen to how many people complain when something is SD only or Turbo BASIC? hehe

[Geister]

Ricortes, I can't image why anyone would not want to use SpartaDOS/TurboBASIC. Maybe back in the day when they cost some real money and we barely had any left after buying the computer and disk drive, I could understand it, but now when they just cost the time of a download, what's the sticking point? SpartaDOS is head and shoulders above any menu driven DOS that was released on the ATARI. Going from SpartaDOS to DOS 2.0, 2.5, etc. is like going from DOS 2.0 to a set of Commodore drive commands or doing everything through XIO commands.

 

TurboBASIC is so compatible to Atari BASIC and so much faster, where's the downside?\

 

Well, anyway, back on topic. I'm still having problems with Lightspeed C, but this time the issue appears to be the floating point routines not behaving as I would expect them to. Specifically, the Hat/Fedora program goes astray and often plots too many points per iteration. I often plot in the wrong location. The first problem I think I've tracked down to a difference in how the Lightspeed floating point handles INT(), or actually ftoi(). Atari Basic seems to truncate anything after the decimal point, while Lightspeed floating point rounds up. This could just be my lack of understanding of how Atari floating point works.

 

Also, as you said, you do suffer a huge penalty running under anything but Lightspeed DOS. Under SpartaDOS, the C version of this program runs as slowly as Atari Basic, maybe slower. Maybe once I get it working on SpartaDOS I'll move back to Lightspeed DOS and run Faster six or seven times...

[Alfred]

So you need a way to bind the full runtime to your code, to remove the requirement for LSC DOS.

[Geister]

That's actually provided, but I assume that the runtime included for other DOS versions is what makes the program run so slow. I may be mistaken, and maybe it's just as slow under LSC DOS, or maybe the Floating point package provided by LSC is just that bad.

I think maybe its time to give up on native compilers and just move to CC65.

[ricortes]

@Geister, nothing was wrong with any of them as long as you had an 800xl or later computer. They were pretty much incompatible with everything sold before ~1985. Even after, SDX was incompatible with the ATR8000 timing. Ditto for the 810 which can't handle anything but SSSD. They weren't even compatible with each other! Both wanted the RAM under ROM space so they didn't like some of the features by alternative operating systems like Omniview with its fast FP routines. I think SD had a 1.1 disk that came with their USDoubler so 800 users could use it, but it may have been a memory hog???

 

Turbo BASIC and SD did win. I even went so far as to gladly give my 800 away as I hadn't used it in a decade. To me it's not quite the same level of 'be happy' when everyone that bought an Atari computer the first ~5 years they were out got left out. But this stuff happens everywhere like the ST came with 3.5" SSDD 360k disks so that was the standard. I remember getting MSDOS on something like half a dozen floppies. Time marches on. Now floppies and even CDROMs are not standard on all new computers.

 

I'm sweating design details right now. Parts are coming in and I'm thinking the smallest memory model I want to make is 512k. Thanks for bringing this up because even though it will be a one off hobby computer I am thinking I should burn some brain cells so everything will play nice with each other in theory.

Edited March 26, 2019 by ricortes

[Alfred]

 

Also, as you said, you do suffer a huge penalty running under anything but Lightspeed DOS. Under SpartaDOS, the C version of this program runs as slowly as Atari Basic, maybe slower. Maybe once I get it working on SpartaDOS I'll move back to Lightspeed DOS and run Faster six or seven times...

 

That really makes no sense, unless they deliberately crippled it to perform poorly if not running under LSC DOS. Can you post a binary of some small program that runs like crap ?