mithrendal commented 4 years ago

emulator https://dirkwhoffmann.github.io/virtualc64web/

with original commodore roms no issues

when setting up with open roms ... tape loading is almost not working ....

we at "virtual c64 web" project suspect the fault in memory mapping

we like to tell you our findings ... on one specific title Galaxy.tap where we somehow made an attempt where it loaded successfully with open roms but only once ...

look here this attempt loaded it successfully (we documented it in a picture ... thread https://github.com/dirkwhoffmann/virtualc64web/issues/29) grafik

but now it constantely gives this

grafik

we observed

when it once loaded successfully the start adress was $0801

we never managed again to load it successfully ... now it always tries to load from $02c0 🤔 ... with loading error ...

with original commodore roms it always works correct as expected

Do you think it is maybe an issue on open roms tape loading implementation ?

FeralChild64 commented 4 years ago

If it loads from $02C0, this is most likely autostart software - such games most likely won't work (just like autostart disc games), currently the Open ROMs internals are probably too different.

Have you tried other tapes?

mithrendal commented 4 years ago

Have you tried other tapes?

I just tried some ... none seem to work ...

here for example choplifter.tap loading from $0801

grafik

loads fine on commodore roms ... but yes 🙈... autostarts .... if that is the culprit then at least we know why 😅...

maybe all 6 app titles I just tried on open roms have auto start ... (I tried to choose some from 1982-1983 in a hope that they do not have autostart 🙄...)

As a last try ... in case the error is not in open roms but on our side ... ... we could test vc64mac version 4.0 on the latest open roms for tape support which is under heavy construction ... @dirkwhoffmann could you try galaxy tape on vc64mac ?

dirkwhoffmann commented 4 years ago

Loading Galaxy with the latest and greatest dev build of VirtualC64 4.0: 😎

Now trying with OpenRoms: 😍

No, same issue: 😢

FeralChild64 commented 4 years ago

Do all of them load from $02C0, or do they start from different addresses? If this is a popular loader, than it is worth to try to add a workaround (but I'm not promising anything, I've already got a lot to implement/fix).

Unfortunately, there are several methods to implement autostart, all of them use more-or-less dirty tricks to achieve this. If something loads between $0200 and $02FF, it means it overrides CPU stack to force it to jump to the loaded code instead of returning from subroutine at some point (it's classified as "critical vulnerability" in modern language...).

mithrendal commented 4 years ago

No. Not all ... see above choplifter.tap started fom 0801 and had loading error too 😳

FeralChild64 commented 4 years ago

OK - tried with VICE, Choplifter loads every time with the current development ROM (https://github.com/FeralChild64/open-roms/tree/master/bin). With VirtualC64Web (it fetched DEV.200802.FC.1) I see this is random. On some screenshots I can see release DEV.200701.FC.2 - please upgrade, I can see this one never loads Choplifter correctly (ends the file loading too early and the game does not start).

I'll try to test it more, but... Open ROMs uses rather unusual CIA timers setup for tape loading, so that it can load/autodetect both NORMAL and TURBO without reconfiguring the timers; probably no other tape loader does this. Maybe it works on some emulators/FPGA machines, but not on others; I don't have the possibility to test these ROMs on the original hardware, I'm mainly using VICE/Ultimate64. I'll try to do some more testing once I've got more time.

dirkwhoffmann commented 4 years ago

Open ROMs uses rather unusual CIA timers setup for tape loading

I'm pretty sure the CIAs in VirtualC64 are OK.

In my view, the prime suspect is the VirtualC64 datasette, i.e. the algorithm that generates the pulses. TAP files are nothing more than sequences of pulse lengths. When VirtualC64 reads a pulse n from the file it emulates a rising edge on the datasette line at time n/2 and a falling edge at time n. Since this worked so well with the original roms I assumed that this is correct. I don't know what VICE does, because their source code is not easy to read.

FeralChild64 commented 4 years ago

It seems it works in VICE all the time, but some other emulators (HOSX and Denise) give random results - just like VirtualC64. LOAD ERROR happens almost immediately after the "FOUND ..." screen. This starts to be interesting...

mithrendal commented 4 years ago

It seems it works in VICE all the time, but some other emulators (HOSX and Denise) give random results - just like VirtualC64.

Awesome ... good idea to test the other guys too !

This starts to be interesting...

Sounds like an exciting crime story ... 🕵🏼

dirkwhoffmann commented 4 years ago

give random results

With random results, you mean that the same game in the same emulator sometimes succeeds to load and sometimes fails to load? If yes, it might point to an issue in the OpenRoms. They might be sensitive to the time when the play key is pressed w.r.t. to the current state of the CIAs or something like that. It might well be true that pulse generation in VirtualC64 is bogus, but a wrong pulse creation algorithm wouldn't cause indeterminism.

Sounds like an exciting crime story ... 🕵🏼

Definitely 🤠. Time for the CIA to take over... but wait... they are among the suspects 😬.

FeralChild64 commented 4 years ago

Right. In VICE - loads every time. In other emulators - it's random. The online VirtualC64 usually fails, but for example HOSX usually succeeds.

I can see no data is loaded in case of failure, most likely there is a problem either with routine that gets end-of-byte/end-of-block marker, which can report false end-of-block marker.

[edit] VICE is nice for development, as it has Linux version, allows to set a breakpoint and check memory content when it is encountered, it can even import symbols from the assembler - so debugging most problems is relatively easy.

mithrendal commented 4 years ago

VICE is nice for development

🙋🏻‍♀️when I remember correctly ... the VirtualC64Mac version has also a debugger and disassembler .... VirtualC64 for Mac is more like a version for professionals 😎 ... of course it needs a mac to use it 🤭...

The WebEdition of VirtualC64 is more "end consumer oriented"🕹🕹 as it uses the same core compiled to WASM but with a web front end and therefore runs on all plattforms for example also on Phones and iPads (when saved to homescreen it turns into a progressive web app (PWA) which is startable even when offline ...) etc...

BTW: otherwise from the "not so good working" tape support, using open roms only (without the commodore rom for 1541) in conjunction with VC64(mac or web) works already quite well for many old titles in T64, CRT or PRG format... Thank you for making the open roms 😍...

FeralChild64 commented 4 years ago

My latest build should solve the tape loading problem:

https://github.com/FeralChild64/open-roms/tree/master/bin

mithrendal commented 4 years ago

cool 😎 200826.FC.1

lets test this puppy out ... opening choplifter.tap now ... hang on ...👀

grafik

wow nice one .. no loading error anymore 👍 very cool

now lets hit "return" ... and yes it runs very well ...

grafik

congrats .. loaded from tape with open roms only ... 👏🏻

EDIT: lets do it run a second time ... just in case of ... 😬

and ...

yes still works ... 😅

... still 12 humans to rescue ... I have to go into the helicopter again ... 🧑🏻‍🚀

FeralChild64 commented 4 years ago

Glad to hear that :) And thank you for the bug report!

dirkwhoffmann commented 4 years ago

My latest build should solve the tape loading problem:

Awesome 🥳. Was it a timer issue?

mithrendal commented 4 years ago

Awesome 🥳. Was it a timer issue?

emulate a unreliabe tape drive option was maybe enabled ---- 😜 I bet FeralChild64 just disabled it ... I remember my datasette (in real life 1984 or so ) had so many loading errors ... I saw that message constantly ...😩 ... until my parents bought me finally a 1541 😍

@FeralChild64 What do you think about that we implement a direct fetch of the rom files from here, rather then a fetch of a copy from our github-pages site as we have currently implemented ?

Unfortuntaly we can not fetch directly from address https://github.com/MEGA65/open-roms/tree/master/bin when user clicks the "fetch and install open roms" button, because cross origin ressource sharing (CORS) is not activated on normal github sites ... it must be published to a gh-pages site to make CORS allowed for web apps from a different origin. (VirtualC64 Mac is in a clear advantage here as it must not obey to the rules of safer web 🙄 the CORS rules of the browser police should prevent cross ressource sharing between web sites from different origins unless it is explicitly allowed)

you have some options to allow this ... you can either

set up a extra gh-pages branch from within the settings of the repo but this also implies that you have to copy over the roms to the gh-pages branch and do a second commit and push

OR

you choose the simple "fire once and don't care again solution" ... then you would simply choose to replicate the whole master to a gh-pages location from within the settings of the open roms repo like in this example (I did the screen shot from my repo to demonstrate)

grafik

of course the destination website will be then at http://mega65.github.io/open-roms/bin the second (simpler) option should keep the master automatically in sync with the gh-pages http://mega65.github.io/open-roms/ web site whenever you push into the master.

and the vc64web could fetch automatically from there ...

FeralChild64 commented 4 years ago

Actually, there were two issues, both specific to normal (non-turbo) save format:

due to some optimization (not reading the backup block if the first copy was OK) the data read routine sometimes tried to interpret the header backup block pilot/sync instead of the data main block pilot/sync - somehow, this never happened in VICE; I have disabled this optimization, it was dangerous nevertheless; tape should stop when the backup block ends, not earlier - someone might want to record the next file, we don't want him to override the backup block of the previous one
the normal/turbo autodetection code (works while searching for the pilot) was being triggered also when searching for the pilot of the data block, causing havoc in some cases

As for fetching the ROMs - you would have to ask Paul, I don't have control over this repository. I'm doing the whole development on my fork, creating a pull request from time to time. And fetching all the builds automatically from my repository is a bad idea: sometimes I update binaries with new features already enabled, but not yet fully working. An ordinary user seeing an unfinished feature might (wrongly) think it's a bug.

gardners commented 4 years ago

We should be able to arrange to make the ROMs available via pages on this repo. @FeralChild64 would you like to have the privileges to do this, as it seems a bit indirect for me to do the updates all the time, when you are the one actively working on the code?

mithrendal commented 4 years ago

... to do the updates all the time...

If the second option

the simple "fire once and don't care again solution"

from above is choosen then there is no explicit copy to ghpages necessary... it just mirrors the repos master files to ghpages in that case...

FeralChild64 commented 4 years ago

@gardners - OK, I'll handle this. If you don't mind, I'll also clean up the issues; several are already resolved.

For now I'll set the master as a GitHub page, we'll see how it works. But keep in mind, that for now the fix is in my fork repo, which is not ready to be merged to the master yet - there is a large, half-baked feature there (80 column screen for MEGA65), I need some time (probably few days) to at least stabilize current functionality.

gardners commented 4 years ago

Sounds like a plan!

mithrendal commented 4 years ago

ok lets alter the address from which https://dirkwhoffmann.github.io/virtualc64web/ fetches the roms

up to now we installed from

    install("roms/basic_generic.rom");
    install("roms/kernal_generic.rom");
    install("roms/chargen_openroms.rom");

we change now to yours address:

    install("https://mega65.github.io/open-roms/bin/basic_generic.rom");
    install("https://mega65.github.io/open-roms/bin/kernal_generic.rom");
    install("https://mega65.github.io/open-roms/bin/chargen_openroms.rom");

and lets test it ...

grafik

it fetches the roms files from your site now ... lets look at the network analyser in the picture above ... yes it is loading really from your adress now ...

Its under your control now which version of the roms is going to be installed when the user hits the „fetch and install open roms“ button 😀

51 closed

Amazing stuff 😍!!! We interconnected our projects 😎! CORS is working fine ...

mithrendal commented 4 years ago

grafik

we use your icon (or is it a flag?) in the fetch and install roms button for the vc64web emulator ... hope it is ok for you 😍...

gardners commented 4 years ago

Fine by me :)

FeralChild64 commented 4 years ago

Just merged the branch with fix to the master in MEGA65. Checked, that VirtualC64 correctly fetched the new ROMs, I can see the Choplifter loads successfully.

mithrendal commented 4 years ago

wait ... wait ... you are too fast for me ... I want tooo 🤤

first step ... install the new roms right ?

hm lets see ...

wow cool ... I have got new rom chips ... without changing anything in vc64web ... awesome 🤤🤤🤤

okay now lets drag that choplifter_tap.zip into the file slot ...

select the tape file from the zip archive ... and mount it ...

hitting insert tape now ...

oh yes it loads ... well I can see the progress ... screen flickers like mad 🤩 (oh boy ... that was so modern in the old days ...)

looks good ... lets hit run and see what happens ...

oohhh nice even more flickering 🤩🤩... it flickers even more mad than before 🤪... is it really loading choplifter ? 🧐 or a different game ... called "flickering madness" ?

🥳🥳🥳 AWESOME ... You did it !!! Thank you !!!

MEGA65 / open-roms

loading from tape ... memory mapping #52

we observed

51 closed