PLATOTerm for Atari - Working out tgi and ser issues.

[tschak909]

Ok, so.. I've now cut a brand new test release.

 

DOS 2.5 is now used as the base DOS.

 

The fancy loader is temporarily gone, until I can come up with a solution that works well, that will automatically load the right handler and PLATOTerm. any pointers on this would be welcome.

 

The "touch" driver is now by default set to NONE. This is so R-Verter users can work out of the box, as R-Verter and Touch conflict with each other (it freezes while trying to do the mouse_load which also does mouse_install, which is where it actually fails...), so to end-around this for now, I have set the touch driver to none. If you are an R-Verter user, and change the Touch driver in the OPTION setup menu, you will freeze. If this happens, simply delete the CONFIG file. You have been warned. Atari 850 users do not have this issue. If you enable touch, and you're not an R-Verter user, and things freeze, please go to the Issues tracker in github and let me know.

 

The details and preliminary documentation is here:

https://github.com/tschak909/platoterm64/releases/tag/TEST_20180911

 

Please let me know how this fares, compared to previous builds. I want to tidy all this up as soon as possible, and get a solid release out to you guys.

-Thom

[_The Doctor__]

am I to understand that JoyTouchEmu is also disabled and bad things will happen using the old joystick method as well when using an r verter?

[tschak909]

since the joystick in PLATOTerm is loaded as a "mouse" driver, and all the "mouse" driver support is set to NONE by default, then yes.

 

This is a weird issue that will need to be tracked down.

 

-Thom

[mr-atari]

No, does not work.

 

I have my R-driver setup and loaded, then I load plato and it stops there.

Only thing I can do is OPTION, but that brings me nothing too.

Seems that it does not open device R: for communication.

Although its installed.

 

Why does PLATO clears page 6 ?

[mr-atari]

OK, got something working now.

Strange error (not reported, plato just continues), not closing IOCB #1 and opening it for atrrdev.ser....

 

anyhow

 

Using Rverter, 2400 baud, 256byte buffer, it overflows.

Switched down to 1200 baud, 256 byte buffer, OK, hardly 16 bytes used.

Same graphic issues as before, checkers is unplayable.

(see picture)

Also I noticed some weird rounding and strange angles in text/graphics.

 

Graphics are drawn faster, nicely done !

But crooked, alas less nice then the previous build.

Maximum baud-rate 1200 else it overflows (so, same as before).

 

Cheers.

Sijmen.

Edited September 11, 2018 by mr-atari

[tschak909]

looks like some translation errors happening subtly in firmware. What firmware are you using for your internet device?

 

-Thom

[tschak909]

I really want to cry.

 

DOS 2.0 allowed me to move the RUNAD down to $2200, which, gives enough space for everything to work, even the R-Verter.

 

