PLATOTERM LITE 1.3 Cartridge Release

[tschak909]

and that's why. The R:Verter handler only uses the first 256 bytes of the input buffer. At 9600 baud, this can quickly overflow as roughly 1000 bytes come crashing in at once.

 

sigh. Can somebody _PLEASE_ write a better handler?! I am _begging_.

 

-Thom

[mr-atari]

MyIDE-][ does 16k cartridge emulation.

That is what I use to test PLATO.

[tschak909]

A bit of an update:

 

I have been able to get the cart to run in systems with only 16K of RAM, BUT ONLY if DOS isn't loaded.  (memory is really tight, 8K of RAM is used just for the graphics memory, 1024 bytes used for a receive buffer, 768 bytes for font data, etc.)

 

and

 

I am trying to get a plan in motion to try and get SIO WIFI dongles plopped in the PLATOTERM boxes, so this can be used out of the box.

 

-Thom

[mr-atari]

How much room is left in your cartridge, I mean can it fit (my) tiny R:handler, like, say 256 bytes?

Otherwise a sio2wifi module is work-less.

[tschak909]

I'll do what I can to make it fit. It should, at this point, I've been doing a lot of squeezing.

 

All I ask is that the messages etc are stripped out. and that it is able to utilize the larger receive buffer that is asked of it.

 

-Thom

Edited September 25, 2019 by tschak909

[mr-atari]

In the meantime, I use the bootable R-verter driver from disk (No DOS), that does what you ask it to do.

 

Have to re-do the SPECIAL baudrate-command, since you should not/can't overwrite this.

Baudrate is set using an AT-command, not by changing the pokey bitrate.

 

Later!

[mr-atari]

On 9/23/2019 at 9:34 PM, tschak909 said:

 

Which interface are you using? Apparently only the Atari 850 handler correctly uses the whole 2048 byte buffer allotted to concurrent mode. Seriously, the more I deal with Atari R: and RS232, the more I get angry at just how ham-strung the whole design was.

Short question:

Why is PLATO 1.3 reserving $C00 buffer (3k) instead of your 2048 mentioned above?

[tschak909]

Looks like the version I was testing that did 3K made it out.

 

-Thom

[mr-atari]

Next:

Does PLATO use translation modes $00 (EOL<->CR) or $40 (Add LF to translated CR) ?

[_The Doctor__]

unless something has drastically changed, Plato should work best with a raw connection and no translations as it has it's own word and terminal protocols outside of what consider the normal scope of most terminals. The only issue is during initial dial up, when the modem/lan device needs to connect once you have connected it should all be handled through Plato without translation since Plato has it's own if no one changed things.

You need to look up whatever the serial to lan adapter of choice expects for atdt ip/# or any return for that matter... but once connected everything should be raw and transparent... again if it's not been modified....

 

 

Edited September 27, 2019 by _The Doctor__

[Mr Robot]

I very much like where this thread is going

 

[manterola]

I am actually having problems with the fast io 2400baud 1.2 and 1.2.1 versions: everything works until I got actually connected and get  to the login screen of platoterm. In that point everything I type got not echo and enter doesn't work either. My guess is that it has something to do with the translation, since platoterm 1.0 and now 1.3 works withouy problems. 

I'm using esp8266 rverter based

[Mr Robot]

So a first pass at making a thing. Need to print and make sure the sizing looks good. SIO connector width but a bit longer. 

 

 

[tschak909]

2 hours ago, manterola said:

I am actually having problems with the fast io 2400baud 1.2 and 1.2.1 versions: everything works until I got actually connected and get  to the login screen of platoterm. In that point everything I type got not echo and enter doesn't work either. My guess is that it has something to do with the translation, since platoterm 1.0 and now 1.3 works withouy problems. 

I'm using esp8266 rverter based

Mr. Atari is sending one of his dongles to me, and I will start testing and working through the problems.

 

The goal here is to have a cartridge version that works with these R:VERTER devices, and...hopefully eventually get something that can be ploppinated into an SIO connector that can be mass produced.

 

Let's get ALL the Atari's connected!

 

-Thom

[Mr Robot]

Was 1mm to big, quick reshuffle and it looks about right

[mr-atari]

I posted this on facebook, small change to the schematics, the 3.3v regulator is to week.

"I currently use the LM2937 (500mA), because the 2950 (100mA) kept resetting the ESP for 1-2 minutes before it stayed ON....
And changed the 10 uF to 0.1 uF, removed the 0.1 uF between 5vReady and ground."

 

I have put the board vertically in the SIO-plug, that just fits.

The 7404 can be a SMD-version, but I have put a DIL in the gap on the other side.

 

[mr-atari]

My question about translation is for the driver.

Currently it only supports RAW and sends Error-146 if something else is chosen.

If plato uses it in TTY-mode, then I have to add this.

 

Variable buffer/size and location already works, as changing the baudrate.

But changing the baudrate only is to match the atari with the ESP.

Changing the baudrate on the ESP is done with an AT-command.

 

Work in progress and quit working OK:

R-driver as bootable disk.

Patched FAST-IO in a 1.3 version NOTOUCH, GET BYTE and STATUS only.

 

Later!

[tschak909]

platoterm is always in raw mode, so that's okay.

[mr-atari]

OK, here are my w.i.p. versions:

I do have the impression, PLATO has changed internally and the server interaction is different.

(Perhaps that's why FAST-IO 1.2 stopped working.)

 

Anyhow, I tested 9600 baud and that goes OK.

 

Baudrates 300-600-1200-2400-4800-9600 supported by the driver.

Colors in the background, just to check if transmission still goes.

(300 and 600 are not supported by the ESP, but I have included them for R-verters)

PLATOTERM-LITE-ATARI-1.3-NOTOUCH-FASTIO.rom FASTIO.ASM R-ESP.ATR

Edited September 28, 2019 by mr-atari

[tschak909]

cool. ok, this definitely shows an improvement, even at 9600 baud when the buffer isn't totally utilized (APE).

 

Sijmen: your ESP should be here in a few days, and I will be testing this extensively, and working on trying to fold your assembler changes above into the serial driver. I may have to gently ask Christian Groessler for help.

 

(for all I can do, I really...reaaaaaallly suck at assembler)

 

---

 

I have also been testing with APE, since that is what I have here for connectivity:

 

Am trying to tackle APE in a two-pronged fashion:

 

(1) ask Steve to tweak the driver to allow the bigger buffer, and

(2) try to find a set of buffer tolerances that will allow XON/XOFF to be triggered properly.

 

---

 

Dunno if it has been noticed, but, William Schaub had been doing quite a lot of work on the underlying NOS system and to the PLATO to NAM interface (PNI) to support XON/XOFF. It now works (with an appropriate latency due to it being in-band flow control)...

 

Also, Thank you, so much Sijmen, for hacking on this. If I ever meet you in person, I wanna give you a huge hug.

 

---

 

Also, with this, I am finding it very difficult to justify the disk based version for the Atari systems. There really is no reason for it, other than for preferences and the fancy splash screen.

 

I can always build an XEX that runs alongside the cartridge version. 

 

The advantage of the cartridge version is that once we get the bits and pieces all shoved in, it will work even on 16K systems.

 

I still need to also look into how the 850 handler load happens etc so that I can cram that straight into the cartridge, see how many bytes that takes up.

 

The last big challenge, that Chris (sanny) has been experimenting with, is cramming all the touch drivers etc onto the cartridge. This is a really daunting challenge, as all four drivers together take up roughly 512 bytes (and some change) on the cartridge, and it's proving to be _REALLY_ interesting to find the space.

 

I have literally had to completely do the Atari Cartridge port seperately from the main tree (I literally started from a skeleton, and folded in PRECISELY the code needed, carefully removing any and all fat that I could find.), and it has been quite nuts to make it all fit.

 

I really do appreciate the patience given.

 

-Thom

Edited September 28, 2019 by tschak909

[Mr Robot]

Revised schematic, updated layout, case WIP

[_The Doctor__]

Cartridges might be needed for systems(normally consoles) that have no memory. Turning the system on and off, plugging and unplugging cartridges is fine for playing games.

The reason why so many love disk versions are because we like to use the computer and bop in and out of our software like every other convenient and well behaved system does.

This is just one of the reasons why stack-able and pass through carts were developed and were made in a fashion that they could operate in different modes, ala SpartaDOS X etc.... the cart is still accessible with the other cart on top or next to it active, you can turn them on or off as well, you can go to disk based DOS and back, no power cycling or cold start needed...

 

PLATO was meant not only to be able to store information but also run programs locally as well.

 

If the PLATO cart will allow load through and device drivers, perhaps some form of cart control that would be in keeping with such wonderful history.

Edited September 28, 2019 by _The Doctor__

[tschak909]

A portable Micro-TUTOR implementation is planned, it is COMPLETELY documented, and I have the source code to the virtual machine, I just have to figure out a way to fit it in. It will require overlays or bank switching.

 

(If somebody wants to take a crack at converting the Micro-PLATO virtual machine to C, please try. The source code that I have is Z80 assembler.)

 

As I said, To appease the non-cart people, I'll make single XEX (COM) versions.

 

-Thom

 

@Mr Robot Also, the above design is awesomesauce!

Edited September 28, 2019 by tschak909

[tschak909]

The only thing I can NOT do, is squish this terminal into 8K of code.

 

God knows I've tried. Multiple times.

 

 

[tschak909]

Can anyone see what I'm doing wrong here? am trying to graft in an R: handler load directly into the cart: I get a raspberry, but no beep.