Jump to content
tschak909

PLATOTERM LITE 1.3 Cartridge Release

Recommended Posts

yup, I can do a handler load, but it looks like i'm going to have to be _REALLY_ creative with handler placement so that it will fit properly in 16K of RAM and allow the rest of the program to run.

 

-Thom

Share this post


Link to post
Share on other sites

@mr-atari If you know where the source code for the firmware on your devices is, I can patch it to default to a much more sane baud rate (e.g. we can patch it to start up in 9600 baud), and do the same for the terminal...

 

-Thom

Share this post


Link to post
Share on other sites

I have here, an experimental build of 1.3, which runs as a non-boot cartridge, but tries to cause an R: handler load.

 

This will work on 16K machines. If anyone has a 400 or a 600XL, please test. :)

 

Because this replicates the way it's done in AUTORUN.SYS type loaders, the APE handler will also load now (APE's R: handler does not respond to timed out D1: requests).

 

mr-atari's patch is going to take me some time to decipher and fold into atrrdev.s.

 

With the ESP firmware properly programmed, the mini-terminal in @mr-atari's serial driver will not be needed. We can make the necessary changes to make sure it starts up sanely.

 

-Thom

platoterm-lite-1.3-experimental-16k-with-load-handler.rom

Edited by tschak909

Share this post


Link to post
Share on other sites

The other thing to consider, if you are trying to make this an out of the box anyone can use it, without much knowledge deal (which is what it looks like your doing) is a device config or setup companion disk that does all the set up for people, they simply select the device from your menu and the settings are done and save for each device, whatever lantronix(mss|uds|eds)/esp/perle/wimodem/ etc that is might be.

 

That would ensure the devices are actually ready for PLATO TERM to use.

 

Edited by _The Doctor__

Share this post


Link to post
Share on other sites

If I am reading...my memory map of the outputted binary from the experimental build correctly:

 

Segment list:
-------------
Name                   Start     End    Size  Align
----------------------------------------------------
ZEROPAGE              000082  00009B  00001A  00001
EXTZP                 00009C  0000A6  00000B  00001
LOWBSS                000DC0  000DC2  000003  00001
DATA                  000DC3  000F6C  0001AA  00001
BSS                   000F6D  001FD0  001064  00001
STARTUP               008000  008062  000063  00001
LOWCODE               008063  008076  000014  00001
ONCE                  008077  0080BE  000048  00001
CODE                  0080BF  00B358  00329A  00001
RODATA                00B359  00BA61  000709  00001
UPPERBANK             00BC0C  00BC24  000019  00001
CARTHDR               00BFFA  00BFFF  000006  00001

 

looks like the highest address in ROM is currently BC24, which when subtracted from BFF9, gives us.... 0x3D7, or about 983 bytes of space.

 

Also if you notice, the RAM area for the code starts at $0DC0. Which is quite literally $0700 + the $6C0 bytes of handler that get loaded when the R: handler bootstraps itself.

 

With the BSS (uninitialized RAM space, this is mostly buffer area), this fits under $1FD0, which is 47 bytes shy of $2000. Why is this important? Because PLATOTERM needs an 8K block of RAM for the 320x192 mode F display.

 

This puts things _very_ snug on a 16K machine (which has a maximum address of $3FFF)

 

The DATA area, is the part of memory with pre-initialized variables that will change, I will try to whiddle this down as much as I can.

 

Some of the recent optimizations have included pushing a lot of the protocol decoder variables into zero page.

 

-Thom

Edited by tschak909

Share this post


Link to post
Share on other sites
11 hours ago, Mr Robot said:

Revised schematic, updated layout, case WIP

Screenshot 2019-09-28 at 12.47.03.jpg

Screenshot 2019-09-28 at 12.47.31.jpg

SIO232 CASE.png

That looks awesome.

 

At Fujima me and Manterola were also playing around with connecting an ESP07 directly on the SIO bus.

