Posted By
Gaia
on 2002-12-03
|  New Yape bugfix release soon!
I am about to release a strictly bugfix version of Yape soon. What's already corrected:
- full screen crash on some machines (mainly NT)
- various sound glitches
- reload emulator ID setting from INI file
I am really eager to fix those nasty SEQ and PRG loading bugs in the parallel port 1551 emulation but I'm afraid it'd take some (=too much) time....  Any bugs you guys know and I am yet unaware of? (note: bugs, not missing features)
Thanx
|
|
Posted By
SVS
on 2002-12-04
 | Yooo... Attila, BTW please please fix the loader bug!
LOAD "nnn",8 and DLOAD "nnn" must load the code on the current standard address ($1001 or $4001) whatever is your stored address in the first two bytes.
Only when ",1" flag is present on LOAD, or with monitor command "L", the stored address have to be used for relocating load.
Thank you very much and best greetings
|
|
Posted By
Gaia
on 2002-12-04
| IEC
I'll try and have a look... The difficult thing is not loading to the address
specified by the $2B/$2D vector but to catch that extra ",1" parameter in
those nasty IEC commands. Any hints?  I'd rather not start debugging
now as it takes quite a while....
Would be nice to support the SEQ files in 1551 mode while I'm at it....
The problem there is similar to the one mentioned above. Basically it
would not be a good idea to reimplement the whole IEC protocol when a proper
processor level drive emulation would handle it all by itself but it's
still easier to debug and will always be much quicker.
Anyway, enough of lamenting, thanks for your help!
|
|
Posted By
SVS
on 2002-12-04
| Load problem possible solution
You could intercept the call to Kernal "SETLFS" routine ($FFBA). When called for a load operation, .Y is: $00 for standard address; $01 for relocating address.
That is if .Y=$00 then consider the address in $2B, $2C and ignore the first 2 bytes of the file to be loaded.
TNX!
|
|
Posted By
Noro
on 2002-12-04
| A non-bugfix Yape wish
Hi Ati,
I would love to get the fire button of the joystick emulation to a key left of the cursor block. e.g. right alt.
Is there any chance to get this, maybe via a setting in the .ini?
TIA
|
|
Posted By
Gaia
on 2002-12-04
| Responses
Noro: It WAS once on the right CTRL key, but I've moved the C= there instead a while ago... The plan is once to be able to remap the joystick/keyboard completely and store it in the INI file, but that'll need a helluva lotta work
SVS: I'd rather not place KERNAL traps for the sake of this feature (I'm at the moment not using any). Instead I catch the bytes that are going thru ports FEF0, FEF1 and FEF2. There must be a way for it on the protocol level. I _think_ the secondary address of the IEC command OPEN (high nibble is $F0) is the one to shoot for (thus: $F1 - open with start address given, $F0 - open without address), but I'm only guessing here, I have to check this at home. The IEC OPEN command is at least always called with a secondary address (ie. $F1) as I remember. Am I right? If yes, I could check for this secondary address and then simply throw away the first two incoming data bytes and put there what's at the BASIC start vector ($2B/$2C). Looking at the ROM disassembly of the 1541 would also help a lot, but it's also rather time consuming...
|
|
Posted By
Gaia
on 2002-12-04
| Not a bug....
SVS: Sorry I checked it at home and still I have to say, that on the protocol level there's no difference between the 2 kinds of LOAD commands. It is rather distinguished by the BASIC interpreter/system kernal (whatever). The byteflow is exactly the same in both cases.
Also, I wrote in a program that simply does :
10 GRAPHIC1:GRAPHIC0
Then saved it with DSAVE. Then I made a RESET and a DLOAD and the program loaded back correctly to $1001 while checking the first two bytes in the PRG were $01 and $40....
You might have done something wrong?
|
|
Posted By
JamesC
on 2002-12-04
| Atilla -->
Can you make Emulator ID on by default?
And what will be your preferred way to detect the use of the emulator?
SVS has a program in Beta test that we can code this feature into, and have response by the end of the year.
|
|
Posted By
Csabo
on 2002-12-04
| Defaults
As long as we're on defaults, how about making 50 fps the default?
|
|
Posted By
JamesC
on 2002-12-04
| Csabo -->
I thought 50fps *is* the default! Am I wrong? Does YAPE default to 404% and 85fps (the maximum my AMD 1.2GHz system can push it)?
|
|
Posted By
SVS
on 2002-12-05
| more Defaults...
should be good the INI file stores the work-folder too (last selected) 
TIA
|
|
Posted By
Gaia
on 2002-12-05
| INI file
Storing the work folder: good idea, I think I'll
implement it.
Refresh rate: well, 50 HZ is the default for a real
PAL machine and 60 Hz for NTSC. Not exactly though
as both mode uses scanline interleaving (AFAIK). Yape
defaults to a maximum of 85 simply because most
monitors are running below this refresh rate anyway
and I can save some CPU power for the emulation of the
CPU of the plus/4. It is therefore not determined by the specs of
anyone's PC but rather Yape itself (of course if your PC is slow
this value won't even reach 85).
Why would 50 Hz be the default?
There's another fix/feature (I'm not sure here) I've
forgotten to mention: the new release will always read
the INI file from the same folder where the program was
started from (ie. where the YAPE.EXE is located...).
Would this solve these default setting issues? Cause
this way once you have your INI file in your YAPE
folder, it'll always be able to read from it no matter
how you started it up (eg. by clicking on a PRG).
|
|
Posted By
Noro
on 2002-12-05
| 50 fps
I think it is not the matter of fps, but machine speed.
If Yape does not find an .INI file, it defaults to maximum, not 100%.
This is if you associate .prg with yape and then start a game
from a directory without an yape.ini.
|
|
Posted By
Gaia
on 2002-12-05
| Difference between FPS and CPU speed
There's a difference between the FPS and the actual speed of the emulation. Let me clarify this:
Emulated CPU speed: shown in %, represents the actual speed of the emulated CPU compared to a real 7501/8501.
FPS: shown as frames per second is just the number of screen refreshes per second. Does NOT necessarily relate to the speed of the CPU (more on this below).
Yape, when started without an INI file, by default does not limit the CPU speed but does limit the FPS to 85. In a way there's a correlation between the two, however. If the CPU is to slow (either because of your settings or because of a slow computer) the FPS can of course also not catch up with it (it can't simply be ready).
So when the emulated CPU speed is above ~170%, the extra frames are just simply thrown away by YAPE.
|
|
Posted By
JamesC
on 2002-12-05
| Atilla -->
I installed YAPE to a computer at work last week. When running from a DOS prompt (Win98 on this system), YAPE.ini is created in the YAPE directory. However, when I created a Desktop Shortcut within Windows, and used the Desktop Shortcut to launch YAPE, there was a new YAPE.ini created on the Desktop when I adjusted and saved settings.
Shouldn't YAPE be updating the existing .ini instead of writing a new one?
And a congrats to you -- this was the only Plus/4 emualtor that worked halfway decently on a 233MHz machine. YAPE runs at half speed, but at least it keeps up with my fingers. All the others lost characters when I typed.
|
|
Posted By
Gaia
on 2002-12-05
| INI file revisited
I emphasize that this was indeed a "bug" in all versions so far including 0.41 and I've just corrected this for 0.42 (to be released soon): YAPE checked for the INI file in the actual folder (can be anything, not necessarily the startup folder) and if not present a new INI was created in the currently valid folder....
As for typing: Windows keypress events are scanned by YAPE whenever a new frame is rendered by TED. The keyboard matrix of the plus/4 is then updated. That is, within a certain limit all keys pressed will be kept for good Another method is to scan the status of the _whole_ keyboard of the PC every time the keyboard latch is read by the emulated machine. This would be a more efficient way providing the status of the keyboard in the exact moment when it's needed and would probably also allow faster emulation. However I think it would lose keypress events on slower machines (as you have to type in similar velocity as how the emulator is expecting it), I'm not sure which method other emu's are using, but probably this latter. Considering the positive feedback you've just given (which I appreciate BTW! ) I still think one should go for this second way as it gives optimal performance on 100% speed. This is how inefficient coding can sometimes become an advantage, you see??
|
|
Posted By
SVS
on 2002-12-07
| Attila: More info about load bug
Ciao,
I made further deep tests on this problem. The results are:
a) DLOAD, LOAD commands work as well;
b) The manual load (by menu or by [F8] is affected by the bug, that is: it always loads on the relocated address (stored in the first 2 bytes of the files).
---* Another important fix to do:
Whatever you set the standard folder by menu, if you do a SAVE operation the file goes into the system directory. To obtain it goes into the folder you did specify, you first have to do a manual load operation (by [F8]).
Thanx Attila, and feel free to ask me any further info you need.
S\_/S
|
|
Posted By
Thomas
on 2002-12-07
| Full screen crash
@Attila: good you're correcting that full screen crash.
Neither under Windows 98 SE nor under Windows 2000 nor under Windows XP I can run Yape in full screen.
But at least Windows XP doesn't crash.
|
|
