Closed oliverschmidt closed 6 years ago
Yup, actually, the up2400 branch utilizes ser for a port of Chris Hug's 2400 baud driver (and it uses conio as well).
https://github.com/tschak909/platoterm64/tree/up2400
:)
(and yes, I want to do an Apple II version soon, the trick is finding an Apple II emulator setup that can connect to the service, I haen't been successful there, yet.)
p.s. I am also doing an Apple IIgs version using ORCA/C and thus is a native IIgs desktop app.
-Thom
At first look that should indeed work on the Apple II and ATARI (likely with some minor adjustments) :-))
the trick is finding an Apple II emulator setup that can connect to the service, I haen't been successful there, yet.
GSport has strong serial port emulation support (with "builtin tcpser") but only for the Apple IIgs-specific serial port chip - for which there's no cc65 SER driver.
AppleWin has some serial port emulation support as well but I've never tried it on my own.
Regards, Oliver
We don't need an Atari port, thankfully, because Atari wrote one back in 1984 :) A few of us are disassembling it over on another part of github:
http://github.com/jduerstock/tlp
The adjustments for the Apple II mainly will revolve around a smaller default font (because of the fact that Apple II only has 280 dots across, instead of 320, this mandates more or less a 4x6 character set instead of 5x6... I still have to figure out how to scale down customer character sets that are streamed across...the algorithm for this is in the aforementioned Atari cartridge, but needs to be pulled out or converted to C.)
-Thom
We don't need an Atari port
But that one surely doesn't support Ethernet to directly connect to your server ;-)
this is true. ;)
-Thom
With a few minor adjustments, this code compiles via gcc for 6809, or modern linux boxen. I vote for making it cross platform, not just cross target.
I didn't dare to propose that here, but... From my personal perspective one of the primary benefits of programming retro machines in C is the ability to test/debug the code on Linux/Windows with nice/well-known debuggers. E.g. I fixed all the bugs the in the Contiki web browser on Windows using the Visual Studio debugger. I created a cc65-conio implementation for that purpose based on the Windows Console API (and someone else did the same based on ncurses). For PLUTO one could create a TGI implementation based on SDL. If this were my project I'd do that because I'd think that this investment pays off sooner or later. However, it seems to me that Thomas thinks - at least at this point - that he'll get this project done cheaper/faster/easier and telling him what I personally believe he'll have to invest until it runs (and performs) in a reasonable way could drive him off ;-)
Its pretty close already. I had a bare metal coco3 running it in a few hours. I maybe had six functions i had to implement.
@beretta42 for 6809 targets, I would rather recommend CMOC, which comes with a (small) library and it is maintained and updated regularly.
as for cmoc: that should help any developers working in a MS windows envrion, for sure! As of now, almost no std libraries are needed, which will add to the easy of implementing new platforms. We should be able to easily do both compilers.
@oliverschmidt I completely agree with your assessment, and don't worry about driving me off. There is a much bigger force pushing me to get these terminals done. I'm actually surprised that nobody has done an SDL wrapper around TGI for debugging. :)
The issue i'm running into now, is that the terminal is mostly complete, and working, sans working flow control and character loading... the former is proving difficult to track down, and the latter requires that I or somebody take an assembler algorithm and translate to C (which, admittedly, I've never done.)
-Thom
Is the asm code from source somewhere?
On Jun 26, 2018 12:53 PM, "Thomas Cherryhomes" notifications@github.com wrote:
@oliverschmidt https://github.com/oliverschmidt I completely agree with your assessment, and don't worry about driving me off. There is a much bigger force pushing me to get these terminals done. I'm actually surprised that nobody has done an SDL wrapper around TGI for debugging. :)
The issue i'm running into now, is that the terminal is mostly complete, and working, sans working flow control and character loading... the former is proving difficult to track down, and the latter requires that I or somebody take an assembler algorithm and translate to C (which, admittedly, I've never done.)
-Thom
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/tschak909/platoterm64/issues/2#issuecomment-400387266, or mute the thread https://github.com/notifications/unsubscribe-auth/ALWXoJfUq38dvasjBgmKkZEQnb_52uJtks5uAmcegaJpZM4UDIEC .
https://github.com/michaelsternberg/tlp/blob/52a634fd1ed54c71e8f7a8c1492fee2927a3e105/tlp.asm#L2629
Wonderful description of algorithm appears before the code.
Have done a significant amount of work on this, and have fanned everything out into system specific parts, that the makefile puts into targets. so far have c64 and atari, and will be adding c128 tomorrow, so I would call this goal reached.
I see. Just out of curiosity: Any reasons to spare the Apple II? The 280x192 compared to the 320x200? A very high percentage of Apple II machines support the 560x192 mode. However, there's currently no TGI support for that mode.
I'm not sparing it, just haven't done it yet. I will have to design a font for that system (a 4x6 font), as well as adapt the image processing routines for the character set download (when I have them done.)
It is planned.
-Thom
but it can now be done, because untangled the system dependent stuff.
-Thom
Hi,
One of the major benefits of the cc65 tool chain is to be able to generate programs for multiple 6502 machines from a single source. PLATOTerm seems like the very project to make use of that cc65 capability.
PLATOTerm already uses the cc65 TGI API for video output. Maybe it can use the cc65 SER API (http://cc65.github.io/doc/funcref.html#serial.h) for serial I/O. And I guess it surely can use the CONIO API for keyboard input (http://cc65.github.io/doc/funcref.html#kbhit and http://cc65.github.io/doc/funcref.html#cgetc).
Regards, Oliver