Classic99 Wigouts?

[unhuman]

Anyone else get the issue where the keyboard gets stuck (with some key pressed)? Happens to me a lot... Any way to reset the keyboard w/o bouncing Classic99?

 

Thanks - Howie

[matthew180]

Are you running the latest version (V340A)? There was some known issues with the keyboard, but most should have been fixed in the latest release a few weeks ago.

 

Matthew

[unhuman]

Yep, QI340a

[Tursi]

Usually this happens if you use a keyboard shortcut to take focus away, for example, Alt+Tab -- Classic99 sees the alt and the tab down events, but Windows never delivers the up events because it doesn't have focus anymore (now that I think about it, it would be easy to clear the keyboard state when focus is lost, let me take a note on that and I'll code up that fix).

 

If you are running CPU overdrive, the keyboard repeat delay ends up way too short, and my workaround for that doesn't work in Extended BASIC, so you get massive keyboard repeats, although that at least should respect the keyboard.

 

There's no explicit reset built-in, but tapping the key that is repeating should stop it. Tapping Enter should clear any stuck meta-keys (control, alt, shift).

[unhuman]

Thanks I'll try those tips!

[Tursi]

I couldn't reproduce, and the fix I had in mind is already in the code... that said, if you take focus away (click on some other Window), that should completely reset the keyboard code and stop whatever it's doing.

 

I'd like to know what's happening so I can fix it someday...

[Retrospect]

On 4/16/2010 at 9:10 AM, Tursi said:

I'd like to know what's happening so I can fix it someday...

Did this get fixed? 

[Tursi]

7 hours ago, Retrospect said:

Did this get fixed? 

In the 13 years since this thread started, I haven't heard it causing any more serious issues nor had it myself.

 

[JasonACT]

There's a MAME Cart file called Soduko.zip, probably written using an emulator, it sets 4KB RAM mode on the 9918A during VDP memory setup, then goes back to 16KB while running.  Works fine on an emulator, but doesn't work very well on real hardware...  Just FYI.

[Tursi]

5 hours ago, JasonACT said:

There's a MAME Cart file called Soduko.zip, probably written using an emulator, it sets 4KB RAM mode on the 9918A during VDP memory setup, then goes back to 16KB while running.  Works fine on an emulator, but doesn't work very well on real hardware...  Just FYI.

Classic99's 4k mode matches hardware. But... while it's an interesting tidbit, was there something you wanted me to do about it?

 

[+mizapf]

I found soduko.rpk in my collection (as a demo only), and as far as I know, nobody really cared about fixing the 4K mode in MAME's emulation of the VDP yet. That is, it may falsely run on MAME when it is expected to crash.

[JasonACT]

I'm in two minds about it, on one hand "meh", but on the other, it doesn't help developers to produce "working" code.  Of course, since I'm trying stuff out on "new hardware" it's things like this that need to be investigated.

 

But then we have "Robotron: 2084" which does work (after I trimmed off the extra zero bytes from end of the files, since I pre-check D.bin files are 8KB max in the loader) on real hardware, but I can't get past the 2nd "Press ENTER" screen on the 2 GameBase emulators.  I do see a lot of threads here talking about that one though.

[Tursi]

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.

 

Edited August 27, 2023 by Tursi

[JasonACT]

I've got Classic99 QI399.064 and it doesn't get past the "press ENTER" for Robotron?

 

That "rotated" bit on the end also gets right-shifted into the "static" bits area (the top bit making up the 3 in 0x203F) meaning only 8KB (or less) is addressable?

And yes, there's a soduko & sudoku in MAME/GameBase, where the latter seems to be more complete (while still a demo) but has the same issue on real hardware, and both are easily fixed by flipping a single bit in the register constant, to keep 16KB mode...

Maybe 4KB mode on the 9918A doesn't perform the refresh cycle on the full 16KB area though?

sudoku.zip

[Tursi]

19 hours ago, JasonACT said:

I've got Classic99 QI399.064 and it doesn't get past the "press ENTER" for Robotron?

Yeah. The game starts with FIRE, not enter.  It's a prototype, I guess that's one of the issues.

19 hours ago, JasonACT said:

