tschak909 Posted November 12, 2019 Share Posted November 12, 2019 (edited) Does anyone have a problem with me reserving $70-$7F for #AtariWifi? These will be used for the N: devices for networking functions (being able to open up to 7 CIO connections + the control channel) @phaeron ??? -Thom Edited November 12, 2019 by tschak909 Quote Link to comment Share on other sites More sharing options...
Rybags Posted November 12, 2019 Share Posted November 12, 2019 Unknown if they're in use. SIO2SD and probably SIO2PC derivatives do use some extra special commands for things like listing images on SD cards, mounting etc - usually front-ended by an Atari based program. In theory you could get by with using 1 or 2 custom SIO command values and just include the actual command as Aux or part of the data frame. Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted November 12, 2019 Share Posted November 12, 2019 I thought he was referring to the device ID as found in DDEVIC? Quote Link to comment Share on other sites More sharing options...
tschak909 Posted November 12, 2019 Author Share Posted November 12, 2019 (edited) Yeah, that's what I am referring to, for a new set of devices. one of them being a special control channel for adjusting adapter settings, mounting disk images, etc. To be clear, the N: devices are for TCP or UDP communication, and this would allow up to say 6 or 7 simultaneous connections with CIO. (although to be safe, would just say 4.) -Thom Edited November 12, 2019 by tschak909 Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted November 12, 2019 Share Posted November 12, 2019 (edited) Deleted (had brain freeze). Edited November 12, 2019 by flashjazzcat Quote Link to comment Share on other sites More sharing options...
E474 Posted November 14, 2019 Share Posted November 14, 2019 Hi, Don't these values clash with the Sdrive device ids? They're listed here: http://raster.infos.cz/atari/hw/sdrive/sdriveen.htm and in the attached document - unless you mean a different set of #$70+? Hope this helps! SDrive_siocommands.pdf Quote Link to comment Share on other sites More sharing options...
tschak909 Posted November 14, 2019 Author Share Posted November 14, 2019 Why in the hell does SDRIVE use those IDs? #$%(@#$%(# grrrr. -Thom Quote Link to comment Share on other sites More sharing options...
baktra Posted November 14, 2019 Share Posted November 14, 2019 On 11/12/2019 at 11:19 PM, Rybags said: Unknown if they're in use. SIO2SD and probably SIO2PC derivatives do use some extra special commands for things like listing images on SD cards, mounting etc - usually front-ended by an Atari based program. In theory you could get by with using 1 or 2 custom SIO command values and just include the actual command as Aux or part of the data frame. That sounds like the most reasonable advice. If possible, do not flood the limited SIO addressing/command space if not absolutely necessary. Quote Link to comment Share on other sites More sharing options...
Rybags Posted November 14, 2019 Share Posted November 14, 2019 I guess an advantage to using a second device # for what's essentially an emulated disk drive is that it might make programatically determining if you're dealing with a real or emulated drive a bit easier. Plus stop the annoying noseblow sound when unknown commands get the NAK from a real peripheral. Quote Link to comment Share on other sites More sharing options...
HiassofT Posted November 14, 2019 Share Posted November 14, 2019 A quick grep through the Altirra source code turned up that SIO2SD uses device id $72 as well. These additional device IDs are mainly used for device configuration (eg selecting drive mapping, navigating through the directory tree on the SD card, setting highspeed baudrate etc) and using a fixed device ID for that (compared to adding commands to eg the $3x disk drives) makes a lot of sense: this device ID will always be present on the SIO bus if a SIO2SD, SDrive, ... is connected (even if no actual drives are currently enabled) and there's no chance the additional commands added to eg $3x disk drives could interfere with existing software trying to check for or use some proprietary (Happy, Speedy, ...) command and/or highspeed SIO protocol (XF551 and Happy Warp are inidicated by bits 7 and 5 set in the command). So the command space of disk drives is already quite cluttered and it's not easy to find an empty spot there. I'm pretty sure several other device IDs will be used by existing hardware (or PBI devices or SIO emulators). For example I use $61 ("a") in AtariSIO for the remote control interface - it can be disabled though if it causes problems. Ah and PCLink uses $6F. IIRC IDEPlus and SIDE U1MB BIOS use $20, $Bx and $A0. @flashjazzcat should know more about that. Not sure if some devices use the other lower number IDs ($00-$2F) plus you can also look into using some of the higher ones ($80-$9F, $C0-$FF). so long, Hias 2 Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted November 14, 2019 Share Posted November 14, 2019 10 minutes ago, HiassofT said: IIRC IDEPlus and SIDE U1MB BIOS use $20, $Bx and $A0. Correct. $20 = physical disk, and bit 7 set = XDCB (32-bit sector and buffer addressing, etc), so $Bx for logical volume access with XDCB, and $A0 for physcial disk with XDCB. 1 Quote Link to comment Share on other sites More sharing options...
tschak909 Posted November 14, 2019 Author Share Posted November 14, 2019 so can we get a table of device IDs that can be agreed upon? I need a block of 6 or 7 device ids that I can use for the N: devices. -Thom Quote Link to comment Share on other sites More sharing options...
xxl Posted November 14, 2019 Share Posted November 14, 2019 SIO ID: $69 - WiFiPrime $6A - SIOCart Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted November 14, 2019 Share Posted November 14, 2019 1 hour ago, tschak909 said: so can we get a table of device IDs that can be agreed upon? I need a block of 6 or 7 device ids that I can use for the N: devices If it turns out to be problematic to reserve eight IDs, would implementing a single ID and using an alternative extended command frame (along the lines of the PCLink protocol, which employs one ID but supports fifteen unit numbers) be possible? 1 Quote Link to comment Share on other sites More sharing options...
tschak909 Posted November 14, 2019 Author Share Posted November 14, 2019 Can I safely use the $C0-$CF range? These are going to map to N: CIO devices for doing TCP/UDP comms (as well as doing control to mount "D:" devices etc) I'm going to try. -Thom Quote Link to comment Share on other sites More sharing options...
tschak909 Posted November 14, 2019 Author Share Posted November 14, 2019 also, with regards to the SIOV calls, is DUNIT simply added to the DDEVIC? Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted November 14, 2019 Share Posted November 14, 2019 43 minutes ago, tschak909 said: is DUNIT simply added to the DDEVIC? Less one, eg: lda ddevic clc adc dunit adc #$ff sta cdevic Quote Link to comment Share on other sites More sharing options...
tschak909 Posted November 14, 2019 Author Share Posted November 14, 2019 the funny things that pop up in implementation details. -Thom Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted November 14, 2019 Share Posted November 14, 2019 (edited) Regarding the IDs, if I were you I'd just pick a range which appears vacant at the moment and change it later on if someone pipes up after the event. The entire ID range can be encompassed in a single equate in the source code. That's assuming you don't want to or can't use the PCLink method of employing a secondary command frame and just passing a fixed device ID and unit number in one of the auxiliary bytes in the four byte frame. I suppose there's a little more overhead doing it that way, but on the other hand you gain a lot of flexibility and you only need to reserve one device ID. Edited November 14, 2019 by flashjazzcat Quote Link to comment Share on other sites More sharing options...
tschak909 Posted November 14, 2019 Author Share Posted November 14, 2019 yeah, noted. This device is still taking shape (albeit very quickly, it just booted jumpman off of the internet, yesterday), so am still getting a feel for what will be feasible. -Thom Quote Link to comment Share on other sites More sharing options...
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
Recommended Posts
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.