Jump to content

sanny

Members
  • Content Count

    424
  • Joined

  • Last visited

Everything posted by sanny

  1. This seems to be a patch for the binary. Which assembler was used to compile it and how do I apply it? I had expected a source-code patch, since both cc65 and PLATOterm (AFAIK) are available in source. FYI, in case you don't know: If you want to modify some part of the cc65 runtime library (I think the serial driver is changed by this patch, at least), you can copy the relevant source file from the cc65 library, modify it to your needs, and use this version. So copy e.g. libsrc/atari/ser/atrrdev.s to your directory, modify it to your needs, and compile like this cl65 -t atari .... atrrdev.s ... As long as you don't change the exported symbol names, the linker will pick up your modified version instead of the version contained in the lib. Remember, the cc65 lib must work for general programs. You know what your program does. And if the official cc65 lib version is suboptimal (because of checks for things which cannot happen in your program), it's perfectly valid to use a local tweaked version of the lib file(s) affected. regards, chris
  2. I'm curious about the changes in "PLATOTERM 1.2 test release with FAST-IO!", and there especially in "Improves I/O throughput immensely, 2400 baud is stable now!".
  3. Thom, did you check in the changes to github? I don't get anything new there. regards, chris
  4. I don't expect them to be compatible at the hardware level (and also not to the original DragonCart), but IP65 will definitely get support for both. If ol.sc doesn't implement it, I will do... So for existing programs a recompile/relink will probably be needed. regards, chris
  5. "...may improve XON/XOFF handling..." Does this improve the handling even when connected over a TCP channel? Like with "tcpser"?
  6. And, yes, XON/XOFF should be honoured by the peer (e.g. tcpser)
  7. Ok. So no degrade there, good. But a few thoughts: I had recently looked at the 850 R: driver source code, and XON/XOFF handling appears (to me to) be implementable there. In a much better way as you (I think) tried to implement in the user program/PLATOterm. Could this be something to pursue? select a "special" R: driver for 850 in PLATOterm. Which replaces the original/already loaded R: driver. Would just work for real 850s Is the PLATO protocol XON/XOFF "clean"? IOW, doesn't it transfer these values as part of the data stream?
  8. Hi Thom, do you know what was the max baud rate of the original PLATO cartridge?
  9. Yes, more or less. I don't know the source code, but I guess that the parser looks for the first "." and then looks up the first matching word with the characters it's got so far (the chars preceeding the "."). With "POK." it'll find "POKE". So "POK." is not an 'intentional' abbrevation, but just a side effect from how the parser works.
  10. Thanks :-) I'm open to any contribution which improves the Atari (and Atari5200) support. And you did a good job! regards, chris
  11. Calm down, guys. Re-reading the posts I think Doctor did misinterpret you, brenski.
  12. Daniel's (dmsc's) XEX changes to cc65 had been incorporated into cc65 some days/weeks ago. They are not the default, so read the documentation. But it should be simpler now for newbies to create multi-segment Atari executables. Don't know, Daniel, if you'd like to elaboarate a bit more on that... regards, chris
  13. Yes, but should be rather simple. Just install a DLI handler which changes the color registers. VBI will take care that in the next frame the colors will be restored for the lines before the DLI position.
  14. Make the "<-- Currently latest version!" string better bold. Took some time for me to find it. regards, chris
  15. I *think* VICE for the CBM machines supports the debugging info generated by cc65. I've never used it, though. So if support for the debugging info would be added to the Atari emulators (Atari800, Altirra), their debuggers could support source-level debugging of C code. Right now you could always use "printf debugging", or add breakpoints at interesting places in the code and then continue from there (in assembly language). What problem do you want to debug right now? regards, chris
  16. Might be good, but keep in mind that stack overflow issues are ones of the most difficult to debug. OTOH, the 0x800 value is quite conservative in the first place. Still depends on your program, though. If you're using many local veriables (or even arrary there), 0x800 might even be small. Look at the linker map file to find out where your memory is consumed. regards, chris
  17. Me not . I'm granting myself the luxury of a home server running 24/7. And this is not just some small NAS thing. It runs the DHCP server (ISC DHCPD) and it can be configured to what I want, not restricting me to the things that the DSL-router GUI allows.
  18. I'm using TFTP to boot one of my (PPC) Macs and a Motorola M8120 and a NCD X-Terminal. TFTP is good
  19. As the CEO of a former company where I was said, "we do both". So best to get both variants, cartridge and PBI version :-)
×
×
  • Create New...