AtariGeezer Posted September 28, 2019 Share Posted September 28, 2019 io_handler_load_success: LDA #$0B something missing after this? Quote Link to comment Share on other sites More sharing options...
tschak909 Posted September 28, 2019 Author Share Posted September 28, 2019 oops, supposed to be LDX -Thom Quote Link to comment Share on other sites More sharing options...
tschak909 Posted September 28, 2019 Author Share Posted September 28, 2019 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 Quote Link to comment Share on other sites More sharing options...
tschak909 Posted September 28, 2019 Author Share Posted September 28, 2019 @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 Quote Link to comment Share on other sites More sharing options...
tschak909 Posted September 28, 2019 Author Share Posted September 28, 2019 (edited) 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 September 28, 2019 by tschak909 Quote Link to comment Share on other sites More sharing options...
_The Doctor__ Posted September 28, 2019 Share Posted September 28, 2019 (edited) 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 September 28, 2019 by _The Doctor__ Quote Link to comment Share on other sites More sharing options...
tschak909 Posted September 29, 2019 Author Share Posted September 29, 2019 (edited) 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 September 29, 2019 by tschak909 Quote Link to comment Share on other sites More sharing options...
Lastic Posted September 29, 2019 Share Posted September 29, 2019 11 hours ago, Mr Robot said: Revised schematic, updated layout, case WIP 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. Quote Link to comment Share on other sites More sharing options...
mr-atari Posted September 29, 2019 Share Posted September 29, 2019 (edited) 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 September 29, 2019 by mr-atari Quote Link to comment Share on other sites More sharing options...
tschak909 Posted September 29, 2019 Author Share Posted September 29, 2019 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 Quote Link to comment Share on other sites More sharing options...
Mr Robot Posted September 29, 2019 Share Posted September 29, 2019 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. Quote Link to comment Share on other sites More sharing options...
manterola Posted September 29, 2019 Share Posted September 29, 2019 (edited) 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 September 29, 2019 by manterola Quote Link to comment Share on other sites More sharing options...
tschak909 Posted September 29, 2019 Author Share Posted September 29, 2019 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 Quote Link to comment Share on other sites More sharing options...
mr-atari Posted September 30, 2019 Share Posted September 30, 2019 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! Quote Link to comment Share on other sites More sharing options...
mr-atari Posted October 1, 2019 Share Posted October 1, 2019 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 Quote Link to comment Share on other sites More sharing options...
mr-atari Posted October 2, 2019 Share Posted October 2, 2019 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 1 Quote Link to comment Share on other sites More sharing options...
tschak909 Posted October 2, 2019 Author Share Posted October 2, 2019 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 1 Quote Link to comment Share on other sites More sharing options...
mr-atari Posted October 2, 2019 Share Posted October 2, 2019 (edited) 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 October 2, 2019 by mr-atari Quote Link to comment Share on other sites More sharing options...
manterola Posted October 2, 2019 Share Posted October 2, 2019 (edited) 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 October 2, 2019 by manterola 3 Quote Link to comment Share on other sites More sharing options...
tschak909 Posted October 2, 2019 Author Share Posted October 2, 2019 Fantastic idea! -Thom Quote Link to comment Share on other sites More sharing options...
sanny Posted October 2, 2019 Share Posted October 2, 2019 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. Quote Link to comment Share on other sites More sharing options...
tschak909 Posted October 2, 2019 Author Share Posted October 2, 2019 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 Quote Link to comment Share on other sites More sharing options...
sanny Posted October 2, 2019 Share Posted October 2, 2019 Could be tagged as bug in APE ? But I've understood... Quote Link to comment Share on other sites More sharing options...
tschak909 Posted October 2, 2019 Author Share Posted October 2, 2019 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 Quote Link to comment Share on other sites More sharing options...
tschak909 Posted October 2, 2019 Author Share Posted October 2, 2019 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 Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.