fujinet #FujiNet - a WIP SIO Network Adapter for the Atari 8-bit

[tschak909]

#FujiNet #atari8bit So far, I've gotten almost everything in FoReM XE Pro 5.4 to work correctly, except for file uploading/downloading. While I can properly configure the SIGs (and go into them, after modifying paths in both FOREMXE and MODULE.54), the program hangs when attempting to do an xmodem file transfer (which uses a call into AMP to pull it off.), it will send ONE SOH (CTRL-U), but it sends/receives nothing after that. Somebody who's a FoReM XE wiz will need to figure it out. -Thom

[tschak909]

I have added a new page of documentation on the Wiki showing additional commands added to the R: device, specifically:

 

* 0x4C ("L") bind a TCP listening port

* 0x4D ("M") close the TCP listening port.

* 0x4E ("N") toggle whether to lock baud rate from further CONFIGURE changes.

 

These commands augment the existing Atari 850 compatible commands to account for the fact that it's running as a TCP/IP device.

 

Of special note, baud rate lock was added to allow certain BBS programs to consistently run at a particular baud rate, e.g. BBS Express, which tries to intelligently change baud rate to match the caller based on the initial barrage of CR/EOL characters.

 

The 0x4C command is implemented in RLISTEN.COM, in fnc-tools, and the source code is pasted in the page above, for programmer reference.

The 0x4D command is implemented in RULISTEN.COM, in fnc-tools.

The 0x4E command is implemented in RBAUDLOK.COM, in fnc-tools.

 

Examples:

 

to listen for TCP connections to R: on port 6502:

RLISTEN 6502

to stop listening for TCP connections to R:

RULISTEN

to lock the baud rate of R: to 2400 baud:

RBAUDLOK 2400

to unlock the baud rate of R:

RBAUDLOK UNLOCK

More coming, so much to do...

-Thom

 

[tschak909]

Current status:

 

Have spent the last week trying to improve R: handling for BBS use. This has turned out to be a briar patch, as every BBS program abuses R: in their own unique ways.

 

The results from this:

 

* BBS Express 1.0 - Works when using RBAUDLOK to lock the baud rate.

* Carina II 2.7 - almost works, high speed SIO had to be turned off for me so MOE didn't throw a fit, otherwise, doesn't answer. argh.

* BBS Express 5.0b - works after changing ATA behavior to send the CONNECT string AFTER going back into STREAM after doing the block write.

 

If anyone gives a damn about this, then i'll pursue further.

 

In the mean time, I need to get back to working on N:, currently debugging the file level TNFS protocol, wildcard matching for directory listing is causing the device to time out, and I suspect it's because of subtle buffering issues with the UART (not sending the ack because it's expecting more data in the tx buffer?)

[tschak909]

#Atari8bit #FujiNet shown here running Carina II BBS on the R: device. Since it is a large BBS, it is shown here being copied into ram disk before use. Also shown here are two complete call sessions, showing that it does indeed work very well.

 

[_The Doctor__]

Holy crap that was FOREVER!

[tschak909]

1 minute ago, _The Doctor__ said:

Holy crap that was FOREVER!

Believe me, if you don't do the copy to the RAM disk, Carina is painfully slow.

 

-Thom

[_The Doctor__]

Battery backed up ram-disks reason for being

 

Nice job pushing your way through this!

[tschak909]

I am still having ONE issue, where I have to press RETURN on the connecting system AFTER the CONNECT banner appears.

 

Changing my modem firmware code to pause for a moment, causes Carina to pick up the resulting CONNECT banner, however it somehow gets confused, tries to switch baud rates, and hangs up.

 

I _really_ would like some help with somebody who knows how WAITCALL works to try and fix this goofy thing. @bf2k+ ??

 

-Thom

[_The Doctor__]

There may be some confusion... many of the old style BBS software tried to detect baud rate and translation from carriage returns... so you would connect and get a message from the BBS to smack return etc...

 

If the word connect is from the #FujiNet modem emulator or if it comes from BBS is the question...

each BBS used slightly different conventions that mostly all modems used back in the day...

some wanted numeric responses, some Verbal responses... if a modem strayed far outside the boundaries... a special wait call of configuration file was needed to fix up what the keyword would be to signal a connection was there and what kind...

 

Your modem might say connect 19200 and the bbs would parse that and set it's baud rate to match...

