[BUGS] Problem with REU transfers from/to I/O when turbo is enabled

Caution: Non registered users only see threads and messages in the currently selected language, which is determined by their browser. Please create an account and log in to see all content by default. This is a limitation of the forum software.


Also users that are not logged in can not create new threads. This is a, unfortunately needed, counter measure against spam. Please create an account and log in to start new threads.

Don't Panic. Please wash hands.
  • 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).

  • can you please provide a working binary of the program you are testing? it looks like there are simply bugs in your program - but its hard to tell since i am not familiar with that assembler you are using.

  • I could easily attach a D64 file, but I can't seem to attach files to this forum. I'm not sure yet if my Google account will let me upload files (I haven't checked into it). Are there any recommended sites for attaching files, or is there a way to do it directly in this forum? I'll be back on later tonight to see if I can create and upload the file you need.

  • In response to your response, the program shouldn't have any bugs because it works with a regular REU attached to the C-64 -- it works with the 2MB CMD REU, a 512K REU I have, and the REU provided by the 1541 UltimateII+. I'm providing a D64 file that you can test. This is not my main program project, but rather a test program that I whipped up that tests the routine that seems to fail on the TC64. The code I provided at the start of this post is part of the file on the D64 image. But I also added other code that should help you to be able to diagnose things. So simply download the file to get started:

    https://drive.google.com/file/…SUEohizy/view?usp=sharing


    And then load and run the file in the image (make sure to include ",8,1"). Issue an SYS15549 to run it.

    The program will clear the screen, fill the text screen with reversed spaces, fill the color RAM with a pattern, issue a "STASH" of the color RAM to the REU, a pause is executed, then the screen is cleared again, filled with reversed spaces again, and then the color RAM pattern that was copied to the REU is "FETCHed" back into the color RAM. Another longer pause is issued before control is given back to BASIC.

    Now if you're using a regular REU with a C64, the program works fine (as far as I can tell). But when I run the program on my TC64, the RTS instruction is bypassed as mentioned in my original post and one of the following BRK instructions is executed instead. As a temporary fix to the problem, you can POKE 15618,96 and POKE 15619,96 and I think that should allow my routine to work (issue an SYS15549 again at that point).


    But I think you should also be able to witness the color byte issues shown in my attached photos, except in this case, you'll have to find the "bad bytes" in the color pattern produced by this particular test program (it may take some searching). On my screen, they tend to be light blue. So run the program again -- SYS15549 -- and do not clear the screen! Issue another 15549 (right over all of the mess on the screen) and keep doing this over and over again -- you should be able to find some bad color bytes on the screen (at least this is happening on my TC64).

    Anyhow, let me know if you have any problems. My test program isn't elegant -- it's just a test program, and a tad messy in structure. I just wanted to keep the STASH/FETCH routine exactly where it resides in the program that I'm currently working on (a big project that I started back in 2000). So the file I've given you jumps past the STASH/FETCH routine and does all of the stuff mentioned above and then it calls the STASH/FETCH routine twice before returning control back to BASIC. It also switches BASIC ROM off during the STASH/FETCH because my larger project also turns the ROM off and I just wanted to recreate the situation the best I can (I'm not sure that the ROM being off has anything to do with the glitch). Regardless, my project needs the ROM to be switched off.

    Let me know how it goes...

  • attaching files should work now (hopefully...)


    checked your program (see the zip) and indeed it seems to be fine.


    not surprisingly, it also works fine here with chameleon :)


    now it would be interesting to know your exact setup, what do you have connected, what are the chameleon settings, etc. for example, does the problem only happen when turbo mode is enabled? (that seems to be the case actually, but first lets find out if it works for you without turbo...)

  • The file I sent you does seem to work fine when turbo mode is turned off. My program makes use of the turbo mode when a computer has it (I think during the REU access), so I guess that may be the problem. But the problem only seems to happen with the color RAM screen in turbo mode (other areas of RAM seem to fetch and stash without issue as far as I can tell).

    I don't think I've messed with other settings. I'm only concerned with turbo mode and having the REU enabled.

    So when you enable turbo yourself, do the issues I mentioned pop up? It would be nice to have a fix, if possible. I understand that FPGA is a complex thing. I don't remember if I read this or not, but don't the stash and fetch actions of the REU still happen at 1MHz? I think this is the case with the SuperCPU. I have to wonder if the glitch I'm seeing with the SuperCPU is also happening ONLY in turbo mode (something I can check into). The SuperCPU issue isn't "lethal" though, so it's a minor thing and hardly noticeable in my program. But the TC-64 issue is "lethal", unless I pad things with the extra RTS instructions.

    Anyhow, please let me know if anything can be done on your end. On my end I suppose I could turn turbo off during REU access (when copying the color RAM), but it will make the process a tad convoluted (I'd rather not have to turn it off if possible).

    I think I read in the terms of service that I can't promote my software program here. Sadness... It supports the turbo mode of the TC-64 and the SuperCPU, and it requires either REU memory or the expanded memory of a SuperCPU. So anyone who buys the software will need to have a TC-64 or a SuperCPU to enjoy turbo speed (the only two devices supported at this time for turbo), and an REU if they don't have an expanded SuperCPU.

    Thanks for enabling file attachments! Does this work for photos? Videos?

    What is your attached file for? I downloaded the file, but I wasn't sure if you were just testing things.


    -------------------------------------------------

    Addendum: Just tested the SuperCPU again. The issue with it happens at normal speed.

  • the zip i attached contains your program, i just disassembled and commented it a bit so i can see what it does :)


    so i guess we can confirm that there is a problem with REU transfers to I/O (colorram) when turbo is enabled. there is no easy/quick fix for this - we'll have to look into it at our next debug session :)


    that said, on chameleon when turbo is enabled, it is actually faster to copy bytes in a loop with the cpu (because as you said, REU is still tied to 1MHz)

  • Yeah, I'm sure it is a lot faster to copy bytes in turbo mode -- the same thing goes for the SuperCPU. But I need the extra memory, sadly enough. My program pretty much uses all of the memory of the C64 up to location 53247, and that doesn't leave enough memory left to actually load and save any data (even the RAM after location 53247 isn't enough). One of my missions is to make the humble REU more relevant, so many of my projects will probably use it. So if anyone wants to use my software, they're gonna have to find an REU in some form (VICE would be the cheapest option of course) if they don't have a SuperCPU with expanded RAM. I plan to eventually add GeoRAM as a supported RAM. But again, having a turbo mode of any kind will be a great bonus for any user of my program. So you might see some sales of the TC-64 as a result of my software (if the TC-64 is available when I launch). I honestly don't know the impact I'll have though. It might be good if somebody could compile a list of software that benefits from the TC-64 (so that people can answer the question "Why buy one?" -- aside from the usual reasons for buying one). Any project like yours that my software can take advantage of, I'll support it for sure!

    I honestly wasn't looking for any problems with the TC-64 -- I have felt the pain numerous times of dealing with the bugs in my own software. It was only in recent months that I discovered that REUs don't "wraparound" properly at every 512K. Normally a chunk of data will overlap into adjacent banks without issue, but not at each 512K mark. So I had to fix my software to deal with the issue -- in case a particular REU had the issue. Thankfully, I don't think the TC-64's REU has this issue (I applaud you!), but I still have to pretend that the issue exists regardless (even VICE mimics the "bad" behavior accurately, as well as the 1541 UltimateII+). Anyhow, I think I've handled most of the hardware issues I've come across. I can't do anything about the issue that the SuperCPU has with copying the text screen to an REU, but again, it's minor. The only real workaround is to copy the text screen to a different location in memory, and then send the copy to the REU instead. I'm not sure why the problem happens, but I'm sure it has to do with the mirroring that the SuperCPU employs (between the C-64 memory and the 64K of memory inside the SuperCPU itself).

    As for my assembly language at the top of this thread, I thought it would be an easy read for you -- sort of a generic layout of the code. But I created my own assembler because I really don't like how assemblers format things. I'm spoiled by all of my programming in BASIC, so I prefer a layout that is easier for me to read. My assembler even supports line numbering -- like BNE1000 (not the address "1000"). And I seriously dislike hexadecimal, so I rarely ever use it.

    So are you going to update this thread if a fix is found?

    Thanks for listening!

    P.S. I thought the TC-64 emulates a GeoRAM as well (I thought I saw that it did). So if it does, has it been tested to work in turbo mode? I suppose that might be good to know (for me).

  • I think I read in the terms of service that I can't promote my software program here.

    The terms of service are written by a lawyer who knows very little about the Retro community. Rest assured that mentioning your software and a source where people can buy it will not be treated as a violation. We're part of the retro community, and support for other developers should be taken for granted. I guess (because I can't look inside the weird brain of a lawyer) the idea behind "no advertising" is to keep spammers out and to disallow direct competition in this commercially-run forum.

    P.S. I thought the TC-64 emulates a GeoRAM as well (I thought I saw that it did). So if it does, has it been tested to work in turbo mode? I suppose that might be good to know (for me).

    Yes, GeoRAM is supported. You can switch it on and choose it's size in the settings, and even enable it at the same time as REU, creating a setup where you have access to 20MB additional RAM (max size of GeoRAM is 4MBytes).


    There are other software-compatible implementations such as "NeoRAM" and due to the low price, the German company "Rex Datentechnik" has sold quite a few 512k units back in the days (I think this was under the real name "GeoRAM").


    As for turbo compatibility, I would not expect any problems because it's way less complex than the REU.


    Jens

  • Quote

    So are you going to update this thread if a fix is found?


    of course :)


    btw, as for the 512k wraparound... the chameleon also emulates that, but only for REU sizes <=4MB (IIRC)

  • The last reply was more than 365 days ago, this thread is most likely obsolete. It is recommended to create a new thread instead.