atarionline.pl #FujiNet - karta sieciowa SIO dla Atari 8-Bit. - Forum Atarum

Jeśli chcesz wziąć udział w dyskusjach na forum - zaloguj się. Jeżeli nie masz loginu - poproś o członkostwo.

  • :
  • :

Vanilla 1.1.4 jest produktem Lussumo. Więcej informacji: Dokumentacja, Forum.

8. Sprzęt / Hardware  »   #FujiNet - karta sieciowa SIO dla Atari 8-Bit.

W dół

Od 51 do 100 z 726

  1. <
  2. 1
  3. 2
  4. 3
  5. 4
  6. 5
  7. 6
  8. 7
  9. 8
  10. ...
  11. 15
  12. >
  1.  
    The HTTP protocol for the N: device is starting to breathe...
  2.  
    #FujiNet #Atari8bit #TLS A little status report:

    Some of you may have noticed that I've hinted at TLS (encrypted) support. Yes, the ESP does TLS encryption, just fine. It works. If you provide either a certificate fingerprint to check against, OR the appropriate root certificate.

    It can be made to "just work" once a certificate store has been written, the appropriate root certificates injected into it, and code which returns the correct certificate given a fingerprint.

    I will work on this, when the other parts of the N: device are more complete. If someone wants to take a whack at implementing a TLS certificate store, the certificates can be found here:

    ->link<-
    • 3:
       
      CommentAuthorKaz
    • CommentTime16 Apr 2020
     
    No panowie, ktoś chciałby wspomoć Thomasa?
  4.  
    Just so everybody knows, I am compulsively public about this project, and I put out feelers for help to get people interested, because all too often in past projects I've had people jump in and say, "how can I help?" :)

    -Thom
  5.  
    On the N: device, With aux2 set at open, this specifies that EOL translation should be done for input and output. There are currently four values:

    * 0 = No Translation
    * 1 = Translate CR (0x0D) to EOL (0x9B) (Macintosh style line endings)
    * 2 = Translate LF (0x0D) to EOL (0x9B) (UNIX style line endings)
    * 3 = Translate CR/LF (0x0D 0x0A) to EOL (0x9B) (PC/Windows style line endings, also default Telnet NVT behavior)

    This works across all protocols, and is demonstrated here by doing http GET fetch of an nginx title page:


    Currently working on getting headers to work. From the user's perspective, this will be a multi-step process, where for e.g. a GET, you:

    * Open the connection
    * Tell the N: device you want to give it a list of headers to fetch, via an XIO
    * PRINT each header you want, one at a time,
    * Tell the N: device you are done giving it a list of headers, via an XIO.
    * Get a STATUS, which actually does the request
    * Tell thE N: device you want to get the headers, via an XIO
    * INPUT each header, one at a time.
    * Tell the N: device you're done with headers, via an XIO
    * GET or INPUT the data.
    * CLOSE

    Other verbs, like POST will work similarly. You OPEN, you set your headers you want to send, specify any you want to recieve, PRINT your post data, get a STATUS which will get you the # of bytes of the response, then GET your response and CLOSE.

    This is complex, yes, but it will allow for the whole of HTTP to be mapped cleanly onto the Atari I/O system.

    ---

    Na urządzeniu N:, Przy otwartym ustawieniu aux2, określa ono, że należy wykonać translację EOL dla wejścia i wyjścia. Obecnie są cztery wartości:

    * 0 = brak translacji
    * 1 = Przetłumaczyć CR (0x0D) na EOL (0x9B) (końcówki linii w stylu Macintosha)
    * 2 = Przetłumaczyć LF (0x0D) na EOL (0x9B) (końcówki linii w stylu UNIX)
    * 3 = Przełożenie CR/LF (0x0D 0x0A) na EOL (0x9B) (zakończenia linii w stylu PC/Windows, również domyślne zachowanie Telnet NVT)

    Działa to we wszystkich protokołach i jest pokazane tutaj poprzez wykonanie http GET fetch strony tytułowej nginx:


    Obecnie pracujemy nad doprowadzeniem nagłówków do pracy. Z punktu widzenia użytkownika będzie to proces wieloetapowy, w którym np. dla GET-u będziesz mógł pracować:

    * Otwórz połączenie
    * Powiedz N: urządzenie, które chcesz dać mu listę nagłówków do pobrania, przez XIO
    * Nadrukuj każdy nagłówek, który chcesz, jeden na raz,
    * Powiedz N: urządzenie, które skończyło, dając mu listę nagłówków, poprzez XIO.
    * Get a STATUS, which actually does the request
    * Tell thE N: device you want to get the headers, via an XIO
    * INPUT each header, one at a time.
    * Tell the N: device you're done with headers, via an XIO
    * GET or INPUT the data.
    * CLOSE

    Inne czasowniki, jak POST, będą działać podobnie. Otwierasz, ustawiasz nagłówki, które chcesz wysłać, określasz, co chcesz otrzymać, DRUKUJ dane postu, otrzymujesz STATUS, który da ci # bajtów odpowiedzi, a następnie ZAMKNIJ.

    Jest to skomplikowane, tak, ale pozwoli na czyste odwzorowanie całego HTTP na systemie Atari I/O.
  6.  
    #Atari8bit #FujiNet Here I show how HTTP requests will work, for both headers and bodies, at the SIO level using the test programs I previously wrote. Notice the same programs I've been using all along scale to HTTP requests.

    ---

    #Atari8bit #FujiNet Tutaj pokazuję jak będą działać żądania HTTP, zarówno dla nagłówków jak i dla ciał, na poziomie SIO za pomocą programów testowych, które wcześniej napisałem. Zwróć uwagę na te same programy, których używałem w całej skali do żądań HTTP.

  7.  
    #atari8bit #FujiNET Here is #FujiNET doing something none of the other 8-bit Network Adapters can do :)


    (lest you thought we were exaggerating) ;)
  8.  
    #FujiNet #Atari8bit final video for the weekend, showing how HTTP POST requests work at the SIO level. I am using ->link<- as the testing harness.

  9.  
    #FujiNet #Atari8bit For the N: device, it is critical that we use interrupts to prevent constant polling of the #FujiNet for network status. The designers of SIO left us two pins for this purpose, and I show how we are using them in a version of #PLATOTERM.



    In other news, @Jamm has been a HUGE help with the firmware, he successfully got TYPE 1 SIO polling working, and thanks to @phaeron for the Altirra R: handler firmware, which works wonderfully.

    ---

    #FujiNet #Atari8bit Dla urządzenia N: krytyczne jest, aby używać przerwań, aby zapobiec ciągłemu sprawdzaniu stanu sieci przez #FujiNet. Projektanci SIO zostawili nam do tego celu dwa piny, a ja pokazuję jak ich używamy w wersji #PLATOTERM.

    W innych wiadomościach @Jamm okazał się bardzo pomocny przy tworzeniu firmware'u, z powodzeniem przeprowadził ankietę TYPE 1 SIO, a także dzięki @phaeron dla Altirra R: handler firmware, który działa cudownie.

    Przetłumaczono z www.DeepL.com/Translator (wersja darmowa)
  10.  
    #FujiNet #Atari8bit. Now that the SIO layer for the N: device is mostly stable, I have started on the third re-write of the CIO handler, shown here loading a BASIC program over HTTP and doing TCP input from BASIC.

  11.  
    #Atari8bit #FujiNet I finally folded in RFC compliant URL handling into network.cpp and the protocols, which allows for e.g. URL prefixing to work, so that DOS can handle Network URLs!

  12.  
    #Atari8bit #FujiNet The N: device will be a complete CIO device exposing all of the modern network protocols to the Atari and its operating system. Shown here is the ability to copy files to and from HTTP and TCP connections in various DOSes.

  13.  
    I sigh in slight frustration...but I will try to be as articulate as I can be...

    This project isn't being developed like most projects, where everything is happening in secret, and there is the big reveal. That can't work on this project, and I refuse to do it that way.

    In order for this project to succeed, it is important that early adopters who can build from the schematics we release, build devices for those who can help write the software, either on the Atari side, or on the ESP side.

    There are approximately 4 of us actively coding on the firmware, and we have a LOT of work left to do, and we could use the help of many talented people that I KNOW exist in this club, people who could make short work of many tasks that are harder for myself and my team because we are having to re-discover knowledge that is locked in the heads of many AtariOnline.pl members.

    The whole point of me making all these videos and releasing all this information is so that people will come forward, and the more people do this, the quicker we can get this device into a polished state.

    This project will exist because we as a community want it to exist. that's why it is open, that's why anyone so inclined can build it, that's why anyone can hack on the firmware, because not all of the smart people in the world work within the FujiNet project, a good many of them are here in AtariOnline.pl, and we need you.

    -Thom

    ---

    Wzdycham w lekkiej frustracji... ale postaram się być tak wyrazisty, jak tylko potrafię...

    Ten projekt nie jest rozwijany jak większość projektów, gdzie wszystko dzieje się w tajemnicy, a tam jest wielkie odkrycie. To nie może działać w tym projekcie, a ja odmawiam robienia tego w ten sposób.

    Aby ten projekt odniósł sukces, ważne jest, aby wczesni adepci, którzy mogą budować na podstawie publikowanych przez nas schematów, budowali urządzenia dla tych, którzy mogą pomóc napisać oprogramowanie, albo po stronie Atari, albo po stronie ESP.

    Jest nas około 4 osób, które aktywnie kodują firmware i mamy jeszcze sporo do zrobienia, i moglibyśmy skorzystać z pomocy wielu utalentowanych ludzi, o których wiem, że istnieją w tym klubie, ludzi, którzy mogliby wykonać krótką pracę z wielu zadań, które są trudniejsze dla mnie i mojego zespołu, ponieważ musimy na nowo odkryć wiedzę, która jest zamknięta w głowach wielu członków AtariOnline.pl.

    Cały sens tego, że robię te wszystkie filmy i uwalniam wszystkie te informacje jest taki, że ludzie będą się zgłaszać, a im więcej ludzi będzie to robić, tym szybciej uda nam się doprowadzić to urządzenie do stanu wypolerowanego.

    Ten projekt będzie istniał, ponieważ my jako społeczność chcemy, aby istniał. dlatego jest otwarty, dlatego każdy tak chętny może go zbudować, dlatego każdy może włamać się do firmware'u, ponieważ nie wszyscy inteligentni ludzie na świecie pracują w ramach projektu FujiNet, wielu z nich jest tutaj w AtariOnline.pl, a my cię potrzebujemy.

    -Thom
  14.  
    #Atari8Bit #FujiNet The N: urządzenie pozwala na łatwe tworzenie gier, które wysyłają ruch sieciowy za pomocą protokołu UDP, używając jedynie standardowych poleceń Atari I/O.

    • 15:
       
      CommentAuthorKaz
    • CommentTime29 Apr 2020
     
    Przyłączam się do apelu Thomasa - może ktoś pomoże chłopakom w pracach nad softem? Ewentualnie - może ktoś powie, co stoi na przeszkodzie w tej pomocy - to spróbujemy przedyskutować co można z tym zrobić.
  16.  
    For anyone who can answer.

    I have a CIO handler, that I've ported entirely to assembler (using AMAC), and it works. It loads just above the memlo that is imposed by DOS XL 2.30 with two double density disks ($2300), and with this, I am able to test and work through the rest of the CIO handler actions and debug without the weird side effects imposed by the C prototype version.

    In addition to the attached files here, I've uploaded my current work to the #FujiNet repo:

    ->link<-

    However, I've noticed a bit of an issue, What about DOS 2.0/2.5?

    Specifically,

    If I load at MEMLO (e.g. $1CFC or similar), then DUP will clobber my code. Normally, for devices like R: this is fine, because they're not being used by the DUP potentially for file operations (like copying or loading binary files), so DUP can swap back in via MEM.SAV, and things don't go awry. However...if I try to binary load using NDEV.COM in DOS 2.0, the DUP has overwritten my handler, and it doesn't know to swap the overwritten memory back in. whoops.

    The solution I had done, to continue debugging on DOS 2.0, was to make a version that assembled roughly at MEMHI, which puts it out of reach of the DUP, and then things work. But this isn't ideal. 

    Is there a better solution? or am I going to have to patch a version of DOS 2.0/2.5 to add the N: handler for those who want to use it? (roughly 975 bytes + 2K of buffers.)

    What's the right decision, here?

    -Thom

    ---

    Dla każdego, kto może odpowiedzieć.

    Mam CIO handlera, który został przeniesiony całkowicie do assemblera (przy użyciu AMAC) i to działa. Ładuje się on tuż nad memlo narzuconym przez DOS XL 2.30 z dwoma dyskami o podwójnej gęstości ($2300), a dzięki temu jestem w stanie przetestować i pracować przez resztę akcji CIO handlera i debugować bez dziwnych efektów ubocznych narzuconych przez wersję prototypową C.

    Oprócz załączonych tutaj plików, wgrałem swoją aktualną pracę do repo #FujiNet:

    ->link<-

    Zauważyłem jednak pewien problem, Co z DOS 2.0/2.5?

    Dokładnie,

    Jeśli załaduję w MEMLO (np. $1CFC lub podobne), to DUP zaklepuje mój kod. Normalnie, dla urządzeń takich jak R: to jest w porządku, ponieważ nie są one używane przez DUP potencjalnie do operacji na plikach (jak kopiowanie lub ładowanie plików binarnych), więc DUP może zamienić się z powrotem przez MEM.SAV, a rzeczy nie idą źle. Jednak... jeśli spróbuję załadować binarne pliki za pomocą NDEV.COM w DOS 2.0, DUP nadpisał mój handler i nie wie, jak zamienić nadpisaną pamięć z powrotem. whoops.

    Rozwiązaniem, które zrobiłem, aby kontynuować debugowanie na DOS 2.0, było stworzenie wersji, która została zmontowana mniej więcej w MEMHI, co czyni ją poza zasięgiem DUP, a potem wszystko działa. Ale to nie jest idealne rozwiązanie. 

    Czy istnieje lepsze rozwiązanie? Czy też będę musiał łatać wersję DOS 2.0/2.5, aby dodać N: handler dla tych, którzy chcą go używać? (około 975 bajtów + 2K buforów.)

    Jaka jest właściwa decyzja, tutaj?
  17.  
    #Atari8bit #FujiNet - Have spent the last week porting the CIO handler to assembler. A lot more to do, but wanted to put it through its paces through a few different DOSes, and programs to show its transparency. I just loaded a document into AtariWriter from HTTP :)
    • 18:
       
      CommentAuthorKaz
    • CommentTime4 May 2020
     
    Thomas, I think people can see that you're doing things great. So great that you don't need help. A paradox.
  19.  
    *shrug* ;)

    If someone could take the assembler routines I've laid out above and do a SpartaDOS X driver, that'd be great :)

    -Thom
  20.  
    ...

    Is there any documentation (besides what's e.g. in the MADS assembler and SDX tech manual) for making SDX kernel drivers? I need some context as to what to implement, and I've NEVER implemented any relocatable code, not to mention for the SDX format, so...really need some context.

    -Thom
    • 21:
       
      CommentAuthorKaz
    • CommentTime6 May 2020 zmieniony
     
    We are just talking about you and FujiNet project on zoom meeting :)

    Montezuma is presenting us this amazing device.
  22.  
    For anyone who wants to help, another task:

    I did a sort of quick port of the ATX code to a #FujiNet test, back in December 2019. I could not get it to work correctly.

    We've since moved to Platform.IO, and it would be great if the code (which was borrowed from SDrive-MAX), could be folded in to work, which would allow copy protected disks to work. (one thing to note, disks would need to be fetched and stored temporarily locally, so that timing is consistent)

    ->link<-
  23.  
    Spent the morning updating the Wiki documentation for programming.



    Now that the PLATFORM.IO API is firming up, I took out all of the earlier iterations of commands that were part of test programs, and am trying to get the documentation nice and current.

    ->link<-

    Updates to the SIO commands. I tried pasting the direct links, but they were chewed up.
    • 24:
       
      CommentAuthorKaz
    • CommentTime9 May 2020
     
    Thomas - great work! Expect an article on the main page about #FujiNet tomorrow evening! :)
  25.  
    @jeffpiep has been hard at work implementing the Atari 1025 emulation, and it looks absolutely fantastic! Here is test output from the T1025 program. ->link<-

    Here is some 1025 printer output from Atari Macro Assembler (AMAC) ->link<-

    In contrast here is the same output from the Atari 1027 letter quality printer emulation. ->link<-
  26.  
    @all: has anyone here worked on page level code relocation?

    I have a driver here in MADS, and it needs to be made relocatable, if anyone wants to take a crack at it?

    ->link<-
  27.  
    #FujiNet #Atari8bit Stały postęp debugowania CIO handlera, wypróbował ACTION! narzędzie do generowania przenaszalnych binariów, które działa z wyjątkiem SpartaDOS, więc teraz spróbuje metody Jona, ale dla potomności pokażę proces i wyniki, tutaj

  28.  
    #Atari8bit #FujiNet I didn't expect to record TWO videos today, but I decided to fix #FujiNet so XDOS could boot, and in the process, tested the N: driver, and it works very well, just need to fix a couple of bugs. Special Thanks to Stefan Dorndorf, who wrote XDOS.

  29.  
    #FujiNet #Atari8bit Continuing the march of adding protocols to the N: device, FTP starts to work, shown here showing directories, copying files, and running software!

  30.  
    This is a quick video showing file upload to FTP using the N: device courtesy of SpartaDOS. #ATARI8BIT #FujiNet

    • 31:
       
      CommentAuthorKaz
    • CommentTime19 May 2020
     
    Wow, we can upload files directly from Atari! Great!
  32.  
    And finally, from the Stupid Pet Tricks Dept. I copy a file from one FTP server, to another, through the Atari! #FujiNet #ATARI8BIT

    • 33:
       
      CommentAuthorbocianu
    • CommentTime20 May 2020 zmieniony
     
    Przy okazji napomknę, że ruszył pierwszy polski serwer FujiNet pod adresem fujinet.pl -> ->link<-
    Na razie jedyną odpaloną usługą jest testowy serwer TNFS, ale niebawem więcej.
    • 34:
       
      CommentAuthorKaz
    • CommentTime20 May 2020
     
    Bardzo dobra inicjatywa. Może przy okazji zamieścić tam jakieś linki na AtariAge, AOL - które prowadzą do artków i dyskusji, które się toczą w temacie FujiNet?
  35.  
    Yup, we are helping out bocianu, as much as we can, and I thank him immensely for planting a flag. :)

    Seriously, this puts a huge smile, on my face. :)

    The CIO handler is reaching functional completeness, there are lots of edge cases to work out...

    ...but the main thing I _really_ need help on is trying to reduce the memory footprint

    As of RIGHT NOW, the handler is:

    * roughly 80 bytes of initialization code...
    * roughly 980 bytes of handler code...
    * approximately 20 bytes of bss for variables.
    * and four 256 byte buffers, totalling 2048 bytes of bss.

    Making roughly a 3K footprint.

    I am not an assembler programmer, I've basically been guessing my way through it all, and trying to do the best job I can to make it work correctly, not worrying about making it small...

    so I KNOW that I am doing a lot of stupid things in the code.

    e.g.

    Can we get rid of the buffers and replace them with say, 4 32 character buffers that sit in the cassette buffer (page 3) or user area? (page 4), for CIO operations that don't explicitly provide a buffer in the IOCB?

    -Thom
  36.  
    #Atari8bit #FujiNet in this status report, I show how CHDIR is implemented at the CIO level, compatible not only with SpartaDOS, but other DOSes, relative paths in FTP, along with much nicer directory listing with wildcards!

  37.  
    Bonus video! #FujiNet #Atari8bit just as it says, navigating N: device to a spot on FTP with some ACTION! source code, and compiling/running it directly from the FTP site. :)

  38.  
    I Have been steadily refining the CHDIR functionality for the N: device, and its "wrapper" NCD.



    * NCD to .. causes one of two things to happen:

    (1) if the last element in the path is a folder, remove it, thereby going up a directory

    (2) if the last element in the path is a file, remove the file, and stay in its directory.



    * NCD to / causes the path to revert to the last full URL provided to the OPEN, that is, if you did an initial NCD to:



    FTP://FTP.PIGWA.NET/



    and you then NCD'd to stuff/collections



    your path would be:



    FTP://FTP.PIGWA.NET/stuff/collections/



    then NCD / will cause it to revert to



    FTP://FTP.PIGWA.NET/



    There is an interesting side-effect to this, if the last absolute URL provided to NCD has path elements in it, they are retained as the "initial path" so the / will not remove them.



    This has produced a usable pair of tools in NCD and NPWD that can comfortably move around networked filesystem directories, regardless of the underlying DOS, which simply does not care.



    Of course, since this isn't actually a "Change directory" call, but rather a "set prefix" call, you can chdir to a file directly and reference it as N:, e.g.



    NCD files/foo.com



    This allows you to use DOSes with broken copy commands (e.g. OS/A+ or DOS XL), or DOSes that explicitly penalize you for thinking that any device other than "D:" can possibly have a file system! (Looking at you, Atari DOS 3)



    Since the CIO call for CHDIR is 0x2C (aka XIO 44), this is compatible with SpartaDOS, and thus, you can use CWD under SpartaDOS 3.2, or CD under SpartaDOS X to accomplish exactly the same thing, with the exact same behavior.



    and of course, since this is an XIO call, it can be done from BASIC, without needing to load NCD.



    I have been spending hours now loading random files into BASIC, Action! MAC/65 etc from the ANTIC! archives, and having way too much fun doing so. ;)
    • 39:
       
      CommentAuthorbocianu
    • CommentTime22 May 2020 zmieniony
     
    U mnie też już pierwsze sukcesy.

    1. Poskładałem #FujiNeta i działa:



    2. Udało mi się dzisiaj po trzeciej w nocy połączyć z internetem z poziomu Mad-Pascala:



    gry sieciowe na Atari coraz bliżej ;)

    :D
  40.  
    Awesome! :)

    -Thom
    • 41: CommentAuthorxxl
    • CommentTime24 May 2020 zmieniony
     
    napisalem komunikatora (jeszcze na wifiprime) moze jak bedzie wiecej userow fujinet to uruchomie server komunikatora :-) chyba ze Fujinet ma juz cos takiego?
    • 42: CommentAuthorpin
    • CommentTime24 May 2020
     
    Jak tylko program uruchomi się na Atari, to czemu nie ;)
  43.  
    @xxl go for it.

    As for things I need help with:

    * SpartaDOS X kernel driver, I know there are at least a few people on here that could make easy work of this.

    * Squeezing the code for the N: device from 850 bytes to approximately 512 bytes, so it can fit under DOS 2.0's DUP. current code here: ->link<-
    • 44:
       
      CommentAuthorpirx
    • CommentTime25 May 2020 zmieniony
     
    squeezing the code will not be easy without thorough understanding of the handler, for a quickie I can see only
    LDY #EOF
    LDA #EOF

    that can be shaved by 1 byte.
    possibly maybe reuse some code from system?
  45.  
    Would it help if I made a video walking through and describing the handler?

    -Thom
    • 46: CommentAuthortebe
    • CommentTime25 May 2020
     
    used by xBootDos, FoxDos (not working with old OS 400/800)
    pentv	equ	$e486

    	ldx	#'N'
    	ldy	<handler_table
    	lda	>handler_table
    	jsr	pentv
    • 47:
       
      CommentAuthorbocianu
    • CommentTime25 May 2020 zmieniony
     
    napisalem komunikatora (jeszcze na wifiprime) moze jak bedzie wiecej userow fujinet to uruchomie server komunikatora :-) chyba ze Fujinet ma juz cos takiego?


    Ja napisałem w weekend prostego komunikatora właśnie, jako wprawkę. Działa po UDP i jest prosty jak diabli, ale chyba działa :D
    Serwer jest napisany w node.js i źródła już są tutaj:

    ->link<-

    Źródła klienta udostępnie jak uporządkuje kod i przepiszę fragment odpowiedzialny za odbieranie danych na przerwaniu, bo na razie to klient polluje datagramy UDP.

    Mam tez ambitny plan napisania prostego klienta IRC. Jak ktoś zna protokół i chce połączyć siły, to chętnie!


    EDIT:

    Dorzuciłem źródła klienta: ->link<-
    • 48: CommentAuthorMADRAFi
    • CommentTime25 May 2020
     
    No troche pracy bedzie.
    Zdrodla klientow sa w C
    opis protokolu: ->link<-
  49.  
    So this works well. I had to put shoutbox onto a LiteDOS disk as DOS XL was conflicting with the program code, and took the opportunity to set up a server at atari-apps.irata.online:6502. If you load Comms/shoutbox.atr from atari-apps.irata.online TNFS, it will automatically connect.

  50.  
    @everyone starting to add the rest of the N* tools to fnc-tools.

    These are tools that talk to the SIO part of the N: device directly, and therefore do not require the NDEV to be resident, and will be provided as a form of "always compatible" that will work whenever ndev takes up too much RAM, or is incompatible with a chosen DOS.

    There will be:

    NDIR - directory listing
    NCOPY - copy files
    NDEL - Erase files
    NREN - Rename Files
    NLOAD - binary load from N:

    I have now checked in NDIR, and am proceeding to write the rest.

Od 51 do 100 z 726

  1. <
  2. 1
  3. 2
  4. 3
  5. 4
  6. 5
  7. 6
  8. 7
  9. 8
  10. ...
  11. 15
  12. >