Enterprise Forever
:UK => Programming => Topic started by: gflorez on 2016.April.28. 15:25:25
-
I am still eager to see the first Enterprise game taking advantage of the use of a mouse.
There are a lot of games conceived as point&click adventures, Shoot'em up's or strategies whose gameplay would increase a lot being managed with a mouse.
I like to play games, but usually I am trapped on other concerns that amuse me more....That's why I do not know a lot about games.
Is for that I've opened this thread, to collect game titles that could be enhanced if adapted to mouse use.
I'm not saying that I will do the conversion, I have no level to do it.
Only as a wish list of Enterprise games or other waiting to be converted.
Then, "somebody" can take the idea and attempt to do it...
For example, I have heard about CPC versions of point&click adventure games that I have played on Pc, like Blade Runner(inspired on the movie), or Full Throttle. Also Orion Prime (http://www.cpcwiki.eu/index.php/Orion_Prime#Downloads) with a Spanish version.
(http://www.cpcwiki.eu/imgs/2/2a/OrionPrime_Beginning.png)
Edit: The CPC's Blade Runner and Full Throttle games are not point&click. Sorry, I was lied by a trash web page....
-
many "tr-dos" games uses mouse, waiting to convert :)
(tr-dos is a russian specy thing, see wos archive)
-
(tr-dos is a russian specy thing
Just for the sake of accuracy: originaly it is "Made in England" by Technology Research Limited. Then many clone created in Russia, Brazil, Czechoslovakia, Italy.
-
I have found B.A.T. (http://cpcrulez.fr/GamesTest/b_a_t.htm) for CPC, a point&click with comic like graphics. Here (http://ftp://ftp.nvg.ntnu.no/pub/cpc/games/adventur/graphic/bat.zip) is another English version.
(http://cpcrulez.fr/img/922b.png)
-
Shufflepuck cafe is a fun and beautiful mouse game and there's a cpc version http://cpcrulez.fr/GamesTest/shufflepuck_cafe.htm
https://www.youtube.com/watch?v=KeJbxffRKAY
Additional enhancements could include sample sounds and maybe an attribute-mode colorful opponent choosing screen (but the cursor can be a problem, I think) and title screen... Or maybe even use the mode for the opponent's ingame graphics. Also looking at the ingame screenshots it seems that the fix-bias in 16c mode shouldn't be a problem because the playfield seems to use max 8 colors.
For the enhanced graphics (and sound?) amiga version could be used.
-
Shufflepuck cafe is a fun and beautiful mouse game......
I have played it in the EP128emu CPC emulator with the PC cursors, and really the movement with the pads is very similar to the actual machine.
-
List of ZX Spectrum games and utils with Kempston Mouse support: http://velesoft.speccy.cz/kmsoft.htm
-
List of ZX Spectrum games and utils with Kempston Mouse support: http://velesoft.speccy.cz/kmsoft.htm
Wow!
Can you link some informations about the Kempston Mouse? How it is working... for compare with EnterMice.
-
is it possible to use mouse in is-basic programs?
maybe I will make some if yes
-
I also didn't know of it. Seems that it works differently than EnterMice or MSX-Boxsoft-Neos. The Kempston mouse (http://www.worldofspectrum.org/infoseekid.cgi?id=1000221) use other pinout than the Kempston joysticks. Here (http://www.worldofspectrum.org/pub/sinclair/technical-docs/KempstonMouse_Schematics.png) you can see the schematics of the interface.
It returns directly the coordinates reading Z80 ports. But the drawback is that the resolution is limited to only 255x255, enough for a Spectrum.
-
On one of the links of the WOS page I found this explanation about how to use it on the Spectrum Basic:
MOUSE TALES
THIS MONTH’S £30 software prize goes to Andrew Haslam, who’s sent in a wonderfully concise program that illustrates exactly how to control a BASIC program with a mouse.
Andrew read about Paul Cotton’s Kempston Mouse problems in Issue 46: he has discovered three IN commands that let you read the mouse position and both buttons from BASIC or machine code. The listing is his program — a trivial drawing routine, where the left button lifts the ‘pen’ off the screen and the right button clears the display. It’s not really useful as it stands, but it’s a good starting point for further experiments.
According to Andrew, the program works with the Kempston Mouse and its clones: I haven’t got the right interface to be able to test it.
IN 64479 reads the horizontal position of the mouse, and IN 65503 gives the vertical position. The two buttons are read with IN 64223, which gives 252 if both are pressed. 253 for the right button only and 254 for the left button. You get 255 if neither button is pressed.
10 LET X = IN 64479
20 LET Y = IN 65503
30 IF IN 64223 = 253 THEN CLS
40 IF IN 64223 = 255 THEN PLOT X,Y
50 GOTO 10
-
is it possible to use mouse in is-basic programs?
maybe I will make some if yes
Are you think about the EnterMice?
Yes it is can be used in Basic, see the examples. (http://wiki.enterpriseforever.com/index.php/EnterMice#Examples)
-
(tr-dos is a russian specy thing, see wos archive)
Can you link some informations about the Kempston Mouse? How it is working... for compare with EnterMice.
TR-DOS and Kempston Mouse is popular in Russian because that interfaces is cheap, simple and came to the Post Soviet countries in first of all.
Unfortunatly, about Kempston Mouse i can't say anything. I'm not hardware guru. :oops: I just love retro computers.
-
I thought that Endi was asking about Spectrum Basic.... Yes, on the EnterMice wiki there are also Basic examples to download if you don't want to type.
-------
I've not seen a Kempston mouse system in my life, but if it is the mouse who says where on the screen is the pointer, then it will force total linearity to the movement, without velocity at all.
On EnterMice, the driver multiplies by 2 the relative increment if greater than 1, and I think that "modern" PS/2 mice add velocity internally.
What is mouse velocity? You are in front of a PC now, isn't it? if you move slowly the mouse the pointer is displaced precisely across the screen, and you need a big table to reach from corner to corner.
But if you attempt the same distance with rapid shakes of the mouse you will see that you only need a few centimetres to reach the opposite corner. The faster you move the hand the farther the pointer reaches with lower precision.
Of course, that games can be theoretically emulated to use EnterMice without problems if they manage some type of coordinates. But the gameplay will be better than in the original game, I think.
-
I think need to put EnterMice reading to the IRQ routine, and put the screen coordinates to memory variables. And modify the Kempston routines for read memory variable instead the I/O port.
If the Kempston reading also in the IRQ routine then possible replace with directly with EnterMice.
With 48K programs don't problem with memory, Page 0 are available for the extra routines (it is a ROM in Spectrum).
With 128K program can be problem if the program fill the whole 128K, but this situation also problem without mouse, because need a space for LPT.
But the most of 128K programs don't use the whole 128K, it is run on 48K, and 1-2 extra segments used for AY music.
-
What about Lemmings (http://cpcrulez.fr/GamesTest/lemmings.htm?t=Uw==)? I played it a lot on Amiga.
This CPC game (https://www.youtube.com/watch?v=bJhJqL-Stu0) was made without mouse control, but has a nice pointer that is moved with the joystick.
(http://retroshowcase.gr/images/computers/AmstradCPC/95/1.jpg)
-
This Bloodwych (http://cpcrulez.fr/GamesTest/bloodwych.htm?t=Uw==) RPG game let us to play two players at the same time on the screen.
It is controlled by moving a pointer over the screen, every player owns one.
(http://cpcrulez.fr/img/556.png)
Teorethically two mice can be conected to the Enterprise, one of them Entermice mode as Ps/2, and the other on the joystick port 1 as Boxsoft. The two could be read easily at the same time with the same reading routine. The only problem can be the buttons, as some of them are shared by the two modes.
-
What about Lemmings (http://cpcrulez.fr/GamesTest/lemmings.htm?t=Uw==)?
The Spectrum version already exist on Enterprise.
-
This Bloodwych (http://cpcrulez.fr/GamesTest/bloodwych.htm?t=Uw==) RPG game let us to play two players at the same time on the screen.
It is controlled by moving a pointer over the screen, every player owns one.
(http://cpcrulez.fr/img/556.png)
wow this looks cool, and I love the types of games
-
The Spectrum version already exist on Enterprise.
Yes, but the Spectrum version of Lemmings was very dull:
-
Pirates! (https://youtu.be/pegEMu-j4l8?t=416) was also a great sensation on CPC.
(https://i.ytimg.com/vi/pegEMu-j4l8/hqdefault.jpg)
-
Swap (http://www.ep128.hu/Ep_Games/Leiras/Swap.htm)
-
What a marvellous and coloured game! It is like a great Enterprise demo in itself.
I've mid-understood that this game is not a conversion. It can be a perfect candidate.
-
If i remember well, there did not remain free time for the CPU in the game, because of MOD player, I read that placing cursor on the screen could be solved, but nothing else could be done, but yes, if mouse implementation is possible, then this is a perfect candidate.
-
The joystick 1 reading routine can be mixed with the mouse routine as it is the same procedure done four times. The mouse has to be read in time, although the Neos chip inside MSX mice admits some delay stretching.
The procedure is:
-Put RTS low
-Delay
-Read a nibble formed with the four direction lines, higher four bits of X displacement since last lecture
-Put RTS high
-Delay
-Read a nibble, lower four bits of X displacement since last lecture
-Put RTS low
-Delay
-Read a nibble, higher four bits of Y displacement since last lecture
-Put RTS high
-Delay
-Read a nibble, lower four bits of Y displacement since last lecture
-Read mouse buttons, row 0, B6h port.
Observe that the RTS signal is what triggers the mouse reading. It must begin and end high.
This is the simple delay routine:
WAIT: nop
nop
nop
dec b
jr nz, WAIT
ret
On the original Boxoft routine the delays where 8, 5, 5, 5 cycles between lectures, but experimenting with the values we have realized that 3, 2, 2, 2 cycles are safe enough for a Neos or a MSX mouse. EnterMice admits even lower delays, working the same on a 4Mhz or a 10Mhz Z80.
This as a minimum, but I've not tested the routine for maximum values. Then, super big delays can be used to do other tasks, like reading the keyboard matrix, joystick 2 or play sound.
The beginning of lectures have to be synchronised with video frames. If an error occurs, the program only must wait till the next frame and the mouse(or EnterMice) will be ready again.
-
Returning to the Kempston mouse, The CPCs also used it, and here (http://www.cpcwiki.eu/index.php/Kempston_Mouse) is a thoughtful explanation of its operation.
I don't know if I misunderstood the Spectrum page, but the Kempston mouse on CPCs gives relative movements, like MSX-Neos does. The data is also read every frame from three Z80 ports like on the Spectrum.
On the web-page it says that the necessary interface is copied 90% from the Spectrum one, only changing the Z80 ports where the data is read from.
Edit: the readings on CPCs or Spectrum are both absolute positions, but the position wraps around i.e. no mater where you are, if 0 is reached the following value is FFh. Or if FFh is reached the following value is 0.
-
I am still thinking about that Spectrum mouse games.
Some of them work on the EP128 emulator but other hang when executing.
Convert them again to EP is not the way.
The only plausible form I see to benefit our EPs from the hard work done on that games is to emulate them properly. We already have sofisticate Spectrum emulators for EP, SPemu and SPemu128, thanks to geco.
What if the Kempston mouse could be emulated inside SPemu?
I don't see great incompatibilities. The Kempston interface data is read on three fixed Z80 ports and on the EP side the EnterMice routine can be efficiently merged with the joystick parsing routine.
Also, converting EnterMice mouse data to Kempston mouse data is not straight like from PS/2, but very easy and not time consuming.
Buttons can be passed the same, and the Spectrum coordinates simply adding successively the MSX increments , if the sum is greater than 255, it follows a zero, or if below zero it follows a 255.
-
What if the Kempston mouse could be emulated inside SPemu?
How do you think the solution?
Kill all Kempston mouse code in the program, and substitute it with Entermice routine and convert it's output to Kempston mouse?
This could work.
Other question is that how many way (code) exist to read Kempston mouse, because I have to check "all" of them to change it.
I would like to ask your help about finding kempston mouse routines, or programs which are using kempston mouse.
-
Convert them again to EP is not the way.
Not need convert again. Needed to check what is modified in the Spectrum version, then do samething in the EP version, just use EnterMice routines.
-
How do you think the solution?
Kill all Kempston mouse code in the program, and substitute it with Entermice routine and convert it's output to Kempston mouse?
This could work.
Other question is that how many way (code) exist to read Kempston mouse, because I have to check "all" of them to change it.
I would like to ask your help about finding kempston mouse routines, or programs which are using kempston mouse.
You can find all the programs and all the information on this (http://velesoft.speccy.cz/kmsoft.htm) page. I have tested some of them on the Spectrum side of EP128EMU, and usually they hang or reset the emulated machine. I have to test them on other Spectrum emulators to see.
Not need convert again. Needed to check what is modified in the Spectrum version, then do samething in the EP version, just use EnterMice routines.
Velesoft, the group that have converted almost all the programs, injects a tailored mouse driver on every one, so I think it is no easy work to see what has changed on every game and interpolate it to the EP conversion. We can end with a lot of versions, two on the Spectrum side and another two on the EP side.
It is more easy to redirect the EnterMice data to the emulated Z80 ports on geco's emulators. This can serve for all the modified Spectrum games. Then one by one can be fixed the minor errors found on the emulators.
Of course, this is only an opinion. Other way can be to convert only the most interesting games or applications.
Velesoft's mouse driver is not as simple as you can think, it weights about 5k added to every game. The basic EnterMice routine, on the other side, is tiny, only about 200 bytes of additional code.
----------------
Another aspect is, what we want to be emulated? The Kempston mouse protocol has evolved, like the MSX protocol, to allow more buttons and wheel. The information is passed on some unused bits on the buttons lecture byte, not needing the reading routine more time to acquire the extra information. Of course it needs to be processed later by the game/application.
On the EnterMice side, we need to send four additional nibbles to pass that extra information. This is double the time, so I think it is better to limit us to the basic two buttons+movement. The game will remain functional, only that the added options will need keyboard keys to be made.
-
The Z80 ports used by original Kempston-mouse interfaces are:
buttons= 64223(#FADF) D0-D2=buttons, later added an additional button on D3 and a wheel counter on D4-D7
X-AXIS = 64479(#FBDF) circular absolute counter
Y-AXIS = 65503(#FFDF) circular absolute counter
Other ports are used for an extra slave mouse and recognition on evolution adapters. See this (http://velesoft.speccy.cz/kmturbo2008-cz.htm).
-
SPECCY 4.0 (http://fms.komkon.org/Speccy/Speccy40-Windows-bin.zip) emulates the Kempston mouse, I don't know what hardware emulates R-Type, it resets the emulated machine.
Others that don't work for me: Hero quest, Trough the wall and Xcel. But a large majority of games are emulated and give good feelings...
-
Still thinking....
We don't need to dig K-mouse code on Spectrum games to know what they did. We already know how:
They first selected a target game, shoot'emups or pointer games where their favourites.
Then, the moving object coordinates and the fire memory positions are searched.
A max and min is tested for the moving object.
A hook is put on the keyboard-joystick parsing routine.
A K-mouse option is placed on the controller selection menu.
And a k.mouse little routine(not 5k as I said) is placed on some part of the memory, called by the hook if the option controller is selected.
-
I am eager to continue adapting games or applications to mouse use, but I'm not as good programmer...
I have attempted to reach the SWAP game code, but it has a complicate loading routine(SWAP.COM) that I have already disassembled. It loads two demos before the game, jumping to the loaded code, and seems that all the chunks are compacted or encrypted, because I don't see anything recognisable with the hex editor.
Does somebody have code from a game or application to try?
-
Still thinking....
We don't need to dig K-mouse code on Spectrum games to know what they did.
The code is neede to find the place in a speccy game of mouse code where we can place call for our mouse routine. If we can nonvert the result of kmouse to entermice then we are in a good position, if all of them are working directly with screen position in the same routine it would be the best.
-
I have attempted to reach the SWAP game code, but it has a complicate loading routine(SWAP.COM) that I have already disassembled. It loads two demos before the game, jumping to the loaded code, and seems that all the chunks are compacted or encrypted, because I don't see anything recognisable with the hex editor.
And what do you think about this solution: leave to load the game, when it is loaded then you can find the controls, create a snapshot, and you can patch mouse code there and if it is ready then create another snapshot, and we can try to isert the result into Swap's code.
-
There is a group of Spectrum games that come with a Z80 snapshot of an assembler loaded with the tailored driver(see this (http://velesoft.speccy.cz/kmouse/kmvelesoft/kmsource-remake.zip) file), others not. The most important data is the memory position of the coordinates, max and min positions and fire buttons, but I think the rest of the K-mouse routine is practically the same.
----------
I like very much your solution, but there are some minor problems:
- EP128emu still doesn't emulates mouse, XEP128 does but I don't know if it manages snapshots.
- I have to study how can I patch code into a snapshot.... not a big problem, I only need some hints... There are some empty memory zones that can fit the routine.
----
If at the end you will try to insert the modified code in SWAP, why don't you try to first extract the game plain executable for me?
I could then disassemble or hex-edit it to study, and try the modified code on the real machine. Once finished you can join the pieces again easier.
-
I like very much your solution, but there are some minor problems:
- EP128emu still doesn't emulates mouse, XEP128 does but I don't know if it manages snapshots.
- I have to study how can I patch code into a snapshot.... not a big problem, I only need some hints... There are some empty memory zones that can fit the routine.
----
If at the end you will try to insert the modified code in SWAP, why don't you try to first extract the game plain executable for me?
I could then disassemble or hex-edit it to study, and try the modified code on the real machine. Once finished you can join the pieces again easier.
Sorry, i forgot EP128emu does not support mouse, patching in EP128emu is easy, there are two ways, you can use inline assembler of the emulator, or the other (the best) you create your asm after assemble it to binary, and finally you can load it into the memory where you want.
The idea is good, but i think compressed parts are used to fit the program into 128k, and if it is true then creating executable is bigger work, my idea was: we can insert the mouse code into thedecompressed binary and compress it again, if it was compressed by old DTF then only this file should be processed, if not then every files should be recompressed.
Please give me some 1-2 weeks, i will check if i can create executable for you.
-
Thank you, I'll wait.
If I can aid you.....
Poking around while SWAP is executing, I've seen that the same loader, at 0100h, has been used to load the two demos and the game, the three of them are read successively in chunks from the SWAP.PRG file and placed uncompressed in memory.
They are executed in cascade. At the end of the demos, when Space is pressed, the execution is passed to the loader and the next module is loaded and executed.
-
Exciting, i hope so, something will be from him! Swap would be much more enjoyable with a mouse! :-)
-
Here is SWAP without packing, and separate files, you can work with it :)
If you are finished, I think I will make it EXOS compatible. The program plays the mod music from high frequency interrupt, I hope you will have enough CPU time for implementing mouse, and with mouse the program will not overrun on the 50Hz interrupt, if yes, then we can check if it cause any problem in game play or not, if yes, we can play with delay, insert game code into delay part.
-
Thanks. I will last a little more than you, one or two weeks.....
Meanwhile, Academy seems to need a mouse for better game playing.
-
Talking about how difficult are C64 -> EP conversions, I would love Maniac Mansion ported...
(https://www.c64-wiki.com/images/e/ed/ManiacMansion_Animation1.gif)
A lot has been spoken in other forums about CPC and MSX conversions of Maniac Mansion that have never been even started.
-
I suppose it's a matter of time of a talented individual. I strongly believe that first SCUMM games are perfectly doable in all machines. Right now even a Oric SCUMM-alike engine is being worked on...and looks fantastic.
Looks really incredible that there's still no Z80 port of this famous engine :-(
These games are the wet dream of a mouse user :-)
-
Here is the test version of spemu128 with kmouse support, I hope I set the right directions.
-
The directions are right, the three Spectrum games work perfectly on XEP128!
I don't see any slowdown. I still must to test it on the real EP.
-
The directions are right, the three Spectrum games work perfectly on XEP128!
I don't see any slowdown. I still must to test it on the real EP.
Great, thank you very much :)
We will have one problem, I tested about 10 games, and these 3 worked, most of them was packed, and 1 or 2 overwrote the "ROM", so possibly we should make a snapshot from those tap's.
-
On the real EP,"batty-km" doesn't move the bat, surely a minor timing problem, but the other two work like on XEP128.
I had similar problem with Paszians, first working versions only did on XEP12, not on EP.
-
On the real EP,"batty-km" doesn't move the bat, surely a minor timing problem, but the other two work like on XEP128.
I had similar problem with Paszians, first working versions only did on XEP12, not on EP.
Should I increase WAIT routine?
-
You can do that way. I changed easily the No. of loops only poking new values. The original Boxsoft routine had 8,5,5,5.
I imagine you have used 3,2,2,2 if you have copied the wiki routine.
Putting the original No. of loops on Pasziansz did the trick.
But better test your values, because you lose Z80 time stretching the pauses.
-
I imagine you have used 3,2,2,2 if you have copied the wiki routine.
Yes :D
Could you please check the new attachment? it uses 4,3,3,3
-
It works!, but also the first version did it.....
That "batty-km" game has a stupid method of selecting controller and I didn't pressed option 7 as I though it was already selected.
-
It works!, but also the first version did it.....
That "batty-km" game has a stupid method of selecting controller and I didn't pressed option 7 as I though it was already selected.
Great, thank you very much, I will change back the values:) Meanwhile I found also mistake, when keyboard was checked with in x,(c), the program sent it to AY register read routine :D
I will test some games ( a lot of without kmouse, and kmouse games ) when I finished I will upload the final version.
Should I implement mouse into SPEmu48 also?
-
There are only a few 48k games for K-mouse, but SPEmu128 is enough to emulate them. As you wish.
-
I have added your SPEmu128 emulator to the EnterMice wiki list of compatible programs. Once you launch the release I will put a link to the executable.
Also I have added a mention to say that XEP128 and SPEmu128 mouse capabilities are compatible, you can emulate a Kempston mouse from EnterMice and then from PC mouse movement.
-
I have added your SPEmu128 emulator to the EnterMice wiki list of compatible programs. Once you launch the release I will put a link to the executable.
Also I have added a mention to say that XEP128 and SPEmu128 mouse capabilities are compatible, you can emulate a Kempston mouse from EnterMice and then from PC mouse movement.
Thx :)
great, an emulated mouse, which is also emulated, runs on a simulator, which runs on an emulator :D
In my case the emulator runs on a virtual Windows :ds_icon_cheesygrin:
-
Any more EP game suggestions to convert to EnterMice?
-
Sim City...? :-)
-
I can try, but there is a Sym-city(Spectrum) on the Kempston mouse packet emulated by SPemu128. Sooner or later it will work on the real EP, by now it does on XEP128.
-
Zolyx (http://www.ep128.hu/Games/Zolyx.htm) also has mouse pointer controlled menu.
However not a game, but Music Box (http://ep128.hu/Ep_Util/Music_Box.htm) would "bear" the mouse control.
-
I can try with that Zolix game or others that have a moving pointer already made. It is relatively easy if there is a free zone of memory.
But I am not so skilled to implement a pointer on a program. May be if the program is EXOS compatible, the mouse driver can be used definning click zones.
We need developpers that would want to do that type of things.
-
Original SWAP (https://enterpriseforever.com/letoltesek-downloads/enterprise-software/?action=dlattach;attach=15993) game got mouse support by GFlorez, and the game has been made EXOS compatible and recognize Turbo machines by me :)
-
:smt038
-
Link added on the EnterMice wiki pages (http://wiki.enterpriseforever.com/index.php/Main_Page#EnterMice).
-
is it possible to try these games with the emu?
-
is it possible to try these games with the emu?
With XEP128.
-
I have added a XEP128 configuration explanation to the EnterMice wiki pages. Actually only for Windows based pc's.
http://wiki.enterpriseforever.com/index.php/EnterMice#XEP128_Emulator
-
is it possible to try these games with the emu?
With EP128emu the games will work perfectly, but the mouse control, both serial or EnterMice, is still not emulated.
-
Zozo, Gflorez, could you please test the following game if works correctly with mouse?
I tried it with XEP128, but cursor moved only up in any config, and I tried again Swap, but mouse still does not work for me :(
Thank you very much
-
At least it works with XEP.
Only that the upper and left margins have to be fixed. If the limit is reached the pointer is put at the opposite side side.
Some times with a piece taken, if the lower limit is reached, the game frezees.
I am struggling to make a video of it.
-
Thank you very much, possibly freeze not caused by lower limit, I could reproduze by picking up a piece and dropping down and repeat this step 3x, 4x.
-
Here you have a video on a lower frame-rate so , it not do justice to the pointer smooth movement.
https://www.dropbox.com/s/s9pzdqkf2zh8tse/cm3.avi?dl=0
-
Now the pointer should not jump to opposite side, and the game should not freeze when you pick and drop a piece 4 times.
Thank you very much the video, it was cool to see EGI with mouse, and CM also :)
The freze caused by wrong bottom border check, and I found the problem mentioned below.
-
Now the game works perfect but..... still the taken piece is drawn outside the screen when the pointer is moved down. The error is only with 3d pieces, not 2d ones.
Take a look at this video, what happens when I move slowly a taken piece to the lower limit.
https://www.dropbox.com/s/hzkgltarnrafun9/cm4.avi?dl=0
-
Thank you very much for testing :)
I tested it in 2d only today :)
And this problem can be produced by normal keyboard move, just I did not try to move down the piece ;)
And this is buggy on the original version also, just there the program does not hang, because of CPC screen addressing.
-
I have tested it on the real thing.
Another error has surfaced that not happens on XEP.
When opening the Left and Right menus and slowly displacing the pointer to down, about at the middle of the list of options, the pointer disappears and returns randomly at the margins but on the same row.
Some bits of the menu options are also drawn there where the pointer appears.
The middle menu is not affected by this error.
This error doesn't make the game unplayable, as if the pointer is moved faster, the menu options can sometimes be selected.
If I can I will drop a video but it can be seen using the keyboard.
-
Please forget my last commentary... My mouse was making weird things.
The program works the same on a real EP!
Edit: the error as returned, only with my old EP, on my unopened issue 6 EP it works perfect.
My old EP has some problems.....
We need more beta testers.
-
Please forget my last commentary... My mouse was making weird things.
The program works the same on a real EP!
A rock fell off from my heart. (sorry it was translated from hungarian) :)
-
My old issue 4 EP makes again the error, even with the keyboard, but on my unopened issue 6 EP the program works perfect.
My old EP is very, very used, I don't know what can happen to it.
The other mouse programs work on it.
You need Zozo as beta tester.
-
I hope the latest version do not show this strange error :)
-
I could not reproduce this error on EP128emu with keyboard, I changed vertical movement from 4 to 1, this grants the slow movement.
-
You need Zozo as beta tester.
I'm now away on vacation, I can test it two weeks later.
(With XEP: mouse total random moving)
-
I'm now away on vacation, I can test it two weeks later.
(With XEP: mouse total random moving)
Have nice vacation :)
I hope it is a mouse driver bug :D , it is interesting, I use the same code as in SPEmu, and main parts are the same as in Swap, and mouse moves at Gflorez, you have a Random movement, and when I last tested mouse moved continously up in CM2000, and bit randomly very slowly (or no movement) in Swap.
-
With my issue 6 EP I have found a little error that may be the cause of the bigger error on my old EP. It only happens with mouse control.
If I click on the menus and slide the pointer without clicking over the revealed list, suddenly the menu closes. The pointer remains in the same position.
On the old EP is the same, but also with keyboard, the pointer vanish and appears near the border on the same row. Parts of the menu list are redrawn there like garbage.
I have observed a slight delay in the music while over the menu.
-
Remains the cursor in the same position, and the cursor does not move anymore?
-
I will do a video.
-
Remains the cursor in the same position, and the cursor does not move anymore?
No, I mean, with the new EP (from now on I will name my issue 6 one as this), I click on a menu word and the menu list reveals itself.
Then, once slowly sliding the pointer over the list, the menu disappears but the pointer remains still working as normal.
On the old EP the error reaction is worse, the menu and pointer disappear but resurface on the same row at the borders, some bits of the menu are drawn like garbage there..
I still had no time to do the video. Perhaps a little later.
-
Then on issue 6 ep the mouse movement is ok, the menu disappears when the cursor leaves it.
I did not check yet , i just thinking (i did not turn on my pc), and this pointer jumping error what your old ep produce should not occur, the mouse is read in the interrupt, and screen addree is calculated also there and stored, so interrupt is disabled, and it seems cursor position goes to bad, what normally can not occur.
-
Exactly.
Now I have observed what is the problem (on my healthy EP). When you click a menu word, you only can slide the pointer on an area as wide as the title word, but the menu list is wider than that area.
Try to put the pointer on a menu option and then move the control to the left or right. You will see that the list disappears with the pointer still over the menu list.
Of course this is not your fault.
I think that the solution can be to enlarge the menu click area.
--------------------------------
On my old EP.... here you have a video of its estrange behaviour:
https://www.dropbox.com/s/ef5j8ziy5hc39rl/cm5.mp4?dl=0
-
On my old EP.... here you have a video of its estrange behaviour:
https://www.dropbox.com/s/ef5j8ziy5hc39rl/cm5.mp4?dl=0
Thank you very much the video.
Hm, it is very interesting, it seems it seems something is corrupted when you press fire, and therefore the action is not performed, just the cursor is redrawn with the saved background. Is it an EP128 or EP64?
-
I don't press fire, I only click on the title word and slowly move the pointer over the list that appears without touching the mouse buttons.
My old EP is an early 128, serial number 1179, issue 4 with old Nick.
(I have observed that the interlaced presentation screen of CM2000 is a good version-test for Nick.)
--------------
Edit: Try to NOT DISABLE interrupts on the Mouse reading routine. That worked for me on the other games.
-
(I have observed that the interlaced presentation screen of CM2000 is a good version-test for Nick.)
It is a non interlaced Attribute screen :) , but these kind of attribute screens are good Nick testers.
Edit: Try to NOT DISABLE interrupts on the Mouse reading routine. That worked for me on the other games.
Hm, even if it is in the interrupt?
-
Hm, even if it is in the interrupt?
Yes, practice has probed me that using DI and EI when trying to read the injected mouse-movement-routine is a bad idea.
Remove them and try, probably the game will work the same or better.
But I may be wrong with this game....
-
Here is the mouse routine with enabled interrupt, but I found something, sometime the part of the border of menu, is drawn just below, or above the menu border.
Could you please try this mouse with enabled interrupt version?
-
I think I found the reason of the problem, interrupt is disabled at all background restore and cursor draw routine, except at one place where the interrupt is enabled just before this routine, it seems on CPC this did not cause any problem, on EP it caused at least the previously mentioned border problem.
-
I have tested only this last version.
On Xep it works the same, on my new EP also the same, but on the old EP something has changed.
Still the same behaviour when the pointer is moved over the menu list, the menu suddenly disappears and the pointer is thrown to the sides, but at least no menu garbage is drawn sideways of the screen.
Sometimes the list doesn't disappears and this lets you to click the options.
Good job.
-
I have tested only this last version.
On Xep it works the same, on my new EP also the same, but on the old EP something has changed.
Still the same behaviour when the pointer is moved over the menu list, the menu suddenly disappears and the pointer is thrown to the sides, but at least no menu garbage is drawn sideways of the screen.
Sometimes the list doesn't disappears and this lets you to click the options.
Good job.
Thank you very much for testing, and help :)
Hm, it is very interesting, is it possible Entermice does not work 100% correctly on your old EP, it seems it generates a big horizontal movement, and it is the reason why the menu disappears and cursor moves to left/right border.
The program calculate x,y position and based on x,y position of the cursor it calculate the screen address, it is stored, and if the pointer is drawn, the address alwas is read.
-
Thank you very much for testing :)
I tested it in 2d only today :)
And this problem can be produced by normal keyboard move, just I did not try to move down the piece ;)
And this is buggy on the original version also, just there the program does not hang, because of CPC screen addressing.
I just play with the CHESSMASTER 2000 with internal joystick and goes very well with mouse will be awesome ...
-
I forgot to say that my old EP is since long upgraded with a 1MB SainT´s memory expansion.
Now, I have just put another 1MB Ram card inside my "new" EP..... and it behaves exactly like the old one with CM2000's menus...
So now I have two healthy EPs...
May be the faster memory the problem?
-
Also, I have observed how the music slows down while sliding the pointer over the menu list.
-
Try to start the expanded machines in 128K mode, what will happen?
-
And I will try it on expanded machine in emulator also, normally it should work the same as on a normal EP128, because I use 3 normal RAM, and 1 VRAM, and there is no paging.
Music slow down occurs because of a longer disabled interrupt I think, I will check if there is the possibility to solve this slow down.
-
With F1 pressed on Zozo's Fast Ram Check I can emulate a 128K EP.
The error on menus with expanded EP's was only with the File and Options menus, Play menu worked fine.
Now, emulating a 128K EP, the result is the opposite, File and Options work correctly, but clicking on Play draws the list menu to immediately disappear, throwing the pointer to a side.
-
Even more extrange...
On 128k emulation, if I run directly the game, it fails on the File and Option menus, but if I launch it from the EGI, it fails only on the Play menu.....
? ? ? ? ? ?
I have a possible clue to this behaviour. On my Mouse conversions invariably I had problems with the mouse buttons status not detected properly.
The solution was to incorporate a de-bouncing routine.
-
I have a possible clue to this behaviour. On my Mouse conversions invariably I had problems with the mouse buttons status not detected properly.
The solution was to incorporate a de-bouncing routine.
What does it mean exactly?
-
I mean that on EnterMice the pressed status of a button can bounce, it is read as two clicks. EnterMice is faster than Enterprise, and the computer interprets a single click as two clicks or pressed.
-
Hm, it is a real possibility, and how can we avoid it?
-
To do it you must differentiate the real button status from the value you return to the game.
You must save internally on the mouse routine the physical button state on the last mouse reading cycle. If it was pressed and now it is still on, you must return to the game the actual state as released. Internally you must check this every cycle, not putting the "external" status to pressed until at least 1 "internal" released+pressed cycle occurs.
With this you assure that all the clicks only last 1/50 seconds, being immediately released on the following cycle. Then, if the key is keep pressed(or a slow click), the game is not fooled to react to two clicks, as it thinks it is already released.
-
With this you assure that all the clicks only last 1/50 seconds, being immediately released on the following cycle. Then, if the key is keep pressed(or a slow click), the game is not fooled to react to two clicks, as it thinks it is already released.
The "immediately" means exactly 1500 μs.
-
Normally this should not cause any problem, the keyboard fire could also be active in 2 or more next interrupt, and mouse fire is released until next interrupt if mouse button released.
-
But it caused key bouncing on EDCW and SWAP...
If you study my injected mouse routine in SWAP you will see how I fixed it.
Actually I implemented two debouncing fixings on the mouse routine for the mouse clicking.
-
But it caused key bouncing on EDCW and SWAP...
Ok, I will insert a code which will check the previous state, and if it was pressed, then it will give up a non pressed value, until the mouse button released, and pressed again.
-
Itsvan says that on SWAP the key click routine is out of the 1500 us timeout. Can it be the same problem with CM2000?.
I don't know how it can be tested...
-
But the Swap is working on real machine... interesting!
-
Yes, but the buttons didn't work well and I put a debouncing routine. Just like EDCW, the main mouse button remained pressed until I put a debouncing routine on it. Do you remember?
-
Here is the version where continuously pressed mouse button counts to one short press, the previous version processed the fire when it was released, so I do not think the cursor jumping will be disappeared. Could you please check it on real EP? It worked fine on Emu, but previous version also :D
-
But the Swap is working on real machine... interesting!
So, on the real machine, the mouse buttons always work as the second and third fire buttons on EXT1, even without an RTS state change? That could be tested with this program (https://enterpriseforever.com/programozas/enterprise-billentyzet-es-joystick-teszt/msg50234/#msg50234).
-
Could you please check it on real EP? It worked fine on Emu, but previous version also :D
Still the same annoying error on ChessMaster 2000 when on the real machine upgraded with 1MB, not on the 128k. May be IstvanV can aid here if I explain what happens. It can be the memory so fast?
Please IstvanV, see this video (https://www.dropbox.com/s/mz3015ejhq6t2a0/cm2000_5%5B1%5D.mp4?dl=0).
The central menu works, but FILE and OPTIONS menus disappear when the pointer is over them. Also the pointer vanishes and surfaces near one of the side borders.
---------------
On SWAP, the contrary, the button works on the real thing and XEP128 but not on EP128emu.
-
Still the same annoying error on ChessMaster 2000 when on the real machine upgraded with 1MB, not on the 128k. May be IstvanV can aid here if I explain what happens. It can be the memory so fast?
The memory should not make a difference, CM2000 always disables wait states and the mouse routine runs in normal (not video) RAM even on 128K machines. I did not find any obvious errors in the code so far, but I may need to check more. Perhaps it is a problem specific to that particular 1 MB machine? Do others have the same issue with CM2000 on real machines?
In the emulator, I found only some minor issues, like the sensitivity, which also seems to be higher on the X axis, I think it is 4x X sensitivity and 2x Y compared to MOUSE.XR. Using NEG on the 8-bit motion values can also overflow, but only when the mouse is moved very fast (NEG(-128) = -128), so it does not really matter in practice.
On SWAP, the contrary, the button works on the real thing and XEP128 but not on EP128emu.
The current version of ep128emu emulates the mouse buttons on EXT1 columns K and L only while the 1500 us timer is active. Using the actual joystick buttons works in SWAP, but perhaps the mouse buttons should be mapped to EXT1 fire 2 and 3 all the time, and not only for 1500 us after an RTS state change?
Another annoying "feature" of the input in SWAP, and I think this is not emulator specific, is that the pointer already needs to be moving in the direction of the swap at the moment when the button is clicked. That is, it is not possible to move the pointer to the tile that needs to be swapped, then press the button, and then while it is held down, move the pointer to the other tile to swap with. This, combined with the high sensitivity, makes controlling the game not very convenient. Using the external joysticks has the same issue, but interestingly not the keyboard/internal joystick.
-
I have two EP, one issue4 and the other issue6, both extended with 1mb Saint memories.
If I start the EP in 128k or 64k modes the menus work normal. With all the memory is when the error happens.
---------------------------------
About SWAP, I understand you, but EnterMice stops sending fire buttons if there are no changes on the RTS line.
Is for that I change RTS just before reading the K line for the Buttons. It is explained in the EnterMice wiki just at the end of the page.
The PS/2 buttons aren't hard wired connected to the EnterMice fire buttons.
-
I have two EP, one issue4 and the other issue6, both extended with 1mb Saint memories.
If I start the EP in 128k or 64k modes the menus work normal. With all the memory is when the error happens.
I do not really know what the problem might be then, it could be something specific to the memory expansion hardware. I suspected the timing, but the wait times in CM2000 seem to be correct. On a turbo machine (6 or 7.12 MHz), they could become too short, however.
About SWAP, I understand you, but EnterMice stops sending fire buttons if there are no changes on the RTS line.
Perhaps I tested a different (older) version of SWAP then? It checks the state of the buttons more than 18 ms after the last byte is received from the mouse. In other words, in each 50 Hz interrupt, it polls the buttons first without writing to port B7h (similarly to SymbOS before it was changed), and only after that it receives the X/Y motion bytes. But maybe the timeout for the buttons is longer?
-
Sorry, my fault :oops:
I looked exact the source code of Entermice. Only bits D0-D3 are cleared after 1.5 ms.
Button states are on bits D4 and D5, which are set or reset when done the next reading of the mouse, which is 20 ms.
With the code shows that if there is no further read PS/2 mouse, the states of the buttons on the bits D4 and D5 will remain unchanged. Is this defect?
I would have to do an additional watchdog, which resets the states of buttons after the end of polling the interface.
-
It would be interesting to test this program on the real machine, what happens when the mouse or EXT1 buttons are pressed?
[attachurl=1]
With the code shows that if there is no further read PS/2 mouse, the states of the buttons on the bits D4 and D5 will remain unchanged. Is this defect?
If that means the button states "stick" permanently on port B6h when polling is not requested (even after the buttons are released), then it could be a bug, if I understood it correctly. I guess it would be easy to clear them together with the other bits after 1500 us, like the emulator does now, but this would break some old programs. It could be limited to native mode, though, with the BoxSoft compatible mode left the same as before.
-
I think so. Should check it out.
-
But maybe the timeout for the buttons is longer?
In practice it seems to be longer, as SWAP work "as is" perfectly on the real thing. Exactly the same that happened with SimbOS before fixing it, as you say.
-
Well, I am still not entirely sure exactly how it works on the real machine, but for now I will probably just map the mouse buttons as EXT1 fire 2 and 3 all the time. Which is not accurate, but at least it should not break programs.
-
It would be interesting to test this program on the real machine, what happens when the mouse or EXT1 buttons are pressed?
I only see them working as I expected,: Main button(left) turns the screen to green, while the secondary button to blue. Both pressed at the same time make the screen light blue.
On the EnterMice joystick port 1, the same happens but with fire 2 and 3. Joy1 Fire 1 and all the fires of joy2 don't paint the screen.
The buttons are interchangeable, if I press main mouse button + button 3 on the joystick port, the screen turns to light blue.
Is that right?
The Joystick buttons are hard-wired, while the mouse buttons need a change in the RTS line to appear.
-
I only see them working as I expected,: Main button(left) turns the screen to green, while the secondary button to blue. Both pressed at the same time make the screen light blue.
Does pressing the mouse buttons make the whole screen green or blue all the time? What the program does is that it toggles the RTS bit just below the status line every 50 Hz interrupt, and it shows the state of the three lowest bits of port B6h with row 0 selected on the border color (it is constantly updated by the main program). Also, toggling RTS is periodically disabled, for 16 frames it is active, then not for another 16 frames, then active again for 16 frames, and so on. Thus, depending on the implementation of the mouse interface, not all the screen may be colored, or it may periodically flash.
-
If I maintain pressed the buttons, the screen is solid on all cases. But if I click quickly, the flicker happens.
Some times a sticky coloured screen remains less than a second even when I have already released the mouse buttons. This doesn't happens with the joystick buttons.
Do you want a video of it?
-
Here (https://www.dropbox.com/s/9yd2170hvqxz2t3/mbtntest.mp4?dl=0) you have the video. I have put the mouse against the screen to show you when I press the buttons.
I think it is not necessary another video of the joystick buttons.
-
Here (https://www.dropbox.com/s/9yd2170hvqxz2t3/mbtntest.mp4?dl=0) you have the video. I have put the mouse against the screen to show you when I press the buttons.
Thanks, I made some changes to the GitHub sources and SWAP works better now. Does the test program look the same with the joystick buttons?
-
Joystick buttons behave exactly the same.
Thanks to you for your efforts.
-
I don't know if Music Box (http://ep128.hu/Ep_Util/Music_Box.htm) has already been mentioned but it would also work better with the mouse. However it uses character screen and the mouse movement would be "funny" with that pointer of square shape.
-
If the source exist I can try to implement the mouse control on the program, but may be it needs a deep rework, with new archive types and a colourful graphics screen. I haven't the skills for that, sorry.
On the other side, where is the link to MusicBox? I still hadn't use that program.
Edit: OK, found.
-
Enigma Force (Kmouse)
Release: 31.03.2018
Kmouse: Hood
INFO (https://hood.speccy.cz/dwnld/enigmaf_km_info.htm)
Download (https://hood.speccy.cz/dwnld/enigmaf_km.zip)
-
Lemmings (http://www.ep128.hu/Games/Lemmings.htm) (CPC conversion would be better!)
Turbo Amoba (http://www.ep128.hu/Ep_Games/Leiras/Turbo_Amoeba.htm)
Amoba was written by Miklán Attila, so may be the source code is avaliable...
I've tried both game with EnterMice joystick mode, they are playable, but very slow cursor movement, so native mouse support would be much better :-)
One interesting thin in EnterMice joystick mode: the red LED is lighting, but only if mouse is not moved. Does it work by design?
-
One interesting thin in EnterMice joystick mode: the red LED is lighting, but only if mouse is not moved. Does it work by design?
According to the wiki it is OK.
"If DS3 is ON, in joystick mode lights up red LED. It's blinking when any direction-contact is shorted. "
-
I have been playing the Turbo Amoeba game. It is very enjoyable and I think it would be even better with a mouse option.