Todays modem says connect xxx.xxx.xxx.xxx ..... so it knows there is a connection but not the baud rate... this is why TCPIP/Express had new wait calls... simply to account for reading ip addresses and storing them in the user profile...

 

Generally only a handful of of Smart Modem or Lantronix commands need be emulated. They need to be configurable like a modem and respond with the admins/softwares selected choice of verbal or numeric answers...   This was the way of all communications products back in the day....

 

You've got two distinct pieces the Actual R: handler and then the #FujiNets Modem emu... it looks like you are finding the dividing line between the two and it's a wonderful thing that your xio sio choices are allowing all the functions you've packed in the entire device to get along, #Fujinet is a device duplicating/emulating beast. It's also a testament to your puzzle solving abilities!

Edited July 16, 2020 by _The Doctor__

[tschak909]

In my case, I am writing the MODEM firmware, and returning a baud rate that matches the currently configured baud rate (gotten from the last SIO CONFIGURE command to device $50).

 

-Thom

[Kyle22]

It would be nice to have the option of it returning CONNECT ip.ad.dr.ess for those TCP/IP Express users.

 

[tschak909]

seeing as it's virtually impossible to get a copy of TCP/IP Express, and the people who currently hold that copyright are complete twatwaffles (are any of you genetic defectives reading that hold the copyrights to Express reading? You all should be ashamed of yourselves.), that would need to be implemented, but completely untested.

 

[tschak909]

Would anyone like to take a copy of this FujiNet logo, and make a version using ATASCII characters?

 

(38 chars wide, 18 lines, so 720 bytes total)

 

 

[bocianu]

 

FUJINET_LOGO.ASC

Edited July 17, 2020 by bocianu

[+mytek]

I'll try to make this quick so as not to sideline this topic too much. I know you are writing all kinds of software for FujiNet, and some of it appears to be menu driven. It would be nice to support and/or take advantage of the TK-II special navigation keys as they are mapped on the PS/2 keyboard.

 

Here's a graphic showing the Atari key codes that are assigned as single key presses (without CTRL or SHIFT) to the navigation section. Decimal on top, and the hex equivalent on the bottom. Some of these are 1200XL function key codes, which are recognized by any XL or XE system.

 

 

TK-II Manual

 

Thanks

 

[ivop]

23 hours ago, bocianu said:

FUJINET_LOGO.ASC 520 B · 3 downloads

What's that editor you used? Looks handy!

Edited July 18, 2020 by ivop

[bocianu]

1 hour ago, ivop said:

What's that editor you used? Looks handy!

That's ARTur Atascii editor.

Can be downloaded HERE.

 

handy keyboard shourtcuts:

 

 

 

 

Edited July 18, 2020 by bocianu

[tschak909]

#FujiNet #Atari8bit Hello to all reading this, who may be able to chime in:

I am currently trying to re-think some parts of the N: device, while I still can (while almost nobody is actually using it).

There are two parts to the N: device: The handler, on the Atari, which converts CIO to SIO. And the Firmware, which converts SIO into actions on the ESP32.

This is fundamentally important, because SIO is block based, and CIO is character based. To simplify discussion for now, I am only talking about the SIO layer.

THE SIO LAYER:

You can see the SIO commands for the N: device here: https://github.com/FujiNetWIFI/fujinet-platformio/wiki/SIO-Commands-for-Device-IDs-%2471-to-%2478

SIO is half duplex. It only handles data in one direction at a time, and although there is a field in the command structure sent to the Atari to tell how many bytes need to be transferred, this does not get conveyed as part of the command frame either to or from FujiNet, which we need for READ and WRITE operations. However, the two AUX1 and AUX2 bytes do. So we have to duplicate what is in the DBYT field in the AUX1 and AUX2 fields, so that they show up as part of the command frame, and can therefore be intercepted by the firmware.

OPEN – creates a protocol connection, payload goes to the FujiNet, and that payload is the N: file specification. AUX1 becomes the open mode, at the very least, bit 2 and 3 are reserved for read and write, respectively by CIO, so we need to mirror those.

In OPEN, AUX2 becomes the TRANSLATION mode, that is, given an end of line sequence, how do we translate it? Currently: 0 = no translation, bit 0 translates CR, bit 1 translates LF, so if bits 0 and 1 are set, then CR/LF are translated to and from the two end points. Doing both CR/LF makes things more complicated, because either a byte will be ADDED (in the case of converting a single EOL byte to CR/LF bytes), or a byte will be SUBTRACTED (in the case of converting CR/LF bytes to a single EOL byte). Remember that we specified how many bytes to read/write, ahead of time?