Everything, except the fucking P:R: connection. With the P:R: connection, it shoves MEMLO up to $2411 (sloopy's testing)

 

But if I shove MEMLO up to $2500, then my Atari 800 with 48K of RAM is no longer able to install the CC65 serial driver.

 

I do not know what the fuck to do.

 

-Thom

[tschak909]

I want to punch the Atari engineers for being so stupid about installing non-relocatable code for handlers...

 

-Thom

[tschak909]

Build updated YET AGAIN, Load address $2420, just above the MEMLO for the P:R: connection under DOS 2.

 

Please let me know if this works.

 

https://github.com/tschak909/platoterm64/releases/tag/TEST_20180911

 

-Thom

[sanny]

What to checkout from github to build locally? I'm seeing a new branch 'atari_fast_text' and a new tag 'TEST_20180911'. Both fail because of a missing 'screen.s'. Did you forget to check-in?

 

regards,
chris

[tschak909]

Yup, I cut the release before I checked in. Bad me. Whoops.

 

I have checked all the relevant bits into atari_fast_text.

 

-Thom

[_The Doctor__]

what did you define APPMHI as and what did you define RAMSIZ as?

I didn't get very far this time.

might I also ask why PlatoTerm doesn't like to relocate? Is it not using branches?

last really stupid question... If you don't like the R:handler how hard to make something to sit where you wish it to, people make their own handlers. another thought was if you don't like things moving because of different handlers and you use fixed code for term, why not pad the handlers out with null handlers to keep things slotted where you wish.

 

I sure I'm misreading the whole thing as usual, but just be abstract for a bit.

Edited September 11, 2018 by _The Doctor__

[tschak909]

What happens when you try to run it?

What's your hardware complement?

 

-Thom

[_The Doctor__]

130XE, MIO, Lantronix, hard and floppy

 

I think I'm going to just make a stack of R: for you and try it on every one each time.

MIO, BB, PR: 850 and sx212 rverter. putting it all away and digging it out and setting it up again is a hassle, might as well make it semi permanent.

 

I'll set up like this with real hardware.

MIO1meg-130XE

BB-320XE

850 800XL floppy only

PR 800XL MyIDE

 

will that cover the bases or do you want a specific combination to test with, lastly are you still wishing it to be tested with all DOS versions or just 2.5?

Edited September 11, 2018 by _The Doctor__

[tschak909]

yeah, that should cover a good solid # of bases.

 

And I'm testing with the following OS combos:

 

DOS 2.5

SpartaDOS 3.2 (and RealDOS)

SpartaDOS X

MyDOS 4.53

 

That should cover most of them. Any that others are using that I should explicitly cover?

 

(I did try with DOS 3, on a lark, and it almost works, but it crashes when loading the serial port driver)

 

-Thom

[tschak909]

meanwhile, i've rolled out almost all the 8-bit ports, for a picture:

 

Atari 800

Apple ][

Commodore 64

TI 99/4A

Sinclair ZX Spectrum

Amstrad CPC

 

Not pictured, but working:

Radio Shack Color Computer 3 (DECB)

Commodore 128 (uses the VDC for a full scale PLATO display, but x128 does not emulate the VDC completely enough to show.)

 

All from the same code-base

 

-Thom

[Kyle22]

Wouldn't it be faster on each machine if it were written in Assembly? It may be capable of a much higher baud rate.

 

Just asking.

 

Edit: Damnit: One typo.

Edited September 12, 2018 by Kyle22

[tschak909]

sigh.

 

You want to write lots of different ports each in Assembly? Have you actually tried to tackle something like that? You'd still be stuck debugging the protocol handler. (I speak from experience.)

 

I have limited amount of time, and a huge project scope that must be tackled to achieve the goals that I want to achieve. So I am trying to attack the problem as intelligently, as I can.

 

step 1, is getting a terminal written and out there in the hands of everyone, for as many systems as I can, just get it working.

step 2, is to accept patches from others to make things better and faster, possibly to foster a path to ownership of each port to other people.

 

-Thom

[Kyle22]

Thom, I did not mean to offend. Just asking if this could be a possibility in the future.

 

[tschak909]

oh yes.

 

To start, functions in C can be replaced with assembler functions, to be called from the main C code.

 

This process can be done to systematically leverage speed in critical sections, while keeping e.g. the protocol decoder sections in C, due to their extreme complexity (if you look at the protocol decoder on the original Atari cartridge, you'll see that it is dense and full of gymnastics tricks.)

 

-Thom

[Kyle22]

oh yes.

 

To start, functions in C can be replaced with assembler functions, to be called from the main C code.

 

This process can be done to systematically leverage speed in critical sections, while keeping e.g. the protocol decoder sections in C, due to their extreme complexity (if you look at the protocol decoder on the original Atari cartridge, you'll see that it is dense and full of gymnastics tricks.)

 

-Thom

Nice

[tschak909]

Can PLATOTerm be not only used in SpartaDOS X, but also be installed to a hard drive, and be used alongside TD?

 

YES.

 

 

This will be in the next build, in the next day or two.

 

-Thom

[mr-atari]

When plato is loaded from D2, it assumes the rest of the files are on D1....

That should not be this way.

It should be using DUNIT and load files from the active drive.

The resulting errors, file not found, end of file, are not shown when loading.

Took me some hours to hunt down these ghosts.

 

Memlo should not be an issue, did you minimize DOS?

That can shave off some bytes.

For me it's certainly no issue, memlo without driver is $0f00

 

I'm still unlucky to get online with my ESP8266 connected directly to SIO.

Only had success with Bobterm connecting to a BBS.

 

Question 1:

Does plato let me send $0A / CONTROL-J ?

So I can add RETURN and CONTROL-J to send commands to my module?

 

Question 2:

Does plato send out a Xoff when the buffers fills up and Xon when its drained below treshhold?

I noticed that 2400 baud is to fast, my buffer of 256 bytes overflows.

 

Question 3:

Why does plato clears page 6?

 

Grtz,

Sijmen.

Edited September 12, 2018 by mr-atari

[tschak909]

1: I can add the necessary line feed.

 

2. it currently does, but it will not help unless your firmware handles XON/XOFF locally, and to my knowledge, the firmware you guys are flashing to these devices, doesn't, even when you send the relevant AT&Kx command.

 

-Thom

[mr-atari]

Hmmm, OK.

 

I tried this in my driver.

Xoff when 80% buffer and Xon (when Xoff was used) when empty again.

When I send Xoff, the plato server does not stop sending.

 

I looked into your keydef_table.

control-x is mapped to $0A.

So I tried this.

AT <return> <control-x>

-nothing-

 

Checked serout, it does not send out $0A, it does $26.

Then I changed your keydef, added $0A for the /|\ or inverse key.

That was undefined with $FF.

Nop, still no $0A sended out, again $26

 

Page 6, why does plato clears it?

I notice that it is not used, so why clear it.

 

This is what I can do so far.