Jump to content
IGNORED

RespeQt 4.3 beta


ebiguy

Recommended Posts

 

My develop branch has all the commits of everybody. It is up to date so the themontezuma's work is fully embedded in my branch.

So, yes, this branch is based on the "best most up to date and bug free RespeQt we had so far being r4".

 

TheMontezuma added SIO2BT support and some other stuff too, all done AFTER Joey's last formal release, which was r4.

 

Like I said earlier, in the Win32 binaries I just downloaded again today from Joey's repository on GitHub, that option did not exist in the settings. The Windows binary posted in this thread in December has them.

 

All of that is not really in dispute or any confusion to me. What *is* confusing to me is why those options are hidden and not used for *nix OS's (OS X, Linux, whatever ...). I am tempted to comment out that entire section and recompile on my RPi3 and see what happens.

Link to comment
Share on other sites

Okay, so some progress with the *nix version. I changed the line I mentioned above that hides the Trigger on Falling Edge option. Sure enough, that now appears as an option in the Raspbian binary I created tonight.

 

By default it is not checked. However, performance remained more or less the same with most ATX files: intermittent but mostly a failure. I experimented with adjusting the response time dialog down from the *nix default of 800 microseconds all the way up to 1,000 microseconds (worse performance) down to as low as 250 microseconds (below the Windows standard of 300). I got marginally better performance with at least one ATX (Archon, for instance, loaded when I changed the delay down to about 600 microseconds). However, most files still hung up - the RespeQt log usually showed a phantom sector or a CRC error part of the file.

 

HOWEVER … when I decided to experiment by changing the Handshaking to NONE and selected the now-visible Trigger on Falling Edge option: VOILA! The Goonies loads, Bruce Lee loads, Ghostbusters loads, Seven Cities of Gold loads. M.U.L.E. loads. The Eidolon loads …

 

You get the idea. So - it seems the best way to actually use this branch of RespeQt with ATX support under *nix is to set handshaking to NONE. I'll do more experimenting tomorrow to see if the "Trigger on Falling Edge" actually makes a difference.

  • Like 3
Link to comment
Share on other sites

More experimentation ...

 

So with the success I had using my RPi3 and handshaking set to NONE, plus Trigger on Falling Edge, I wondered how much that usually-hidden setting for *nix actually matters on this platform. I launched the 4.3 build I made the other evening on my Raspberry Pi Zero W and set Handshaking to NONE, loaded up my usual ATX for Ghostbusters and ... waddaya know? It works! So I tried The Goonies - it worked too. Same for Bruce Lee, The Eidolon, Seven Cities of Gold …

 

I *will* say that setting handshaking to NONE really taxes this little RPiZeroW. The CPU is maxed out at 100% whenever it's "listening" for SIO traffic to respond to. The RPi3 was generally more responsive and had lower CPU usage, which makes sense. Nice to know this little tiny board works at all, but it might be time to retire it to something less taxing and just pick up another $35 Pi3 B Plus for this task.

  • Like 1
Link to comment
Share on other sites

You get the idea. So - it seems the best way to actually use this branch of RespeQt with ATX support under *nix is to set handshaking to NONE. I'll do more experimenting tomorrow to see if the "Trigger on Falling Edge" actually makes a difference.

Happy to read that your Linux problems are over.

 

Did you change anything else other than the source line you mentioned in your post (which was used to hide the falling edge option) ?

Because in the serialport-unix.cpp, the falling edge is not read and not set on com port.

If you did not change the implementation, there is no chance that checking this option can have any effect on RespeQt under Linux.

 

I mean that the implementation was consistent: the falling edge in the option dialog box is hidden on Linux because it is not implemented in the Linux runtime.

Displaying this option should come along with a change in the runtime (file serialport-unix.cpp) to use it.

Link to comment
Share on other sites

Good information. No, I did not make any changes to serialport-Unix.cpp

 

There was some discussion, probably 3 years ago, when RespeQt was forked from AspeQt in the first place, and Hias made some excellent contributions regarding SIO timing, and especially how those things mattered differently for *nix operating systems (I was using a Mac at the time) than they do on Windows. So to the extent anything in that code has changed since the fork, I'm sure it was for a good reason at time.

 

