Tursi

My VGM toolchain is for conversion and playback, so you'd have to compose the music in a compatible format first. I don't know anything about Jumpman. Also not sure if you might be asking about another tool in this thread

The VDP registers aren't guaranteed on startup... something has to be setting those values. That said, now that I've actually had to look... the datasheet doesn't explicitly say and I have never run a system that doesn't init the registers before I get control, so I guess I can't prove it I believe ColecoVision carts that bypass the delay also bypass all VDP init, so could test the theory there...

Since you are using Classic99, make sure you checked the debug log for warnings after the operation.

I don't stream often, but when I do I'm usually doing development. Which means it's mostly code and might not be TI-centric. And my streams only stay up two weeks and are auto-deleted. But, if you want to follow - https://www.twitch.tv/tursilion

Hey, if we could slap an AtariSoft logo on them, I'd happily go for some new titles.

Good research, terrible reporting.

Yes, but support for full screen mode is limited to sympathy. But the gamebase projects wanted it. Make sure Classic99 is not running. Go into Classic99.ini under the [video] section and set "StretchMode=3" (0 is no stretch, 1 is GDI, 2 is DirectX, 3 is DirectX full screen. The resolution is set by "fullscreenmode", but set that inside Classic99 first and then exit. Or read the manual for the options.) In full screen mode you won't see the menu and won't have an easy way out. You can use alt+enter to go back to windowed mode, but of course on exit that will re-write Classic99.ini. Under the [emulation] section: Set "enableAltF4=1" to make Alt+F4 close the emulator. This is 0 by default and the keys are passed to the TI. Under [video] you can also set "LockFullScreen=1" to make alt+enter not toggle back to windowed mode. But then if you don't have enableAltF4 set there is literally no way to exit the application and you'll have to kill it. There's no way to access the menu in full screen mode.

Ah, I didn't understand what you were trying to get it. I just ran the code through the samples in the comment and you're right - it should be >>6. (I had no idea why you were talking about dumps, hehe. Should have just told me that the numbers in the comment don't math up!) That code's been untouched for probably better than a decade, but I'll go fix it.

Classic99 supports CRU switching up to 64k. It doesn't have a separate mode for it, it's piggybacked on the normal 8/9 modes.

Classic99 has thousands of lines of code. Bugs are guaranteed. I'm not really worried about accurately emulating dram decay until there is a widely used piece of software that requires it. And then I will note that software was a bad idea since it will fail on F18A machines. Still, that's a nice piece of investigation.

Robotron does hit the CRU in strange ways, but, it's been better than a decade since I looked at it. The 2 joystick version is my hack, I rewrote some of the input code. Maybe that affected it.

When you blank the screen, you're writing 0 to the VDP register, which also clears the 16k bit.

Interesting. But not interesting enough for me to dig into it. I'm kind of done with debugging other people's software for a few years. Sure, you can argue the bug must be mine cause hardware works, and I'd agree, but I guarantee it's some oddball behaviour that happens to work on hardware rather than was meant to work. Yes. Because you are trying to make sense of it as a single operation, but it's not. That address is not the address written to in 4k mode, because it's a row/column (not an address). That address is the address that data ends up at in 16k mode when it's written in 4k mode, because Classic99 doesn't emulate DRAM to the row/column level. So yes, it's bound to be a bit confusing! I'm not going to spend too much time worrying about whether that single sentence is technically accurate though. Sean Young's doc is the reference. The comments in Classic99 only have to be detailed enough for me to remember what I was talking about.

Yeah. The game starts with FIRE, not enter. It's a prototype, I guess that's one of the issues. Basically, it's DRAM. So it's addressed as a row, and a column, instead of the linear space we expect with SRAM or ROM. Setting 4k mode limits the number of bits used for each of those. The math that you copied out calculates a 16k address for that 4k representation. When I write data on a real console in 4k mode and read it back in 16k mode, it shows up as calculated. That's all I needed to simulate. That seems reasonable. I don't know enough about DRAM to answer that. I can only tell you it worked for the addresses I tested. I didn't test filling 16k mode, going to 4k mode, and then going back to 16k mode. But, I would be willing to bet all the data is still there. Not a large amount, mind. Sudoku crashes pretty good in Classic99: The debugger warns about the 4k set ("WARNING: Setting VDP 4k mode at PC >65C8"). And confirmed, the one-byte patch fixes it. Interesting. I'm sure I remember seeing this released - isn't this Sometimes99ers? I believe I implemented the 9901 timer for this title. (But, that was before I implemented 4k mode, so Classic99 wouldn't have caught it then.)

It's worth noting that the F18A will ignore the 4k bit, so software that messes around like that will operate with a flat memory space on that too. The emulation challenge comes from setting the VDP to 4k mode but having 16k attached to it. The bit changes the way VDP addresses are presented to the RAM chips, with the net effect being that data reads and writes to a different spot in the RAM chips. To emulate it in Classic99, I calculate a 16k address based on the way the address lines are presented in 4k mode. Comparing data written with hardware, it seems to work. I dunno about Sudoku, I don't have it. I always thought it'd be a good emulation trap though As far as Robotron goes, it messes with some rarely used CRU bits. I remember I had to update Classic99's CRU emulation to get it to run.