When a STATUS command is sent, four bytes are returned.. BL BH CO ER, BL and BH are the low and high bytes of the # of bytes available (up to 65535), while CO is Connected (1 = connected, 0 = disconnected), and ER is the error code that gets passed to the CIO handler.

So let’s say we’re reading data from an HTTP end-point:

OPEN N:HTTP://www.google.com/

and in a loop:

```

STATUS();

while (status.bytesAvailable>0)

{

READ(buf); // Decrements # of bytes available.

process(buf);

STATUS();

}

```

So as part of the loop, we’re doing a status to see how many bytes are available.

The WAY I deal with translation currently, is literally to fudge it, keeping the same # of bytes:

If CR, then EOL gets translated to CR, CR gets translated to EOL.

If LF, then EOL gets translated to LF, LF gets translated to EOL.

If CR/LF, then the transmission buffer gets enlarged by 1 (and transmit buffer length increased by 1), and EOL becomes CR, with LF inserted immediately after, while on the receive, CR becomes a SPACE, while LF becomes the EOL.

This allows the receive buffer to not need to change size. Is this a bad idea?

A variation of this, is the translation of directory data for network file system endpoints. You can specify in the OPEN call if you wish to read the directory (aux1=6), but Every network protocol does a file directory differently, presenting what is conceptually a list of objects in wildly different array of syntax.

While in some cases we could display the data as is (e.g. from FTP), a number of Atari programs (such as (AtariWriter) expect something that looks like the Atari DOS disk directory. This is why even DOSes like SpartaDOS default to a directory listing that looks like Atari DOS. This means that there is currently code in the firmware to translate the directory data that comes back from a protocol into something that looks like a DOS 2 directory. Currently, this also means that the ACTUAL read of directory data happens in the STATUS call, draining the data into the receive buffer, while READ drains the RECEIVE buffer to the Atari and subsequently clears it for the next status call.

So the question becomes: Is there a better way? Currently the CIO handler on the Atari is about 1000 bytes of code, with 256 bytes of buffer on top (so 1.3K in total memory usage). It’s small because everything happens on the ESP, and the handler passes everything through (with some small exceptions). CR/LF translation could be moved to the Atari in the CIO handler for example, adding approximately 40 or so bytes of code, but how should we handle things like file directory translation? Is handling in the status call the only sane way to really do this?

Thoughts?

 

[tschak909]

@jeffpiep has done it again! OkiMate 10 emulation, _WITH_ COLOR support! printout_11.pdf

 

[Fierodoug5]

Does the current new code still work on older esp32 wroom boards?

[mozzwald]

15 minutes ago, Fierodoug5 said:

Does the current new code still work on older esp32 wroom boards?

I don't know but you can still try to build it. Copy the platformio-sample.ini to platformio.ini and modify it for the WROOM board:

default_envs = fujinet-wroom

 

[StickJock]

About your CR/LF conversions:

If you are converting EOL to CR/LF, you are incrementing the buffer length.  What if the buffer length is $FFFF?  This would increment to $0000.

 

Going the other way, converting CR/LF by replacing the CR with a space - what if the line is at the max length for the device (say, 80 for an 80 column printer, or 40/80 for the display, and then instead of doing the CR, you do a space?  This would cause the printer or screen to advance to the next line, and then you would do the new EOL which would then advance to the next line, which would end up "double spacing" the text.

 

I don't have answers for you, but I wanted to make sure that you considered these corner cases.

 

[_The Doctor__]

2 hours ago, tschak909 said:

@jeffpiep has done it again! OkiMate 10 emulation, _WITH_ COLOR support! printout_11.pdf

 

Awesome, he could easily take it to OkiMate 20 density with almost no work at all... although I'm not sure if the pack in software supports the greater number of dots...

Kick *ss work.

[mozzwald]

9 hours ago, Fierodoug5 said:

Does the current new code still work on older esp32 wroom boards?

 

9 hours ago, mozzwald said:

I don't know but you can still try to build it. Copy the platformio-sample.ini to platformio.ini and modify it for the WROOM board:

default_envs = fujinet-wroom

 

I tested the latest code with my older WROOM board and it boots from a tnfs server. That's as far as I tested, YMMV with other features

[Fierodoug5]

Just updated both my wroom units, all seems to be working fine.