Playing Robotics on ZX UNO+

[Juan F. Ramirez]

I'm trying to load Robotics by Ocean (an old Z80, the TAP file in the archive and a Z80 file made from the TZX file) but when the game starts, I can only shoot, I can't move the character.

The keys are Fire: A, Up: S, Down: X, Left: N, Right: M.

However, the first Z80 file mentioned above runs OK in my Spectrum Plus and some emulators. Only the ZXUNO+ has problems in running it. I'm in 48k mode.

Any ideas?

[Pegaz]

I tested briefly on the RVM emulator and movement keys really don't work !?
I guess the disabling all various peripheral devices are needed, which "Uno" uses by default and try the equivalent of the basic 48K machine.
Tried to do it in the Uno Setup menu and LFN Browser config screen (Shift+C) but it didn't work.
Also, disabled DivMMC completely and loading the game from audio source, but didn't succeed.
At the moment I can't try on my real Uno+ setup, with azesmbog/kyp cores, which are the most accurate and closest to real Spectrum.
If it doesn't work there either, then I don't know what is the cause of this...

[Alcoholics Anonymous]

It's seeing a Kempston joystick -- if a kempston is detected the keys don't work but the joystick will. On the Spectrum Next, disabling Kempston allows the keys to work.

[Pegaz]

The problem is, how to disable Kempston or some other joystick interface in ZX Uno setup menu, because there's no Disable option, only another interface can be selected (Kempston/SJS1/SJS2/Protek/Fuller).
However, the LFN browser, has the option to set joysticks to "None" in the config menu, but this still didn't solve the problem.
Very interesting, indeed...

[Juan F. Ramirez]

Anyway, as I said before, the game works in my real Spectrum but in a weird way, for example shootings I don't make appear in a some place of the screen... even the game once crashed displaying this Basic error message (it has the spanish rom):



Won't be the problem of this game that it has certain bugs?

[Alcoholics Anonymous]

Testing on a Spectrum Next and using the files from here, one is "frenzy.z80" and that encodes a 48K spectrum in the z80 file. The Next will run the program as a 48K and that works fine with key control after disabling the Kempston joystick. I played a few screens and nothing unusual seemed to happen except one of the robots seemed invincible. It took four shots and still didn't die before I died to something else.

The tap file "robotics.tap" I loaded as 48K and that worked the same as the z80 after disabling the Kempston. As a 128K, the game had to be loaded in USR 0 mode. After doing that and disabling Kempston, key control worked and I didn't run into any crashes after playing a few screens. It seemed to run the same as under 48K.

Did you try USR0 mode on the Spanish 128K if loading from tape? If you're loading with a divmmc I guess that's USR0 mode already. It's possible the game could crash if the roms have been modified (the +2/+2A/+3/Spanish128 contain differences from the Sinclair 128K roms). If it's still a problem under USR0 then I can try to locate the Spanish roms and see if I get to the same place as you.

The problem is, how to disable Kempston or some other joystick interface in ZX Uno setup menu, because there's no Disable option, only another interface can be selected (Kempston/SJS1/SJS2/Protek/Fuller).
However, the LFN browser, has the option to set joysticks to "None" in the config menu, but this still didn't solve the problem.
Very interesting, indeed...

Yeah it's going to depend on what it means to change the joystick selection in the hardware. On the Next, disabling something is the same as if the hardware is unplugged. But maybe the Uno hardware is just changing where the joystick data is directed but the ports are still active? So even if Kempston is not selected port 31 is still returning a "no directions" result? If you do a "PRINT IN 31" from basic after Kempston is not selected is the result 255 (no kempston) or something like 0 (Kempston there but no directions)?

[Pegaz]

[mention]Alcoholics Anonymous[/mention]

Yes, you're right, even when Kempston isn't selected or even disabled, Port 31 always shows 0.
As far as I remember [mention]azesmbog[/mention] used its customized 48K Uno core, for a successful Timing Test, without any peripherals involved.
I believe that version would work well... or there's maybe another way to overcome this...

[Alcoholics Anonymous]

As far as I remember @azesmbog used its customized 48K Uno core, for a successful Timing Test, without any peripherals involved.
I believe that version would work well... or there's maybe another way to overcome this...

I think it's worthwhile to bring to Miguel's attention. Something like this is rare but it is not the only case. If you want to reach for 100% compatibility you can't change a single byte in the roms and you can't leave devices permanently "plugged in". In the verilog/vhdl it's fairly easy to "unplug" by including the enable bit in the port decoding which should be a very quick work for Miguel.

[azesmbog]

@azesmbog of course can turn off the hell of a Kempston joystick, but give it a "wrong" file that does not work correctly. For check.

[desUBIKado]

@azesmbog of course can turn off the hell of a Kempston joystick, but give it a "wrong" file that does not work correctly. For check.

Hi azesmbog,

