Enterprise Forever
:UK => Programming => Topic started by: Zozosoft on 2016.April.19. 09:59:49
-
Another challenge to Gflorez! If you do not mind :oops:
This game use built in mouse driver (serial Mouse System only), will be nice if EnterMice also can be used.
Source of this are also included in the big HSoft pack (https://enterpriseforever.com/downloads/?dir=Hsoft_programjai_es_forraskodjai), but some files are missing! :-(
Fortunately at 1994 I got one earlier version sources from Hsoft, then I completed the latest version with the missing files.
There is the complete pack, works with HEASS.
-
Thanks for trusting on me...
As you know, I only understand the easy(for dumbs) functioning of Sjasm, but I will see...
There is a "big" zone at the end of the Pasziansz.rom filled of FFh, of about 3,3kb, enough to put there the EnterMice routine and much more.
Even we can try an English version.
-
There is a "big" zone at the end of the Pasziansz.rom filled of FFh, of about 3,3kb, enough to put there the EnterMice routine and much more.
This is not the ROM version, it is the original loadable.
When it is done then possible to create the new ROM version (it is just copy the program from the ROM to RAM).
-
Ok, then it could be tested more easily on an executable.
---
Yes, Pasziansz uses exactly the same mouse routines as found on EPDOS2.1. And "normal" coordinates(16bit x 16bit), not as on EDCW.
-
This is not the ROM version, it is the original loadable.
When it is done then possible to create the new ROM version (it is just copy the program from the ROM to RAM).
Then you can do the same with EDCW, as it works the same. The problem is the lack of space to put any more code.
-
This is a first attempt.
Please Zozo, can you compile it?
If there is some movement it will be inverse on both axis,
-
It doesn't work... I have compiled it with HEASS on EP128emu.
-
It doesn't work... I have compiled it with HEASS on EP128emu.
Yes it is hang up at the start :oops:
-
Try this, at least it works on XEP128.
The problem was EI and DI, as this game works with HALTs. I removed EI and the game started to work with the X inverted. Then I NEGated the X_REL relative increment and now it works.
-
On the real machine(EP128+sd-reader) it hangs.....
-
It is works very crazy on Xep128 for me :oops:
The cursor are tremble/jumping, and mainly moving inverted.
-
Strange, as I have tested all versions of XEP128 I have and it works perfect on all....
-
You can invert the movement here in this part of the code. you can activate or deactivate the NEG opcodes to do it.
-
Tested on real machine: it is freeze when mouse moved.
Joystick will work until the mouse moved.
Sometimes freeze at the start.
:oops: :oops: :oops:
-
Tested on real machine: it is freeze when mouse moved.
Joystick will work until the mouse moved.
Sometimes freeze at the start.
:oops: :oops: :oops:
Maybe gflorez used the -fix-crashing-ep Xep128 command line switch :) :) :) :) Ok, bad joke .... :(
-
Tomorrow I will put here a video with the program working. May be Xep depends on the host Pc?
-
Tomorrow I will put here a video with the program working. May be Xep depends on the host Pc?
Of course it depends, since it runs under the host OS - it won't work without any OS :) But it depends what you mean about the depending on host OS, of course.
-
This game works on halts. May be on some computers this is better emulated than in others.
-
In my house, on a Lenovo laptop running on XP, it also works.
As it doesn't work on the real EP, may be interruptions are worse emulated on XP?
-
This game works on halts. May be on some computers this is better emulated than in others.
On halts? Do you mean the HALT Z80 opcode? Basic hardware emulation (CPU, memory) should not depend on the host OS at all, I mean the host OS / computer exact type does not matter (I also tried Xep128 on Raspberry Pi, which has ARM CPU, not even x86 ... but not so surprising as it's written in C, so it should work on all platforms the same way which has well bug free C compiler). Of course some interaction still depends on host OS more. Eg mouse events are from the host OS after all, and whatever the Entermice emulation does in Xep128, host OS may decide to route mouse movements in "big chunks" or small ones, etc, so maybe not the *very* same input an EP software in Xep128 will get even if - in theory - you can move the mouse the *exact* same way (which is not possible too much, but that's another question). It was only a stupid example, of course ...
-
In my house, on a Lenovo laptop running on XP, it also works.
As it doesn't work on the real EP, may be interruptions are worse emulated on XP?
No, it shouldn't. Z80 interrupts are nothing to do with the host OS. Even if a computer is very slow, and Xep128 can't go real-time, the Z80 emulation code counts Z80 t-cycles etc not the real time of the host OS, etc. But surely, nobody can say at 100% that something is bug free, but it would sound quite odd for me ...
-
I mean this:
IDOMERES: LD A,0CH
OUT (0BFH),A
LD HL,0C937H
LD (38H),HL
LD HL,5000
LD A,30H
OUT (0B4H),A
EI
HALT
OUT (0B4H),A
EI
OR A
IDOMERES10: DEC HL
Edit: tomorrow I will test on a Vista OS.
-
I mean this:
IDOMERES: LD A,0CH
OUT (0BFH),A
LD HL,0C937H
LD (38H),HL
LD HL,5000
LD A,30H
OUT (0B4H),A
EI
HALT
OUT (0B4H),A
EI
OR A
IDOMERES10: DEC HL
Edit: tomorrow I will test on a Vista OS.
EI enables interrupts only after the *end of next* opcode. So after HALT ... This code fragment seems to be strange for me, at the first glance, but it's possible that I'm tired only :) Of course if interrupts were enabled even before EI, it may does not cause too much headache, but if interrupts are disabled, this would halts the CPU, as interrupts are enabled by EI only after the HALT, but it won't occur, as HALT waits for an interrupt ... But I am really unsure ... As HALT can be imagined as a re-executed opcode without incrementing PC. So maybe it's still possible that the stuff above works, because on the "second iteration" of HALT that's already an opcode away from EI, so an interrupt can "kick off" Z80 from HALT state.
http://www.z80.info/zip/z80-documented.pdf
As far as I can see, my second explanation is the right, if you read things about EI and HALT in this nice (and quite useful, in my opinion) documentation on not-so-well-known Z80 features :)
But anyway, I haven't written the Z80 emulation code itself, it's from Z80EX project, which is basically based on FUSE, which is a Spectrum emulator by the way (Free Unix Spectrum Emulator, or something like that). I can't say that Z80EX is bug-free, but even if it's not, that behaviour is nothing to do too much with the host OS/machine.
Moreover, of course HALT will stop the execution regardless of EI, if no interrupt is got by the Z80 ... Since in EP, all maskable interrupts comes through/from Dave, it's possible, that there is some specific problem in the Dave emulation itself, not the Z80 part. I even have some faint idea ... On a real EP, Dave just runs in "parallel" with CPU, I mean its counters for example. This is not possible in an emulator too much, as emulator is a single sequence of code (ok, you can have more CPU cores, multithreading etc, but then it won't work too much as you can't keep stuffs in sync using a host OS which has its own idea on scheduling processes/threads/etc in this very low scale time factor at least). So Xep128 in reality runs one Z80 opcode and _then_ runs the Dave "tick" function which emulates amount of Dave cycles calculated from the Dave / Z80 clock ratio (fractions are not lost ....). That "tick" funcion is responsible also to decrement Dave counters and causing interrupt for example if it's enabled. Usually this should not make any difference, but I think it will, if very tight cycle exact reaction is needed. But I am really unsure now. In theory, interrupts are not accepted of course within an opcode execution by the Z80, so it won't cause difference, however, there is one exception: if a CPU opcode is long enough (in T-cycles) that multiple Dave ticks "fits", then Dave tick function is called more times without Z80 activity in the emulator code level at least. With the current code structure, I can't avoid that, otherwise the CPU/Dave frequency ratio cannot be kept at all. Well, it's just one possible reason that Xep128 can behave a bit different than a real EP, if accurate timing is important. Some other areas where Xep128 is not exact:
* VRAM timing it totally missing :( It's a quite *big* difference from a real EP! In fact, I think, more important than the case of Dave/CPU sync which is about to be good, just few cycles difference maybe (those inaccurate cycles would "average out" each other on long term, but can cause problem if ONE cycle exact emulation is needed for some reason!)
* Nick/CPU exact timing is also not exact, well this cause the previous VRAM timing problem :) But it can be detected by other means, if someone plays with rapid modification of data Nick would read very soon, etc ... I don't think too much people used tricks like this ever ... Maybe IstvanV had a nick program (which even doesn't work on ep128emu) playing with _reading_ Nick registers which would reflect the last bus state between Nick and its RAM (VRAM). Not so easy to do it at a very exact way ...
-
Tested on a mini laptop Asus running on Win 8.1.
It works as on XP.
-
I'm still unsure what is wrong for you about the code pattern above. Since it writes 0x30 to port 0xB4, tt should be (enable INT1 and reset INT1 latch) something with Dave INT1 which is connected to the VINT output of Nick, that is "video interrupt". Since the label in asm code says "idomeres" it means "measure time" in Hungarian. Maybe the fact that VINT is generated 50Hz rate if VINT bit is set on a single LPB during the LPT normally. But what I still can't understand that what's your problem with this, it should work differently in other emulators and/or on real EP? Exactly what is the difference, it would be nice to know :)
-
For me it is fine that the game worked perfectly on your emulator as it means I am near from achieving the same on the real EP.
What annoys me is, why it doesn't work for Zozo?
Now I have tested your XEP128 with Paszians on a Win7 Pc and it behaves exactly the same how Zozo describes it.
On the other side, on the same Pc, mouse on EGI works. It is strange, isn't it? Not your fault, it can be again Windows jungle...
-
On the other side, on the same Pc, mouse on EGI works. It is strange, isn't it? Not your fault, it can be again Windows jungle...
Never say "not", it can be mine :) That's why I am insterested, you can never know, that you may found some bug which is hard to find, but still :)
-
There is no way.
Paszians seems to be incompatible with EnterMice mode, but on the other side probably I could implement a Boxsoft mode.
This game works constantly writing and reading port 0B4H(Dave enable/reset interrupt sources/latches), and writing port 0BFH(Dave sysconfig register, wait states, clkdiv).
Probably this corrupts the lecture of bit 1 (K column) of port 0B6H(game ports), but leaves untouched bit 0 (J column).
I don't know how many games use this interrupt system, but it can be that choosing the unused K column for EnterMice has not been the best idea.
Why K and L remained undocumented so many years? May be the developers discovered the incompatibilities and abandoned their use?
At least we still can switch to Boxsoft mode on the EnterMice adapter.
------
May be someone can explain me why this happens. Paszians writes 110000b to port B4h.
-
May be someone can explain me why this happens. Paszians writes 110000b to port B4h.
This is reset video interrupt. :)
-
I guess the problem are: executing the EnterMice routine need more CPU time, then the next interrupt come in wrong time.
In the XEP128 the timings not emulated yet, then the IRQ come at different point than the real machine.
-
I guess the problem are: executing the EnterMice routine need more CPU time....
This was my first thought, then I removed the EnterMice routine, only parsing the left mouse button on the original parsing routine. I have only easy added a RRCA and a jr nc, label, only three bytes more. The program works normal on the real machine, parsing correctly Joy1 Fire, and later Enter, Space and ESC.
But bit 1 on B6h port gives no activity:
LD A,5 ;B=0
OUT (0B5H),A ;FIRE2
IN A,(0B6H)
RRCA
RR B
XOR A ;FIRE1
OUT (0B5H),A
IN A,(0B6H)
RRCA
;Modification here
jr nc, PRESSED; Joy1 fire or left mouse button suits us here
rrca
PRESSED
;end modification
RR B
LD A,(ALLKEY0+8) ;SPACE on row 8
RLCA
RLCA
RR B
LD A,(ALLKEY0+7) ;ENTER on row 7
RLCA
RLCA
RR B
LD A,(ALLKEY0+3) ;ESC on row 3
RLCA
RR B
LD A,(MKEY)
OR 11111000B
XOR B
LD HL,(KEY)
LD (KEY),A
OR L
XOR L
OR H
LD (KEYPRESS),A
-
Just to test bit 2 of port B6h, I have added one more rrca, with the same null results.
-
Now I have managed the Pasziansz game to work with the old Neos mouse +Boxsoft clone modified to read K column instead of J column. Also it works with the Boxsoft interface made of optocouplers + Neos mouse.
Still PS/2 converters(including EnterMice) didn't work at full, but at least the pointer moves.
-
I hope so, he manages to solve it! :-) Let us wait for it. (Passziansz and Swap would be very good with a mouse!)
-
Thanks, Ep128.
At last I have fixed the movement on all interfaces. Of course it was a silly error from me.
On EnterMice the button still acts a little erratic, only clicking when the mouse is in movement....
On a few days I will have the definitive version.
At the first screen, when the music is playing, press Space to continue.
-
Sorry, not days, minutes. This is the definitive version.
Exit from the music on the main screen must be done with Space when on Entermice. I have tried to call the mouse routine there but it corrupts the music as it adds time to the keyboard capture..
Edit, this is really the definitive version.... now EnterMice mouse button stops the "Pop corn" melody.
Hint thanks to Pear.
-
Added the Pasziansz game to the list of compatible programs inside the EnterMice wiki.
The very first one, but I hope not the last....
-
The problem is that the PS/2 mouse buttons are not connected directly to the terminals in the joystick port.
To close the appropriate contacts EnterMice must first read the status of the mouse buttons.
Updating is triggered by change in the RTS, exactly by the timeout 1.5 ms after the last change of this state.
Hint is, to change the state of the RTS signal and force data reading from the mouse.
You don't have to read data from EnterMice if you not need them, but contacts of buttons in the joystick port will be connected properly.
That's all.
-
I have put an explanation and example on the EnterMice wiki pages (http://wiki.enterpriseforever.com/index.php/EnterMice#Mouse_buttons_reading_without_executing_the_rutine).
-
I did a little correction.
-
It is works fantastic!!!
-
Yes, it works...
Try with the serial card and EnterMice at the same time, it should work indistinctly with the two mice.
-
Original Pasziansz (https://enterpriseforever.com/letoltesek-downloads/enterprise-software/?action=dlattach;attach=16014) game got mouse support by GFlorez, and the game has been made EXOS compatible and recognize Turbo machines by me :)
-
Thanks for the credits...
There was a Paszianz Rom, can you compile this final version to be resident?
I think that the Rom is basically only used as a recipient, as the game is ldir'd to 0100h to act just like the file version.
Or it was EDCW? I don't remember it now....
-
Thanks for the credits...
There was a Paszianz Rom, can you compile this final version to be resident?
I think that the Rom is basically only used as a recipient, as the game is ldir'd to 0100h to act just like the file version.
Or it was EDCW? I don't remember it now....
I think it was EDCW.
-
Link added on the EnterMice wiki pages (http://wiki.enterpriseforever.com/index.php/Main_Page#EnterMice).
-
I think it was EDCW.
And Pasziansz :-)
-
And Pasziansz :-)
Hm, pasziansz also had ROM version? It occupies 4 segments.
-
Hm, pasziansz also had ROM version? It occupies 4 segments.
Yes, there is it (the original).
-
I have added about no more than 300 bytes so, it must fit.
-
I created the packed version of Pasziansz, link below updated. I made compressed version as prerequisit of ROM version, but finally did not create ROM version, because the ROM contains 2 programs, Pasziansz and Kaszino ( I checked ROM after packed version has been finished), so Kaszino should be made EXOS compatible also, and rewrite ROM routines.
-
Kaszino, including sources.
-
Sorry for my ignorance but, what makes a program EXOS compatible?
I think it can't touch Exos zones on ff segment or the interrupt routines at beginning of page 0. Also it must return to main program(Basic) if the reset button is pressed, freeing recurses like Ram.
-
Sorry for my ignorance but, what makes a program EXOS compatible?
Allocating all used memory from EXOS, and don't write directly non fixed memory areas without verify EXOS version. For example, LPT table, Status line, character set are in different locations in EXOS 2.0 and 2.1+
-
I see, this has more to do with knowing what version of EXOS runs the program.
Also, making a program EXOS compatible implies to remove bad programming techniques that can corrupt the system.
Thanks.
-
There are 2 problems with kaszino, 1 is solved, the program use EXOS for VIDEO i tried to allocate the necessary video segments, then OPEN VIDEO gave back insufficient memory, i decided to allocate fc, fd, fe video segment (the program uses all of them) and release fd and fe after allocation, it is good for checking if they are free.
2nd the program uses SOFT IRQ, what if i remember well does not exist in EXOS 2.0.
What should I do, reset the machine on EXOS 2.0, or try to make it work to create a direct IRQ to 0038h on EXOS 2.0, or simply create a patch into EXOS 2.0 IRQ to include the int rut of the game ?
-
Try to patch the IRQ code.
-
Try to patch the IRQ code.
Ok :-)
-
EXOS compatible version of Kaszino (https://enterpriseforever.com/letoltesek-downloads/enterprise-software/?action=dlattach;attach=16041).
It was much harder to convert it to EXOS compatible than SWAP and Passians :lol
SOFT IRQ adaptation to EXOS 2.0 was frozen several times when I recognized I have to put a DAVE 0B4h port reset into the game IRQ, because I patched it into the beginning of EXOS IRQ, and it contains an EXOS call which enables SOUND interrupt.
ROM version is almost finished, I have to add the HELP text of the original ROM, it will not contain the full more than 4 Kb text, because I have 1 Kb free space remained in 32Kb ROM.
-
Good job, you have packed the 64K Rom in only 32K.
-
Good job, you have packed the 64K Rom in only 32K.
Good job made by DTF -cr -lz :)
-
ROM Version (https://enterpriseforever.com/letoltesek-downloads/enterprise-software/?action=dlattach;attach=16042)
-
Kaszino has been modified, scrolling KASZINO text do not leave dirt on the screen, PASZIANSZ ROM also updatet, links below contains the updated version.
-
Rom link added to the EnterMice wiki pages. Aesthetics changes on the list of compatible programs (http://wiki.enterpriseforever.com/index.php/EnterMice#List_of_mouse_compatible_programs_up_to_date).
-
KASZINO had a bug in VIDEO segment request, therefore it started on EP64, and hang, it is corrected, links below are updated. (KASZINO, PASZIANSZ ROM)