tschak909 / platoterm64 Goto Github PK

Setup on the Apple II needs better documentation. For example:

• The SSC must be in slot 2, but the release notes don't mention this.
• The SSC must have interrupts enabled (DIP switch on the card), but the release notes don't mention this.
• The SSC has DIP switches for various serial port settings. PLATOTerm doesn't use these settings, but the release notes don't mention this.
• Setup in an emulator requires multiple steps (see #13), and these steps need to be documented somewhere.

I'm happy to write this documentation. What's the preferred format (text, Markdown, HTML) and location (convention or organization or platform-specific documentation)?

You need to create a list of these somewhere.

I need to find a solution to the fact that when I add stdio.h, my code size balloons by 6K. I know I can use CIO on Atari, and there are the kernal routines in C64 and C128, am wondering, what I can do for apple2?

@groessler @greg-king5 am wondering what I should do? :)

-Thom

Report: (from @mr-atari)
TTY-mode, return sends CR LF LF (expected CR only)
BOTH-modes, SELECT-return sends CR LF LF (not CR LF)
TTY-mode, control-M sends CR LF (great, that works for me).
PLATO-mode, control-M does nothing (sends value $7B).

Hi,

https://www.irata.online/#connecting and the mentioning of tcpser indicate that IRATA.ONLINE is actually accessed via a TCP connection.

Instead of using a serial connection to some TCP proxy it is a viable alternative to have the 6502 machine do the TCP connection on its own.

There's a TCP/IP library available written in 6502 asm called IP65 (https://github.com/oliverschmidt/ip65) that is directly usable from cc65 C programs (https://github.com/oliverschmidt/ip65/blob/master/inc/ip65.h).

The IP65 library supports three Ethernet chips:

• Cirrus Logic CS8900A
• Microchip LAN91C96
• WIZnet W5100

From these three chips the CS8900A is the most popular. It's even so popular that it is emulated in all relevant emulators:

• C64: VICE
• Apple II: AppleWin & GSport
• ATARI 8bit: Altirra

If you are interested in Direct TCP/IP Access and have problems you can contact me...

Regards,
Oliver

I've noticed that when using the UP2400 driver, screens will often have garbage characters in places, and incorrectly-drawn or positioned, or sometimes completely missing elements - see the screenshot below.

This doesn't seem to be a protocol-decoding issue, since the same screens render fine with SwiftLink, but they always seem to render with the same corruption under UP2400. Could this be related to #28, discussing a change in the upstream UP2400 driver to fix an issue where 0x00 bytes got received as 0x0D? From commit f270f52, it looks like the the UP2400 driver distributed with PlatoTerm has diverged from that codebase, but I couldn't find a copy of the source to examine the changes.

When color support is enabled (with appropriate define in makefile) for color support, the up2400 driver fails and PLATOTERM crashes.

The swiftlink driver is
The color support requires an NMI trampoline to alter color ram, and I've in-lined it with the text output code, here:
https://github.com/tschak909/platoterm64/blob/master/src/c64/screen.c#L311

The existing NMI trampoline is here:
https://github.com/tschak909/platoterm64/blob/master/src/c64/nmi-trampoline.s#L1

and the user port 2400 driver for cc65 is here:
https://github.com/nanoflite/c64-up2400-cc65/blob/master/driver/c64-up2400.s

I suspect I may not be properly accounting for the NMI trampoline when flipping things in and out for color ram access.

-Thom

Got a work-in-progress brewing for a Plus/4 port of PlatoTerm, though it is contingent on a couple of bugfixes in VICE and CC65.

• PlatoTerm code is in the port/plus4 branch in my fork.

• CC65 must be built from my feature/plus4-tgi-driver branch (this branch also contains bugfixes for the plus4 runtime and a minor change to the plus4-stdser serial driver, to use Kernal variables for the buffer pointers so that PlatoTerm can keep track of receive buffer usage)

• VICE needs this patch to fix a bug that prevented the emulated ACIA from generating interrupts (and incidentally make the status register error bits clear when reading the data register, as per the datasheet).

