+MarcoJ Posted October 5, 2023 Share Posted October 5, 2023 2 minutes ago, DirtyHairy said: But that means yielding to the scheduler, and then we're talking microseconds again. I think polling is the only way here. Hmm, that's a shame. The scheduler is evil kneivel. I suppose polling is OK if Stella was able to do some useful work before making it to the Timer polling. The Timer chip would just enforce waiting "enough" time rather than the exact time. Link to comment Share on other sites More sharing options...
+Al_Nafuur Posted October 5, 2023 Author Share Posted October 5, 2023 32 minutes ago, splendidnut said: What about doing the evil 'dump the ROM' for the checksum and then 'reset/reboot' the cartridge either via hardware or software (making sure to randomize the starting bank)? Dumping the PlusCart means dumping half the internet 🤣 But currently the debugger is doing a scan of what he thinks is the "first bank" anyway. So maybe the md5sum of this scan is enough to distinguish the cartridges? The 7800 is doing a "checksum" read of the cartridge at startup to determine if it is a legit 7800 cartridge. Most 2600 cartridges should be OK with this startup, so maybe we could do the same and use the generated checksum? Link to comment Share on other sites More sharing options...
+Al_Nafuur Posted October 5, 2023 Author Share Posted October 5, 2023 Just now, MarcoJ said: Hmm, that's a shame. The scheduler is evil kneivel. I suppose polling is OK if Stella was able to do some useful work before making it to the Timer polling. The Timer chip would just enforce waiting "enough" time rather than the exact time. That was the idea anyways. Link to comment Share on other sites More sharing options...
+MarcoJ Posted October 5, 2023 Share Posted October 5, 2023 3 minutes ago, Al_Nafuur said: But currently the debugger is doing a scan of what he thinks is the "first bank" anyway Does it use the GPIO peek/poke driver to do this? If so, I imagine that would be fine for heuristics like a normal rom. Link to comment Share on other sites More sharing options...
+Al_Nafuur Posted October 5, 2023 Author Share Posted October 5, 2023 12 minutes ago, MarcoJ said: Does it use theG PIO peek/poke driver to do this? If so, I imagine that would be fine for heuristics like a normal rom. It has to use peek from the driver, otherwise he would have only the data from the bin file. you can check it by starting the emulation directly to the debug window by adding the "-debug" switch to the command line. Even though Stella hasn't even emulated anything you can see the whole data in the debugger. 1 Link to comment Share on other sites More sharing options...
Thomas Jentzsch Posted October 5, 2023 Share Posted October 5, 2023 19 minutes ago, Al_Nafuur said: But currently the debugger is doing a scan of what he thinks is the "first bank" anyway. So maybe the md5sum of this scan is enough to distinguish the cartridges? Distinguish yes, identify no. Link to comment Share on other sites More sharing options...
+Al_Nafuur Posted October 5, 2023 Author Share Posted October 5, 2023 8 minutes ago, Thomas Jentzsch said: Distinguish yes, identify no. Yes banked cartridges would have multiple md5sums depending which bank was active during start up, but it would be a finite amount of md5sums per cartridge. Link to comment Share on other sites More sharing options...
Thomas Jentzsch Posted October 5, 2023 Share Posted October 5, 2023 (edited) 7 minutes ago, Al_Nafuur said: Yes banked cartridges would have multiple md5sums depending which bank was active during start up, but it would be a finite amount of md5sums per cartridge. You still have the problem of random values returned by hotspots. These have to be eliminated. So we need two steps: detect bankswitching from first bank create checksum of first bank, ignoring hotspots Also, the first bank may not provide the pattern Stella is looking for. Edited October 5, 2023 by Thomas Jentzsch 1 Link to comment Share on other sites More sharing options...
+MarcoJ Posted October 5, 2023 Share Posted October 5, 2023 The bootloader went on fine using the AVRDude utility and zadig windows driver utility. With the micronucleus inserted, linux on the pi detects it as a USB device. It is now primed to have Timer program changes through Linux. The routing of timer I/O lines are marked up in the photo below. 1 Link to comment Share on other sites More sharing options...
+Al_Nafuur Posted October 5, 2023 Author Share Posted October 5, 2023 13 minutes ago, MarcoJ said: The bootloader went on fine using the AVRDude utility and zadig windows driver utility. With the micronucleus inserted, linux on the pi detects it as a USB device. It is now primed to have Timer program changes through Linux. The routing of timer I/O lines are marked up in the photo below. Cool! Does it have a external (20Mhz) clock? AFAIK the internal one is only 8Mhz. The internal timers can be up-scaled to 8x clock (64Mhz). Which would be fine, but the internal clock seems to have a precision of +/-10% so the up-scaled timers will be not very precise! Link to comment Share on other sites More sharing options...
+Al_Nafuur Posted October 5, 2023 Author Share Posted October 5, 2023 I ordered a few ATtiny25s, but I got ATtiny85 🤷♂️ Waiting for the programmer, it should arrive today. 1 Link to comment Share on other sites More sharing options...
+splendidnut Posted October 5, 2023 Share Posted October 5, 2023 1 hour ago, Al_Nafuur said: Dumping the PlusCart means dumping half the internet 🤣 I get that you're probably joking, BUT, I would think that the PlusCart either starts to it's own menu OR starts with a preloaded game. i.e. a somewhat STATIC ROM. And then when a game is loaded from the PlusCart, Stella would have to re-identify the Cart, probably when the reset vector is hit. Dumping the Cart seems like a viable option.... not necessarily the best option, but an option none-the-less to get things working for now. 1 Link to comment Share on other sites More sharing options...
+MarcoJ Posted October 5, 2023 Share Posted October 5, 2023 5 hours ago, Al_Nafuur said: I ordered a few ATtiny25s, but I got ATtiny85 I could be wrong, but the difference is just the flash size? Link to comment Share on other sites More sharing options...
+MarcoJ Posted October 5, 2023 Share Posted October 5, 2023 5 hours ago, Al_Nafuur said: Does it have a external (20Mhz) clock? AFAIK the internal one is only 8Mhz. The internal timers can be up-scaled to 8x clock (64Mhz). Which would be fine, but the internal clock seems to have a precision of +/-10% so the up-scaled timers will be not very precise! No, it would be currently using the internal one. Given the program on the chip is essentially doing nop delays, it's precision would only be a multiple of 1/20Mhz anyway. Perhaps 50 ns steps, or something like that. I'll look into it more tonight. Link to comment Share on other sites More sharing options...
Kroko Posted October 5, 2023 Share Posted October 5, 2023 (edited) 23 hours ago, Kroko said: no will try that tomorrow ... this is a 2 ms plot of the bus (2000 cycles): the small black interruptions are 5us gaps (or areas where the address bus is not changing 5 cycles), the larger gap is 35 us So at least that new setting changed something ... echo -1 > /proc/sys/kernel/sched_rt_runtime_us Edited October 5, 2023 by Kroko 1 Link to comment Share on other sites More sharing options...
Kroko Posted October 5, 2023 Share Posted October 5, 2023 But this looks quite bad... its recording from DigDug: Link to comment Share on other sites More sharing options...
+Al_Nafuur Posted October 5, 2023 Author Share Posted October 5, 2023 9 minutes ago, Kroko said: But this looks quite bad... its recording from DigDug: The second one is $02 (WSYNC), so this should be normal. The first one is $0284 (INTIM) but looks to me like a WSYNC too 🤷♂️ 1 Link to comment Share on other sites More sharing options...
Kroko Posted October 5, 2023 Share Posted October 5, 2023 3 minutes ago, Al_Nafuur said: The second one is $02 (WSYNC), so this should be normal. The first one is $0284 (INTIM) but looks to me like a WSYNC too 🤷♂️ oh ... I completely forgot about that 1 Link to comment Share on other sites More sharing options...
+Al_Nafuur Posted October 6, 2023 Author Share Posted October 6, 2023 19 hours ago, Thomas Jentzsch said: You still have the problem of random values returned by hotspots. These have to be eliminated. So we need two steps: detect bankswitching from first bank create checksum of first bank, ignoring hotspots Also, the first bank may not provide the pattern Stella is looking for. Does anyone know what the 7800 is doing at startup to generate the checksum of the ROM? I would think it is omitting RAM and hotspots? Link to comment Share on other sites More sharing options...
+Al_Nafuur Posted October 6, 2023 Author Share Posted October 6, 2023 13 hours ago, MarcoJ said: I could be wrong, but the difference is just the flash size? Yes RAM/flash/eeprom sizes are different. The 25 is the smallest, but should be sufficient for our purpose. Link to comment Share on other sites More sharing options...
+MarcoJ Posted October 6, 2023 Share Posted October 6, 2023 14 minutes ago, Al_Nafuur said: Yes RAM/flash/eeprom sizes are different. The 25 is the smallest, but should be sufficient for our purpose. I see what you mean by the 8MHz thing. If our goal is to emulate a 6507 cycle, that gives us only a few instructions to implement this timer. Back to software solution for a second. How difficult would it be to have a separate CPU core in Stella that implements the nop delay only and then send CPU flags/semaphores when the timer is ready? Link to comment Share on other sites More sharing options...
+Al_Nafuur Posted October 6, 2023 Author Share Posted October 6, 2023 7 minutes ago, MarcoJ said: Back to software solution for a second. How difficult would it be to have a separate CPU core in Stella that implements the nop delay only and then send CPU flags/semaphores when the timer is ready? @DirtyHairy has made a similar proposal, but using a cpu cycle counter instead of a nop loop. Both approaches are dependent on the CPU clock, but the cycle counter would be better, because we can compute the amount of cycles to wait if we have the clock speed of the current cpu. For the NOPs this is not that easy and we would have to test for different CPU/Pi versions. 2 Link to comment Share on other sites More sharing options...
+MarcoJ Posted October 6, 2023 Share Posted October 6, 2023 https://s3.amazonaws.com/digistump-resources/files/97a1bb28_DigisparkSchematic.pdf This is the schematic of the Digispark with it's ATTINY85. The external crystal option is possible with pins 2 and 3. However, these pins are already used for the USB interface. Thus, it looks a bit much to mod to have the external crystal for this module. It would suit the bare DIP-8 packages though like what you have. 1 Link to comment Share on other sites More sharing options...
+MarcoJ Posted October 6, 2023 Share Posted October 6, 2023 21 minutes ago, Al_Nafuur said: test for different CPU/Pi versions It is possible to find the Pi in use by running: cat /proc/cpuinfo | grep Model It could be possible to have a database of board types to select an appropriate delay 1 Link to comment Share on other sites More sharing options...
+Al_Nafuur Posted October 6, 2023 Author Share Posted October 6, 2023 32 minutes ago, MarcoJ said: It is possible to find the Pi in use by running: cat /proc/cpuinfo | grep Model It could be possible to have a database of board types to select an appropriate delay Yes , but we would have to keep this database updated and make tests with new devices (Pi6B+/- etc.) to know how many NOPs every model/variant needs, whereas CPU cycles will always be measured in hz: cat /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_cur_freq Link to comment Share on other sites More sharing options...
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
Recommended Posts