Classic99 Wigouts?

[JasonACT]

23 minutes ago, mizapf said:

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

1 & 2 do work on real hardware, + doesn't.

[Tursi]

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

 

Quote

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

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.

 

[Tursi]

13 hours ago, sometimes99er said:

I don't know why it has to do with the 4K selection, which I believe I never used. 

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

 

[Tursi]

10 hours 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.

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.

 

[Tursi]

10 hours ago, JasonACT said:

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 38.5 kB · 0 downloads

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.

 

[JasonACT]

8 hours ago, Tursi said:

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.

I'm not here to argue, your free time is yours and I'm not asking for anything.

8 hours ago, Tursi said:

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.

But the single sentence is actually accurate and correct...

8 hours ago, Tursi said:

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.

I'm not worried about decay either, and you're welcome to keep all the bugs, it was a conversation that digressed, but which I still found worth looking at.

 

Here is a small program that loads my snapshot of the 16KB memory while in 4KB mode and makes sense of it, using your algorithm, but with my bug-fix (changing the shift >> 7 to be 1 less):

It now finds no mismatches in the dump, where there were thousands with your original >>7.

 

That's all 

[+hloberg]

while were on the subject is there a way to start Classic99 full screen? minor quibble having to full screen manually but I thought I'd ask to save one step.

[Tursi]

13 hours ago, JasonACT said:

Here is a small program that loads my snapshot of the 16KB memory while in 4KB mode and makes sense of it, using your algorithm, but with my bug-fix (changing the shift >> 7 to be 1 less):

It now finds no mismatches in the dump, where there were thousands with your original >>7.

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.

 

[Tursi]

5 hours ago, hloberg said:

while were on the subject is there a way to start Classic99 full screen? minor quibble having to full screen manually but I thought I'd ask to save one step.

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.

 

 

 

 

 

[+OLD CS1]

49 minutes ago, Tursi said:

Yes, but support for full screen mode is limited to sympathy.  But the gamebase projects wanted it.

Well, also kiosk mode.  You are a generous benefactor.

[+Retrospect]

3 hours ago, Tursi said:

you can also set "LockFullScreen=1"

Yep.  I found this option and then had no idea how to get out of it.  Fingers performing acrobatics on keyboard until I pressed alt escape or something and had to right click kill 😂

[JasonACT]

On 8/29/2023 at 7:56 AM, Tursi said:

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.

Well, I wouldn't guarantee that myself:

 

 

You are hard-coding CRU read values here, that in some cases are expected to be in the "other" state by Robotron, making it fail.

 

Removing the cassette if-test here allows "the last written value" to be returned, like it does on a real console, and the game's keyboard routine will start to work properly.  I'd say, the oddball behaviour here, is the emulated '9901 not behaving like a real one.  It could be argued as to why they read 4 unneeded extra CRU bits, but they did their homework.

[JasonACT]

On 8/28/2023 at 10:41 PM, JasonACT said:

1 & 2 do work on real hardware, + doesn't.

Silly me...  <Shift>= doesn't work, but "=" alone does.

[Tursi]

14 hours ago, JasonACT said:

Well, I wouldn't guarantee that myself:

 

 

You are hard-coding CRU read values here, that in some cases are expected to be in the "other" state by Robotron, making it fail.

 

Removing the cassette if-test here allows "the last written value" to be returned, like it does on a real console, and the game's keyboard routine will start to work properly.  I'd say, the oddball behaviour here, is the emulated '9901 not behaving like a real one.  It could be argued as to why they read 4 unneeded extra CRU bits, but they did their homework.

Good research, terrible reporting.

 

[JasonACT]

Meh...

 

Classic99 QI399.064:-

Comparing files classic99.exe and CLASSIC99O.EXE
00020D3C: 90 0F
00020D3D: 90 86
00020D3E: 90 5D
00020D3F: 90 FE
00020D40: 90 FF
00020D41: 90 FF