For now, the following are known to be broken/questionable:

• Keyboard handling - seems to work in PLATO and TTY modes, but goes haywire in the preferences screen. Since I just lifted the keyboard code (and most everything else) from the C64 version, there are probably some PEEK/POKE location differences that I haven't accounted for, or something. Additionally, saw somewhere that the keyboard scancodes are subtly different, but I don't have a summary handy right now.

• RS232 flow control. As far as real hardware goes, my ESP8266 modem thingy doesn't have RTS/CTS hooked up, which explains the half-rendered screen in the attached picture, but even in VICE, I've seen display glitches that look like flow control issues.

Terminal stops outputting (but still accepts input) when doing the character set load in Mahjongg. Something odd happening after the paint code was added, maybe running off the edge of memory?

As fill is somewhat time consuming, add a toggle for it in setup.
-Thom

The current 128 release is almost unusable because while handling the "Welcome to Irata" screen, it executes a misfired floodfill that escapes and tries to fill the entire screen.

See https://www.c64-wiki.com/wiki/LOGO_%28Disambiguation%29

There is is no user interface for viewing preferences, such as selected baud rate. I often find myself re-entering preferences because I've forgotten what I entered previously.

I suggest an enhancement that summarizes the current preferences, like "Serial (Slot 2), 1200 baud 8N1", upon startup.

I brought this up on reddit, and was advised to obtain a virtual modem (tcpser) and cable (com0com) in order to connect using platoterm.

I started tcpser with -d /dev/ttyS8 -s 2400 -p 8005 -l 4 and configured com0com to make a null cable between COM8 and COM9.

If I use PuTTY to make a serial connection to COM8 and enter ATDTirata.online:8005 I can connect.

If I start AppleWin and direct it to connect it's virtual port to COM8 (note: I can use ProTerm on COM3 which is my real USB modem with no problems) and then boot Platoterm, I get nothing beyond the graphical PLATOTERM for APPLE ][ spash screen.

At present, the only supported serial interface for the C128 version is the SwiftLink UART cartridge. This is fine (preferable, even) for running in emulation, but on real hardware, support for software-driven RS232 over the user port (like in the UP2400 driver for the C64) would be desirable, as it doesn't require any additional hardware.

While the UP2400 driver is external to the PlatoTerm project, writing a similar driver for the C128 would be beneficial to the project, as it would allow C128 users without SwiftLink cartridges (such as myself) to use the high-res C128 PlatoTerm instead of the C64 version.

The magazine article that the UP2400 driver was based on ("Towards 2400", Transactor Magazine, vol. 9, issue 3, pp. 62) appears to talk about support for the 128 and even 2MHz mode, so in theory at least, it should be possible to modify the existing UP2400 driver code for use on the 128.

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

SDMCTL needs to be reset to 34 (normal playfield, no P/M DMA) when program exits (put it in screen_done()) so that P/M bar does not show up when returned to DOS.

Some other thing I dug up for you:

Found:
Changing the config will save a file called CONFIG.SER
Cause:
This is due to a residue of letter from the last file accessed (ATRRDEV.SER) left in the filename-buffer.
But the main cause is that there is no EOL character after the filename.

You can solve this by clearing the buffer first or (preferred) ending the filename with $9B

Suggest some sort of report that tells the user if the selected device (modem etc.) Is not found. At present the screen simply appears frozen and waiting infinitely.

Recent firmware versions of the 1541 Ultimate II cartridge allow the C64 to open TCP connections on its onboard ethernet interface. I use one, and it would be nice to be able to use that to connect, rather than my (unfortunately rather flakey) wifi-to-serial modem.

While documentation is thin on the ground right now, https://github.com/xlar54/ultimateii-dos-lib provides a library interface and some example applications, and the firmware source code describes the interface in a fairly straightforward manner. I'd be happy to throw together an implementation if you think this would be a useful addition.

