eswartz / emul Goto Github PK

V9t9 video updating is being done at times and rates totally different from what the emulated machine expects, so effects like scrolling can become obvious in V9t9. These updates should track the emulated VDP interrupt instead.

From @endlos99 's report in #2:

"Well, what is "smooth"? To me, it feels choppy in that the Parsec ship jumps and/or keeps moving after I release the key, and the landscape scrolling looks "wobbly", i.e., the scenery often grows and shrinks during scrolling -- not very profound, but noticeable. There are no such effects in MESS."

From me:

I agree about the landscape choppiness. V9t9 tries to avoid eating up CPU by making video updates to the entire screen according to arbitrary host CPU timing, whereas a game like Parsec assumes the video is being updated row-by-row at a given rate and the top row starts being updated in lockstep with the video interrupt, thus giving it time to scroll the landscape "before" the monitor shows the changes. I think MESS tries the row-by-row approach, but it's much more CPU-intensive, and my goal (as you've noticed) is that an emulator asking like an ancient machine will actually use less CPU than a modern machine. ;)

That's just a long-winded way to say, I guess I need to pay some more attention to doing that video synchronization more correctly.

From RvK:

1.      Ms. Pacman  starts, but then hangs the system

2.      Jumpy  as well it hangs once loaded

>> for item 1 and 2 I have added the ASSMDS1.DSK  (to load via Extended Basic,  

    But the same happens when loading the .BIN (module file) also attached

(but in the previous V9T9 it is working)

From Ronald van Kleunen:

When I have many modules of “Miliken” it always starts the 1st one in the list.

The same issue with these modules (“Parker Brother’s Game is shown as the option after the TI-titlescreen)

(Frogger, QBert, Popeye) – also attached

I was documenting the way joysticks can be emulated with the numeric keypad when I found that the support is broken:

• keys/fire are sticky (need '5' to reset)
• joystick 2 can't be used this way since shift-keypad-5 not supported
• Num Lock must still be on for this to work

Screenshots taken by the program version of 23. May 2013 have wrong colors. I attached a screenshot of the start screen. This looks not like that what I can see in the emulator itself.

V9t9 has a usability issue in the absence of certain DSR ROMs. That is, the Device Selector allows you to enable support for things that reference missing ROMs, and the UI gives no hints about this. So you can try to set up disk stuff or RS232 stuff, which will never work (with the only clue being the italicized entries in the Setup dialog or the popup indicators about missing ROMs at time of access).

Instead, the Device selector and/or device buttons should be disabled or visually indicated to be in an error state if they cannot function due to missing ROMs.

The Bigfoot cartridge exhibits some bugs if the emulator does not properly ignore the LSB of the PC.

By Tursi / Mike:

Found it. I’ll write up a technical explanation that you can share, please.

Bigfoot’s a somewhat buggy program that relies heavily on undocumented side effects. I wonder if it would work at all on a 9995? It’s also very strangely programmed, and mixes code and data indiscriminately.

The good news (from my perspective) is that this answers a hardware question I was waiting to get home to test, about whether the CPU preserves the LSB of the address counter. It does not!

The problem is that the code is very fond of mixing up code and data addresses. In particular, the text display routine emits a string of text, then branches to the address immediately after the text. This address is VERY frequently odd. On the real 9900, the least significant bit is ignored, and the code is executed correctly. This is also true in Classic99 (and JS99er and likely V9T9).

Where this falls down is here:

A3C9 06A0 bl @>a89c

A89C C03B mov *R11+,R0

A89E C0BB mov *R11+,R2

A8A0 C3CB mov R11,R15

A8A2 06A0 bl @>a9dc

A8A6 D83F movb *R15+,@>8c00

This is a little confusing, but what happens is that a block of code was executing at odd addresses (A3C9). This was working correctly and fetching the correct (even) words, and everything was okay. Then the BL occurred.

R11 got the /odd/ address for the return address. Again, this would normally be no big deal, because the CPU fetches would still get the correct even addresses. The MOVs at A89C and A89E both do the correct thing with the odd R11, fetching the correct even data. Then we move R11 to R15 so we can branch to A8A6, which is the actual display routine.

Now R15 is fetching data with a 1 byte offset, and because it’s using bytes, we see that onscreen. Worse than that, at the end of the display loop, this happens:

A8AA 0602 dec R2

A8AC 15FC jgt >a8a6

A8AE 058F inc R15

A8B0 045F b *R15

A3E6 A89C a *R12,@>0128(R2)

A3EA 0011 data >0011

A3EC 484F szc R15,@>5720(R1)

R2 correctly counts down the number of bytes to display, then we increment R15 one last time and branch directly to it! The problem is, because we started off by one, we’re actually now off by two, and we branch to the wrong address – we should have branched one word earlier (because the code was expecting to end up with an odd number, and have it ignored by the system). This is why there is an illegal opcode at A3EA, it’s actually part of a different instruction.

The fix is simple – the Program Counter in the 9900 is 15-bits wide and should never include the LSB. It’s funny this topic came up recently at AA since MESS apparently has it right. :) To recap: the bug is that an odd PC is being stored in R11 for BL (presumably BLWP and interrupt calls would have a similar bug). The best fix is to just strip the least significant bit from the PC in all cases.

