Greetings!
I've posted on the Yahoo group before. This time I come bringing news of a possible TC-64 glitch (Beta 9g)! I've been working on a program that benefits from the turbo mode and the REU of the TC-64. This program also benefits from the turbo mode of a SuperCPU, and any expanded RAM it might have. My program also has a menu mode. Well, my program seems to work fine on the TC-64 (I kind of need it to if I am to support the device), except when it comes to the menu! See, before the menu is displayed, I have my program copy the screen (text and color) as well as the information on "logical lines" to the expanded RAM that's available (so it could be copied back after the user is done with the menu). I have provided a routine below that mostly resembles the routine my program uses to copy this information to an REU (it's just a simple REU access routine). Immediately following the first RTS instruction would be the code that copies the same information to a SuperCPU (I don't need to provide that code).
Anyhow, on the TC-64, I noticed that my program was attempting to copy the screen information to a nonexistent SuperCPU (my program generates an error in such events to prevent a possible crash). I thought perhaps my program had detected the TC-64 to be a SuperCPU, but after trying to close in on the cause of this bug, I couldn't find anything wrong in my program code -- very frustrating! It never occurred to me that the TC-64 could be at fault (and considering that it is in a "beta" stage, I should have put two and two together much sooner). My program has no problems accessing other REU implementations.
For whatever reason, the RTS instruction was not being executed on the TC-64, so the SuperCPU code that followed it was being executed somehow. I had a hunch, though -- after further narrowing things down, I guessed that it could be the copying of color RAM to the REU that is causing the glitch. To test my hypothesis, I simply had my program copy the screen text twice in place of copying both text and color data. Sure enough, the glitch stopped happening! The RTS instruction was being executed!
Perhaps there are timing issues involved with this glitch? I don't know since I know nothing about electronics and FPGA-related matters. Studying the problem further, I noticed that I had to pad two more RTS instructions into the code to get one of them to be executed. I tried another instruction at one point (I think an INC instruction) in my investigation and I noticed that it wasn't being executed either. BRK instructions ARE executed though (if you replace any of the RTS instructions with a BRK, it will be executed). The final BRK in the listing below does not execute. The extra two RTS instructions and the BRK instruction are NOT part of the original code -- just added for testing. As a temporary fix to the problem, having the three RTS instructions there sort of solves the problem -- the color RAM is copied to the REU.
But the problem still rears its ugly head in that something is not being copied correctly. Some of the color bytes are not being restored to their original colors after the menu is displayed and then the original text screen is restored. I'll try to attach some photos of the minor color glitches. Anywhere from 1 to 9 bytes come back in the wrong color. For the sake of testing for color issues, the entire screen was filled with reversed spaces in my test photos. There is a little consistency between the spacing of the gray squares you see (I don't think it's 100% consistent). If you follow an upper one down to a lower one, the lower one is usually twelve spaces down and four spaces back (so I guess that makes them spaced 476 bytes apart). The "bad bytes" seem to be paired in twos.
I'm providing the code below in the hopes that you guys can reproduce the error. I'm not sure if the error would occur if I altered my code and recompiled it. In other words, the current starting point of this code is at location 15554, and moving the code from this location MIGHT generate different results (I haven't tested this theory). I am guessing that the problem occurs the moment STA57089 is issued. The "DEY:BNE#3" is important to my code but is not relevant to the problem. The "LDA#0" at the beginning does not exist in my code, but the Accumulator is zero by that point (the STA57098 should still fall at the correct address of 15556 in my program). I don't know if there is anything else relevant that I need to disclose, except that the BASIC ROM is turned off much of the time in my program.
Variables:
M1=55296 (C64 address)
M2=REU address (address 230632, 3 bytes)
L=1000 (length)
DR=0 (data direction)
Routine Address = 15554
LDA#0: STA57098
LDA#31: STA57097
LDA M1: STA57090
LDA M1+1:STA57091
LDA L: STA57095
LDA L+1: STA57096
LDA M2 :STA57092
LDA M2+1:STA57093
LDA M2+2:STA57094
LDA DR:ORA#144
DEY:BNE#3 (note: this branch is not executed as .Y=1)
STA57089
RTS (bypassed)
RTS (bypassed)
RTS (executed!)
BRK
Final words:
Okay, I wrote this some weeks ago and I admit it's not an easy read -- I apologize if anything confuses anyone. I wanted it to be as detailed as possible. I recently discovered a glitch in how the SuperCPU works with an REU, but the issue is different (but not entirely unrelated). With the SuperCPU, the text screen being copied has issues (when it is copied to the REU). Apparently, the text that you see onscreen gets shifted over a byte (during the "STASH") and a reverse letter "P" appears at the head of the data being "stashed" (I believe this to be the actual "stash" code itself, since it happens to be 144). I understand that the SuperCPU "mirrors" data between the SuperCPU and the C-64, so I believe that this strange issue is only happening to the data residing on the C-64 text screen (and not the SuperCPU "mirror"). I could have a defective SuperCPU, but it seems to function fine for everything else I throw at it.
Anyhow, you should be able to recreate the glitch where the RTS instructions are being bypassed (using my code above). As for the gray color bytes in the photos I intend to attach, I'm less confident that you'll be able to reproduce those with my programming above. I tried running the routine above outside of my main program and only the instruction bypass issue seemed to pop up. I hope all of this helps in some way. Can you let me know if/when this issue is resolved?
Here are the photos I've taken of the visual anomalies I've mentioned (in my fifth paragraph): https://photos.app.goo.gl/29Q9ki4uUbBqzEpc7
(I hope you can see them -- I'm new to sharing photos via Google).