Tursi

The 9901 interrupt pin was an interesting gotcha too... I accidentally turned on interrupts on the joystick left line when I added the SID Blaster support to Super Space Acer. I didn't realize it was interrupts until I asked ArcadeShopper to try it and he reported that it lit up the PEB. Basically, I was turning on the SID blaster by writing to the keyboard column select at CRU 24. But, I accidentally wrote >24. The result was holding left would freeze the game while the console ROM tried to figure out which DSR asked for an interrupt. Since Classic99 didn't support 9901 pin interrupts, there was no real help there. >24 is 36, but the CRU pin space is only 32 bits long, and Classic99 also wasn't wrapping the address around in that space like it was supposed to. (Bit at address 4 is joystick left.) Soooo.. those two changes to the 9901 code came out of my needing several days to figure that out. Though it's kind of neat to know that yes, joystick and keyboard inputs can trigger interrupts.

This update is worth mentioning - file system fix. It's a gotcha. Classic99 399.069 This fixes a detection issue accessing DF128 headerless on FIAD if any part of your disk path contains a period (assuming an extension exists, which isn't allowed). It was checking the entire path instead of just the filename. Note you can always bypass that restriction using the ".?X" option (ie: DSK1.?X.WIN.EXE would allow opening an exe as DF128). Also: mute "Skipped 0 sentences on shut up" message (we don't care if it was 0) fixed case of DLL load on FilterDLL.dll and hq4xdll.dll for those running from case sensitive filesystems. (If you renamed the DLLs, you may have to rename them back). emit a warning in the debug log if loading a DSR to an invalid CRU base correct address wraparound in the 9901 address mapping add interrupt pin warning to debug log in the 9901 emulation (Classic99 does not support 9901 hardware interrupts) don't spam the same debug statement repeatedly to the log (note: no timeout. If you NEED to see a repeated statement, force another one in between. For instance, press Control to get the speech clear debug) also note the external debugger (debugview) is NOT filtered this way, so that you have best visibility there Given that bug has been in there since I first added DF128 headerless support, it's probably a pretty obscure case. But there was no help in the debug log when it happened, so worth fixing. As usual, the web site may require 24 hours to update but the download zip is uploaded (edit: looks like I got in right before the update ran ) https://harmlesslion.com/software/classic99 (Regarding the 3 uploads comment from way back, yeah. I had to push to git, then ftp the zip to my server, then go into my database update tool and write the update there. Now I just push to git and everything else is automated. )

I'll give these a try! As for the SYNTAX ERROR, you'll probably find all you needed was to insert a CALL INIT before calling CALL LOAD. (Edit) Impressive amount of work there! The Megaman sprite looks great, too!

Well, he won't get a thousand bucks for it. And if he does, I have two I'm not using...

I doubt the disk side is different, but I only have the one dump. It definitely follows the TI DSR, but in doing a direct compare just now, it doesn't directly compare. It's possible he reassembled it with his patches rather than just hacking the binary. (Given that he needed to free the last 512 bytes for the hardware interface, that makes sense.)

Well, I wrote literally 42 helpers for converting, massaging, and mangling VGM (and other audio) files, so let me have a quick play. They'll handle the noise pitch conversion for you or let you do it manually, and if you don't want to use my compressor the final intermediate format is a simple text file that should be easy to pack into whatever you are using. https://harmlesslion.com/software/vgmcomp2/ The VGM unpacker informed me one potential issue with re-tuning the noise: It seems like that's true only in selected parts though, as I test play it. (The 0 notes tuned output there is a bug, it still retunes all the noise). (Note it also converted the 50hz original for 60hz playback). My default converter in that case will keep the channel 2 frequency and map the noise to the closest fixed shift rate, so I went ahead and tried that out... So we can see that 3935 notes out of 8206 may have changed. If they are drum beats, we probably won't notice. If they aren't, we probably will. It's good for a little while, but about halfway through the song there are some long notes on channel 2 AND some long notes on the custom noise channel... and changing them to non-custom as the converter wanted to did not work. (Around 1:24). This is a bit of a tricky case. Most of the song is fine with the fall-back to fixed rates. But those places absolutely are not. So it would be necessary to either mute the noise channel during those areas, or deliberately detune channel 2, or live with the detuned noise. I don't know if there's a happy medium there. My tools would allow the detune of channel 2, and then overlay 2 onto the noise channel so that the prepare tool can make the right decisions. D:\new>d:\work\ti\vgmcomp2\release\scalepitch.exe 1.066667 bbcapple-palsms-3_2.vgm_ton02.60hz VGMComp2 Pitch Scaling Tool - v20210707 Opened channel 0: bbcapple-palsms-3_2.vgm_ton02.60hz Imported 12400 rows, scaling by 1.066667 0 notes clipped (lossy) 0 notes zeroed (lossy) Writing: bbcapple-palsms-3_2.vgm_ton02.60hz ** DONE ** But this was really really bad and immediately wrong, though, as soon as channel 2 kicked in. So I think the only answer, if using this source, would be to let the noise be slightly detuned during those long stretches. It would be correct everywhere else. There appears to be no need to mess with channel 2 vs 3 anywhere but those long sections, but that would require hand editting of the psg files to cut out just the parts to edit, so in the interest of speed, I went ahead and overlaid channel 2 on 3 (after undoing the pitch scale above). This means that both channels will have the same pitch so prepare doesn't try to remap the noise, while not interfering with the custom noise pitches while channel 2 is otherwise silent. (I had to make a new tool, I never thought of this case before): Also had to tweak the prepare tool to accept a case where channel 2 and noise were both playing but asking for the same shift count. Made it seem a lot happier (we preprocessed away a lot of the noises that were having trouble). Seems to sound okay though! I dunno. Sorry for the spam. I just wanted to take a stab and it, and it revealed a couple places I could do better, so was happy for that. bbcapple_vgmcomp2.zip

We are all building on the work that came before us - that's how we advance

DJ's here in Calgary, I did lunch with him once and saw some of his robotics projects. Oddly, he also knows one of the guys I worked with down in San Francisco at Neato. Small world!

It's almost certainly a cracked trace or solder joint somewhere, and so the >1100 disk DSR is never turned on. There's no need to format the card. In fact, if you do The CF7 will destroy the format when the TI powers on. I analyzed the startup sequence from a software point of view and documented it here: https://docs.google.com/document/d/1DxNAKxdgqQrBmYwBmFweYK8yHgpJK-peIHVxzQ9H25c/edit?usp=sharing Won't really help this problem, but for some of the myths it might.

Correct - this will also happen for CF cards it can't talk to properly. It sends a command at powerup and waits forever for a response. However I don't know too much deeper than that. I do have the DSR working in Classic99, but in looking at it, only the disk DSR is there. So I suspect you are right about there being a banked ROM. I guess all you can really do is check the solder joints going to the CPLD and to the flash chip. Basically it's decoding >1300 but not >1100.

Further research from GitHub on how developers are using its Copilot tools found that, on average, tasks can be completed up to 55% faster when assisted by AI. None of my programming friends whom I have talked to have yet been able to tell me a single use case for AI saving them time, save creating a code framework - a task that takes mere minutes anyway. I think the only people who are finding it creates the code faster are those who couldn't write it anyway, and there are no metrics at all about whether the code that was generated /actually worked/. Certainly think that someday it'll happen that this works. But the day is not yet over.

I missed this one, but I did see the 2017 one. My friend and I drove up to Oregon from California. He has sussed out a little field along a side-road he hoped we could park by long enough to watch. When we got there all the roadside stops were blocked by the police (as they were already full). We got on the side road and found the field he'd found on Google Earth had been blocked by the owners with signs posted not to trespass. So we kept driving. By fluke we saw a little sign that said 'eclipse parking, $20', so we followed that. A family had cleaned out their horse pasture and opened it up to people to park. For your $20 you got parking, cookies, fresh coffee and even a bathroom. I felt bad that they only got about six of us but it was such a relief and such a comfortable way to watch. I was impressed how quickly the air cooled and how the birds got quiet. I was very hesitant with the glasses until I trusted them, and I was really surprised that at the moment of totality it was suddenly too dark to see through them at all. Caution again as I looked without them, but then yeah. If I've ever had a religious moment in my life, seeing the corona was it. I didn't know how long totality was meant to be, so I kept checking for any hint of bright again with the glasses. I think we got just over 2 minutes. My buddy used a cheap camera to record the whole thing (we didn't know if it would fry the sensor but it was okay to lose this one). It captured the eclipse wonderfully, especially for what it was, but you can also see the shadow moving across the field of view on the ground and even in the sky, which is really cool. Uploaded it here. Especially if you view it in fast forward the shadows are easier to see.

