Re: Welcome! « Result #3 on Sept 5, 2009, 8:42am »
Thanks, Dan!
[When I first saw your handle, "Madbeing", I thought for sure here was another piece of spam...that's mostly what I do on this board, clean up the spam, lol....]
Anyway, BDS C was a fun thing to have been involved with, and I'm really happy about the fact that lots of creative developers got their leg-up into doing C and/or C++ development by having this access to a reasonable C development system on the old 8-bit machines. My only regret was that I didn't have much of a head for business, and missed several opportunities to allow the product to snowball into bigger and more contemporary things. But then, the world probably never needed Yet Another Bill Gates anyway!
Re: Welcome! « Result #4 on Sept 3, 2009, 10:04pm »
Leor,
I wanted to tell you (somewhat late) that using BDS C was one of the really fun things of my early days in computing. I was one of your satisfied customers. I believe I purchased at least two releases. I wish I had kept the first manual set but it succumbed to a massive clean up around 1996. Anyway, your software beat the heck out of other systems from that period. It was fast, easy to use and generated reasonably tight code for the time.
Personally, I ended up using it to learn C and to roll lots of useful utilities for myself and later for various departments at Tulane Univ (in New Orleans) where I worked for the computer center in the 80's. I wouldn't be surprised to find some bits still in use there. I did one specialized comm / upload / download program for a custom S-100 based system in the Physic's dept (the S-100 box was the A/D and D/A interface for the prof's experiments. I provided a junior version of Kermit so he could communicate with the University's mainframe systems (some DEC-20's and a large IBM 308x system). In the BioStat group I wrote a very small, high reliability comm program that they used for years to upload field data from Africa to France to New Orleans to get around weird government restrictions in some of those places.
Anyway, I just wanted you to know that your efforts were appreciated. You don't see many software systems these days which are as elegant and fast as it was. I will have to download the binaries and pull it up in an emulator for old times sake.
Re: BDS C on the Zicog 5 chip emulation « Result #7 on Aug 17, 2009, 7:21am »
See attached image. This is the IDE used on the N8VEM or the Zicog boards. Just attach the CP/M board via a serial cable.
New brings up the very simple 'hello world' program. The rich text box is much easier to work with than wordstar (though not the purist programming experience, I agree). Click on the compile button and it compiles using the simh, and then downloads and runs the program. I timed that whole process at 9 seconds.
I have a similar screen for sbasic which has a few more buttons, eg you can compile on the simh and leave the simh window open. But I prefer running on a real board as invariably there is real I/O to test and use.
I find getting a simple program working rapidly makes the whole experience of coding much easier, especially if the compile/test/edit/recompile cycle is as quick as possible.
Re: BDS C on the Zicog 5 chip emulation « Result #8 on Aug 16, 2009, 11:32pm »
Yes, 32k is good. The zicog emulation started out life with only 20k but now has the full 64k which is even better. Re writing a program, would wordstar in non document mode work? Or another approach which I've used with sbasic, where you write in a richtextbox in vb.net, hit 'compile' and it goes off and compiles it automatically in about 1/10th a second on the altair simh, then downloads to the board in xmodem and runs it. So compiles are only 5-10 seconds even for big programs. I'd like to get BDS C into that environment too.
One big advantage of BDS C is that all the docmentation is available, and it is professional quality documentation too. Back to coding...
Re: BDS C on the Zicog 5 chip emulation « Result #9 on Aug 16, 2009, 11:03pm »
Looks good!
So were you asking what the minimum RAM required would be? I think around 32K of RAM allows a short program to be compiled (can't recall exactly how short, but perhaps a hundred lines or so?)
All the work happens in RAM, so the more RAM the merrier. BDS C recognizes up to a full 64K present in the system.
When I tried to play with BDS C on SIMH, I was stymied because I couldn't remember any of the WordMaster key bindings, lol. I couldn't write a new program to try to compile! (Not that I would have had anything necessarily worth creating...)
BDS C on the Zicog 5 chip emulation « Result #10 on Aug 14, 2009, 9:32am »
What is the minimum hardware to run BDS C? This is all rather experimental at the moment, but in the attached photo we have one Propeller chip, one 512k ram chip, one 74HC573, one 32k eeprom and one max232. The sd card contains 8 Altair SIMH drive files and BDS C is on drive C (of course!). The Propeller is running a Zicog Z80 emulation in software, with a package that emulates an Altair SIMH disk image. It is about the same as a 4Mhz Z80 in speed. This is talking to a terminal program on a PC, but can easily talk to a VGA screen directly using a Pocketerm http://www.brielcomputers.com/wik/index.php?title=Image:Pocketermrev1.jpg (using another Propeller chip).
Can it compile and run a program? Yes, it can! See below for a printout. And, the Z80/CP/M emulation is written in Spin, which is a new language that looks awfully similar to BDS C.
More updates on this amazing crazy retro project at the Parallax Propeller forum.
I'm looking forward to using this fantastic language BDS C in some real-world applications soon. Cheers, James Moxham
64K CP/M Version 2.2 (SIMH ALTAIR 8800, BIOS V1.25, 2 HD, 15-Jan-07) Unknown console status write with byte &H03
A>C:
C>DIR
C: BDSCPAT Z80 : -READ ME : BDS LIB : CMODEM C C: C CCC : C SUB : CASM C : CASM SUB C: CC COM : CC2 COM : CCC ASM : CCONFIG C C: CCONFIG COM : CCONFIG H : CCONFIG2 C : CHARIO C C: CLIB COM : CLINK COM : CLOAD C : CRCKLST1 CRC C: DEFF CRL : DEFF2 CRL : DEFF2A CSM : DEFF2B CSM C: DEFF2C CSM : FILES DOC : L2 C : SOURCES LBR C: STDIO H : STDLIB1 C : STDLIB2 C : STDLIB3 C C: ZCASM LBR : -LBR NOT : BCD LBR : BDSCIO H C: BUGS DOC : CDEBUG LBR : CRCK COM : CRCK DOC C: CRCKLST2 CRC : DEFF15 CRL : LBREXT COM : LDIR COM C: LONG C : MCONFIG H : RED LBR : TARGET C C: UNCRUNCH COM : CASM CRL : CASM COM : CHARIO CRL C: L2 COM : CCV16PAT HEX : CLOAD COM : TAIL C C: CCV20PAT HEX : CMODEM H : CMODEM2 C : CP C C: DATE C : DIO C : DIO H : HARDWARE H C: LPR C : NDI C : NOBOOT C : RM C C: UCASE C : WILDEXP C : TAIL CRL : TAIL COM C: CCONFIG CRL : CCONFIG2 CRL : UCASE CRL : UCASE COM C: UCASE TXT C>CC UCASE
BD Software C Compiler v1.60 (part I) 35K elbowroom
BD Software C Compiler v1.60 (part II) 33K to spare
C>CLINK UCASE
BD Software C Linker v1.60
Last code address: 1F8E Externals start at 1F8F, occupy 000E bytes, last byte at 1F9C Top of memory: E405 Stack space: C469 Writing output... 40K link space remaining