I did learn that I have to adjust a few things when I'm trying to load ordinary ATR files (*NOT* copy-protected ATX files), especially if I want to use high-speed IO. SIO divisor 0 works great for ATR files so long as I have handshaking set to my device's standard of DSR; keeping it set to NONE full-time results in framing errors and usually a failed load. So high speed requires hardware flow-control on my setup.. However, for ATX files I step things back down to the SIO standard of 19,200 bps. For those, I need to change handshaking to NONE or the file will choke, usually at one of the "protection points" in the ATX file - the RespeQt log window will usually display a message that the file is simulating a phantom sector, a CRC error or something like that.

 

So I wonder if we might put in another conditional section in optionsdialog.cpp for *nix operating systems: maybe a checkbox option that asks the user if they are trying to load protected ATX files, and if so, sets the Handshaking method to NONE, and also sets the transfer speed to 19,200. If the box is unchecked, handshaking is reverted to whatever it was set to before the box was checked, and sets the transfer speed back to whatever the user was using before the box was selected.

 

Obviously, more *nix-using people need to see how ATX file loading goes on their systems, with whatever SIO2PC devices they've got on-hand. So far my results are limited to just my 1088XEL machine with an FTDI-based SIO2PC device built in, and with two different Raspberry Pi boards running more or less the same version of Raspbian. I will try again later today with my virtual Ubuntu installation on my Windows box and see if the results carry over. I will also try to dig up my standalone SIO2PC device and load some files on a 1200XL.

Edited by DrVenkman
  • Like 1
Link to comment
Share on other sites

I did learn that I have to adjust a few things when I'm trying to load ordinary ATR files (*NOT* copy-protected ATX files), especially if I want to use high-speed IO. SIO divisor 0 works great for ATR files so long as I have handshaking set to my device's standard of DSR; keeping it set to NONE full-time results in framing errors and usually a failed load. So high speed requires hardware flow-control on my setup.. However, for ATX files I step things back down to the SIO standard of 19,200 bps. For those, I need to change handshaking to NONE or the file will choke, usually at one of the "protection points" in the ATX file - the RespeQt log window will usually display a message that the file is simulating a phantom sector, a CRC error or something like that.

The read sector command in RespeQt takes care of the timing when an ATX file is loaded in the drive slot but, of course, the transmission high speed may affect the protection.

 

But I thought all ATX titles would run regardless of the transmission speed in the option dialogbox if you have a standard OS doing I/O at normal speed.

RespeQt automatically switches back to 19200 after 2 retries. And then all the remaining sectors of the ATX is read at normal speed.

So, if you have selected NONE for the handshake method on Linux, ATX titles should work regardless of the divisor selected in the option dialog.

...unless you have a modified OS doing high speed on standard read sector command. In this case, RespeQt stays at high speed and timings are affected and, of course, some ATX titles do not work.

 

I have a stock XE (standard OS) and high speed is selected in RespeQt (under Windows) and I can load any ATX file. The speed is reverted to 19200 on the first read sector command.

Link to comment
Share on other sites

I did some more experimenting this afternoon - my RPiZero is just not quite up to snuff running with Handshaking set to NONE. For whatever reason, with the same files, same hardware and software and settings, I'm now having issues loading some stuff from it. But the same software runs like a champ on the much more capable RPi3 hardware. Even better, it has enough horsepower to load ATX files at 125kpbs with Handshaking set to NONE (Seven Cities of Gold, for instance).

 

The RPiZeroW handles ATR files up to 125kpbs with no problem so long as Handshaking is set to DSR to match my interface. Set it to NONE and it can generally handle ATX files at 19,200 but beyond that it seems to choke. And again, this morning it's acting flaky when last night it worked great.

 

So looks like I'll be picking up another one RPi3 or 3+ ASAP to use as my dedicated RespeQt server.

Link to comment
Share on other sites

I did some more experimenting this afternoon - my RPiZero is just not quite up to snuff running with Handshaking set to NONE. For whatever reason, with the same files, same hardware and software and settings, I'm now having issues loading some stuff from it. But the same software runs like a champ on the much more capable RPi3 hardware. Even better, it has enough horsepower to load ATX files at 125kpbs with Handshaking set to NONE (Seven Cities of Gold, for instance).

 

