I don't think that's a real concern since the "original" disks are already copies - you can make many more and they are all over the net.
Also, some programs need to be write-enabled to work at all.
I don't think that's a real concern since the "original" disks are already copies - you can make many more and they are all over the net.
That's nice, to me, I find the idea of the system simulating the spinning disk aesthetically pleasing. Though ideally, it should spin that disk, it shouldn't care what data registers the CPU looks at or anything, no hacks, no nothing -- if the 6502 doesn't read it in time, the byte is just lost. I assume that's what the real hardware does. 6502 with no interrupts is pretty deterministic, and any code that was developed on emulators that doesn't time this properly has every right to break. This is Mister, and this stuff should be correct, is kind of the spirit of this I feel. Besides, all these games out there with embedded DOS 3.3 in them, who knows what they're doing, what weird hacks are lurking out there.ExCyber wrote: ↑Thu Oct 07, 2021 10:37 pm It's been a while since I studied this code (and I did so with the primary goal of adding a second drive, not write support), but I do think it simulates the spinning disk, albeit fudging it a bit. I believe the position increments based on a counter expiring or when the CPU reads the data register. I'm not sure why there are two conditions; maybe it's for compatibility with routines that were developed on emulators or that take the wrong amount of time on a 65C02?
I basically agree, although that line of thought probably ends with implementing a flux transition buffer, simulating the MC3470, and supporting WOZ 2.0 images. I'm not opposed to that, but I also don't expect enough developer interest to actually see it happen.cathrynmataga wrote: ↑Sun Oct 10, 2021 5:29 amThat's nice, to me, I find the idea of the system simulating the spinning disk aesthetically pleasing. Though ideally, it should spin that disk, it shouldn't care what data registers the CPU looks at or anything, no hacks, no nothing -- if the 6502 doesn't read it in time, the byte is just lost. I assume that's what the real hardware does. 6502 with no interrupts is pretty deterministic, and any code that was developed on emulators that doesn't time this properly has every right to break. This is Mister, and this stuff should be correct, is kind of the spirit of this I feel. Besides, all these games out there with embedded DOS 3.3 in them, who knows what they're doing, what weird hacks are lurking out there.
Code: Select all
-- Lower bit indicates whether disk data is "valid" or not
-- RAM address is track_byte_addr(14 downto 1)
-- This makes it look to the software like new data is constantly
-- being read into the shift register, which indicates the data is
-- not yet ready.
Code: Select all
LDA Q7 ;insure read mode
R1 LDA Q6 ;ready yet?
BPL R1 ;if not, try again
STA DATA1 ;got a valid byte, so save it
R2 LDA Q6 ;repeat ad nauseam...
BPL R2
STA DATA2
R3 LDA Q6
BPL R3
STA DATA3
Fantastic! Keep us informed, it's very important implement this feature!RedskullDC wrote: ↑Mon Oct 11, 2021 1:42 am Hi All,
Had a tinker with the Apple II core over the weekend.
Got the write working ok in the disk ii module.
Was able to write a sector using CIA utilities and read it back ok.
Though it might make more sense to download the whole NIB disk image to RAM, rather than a track at a time.
Tried that, but there are not enough free 10K RAM blocks available
That makes saving the image file back out a bit more complicated.
Will keep at it...
Cheers,
Red
Great work!RedskullDC wrote: ↑Mon Oct 11, 2021 1:42 am Hi All,
Had a tinker with the Apple II core over the weekend.
Got the write working ok in the disk ii module.
Was able to write a sector using CIA utilities and read it back ok.
Though it might make more sense to download the whole NIB disk image to RAM, rather than a track at a time.
Tried that, but there are not enough free 10K RAM blocks available
That makes saving the image file back out a bit more complicated.
Will keep at it...
Cheers,
Red
With the current setup, each track is re-read from the SD card , decoded to NIB, processor halted while the track mem is updated each time the drive head is moved. This can have quite an impact.
Thanks for the bug report.breiztiger wrote: ↑Thu Nov 11, 2021 9:43 am perhaps a bug
https://www.pouet.net/prod.php?which=75630
this doesn't restart correctly after one run, have scramble caracters at buttom
run well in core 21.10.18
The colors in the core were taken from this newsgroup post:
I'm torn on this. The Apple II keyboard layout is somewhat odd in that:
Most of those colors seem reasonably close to what I see from the core, but the "gray" colors (#5 and #10) are very obviously different from each other, and neither looks even close to a 50% gray, at least on my monitor+eyes.Newsdee wrote: ↑Sat Nov 13, 2021 2:39 amThe colors in the core were taken from this newsgroup post:
https://groups.google.com/g/comp.sys.ap ... XDxQhWi1AJ
I like the idea of having an option to switch it to a PC layout. I will look at this. I find it really hard to use the cores in the original layout when you just want to play a few games. If you want it as a replacement for the original, then the original layout makes a bit more sense.cathrynmataga wrote: ↑Sat Nov 13, 2021 3:24 pm Maybe for the UK cores, the keyboard layout is 'part of the thing,' but with Apple 2, there were all kinds of keyboard layouts, and they eventually evolved towards the PC style layout in the end. I prefer the PC layouts myself. The PC emulators I use mostly use PC layouts, and it's a quirk of mister, hunting around in oddball cores to find where the '*' key is. If there's an option to select the 'PC Keyboard' I pick it first thing. I think COCO2 core has this.
That said, left, right alt for open and closed apple, makes sense. F11 for reset?
https://apple2history.org/wp-content/up ... yboard.jpg
Keyboard code only emulates the ASCII keys.