Joey Z

I would say just the specific command. This is really a security thing, I guess. Maybe I'm being paranoid I don't even really care all that much, but someone else might.

no, those are all the later 5V powered models. The original 800 supply was a 31VA 9VAC transformer. 31VA equates to over 3A (or 3000mA). You can try the 2.1A supply, but it's possible you might draw too much current for it on a fully loaded 48K machine. They previously had a 15VA supply on the 400, and supposedly that wasn't enough, for the 400. The 400 having less RAM slots.... Not to mention, on an 800 you can plug in two carts, and an SIO device, and stuff powered through the joystick ports, and and and..... So anyway, 31VA on the original supplies is almost certainly overkill for continuous duty, but by how much, I don't know.

Another note, pull requests for new features from now on should be made to the develop branch. Master will be used for 'production ready' code, as per this scheme: http://nvie.com/posts/a-successful-git-branching-model/ unless someone sees a flaw with this, and objects to it.

It's not out of the question, but I think enhancement of cassette support is a backburner item now and probably for quite some time.

This functionality belongs in a separate software package IMHO

A long overdue announcement I think, but the last pull requests I will process before compiling and creating an r4 beta to be released is this Friday, April 14th, 2017, Central Daylight Time (GMT-5:00). You might squeak by if you get a PR in by early saturday morning. After that, I have to begin the painstaking process of doing all the little things to prepare for release, and the time from the beta to the actual release can't have any new changes in the master branch. I've got a text file somewhere reminding me what all those little things are.... I may be contacting contributors privately to discuss certain minor aspects of this process, in particular, applying the proper copyrights to new files, under the proper (preferred) names/handles. So, long story short, if you're a contributor with something worth making it into beta, go ahead and make a PR by Friday so I can merge it before I release the beta. Thanks

Additionally, as a general note, I think release 4 is long overdue at this point. Plenty has been added, and plenty has probably become mature enough to be released. That said, I'll be 'locking down' RespeQt this weekend, so friday night will be your last chance to get a pull request into the repository if you think something is ready to go into an r4 beta I hope to release this weekend. Given most of the stuff here has more or less been released in some kind of alpha or beta form, I'll trust that (barring any obvious issues) a week of beta testing is sufficient before the beta is considered 'stable' enough to be a normal release. Also, I'd like to work on the 'RespeQt infrastructure' here a bit so to speak. time allowing, I want to formalize the contribution system a bit, developing documentation for how to contribute and that kind of thing. I've been reading a great open-source book about managing open-source projects and it's made me realize the importance of some of these things (mostly because I've seen the general shortcoming of my current method(s) of managing RespeQt).

The subfolder I agree with, but the namespaces might require a bit more discussion. Are they really necessary? Do they provide an important improvement in readability, or code organization? If you believe so, then you have my support, but if not, then I'd stick with just using classes outside of a specific namespace. I assume you were going to do something like put all the printer classes into a Printer namespace. Maybe I'll have a look at your git fork and see what you've currently done....

Well, the 'polling' process you describe, if I'm not mistaken, is performed by the OS ROM actually, not the DOS. I could be mistaken. 400 and 800 don't do the polling, so the only way to load the 850 handler is by disk boot without disk, or by running a special loader from DOS that loads the 850 code. I'd consider keeping the functionality, but implemented in a somewhat different form. For the moment, it could be left off, and then implemented later once time has been taken to figure out how the feature would be worked into the current RespeQt APIs.

A lot has happened on RespeQt since I was busy working on other things.... This is certainly an interesting feature, but I think we should discuss adding a checkbox to the option to disable it. (or has this already been done?) The last thing we would want is malicious software running on the Atari that is submitting things to a malicious URL. Seems unlikely, but I'd rather not give the NSA reasons to write Atari software

There are SIO2PC devices which may use the DTR or the RTS signals to select the mode, either to enable them or to set them to SIO2PC mode (vs, for example, 10502PC mode). I seem to remember the Atarimax RS232 SIO2PC needs one of these lines set properly, though I could be mistaken.