The programme under discussion is Frenzy (a.k.a. Robotics): https://spectrumcomputing.co.uk/entry/4 ... rum/Frenzy

Use the .Z80 version to perform the test.

If you are strong for it and want to go one step further, there is another problem with the kempston protocol implementation in the mcleod_ideafix core. You may notice that if you load the NONAMED game ( https://spectrumcomputing.co.uk/entry/3 ... um/Nonamed ) and use the kempston joystick, the main character keeps kicking continuously. This happens on the mcleod_ideafix core and the ZX Spectrum Next core. It does not occur on the Kyp core or the MiSTer or MiST core.

[Alcoholics Anonymous]

You may notice that if you load the NONAMED game ( https://spectrumcomputing.co.uk/entry/3 ... um/Nonamed ) and use the kempston joystick, the main character keeps kicking continuously. This happens on the mcleod_ideafix core and the ZX Spectrum Next core. It does not occur on the Kyp core or the MiSTer or MiST core.

This one has to do with the game using the wrong port number ($DF) to read the kempston joystick ($1F). If you poke these addresses after loading the game, kempston will work properly:

poke $9777,$1F
poke $977D,$1F

The game is depending on the partial decoding of the original interface to work at all. I don't know why the programmers would use a port other than the one documented by Kempston ($1F), especially in 1987 when this was very well known.

The Mister core (and probably others that are working) are only looking at the bottom six bits of the port address for Kempston ( https://github.com/MiSTer-devel/ZX-Spec ... m.sv#L1005 ). This means that on the Mister, Kempston responds on ports $1F + $40 * N (N = 0,1,2,3) since it's only looking for bit 5=0 and bits 4:0=11111.

The zx next core is looking for exactly port $1F and likely the uno core is as well. Some modern day kempston interfaces are also fully decoding the address to $1F and will likewise not work with this program. I'd encourage you to report problems like this to the zx next repository and the zx uno repository when found as problems like this one are very easy to fix.

The incomplete decoding of a port as done in the Mister (and original Kempston interface) leads to increased problems of peripheral compatibility. Any device that uses the same ports as any that the Kempston responds on would not be able to work when plugged into the machine at the same time as the Kempston joystick. On a Mister or Mist, that's not so much a problem because the set of peripherals "plugged in" is static and is wholly controlled by the fpga designer. If you have a machine that allows random stuff to be plugged in via a physical expansion port, this relaxed decoding decreases compatibility. For the zx next, port $DF is already a write-only dac port address (corresponding to a real dac interface in Eastern Europe) but it can co-exist as read-only for Kempston. However, there are known peripherals responding on port $DF so allowing that all the time will mean those couldn't be plugged in. So likely I will add $DF and only $DF for Kempston but it can only work when the internal dac port is enabled.

I think there's a reason that $DF was used in this game and not the many other ports the original Kempston responds on so I think specifically allowing $DF and $1F only will catch these sorts of cases. At least until a counterexample comes along for which a more complete solution would have to be found.

[Pegaz]

As far as I remember @azesmbog used its customized 48K Uno core, for a successful Timing Test, without any peripherals involved.
I believe that version would work well... or there's maybe another way to overcome this...

I think it's worthwhile to bring to Miguel's attention. Something like this is rare but it is not the only case. If you want to reach for 100% compatibility you can't change a single byte in the roms and you can't leave devices permanently "plugged in". In the verilog/vhdl it's fairly easy to "unplug" by including the enable bit in the port decoding which should be a very quick work for Miguel.

I'm not sure if Mcleod is a member here but, it would be good to do this fix for official Spectrum core.
In the meantime, I hope that azesmbog will do some magic and help us solve this completely.
The good thing is, that Juan noticed this issue, I rarely play such obscure games, but they seem to be the best test examples.

[azesmbog]

the game is really incomprehensible and this problem is not worth a damn. With the Kempston joystick, everything is fine Connect the joy - and you will have joy
Well, if we proceed from 100% compatibility - then yes, as a test of the stupidity of the programmers of this game - then it's ok
Of course, I killed a lot of time, between other things, but a couple of lines were enough to remove this problem. But Bob's browser is also required to disable joysticks in it.
As such, there is no bit here that disables port 31, for a lot of other things - not for Kempston.
I had to go the other way.
ZXDOS + now works correctly. When you turn off Kempston, the number 255 is read from the port.
I don't think that because of such a trifle it is necessary to recompile the core for ZXUno

[Pegaz]

Well, Robotics isn't important at all, but my concern is, does this issue affect some other games ?
If there are more such examples, then we still have a certain problem, here ...
I'm glad you fix this on ZXDOS+ and as far as I'm concerned, if this behavior doesn't show up on your or kyp Uno core, then this problem is solved for me.
Otherwise, I think that fix for zx-uno is necessary after all...

[azesmbog]

https://drive.google.com/file/d/1iHuDDF ... sp=sharing
Just check it yourself.
I have not tested on ZXUNO. Added two lines and compiled.
But all the same, since the joysticks cannot be disabled in the BIOS, but only changed, you must also use Bob's browser and disable both joysticks via the Ctrl + C settings menu

[desUBIKado]

Well, Robotics isn't important at all, but my concern is, does this issue affect some other games ?
If there are more such examples, then we still have a certain problem, here ...
I'm glad you fix this on ZXDOS+ and as far as I'm concerned, if this behavior doesn't show up on your or kyp Uno core, then this problem is solved for me.
Otherwise, I think that fix for zx-uno is necessary after all...

I have commented on the ZX-Uno forum about what is written in this thread. We'll see what response we get.

[Alcoholics Anonymous]

Just to add, this use of port 0xDF instead of 0x1F for Kempston seems like it might be more than rare. You can likely find examples in several threads here complaining about erratic Kempston behaviour in emulators like this one:

viewtopic.php?f=23&t=2336

I only checked Astro Marine Corps but that one is also using port 0xDF and is the reason it is not working properly in ZX Spin and my copy of a not-quite-up-to-date SpecEmu.

I do think 0xDF is the only off-beat port of the many the original Kempston interface will respond to because it is following Sinclair's original port decoding idea of using one single 0 bit to identify a peripheral. That's the only reason I can think of that someone would use a port address other than what Kempston told them to use.

[azesmbog]

Otherwise, I think that fix for zx-uno is necessary after all...

Please check if it doesn't bother you.
And another request.
I understand this is your video?
https://youtu.be/Ix9Wy2jhDwI
Another request - is it possible to make a video of this test again, but for a longer time and with good quality and not on the side of the screen? Thanks.

[Pegaz]

Otherwise, I think that fix for zx-uno is necessary after all...

Please check if it doesn't bother you.
And another request.
I understand this is your video?
https://youtu.be/Ix9Wy2jhDwI
Another request - is it possible to make a video of this test again, but for a longer time and with good quality and not on the side of the screen? Thanks.

Yes, that's my video.
I hope these days, I can test your new test core and this snow test again.
Currently, "Uno" and other ZX hardware arent available to me... moving is quite a mess...

[desUBIKado]

In this moment Telegram group of ZX-Uno is on fire with this issue. Azesmbog, we miss you

[azesmbog]

In this moment Telegram group of ZX-Uno

There is still no telegram yet. It's not time yet%

I hope these days, I can test your new test core and this snow test again.

I will look forward to it !!
And in order not to get up twice - check and make a video
modifications of this test.
https://drive.google.com/file/d/1Jhc_ts ... sp=sharing

[Pegaz]

I hope these days, I can test your new test core and this snow test again.

I will look forward to it !!
And in order not to get up twice - check and make a video
modifications of this test.
https://drive.google.com/file/d/1Jhc_ts ... sp=sharing

Ok, finally managed to unpack my stuff and among them, my good old rubber Speccy to perform these two tests you asked.
It's more than three years, since I didn't turn it on and the old keyboard membrane seems to be no longer completely working.
Fortunately, the Load "and Enter keys worked, so here is the video for both tests, as I promised:
https://drive.google.com/file/d/1FZ-6Mx ... sp=sharing
https://drive.google.com/file/d/1Q4FxJt ... sp=sharing
Recording with my daughter's tablet in HD resolution from LCD TV, through RF output.
I used Spectrum 48k Issue 3, without any peripherals attached and both test programs have loaded with Android smartphone and PlayZX app.
I hope it will be useful, fiddling with all these old hardware, cables, sound adjusting, camera etc, wasn't easy as before.
Obviously, emulators and ZX-uno spoiled me, more than I thought.
btw, I looked at the old snow test and tried to compare with the SpecEmu.
It looks like pattern isn't 100% identical...

[azesmbog]

Fine!!! Excellent video quality and the right angle !!!

btw, I looked at the old snow test and tried to compare with the SpecEmu.
It looks like pattern isn't 100% identical...

This test demonstration was carried out just in order to clearly see and notice the difference between the real ZX48 and emulators, including ZXUno
Of the huge number of emulators, only 8 emulators can boast of "snow" support.
Of these eight, only two emulators will have an identical picture, as in real life.
In both tests.
But yesterday another reincarnation of the last test was made, and of the two previous winners, only one remained !!!
On ZXUno, the picture is also different, at least on my copy, up to 100% identity is still far away.
Thank you, I hope, as a last resort, to bother with testing in real life.

[Pegaz]

[mention]azesmbog[/mention]

Interesting...
Now I'm curious, who is that lucky winner ?
Let me guess ... SpecIde ?

[azesmbog]

Not guessing! The winner is a well-unknown emulator written in JAVA (Or is it JavaScript?))
viewtopic.php?f=23&t=4568
The picture is exactly the same in both tests, and in one more