-
-
Notifications
You must be signed in to change notification settings - Fork 5
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
revamping the ROMs dialog ... #50
Comments
I will find the cute rom chip images from the picture above in the xcode project right ? |
Yes. They are in virtualc64/Resources/Assets.xcassets 😎 |
work in progress ... the rom pictures are already set dynamically ... also is the delete rom trashcan ... Ah and the button Install Open Roms is missing do you think we have to ask them in order to fetch the generic roms from their github site ? In this issue MEGA65/open-roms#33 @gardners said
Do you think it is ok with them to automatically load them from https://github.com/MEGA65/open-roms/tree/master/bin and store them into the local storage of the browser ? |
Very nice 😎
Yes, I think that's fine. I thinks it's best to implement the prototype just the way you want at the moment. Once this is done, we ask if this is OK for them. |
quite done ... but before we automatically slurp in the open roms ... I wanted to test them out ... and the current files give me an error any idea ?
it accepts the open roms charset but not the kernal and not the basic 😢 Another question: how to know whether it is a mega rom or a commodore rom ... is the kernal capable of telling me this ? I need it in order to show the correct rom picture I pushed the preview to gh-pages ... |
I can't even run them in vc64Mac ... it seems to me that the current open rom kernal and basic is not even accepted in vc64Mac too ... not even in latest Version 3.4 ... Or am I doing something wrong here ... the magic header must have been changed ...no ? |
Yes, that's right. The v3.4 core just checks the header signature and is not compatible with the latest Roms. The v4.0 core (dev branch) is smarter and can handle the latest Roms (there are magic bytes and version numbers at fixed memory locations inside the Rom, but they are not at the beginning). But please do not use the v4.0 core yet, because it's far from being ready. Maybe it's better to just update the magic header bytes in vc64web to match the current Roms. |
sounds good ... how and where to patch ? can you give me a quick hint ? |
I patched the core 😷 .
as a result vc64web runs with open roms only ... it can play the pacman .crt file version 😎✌️ ... next task: the open roms install button |
Now, we have a VC1541 without a Rom 😬. But if the drive is not accessed, nobody cares 😉. On my iPad, I experienced the following (yesterday evening):
P.S.: I'll work on a nicer icon when Big Sur comes out, because all icons need to be adjusted to the new icon layout anyway. |
Therefore I added the sentence: „or just touch or click the sockets.“
Yes I have to recognize the header and according to the results set the picture. Does the core 3.3 have a method for that? Otherwise I will do in JavaScript which is easy. Next install open roms button 🤤 |
No, the Rom handling is done in the Swift part 🙄. But the v4.0 core has 🤩. OK, let's postpone this until the v4.0 core is ready. |
... the cross site request for the roms may make trouble we are hosted at and the roms are when github.com is different to github.io we may have a cross domain request and that is most likely prevented by the browser police, except github has enabled CORS (Cross-Origin Resource Sharing) I am testing this now ... |
I have just deployed the version which loads the local version of the basic.rom fine in order to test it on the wild site and the police is strict ...
😩 Wait ... why "Anschlag" 🤔 ? I just submitted a read to that ressource ... looks like the browser thinks that could be evil... It gives this further read https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS we could still host the files on our site 🤕 |
So mean 😖
Yes, I think that's the best workaround for now. We can update the Roms manually from time to time. |
yes, acceptable fallback... I am just digging deeper in analysing the problem ... for making CORS work the target webserver has to explicitly accept the request origin ... our request header and the open roms site response header if we could just rewrite our origin ... 😁 I think not possible ... or set the access-control-allow-origin header on the target website ... the host is both times github.com but the origin is different ... |
I just read that github-pages has CORS enabled by default
that means when openRoms project setup a gh-pages branch and publish their builds there ... then we can fetch the roms from there on a button click from our vc64web app... |
yes I was looking for freedom ... 😂 in the mean time I do host a copy of the open roms at our dirkwhoffmann gh pages in our roms folder... |
Before we ask the open roms team about better to publish the roms to gh-pages branch ... we should check whether it is really working what the above stackoverflow posting claims 🤔... 👀lets try chrome this time ... I don't want to risk another "Anschlag" 😌... I will start vc64web now from localhost and let it fetch the roms from our dirkwhoffmann gh-pages space... one two three go !! 😵 it is does not load it let look in the javascript console then
it is not working .... the post was apparently a wrong ... lets check the headers request
response:
no way ... |
maybe we have to enable CORS in the gh-pages settings... unfortunately I have no access ... only you ... I will make fork and look into the settings of gh-pages... |
no I found nothing ... but I found this in https://stackoverflow.com/questions/26416727/cross-origin-resource-sharing-on-github-pages
maybe ressource sharing from ghpages works only when consumer is https hosted ... lets test ... |
If I understood your posts correctly, I don't have to change anything, do I? |
you understood it right. I only needed access to the settings to analyse whether there is a CORS enable setting or not ... then to get access to the settings I forked the repo ... I looked into it but found no such setting then I configured the dirkwhofmann/vc64web to access mithrendal/vc64web/roms/... because that is another origin it should activate the CORS prevention policy, and prevent the access except that the target site is explicity stating that it is ok with sharing its contents... The test revealed that when the app which has been loaded from https://dirkwhoffmann.github.io/virtualc64web/ requested resources from https://mithrendal.github.io/virtualc64web/roms/ ... the gh-pages server answered with header in the picture above you see the app is loaded from dirkwhoffmann (look in the addressbar at the top) and that it loads the roms from mithrendal (look into the network analyser at the bottom) also ... good to know ... when the requesting origin is loaded from a nonsecure (no https) site the gh-pages server does not grant the CORS in shortwe can perfectly slurp in the roms from the MEGA64 open roms site, if they set up a gh-pages branch and publish the prebuilt roms into there |
it works they set it up and we are slurping in the newest roms from their web site from now on !!! |
now:
goal:
![grafik](https://user-images.githubusercontent.com/17108995/90253560-a1fa5700-de41-11ea-9500-8519a3e72355.png)
The text was updated successfully, but these errors were encountered: