CC65 to prove difficult for our needs.

[Guest]

In the first chat, I proposed that we create the new BBS using CC65.  My logic was based on the knowledge that C is easier to maintain than assembler, and much easier to cross-develop than CBM Basic 7, accompanied by the fact the Contiki (a rather huge project) had successfully been implemented in C with CC65.

Since then I've done some proof of concept work and found two major limitations with using CC65 on the 128.  As most of you know, the 128 has a very ODD memory scheme.  There's really nothing quite like it.  And as such, CC65 basically ignores anything except BANK 0.  My hopes were that we could let the CC65 runtime create the heap in bank 1 and then we could just use bank 0 for executable code, but that appears to be a fools dream.  We can trick CC65 into using the memory in Bank 1, but we do so at our own peril.  Secondly, loadable modules is not readily available in CC65's linker.  All libraries are statically linked into the executable, as well as the bootstrapping code.  To get around this, the Contiki guys wrote a PERL script that gets executed after the kernel of Contiki is compiled that creates a custom linker config for all of the modules and applications to use so that the libraries don't get duplicated.  This, however, means that anytime the main executable is recompiled, everything must be recompiled.  We would have to have an understanding amongst everyone involved that the entire build environment, from soup to nuts, must be easily reproducible and readily available for free.  This could be a logistical nightmare for us as we start having people running their own BBS and writing their own C.

[Blacklord]

In the first chat, I proposed that we create the new BBS using CC65.  My logic was based on the knowledge that C is easier to maintain than assembler, and much easier to cross-develop than CBM Basic 7, accompanied by the fact the Contiki (a rather huge project) had successfully been implemented in C with CC65.

Since then I've done some proof of concept work and found two major limitations with using CC65 on the 128.  As most of you know, the 128 has a very ODD memory scheme.  There's really nothing quite like it.  And as such, CC65 basically ignores anything except BANK 0.  My hopes were that we could let the CC65 runtime create the heap in bank 1 and then we could just use bank 0 for executable code, but that appears to be a fools dream.  We can trick CC65 into using the memory in Bank 1, but we do so at our own peril.  Secondly, loadable modules is not readily available in CC65's linker.  All libraries are statically linked into the executable, as well as the bootstrapping code.  To get around this, the Contiki guys wrote a PERL script that gets executed after the kernel of Contiki is compiled that creates a custom linker config for all of the modules and applications to use so that the libraries don't get duplicated.  This, however, means that anytime the main executable is recompiled, everything must be recompiled.  We would have to have an understanding amongst everyone involved that the entire build environment, from soup to nuts, must be easily reproducible and readily available for free.  This could be a logistical nightmare for us as we start having people running their own BBS and writing their own C.

Proverbial spanner.......

[David Nelson]

So we go to plan B and code by hand? I recall reading someplace that coding by hand was the most efficient method, although time consuming. There is perhaps also the option of writing it in basic and using a compiler (Abascus 128?) . Too bad, because I liked the idea of using C.

-David

[Guest]

So we go to plan B and code by hand? I recall reading someplace that coding by hand was the most efficient method, although time consuming. There is perhaps also the option of writing it in basic and using a compiler (Abascus 128?) . Too bad, because I liked the idea of using C.

-David

I'm afraid I'm not down with coding it by hand.  My major interest in this project was doing something useful with CC65 as my excuse for learning old-skool C.  We can make it work, but I'm not sure we'd all be happy with the process.  There's always the possibility that if enough of us ask Uz that he may add support for a pre-defined link table that would never have to be changed, and thus mass recompiles would not be required with the main executable is recompiled.  And supporting the extra memory in the 128 is probably something that we can achieve through clever coding, possibly by putting the heap in Bank 0, and loading chunks of code to different locations of Bank 1 and using non-standard bank configurations to bank that code into the same 64k that the heap resides in.  This, of course, would require that all calls between modules would have to be marshalled through a memory manager.  By the time we're done with it, we'd have an operating system.

[OzOne]

I'm thinking back to Basic then is the likely answer ?