It is highly likely, though I don’t have hardware to test, that the Workspace Pointer is also 15 bits wide.

Please feel free to share this with the other affected emulator authors.

From RvK:

. Also I saw that the “P-code GROM” file had to be renamed otherwise it does not load

(for people migrating from 1 version to the latest one “pcode_g0.bin” to “pCodeGroms.bin”)

Hello,

Starting v9t9 on Ubuntu 14.04 fails with this error message:

There is an incompatible JNA native library installed on this system.
To resolve this issue you may do one of the following:

• remove or uninstall the offending library

• set the system property jna.nosys=true

• set jna.boot.library.path to include the path to the version of the
  jnidispatch library included with the JNA jar file you are using

  at com.sun.jna.Native.<clinit>(Native.java:142)
  at ejs.base.sound.AlsaLibrary.<clinit>(AlsaLibrary.java:56)
  at ejs.base.sound.AlsaSoundListener.<init>(AlsaSoundListener.java:52)
  at ejs.base.sound.SoundFactory.createAudioListener(SoundFactory.java:35)
  at v9t9.gui.sound.JavaSoundHandler.<init>(JavaSoundHandler.java:61)
  at v9t9.gui.client.swt.BaseSwtJavaClient.<init>(BaseSwtJavaClient.java:107)
  at v9t9.gui.client.swt.SwtLwjglJavaClient.<init>(SwtLwjglJavaClient.java:22)
  at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
  at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57)
  at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
  at java.lang.reflect.Constructor.newInstance(Constructor.java:526)
  at v9t9.gui.client.ClientFactory.createClient(ClientFactory.java:48)
  at v9t9.gui.Emulator.create(Emulator.java:228)
  at v9t9.gui.Emulator.main(Emulator.java:192)
  at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
  at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
  at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
  at java.lang.reflect.Method.invoke(Method.java:606)
  at v9t9.launch.Launcher.launch(Launcher.java:156)
  at v9t9.launch.Launcher.main(Launcher.java:50)
  

When I add -Djna.nosys=true to v9t9.sh, then I get this error message:

ALSA lib pcm.c:7986:(snd_pcm_set_params) Unable to get period size for PLAYBACK: Invalid argument

Java version:
tiger /opt/v9t9 > java -version
java version "1.7.0_79"
OpenJDK Runtime Environment (IcedTea 2.5.5) (7u79-2.5.5-0ubuntu0.14.04.2)
OpenJDK 64-Bit Server VM (build 24.79-b02, mixed mode)

From @endlos99's feedback:

""" To me, it feels choppy in that the Parsec ship jumps and/or keeps moving after I release the key. """

I think I messed that up when attempting to provide more reliable keyboard emulation for programs that use text input. Thus, keys held down, like arrow keys here, will be doled out long after you release the key.

I can't reproduce this. That's just the way Parsec works (again, verified with v9t9 v6.0 for DOS). The left/right arrows provide a thrust that accelerates the ship which then retains its velocity. As for up and down, I don't see that acting any differently than expected. I need to put on my scrutinizing glasses before accepting things as bugs.

After setting up an installation of v9t9 on OSX with a Retro-bit Atari USB (I couldn't find a TI replica, sadly), I was disappointed to discover that the emulator seems to believe the joystick is stuck pressing "left". Using Enjoyable, I was able to emulate keypresses using the joystick (so I know the joystick is working correctly). This is not an ideal solution however, because in addition to needing to be enabled before each play session, it only appears to support simulating presses and not holds. Games like Parsec and Burgertime quickly become tedious if the player needs to pump the joystick in order to move. 😉

Is there a way to change the default mapping, or perhaps calibrate the joystick?

In the Jul 21 release I changed the modules setup dialog a bit. It seems that module name editing and context menu access work much worse in Windows than on Linux, making it impossible to rename them.

Is it possible to show just the emulated screen without the gradient bars and icons that really clash with the original interface?

In other words, I want to make this:

Look like this:

Sorry if this is already possible and I missed it in the doc. If it's not possible now, maybe it could be implemented to toggle with a keystroke, or be available as a menu option.