Jump to content


  • Content Count

  • Joined

  • Last visited

  • Days Won


Tursi last won the day on September 7

Tursi had the most liked content!

Community Reputation

4,546 Excellent

1 Follower

About Tursi

  • Rank
  • Birthday 11/29/1971

Contact / Social Media

Profile Information

  • Custom Status
  • Gender
  • Location
  • Interests
    Buy me a Kofi! https://Ko-fi.com/tursilion

    Or fill in my 'SurveyWalrus' and help choose my next task!
  • Currently Playing
    Current Project: Update TI and Coleco VGM compression and playback tool (Project 'ballp'). (and.. lots of RL work... ;) )
  • Playing Next
    Next project (per survey): Fixing up my Genesis bartop

Recent Profile Visitors

29,250 profile views
  1. It's difficult to debug from a couple of screenshots. Have you tried a debugger on the code to see where it fails? To me, this line says to look at your memory access patterns - something is being corrupted. Where do you store your runtime data? It's not in the supercart by any chance, maybe where the program sits?
  2. Your TI motherboard doesn't put out a strong enough signal for the FCC to find you with their radio sniffer from the street. It's unlikely it's even strong enough to get through the paper-thin wall to my neighbors. You can prove this for yourself. Tune an AM radio to a local station, and see how close you have to get to your open TI before you can hear it. Now my microwave, THAT throws off a hell of an interference pattern. The FCC can have it if they want it.
  3. 99/4A consoles, while built ruggedly for the minimum spec, do seem to vary a lot to the maximum spec. I've had quite a few VDPs that can't run without the VDP heat sink in place for more than a few minutes, and I've definitely run my plank with some VDPs without a heat sink for at least a few minutes. But I think it's safe to say that the heat sink is required in your case, and I wouldn't deliberately run long term without it.
  4. I learned a little more about that crazy DSR...
  5. Because you told it to. Look at your disk configuration for DSK3 - you have AutoMap DSK1 enabled. This option lets you run software that expects to run on DSK1 from other disks, by dynamically searching for and replacing such strings in the binary as it loads. I never considered the case you're in, but yeah, it's clearly not a good option to turn on if you are intentionally using all your drives. Turn it off. (As an addendum, that's exactly why the debug log spells out all the things it does on purpose )
  6. The Bug99 window is only useful if you use Thierry Nouspikel's Bug99 package for remote debugging.
  7. I plan to expand the visualizations when I get to 4.0, if I get there! The visualizations are fun, but I actually do use the heatmap for debugging, too - it's great to see when a program is in a tight loop or running away, and I used it a lot to get an idea of the memory access patterns of my VGM compressor.
  8. Even so, these regulations are for manufacturers... you don't have to worry about a knock on your door because you removed the RF shield. Not yet anyway. Weird_w does make a good point about the reverse though -- the shields also protect your machine from everyone else's noise. I haven't had any trouble with my plank TI though.
  9. I think the answer to your question is yes... tiles are the background 8x8 character patterns... Terminology is annoying.
  10. It's not a bug, it's just the default for your DirectX drivers when bitmaps are scaled with it. Some drivers do it, and some don't. I don't set anything special in the code for it and I can't even say how to turn it on or off for a particular driver. I usually tell people if they don't want it, to use GDI as that usually doesn't anti-alias the scaling. But to get it on a driver that doesn't normally provide, no idea.
  11. I'm just sticking my nose in here, but.. why are you doing RUN 500 instead of just RUN? (Oh, I see, it's part of the test )
  12. In earlier machines the 9904 also attached a heatsink, and even without it also runs pretty warm. But QI machines ditched the top shield entirely and the VDP just has a clip-on heatsink there.
  13. If you had all of the files in the same folder (_8, _9, _C), that would explain it working. If you look at the debug log (first place you should ALWAYS look for weird behaviour), you'll see that Classic99 is loading them ALL if you are using User->Open or drag and drop. If the right one loads last, then it works. The reason is the old C/D/G issue. Since User->Open is an automatic mode, Classic99 doesn't assume that it knows what all the files associated with one cartridge are, so it just tries them all, and loads any that it finds (even if they overlap). So, it looks for 3,8,9,C,D, and G versions of the filename passed in. So if you're in there making different versions of the ROM and testing in Classic99, make sure you change the filename as well as the last character, or put them in different folders, OR just use a Classic99.ini entry so the emulator doesn't have to guess.
  14. First, I ran the CF7 normally with a breakpoint on VDP reads from >3FFA, so I could see where the DSR does the lookup for DSK1. I don't follow the code that does the calculation, unfortunately, we'd have to work backwards, but the code that uses the calculation is here: 55DE D220 movb @>834c,R8 834C 55E2 0988 srl R8,8 55E4 0608 dec R8 55E6 0A18 sla R8,1 55E8 A220 a @>8358,R8 8358 55EC 0228 ai R8,>010d 010D > 55F0 06A0 bl @>4628 This puts the base address (>3FFA) into R8. The BL sets the VDP address and reads two bytes for return in R0. So with that in mind, I started up TML and put a breakpoint at >55F0. When I run TML with the CF7 in Classic99, I see all eight bytes at >3ff8 have been zeroed. That would of course be a problem... so in the debugger I manually added them back before the test. I should breakpoint anyway... and the address is >3FFA! and the disk access worked (remember I manually poked the values back in). So, I can take it back.. it likely IS the loss of those top bytes -- but they are all lost, not just the two header bytes.
  • Create New...