Since the Ultimate II handles all the TCP logic and just exposes a byte stream to the C64, this (hopefully) shouldn't require much in the way of architectural changes, but I thought I'd open this issue before I started working on an implementation, in case you had any thoughts about how you'd like it integrated.

My initial thought would be to make it a general-purpose CC65 serial driver that can just be loaded in place of UP2400 or SwiftLink, with an additional driver-specific ioctl interface to specify a host to connect to. That way, the only major change required to the PlatoTerm code would be to prompt the user for a host and port at startup if using the Ultimate II driver.

I was not able to get online with my ESP for testing, so I did most debugging with altirra.
On the real atari, debugging done without be able to get online, but with my build-in feedback to see if keys work and data comes or goes.

Beside my report below, it looks great, pity it does not go all the way for me (for now).
I will try another method later this week, to get first online, then start plato.

Report:
TTY-mode, return sends CR LF LF (expected CR only)
BOTH-modes, SELECT-return sends CR LF LF (not CR LF)
TTY-mode, control-M sends CR LF (great, that works for me).
PLATO-mode, control-M does nothing (sends value $7B).

Filename-handling is not conform atari-standard, giving issues with other DOSsen.
Please pad the name with SPACE ($20) to 11 characters long or use EOL ($9B) if the name is short.
Use "CONFIG " or "CONFIG",$9B not "CONFIG", please.

The new "fill-in" screen takes long to draw, at 1200 baud the serial-buffer overflows.
Beside that, slowing down users from doing actual work can be rather annoying...
On faster systems, this looks nice, but on the atari the wait it looooooong.
Can the fill-in be disabled from the user/config?

Xon/Xoff, the plato-server does not respond to these codes.
I know I have raised this issue before, the server does it wrong, not the R:device/handler.
Now with the fill-in active..... Results in buffer overflows all the time.
Sending Xoff goes through the modem to the server and should pause the server.
Sending Xon goes through the modem to the server and it can start sending data again.
Can Xon/Xoff be disabled from the user/config?
Options now are 2 threshold values.

Need to clarify licensing.

The 640x480 interlaced graphics mode (c128-vdc2.tgi) currently used by PlatoTerm on the C128 only works on late-model (or upgraded) C128s with 64k of VDC RAM. Earlier machines with 16k of VDC RAM are out of luck. Additionally, even if the machine supports it, some monitors don't handle the interlaced mode well (on my Sony PVM, I have to put it into underscan mode to see the full screen, and I could imagine LCD monitors not liking it at all).

The c128-vdc.tgi driver uses a 640x200 mode that works on all C128s; building a version of PlatoTerm with that driver (and appropriate scaling changes) would make it usable on all C128s.

Since TGI drivers can (I think) be dynamically loaded at runtime, it would also be possible to select the appropriate mode at startup, which would be pretty cool.

(Sorry about the issue-spam; I’ve been poking around at the codebase lately and wanted to get some of my ideas out there to see what others thought)

We need much faster text output, that takes the 6x5 font data in the character set, and transfers it to the display, but with transfer modes:

• Rewrite, black background, white foreground
• Inverse, white background, black foreground
• Erase, transparent background, black background
• Write, transparent background, white background

I can of course figure this all out on my own, and spend months doing so...would really like some help.

-Thom

For the ESP8266 to become transparent, I need to send one more command to the module.
That is after the module has established connection and data from the server is coming in.
That is a no-go area for me, since plato does not send out CR/LF anymore, nor does control-M/J works.

Plato sends out 1xCR and 2xLF's, not CR/LF, giving errors back from the module. In TTY-mode

Having CAPITOL letters when configuring the connection would be nice, thanks.
Holding SHIFT makes you forget to release it when typing non-letters.
Most modem devices only accept capitol. AT is ok, at is error.

Graphics are drawn faster, but crooked, less nice then the previous build.
Odd pixels (making O->Q) and miss-drawn lines. Errors in backspace/erase and new characters.
Maximum baud-rate 1200 on the old graphic engine else it overflows, new engine can do 2400.
But needs a 256 byte R:buffer and throttled reply to the server.
1200 is safer to use.