The RPiZeroW handles ATR files up to 125kpbs with no problem so long as Handshaking is set to DSR to match my interface. Set it to NONE and it can generally handle ATX files at 19,200 but beyond that it seems to choke. And again, this morning it's acting flaky when last night it worked great.

 

So looks like I'll be picking up another one RPi3 or 3+ ASAP to use as my dedicated RespeQt server.

The weak point of the RPi 1 was the USB port. It was not designed to handle timing dependent communication. I had not much success with a frame grabber on a Rev 1 RPi, but on the Rev 3, that was no big problem. Since the RPiZero is about the same a Rev. 1 RPi, the reported behaviour with RespeQt is no big surprise for me.

Edited by JoSch
  • Like 1
Link to comment
Share on other sites

So now that I've got a setup that is reading and loading ATX files reliably on my hardware, what's the best method to write ATX files to real, bookable floppy disks using my real Happy 1050 drives (I have two of them).

 

I saw some weeks back when user Larry was making images from his protected disks - I tried that for a few minutes tonight myself from a few of my old originals, but I had a medical procedure this afternoon and I'm probably not at my sharpest right now. :)

 

Might it be a good idea to start a new thread? For instance, I've never had any experience with any Archiver drives at all, and I've only had my 1050's upgraded with Happy boards within the last year. So some step-by-step instructions on how to make floppies from ATX files using Happy software or whatever the equivalent is for Archiver, and how to make images of protected disks to RespeQt using Archiver or Happy options would be great too.

Link to comment
Share on other sites

Writing to Super Archiver drive is very easy. No procedure or patch is needed.

Just run your Super Archiver software, either from real floppy or from an ATR file.

Then put a blank disk in your super archiver drive and an ATX in a free RespeQt slot.

Then select the source and destination in Super Archiver software and run the copy process.

Very easy if you know the software. Documentation can be found on internet or in other AA threads.

 

On the contrary, writing floppies to Happy drives requires you to follow a strict procedure because :

  • Happy Backup software must be patched on the fly to be compatible with RespeQt
  • Happy backup does not allow you to choose which drives are the source and the destination

I wrote a walkthru to make real floppies from ATX images with Happy drive in this thread.

 

If you experience some difficulties, let me know and I will be happy to guide you.

  • Like 2
Link to comment
Share on other sites

Thanks for that walkthrough. I still haven't been able to write an ATX file to a real floppy - I keep getting errors when I try it with my Raspbian build but I'm not drawing too much from that until I give it a try in Windows this weekend.

 

I do have a question specifically about this 4.3 branch - your first post indicates that PDB files are now supported. That's great since the 7.1 disk includes quite a number of them, especially if you have a proper full 7.1 Side B image - #protip: most of the archives out there do NOT have an accureate side B. In every case I found until last summer, the B side image wasn't correct or was basically corrupted. Fortunately, after I posted about my problem locating a good side B, some kind soul PM'd me with clean ATRs of his original disks which provided me with working B side images and the additional PDB files.

 

So anyway, whenever I've tried to use a PDB file, as soon as the PDB file is loaded, and I try to continue the Copy procedure, RespeQt goes nuts with a cascading series of red error messages in the Log window while my computer makes scary screeching SIO noise. I have to reboot the computer and usually force-quit RespeQt.

 

I have been swapping the ATX into the D1: slot by drag-and-drop. Should I use the Open icon on the drive slot itself instead?

Link to comment
Share on other sites

I have been swapping the ATX into the D1: slot by drag-and-drop. Should I use the Open icon on the drive slot itself instead?

Very good question. I have to check if drag-and-drop and Open icon execute the same code. Not sure.

But I am sure that with Open icon, you can change the content of RespeQt slot and it will work with PDB files.

 

The way AspeQt and RespeQt were implemented was OK for stock 810 or 1050 emulation.

When I added Super Archiver and Happy emulation, then I needed to keep the current state of the enhancement board (mainly the content of the extra RAM).

But when you load another image in the same Happy or Super Archiver slot, AspeQt and RespeQt internally delete the slot context and recreate a new one (so the extra RAM content is lost - hence all these red errors).

