Jump to content

Recommended Posts

Maybe make it configurable? Since not everyone is DT80 user, but will use their favorite terminals instead. I know the worry but, so long as it ships as default for DT80 speed that should be good. If a 'power user' changes a things they should know what they are doing. Just put a note in the manual about fixed terminal speeds for something like DT80, just in case. Just some ideas. Some terms can be fast, others slow... some are weird in that they were written for the iNdus GT and might do changing speeds depending on drive usage. (GT Drive is full speed but external to the GT SIO drives bounce up and down on SIO to get stuff done.

Edited by _The Doctor__
  • Like 2

The slot to slot copy feature doesn't work for me.  At least for external TNFS servers.  I get the message that I should wait for the activity light to go out before pressing any key but it never goes out.  (I've let it sit for hours).  When I do hit a key anyway, there is an image with the correct name, but any attempt to boot it just goes to self-test.  My machine is a U1MB (Atari 800XL).  I had similar issues with XEGS however.  Has anyone else experienced this?

 

 

2 hours ago, 8bitguy1 said:

The slot to slot copy feature doesn't work for me.  At least for external TNFS servers.  I get the message that I should wait for the activity light to go out before pressing any key but it never goes out.  (I've let it sit for hours).  When I do hit a key anyway, there is an image with the correct name, but any attempt to boot it just goes to self-test.  My machine is a U1MB (Atari 800XL).  I had similar issues with XEGS however.  Has anyone else experienced this?

 

 

I will try to make another pass at the copy feature. I tried to get a minimal feature out because people were clamoring for it...

 

-Thom

 

A Mount All command has been added to the Fuji SIO device ($70), so that it can be much easier to implement mount all functionality in a boot loader. https://github.com/FujiNetWIFI/fujinet-platformio/wiki/SIO-Command-%24D7-Mount-All

 

 

  • Like 5

Trying to understand, why is there both ddevice 0x71-0x78 and a unit # 1-8?  If ddevice= 0x71 unit= 3 -- is that N3?  But what about ddevic 0x73  and dunit=1? Does unit take precedence?  The examples I looked at all use 0x71.

 

  OS.dcb.ddevic=0x71;
  OS.dcb.dunit=unit;

18 minutes ago, cathrynm said:

Trying to understand, why is there both ddevice 0x71-0x78 and a unit # 1-8?  If ddevice= 0x71 unit= 3 -- is that N3?  But what about ddevic 0x73  and dunit=1? Does unit take precedence?  The examples I looked at all use 0x71.

 

  OS.dcb.ddevic=0x71;
  OS.dcb.dunit=unit;

Heh, it's...an interesting little quirk of the SIO routines in the OS.

 

Basically unit is decremented by 1 when it enters SIOV.

 

So 0x71 with unit 1, is 0x71.

0x71 with unit 2 is 0x72

and so on.

 

Yeah, I have no idea why they did it this way, but that's how it rolls out.

If you set ddevic 0x73 and dunit=1 then you'll get a target device of 0x73.

 

-Thom

  • Like 1
10 hours ago, tschak909 said:

Heh, it's...an interesting little quirk of the SIO routines in the OS.

 

Basically unit is decremented by 1 when it enters SIOV.

 

So 0x71 with unit 1, is 0x71.

0x71 with unit 2 is 0x72

and so on.

 

Yeah, I have no idea why they did it this way, but that's how it rolls out.

If you set ddevic 0x73 and dunit=1 then you'll get a target device of 0x73.

 

-Thom

Oops, well, that's sillier than I thought.

 

There's not a lot out there on SIO. I google this, and most of the results are you, asking questions about it.

"WARNING: There is a bug in SIO that causes incorrect actions when the last byte of a buffer is in a memory address ending in $FF, such as 13FF, 42FF, etc."

 

I saw this in the Atari OS manual (which I have my original printed copy of). It says 'íncorrect actions' but I have no idea what that is.  Is irritating to avoid this.

 

Currently, the wildcard support is somewhat inefficient:

I need to do a directory read (and parse) for each filename. For CIO devices, this happens over CIO. For N:, this happens over SIO.

In Atari DOS, OSA/DOS XL, MyDOS, and many others, you can't open a CIO IOCB to a directory AND do a read and write at the same time.

Turns out, there are some intersecting buffers, and the three IOCBs will clobber each other, with bits of directory winding up in destination files, and bits of the source file winding up in the directory listing.

So I either have to, for CIO source devices:

(a) for each new file, re-read the directory from beginning to directory position, parse the result, call the copy. Uses least amount of memory, but it takes a bit longer with each file transferred.

(b) Read the whole directory into memory, parsing each entry and putting it into an array. For 127 filenames, this takes 1,651 bytes, so may be okay.

I will probably continue implementing (a) and debugging it, and then move it over to (b).

I haven't even dived into recursive copies yet, which, given that most DOSes don't even support subdirectories, I may just say fuck it and not bother.

  • Like 1

are you talking about the esp side of life in some instances and the Atari in others?

