Amiga disassembly

[20CenturyFan]

I have posted an image of what happened when I tried to compile it. It comes out with a whole bunch of errors and warnings and will not compile. I may be missing files that you have that are required to compile this. It probably won't work for my setup.

My intention was to try to load the "virgin" copy of the Prevue software into WinUAE and see if I could use this to get the overlays to show the contents of the PromoID.dat file. I am beginning to wonder if there is a way to link the two...

[AriX]

I have posted an image of what happened when I tried to compile it. It comes out with a whole bunch of errors and warnings and will not compile. I may be missing files that you have that are required to compile this. It probably won't work for my setup.

My intention was to try to load the "virgin" copy of the Prevue software into WinUAE and see if I could use this to get the overlays to show the contents of the PromoID.dat file. I am beginning to wonder if there is a way to link the two...

I don't believe there is any promo data in the PromoID.dat file - and even if there was, I don't think I've figured out enough about the CTRL format to show it on screen! But as for the code problem, that was entirely my fault - I missed an entire line. I updated the code on the other page - try copying and pasting it again and seeing if it will compile this time! If there are more errors, please let me know... it's probably just my fault again.

[20CenturyFan]

It compiled! And ESQ was showing activity on CRTL H and T. However, I still cannot get an overlay to show. It also seems that the program only runs once and closes, so I put together a batch file to execute it repeatedly. I've been feverishly pushing the L and R keys, but I have not seen an overlay drawn yet. lol

[20CenturyFan]

For the record I believe I am close though! It only seems to show up when I am in the menu, and I have to hurry up and hit print screen to take a capture before it disappears (it is there only a split second when I exit the menu.)

[AriX]

For the record I believe I am close though! It only seems to show up when I am in the menu, and I have to hurry up and hit print screen to take a capture before it disappears (it is there only a split second when I exit the menu.)

Hmm... I don't think that means that the command was successful. I have seen that on occasion. Try this:

Go to Diagnostic Mode
Go back to listings
Run the CTRL command once (not with your batch script)
Go back to Diagnostic Mode

What does the CTRL H: counter say? If it's anything other than 5, something is not working.
What does the CTRL Cmds: counter say? If it's anything other than 1, something is not working.

I'd speculate that your emulated ESQ is not running at the exact same speed as an actual Amiga, and therefore you need to find a different interval to wait for sending the data. Let me know if this is the case - if so, I'll build you a version of my program that tests a large range of intervals, so that we can find the right one for your setup.

Also, just so you know, CTRL H: and T: is cleared whenever you exit Diagnostic Mode, and commands are not parsed at all in Diagnostic Mode - so make sure you're seeing the listings when you are sending CTRL commands.

[tin]

I attempted to do this with my setup (VSPE + Com Port Data Emulator) and could not get my overlays to show up. However, I notice that pressing "L" sends a 0x01 back to my serial, an "R" sends an 0x02 back to my serial, and "G" sends an 0x03 back to my serial (and G works my graphics).

From memory, the Amiga controls the Audio switching card by sending this bitpattern back over the serial port to the data demodulator to flip to right or left video, or background music. The data demodulator then controls the audio card via unused pins in the ISA bus. Thus, the Amiga still makes the decision what to show, and switches the audio in time with the video being chosen.

[20CenturyFan]

In my previous instance above, I was getting those counts on CTRL when I checked diagnostic mode. However, when I tried this on my other computer, CTRL does not respond at all. I run Prevue on two different systems with the same settings... doesn't make sense why one would respond and the other would not . Suppose the hosts running WinUAE have anything to do with it, perhaps the host processor timing? (The one that had a response from the program's CTRL command was an Intel E4500 Dual Core desktop running Vista x64, while the other one is an 8 year old Pentium 4 3.0Ghz laptop running Windows 7 Ultimate 32 bit. They are quite a ways apart in performance.)

(I would like to add that the laptop is the one I would rather it worked on, since it is the one that is connected to my TV and I usually keep my Prevue emulation playing on it overnight)

Correct me if I am wrong, but if I were to compensate for a slower host computer, would I change the "usleep" function in the Ctrl.c file to a number lower than 3177? (If I am going on the wrong tangent here, let me know. lol)

[AriX]

In my previous instance above, I was getting those counts on CTRL when I checked diagnostic mode. However, when I tried this on my other computer, CTRL does not respond at all. I run Prevue on two different systems with the same settings... doesn't make sense why one would respond and the other would not . Suppose the hosts running WinUAE have anything to do with it, perhaps the host processor timing? (The one that had a response from the program's CTRL command was an Intel E4500 Dual Core desktop running Vista x64, while the other one is an 8 year old Pentium 4 3.0Ghz laptop running Windows 7 Ultimate 32 bit. They are quite a ways apart in performance.)

(I would like to add that the laptop is the one I would rather it worked on, since it is the one that is connected to my TV and I usually keep my Prevue emulation playing on it overnight)

Correct me if I am wrong, but if I were to compensate for a slower host computer, would I change the "usleep" function in the Ctrl.c file to a number lower than 3177? (If I am going on the wrong tangent here, let me know. lol)

Hmm... CTRL not responding at all sounds like the program just isn't working, or you're having a problem with the serial port. I don't think that would correspond with the delay - even if the computer is a little slower, you should get at least one byte through to CTRL. For me, the CTS interface needed to get CTRL data doesn't work at all in emulation, so maybe you're having the same problem.

For the one that does work: you do get CTRL H: as 5 and Cmds: as 1? If so, I am going to give you a custom ESQ binary so that you can figure out what data exactly is coming across.

[20CenturyFan]

I didn't pay attention to the numbers other than that it responded the last time, but upon just now trying it again I get the following line...

CTRL: H:00001 T:00000 C:00001 MAX:00001

On the other line featuring CTRL: Cmds:00000000 CErrs:000 LErrs:000

Upon running my batch immediately after checking the results of your program running once:

CTRL: Cmds:00000002 CErrs:001 LErrs:000
CTRL: H:00261 T:00261 C:00000 MAX:00002

At the end of the batch, before I went into diagnostic mode, the command at some point seems to have turned the top half of the screen white (like it is when you exit the menu)

EDIT: I restarted WinUAE and ran your CTRL.exe again and got a different result... H:00002, T:00002, C:00000 and MAX:00001
CErrs:001

From what I can gather, it seems that it is indeed sending out a control command, but it is being received in partial for some reason (could be something on my end)

[AriX]

From what I can gather, it seems that it is indeed sending out a control command, but it is being received in partial for some reason (could be something on my end)

It's definitely a problem with the delay/interval, and the command is not being received properly. If it is receiving five bytes as one or two bytes, it is not even close to working.

I can't do it right now, but hopefully tomorrow I can put together a version of the program that increments the interval so that we can find the one that should work with your software. The interval you are looking for will be higher than the 3177 one that seems to work for my Amiga. (When you're compensating for a slower computer, you are compensating for slower Amiga emulation - not a slower CTRL command sender - so you just need to send the command slower, with a greater delay.)