| Posted By
Csabo
on 2025-04-16
05:38:07
|  YAPE 1.2.6!
If you had issues with the last version of YAPE, worry no longer: Gaia is here with version 1.2.6, which is a much anticipated bugfix release.
* D82 image support in IEC mode
* Automatic line feed bug fixed in MPS801/803 mode
* Re-enabled attach disk image in 1551 mode
* Sound device selection fix
* TED sound frequency regression fix
* Monitor opcode cache clear on memory overwrite
This update is a must for all, so head on over to the YAPE Homepage and hit download!
|
|
Posted By
gerliczer
on 2025-04-18
05:38:07
| Re: YAPE 1.2.6!
Thank you for the new version, Gaia.  I'm glad that this very useful tool still gets better and better after all this time. However, I have a long standing complaint. It is not a serious problem but a cosmetic type one. The Machine/Configuration... window always opens with Custom machine as Preset machine type. Would it be too much hassle to check the configuration and select the actual machine type when opening this window? And another two questions: will the 64-bit build too have the call trace window and will the position of the monitor and trace windows persist between sessions some day?
|
|
Posted By
bszggg
on 2025-04-18
07:36:41
| Re: YAPE 1.2.6!
As I think the "persist between sessions" is always a question.. If somebody resize the screen area, and change monitor that will be a problem to persist it.
I'll be happier, that I can save more custom machine for rom types. Maybe I can start somehow differently. But I 'm happy for the fact, We have Yape! 
The serial adapter emulation in the future maybe will be nice, because I have some idea with it.
|
|
Posted By
gerliczer
on 2025-04-19
10:52:19
| Re: YAPE 1.2.6!
As I think the "persist between sessions" is always a question.. If somebody resize the screen area, and change monitor that will be a problem to persist it.
Sure, but which would you guess is a more frequent occurrence: A) people changing their computer setups; B) people run and quit YAPE umpteen times when debugging a programme under development?
Were you pressed to pick one of these option to support, which would you find more useful to choose? A) Absolute safety? (as if...) B) Everyday convenience and efficiency?
|
|
Posted By
MMS
on 2025-04-19
14:16:21
 | Re: YAPE 1.2.6!
@Gaia. Thank you for adding the support of D82 file format.
This 1MB monster size floppy disc format will give us the chance to release games and slideshows with a lot of gfx.
TCBM2SD already support this D82 format, but if a realease will come in this format (because of YAPE support) nobody will be shocked.
Why D82 and not the 1581 disc format is my preferred big floppy format?
Because the TCBM2SD is not only bigger but much faster too. 6x faster in normal mode than an 1581 (and with special driver 12-14x faster) , and in emulation mode the 1551 with a D82 alone is 4x faster than 1581 in normal IEC mode. (Maybe implementing and getting widespread the fast serial protocol will change it soon.)
|
|
Posted By
Shine
on 2025-06-07
14:29:10
 | Re: YAPE 1.2.6!