I'll be able to attend tomorrows talk as I'm not working this weekend (yay!), so I guees we'll be talking alternatives ?

[David Nelson]

I'm afraid I'm not down with coding it by hand.  My major interest in this project was doing something useful with CC65 as my excuse for learning old-skool C.

Coding by hand is very old school. These days, we never really have a chance to roll up our sleeves and start cranking out assembly because of how complicated the OS's have gotten.

I do recall seeing Abascus Super C, which was a C compiler for the C64/C128. One was on Ebay not too long ago. That might be worth taking a look at if C is still the main focus.

Basic compiled with something like Abascus's Basic 128 compiler is the easy solution, and still a worthy challenge. Or a mixture of assembly and compiled basic might be the winner, since the serial communications might need to be hand-tweaked for speed.

-David

[Guest]

I've used the Super C compiler before and don't wish to replicate that experience for long periods of time, either.  Really, I don't want to spend much time in the 128 doing the programming.  As a programmer, I find it extremely frustrating to code on the Commodore these days when it takes so much time.  Back in the day, none of the professional packages were coded in the 8-bit machines, instead they were coded with cross-compilers on mainframes and I don't blame them!

I have a basic pre-compiler called MacroBasic that I wrote many moons ago that allows you to write CBM basic in any text editor and then tokenize it on the target commodore.  However, because it tokenizes on the target commodore it's not real fast, even in VICE.  One of these days I'll finish the C# version of the tokenizer that would just output a tokenized program file, but I haven't written that part yet.  If I do go that direction then I'll probably just go the extra step and instead of outputting a tokenized PRG file, just compile to assembler.  However, to do that I would run into the same set of issues that are currently faced with CC65.  If I can overcome the MMU and dynamic linking issues in my compiler, I could get over them in CC65 as well, which would allow us to write C and thus leads us right back to where we are today.

[Stephane Richard]

How about Power C?   I just found that one online...so far looks rather complete...but I dont know about Super C.....where can I find out about Abacus Basic 128 ?

[Guest]

I may be wrong, but Power C and Super C are really the same product, just different branding.  I have one of them and have used it a bit, but it's a real pain.  It uses K&R syntax, which is weird, but doable.  The real issue is that the editor stinks.  I imagine that if one could get it working in VICE and use a PC to edit the files (the PC editing software would have to be able to save PETSCII to save a step), it might be workable.  I do not remember if it allows full access to all of the RAM and how it might handle loadable modules that aren't written in assembler.

[xlar54]

Payton - your tokenizer is an interesting application.  What if we had a BASIC editor/interpreter on the PC side that could run BASIC 10 code?  Basically a full development environment for cross developing BASIC programs.  After debugging, one could then run a tokenizer function and output the file for the 128.  This, I find to be very interesting, and more useful than for just BBS development.  A couple of problems come to mind right out of the gate of course - machine specific pokes for example.  But the idea still has some merit.  At times I completely agree with the issue of developing "in machine" (and then there are times that developing in machine feels "like the good ol days".. less often though

Geez I wish they would include a hook directly into VICE's memory via COM or pipes...  I had a hack that would allow you to peek and poke right into VICEs memory, but of course it relied on exact memory locations which changes everytime they come out with a new build.  Your tokenizer, fed directly into VICE's RAM would damn near be exactly what we need...and then include support for BASIC debugging (step/watches/etc).  Ive played with the C code for VICE to do something like this, but I'm just not too up on how they are managing some things in their code.

[Stephane Richard]

I like the sound of that....

there's a package out there that runs TRS-80 code quite fine, I'm sure something similar is doable.I would assume that isntead of using exact memory location, we could either

1. use VICE's memory mannager/allocator to get the infor.
2. create our own virtual C128 RAM/ROM

Cause I think it's save to assume that VICE, once it creates it's Virtual C128 so to speak, doesn't change it's location, hence anything in vice that write/reads, erases, etc from that virtual location could be use/reproduced rather simply without technicially creating our own emulator per se...just a chunk of RAM manipulator so to speak.