Jump to content

DirtyHairy

Members
  • Content Count

    779
  • Joined

  • Last visited

Community Reputation

856 Excellent

3 Followers

About DirtyHairy

  • Rank
    Dragonstomper
  • Birthday 08/19/1980

Profile Information

  • Gender
    Male
  • Location
    Germany
  • Interests
    Music, Guitar, Coding, Retrocomputing & Emulation, Computers & Technology in general, Books, Food, Family

Recent Profile Visitors

9,642 profile views
  1. Ups, sorry, typo, "browser" is what I wanted to write 😏
  2. 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.
  3. @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 😏
  4. Just don't include the nick field if someone has not registered. Otherwise, let's take the 1 char minimum then.
  5. 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.
  6. 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
  7. Suggestions: Use a string to identify the emulator or device, not an enum, and include the version there: "Stella 6.4.1", "6502.ts 1.0.5", etc. That allows to interpret the header without looking at at table Use an UUID for the random ID, that's a standard, and there are packages to generate them Place some reasonable limits on the nickname, i.e. [0-9a-zA-Z ]{0,32}. That allows for straightforward validation and avoids encoding and escaping headaches I would prefer key-value pairs separated by semicolons, trailing and leading spaces trimmed for keys and values, similar to the encoding used for cookies. This makes extending the header in the future much easier My suggestion would look like this: PlusROM-Info: platform=Stella 6.4.1; id=4FDFDFC6-0D45-45E0-9045-A2891E2D7493; nick=DirtyHairy
  8. To the best of my knowledge the dumper and controller MCUs are programmed at factory, and I am not aware of any public way of reprogramming them in-circuit (or whether this is possible at all). Hyperkind dumped the code on their website, but this is not an update that can be installed (or is installed by any firmware), it's just the source for the code programmed into the controllers at factory. That said, the latest 6.x builds *do* include a few controller fixes, but these are implemented in the linux kernel driver and in Stella.
  9. You can check out the BIOS stubs used by Stella here and by the Unocart and 6502.ts here. Neither preserves the register values, both overwrite 0x81 -- 0x9d with zeroes, and both use and overwrite a few bytes at the top of RIOT RAM. Both leave the registers in the same state, X = 0xff, Y = 0x00 and a random value in A (it's not actually random on the Unocart though). I am not sure about the supercharger BIOS, but iirc the Stella stub derives from code from Eckard Stolberg that was modelled after the original SC BIOS, and the Unocart and 6502.ts stub was written by me to match the Stella stub in behavior. If your code behaves differently with both stubs, then I guess it either depends on 0xf0 -- 0xff or on the exact value in A (it is random in Stella and 6502.ts, but constant 0x9c on the Unocart).
  10. As a third choice, 6502.ts works fine, too (it does not emulate ARM cycles, though)
  11. I like both ideas, and I think they should both work fine. I don't think that writing garbage to the TIA would really matter, to the best of my knowledge it doesn't start in a defined state anyway.
  12. Using the ESP32 for driving the bus has the advantage that code running on the core not serving the bus could prepare data for the VCS without any communication overhead; once it is ready it can notify the other thread, which then can present the newly generated data to the VCS. This is similar to what CDF and DPC+ games do on the harmony, but the game logic on the ESP could run even while the VCS kernel is busy rendering, while the harmony has to put NOP on the bus while the game logic runs. If an additional MCU is used this would require communication between both processors, while the secondary MCU is also busy serving the VCS.
  13. Hm, this has raised my curiosity. I have done some more research, and it seems that first stage loader loads the second stage loader into RAM before it executes it, so this may still take too long (especially as it is likely that SPI flash has not been configured for full speed at this point). Another alternative would be to use a supercap to provide enough power to keep the ESP in deep sleep while the VCS is turned off. As soon as the bus is powered the ESP would wake up and execute a "wakeup stub" from RTC RAM. It seems this happens instantly, before the first stage loader is executed. The stub could park the 6507, and after that startup can continue normally.
  14. Interesting, thanks, there is conflicting information in other places on the web, so it is good to have something close to an authoritative answer 😏 What would remain to be seen is whether the logic levels of the ESP32 on input pins are suitable for a clean readout of the 6507 bus. I think the boot issue could be circumvented by extending the second stage loader that runs from SPI flash to drive the bus and run a small payload that makes the VCS jump into a RAM routine that idles until a ROM address is driven to a specific value. At that point the loader can continue to boot. The questionable point here is whether the the time required for the SPIROM loader to come up is sufficiently small. I think this would be a very interesting platform if it can be made to work. Imagine one core driving the bus with a VCS program, and the other core running game logic in Micropython... 😛
  15. Oh, and there is one other thing, I think that the boot-up time of FreeRTOS is too long (I brought it down to a few 100 millseconds in my own projects) to take over the bus before the 6507 comes up. You'd have to extend the bootloader to first "park" the VCS in RAM before continuing to boot the OS. However, that's doable
×
×
  • Create New...