No, there's probably a way to do it. All the .ui file stuff is processed into C++ code that sets an option somewhere. You just need to figure out where it sets that option, and what it is, and then figure out where is a safe place to set it during run time in code that isn't produced from the ui file. I'll look into it myself when I have enough time to do so, if this is still an outstanding issue when I get to it.

yes, provide Qt has linux FB support (and it appears it does) there's something you've got to configure within your Qt build environment to use the linuxfb instead. I'm not sure how to do this, but it might involve building the Qt libs from scratch, unfortunately. There should be nothing in RespeQt that inherently requires X11. Let us know how it goes

has this issue been confirmed to be an SDX problem, or is it potentially an issue with RespeQt still?

If you're so impatient, write it yourself. We don't need your negativity here. The people working on this project do not make money from RespeQt. We do so out of the goodness in our hearts, in our own free time, to support the community with free and open tools to use our Atari computers with. I have no problems with people submitting outside code to the project, so go ahead and get started!

Unfortunately, no, and it will probably never be done. Saving tapes sends audio over the SIO data line instead of data. You'd need to hook your atari SIO cord into a sound card really. Maybe you could look at the raw data in value somehow (no clue if there's an API for that) and measure the timing, but I'm guessing this is *probably* not worth it, better to make some sort of SIO -> audio interface specifically for recording 'tapes'.

yes, this should be fixed. Have we talked about this ever? I'd appreciate it if you could add an issue to github, more things that really should be fixed, to add to the ever growing list.....

yes, I think we're pretty confident this is the issue. Some labels from NewDevice6502.asm: Scratchpad = $8000 JumpTableLo = $8100 JumpTableHi = $8180 GenCode = $8200 So it's definitely using the cartridge region's RAM, which won't work with a cartridge that fills that space. The good news is that it's probably not too bad to fix, just move around the memory map a little bit.

I hadn't realized this was available to be viewed, I figured it would have been closed source. And if this is true, then that's great news, because it's not my problem anymore (because it's fixable in software, and I am just installing the hardware).

So I'm working on a 130XE for someone, for way too long now actually, and I have installed a rapidus and a U1MB into the machine. It took some additional troubleshooting to make it work, but the last problem I can't seem to get rid of is that some cartridges don't load. Basically, rapidus freezes while loading the FPGA core. The loading bar never fills. I've got it narrowed down to 16K cartridges, and I've actually narrowed down that it has nothing to do with the cartridge itself, but that RD4 is pulled high (and thus RAM at $8000 disabled). Has anyone with rapidus been able to consistently get 16K cartridges to load? This machine has no issue with 8K carts at all, just 16K. The worst part, is that I SWEAR I had 16K carts working 2 times exactly (no more, no less) but it wasn't because I fixed anything, or did anything, it was just random chance, apparently. I've removed the U1MB and gone back to the normal MMU and OS ROM, no change. I even reflashed the CPLD and loaded the latest FPGA core, also no change. I've tried different CPUs, no change. I've found other mention of issues with carts, but just from one person: http://atariage.com/forums/topic/257225-rapidus-questions/?p=3597056 he says DK didn't work, that's one of the ones I tried here, and it's a 16K cart. Earlier, he said defender didn't work, another 16K cart. Also, inserting a cart when the system is on (after the rapidus core has loaded) and resetting lets the carts load fine. So it's something specifically during the FPGA core load. I don't know, maybe the rapidus designers forgot that there might not be RAM at $8000? sounds doubtful, but not impossible.

actually this has been on the todo list for a while now. AspeCl was included in RespeQt but it was a known issue since it didn't have source, and licensing was unknown. At some point, when you feel this is complete enough/tested enough, I'd like to add it to RespeQt as a replacement for AspeCl.

there are tty devices, and cua devices, maybe try the other? (just a shot in the dark)

No, polling will work for the RI line, but windows event trapping will not. RI can be read at any time, but it only produces interrupts on the edge we don't care about, that is the issue. That all said, I have had machines that don't work with RI at all for whatever reason. Regardless of RespeQt/AspeQt version.

I suppose in that case, we would have to poll like we do in linux, at least for RI. Maybe make a 'force /CMD polling' option for windows?

You are using windows, right?