I had to change that behaviour so that when you open an image, the current state is kept. But maybe it is not working with drag-and-drop. I have to check.

PDB files need an image change in the same slot that's why it did not work in a previous release but as soon as I changed this behaviour, PDB files were supported.

 

  • Like 3
Link to comment
Share on other sites

Okay, behavior DEFINITELY seems different if the Open button on the disk slot is used to change contents rather than drag-and-drop. I've been able to succesfully load PDB files and write real floppies from ATX files. Unfortunately, the few I've tried haven't resulted in bootable disk images - usually some kind of hang (M.U.L.E. for instance, even when my floppy is set to Unhappy mode), or a disk error when trying to write The Goonies to disk - I have two ATX versions and a PDB file (on Side B of the Happy Warp Backup disk), but I get disk errors using either of the ATX files.

But still, this is progress from where I was yesterday. :)

 

Do you have a couple examples of ATX files, using PDB files or not, that you've been able to write to physical disk successfully? Thanks!

 

EDIT: I tried my second M.U.L.E. ATX file and this time it worked. Cool! This was booted from the floppy I just wrote:

 

post-30400-0-88006200-1551401976_thumb.jpg

Edited by DrVenkman
  • Like 1
Link to comment
Share on other sites

didn't original happy back up need to launched from the happy drive that created it?

 

Some did require a Happy drive to boot, but a lot don't. In fact, a lot of copies (EA titles in particular) won't run at all from a Happy drive - even the copy you make with the Happy software requires you to first put the drive in Unhappy mode to boot it.

Edited by DrVenkman
Link to comment
Share on other sites

Pardon me if this has already been answered, but is the latest development source available on git? I see this link for the development branch:

 

https://github.com/jzatarski/RespeQt/tree/develop

 

... but it doesn't look like it's been updated recently.

 

Thanks

JoeyZ has been busy/otherwise-occupied for a good while and in the meantime, ebiguy and JoSch have been working on the codebase on their own. JoSch has added better printer emulation, while ebiguy has integrated ATX support, Happy emulation and Archiver emulation. See this post in particular for roll-up builds of their work:

 

http://atariage.com/forums/topic/285890-respeqt-43-beta/page-3?do=findComment&comment=4223062

 

I have built binaries for Raspbian myself though my poor little RPiZeroW is no longer quite up to snuff with the changes to the code to handle more demanding stuff like ATX support reliably. An RPi3B or 3B+ has no trouble with it at all however.

Link to comment
Share on other sites

I've been able to succesfully load PDB files and write real floppies from ATX files. Unfortunately, the few I've tried haven't resulted in bootable disk images - usually some kind of hang (M.U.L.E. for instance, even when my floppy is set to Unhappy mode), or a disk error when trying to write The Goonies to disk - I have two ATX versions and a PDB file (on Side B of the Happy Warp Backup disk), but I get disk errors using either of the ATX files.

Maybe technical information about Happy emulation is useful. First, I will talk about an Atari system with 2 Happy drives and NO RespeQt.

 

When you run the Happy backup option with 2 real Happy drives, the "intelligence" is splitted in the 2 drives.

Happy uploads some custom code to the source drive to be able to read special tracks with timing, sector statuses,... and uploads some code to the destination drive to be able to recreate tracks with the same sectors, timing and statuses.

Now if you use a PDB file,, there is (almost) no need to upload some custom code to the source drive as the PDB files contains a description of the source disk. So the "intelligent part" is really on the destination side only.

 

Now, with RespeQt, this is exactly the same. RespeQt emulates the custom code uploaded by Happy sotfware.

So, without a PDB file, RespeQt has to be "intelligent" and simulate the Happy uploaded code to be able to give information about the sector timings, statuses,... from the ATX file.

But with PDB file, the intelligence is almost only on the destination Happy drive (the real physical drive) and RespeQt has a very tiny role in the backup process (just read all the sector content from the ATX to give them to Happy software).

 

So I am very surprised that some ATX backup do not wotk using PDB files. Anyway, I will have a look at your problem with PDB files and fix any potential issues.

 

Do you have a couple examples of ATX files, using PDB files or not, that you've been able to write to physical disk successfully? Thanks!