That "rotated" bit on the end also gets right-shifted into the "static" bits area (the top bit making up the 3 in 0x203F) meaning only 8KB (or less) is addressable?

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.

19 hours ago, JasonACT said:

And yes, there's a soduko & sudoku in MAME/GameBase, where the latter seems to be more complete (while still a demo) but has the same issue on real hardware, and both are easily fixed by flipping a single bit in the register constant, to keep 16KB mode...

That seems reasonable.

19 hours ago, JasonACT said:

Maybe 4KB mode on the 9918A doesn't perform the refresh cycle on the full 16KB area though?

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.)

 

 

[JasonACT]

4 hours ago, Tursi said:

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.

I see.  I think I was confused because the routine uses the 2 high bits that are not used for addresses in the 4KB range.  I.E. passing in 0x3FFF yeilds 0x3FBF as an answer (the zero bit in 0xB here is always zero, making the code comment "There are no fixed bits" more confusing).

4 hours ago, Tursi said:

Yeah. The game starts with FIRE, not enter.  It's a prototype, I guess that's one of the issues.

On real hardware, pressing ENTER works.  In fact, pressing Enter on my USB keyboard with my Pi Pico running my LOAD interrupt patching routine works too.

 

4 hours ago, Tursi said:

Sudoku crashes pretty good in Classic99:

Ah, I see now, you have to turn off the 80 cols hack to get that.

 

I'm not sure who it belongs to, sorry.

 

[Retrospect]

3 minutes ago, JasonACT said:

I'm not sure who it belongs to, sorry.

I can tell that's @sometimes99er 's game just by the "Sudoku" graphic.  
Watch me get that wrong now. 

[sometimes99er]

Yeah, I did it back in 2006. It was only a demo. I think the first crash was due to me not getting certain things on even adresses. At least MESS somehow allowed for this back when. It crashed similarly on real hardware - Mantadoc made and tested as cartridge. I don't know why it has to do with the 4K selection, which I believe I never used. And yes, I tried to use the timer (9901), and Tursi was quick to alter his emulator to allow for that.
 
Two years later I did a TI blog on Sudoko with much better graphics. My active list as of now includes this and 21 other TI game projects. 🙂
 

[sometimes99er]

How do you reference an AtariAge user correctly ?
 

[Retrospect]

1 hour ago, sometimes99er said:

How do you reference an AtariAge user correctly ?
 

If I understand your meaning,  put an asterisk before the name of the person you want to highlight and reference. By the time you've spelled most of their name it should come up in a little suggestion box. 

[Retrospect]

@sometimes99er ... not asterisk, sorry , the " @ "      symbol  .       Silly me.  

[+mizapf]

4 hours ago, JasonACT said:

On real hardware, pressing ENTER works.  In fact, pressing Enter on my USB keyboard with my Pi Pico running my LOAD interrupt patching routine works too.

Interesting - on MAME, ENTER does not work either, but Fire button. Are there different versions of Robotron? I don't believe we have the exact same flaw in our emulators.

[JasonACT]

9 hours ago, Tursi said:

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.

Well, they are basically a bunch caps, and 40 year old ones (like I have here) really do need to be refreshed otherwise they lose their charge.

 

The .zip contains 3 files, test 1, 2 & 3.

 

1 is a VDP dump after setting each double byte (word) to their (even) address value

2 is going into 4KB mode and immediately reading back the 16KB in that state before anything is lost

3 is waiting 10 seconds while in 4KB mode, then switching back to 16KB mode and seeing what remains

 

I, personally, am not a betting man.  And I think you may have a bug.

testvram.zip

[JasonACT]

20 minutes ago, mizapf said:

Interesting - on MAME, ENTER does not work either, but Fire button. Are there different versions of Robotron? I don't believe we have the exact same flaw in our emulators.

I got it from the GameBase download, it has the same overflow of 00 bytes that's been talked about here, so I don't think it's a different version?

[+mizapf]

I just downloaded Gamebase and picked both Robotron RPKs from it (2048 and 2j). The "2 Joystick" version does react to Enter, but not really fast; I have to hold it down for a while (about a second). The 2048 version does not react at all to Enter (on MAME).

 

Edit: I just noticed that the other keys ("2" for 2-player game, "+" to change level) do not work on MAME either.