Jump to content

About This Club

A Club for the PlusCart user, and those who want to become a PlusCart user

  1. What's new in this club
  2. My Heavy sixer is broken currently but I could try it presently; I have a new hex buffer chip I tried to put in but having some trouble getting the socket cleared with the braid. However I have an idea you may be charging the paddle capacitor and not discharging from the description, since the user had to pull the cart and power off to resolve.
  3. Can any PlusCart user with a heavy 6er test: Public ROMs/Homebrew/NTSC/M-P/Pac-Man 4K (2007) (Dennis Debro).bin
  4. The C.A.V.E. Apocalypse backend is now adapted to cope with the new headers too.
  5. The backends of the following PlusROMs should now work with the new header too: all High-Score-Club games PlusClock bB-painter bB-maps online combat t-online newsticker ( this backend doesn't work currently because of a bug in the news API) these PlusROM backends still have to be extended: C.A.V.E. Apocalypse Sokoboo Plus
  6. Ups, sorry, typo, "browser" is what I wanted to write 😏
  7. 👍 Yes right, (but the preflight requests are sent from the browser) most of the PlusROM backends i have built so far were actually only meant as PoC and don't use any special web framworks.. I will start tomorrow to extend these to the new headers and will give feedback here.
  8. Why? The CORS standard defines Origin for that: if the client sends Origin, you answer with Acces-Control-Allow-Origin. If there ist no Origin header in the request you can omit it. However, you are doing POST with a custom header, and I would expect that this implies a preflight OPTION request from the server that you have to answer with Access-Control-Allow-Origin and Acces-Control-Allow-Headers (in order to whitelist the header). You shouldn‘t have to worry about this yourself though, most web framework can handle CORS if configured for it.
  9. There is one more thing I stumbled across when I starred at some of the backends. The Browser based emulators need a CORS header, so the browser won't ignore/hide the response from the application. Currently the backends can determined this by the "WE" prefix of the generated device-id. With our new header they would have to determine this by the "agent" string.
  10. Either way, the PlusROM backends must be able to understand old and new headers. So if we can agree on one variant for the new header, I could add the new header to the backends I host (as far as I know, no one has created their own PlusROM with a backend yet).
  11. @Al_Nafuur Are you going to switch? We are currently finalizing Pluscart support in Stella, and I wonder whether I keep the old header or send new one 😏
  12. That's what we are already doing. At the PlusROM High Score Club these emulator accounts or PlusCarts are listed as "unknown Emulator user xyz" and "unknown PlusCart user xyz". The numbers are determine by the PlusCart device id, if the device id cannot be resolved via the open API. For Emulators these number is determined by the device id and nickname. Emulator nicknames are not unique (unlike PlusStore usernames), so they are listed with a number determined by the device id too. E.g. "Al_Nafuur emulator user 17" is my firefox javatari.js account "Al_Nafuur emulator user 120" is my gopher2600 installation account. How these numbers and entries are generated from the device id and/or nickname (if given) is totally up to the PlusROM backends. The C.A.V.E. Apocalypse backend does not generates any user names. You just need to connect your emulator device id (or PlusCart device hash) with your C.A.V.E. Apocalypse Level Editor account to play your private levels.
  13. Hm, you mean we should submit scores without registration? @Al_Nafuur what do you think?
  14. Just don't include the nick field if someone has not registered. Otherwise, let's take the 1 char minimum then.
  15. That should be the rule for emulators then too, IMO.
  16. The minimum length for a username in nextcloud is 1 char. So a PlusCart that is connected to a PlusStore account will send at least 1 char.
  17. Ok, but if they decide to register, IMO a minimum length should be enforced.
  18. Some users may not want to be "registered". Also there are currently 55% of the PlusCarts not connected to a PlusStore account and so their PlusStore-Id cannot be resolved to a username
  19. IMO we should require a minimum length (2 or 3). A few more chars (if feasible) would be nice.
  20. Why? To me that sounds like unnecessary optimization. If the packet fragments, so what? Besides, the request size will still be way below the MTU. Using an ESP connected via serial to an Atari 2600 already excludes high performance communication 😛 EDIT: Besides, now that I rethink this, an HTTP request larger than the MTU will not usually cause fragmentation at the IP level. Instead, afaik,socket transmissions that exceed the MTU will be split by the network stack into multiple IP packets that fit the lowest MTU on the path.
  21. 👍 I thought of using GUID/UUIDs too, but without the unnecessary hyphens. 👍 except for the 32 chars I think 16 should be enough for a nick. And maybe add [_] too, otherwise my nick would be invalid 🙂 I am a great fan of using existing standards too. This looks nice and is human readable (even if it doesn't need to be). But there is one more thing I would like to mention. Using tcp and http in "gaming" is already a disadvantage, so I want to keep these requests as small as possible to minimize tcp packages and to stay way below the standard MTU size of 1500 bytes (1460 or 1448 bytes payload). Some network connections can have smaller MTU sizes. The proposed changes would not necessarily exceed this limit. But I would still like to shorten/change a few things: PlusROM-Info: agent=Stella; ver=6.4.1; id=0123456789ABCDEF0123456789ABCDEF; nick=Al_Nafuur
  22. On third thought, I agree 😏 To put this into code PlusROM-Info: platform=Stella; platform-version=6.4.1; id=4FDFDFC6-0D45-45E0-9045-A2891E2D7493; nick=DirtyHairy
  23. I would agree with this. My only reservation is how the version number of the platform is encoded. Personally, I would advocate a separate "version" field.
  24.  
  • Recently Browsing   0 members

    No registered users viewing this page.


×
×
  • Create New...