|
|
Post by phonon on Feb 3, 2021 18:12:41 GMT
Dear mates,
I am preparing my "the C64" as development machine for my son and actually would like to get an idea about the workflow.
I prepared a REU enabled TMP and that works great now (especially after the last update without any additonal effords, beside
a standard config file in the root directory). What I really miss is the vice debugger while programming. So I asked myself, what
is the recommended way to debug when developing with TMP. Can I somehow keep the supersnapshot as debugger in the
background, but how could I trigger it to reach the monitor.
Any suggestions?
Thanks a lot and cheers VIVA C64 !
73,
Stephan
|
|
|
|
Post by javimm on Feb 7, 2021 17:55:04 GMT
Hi, Stephan.
I use that very same setup.
First thing I do is launching the Supersnapshot cartridge image. After pressing F7 or DEL to exit the main menu, I mount the TMP image. I have put a _R5 in the D64 file name so that TheC64 activates the REU when the image is mounted. Then I LOAD"TMP+REU",8,1 and then SYS32768 and now I'm inside TMP. To access the SS monitor, press the right SHIFT+Power Button of TheC64 (this is the freeze function) and select the MONITORS option, then the ML MONITOR option and you are inside SS monitor.
Regards.
|
|
|
|
Post by Unbeliever on Feb 18, 2021 22:24:29 GMT
I use the same setup -- TMP+REU along with the Super Snapshot cartridge -- and just wanted to add a few notes. 1) I've had trouble with disk access unless I disable either the Super Snapshot "turbodisk", or the TheC64's own fast access feature. (I believe it's the two running concurrently that causes the issue -- has anyone else had this problem?) To resolve this, I just use the ">TD" command when first exiting to Basic from Super Snapshot. 2) I have a "Programming" directory on my USB, to separate my own work from the various game folders also on my USB stick. (Actually, I name it "!Programming!", so it sorts first in the media access menu.)  The _R5 filename flag on your .d64 is well and good -- but if you EVER switch disks to one WITHOUT that flag during your session, you will lose your REU and everything in it. I recommend putting a file named "thec64-default.cjm" inside your own programming folder, and including this line in the file (changing any options you care to): X:64,ntsc,reu512,driveicon This will make it so ALL of your programming disks (even in subdirectories of your programming folder) will use the REU, and you never accidentally lose it. Any disks OUTSIDE your programming folder will remain unaffected. I am always interested to hear from anyone else doing work with TMP+REU and Super Snapshot. I'm working on my first game -- something like a stripped-down version of Space Invaders -- and having gotten the game fundamentals down, am currently at war with SID to make some sound happen. |
|
|
|
Post by namrok on Mar 30, 2021 19:30:50 GMT
Have anyone had any luck using Super Snapshot's brk/monitor functionality?
I tried getting this working last night, and something just seemed off. According to Super Snapshot's manual, if you bring up the monitor and type "BR" it sets the interrupt vector for a $00/BRK opcode to open up Super Snapshot's monitor. I did so, and it displayed the message "Done", or something to the effect of it having been performed.
However when I went to insert a BRK statement into my TMP program, a program I know otherwise works, I found myself dumped back to basic instead upon hitting it. In fact, I had actually already opened up TMP before opening Snapshot's monitor, and after using the BR command and exiting, I found myself dumped back to basic then as well.
This was using the 5.22 NTSC Super Snapshot cart, in a TMP+REU config.
Wondering if anyone has gotten this to work before.
|
|
|
|
Post by Unbeliever on Apr 6, 2021 22:24:56 GMT
Keep in mind that everything that follows is from someone pretty dang new to TMP+REU and Super Snapshot, himself. Take all of the following with a couple tablespoons of salt...  Now then: when you're working with TMP+REU, it's constantly fetching 64k banks from the REU into the C64's main memory. (Technically, I believe it leaves the lowest 2k alone and fetches everything else from an REU bank.) One REU bank holds TMP and your source code, and gets pulled into main memory when you enter TMP to edit your code. Another REU bank holds your compiled code, and gets pulled into main memory when you launch your code after compiling. So any changes you make to C64 memory are easily lost -- and this might include wherever Super Snapshot is storing that "BR" setting. [Come to think of it, that specific interrupt vector might well be one that TMP is deliberately altering for its own purposes.] In any case, if you find out specifically what memory locations are altered by Super Snapshot's "BR" command, and what values they're being set to, I believe you can simply store those values into those locations at the start of your assembly code. Each time you compile and run, you'll be putting the right values in the right places, and get the functionality you want.
Another possibility -- you could use the Super Snapshot monitor to save off a tiny file with the right values in the right places for BR to work, and then use the Ram->Load command (backarrow, uppercase R, lowercase L) to load that file into the "compile to" REU bank once, at the start of each development session. Same difference.
NOTE: If you DO succeed in getting this to work, let me know how -- I've used the Super Snapshot monitor independently, but never as a debugger for code in TMP, and would love to know how to do it. |
|
|
|
Post by MeneerJansen on Apr 23, 2021 11:10:44 GMT
I use the same setup -- TMP+REU along with the Super Snapshot cartridge -- and just wanted to add a few notes. 1) I've had trouble with disk access unless I disable either the Super Snapshot "turbodisk", or the TheC64's own fast access feature. (I believe it's the two running concurrently that causes the issue -- has anyone else had this problem?) To resolve this, I just use the ">TD" command when first exiting to Basic from Super Snapshot. I have no such trouble w/ TMP, REU and Sup. Snapsh. It saves just fine to a SEQ text file if I use in TMP: "back arrow key" "W" (to write a SEQ to disk). I'm still on firmware 1.3.2 and I use the emulator from this forum (see www.lemon64.com/forum/viewtopic.php?t=76184). I made a snapshot of a disk with TMP on it with Winvice 2.4 (https://csdb.dk/release/?id=129317) with a REU and Sup. Sn.sh. activated. Renamed the snapshot to "TMP REU and Sup Snapsh.D64" and start that. |
|
|
|
Post by MeneerJansen on Apr 23, 2021 11:20:51 GMT
Have anyone had any luck using Super Snapshot's brk/monitor functionality? You can also start Super Snapshot's Machine Language Monitor by typing "@@mon" (without the quotes). Don't know if that's what you meant. |
|
|
|
Post by MeneerJansen on Apr 23, 2021 11:33:58 GMT
Keep in mind that everything that follows is from someone pretty dang new to TMP+REU and Super Snapshot, himself. Take all of the following with a couple tablespoons of salt... Now then: when you're working with TMP+REU, it's constantly fetching 64k banks from the REU into the C64's main memory. (Technically, I believe it leaves the lowest 2k alone and fetches everything else from an REU bank.) Yep that's about right. See my personal notes on TMP: pastebin.com/w8VCLbExOne REU bank holds TMP and your source code, and gets pulled into main memory when you enter TMP to edit your code. Another REU bank holds your compiled code, and gets pulled into main memory when you launch your code after compiling. So any changes you make to C64 memory are easily lost -- and this might include wherever Super Snapshot is storing that "BR" setting. [Come to think of it, that specific interrupt vector might well be one that TMP is deliberately altering for its own purposes.] In any case, if you find out specifically what memory locations are altered by Super Snapshot's "BR" command, and what values they're being set to, I believe you can simply store those values into those locations at the start of your assembly code. Each time you compile and run, you'll be putting the right values in the right places, and get the functionality you want. Another possibility -- you could use the Super Snapshot monitor to save off a tiny file with the right values in the right places for BR to work, and then use the Ram->Load command (backarrow, uppercase R, lowercase L) to load that file into the "compile to" REU bank once, at the start of each development session. Same difference.
NOTE: If you DO succeed in getting this to work, let me know how -- I've used the Super Snapshot monitor independently, but never as a debugger for code in TMP, and would love to know how to do it. In summary TMP + REU can use one or more 64 kB REU banks for: - the assembled program to be exchanged w/ RAM if you want to run it
- a safety copy of assembled source code
- a safety copy of your source code
- a copy the complete 64 kB of the C64's RAM in the state that it was in before you started TMP
See chapter F in my personal notes. |
|
|
|
Post by namrok on Apr 23, 2021 18:23:02 GMT
So I never did get SuperSnapshot to properly pull up the monitor when I use BRK in my assembly. Worked slightly better if I tried to set that configuration after I was already running my program. But exiting out of the monitor still crashed the program I was trying to debug. Also, pulling up SuperSnapshot wasn't helping me debug some of the things I wanted to debug, like the screen memory, since pulling up SuperSnapshot actually changes it.
I just wrote my own overloaded BRK IRQ function, printing out the registers at the bottom of the screen. Will likely expound upon the function to also print out monitored memory locations, and perhaps loop until a key is pressed as well. Or maybe dump the values to a bank of memory for later study. I'll try to remember to post it here if I ever get around to it.
|
|
|
|
Post by MeneerJansen on Apr 24, 2021 8:40:27 GMT
So I never did get SuperSnapshot to properly pull up the monitor when I use BRK in my assembly. Worked slightly better if I tried to set that configuration after I was already running my program. But exiting out of the monitor still crashed the program I was trying to debug. Also, pulling up SuperSnapshot wasn't helping me debug some of the things I wanted to debug, like the screen memory, since pulling up SuperSnapshot actually changes it. I just wrote my own overloaded BRK IRQ function, printing out the registers at the bottom of the screen. Will likely expound upon the function to also print out monitored memory locations, and perhaps loop until a key is pressed as well. Or maybe dump the values to a bank of memory for later study. I'll try to remember to post it here if I ever get around to it. I've never used the monitor from Sup. Sn. when a program was still a running. Now I understand why you have trouble using it. I was already glad that SS works in combination with a REU and TMP because some cartridges don't. |
|
