Jump to content

ol.sc

Members
  • Posts

    122
  • Joined

  • Last visited

Profile Information

  • Gender
    Male

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

ol.sc's Achievements

Chopper Commander

Chopper Commander (4/9)

121

Reputation

  1. If you already have such a cartridge then using http://frogfind.com/ may give you some fun back in using it.
  2. Hi, I presume that most of you aren't aware that Berkeley Softworks ported GEOS also to the Apple II. However, given CBM GEOS programs never run on the Apple II as-is. There's way less information available about Apple GEOS than there's about CBM GEOS. Especially there was never a geoProgrammer published for the Apple II. However, I invested quite some effort in getting enough information (see https://github.com/cc65/wiki/wiki/Apple-GEOS-Symbol-Table and https://github.com/cc65/wiki/wiki/Apple-GEOS-Zeropage-Usage) to allow to port Maciej's GEOSLib (https://cc65.github.io/doc/geos.html) to the Apple II. There are fore sure (many ?) things not working as expected, but I'm not actively working on the project anymore. It was mentioned in this thread that GOES contains its own filesystem that "only" requires track/sector I/O routines. However, that doesn't mean that GEOS disks are totally incompatible with "usual" disks, rather the opposite. I don't know about CBM GEOS, but Apple GEOS uses the Apple ProDOS 8 "kernel" for disk I/O. And it for sure doesn't only use the track/sector I/O routines from ProDOS. Rather it uses the file access routines from ProDOS 8. However, in a way very simliar to CBM GEOS, there are subtile incompatibilities between Apple GEOS disks and usual ProDOS disks (see https://github.com/cc65/wiki/wiki/Apple-GEOS-File-Formats). So a typical GEOS user both on the CBM and the Apple II expects to be at least able to add some files to a GEOS disk from outside of GEOS and use them later in GEOS. Note: I've toyed many years with the idea to port https://github.com/mist64/geos to the Atari, turning cc65 + GEOSLib into a GUI development toolchain targeting all three major 6502 desktop systems. However, I would have never believed that it would be possible to run (many/most) CBM GEOS programs on the Atari! Regards, Oliver
  3. I'm not very well informed about the state of the hardware. As far as I know there's at least one prototype board, but there were issues with programming the CPLD. I guess that doesn't qualify for 99,9% done
  4. I'm into software, not hardware. That's the reason why I re-posted after two years in this thread to check if someone who's into hardware is interested in building it.
  5. > I realize I'm just arguing to argue so I'm sorry and done. After all so do I. And what's even more important: You are arguing for something that's alive and kicking - and is a great success, while I argue for something that will almost certainly never come to life. So I have for sure more reason to be sorry than you are!
  6. I presume to have lost many in the discussion. I try to summarize my perspective... I see basically these viable options: 1. A lightweight, rather stupid device like the W5100. It comes with fixed functionality, that nobody extends. 2. A midweight, rather intelligent device like the ESP32. It allows for extending its functionality to a rather small group for persons coordinating their work well. 3. A heavyweight, very intelligent device like the RPi. It allows for extending its functionality to all its users. 3.1 The connection to the device in 3.) is made by the device in 1.) This way 1.) serves two types of programs: - Programs not asking for intelligence. - Programs using 3.)
  7. I think we're having a misunderstanding here. I certainly don't doubt, that the FujINet team has created really great tools. However, the team produces the tools, the users consume the tools. I guess that's just fine for just about everyone. At least that's the Out-Of-The-Box functionality that Thom always insists on - and that I presume the FujiNet owners love. The only reason why I'm still writing here is, that it doesn't seem clear to everybody, that this is something pretty different to an open platform like a Linux SBC. And that's BTW the point why the way, multiplexing is done, is relevant: In a rather closed environment, the few programmers can come up with any type of custom multiplexing scheme. As long as everybody does everything right, everything works. But in a rather open environment, it's important that one bogus program doesn't bring down the communication channels of the other mature programs. And there the benefit of a built-in multiplexing scheme as provided by a TCP/IP stack becomes important.
  8. > And without an OS that supports multitasking I care because....? I must be missing something. I understand that the FujiNet provides CIO <Letter>: interfaces. Imagine this being done with a RPi, you could/would have one TCP port for each interface. So the interfaces would all work independently of each other. And you could still add you own stuff without disturbing what is already there. This has nothing to do at all with an OS or multitasking. It's about having several independent communication channels. It's like not having a single serial connection but as many serial connections as you like. On one connection you are maybe in the middle of accessing a file while on another connection you go out to some internet thingy. > No I am talking about using Perl on a PC (PI no different.) I think what you are missing is that the Fujinet provides an interface for communicating on TCP. --- It's not all tnfs and disk images. Not at all. I'm pretty sure I understand well what FujiNet provides. Do you run code your own code _ON_ the FujiNet? I understand the answer is 'no'. If FujiNet wouldn't be based on a MCU but on a Linux SBC, you could easily run your own code on it. > So I can write something in PERL, Python, (whatever) on the PI and it can listen on a TCP port and I can send/receive data to that port using the Fujinet and then this application/script I wrote can go off and do something cool on the internet and bring stuff back to the end user. There are lots of youtube videos and documentation and posts here about the N: handler, Fujinet with BASIC, etc. that you might want to read up on. Certainly you can. But if you consider the RPi an obligatory part of the picture, then you only use the FujiNet to connect to the RPi. And that very task is done as well with a W5100. > No. If you are talking about raw protocol support like TCP then definitely, no. The Fujinet project has brought forth interfaces (such as the CIO N: interface) that you can access from BASIC or whatever else on the Atari. The Fujinet folks have also provided Atari binaries and sample code to assist. I am sure this is what you are describing. Look into it... its super cool. Still a misunderstanding. You consume the interfaces provided by the FujiNet team (e.g. for connecting to a remote TCP port), but you don't create your own interfaces _ON_ the FujiNet, doing something totally different. Look at Thom's recent post - would you have been able to do that in the same way? With a MCU, it's always the few with programs ON the device and the many with programs USING the device. With a Linux SBC, everyone who likes has programs ON the device. Even if you learn to program ON the device. How would you share your code with others? The firmware you built? But does your firmware contain the programs from others doing same like you do? Does it contain recent updates from the FujiNet team? A Linux SBC comes with an OS and a file system. Everybody can bring his file/program and start his process. You can create a program and easily share it with others. They can add it to their SBC and run it alongside all the other programs. And the programs can all listen on their own TCP port to interact with Atari programs without disturbing each other. It's an open platform for everyone.
  9. > Who you calling ugly? lol! Okay, likely my fault. I'm no Atari guy. Reading https://github.com/HiassofT/highspeed-sio/blob/master/README.txt left me with the feeling that serial on the Atari isn't exactly straight forward. But I easily might missing the point. > ....this is starting to seem rather subjective... Then e.g. https://www.ibeyonde.com/raspberry-pi-serial-ports.html is subjective too, right? > Not sure why the "event" being tcp socket activity is different then listening to any other type of event. Serial hack vs TCP hack? With serial you only have one port. If you listen to it with your hack, then nothing else works anymore. With TCP you have built-in multiplexing with TCP ports. Your hack listening to port 1234 doesn't keep all the existing stuff on their ports from working. > I am using the netcat.xex application to kick at server ports written in perl to trigger stuff - not unlike what you are doing in Python I guess? I was talking about Python on the RPi, are you taking about Perl on the ESP32? > I just wonder if you have worked much with the FujiNet lately? Nope. However, as far as I understand it's still consuming what is provided by the FujiNet team. Adding something to FujiNet is still implementing it in C/C++, using the ESP32 SDK to create a new firmware and uploading the firmware to the ESP32. I see that doing way less individuals than I see logging into a RPi and writing some Python script.
  10. > Missing something here. Its a protocol. What makes it a custom protocol? The point I wanted to make is that if you connect to an existing endpoint via e.g. HTTP, it often is only available via SSL/TLS. But TNFS endpoints are set up explicitly for FujiNet, so it's easy to set them up without SSL/TLS - thus eliminating the need to support SSL/TLS.
  11. From my POV it boils down to the question if "stock" / "default" endpoints are that relevant / interesting in the first place: * A2Stream streams a custom format - so it requires custom endpoints anyhow. * FujiNet's TNFS is a custom protocol - so it requires custom endpoints anyhow. * http://68k.news/ and http://frogfind.com/ demostrate successfully that it is a viable - or even preferable - option to proxy "stock" / "default" endpoints. So one could argue, that pushing the functionality in question from the host to the device is a 'soon-dead end' too. Pushing it to the cloud could be considered the final solution. As a result, all the host needs, would be access to the cloud. And for that, the W5100 is enough. But if you don't like the cloud idea, you have to ask yourself, if the ESP32 really fits the bill. You easily end up wanting more: * Up to date / user updatable SSL/TLS client library with true SSL/TLS certificate store incl. revocation management etc. * Up to date / user updatable SSH client library to use your Atari as terminal to arbitrary Linux hosts. * Up to date / user updatable CUPS implementation to support arbitrary real printers. * ... From my POV, only a Linux SBC (think Raspberry Pi) truly fulfills the needs (as danwinslow mentioned). E.g. I have my W5100 usually directly connected to the Ethernet port of a RPi. The RPi works as NAT router for the W5100. This way I get: * Transparent WiFi access through the RPi WiFi module for all existing W5100 software * Transparent internet access though the RPi NAT router for all existing W5100 software * Direct access to all kinds of things I run on the RPi... You can as well approach the last point from a totally different perspective: Question: How do I connect a Raspberry Pi to the Atari? Fast? Answer: Using TCP/IP with a W5100. * As fast as it gets this side of DMA * No ugly "serial" hack on the Atari * No ugly "serial" hack on the RPi * Totally natural/implicit end-to-end flow control through TCP sliding window protocol * Totally natural/implicit multiplexing of streams through TCP ports * No need for DHCP/DNS, e.g. * RPI always has the IP address 10.10.10.10 * Atari always has the IP address 10.20.30.40 * So e.g. printer: TCP connect to 10.10.10.10:1234 * So e.g. modem: TCP connect to 10.10.10.10:1235 * Without the need for DHCP/DNS, a printer or modem "driver" just talking to the RPi through the W5100 using TCP is less than 256 bytes. And again, because of the NAT router on the RPi, existing W5100 internet software, not knowing about / not interested in the RPi, works as-is in parallel to "new" software just using the W5100 to access the RPi. And finally: Quickly hacking a Python script on the RPi (of course using the 6502-machine as terminal) that listens on some TCP socket for a request from the 6502-machine and does something cool on the internet is really bringing back the end user empowerment we had back then with BASIC. The combo of BASIC on the 6502-machine + Python on the RPi brings you back from just consuming stuff to making stuff. That's where the fun is - at least to me ?
  12. Thanks for the kind feedback ? With a W5100-based PBI device being available I could imagine very well to implement it. According to my Atari knowledge, it should be (much) easier to implement and/or sound (much) better than A2Streasm.
  13. Full ACK! That's exactly the very reason why I personally consider the W5100 as the right thing. It can be used as Ethernet controller just like the CS8900A of the Dragon Cart. Therefore all my Dragon Cart software will work with the W5100. Optionally, its TCP/IP stack can be used. This allows for stuff shown in the two YouTube videos below. But still, it's an Atari network solution, not an ESP32 (or other MCU) network solution with an Atari attached to it.
  14. Hi, Glenn (@a2retro) confirmed to me the other day that he's not coming back to the Dracarys project for good ? I understand very well, that because of the FujiNet and because of the lack of WiFi and because of the lack of firmware and because <you name it> the general perception is that there's no demand for the Dracarys (anymore)! If however, for any reason whatsoever, there should be somebody willing to bring the Dracarys (or any simliar W5100-based project) to life nevertheless, he can get the Eagle/Fusion files from Glenn. Additionally I'd like to mention that https://github.com/cc65/ip65/wiki/Date65 https://github.com/cc65/ip65/wiki/Telnet65 https://github.com/cc65/ip65/wiki/Tweet65 https://github.com/cc65/ip65/wiki/Wget65 https://github.com/oliverschmidt/contiki/wiki/ATARI do work / will work with a W5100-based PBI device. The assumptions made by that software as-is regarding the interface to a W5100-based PBI device can be seen at https://github.com/oliverschmidt/contiki/blob/main/cpu/6502/net/w5100.S#L162-L204 Again, from my POV, there's no need whatsoever for a discussion why there's no need/demand/use for such a project (anymore). But it's of course not up to me to keep someone from saying what he likes. Regards, Oliver
  15. I'm on the software side of things. The only thing I can say is that the (obviously 100% untested) drivers are available since May 2019: https://github.com/oliverschmidt/contiki/commit/c2a71ee62b3349141a94e72da685d6b839574259 https://github.com/cc65/ip65/commit/d970d4ae11bfa7618594ef47f1f6cbba640dad1e
×
×
  • Create New...