Enterprise Forever
:UK => Enterprise DevCompo => Enterprise DevCompo #1 => Topic started by: geco on 2016.April.01. 11:41:17
-
Bricky Prise (https://enterpriseforever.com/letoltesek-downloads/enterprise-software/?action=dlattach;attach=16526) , the idea and name of the game comes from Endi, He created 1st map, and character set of 1st 8 maps , and bat also. Entering HiScore music is created by Szipucsu.
The game is EXOS compatible, and needs at least 128Kb RAM, HiScore is saved at reset (only if you have EXDOS), Mouse support is not implemented, only if you switch it to joystick mode.
This is a simple breakout clone with 44 levels, and it's target will not cause any surprise :D , if you catch ? sign then you will get extra, which can have positive or negative effect also. You can select difficulty level in main menu by using F1-F3 keys, the difference between difficulty levels are ball speed, and rate of positive and negative extra's.
Controls:
- I, O, Space
- int/ext joystick
- F8 clear background
- keys G & A pressed in the same time gives 2 to high value of lives.
- Left Shift: changes the ball's direction a bit
Random level generation between level 2-39.
Loading Screen
[attach=2]
Menu Screen
[attach=3]
Ingame Screen
[attach=4]
-
You can easily implement EnterMice compatibility with this simple Boxsoft routine arranged by Bruce Tanner. It must be called every frame, 1/50 seg. X_REL and Y_REL must be consecutive on memory.
ld hl, X_REL ;first byte, X displacement since last lecture
ld b,3 ;long delay
call READ_8BIT
inc hl ;Y_REL
ld b,2 ;short delay
call READ_8BIT ;leaves B=0
xor a
out (0B5h), a
in a, (0B6h)
and 6
xor 6
srl a ; here the status of J column is on carry, but is discarded
srl a
rl b ; K column is saved in b
ld (SECBUTT_STATUS), a ; L column is the Right Mouse Button
ld a,b
ld (MAINBUTT_STATUS), a ; K column is the Left Mouse Button
ld a, (HL) ;Y-rel
dec hl ;X-REL
or (hl) ;If a=0, no movement
ret
WAIT:
nop
nop
nop
dec b
jr nz, WAIT
ret
;
READ_8BIT: ld a,2 ;RTS low
out (0B7h), a
call WAIT_READ_4BIT ; read four higher bits
xor a ;RTS high
out (0B7h), a
ld b, 2 ;short delay
WAIT_READ_4BIT: call WAIT ;leaves B=0
READ_4BIT:
ld d, b ;d=0
ld b, 4
READ_LOOP:
ld a, b
out (0B5h), a
in a, (0B6h)
rra ;data is read from K column if EnterMice, J if Boxsoft
rra
rl d
djnz READ_LOOP
ld a, d
rld
ret
-
Thx Gflorez, i decided to not implement it, because the bat movement has 2 speed only and it is good for joystick, and makes no sense to make mouse control for this bat moving solution, and other, reading the mouse is quite CPU consuming task even with this fast code.
-
Ok, it was only an hint....
-
Ok, it was only an hint....
Thx :-) I will use it in the future :-)
-
Another free hint:
For an horizontal movement like of this bat, you only need the X movement, the first two nibbles that are read. Nothing happens if the third and fourth nibbles are not read, at the following cycle at the next frame the first and second nibbles will be X again. The Mouse or the EnterMice interface restarts every cycle. You only have to ensure that you leave the RTS signal high.
This way the routine last only a little more than half the total time, as you still have to read the button. Also you can process 1, 2 or none buttons if necessary.
-
By the way..... Your game is wonderful...
-
Your game is wonderful...
And it is have a stereo sound effects! I think this is the first real stereo game on Enterprise! The left/right volume are depending from the screen position where the event occurred.
-
Wow, nice work! Looks like a proper Enterprise game
-
Nice:D
However I don't like the natural bounce mechanism of the ball when it hits the paddle. The creators of the original Pong also didn't go with that. They didn't go with the basic principle that the angle at which you hit the wall should be mirrored when you bounce off. They used an algorithm that worked as if the paddle had an elliptic surface... I think that you should also change the algorithm used as the game can get "boring" when you are left with one brick to clear the level. Also it's somewhat unintuitive for me that when you catch the ball on the right side and you release it it will bounce to the left because last it went from the right side... I don't know if anyone knows what I mean...maybe it's just my problem...
The change in the algorithm should make the ball more unpredictable (you don't know the exact angle) but at the same time also in some way more controllable (you will be able to control the direction of the ball)
In the appendix of the article below there should be some description of the algorithm...:
http://www.jgorasia.com/Files/Spring08/ICB/Gorasia_Harris.pdf
Basically the algorithm takes into account the distance of the ball from the center of the paddle when calculating the angle.
-
I continue with my "totally free" hints....
To save some time, the external joystick 1 can be read at the same time, it is at bit 0(J column) of port B6, and EnterMice is read at bit 1(K column) of the same port, rows(B5) 1 to 4.
Only that Entermice needs to be accessed two times(nibbles) between a short pause to compose the full X byte, and the external joystick only one.
-
Bricky Prise (https://enterpriseforever.com/letoltesek-downloads/enterprise-software/?action=dlattach;attach=16526) has been changed, one problem was corrected : or 30h was used after in a,(0b6h), now it is or 0feh
and Pause for ESC key has been added, the original link has been updated also.
-
Nice:D
However I don't like the natural bounce mechanism of the ball when it hits the paddle. The creators of the original Pong also didn't go with that. They didn't go with the basic principle that the angle at which you hit the wall should be mirrored when you bounce off. They used an algorithm that worked as if the paddle had an elliptic surface... I think that you should also change the algorithm used as the game can get "boring" when you are left with one brick to clear the level. Also it's somewhat unintuitive for me that when you catch the ball on the right side and you release it it will bounce to the left because last it went from the right side... I don't know if anyone knows what I mean...maybe it's just my problem...
The change in the algorithm should make the ball more unpredictable (you don't know the exact angle) but at the same time also in some way more controllable (you will be able to control the direction of the ball)
In the appendix of the article below there should be some description of the algorithm...:
http://www.jgorasia.com/Files/Spring08/ICB/Gorasia_Harris.pdf
Basically the algorithm takes into account the distance of the ball from the center of the paddle when calculating the angle.
I chosed other solution, you can control the direction of the ball by moving the bat when the ball reach it (increase/decrease the angle)
-
Small update happened:
Cheat: press G & A key simultaneously high value of lives will change to 2, if you used cheat then hiscore save is disabled.
F8: delete background palette of the game, if you did it once, the palette can not be restored, it will be restored at next level, or if a new game started.
The links has been updated.
-
I chosed other solution, you can control the direction of the ball by moving the bat when the ball reach it (increase/decrease the angle)
Oh, now I see. Haven't noticed that yesterday :oops:
Looks better without the "gradient" background IMO :P
Fun.
The sampled sfx give it a 16-bit feel...
-
Update: Random level generation between level 2-39.
Left shift: changes the ball's direction a bit, it is useful if the ball is remaining in the same way, and cannot reach the bat.
Package updated at downloads, and all related links have been refreshed in this topic.
-
A curiousity with the game is that to pass the title screens it can be done with both mouse buttons, bit 1 and 2(K and L columns) of row 0, not commonly used.
-
A curiousity with the game is that to pass the title screens it can be done with both mouse buttons, bit 1 and 2(K and L columns) of row 0, not commonly used.
You asked it to check b0,b1,b3 earlier , and I have done it :)
-
This means you are considering to adapt your beautiful game to EnterMice movement?, the honour to make the first game that use a mouse in the EP history....?
But wait, I already know your actual answer....
Meanwhile, let me try to convince you.....
This is a MSX mouse routine(Boxsoft, Entermice, all are the same), that only reads X increment and two buttons. It must be called at least every 1/50 sec or more to work. It takes almost half the time of the entire MSX routine, only two cycles of lectures on the B6h port, and is used also to read the Joystick 1 at the same time:
MSX:
ld hl, X_REL ;first byte, X displacement since last lecture
ld b,3 ;long delay
di
call READ_8BIT
ei
; Y movement not used here
xor a
out (0B5h), a ; row 0
in a, (0B6h)
and 7 ;bits 2, 1 and 0
xor 7
srl a ; here the status of J column is on carry
rl c ; J column is saved in c
srl a
rl b ; K column is saved in b
Inc hl
ld (hl), a ; L column is the right SECBUTT_STATUS
inc hl
ld a,b
ld (hl), a ; K column is the Left MAINBUTT_STATUS
inc hl
ld a,c
ld (hl), a ; Joy 1 movement and fire is now on JOY1_STATUS(000RLDUF)
ret
WAIT:
nop
nop
nop
dec b
jr nz, WAIT
ret
;
READ_8BIT: ld a,2 ;RTS low
out (0B7h), a
call WAIT_READ_4BIT ; read four higher bits
xor a ;RTS high
out (0B7h), a
ld b, 2 ;short delay
ld c,0; c is reset as we only need to read joy 1 on the second nibble
WAIT_READ_4BIT:call WAIT ;leaves B=0
READ_4BIT:
ld d, b ;d=0
ld b, 4
READ_LOOP:
ld a, b
out (0B5h), a
in a, (0B6h)
rra
ccf ; we need joy 1 port complemented
rl c ;data is read from L column
rra
rl d ;data is read from K column
djnz READ_LOOP
ld a, d
rld
ret
X_REL: db 0
SECBUTT_STATUS: db 0
MAINBUTT_STATUS; db 0
JOY1_STATUS: db 0
Still not tested. Once returned you can limit the increments to make the game more hard, like with the joystick.
-
In the beginning I planned, and Zozo asked it also, but at the end i decided to do not implement it, because of space issues, and the mouse would work also like a joystick, the program would not check the speed of the mouse, just the direction.
-
For more space, it would be possible to use about 1 KB from the EXOS stack (FF:AC00-AFFF). Also, compressing the two largest blocks with epcompress -raw -m0 -9 instead of the default -5 saves 68 bytes. That is not much, but it is better than nothing. And the code from decompress_m0.s could probably be optimized better for both size and speed. :oops:
-
You don't need to check mouse speed, only cut increments greater than a given magnitude. For example, the mouse can return you +127 to -128 increments, but you can put the top on +10 to -10, i.e. greater than that are cut to ± 10.
This will give the max speed you want.
You even can exaggerate the speed to make the game more difficult.
-
For more space, it would be possible to use about 1 KB from the EXOS stack (FF:AC00-AFFF). Also, compressing the two largest blocks with epcompress -raw -m0 -9 instead of the default -5 saves 68 bytes. That is not much, but it is better than nothing. And the code from decompress_m0.s could probably be optimized better for both size and speed. :oops:
Hmm, i have played with compression levels only in the beginning in the last few years i always used the default :ooops
There would be enough space for the code I think, because I found about 340h bytes fre in the 3rd video page, now about 200h is free, but i do not see advantage of implementing mouse, because there is no speed check in the game only direction, if you move the joy into a direction then the bat moves 1 unit into that direction, if you press fire also then it moves 2 units.
We could save probably more space by optimizing game code (possibly speed also :D ), i am not a great coder, something I can do, and a lot of things I can't :D ( and do not check the code :D )
-
You don't need to check mouse speed, only cut increments greater than a given magnitude. For example, the mouse can return you +127 to -128 increments, but you can put the top on +10 to -10, i.e. greater than that are cut to ± 10.
This will give the max speed you want.
You even can exaggerate the speed to make the game more difficult.
Yes, but in this case you can switch Entermice into joystick mode, and the mouse is working as a joystick (if I know well this option exists in entermice also ) this is the reason why i do not see advantage of implementing the mouse.
-
Even if you limit the increments as I said, the result is not the same as joystick emulation.
Movement with mouse is more accurate and softer. You command the bat to directly stay where you intuitively want it to be, not the direction where you want it to go.
I remember the original Arkanoid arcade machine to have a rotary controller to move the bat. Is only for it that I insist so much....
(https://s-media-cache-ak0.pinimg.com/564x/2f/5e/d0/2f5ed0df4670fd22ebe2164d911276b8.jpg)
-
B D F character could not be chosen bug repaired at entering hi score, repaired version (https://enterpriseforever.com/letoltesek-downloads/enterprise-software/?action=dlattach;attach=16526)
-
Even if you limit the increments as I said, the result is not the same as joystick emulation.
Movement with mouse is more accurate and softer. You command the bat to directly stay where you intuitively want it to be, not the direction where you want it to go.
Bricky Prise with mouse support:
[attachurl=1]
This is a rather ugly hack, however, and it may crash or have other problems (edit: it definitely breaks the digital sound effects), it is only to show what the game might be like when controlled with a mouse. The movement speed is limited to +/- 4, twice as fast as what is possible with the keyboard, but this range could easily be changed.
-
újabb emu-s snapshotot légyszi :)
-
újabb emu-s snapshotot légyszi :)
:???:
-
I like your ugly hack!
With +-4 it seems more or less as difficult as the joystick controller.
It is a wonderful game, even more when played with a mouse.
-
újabb emu-s snapshotot légyszi :)
People who speak Hungarian here will be fined. :ds_icon_cheesygrin:
Unfortunately the snapshot didn't load in my PC either. But the other new snapshots did so far.
-
Unfortunately the snapshot didn't load in my PC either. But the other new snapshots did so far.
The snapshot was saved with ep128emu 2.0.10 (https://sourceforge.net/projects/ep128emu/files/ep128emu2/ep128emu-2.0.10/) (not beta; by the way, I wonder why "ep128emu-2.0.10_cmos-x86_64.tar.xz" is downloaded so much?). The snapshot format is compatible between different operating systems and CPU architectures, a snapshot saved on Linux should load on Windows, which I tested as well. You may be using an old (beta) version of the emulator, or it could be some Windows problem.
I like your ugly hack!
With +-4 it seems more or less as difficult as the joystick controller.
The main difficulty is in finding free space for the mouse code, there does not seem to be any that I am sure it is really unused on the segments visible at the time when keyboard/joystick input is read. The hacked version temporarily pages in the system segment (FFh), and the new code is on a part of the EXOS stack that I hope is not used by Bricky Prise (but even that assumption might not be correct). Of course, code running in video RAM is much slower, and because the memory paging is changed, I disable interrupts, but this breaks digital sample playback which needs interrupts at a high frequency. There are also some other issues I did not debug yet.
-
I do not remember either where are empty areas in the memory, I think there should be just enough for mouse driver.
-
Another free hint:
For an horizontal movement like of this bat, you only need the X movement, the first two nibbles that are read. Nothing happens if the third and fourth nibbles are not read, at the following cycle at the next frame the first and second nibbles will be X again. The Mouse or the EnterMice interface restarts every cycle. You only have to ensure that you leave the RTS signal high.
This way the routine last only a little more than half the total time, as you still have to read the button. Also you can process 1, 2 or none buttons if necessary.
Also you can easily fuse the Joystick reading routine with the mouse routine to gain space and time. I did it on the SWAP game modification.
-
I do not remember either where are empty areas in the memory, I think there should be just enough for mouse driver.
Perhaps I can use the space of the decompress_m0 routine (2829h-2A04h) when it is not needed, it is 1DCh bytes, which is plenty enough. And when decompressing needs to be done, I temporarily copy the decompressor from the EXOS stack (is FFh:AC00-AFFFh really unused in Bricky Prise?), then the new code is copied back again. Also, the original drawing routine at 216Fh-21BDh can be overwritten with other code, since it will be moved to the place of the decompressor as well, with changes to support movement greater than +/- 2.
-
I can send you the sources, if you do not get heart attack when you see it :D
-
nekem ez a snapshot se megy, és a futatható program se, kell hozzá valami rom-ot berakni?
-
(original package, hopefully it is up to date)
I checked, this is the latest release, date of the program is 10.11.2016
-
I found and fixed some problems with the extras that use self-modifying code, there will be an updated version soon. I also made it possible to use the mouse to enter the name in the high scores, the only place where it does not work now is to start the game.
-
The EnterMice "wired" buttons don't reflect their status if RTS is not moved. It is just because the Atmel chip converts the PS2 data to MSX protocol only when the RTS is triggered. On the Original Boxsoft interface the two buttons are really wired.
Try this (http://wiki.enterpriseforever.com/index.php/EnterMice#Mouse_buttons_reading_without_executing_the_routine).
-
I found and fixed some problems with the extras that use self-modifying code, there will be an updated version soon. I also made it possible to use the mouse to enter the name in the high scores, the only place where it does not work now is to start the game.
Was it in the original also, or just after mouse implementation?
Do not need you the source?
-
Was it in the original also, or just after mouse implementation?
It was not a problem in the original. I changed various bits of code that I was not aware of being modified from elsewhere in the program (mostly when the various extras are activated by the "?" bricks), so that caused crashes in the mouse enabled version. I fixed these where I found them, but I could still have missed some. The specific extras that I patched are the one that inverts movement direction (it writes into the input code), and another that allows the player to shoot the bricks (this modifies and calls the drawing code, where I also made changes). However, if there are no more bugs to be fixed, I think the source is not needed now.
The EnterMice "wired" buttons don't reflect their status if RTS is not moved. It is just because the Atmel chip converts the PS2 data to MSX protocol only when the RTS is triggered. On the Original Boxsoft interface the two buttons are really wired.
The reason why the current version of the game with my modifications cannot be started with the mouse is that this part of the game uses a separate routine for reading the input, while everywhere else the one at 1B00h is called, and I patched that. For the title screen, additional patching would be needed, but it also seems the digital music playback really slows down the code there, only a few Z80 instructions can be executed on a 4 MHz machine before another IRQ occurs. I wonder if this would cause problems with the timing or performance if I tried to add mouse input there.
By the way, in the EnterMice documentation, what does the standby time mean exactly?
Time from change state of RTS signal to issue data (nibble) for reading 25 μs
Standby time for the next reading (counting from data issue) 14 μs
Does it mean that there has to be at least 39 us (25 + 14) between RTS state changes, or 14 us (if the nibble data is ignored), or something else?
-
Another new change is that the mouse timing will be configured according to the speed of the machine (number of 1 kHz DAVE interrupts per video interrupt). This currently sets somewhat conservative timings because of the simple arithmetic used and all the rounding done in the direction of waiting more, but it is still better at 4 or 6 MHz than a version with hardcoded wait loops for some high frequency like 10 MHz, and in theory it works at up to 20 MHz. :)
-
By the way, in the EnterMice documentation, what does the standby time mean exactly?Does it mean that there has to be at least 39 us (25 + 14) between RTS state changes, or 14 us (if the nibble data is ignored), or something else?
Pear can answer it better, but you must think EnterMice like a car's engine.
-If no RTS signal, the interface stops to work.
-If found RTS but not sync, the interface is on Idle but at least the "wired" buttons are send.
-If RTS is in sync, the interface is running and the "wired" buttons, X and Y deltas, and all the other software buttons and wheel (if present), are send.
-
Updated mouse hack, it still needs more testing, but it works better:
[attachurl=1]
[attachurl=2]
[attachurl=3]
[attachurl=4] (tape version for those with loading problems :razz:)
Source files:
[attachurl=5] (original package)
[attachurl=6]
[attachurl=7]
[attachurl=8]
How to create the patched version:
- unpack the .zip file
- compile bricky_patch.s (sjasm (http://xl2s.eu.pn/sjasm.html) 0.39g6)
- run the Lua script in ep128emu (requires >= 128K configuration), the file I/O directory (Alt+F) should point to the location of all the source and program files
- BRICKY.COM and BRICKY.PRG are now patched with mouse support
Changes:
- fixed bugs that caused crashes in some extras, but there might still be more issues
- the mouse can be used to continue after "game over" and to enter your name in the high scores
- optimized mouse I/O, timings are configured according to the CPU speed (> 20 MHz is not supported), only one data byte is read during gameplay; this needs to be tested on a real machine
-
I can't get out of this bouncing. I think that some sort of random angle must be added.
-
It seems that using the left Shift key does randomize the movement of the ball, but I need to check where this happens in the code. Actually, this is a documented (on ep128.hu) feature of the game.
-
nálam továbbra is:
---------------------------
ep128emu error
---------------------------
incompatible Nick snapshot format
---------------------------
OK
---------------------------
-
Are you using 2.0.10 non beta? Look at Help/About.
-
ep128emu version 2.0.9
ti adtátok a linket hogy ez a legújabb :P
-
It seems that using the left Shift key does randomize the movement of the ball, but I need to check where this happens in the code. Actually, this is a documented (on ep128.hu) feature of the game.
Ok. Left shift works.
---------------
Also I have observed that the 64 bit 2.0.10 version refuse your snapshot as incompatible. The 32 bit 2.0.10 version loads it correctly.
-
ep128emu version 2.0.9
It is 6 years old...
2.0.10 (https://enterpriseforever.com/ep128emu/ep128emu-2-0-10/msg59635/#msg59635)
-
It is 6 years old...
2.0.10 (https://enterpriseforever.com/ep128emu/ep128emu-2-0-10/msg59635/#msg59635)
adtatok egy linket, én meg leszedtem onnan :)
-
Also I have observed that the 64 bit 2.0.10 version refuse your snapshot as incompatible.
That is probably an old beta version. When multiple instances of the emulator are installed without deleting the older version(s) first, it is easy to lose track of what is installed where, but you can always check the real version in "Help/About", as Zozosoft already suggested. If it says something other than "ep128emu version 2.0.10" (without "beta"), then it is not up to date.
adtatok egy linket, én meg leszedtem onnan
The link in this post (https://enterpriseforever.com/enterprise-devcompo-1-37/enterprise-program-bricky-prise/msg59726/#msg59726) definitely points to 2.0.10, I do not know where the 2.0.9 download was posted, but even then it should be obvious that it is old from the release date in 2011. :)
-
ep128.hu (http://www.ep128.hu/Ep_Games/Games_AB.htm) still seems to have the buggy version from 17th that crashes on some of the extras. :oops:
-
na végre működnek a snapshotok
tök jó egérrel a játék :)
-
és a futatható program se
There is actually a new bug in the file I/O code related to reopening the file if it is read-only, this can fail if the file was selected with a file chooser dialog. :oops: It looks like a 2.0.10.1 version will be needed, especially since there are also a few FLTK issues on Linux, and a new 1.3.4 version of FLTK has been released recently.
-
https://youtu.be/-q8d8XWXnyA