I am still having the same problem with NIB that has obstructed everybody that ever tried to come up with a disk to write them out to a real disk: the file format is just too much of a fiction. If you're building from source, this won't affect you either way. The emulator includes the pause.Īlso: I'm dithering this way and that on exactly what to tackle next but expect a release before the weekend, because I'm going away. Also I guess it needs to be factored in to maximum Disk II density calculations. If you had truly golden ears then I guess you should be able to hear the pause when the CPU is generating audio, but I'd be surprised. 1/7th is exactly half a colour cycle, and NTSC is supposed to have every other line be 180 degrees out of phase, but that's a bit awkward if you have the programmer directly involved in artefact colours so the machine just takes the brief pause so that every line has exactly the same colour generation rules. On the 1/7th: it's to ensure that every line of pixel output has the same phase relative to the NTSC colour subcarrier. I think in principle it means I'm an extra cycle behind only every 36-and-a-bit days but it's probably a bit worse than that because of rounding errors that result from using that sort of precision. Since the emulator treats machine clock rate as a double, I think my Apple II actually runs at only 1.020484Mhz. For the CPU it's divided by 14 but for colour output reasons the CPU takes a 1/7th of a cycle pause at the end of every 65th cycle. My understanding is that there's 14.31818Mhz master crystal, which divides by four to give the standard NTSC 3.579545Mhz. Just for information and to be precise, Apple II's clock is 1.0205 Mhz (not 1.0250) (according Jim Sather's "Understanding the Apple II", THE reference.) Which will be really helpful since the complete set of all feedback I've received on the Apple II emulation is: it seems to load slowly. Then I can see what the Disk II speed test says.
#Oric emulator mac full
So a full Oric wouldn't be too much more processing than that.ĮDIT: re the Clock Signal changes on internal modified disk representation, I don't think it'll take much longer.
#Oric emulator mac serial
The C1541 has a 1Mhz 6502 and two 6522s, can signal the serial bus at any time, and can be used to run user programs so you can't make any further assumptions than that. Those notes of caution all being sounded, I read recently that somebody has reimplemented the C1541 as a bare-metal Raspberry Pi program (for hard real-time scheduling) so that you can wire it up to a real C64 via the Commodore serial bus and the C64 can't tell the difference. Either the emulation would be fast enough to provide the real bus or it wouldn't be. But it can do cycle-by-cycle processing if needs be, so I guess that's no big deal. When you write it runs the video quickly for as many cycles as it should have run, then does the write. Which would make the emulator a little less efficient because it currently does that stuff just-in-time - unless and until you write to an area within the video range, no video processing occurs. You'd also need to add the video accesses into what you communicate outward, I guess, as they're surely observable. Then the emulation processing needs to happen very promptly to get to the next cycle, ideally in zero microseconds.
So for real hardware you need to then replay the whole bus cycle, possibly sampling the real bus to supply back to the virtual one. Which is the processor telling you what it did for the last clock cycle to get up to now, when it expects either to sample the bus again or else is currently actively loading something that somebody else could sample. in the Oric specifically you've got the function that receives a complete clock-cycle of activity from the 6502 in one fell swoop.
Most of the machines work similarly, but e.g. Re: potentially attaching real hardware, I think the main constraint as currently arranged would be timing. I'm hoping to work up to adding a 16-bit floppy-based machine to my emulator at some point, as I think that'll really help me to figure out how well my handling of this stuff works there's a lot more there to test with in terms of protection schemes. Capture devices like the Kryoflux will provide the big versions if you want them, but the summarised forms have the critical mass. Where 'very large' is large enough to be problematic for devices like floppy emulators to stream in real time from an SD card.
My understanding of the problem with disk images, even now that a lot of very clever people have a very thorough understanding of all the analogue issues and emulator authors tend to talk to one another, is that they can either be very large or not completely descriptive.
0 kommentar(er)