plato assumes to be on D1, so when you load it from say D2 it fucks up your disk in D1...

Xon/Xoff does not work. Sending Xoff does not kills data from the server. Blocking Xon from being send does not matter either, data is still poring in.

Missing keys from the atari-layout, they are ignored and thus are not send.
Plato does not let me send $0A / CONTROL-J / LF
When you add LF back to the keyboard-def-table, it would work better for me.
CONTROL-J is not assigned by the plato-keyboard, so.

Inverse characters are not readable.

Data is read 1 character a time from R: , most likely slowing things down.

Immediately after loading PLATOTerm, I press "Option," then T)OUCH, then T)RKBALL, and finally E)XIT. PLATOTerm responds with "LOADING TOUCH DRIVER..." and hangs. The R-Verter device is not being closed - I can tell because the SIO motor control line stays high - so no disk I/O can occur.

Testing the 1.3 static release on stock 130XE with Arduino S-drive and ESP8266 R-Verter: Joystick initially works upon PLATOTerm startup. Moving the joystick moves the arrow in all directions OK. I change the baud rate to 2400, it loads the serial driver. But, when i move the joystick a second arrow shows up and both move at the same time only horizontally.

Take a look if the plato protocol uses zero bytes:
nanoflite/c64-up2400-cc65@c71b398

On a C64, I'm attempting to use tcpser with a serial null modem with the following settings "tcpser -d /dev/ttyUSB0 -s 2400"

I can dial irata online , i get a response and can see the "guest login: guest / guest" but there's nothing below to begin logging in and establishing an account. It basically freezes. Bummer, I'm really exciting about this project.

Hank
[email protected]

The C64, Apple2, and C128 targets need faster routines.

You can see an example of accelerated text output in:
https://github.com/tschak909/platoterm64/blob/master/src/atari/fast_text.s

can somebody adapt this for the above targets?

The fast text routine has flags for:

• double size/normal size
• transparent background mode/normal
• normal/erase mode

Hi Thom,

Firstly, what a cool project! I wish you every success and I'm really looking forward to becoming part of the PLATO community.

I've been trying PLATOTerm64 and after many failed attempts finally managed to connect; I didn't realise I needed to invert the modem make/break ratio pin with AT&P0 and enable hardware flow control with AT&K1 before connecting - adding this information to the documentation might be helpful!

However, PLATOTerm64 always locks up at the end of filling the cuboid image on the main menu. The mouse pointer still moves, just the terminal is unresponsive to keyboard input. The fill of the cuboid appears to go out of bounds just before it freezes - the last fill line shoots out diagonally left and down out of the cuboid to the other corner of the screen. The only way out is to reset the C64 - escaping the terminal with +++ doesn't work either.

I will try to upload a screen capture later to show you what I mean. From your Youtube video, the point at which this happens on my setup is here: https://youtu.be/rmRMXSdsF-8?t=453

This hasn't happened on the other main menu images yet - neither Atari nor Tandy that I can remember though I haven't experimented with PLATOTerm64 extensively.

Hardware:
UK PAL Commodore SX-64 and C64C
1541 Ultimate II floppy & cart emulator in expansion port
Wifi64 user-port wifi modem - 2400baud + AT&P0 + AT&K1
Wifi64 modem is this one: http://sharewareplus.blogspot.com/2018/01/commodore-64-wifi-modem-now-finished.html which I think is a "consumer" release of this one: https://blog.hpz.pw/commodore-64-wifi-modem/

Software:
PLATOTerm-1.0
Login as guest user and guest group/affiliation

Apologies for the rather wordy bug report.

Thom, is there an R: handler specification if I want to provide my own for the esp-cart? For example, where should the handler be located in RAM? Should the I/O buffers be located at a specific location? Thanks!

Apologies if this has already been asked.

Is Uthernet II support in the works for non GS Apple II computers (like my Apple IIe Enhanced, for instance)?

Thanks!