Login
Back to forumReply to this topicGo to last reply

Posted By

Crown
on 2025-03-25
10:56:17
 Yape 1.2.5 regression

1551 CPU level emulation settings seems to be borked. Gives Device not present error on Directory with correctly attached D64. IEC level seems to work.
Posted By

Csabo
on 2025-03-25
11:59:36
 Re: Yape 1.2.5 regression

Can confirm, same behaviour here (with a clean INI file).
Posted By

Luca
on 2025-03-25
12:06:49
 Re: Yape 1.2.5 regression

@Crown are you referring to the latest 1.2.5 version? If yes, I suggest to write all the regressions and possible bugs, under the thread which was related to the official news.

For example, to me, the most dramatic regression is the new management of the $2D/$2E values to determine the end of a loaded program: actually, in 1.2.5 when you load a program, the info bar reports the first non-loaded memory location, when you save a program, the emulator forces that memory location as "Save from xxxx TO , but it actually saves the named first unoccupied location too!

Example, a Multi Botticelli's picture, load then save:
(once loaded)
"Loaded: picture.prg at $7800-$9F40"
(when you wanna save)
"from address: $1001 to $9F40"
...and it actually saves $9F40 too!
Posted By

Gaia
on 2025-03-25
16:53:22
 Re: Yape 1.2.5 regression

Hey guys, thanks. These were fixed in the meantime but haven't got around to publish the new version, yet.

EDIT: regarding the save "bug", well that's a feature. I realized that if you do a S "whatever",8,1001,9F40 from TEDMON it saves $9F40 as well, so I made it consistent with that recently.
Posted By

.mad.
on 2025-03-26
06:40:08
 Re: Yape 1.2.5 regression

Some of the Armati BASIC tape loaders fail in YAPE.

e.g. Tower of Evil

the BASIC pokes 239 larger than what is actually needed.
when loaded in YAPE a PI is displayed on the screen rather than the pressing of enter.
so it fails to run.
the text is the same colour as the screen.
so you can't see the error when loading.


Posted By

Luca
on 2025-03-26
07:32:06
 Re: Yape 1.2.5 regression

@.mad. nope, that's not a bug. Armati's green screen turbo needs to be loaded with LOAD"",1,1, as reported in the page (see on the bottom of Tower Of Evil (Armati) as example): once run, the screen goes all green, and you must wait for the tape to pause, then hit the Commodore key as usual (but I guess it works by itself as usual, again).
Posted By

.mad.
on 2025-03-26
11:43:41
 Re: Yape 1.2.5 regression

the tape also fails with load"",1,1 in YAPE.

it works in plus4emu with load"",1 and load"",1,1
*i don't have real hardware to check it.

the same PI problem also happened with similar BASIC loaders on disk.
i had to fix a few when play testing all the games.
i didn't think to make a list at the time.
but reducing the poke239 value fixed it.
Posted By

Luca
on 2025-03-26
11:58:41
 Re: Yape 1.2.5 regression

@.mad. as I pointed out before, it perfectly works on YAPE 1.2.5.


(speed x2.5)
Posted By

.mad.
on 2025-03-26
15:25:40
 Re: Yape 1.2.5 regression

i am not making this up.

you must have a different version of the tap.

mine is perfectly broken in YAPE 1.2.5.
Posted By

Luca
on 2025-03-26
16:08:10
 Re: Yape 1.2.5 regression

@.mad. possibly, the only tap file around has been dumped by me happy

There's something that you're missing somewhere probably. Once your YAPE is set at the best emulation possible in /Machine , describe your moves to compare with my moves, we'll find the gap. Also keep in mind that the final RUN command fails if you're altering the machine's speed.
Posted By

.mad.
on 2025-03-27
15:46:00
 Re: Yape 1.2.5 regression

i tried...
slow
warp
load"",1,1
load"",1
load
pal
ntsc
c16
plus4.
none work for me.

i made a small basic prg for you to test.
*which fails for me.
test error
https://mega.nz/file/XkZ2TbgB#qpJB9wQk8IxtsjpCQHYg-DYhfERM_Mcm0hxQndusJZ8
https://mega.nz/file/jxQiFBhS#k_1tEIDTup_7woQMel0gvXWAwrf7Fu-odKqqpeTNFIs

test2- works reducing the poke number
but return over run is not pressed.




drag the file into yape.
see the pi over RUN.

press return.
type RUN again.
then the program works (running in a loop).
Posted By

Luca
on 2025-03-27
15:57:12
 Re: Yape 1.2.5 regression

@.mad. ok, YAPE always had some problems if you use the tray option to automatically RUN a BASIC program. The classic example is any cassette from Savage Software or Mantra Software: they show a BASIC intro, and if you tray the TAP file over the YAPE window to obtain an automatic LOAD+RUN, that BASIC intro doesn't properly run (try e.g. Al Ladro).

I tried your test programs, but I wouldn't need to, simply because that tape works. It cannot be a miracle, if it works for a user and not for another, if it worls for once, it must work for the other too, and only a mistake of various kind can prevent it to work for the former user.

So, here's how I did.
I opened YAPE, ensured that the Compatibility in the /Machine/Configuration menu was at "Very high", attached the TAP file, typed LOAD"",1,1 and pressed Return, pressed Commodore key at first FOUND and let the BASIC code get loaded. RUN (Return) and the screen goes green, after some seconds the turbo loader FOUND the halfwaved signal so the tape STOPS TO COUNT, pressed Commodore key when it happened and waited.
Posted By

Crown
on 2025-03-27
18:18:01
 Re: Yape 1.2.5 regression

I can confirm that it doesn't run if started with Autostart image, and has the Pi problem on the screen.

I can also confirm that it does run if you manually attach the Tape, enter LOAD start the tape, then enter RUN. But if I enter RUN: here instead that will trigger the bug, which the Autostart process also does. This feels like a bug in the Armati loader.

So looking at the BASIC part of the code, it is missing a POKE1323,13. It sets the preceeding 4 byte and sets the byte after, but I believe this should be set as well, or the last should be 1323 instead of 1324. I've tested it changing 1324 to 1323 and it works with RUN: as well correctly. 1323 is basically random junk, and its in the keyboard buffer.

BTW, LOAD"",1,1 is completely unnecessary if the file needs to be loaded to a fixed address, and the Tape has been properly authored. There is a bit flag in the tape header which if it is set, then the secondary address is ignored, and the file will be always loaded to the designated address.
The only way to load a file to a different address is pressing the RUN/STOP button, when the file is FOUND, then enter MONITOR, update the load address at $b4-$b5, then there is a G address to continue loading, GF10C or GF124 works sorta. This is how you can crack tape loaders. Before continuing loading you should also look inside the TAPE header from $332 there can be code in there. For example NOVALOAD has the start address there which you can replace to $F445 and you're golden.
Posted By

Ulysses777
on 2025-03-28
01:29:51
 Re: Yape 1.2.5 regression

The Armati loader problem is unfortunately another bug which is affected by the RAM powerup state, so it can affect *some* real machines as well.

When loading the normal way (emulator or real machine), the bug will occur if memory location $052B powers up as $FF.

When using the YAPE autostart, the problem memory location is $0530, which is copied to $052B after the buffer is cleared of the LOAD and RUN commands.
Posted By

Crown
on 2025-03-28
03:06:23
 Re: Yape 1.2.5 regression

What is the mechanic of which memory location matters?

Which location matters if Yape autostart use "rU:" R+SHIFT+U+: instead of RUN: ?


Back to topReply to this topic


Copyright © Plus/4 World Team, 2001-2025. Support Plus/4 World on Patreon