T H A N K S
A
L O T
! ! !
<3
|
|
Posted By
Litwr
on 2025-06-15
02:56:46
| Re: YAPE 1.2.6!
It seems the mouse support is still not fixed. 
|
|
Posted By
bszggg
on 2025-06-15
13:35:10
| Re: YAPE 1.2.6!
Az a "bug" relative új.. szóval odébb lesz, mire bekerül esetleg.
Addig is van Yape version a driverből. szóval progit fejleszteni elvileg lehet (amit én írogatok, azt yape alatt tesztelem általában először)
- 1 - Viszont azt nem tudom, hogy a beállításokban van olyan, hogy "Selected IEC Drive working folder" és ez régen működött, de most bármit tekergetek, nem sikerül beállítani, hogy egy foldert használjon drive-nak.
Hogy kell ezt használni??
És ez amiatt baj, mert már amúgy is van sd2iec-ünk, meg tcbm2sd-nk, és amúgy is vannak/ lesznek utántöltős progik, ami segít a memória hiányon, meg hogy ne kelljen lemezekkel bíbelődni, cserélgetni, simán ZIP-ként is ki lehetne adni játékot, vagy programokat.
És a drive emulációk elég lassúak.. szóval most sokszoros teljesítményt élek meg az eredeti vason, viszont ez szuper is lehetne ha egy pc-s könyvtárat tallóznék ki. Fileokat is könnyebben lehetne frissíteni..
Nekem ez nagyon hiányzik..
- 2 - Meg lehetne hogy hard reset-kor újra felolvassa a ROM fileokat.. az ROM fejlesztésnél rengeteg időt tudnék spórolni.
| Re: YAPE 1.2.6!
That "bug" is relatively new… so it'll probably be a while before it's addressed.
In the meantime, there's a Yape version of the driver, so theoretically it's possible to develop programs (what I'm writing, I usually test under Yape first).
1 – However, I don’t know how the “Selected IEC Drive working folder” setting works. It used to work before, but now no matter what I try, I can’t get it to use a folder as a drive.
How is this supposed to be used?
This is a problem because we already have sd2iec and tcbm2sd, and there are and will be loader-based programs that help with memory constraints and eliminate the need to swap disks. It would be possible to release games or programs as simple ZIPs.
And drive emulation is quite slow… right now I’m seeing a huge performance boost on the real hardware, but this could be super useful if I could just browse to a PC folder. It would also be easier to update files that way.
I really miss this feature...
2 – Also, would it be possible for the emulator to reload the ROM files on a hard reset? That would save me a ton of time during ROM development.
|
|
Posted By
gerliczer
on 2025-06-16
08:48:09
| Re: YAPE 1.2.6!
Use the 32 bit version (YapeWin32.exe). That has the functionality in proper working order. The 64 bit build has problems with directory reading, emulation mode selection and folder path persistence.
|
|
Posted By
bszggg
on 2025-06-16
10:31:01
| Re: YAPE 1.2.6!
@gerliczer
the 32bit version worked neither for me
I tried again
|
|
Posted By
gerliczer
on 2025-06-16
11:41:16
| Re: YAPE 1.2.6!
Brevity is welcome in our days of excessive verbosity, but I think you're a bit overdoing it.
|
|
Posted By
bszggg
on 2025-06-16
12:08:07
| Re: YAPE 1.2.6!
so sorry for that. this is because my level of English.. not my personality.
And thank you the answer!
Otherway I hope this will be solved in the future.. .. all of them.. the yape worjking folder, and my knowledge too.
Best regards!
Sz
|
|
Posted By
Gaia
on 2025-06-20
18:06:29
| Re: YAPE 1.2.6!
Believe it or not but the IEC folder issue (which I could not reproduce?!) seems to have been caused by a C++ compiler bug in MingW 8.1 so I recently switched to 14.2 (at last) that seemed to have remedied the problem at people that had similar issues. This part of the code wasn't really touched hence it's twice as weird to me. Stay tuned for the next release pls.
|
|
Posted By
bszggg
on 2025-06-21
04:49:01
| Re: YAPE 1.2.6!
@Gaia Thank you!
You can send me anything if needs to test...
|
|
Posted By
Hop
on 2025-06-24
05:44:09
| Re: YAPE 1.2.6!
I found a bug that affects only 32KB machine.
GRAPHIC CLR doesn't release the allocated memory.
|
|
Posted By
Csabo
on 2025-06-24
08:31:50
| Re: YAPE 1.2.6!
Nice find, Hop, I don't think I've seen this mentioned anywhere before. (Also doesn't have much to do with YAPE.)
Nevertheless, BASIC "bugs" are always fascinating This indeed appears to be an oversight in the code for the GRAPHIC statement. After checking the BASIC sources, it looks like the authors did not account for 32K machines. Or, perhaps to put it another way, they saved two bytes on a check, which causes this issue.
Let's dive in!
The allocation occurs here:
. C641 A5 38 LDA $38 ;is this a 16k or a 64k ted system?
. C643 C9 40 CMP #$40
. C645 B0 34 BCS $C67B ;branch if 64k ted
$38 (or memsiz+1 in the original sources) will contain these values, which is the high byte of the end of usable RAM:
| C16/C116 | $3F | | 232 | $7F | | Plus/4, or 64K expanded machines | $FD |
So the code checks if this value is less than $40, and if so, the allocation and movement of BASIC occurs. So far so good, this works on 32K as well.
Deallocation is here:
. C741 A5 38 LDA $38 ;is this a 16k or a 64k ted system?
. C743 30 24 BMI $C769 ;branch if 64k
BMI jumps on negative, so... $3F will NOT jump, $FD WILL jump... but $7F (which is what we have on 32K systems) will also not jump! That's the "bug". Basically (no pun intended) they are doing the checks differently.
This could be fixed two ways: the deallocation check could also compare to #$40 instead, and branch with a BCS - this would need 2 more bytes. This fix would ensure that the allocation/deallocation occurs on 32K systems. Or, the first check could also use the negative bit instead, which would save two bytes - and the allocation/deallocation would NOT occur on 32K systems.
But of course we can't change the ROM, so if the very, very unlikely event that someone is coding a BASIC program and want to ensure it works correctly on 32K systems... The fix would be to PEEK the value of $38 before GRAPHIC CLR. If it contains $7F, POKE $80 there temporarily. Issue the GRAPHIC CLR. Restore the original value.
Whew I hope this was interesting for someone
1  1 |
|
Posted By
Hop
on 2025-06-24
12:36:14
| Re: YAPE 1.2.6!
Well, I'm glad (?) that it's ROM bug and not YAPE bug because YAPE is perfect.
And thanks for the explanation, I like that sort of stuff.
|
|
| |
Copyright © Plus/4 World Team, 2001-2025. Support Plus/4 World on Patreon |
