Posted By
SVS
on 2011-08-27
03:39:34
 |  Yape 1.0.2 testing
Hello Attila,
I notice the followings issues to be fixed:
a) Each new print is always added under previous one, even if previous one was made by a different *finished* program or Yape was reset after it.
b) After a certain number of printed lines (72?), window page is cleared and restarted in a new white space.
c) Interline setting does not work. It is essential for printing bitmaps. (The vertical space is 1/6" standard with an empty pixels line in order to separate different characters lines. But in bitmap mode it has not be inserted, in order to obtain a solid image [1/8"]).
|
|
Posted By
Luca
on 2011-10-20
05:10:13
 | Re: Yape 1.0.2 testing
Sett Of Demo runs in a different way depending on the chosen compatibily level: it seems to work (but with flickering screen) in fast emulation, works slower in good emulation due to some rastertime issues, does not work in complete emulation.
|
|
Posted By
Gaia
on 2011-10-20
15:32:38
| Re: Yape 1.0.2 testing
Thanks. I need some time for the printer issues (not sure I understand them entirely).
Luca: the program you are mentioning is setting the TED freeze bit in FF07. Now, TTBOK this - and I quote -
"stops TED from incrementing
the horizontal position, the timers and the vertical position. The system
is forced into single clock (894KHZ) and system refresh of dynamic rams."
Yet, the program is stuck in an endless loop waiting FF1D to reach a certain value (which it will not of course). The other emulation levels do not emulate this flag (fully). I need to have a look but I have very limited access now to real HW  (and no transfer! damn)
EDIT: hmm... looking at it a little I think this program should not work at all, actually...! So this ought to be the expected behaviour (though I am not sure of course)
|
|
Posted By
SVS
on 2011-11-01
14:29:26
| Re: Yape 1.0.2 testing
Further issue for printing:
d) Printer output path and a possible driver path are the same. That is: if you set a path for a PC folder, say, for driver#9 and then you set a path for printing output, this last one is set for driver#9 too (and viceversa).
It seems that only one path for PC is stored by Yape.
|
|
Posted By
Gaia
on 2011-11-18
15:28:33
| Re: Yape 1.0.2 testing
Thanks, I had a look at d), and it was hard to decide whether it was a bug or meant as a feature  Anyway, this gets fixed in the next release
|
|
Posted By
Luca
on 2011-11-26
07:41:20
| Re: Yape 1.0.2 testing
I tried several times to load (1541 CPU, with/without ACIA active) Infinity and it has jammed all the times where the pic is displayed and the trackmo has to load.
|
|
Posted By
Gaia
on 2011-11-26
15:17:46
| Re: Yape 1.0.2 testing
Thank you Luca for the heads up. Unfortunately, I am not able to reproduce the error, i.e. it does work at my end... I do recall this demo being notoriously unstable on the real iron, too, which was later discovered (by Istvan) to be caused by the effect preceding this very screen that you copied here. I don't know by heart anymore what exactly caused it (some 0x55 data in the bitmap causing conflicts in the loader by coinciding with the control byte that is used by the KERNAL to check if a 1551 drive is present).
PS: I loaded the demo with the 'inject first PRG from D64 directly into the memory' option turned on.
|
|