Yeah, he's working on his playlist player first, so it may be a while. But I can certainly try to fix my bugs in the meantime. I haven't done much with XB, so I have to sort of work my way through it. I see the issue. STOPSN blindly overwrites the interrupt hook with whatever is saved, but if you never called SONGGO, then nothing was ever saved, so the TML interrupt is lost. It worked for me because I always tested the player first, violating my own instructions. The numeric overflow is because I forgot moving to high memory requires negative addresses, and I didn't test it. Apologies! I decided to go ahead and do it (sort of) properly. I never linked CALL LINK very much so I'm not quick at coding for it. But rather than forcing you to use these slow XB functions, we can speed it up a bit by adding a little more assembly. This now uses the pointer at >2000 to find the new table, so that should prevent too many dependencies. Senior_falcon, it does assume the first two instructions will remain the same LI/CI and pulls the addresses from those. Is that okay? So all the XB subroutines can be tossed - I've provided CALL LINKs which will be faster and take up less space: CALL LINK("STOPSN") - still the same function, but works correctly now and won't break your interrupts. CALL LINK("SONGGO",X) - X is the song index in the SBF file - 0 for the first one. There's no range checking - if you pass one that's too large it'll probably crash, so always save your code before you run it. X can be a variable or an inline number, but not an array. CALL LINK("ACTIVE",X) - X must be a simple variable (not an array). It will receive 0 if the music is not playing, or non-zero (usually 1, but I didn't check all cases) if it is. The enclosed zip file includes a TML program with a multi-song songbank for example. Hope this is fun! TMLSample.zip

I've been testing corn starch on my joystick to fill in the sticky bits. It's been working so far.

Yep. For the same reason that CALL SOUND takes HZ for the frequency. To put it in units more comfortable for humans. It still gets converted down to frames for time and ticks for frequency.