Jump to content

tschak909

Members
  • Content Count

    3,722
  • Joined

  • Last visited

  • Days Won

    5

tschak909 last won the day on October 23

tschak909 had the most liked content!

Community Reputation

3,592 Excellent

2 Followers

About tschak909

  • Rank
    River Patroller
  • Birthday 10/24/1978

Contact / Social Media

Profile Information

  • Location
    USA
  • Interests
    IRATA.ONLINE system operator. Software Development, I also have extensive production experience on various artistic media. Also roast my own coffee.

Recent Profile Visitors

21,670 profile views
  1. The next test will focus on UDP sending/receiving. The tests are becoming more and more complex, so turn-around times are increasing... -Thom
  2. #FujiNet Test #20 - Diskulator now has caching, which is drastically improving the performance of reading disk images across Internet hauls, by buffering an entire track, before returning the result over SIO, like a Happy drive.
  3. I have tested the TI PLATO terminal, it implements an earlier version of CDC's ASCII protocol, that is no longer compatible. It will not work with any of the current CYBIS installations correctly, which is another reason I ported PLATOTERM to the TI99. -Thom
  4. I will reiterate: Atari has had flattening growth in their post-Infogrames licensing model of trumping out their brand at $500,000 a pop, for years. They wanted to dump their penny stock. They decided to generate hype over a console, to inflate interest enough for a bigger fish to buy them. They pull a favor someone from someone at Sonos to fabricate a case, they did not ask him to make something that was mass-producible. They contract a company to make controllers. Do not pay them. This later causes one of the production delays. They hit upon the idea to crowd-fund this thing, brought in a guy who had experience doing this multiple times, never-mind that he's a serial crowdscammer... Crowd-scammer leaves over non-payment, sues, they settle. They find an experienced system designer in Rob Wyatt/Tin Giant. Who DOES have shipping hardware under his belt. He works for 6 months, non-payment. Left in October. Law suit probably coming. Emergency shareholders meeting took place two days ago over the fact that nobody is signed on as a third party developer (and specifically how Unity is not supporting them as an explicit target), to basically beg for their support. There is no indication that the board that was shown even boots. There is no Atari branded operating system, they're saying "load your own." Two distinctly different system configurations. And they're delaying yet again. Atari never intended to actually go through with any of this, and are currently trying to find a way to do the least amount of effort as humanly possible while running away with as much of the crowd-funded money as humanly possible. -Thom
  5. I tried the latest #FujiNet test code on my daughter's XEGS. Works wonderfully.
  6. #FujiNet Test #19 was a resounding success. Here we have a fully functional boot loaded program that is stored on flash, providing the network configuration, and enough TNFS functionality to mount, read, and write Atari disks over the network!
  7. Yeah, I am doing a UDP connect and disconnect, which will use a passed back identifier that will be passed in the aux1. -Thom
  8. #FujiNet Test #19 focuses on how the Configuration program for #FujiNet may function. More functionality implemented, now it is mounting and displaying directories, with image mounting coming next. Stay tuned!
  9. Does anyone have any questions? Anything I can help answer? -Thom
  10. My initial thoughts were to keep TCP in the CIO handler, and leave UDP completely out of it, because every call in the CIO handler takes up resident RAM, whether you use it, or not. UDP's usage doesn't fit well into existing CIO methodologies, at all (and the nail in that coffin is that BASIC doesn't afford multi-byte CIO transfers at all.) -Thom
  11. I do have a question for those of you who would be programming in BASIC. But first, some background. The CIO handler will provide an N: device with easy to use ways to do TCP communication, because the idioms used match well enough. UDP communication will most likely have to be handled via SIO calls. Why? Because you're sending individual packets. Why would you use UDP instead of TCP? Because for certain applications, like games, it may make more sense to send fixed packets containing game state in one go. This is especially true if the amount of game state can fit into, say, 512 bytes. Using UDP also allows you to utilize more exotic methods of transmission, such as multicast, where you can send a packet once, and it will be received by all the recipients at once. This works best on a local network, as even today, some 35 years after the initial specification of IP multicast, most routers will not route multicast traffic without some serious cajoling. But I will make the method available, nonetheless. It does mean, that you lose some aspects of TCP, such as ensuring that packets come in the right order (you have to handle sequencing yourself, even if it just means incrementing a response counter, putting that in the packet, and rejecting packets that have the wrong response #, it's simple enough.), but those usually are inconsequential. What would that look like, e.g. in BASIC? It looks like an SIO call. Basically, to do an SIO call, you POKE a bunch of parameters into a location in memory that is set aside by the OS to hold SIO parameters, the Device Control Block (DCB), and then you use a small USR routine that simply calls SIOV, which does what you ask in the DCB and returns back to BASIC. It looks something like this: 100 DIM BUF$(256) 110 DCB=768:REM LOCATION $0300 120 DDEVIC=112:REM $70 = NETWORK 121 DUNIT=1:REM UNIT (DDEVIC+UNIT-1) 130 DCOMND=ASC("U"):REM U = UDP WRITE 140 DSTATS=128:REM $80 = WRITE 150 ADDR=ADR(BUF$) 160 ADDRH=INT(ADDR/256) 170 ADDRL=ADDR-(ADDRH*256) 180 DBUFL=ADDRL:REM BUFFER LO 190 DBUFH=ADDRH:REM BUFFER HI 200 DTIMLO=15:REM 15 SEC TIMEOUT 210 DRESVD=0:REM RESERVED 220 DBYTL=0:REM # OF BYTES LO 230 DBYTH=1:REM # OF BYTES HI (256) 240 AUX1=0:REM AUX1=0 250 AUX2=0:REM AUX2=0 300 REM POKE VALUES INTO DCB 310 POKE DCB,DDEVIC:POKE DCB+1,DUNIT:POK E DCB+2,DCOMND:POKE DCB+3,DSTATS:POKE DC B+4,DBUFL:POKE DCB+5,DBUFH 320 POKE DCB+6,DTIMLO:POKE DCB+7,DRESVD: POKE DCB+8,DBYTL:POKE DCB+9,DBYTH:POKE D CB+10,DAUX1:POKE DCB+11,DAUX2 330 REM DO THE ACTUAL CIO CALL 340 X=USR(ADR("h Yd`")):REM JSR SIOV 350 RETURN Line 340 looks like this: And the read would be similar, only the command and DSTATS are different (command would be 'V' and the dstats would be 64, aka $40) So my question is: Should this just be distributed as an example subroutine for sending commands directly to #FujiNet? or should we try to come up with a better way to do UDP comms? -Thom
  12. Again, I must remind everyone, that I am writing tons of test programs, this is one of them, to quickly sketch out what will actually be needed. I will have to re-implement all of this when we actually get to production firmware. @jeffpiep is doing excellent work in this area, taking the tests I've written and making nice classes out of them (e.g. making generalized stream classes for TNFS, so they can be used interchangeably with the SPIFFS filesystem objects), and working towards making it more atomic so that multiple instances of the same device can be cleanly handled. My goal with the current incarnation of "Diskulator" is to sketch out what the initial experience should be, and to figure out what SIO and TNFS commands will be needed to implement that experience. This is the largest test program yet, because it's literally melding together "diskulator" and a configuration wizard. and I had to take a few side-lines to learn: How to get CC65 to output a boot loadable disk image/program. How to coax a "selection bar" out of some Player/Missile Graphics How to use VS.Code and PlatformIO, as the release version of the software will be written in it. Some things to work out in diskulator: Scrolling the list of mountable disks from TNFS server, versus amount of network traffic generated for grabbing entries. This is harder than it sounds because of the limited amount of RAM in the ESP8266 (80K, of which, half of it is automatically used to hold Arduino internal state), I can't realistically just cache it all in memory, either in the Atari or in the ESP. Imagine waiting for 2000 ATRs to come across the server other bits that I don't have on my mind atm because I am hyperfocused. Also, this is a call to everyone, if you have an idea, and can help implement it, please jump in. This project is mushrooming like crazy, and all sorts of functionality needs an implementation that can be used at the very least as a proof of concept. -Thom
  13. #FujiNet will have a default disk image in its flash, intended to set up the device; to provide all sorts of configuration functions.
  14. This project is wide open for collaboration. If you have a better way to deal with SIO processing, then please, take a whack at it, the only thing I ask is that you share your findings. -Thom
×
×
  • Create New...