Jump to content

pzembrod

Members
  • Posts

    72
  • Joined

  • Last visited

  • Days Won

    2

pzembrod last won the day on December 24 2021

pzembrod had the most liked content!

1 Follower

Recent Profile Visitors

403 profile views

pzembrod's Achievements

Rookie

Rookie (2/14)

First Post Rare Collaborator Rare Conversation Starter Rare Dedicated Rare Reacting Well Rare

Recent Badges

81

Reputation

  1. Thank you from me, too, to all of you stepping up! Lovely to know the community is alive when hacking at X16 code.
  2. Hi all, I'm happy to announce that I have just released the next version (v0.10) of my Small C compiler cc64. The three main changes that v0.10 brings are ANSI syntax for function definitions, a basic libc, and proper support for _fastcall functions, with a related breaking change in runtime module .h file format. ANSI style function definitions (char f(int a) {...}) are implemented as a syntactic alternative to K&R style function definitions (char f(a) int a; {...}) with exactly the same semantics, i.e. there is no matching or checking of declared parameter types and actual parameter types in function calls. The new basic libc is based on PDCLib. Only a limited range of standard libc functions make sense on an int/char only compiler on the C64, C16 or X16. 18 string.h functions and 2 stdlib.h functions were ported from PDCLib, and 2 functions from stdlib.h, 8 functions from ctype.h and 12 functions from stdio.h were reimplemented in 6502 assembly. The cc64 libc is available in precompiled runtime modules libc-*.[hio], to be used instead of rt-*.[hio]. cc64 always could call a type of assembly-implemented single-param functions which need no own stack frame and get the param passed in a/x. v0.10 introduces the keywork _fastcall to declare or define such functions, as well as _fastcall function pointers, which weren't possible before. The related breaking change concerns the the format of how symbols are defined in the rt-*.h and libc-*.h files. There are now more parser unit tests, some compiler bugs discovered while implementing the libc were fixed, and binary sizes are now tracked in bin-size-register. For more details see Versions. Cheers /Philip
  3. Hi @Kevin Williams, @Michael Steil, I might be able to offer some help around the 65c22 bit-bang approach. It's unusual that this works fine at lower and runs into problems at higher clock rates. Just reach out. Cheers /Philip
  4. @Wavicle, did you see any indication where the DOS for the SDCard might be living? On the X16 it occupies an entire ROM bank, IIUC. Just realized that this would be tricky with only 64K of memory overall ...
  5. I've said it before and am saying it again: Give them a break. Also, you are starting to sound somewhat entitled, which probably isn't your intention. Careful hint : You may be, just maybe, overestimating the value of your so far released X16 software. David is currently dealing with a major shakeup of his project. He's asked a question 5 days ago to feel the water about the option of an X8, and could probably spend some significant portion of his time just reading and digesting all the replies he's getting here in the forum, plus keeping an eye on all the other discussions, such as this one. He has given us an overview of the X8's specs, and I'm not surprised at all if he didn't have the time yet to reply to all the questions that came up. It shouldn't be all that hard for all of us to muster the patience that is called for at the moment. See above - let's be more considerate of all the other things on the project owners' table at the moment. And keep in mind - they have day jobs, too. This here isn't really it, not even for David, IIUC.
  6. @The 8-Bit Guy Hi David, I don't have a clear opinion wrt your questions 2 and 3, but wrt question 1 I would say do release the X8 - I probably would buy one just because it's cheap and it's there. My main interest in the project at the moment is as a platform to develop VolksForth and cc64 for, and at least the former I would likely port to the X8. Regarding the X16 phases, I'm not sure what I would buy. I'm still attracted to self-soldering RC2014-style 65C02 machine, so I might fall into the camp that would consider buying a VERA Cheers /Philip
  7. As others have pointed out before: Things aren't as clear as you believe them to be.
  8. I'll wait for more info and decisions from the project owners, and then decide what will be feasible. If the BASIC at $8000-$BFFF assumption holds, then VolksForth likely will be. For cc64 I'd have to overwrite the BASIC interpreter, and it would still be a close call.
  9. That won't fly in many cases. E.g. cc64 would exhibit abysmal compile speeds if I were to swap out significant parts of the compiler code to and from SDCard.
  10. It's quite fascinating, really, and also provides a nice study in software architecture heritage. The 1541's DOS still shows this structure, only it simulates the second CPU with an interrupt driven disk controller routine. The job codes in the zero page that the file system and the disk controller communicate through - that was the shared memory in the 2-CPU drives.
  11. I feel you may want to dial it down a bit. Give them a break! Let's wait for Frank or David to chime in, but if Wavicle is right, then I'd rather expect the BASIC interpreter to live from $8000-$BFFF - unless I'm mistaken the extended X16 BASIC is 16k; at least it lives in a 16k ROM bank.
  12. Did anyone on this thread already mention that this is exactly what the big CBM disk drives did? The 4040, 8050, 8250, etc...? One 6502 was doing the IEC bus and file stuff and the other did block level disk access. They would communicate through memory locations.
  13. Depends on circumstances and who you are. Way back when the C64 was my main computing device, I found Forth to be the most productive language, by far, that I could lay my hands on. Which is why cc64 is implemented in Forth.
  14. Done, thanks, Tom, I should have thought of that. Here it is:
×
×
  • Create New...

Important Information

Please review our Terms of Use