why would you leave the cio open?

https://www.atarimagazines.com/v3n8/AllAbout_IO.html

https://www.atariarchives.org/cfn/12/02/0010.php

https://www.atariarchives.org/mmm/iocbs.php

http://www.atarimania.com/faq-atari-400-800-xl-xe-how-is-the-input-output-subsystem-of-the-atari-os-organized_73.html

 

some DOS have issues with note and point depending on version as well, since it's their fault and not yours code like it does, let the DOS be fixed, you don't need to do end runs around them but using the fujinet to address some issues as a middle man might work,- or might drive you insane.

 

You might consider teaming up with some DOS specializing coding guru's, reach out for some help. The idea of your own buffer or array might have some possibilities, not sure about all the different DOS variants though. Sometimes I wonder if #Fujinet needs a DOS type flag it can set then choose an entirely different method or subprogram to deal with some issues. Would work for most cases and Sparta would have it swapping out the helper monsters when you access all the different types / structures out there with it's

Not one big monster, but a bunch of little beasts to do your grunt work called when needed and talking to each other. passing iocb data to each other and the cio utility when in basic etc. Hopefully if any of this helps all of the readers maybe some ideas may come from it.

Edited by _The Doctor__

Spent the last week grinding through and debugging a very disturbing problem with N:,

writing data with the filesystem adapters. Reading is stable.

 

Writing seems to introduce glitches into the output.

 

This doesn't happen if I use the TCP and UDP adapters, only when I use those derived from the FS class, e.g. HTTP and TNFS. To repeat, TCP and UDP read and write stably, and I can verify with over a thousand test passes against ordered test data, that this is the case.

 

(My test involves a file of 23,040 32-bit long numbers in sequence, little-endian, to a file, and then copying that file using NCOPY to the Atari, afterwards reading the file back with a companion test program that reads each number and compares with a counted loop to find errors. This works well also for a visual inspection as two 32-bit numbers fit nicely on a hex dump display, and you can quickly see glitches in the output data.)

 

Over the last two days, I made a parallel TNFS2 class that was patterned after the TCP class as much as possible, only to find the problem still exists with the re-implemented class.

 

I am genuinely confused, and am continuing to try and investigate where this transmit buffer corruption is coming from.

 

-Thom

  • Like 1

#Atari8bit #FujiNet FNC-TOOLS now updated to include wildcard support for NCOPY, as well as fixing FLS. DOS directory and Ultimate1MB ROMs also updated. Everything is on TNFS atari-apps.irata.online in /. 

WIN_20210322_21_18_23_Pro.thumb.jpg.16dd8156c8e10188dd6e700314d17533.jpg

 

-Thom

 

  • Like 7
On 3/25/2021 at 8:24 AM, tschak909 said:

Spent the last week grinding through and debugging a very disturbing problem with N:,

writing data with the filesystem adapters. Reading is stable.

 

Writing seems to introduce glitches into the output.

 

This doesn't happen if I use the TCP and UDP adapters, only when I use those derived from the FS class, e.g. HTTP and TNFS. To repeat, TCP and UDP read and write stably, and I can verify with over a thousand test passes against ordered test data, that this is the case.

 

(My test involves a file of 23,040 32-bit long numbers in sequence, little-endian, to a file, and then copying that file using NCOPY to the Atari, afterwards reading the file back with a companion test program that reads each number and compares with a counted loop to find errors. This works well also for a visual inspection as two 32-bit numbers fit nicely on a hex dump display, and you can quickly see glitches in the output data.)

 

Over the last two days, I made a parallel TNFS2 class that was patterned after the TCP class as much as possible, only to find the problem still exists with the re-implemented class.

 

I am genuinely confused, and am continuing to try and investigate where this transmit buffer corruption is coming from.

 

-Thom

That's pretty weird. And you see the same issue with http?  HTTP we know works, I don't know how robust tnfs is, you're sure it's not a bug in tnfs server then. 

3 hours ago, cathrynm said:

That's pretty weird. And you see the same issue with http?  HTTP we know works, I don't know how robust tnfs is, you're sure it's not a bug in tnfs server then. 

An error in my test procedure contaminated the HTTP test. It's okay.

 

The error with TNFS has been traced to the fact that the TNFS_MAX_PAYLOAD size was set to 532 bytes, which, while tnfsd does specify this is the max payload size, this is much too big for practical UDP usage, because it may (And probably will) fragment.

 

In this case, it was leaking some other bit of memory into the transmit buffer.

 

Resetting the TNFS_MAX_PAYLOAD constant to 512 fixed the issue.

 

-Thom

  • Like 1

#FujiNet #Atari8bit Now that libssh2 is embedded into the code and is compiling, I have added a ticket to add an SSH protocol adapter, if anyone wants to try their hand at it.

https://github.com/FujiNetWIFI/fujinet-platformio/issues/439

 

I especially want someone else to do this, so that they can point out to me how incredibly brain damaged my approach is, and hopefully we can make it better.

  • Like 2
  • Haha 2

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.

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...