It works quite good actually and I proposed to use (but don't have a 3D printer) the SDrive2 plug as used by @alsp .

 

I checked with him and the 3D stencil is available to the public https://github.com/fintros/SDrive-ARM/tree/master/box

Using this plug your PCB would be standing up and the activity LED of the ESP would be visible.

The SDrive2 plug stencil off course also needs to be adapted to accommodate a higher/wider PCB.

Share this post


Link to post
Share on other sites

The tiny-terminal inside my driver is because PLATO can not connect the ESP to the server using it's TTY.

Before the ESP get's transparent you need to send the CIPSEND-command, and that is impossible.

PLATO is already connected to the server and data is ging back/forth (after the CIPSTART-command).

Thus making it impossible to send (any) line of text.

 

So, until this is solved, I need to connect to the server with the tiny-terminal.

Then press ESC, PLATO sees the connection and starts immediately, skipping TTY.

 

ESP-driver:

Memory-wise, it uses page 7 and 8 for code and page 9 for buffer (roughly).

Page 9 is free, when the user supports it's own buffer size/place.

 

ESP, out of the box:

This is a bit of a hassle, since you buy it set to 115k and every AT-hard-reset will set it back to 115k.

The ATARI (PAL) can't do 115k and the NTSC flaky (just in/out-side serial specification).

So I wrote a small program that does a simulated 115k bitrate, mixing the pokey's available 111k and 127k bitrate.

Sending the command to the ESP to go down to 1200 (1221 to be axact, lower values are wrongly accepted by the ESP, DO NOT TRY!!).

I can easily change this to 2400, 4800 or any other (unbound) bitrate for PLATO.

 

Grtz, Sijmen.

Edited by mr-atari

Share this post


Link to post
Share on other sites

the ESP8266 on the board can be re-programmed, so the issue of the baud rate being too fast, can be dealt with. 

 

e.g. we can re-flash with Paul Rickards' firmware, or start from the ZiModem firmware, and modify as needed.

 

-Thom

Share this post


Link to post
Share on other sites
7 hours ago, Lastic said:

That looks awesome.

 

At Fujima me and Manterola were also playing around with connecting an ESP07 directly on the SIO bus.

It works quite good actually and I proposed to use (but don't have a 3D printer) the SDrive2 plug as used by @alsp .

 

I checked with him and the 3D stencil is available to the public https://github.com/fintros/SDrive-ARM/tree/master/box

Using this plug your PCB would be standing up and the activity LED of the ESP would be visible.

The SDrive2 plug stencil off course also needs to be adapted to accommodate a higher/wider PCB.

I did think about using @alsp SDrive2 90° case design but decided against it because my board doesn't have an SIO passthrough and a lot of people use devices like Lothareks SIO splittter for devices like that. If the case was the form factor of the SDrive2 it would cover the SIO port next to the one it is plugged into.

 

The circuit designed by @mr-atari has a dual led on it, the case I'm designing will have a hole in it for that LED to poke out of, I just haven't put it in yet.

 

SPLITTERB.jpg

Share this post


Link to post
Share on other sites
7 hours ago, tschak909 said:

the ESP8266 on the board can be re-programmed, so the issue of the baud rate being too fast, can be dealt with. 

 

e.g. we can re-flash with Paul Rickards' firmware, or start from the ZiModem firmware, and modify as needed.

 

-Thom

I am using zimodem, but latest versions have some bug and crash after few seconds. So I am still using an old version. 

Another option is esp-modem, a much simple code, that works well as far as I know. Stefan uses that, and Lastic is doing some tests to see if it works OK for him.  It includes an address book and wifi credentials saving in the nvram.  Not sure if includes all the different wifi encryption options, though. 

 

Edited by manterola

Share this post


Link to post
Share on other sites

Pretty much, with Mr. Atari's optimizations, and the larger buffer being used by the handler means that 9600 baud can be done in PLATOTERM quite nicely (I am doing this with the 850 handler, which does properly honor buffer size)...

 

...so with the above changes, we can basically just set the power-up default to be 9600 baud on whatever modem firmware we choose.

 

-Thom

Share this post


Link to post
Share on other sites

I have set mine now to 4800, let see what it brings.

 

Yours (Thom) was set to 2400 before I shipped it.

It has a sticker on it with "2400", to remind you of setting plato to 2400. ;-)

 

Success on updating the firmware on the ESP. I leave it like it is.

Meaning the long TTY sequence of logging onto a BBS or Plato.

Don't know how/Don't dare to update.

So, please, get the TTY-modus of plato in line with the ESP logon sequence, thanks.

 

(Just thinking out loud, when you set the ESP to 19k2, you could install a firmware that boot-straps and send the driver to the Atari as the 850 does.....)

 

Later!

Share this post


Link to post
Share on other sites

There was a bug in the tiny terminal.

Preventing the baudrate to change.

Somehow it was stuck at 2k4.

I noticed this only after setting my baudrate from 2400->4800 using the AT+UART-command....

(oops)

In PLATO, changing the baudrate was OK.

R-ESP.ATR

Share this post


Link to post
Share on other sites

Small update:

Added 1800 and 19k2

 

Moved 300 and 600 baud to keys "H" and "BSP"

Keys 1-2-3-4-5-6 are now baudrates 1k2-1k8-2k4-4k8-9k6-19k

Default on OPEN R: is 2400 baud, internal 256 byte buffer

 

So, let's see if PLATO can do 19k2 ;-)

R-ESP.ATR

  • Like 1

Share this post


Link to post
Share on other sites

NeatO! I can't wait for the ESP to get here! :)

 

(in the mean time, I will be setting up my daughter's XEGS in her room today, and getting my 1200XL back)

 

-Thom

  • Like 1

Share this post


Link to post
Share on other sites

I forgot to mention the AUX-codes for these baudrates.

They are $08 though $0F, $08 being 600 baud and $0F 19k2

 

So you need to use $0F, for selecting 19k2.

Your buffer can start as low as $900

 

Actually my driver only checks the lower 3 bits, so 8 available baudrates, those obscure <300baudrates are not supported.

Edited by mr-atari

Share this post


Link to post
Share on other sites

I started to write some code to respond to type 0 and/or type 1 SIO polling, so we can embed Mr.Atari new rverter handler in the esp8266 itself. 

To be able to do that we will need a modification to the mr robot pcb design (half rverter interface circuit). The idea is to use one semi avaliable esp8266 output to enable/disable or override the mtr ctrl signal that blocks the esp8266 TX and RX signals. So first the esp8266 talks in the sio bus to answer the polling if necessary, then it switches to sx212 or rverter mode in which the mtr ctrl signal dictates...  Or maybe someone has a better idea about how to implement this, otherwise, the esp8266 won't be able to answer to polling. 

Edited by manterola
  • Like 3

Share this post


Link to post
Share on other sites
On 9/28/2019 at 9:36 PM, tschak909 said:

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.

Stupid question: Why do you want to include the R: handler loading into the cart?

If there is no disk drive present, the ROM will load the R: handler. At least with my 850 it seems to do so according to the SIO sound.

 

Share this post


Link to post
Share on other sites

I've since fixed that problem, although I need to add a status check, so that it doesn't load the handler if it's already there.

 

but to answer your question: in the case of the APE, for example, it does not respond to a SIO Type 1 poll, so it will not load itself if no disk drive present.. it only loads from an AUTORUN.SYS type handler.

 

This is just part of my never-ending quest to try and make this work on as many configurations as I can, because the thing that always kills me is when people say "IT DOESN'T WORK ON MY SYSTEM!"

 

-Thom

Share this post


Link to post
Share on other sites

Oh of course, and I've sent an email to Steve Tucker, about it (and trying to honor the buffer size requested).

 

This is why I would very much like for AT LEAST the R: handler for APE to be open sourced, so it can be fixed.

 

-Thom

Share this post


Link to post
Share on other sites

I'm honestly glad that the latest cart build does indeed run in 16K of RAM. 

 

Why would it matter? 

 

Because _somebody_ will try to run this on their 400, or 600XL. ;) that they grabbed from a swap meet.

 

Hopefully if an SIO adapter can be worked out and plopped in the box, that will be a "just use this" option. :)

 

Personal disclosure: I will have to curb my spending for the next 6 months, as I've just had to postpone my daughter's private school payment by 5 days. This is a bridge too far for me.

 

-Thom

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...

  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...