 Previous Messages |
Posted By
Gaia
on 2011-05-04
01:51:51
|  Re: Yape 1.0 bugs and suggestions.
There were at least 2 versions, one was wired to $FF08 (which is the Trojan Lightpen if memory serves) and another homebrew one (presumably mapped around $FD40 or so... I will have to check). But from what I could see so far is that this one here from Moldi is likely just a translated version of the SW for the homebrew package (that used to be hosted at the GOTU homepage). Noone had the Trojan version in Hungary, I myself had a homebrew one from (East!  ) Germany.
I used to have a more or less working implementation in Yape but I never included it in a release because it just sucked so badly (and this matched my experience with the lightpen in the 80s )
|
|
Posted By
Luca
on 2011-05-03
15:08:34
 | Re: Yape 1.0 bugs and suggestions.
Uh...I guess the standard one is the Trojan Light Pen, and all the other homebrew are similar...
|
|
Posted By
Gaia
on 2011-05-03
14:11:36
| Re: Yape 1.0 bugs and suggestions.
Oh, now I see.... Which lightpen variant is this one using?
|
|
Posted By
Luca
on 2011-04-30
16:01:33
| Re: Yape 1.0 bugs and suggestions.
Re: Yape 1.0 bugs and suggestions./For the drawing tools that use it.
|
|
Posted By
Gaia
on 2011-04-30
15:50:08
| Re: Yape 1.0 bugs and suggestions.
Lightpen? What for?
|
|
Posted By
Luca
on 2011-04-30
09:44:15
| Re: Yape 1.0 bugs and suggestions.
I'm officially asking for a lightpen emulation via mouse to be implemented in YAPE V1.01
|
|
Posted By
SVS
on 2011-01-25
16:40:02
 | Re: Yape 1.0 bugs and suggestions.
@Csabo:
Yape can manage real disks or IEC disks (that are PC folders).
IEC is much faster but cannot, for example, handle SEQ files.
If the running program can detect which device is connected, then it could "decide" how to behave (of course if it is coded so). This opens great horizons for flexible programming.
Similar facts are for printers.
@siz:
If flags are stored in a ROM unused byte, the compatibility is maintained because that byte could remain with the same value of iron (when Yape option is not enabled). In other hand, suppose the byte is $00 on real Plus4, we can set $00 to indicate flags option is off. Gaia would be facilitated because the use of option has not to be set somewhere else.
|
|
Posted By
Csabo
on 2011-01-25
14:48:28
| Re: Yape 1.0 bugs and suggestions.
I agree with siz on the hardware flags. The drive can be detected, and if a program supports printing for different printer types, it should probably ask the user for the printer type.
This leaves emulator version and speed. I'm okay with those Though if Gaia says there can only be one byte, we should just leave speed. I can't think of any practical uses for emulator version.
|
|
Posted By
siz
on 2011-01-25
06:58:19
| Re: Yape 1.0 bugs and suggestions.
Hi SVS!
I don't know what do you want to use this information for but that would result in emulator-only apps. It seems to be better if you detect these information in a way that is compatible with the original hardware if you need them. Just my opinion.
|
|
Posted By
SVS
on 2011-01-25
04:19:51
| Re: Yape 1.0 bugs and suggestions.
Thank you Gaia for support.
1) I confirm the problem with Printing when compatibility is set less than "Very accurate". Tests come from my current project that uses complex printing outputs.
2) I explain with an example: You have set an IEC path saved on INI file. After Yape loading, you save a program by SHFT-F8 (you navigate and set a proper folder). After this operation, printing output goes to this last folder, ignoring the INI setting.
Requests:
1) Me too I agree with MMS. Support for WIN VISTA doesn't worth.
2) This feature has to be optional of course. One can use it or not, depends from what he's doing. If you want, you can set default off.
There are some locations (even in ROM) that are unused (see Ultimate-map) we can use them if this is not a problem (is there a checksum?). About flags content, my suggestions are:
- Emu speed: $0=warp $1=100%; $2=200%; $3=300%; $82=50%; $85=20% (these values are chosen to facilitate, from code, their direct use as divisors/multipliers)
- Printers setting: $0=any; $1 ASCII; $2=802 IEC; $3=803 IEC; $82=802 CPU; $83=803 CPU
- Yape version: $10=ver 1.0
- Disks: $0=any; $4=1541 IEC; $5=1551 IEC; $84=1541 CPU; $85=1551 CPU
The above ones are my idea, of course other pals can suggest new ones (Sound, screen, etc.) or modify them.
|
|
Posted By
MMS
on 2011-01-24
16:48:15
 | Re: Yape 1.0 bugs and suggestions.
I think you should drop Vista support. It is slow, resource hungry and people do not like.
75% of users use XP. All the Vista guys switch to Windows7 now or soon.
And all the Geeks uses Linux
BTW a nice Linux release with all the nice things preinstalled:
http://www.zorin-os.webs.com/
|
|
Posted By
Gaia
on 2011-01-24
09:38:39
| Re: Yape 1.0 bugs and suggestions.
Thanks for the feedback, SVS. Sorry for the belated reaction.
1) The only level where printer emulation does not work is 'Fast mode - low compatibility'. It works fine in 'Good compatibility mode' for me. Are you sure about this bug?
2) This is odd, since the printer path is a resource variable in the INI file and is initialized at turning on the printer. I couldn't reproduce this bug. Are you sure about it?
As per your requests:
1) This is not supported by the Windows API, maybe the new Vista IFileDialog API does have support for it, but that would require a lot of work (making the same thing twice) or otherwise nothing will work below Vista.
2) I know you want this, but it would break the HW compatibility - in case it's unused by the KERNAL, that does not mean anything, since other programs/demos may depend on those unused areas. So even if it gets implemented, it'll be optional only, perhaps the now useless emulator ID will be sacrificed, I'll see. But be more specific please on what else you want ("etc").
|
|
Posted By
SVS
on 2011-01-19
02:31:29
| Yape 1.0 bugs and suggestions.
Just to write down notes for next release:
1) Printing works without problems only is emulator mode is "very accurate";
2) Printing output folder is modified by utilization of F8/SHFT-F8: System does nomore use the path setup in Yape setting, but last path used.
Requests:
a) Restore last used size/location for F8/SHFT-F8 window
b) Yape optionally sets a memory location (unused by +4 O.S.) with its settings flags (speed, etc.) in order to allow running +4 code to know them *** This argument was discussed in the forum some weeks ago ***
Thank Gaia.
|
|