I tried a couple of PDB files last year but don't remember which ones.

Link to comment
Share on other sites

JoeyZ has been busy/otherwise-occupied for a good while and in the meantime, ebiguy and JoSch have been working on the codebase on their own. JoSch has added better printer emulation, while ebiguy has integrated ATX support, Happy emulation and Archiver emulation. See this post in particular for roll-up builds of their work:

 

http://atariage.com/forums/topic/285890-respeqt-43-beta/page-3?do=findComment&comment=4223062

 

I have built binaries for Raspbian myself though my poor little RPiZeroW is no longer quite up to snuff with the changes to the code to handle more demanding stuff like ATX support reliably. An RPi3B or 3B+ has no trouble with it at all however.

 

I seemed to have missed that as I browsed through the thread...

 

I am very interested in the Raspbian builds. I do have a RPi3B and B+ available so I will need to try your version out.

 

Thank you for the help!

Link to comment
Share on other sites

 

I seemed to have missed that as I browsed through the thread...

 

I am very interested in the Raspbian builds. I do have a RPi3B and B+ available so I will need to try your version out.

 

Thank you for the help!

I don’t have portable binaries set up to share right now but I can try to zip up some stuff tonight. I was able to copy ebiguy’s development branch to my board with the following terminal command:

 

git clone -b develop https://github.com/ebiguy/RespeQt.git

 

Then building it is just a few minutes on a Pi3 or better. cd into the RespeQt directory; qmake and then make -j4 (the -j4 option will speed up compile time significantly. If your system hangs or fails, delete the option and try again).

 

This assumes you have the Qt5 libraries installed on your board. If not, there’s a thread further down in this sub-forum that describes how to install them.

Link to comment
Share on other sites

There’s a thread further down called “RespeQt on Raspberry Pi”. This post from Hiassoft gives you the basics:

 

No need to compile QT5 yourself. If you are running the current Raspbian release (Jessie) it's as simple as that:

 

sudo apt-get install build-essential git qt5-default qtbase5-dev
git clone https://github.com/jzatarski/RespeQt.git
cd RespeQt
qmake
make -j 4
./RespeQt 
Takes some 10 minutes total (depending on internet speed and performance of your SD card) on a RPi2. On the old RPi use "make" instead of "make -j 4".

 

so long,

 

Hias

Substitute ebiguy’s repository and that’s about it. I think I had to also download a couple additional Qt5 libraries - SVG and maybe one other. But the compile error I got let me know which ones and then it was just “sudo apt-get install” the missing library and its dev as well.

Link to comment
Share on other sites

Hi,

 

When you run the Happy backup option with 2 real Happy drives, the "intelligence" is splitted in the 2 drives.

Happy uploads some custom code to the source drive to be able to read special tracks with timing, sector statuses,... and uploads some code to the destination drive to be able to recreate tracks with the same sectors, timing and statuses.

Now if you use a PDB file,, there is (almost) no need to upload some custom code to the source drive as the PDB files contains a description of the source disk. So the "intelligent part" is really on the destination side only.

 

I'm not sure this is accurate. I would say that it depends on the PDB. E.g., some PDBs just set some backup parameters such as "force slow" or skew align. In many cases the source drive still needs the custom code to to be able to read the copy protection.

 

In the specific case of MULE, the PDB has an internal knowledge of the original skew align. So it reproduces the original skew alignment without reading it (even if the source disk has the wrong skew align). But it still needs to read everything else from the source disk including the copy protected track with 19 sectors.

Link to comment
Share on other sites

Hi,

 

 

I'm not sure this is accurate. I would say that it depends on the PDB. E.g., some PDBs just set some backup parameters such as "force slow" or skew align. In many cases the source drive still needs the custom code to to be able to read the copy protection.

 

In the specific case of MULE, the PDB has an internal knowledge of the original skew align. So it reproduces the original skew alignment without reading it (even if the source disk has the wrong skew align). But it still needs to read everything else from the source disk including the copy protected track with 19 sectors.

 

Yes, you are right.

That was just a way to "simplify" the explanation but code is always needed in both source and destination disk.

Link to comment
Share on other sites

Guest
This topic is now closed to further replies.
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...