Joey Z

On linux at least, you can set weird formats as you like. Lots of controllers don't support FM, but you can probably convince them to do 130k mode, by telling it you have a 40 track drive that is single sided, and to use 128 byte sectors, and to use 26 sectors per track. Of course, you need a *real* floppy controller for that, USB floppies aren't going to cut it. Also, I bet there's a way to disable the caching in linux, I just don't know it. Windows? you're screwed regardless, without writing new software, and possibly even a special driver to do the atari formats.

There are plenty of telnet based solutions which get by without implementing this fully, for the same reasons. ser2tcp and various terminal server standalone devices like the series of lantronix boxes all have this same issue. They can't know exactly what they're connected to. Somehow they found a way around this problem, most likely the solution was to not support the codes that don't make sense. In this case, you wouldn't do translations between specific terminal commands and NVT. You would, if possible, indicate that the NVT commands which have this issue are not supported. At this point, the far end (unfortunately) has to guess the terminal type by trying specific terminal commands. This is, AFAIK, how most hosts work anyway in the BBS world since not all clients are fully telnet compliant (fully compliant clients are rarer than you might expect I think). ser2tcp, I think, at least partially supports telnet, so this may be a good source to draw from. Additionally, again, altirra would be a good source to draw on for this behavior. Lastly, a professional solution which deals with the same issue are any of the lantronix terminal servers, so if you have one or can get your hands on one for a reasonable price, it may be beneficial to do some network sniffing to figure out how they get around this issue. That said, lantronix boxes aren't always cheap, so this isn't as reasonable if you don't already have one (I don't). It's also possible that someone on the forum can provide help here. It would even be reasonable to set up a telnet server, and ask someone on the forum to just connect with their lantronix box so you can capture the negotiation and some protocol in wireshark. Do you have a decent reference link on the NVT codes? I'd like to have a look myself at what exactly we're dealing with.

I only meant that the Atari software might try to send 0x00, so the Atari's R: handler must scan for this and replace it with 0x00 0x00. Otherwise, it would be interpreted as some other command on the RespeQt side. Nothing needs to be done on the RX side within the atari R: handler. And I think the right way to do things is to explicitely exit concurrent mode, but I'm not sure how the 850 behaves, or how software using it might behave. This is where the source for the firmware on the device might be useful, or otherwise looking at the code for the emulation in altirra is probably fairly accurate.

I'll let the guys who run BBSes decide that. That said, yes, it's no problem to leave it out for the moment and only add it later. Yes, you could either accept only one connection at a time or you can continue to accept connections, and just send some sort of 'busy' message. And that said, Altirra probably provides a decent model for how to do this. It's probably a safe bet that if you don't quite know how to implement something, it can be implemented similar to how altirra behaves. Differences will arise, of course, between an SIO device emulator and a full machine emulator as far as the lower level details go. Any R: handler should be OK to use, it's not really important as long as they provide the same functionality. And yes, support for NONE and SOFTWARE handshake will be difficult in an 850 styled device. There are ways to do software protocol though, like you said, that can effectively signal the emulated 850 to exit concurrent mode without hardware handshaking. Personally, I would pick an unlikely character, such as 0x00, to be a special character. Consider this character to be a sort of 'control code introducer.' You then follow it with a second byte which indicates what the emulated R: device should actually do. So, for example: 0x00 0x00 - literal character 0x00 should be sent by R: 0x00 0x01 - drop out of concurrent mode 0x00 0xnn - various other codes for doing useful things without dropping out of concurrent mode (maybe changing handshaking mode, for example, other R: commands etc.) The Atari has to scan the data going out for 0x00 and replace it properly. This is why I chose 0x00, because it is particularly easy to detect on the 6502, just load the value and check the zero flag. This is only a good idea if 0x00 is an infrequent character to be sent, which is probably a safe assumption to make. Otherwise it results in potentially a large performance penalty, sending two bytes for one byte of information.

If Altirra supports a raw disk image w/o any headers (ala xfd images I think) you can run Altirra in Wine on linux and use /dev/fd0 (or whatever your floppy drive is) as the 'image' file. No way to do it in windows without writing code.

Just so everyone knows, there is officially an IRC channel on the FreeNode IRC network called #RespeQt. There has been for a while. Currently I'm the only one there, come give me some company! If you don't have an IRC client, and don't feel like installing one, there's the FreeNode webchat client at https://webchat.freenode.net/ While you're there, you can visit ##atari as well, and I think there's a few other classic computing related channels in general. This is potentially a faster way to get support for RespeQt. My computer is generally logged in all day, but I'm not always at the keyboard.

Telnet server would indeed be useful. Think of it as when you have a modem that has auto answer. Incoming connection would send RING once to the Atari (assuming Hayes emulation) followed by the appropriate CONNECT message (which may or may not include a speed). This is useful for someone trying to run a BBS. For the 850 emulation, it'd emulate DCD going active at this point as well. There's probably not such a good way to emulate anything other than auto-answer. You'd have to connect on the telnet side, send up to some set number of RINGs to the Atari, and wait for ATA (or maybe this is the *one* command that doesn't need AT preceding it, I forget). If you go through the maximum rings, you drop the telnet connection with some appropriate error perhaps, maybe NO CARRIER or NO ANSWER. Also, I think there should be an API for a generic R:-attached device. That is, maybe one that is a modem emulator using telnet, one that just directs to a file (useful for early testing of the basic 850 functionality I think), and one that redirects to a serial port on the host machine.

The other half of the issue is that a given FTDI isn't even consistent byte to byte. I've looked with a scope and there's just jitter in general. I don't know if it's enough to break this, but it exists. Besides that, I still am having trouble seeing the point of emulating it really, there are other high speed options more suited to SIO2PC-USB which clearly don't have this problem. That's not to say I won't ever look into it, but it's not as high priority as the other things (like R: support) which I'd like to see in RespeQt.

I think the point is that he can't install the sockets. He was hoping the machine was socketed, because it's easy to tack on a few wires, but more difficult to remove a couple DIP chips without damaging the board

Oh, that's just because I forgot to update the text to beta2, it's actually beta2 though.

nope, that's something one of the other contributors must have changed it to for their own purposes. It should say R4-beta2 or something like that.

Have you double checked that it says r4 in the about box? I do think you're using git wrong. try: git clone https://github.com/jzatarski/RespeQt.git git checkout r4 Then see what you get. r4 where it is in the clone command will clone into a directory called r4, not get the r4 branch.

Hmm. Thinking about this more, do the FTDI chips allow asymmetric RX and TX speed? at least on linux, you can independently set ispeed and ospeed, if the hardware supports it. You could switch the ispeed to 38400 right away, but keep the ospeed at 19200 and send the ACK byte, and that would seemingly resolve this issue, but it's dependent on support for asymmetric speeds. I don't know if that's even possible in windows, for example. EDIT: quick test says this is not possible with the FTDI. too bad....

MEMLO of spartaDOS 1.1 is $2300, RCL loads at $2000. So that's not going to work. AspeCL loads at $3000. Given that SpartDOS 1.1 isn't supported by RCL, I'm going to stick with calling this not a bug.

maybe delete the whole thing and start from scratch, the files for the Qt serial port backend aren't in r4-beta2 here, and it doesn't show up on linux or windows.

can you post the problem-ATR as well as (for my convenience) a copy of SD1.1?

that is indeed strange, so it's (so far) not an issue with RCL.

You have high speed software on the atari that isn't supported, as evidenced by it sending commands with bit 7 set. Don't use that software on the atari with RespeQt and you won't have the issue. As far as I can tell, it otherwise works, it's just slow because the high speed atari software continually attempts switching to synchromesh which isn't supported by RespeQt, and can't easily be supported (see above post).

This is the post where the issues become apparent: http://atariage.com/forums/topic/241055-respeqt-r2-released/?p=3431721 Basically the atari expects the 'drive' (RespeQt in these cases) to switch from 19200 to 38400 about 300uS after the ACK is sent from RespeQt. The problem is that a USB serial chip doesn't have anywhere near the timing accuracy to pull that off. Switch speeds early, and we switch in the middle of ACK. Switch speeds late, and we missed data already. To make matters worse, tcdrain, the one call that could probably solve this, doesn't really have determinate timing between machines and SIO2PC. So the synchromesh style of high speed is just not doable.

Did RespeQt log anything meaningful in the log window? I suspect rcl doesn't work on Spartados 1.1 either, but isn't displaying a convenient error message for whatever reason. I think the 139 is probably coming from RCL itself rather than DOS, so it's running, it's just not working. .byte 'SpartaDOS v.2.5 or higher required!',155,0 I'll ping FJC, but keep in mind RCL is in beta, so these kind of issues are to be expected. The other possibility is that something is wrong with folder images, if you're using them. Are you trying RCL from an ATR or a folder image? If it's from a folder image, can you try copying to an ATR and then try?

I think there was a thread about various drive-specific turbo speed modes. We came to some conclusion that it's more difficult than it sounds IIRC. It might be buried somewhere in the general discussion thread however, so it might take me a minute to find it....

The project mostly does just build on windows, but setting up a compiler is *your* problem if you want to build it yourself. That's the only difference. On linux, the compiler is usually set up for you and that makes it easy, but on windows, you're pretty much on your own unfortunately. That's why I do the win32 builds and release them, because most windows users can't be expected to compile it on their own since the process is a bit convoluted. On linux, you have little to no excuse for not compiling yourself, because you pretty much just have to install the dev libraries, run qmake, then make and you're done (well, it might take a while on a slow machine. I remember building on a K6-2 and it taking 30-40 minutes).

Binaries have been compiled and are now available at the link.

OK, Release 4 Beta 2 release 4 (beta) * fixed uninitialized pointer to log window instance causing a crash https://github.com/jzatarski/RespeQt/releases/tag/r4-beta2 Also, win32 binaries are available now.

It's fixed, right? No more QtSerial backend. Try r4-beta2: https://github.com/jzatarski/RespeQt/releases/tag/r4-beta2