MiSTer FPGA Forum

RedskullDC wrote: ↑Sat Oct 02, 2021 6:43 am Last time I looked, code to do the DSK => NIB conversion is done on the Linux side.
NIB image in memory is what the Apple 2 core works with.

Being able to save a NIB image shouldn't be too hard to do, but saving as a DSK means you need to:
Have to have the code on the linux side to convert from NIB back to DSK
Be able to build the Linux side yourself.

Cheers,
Red

cathrynmataga wrote: ↑Sat Oct 02, 2021 3:03 pm ...It looks like something is missing on the hardware side. I don't even know how this works, I think it writes to the actual drive head from software? That it'd have to simulate an actual spinning disk? Low level Apple 2 floppy disk code was pretty obscure stuff, already in the 80s.

#define VOLUME_NUMBER 254

#define TRACKS 35
#define SECTORS 16
#define SECTOR_SIZE 256
#define DOS_TRACK_uint8_tS (SECTORS * SECTOR_SIZE)

#define RAW_TRACK_uint8_tS 0x1A00

cathrynmataga wrote: ↑Mon Oct 04, 2021 4:51 pm Oh I think I see what you're saying about writing nib now. If .nib is a nibble-ized sector with all this crazy already baked int. Maybe we could get this with write support, but for nib files only.

int user_io_file_mount(const char *name, unsigned char index, char pre)
{
	int writable = 0;
	int ret = 0;
	int len = strlen(name);

	sd_image_cangrow[index] = (pre != 0);
	sd_type[index] = 0;

	if (len)
	{
		if (!strcasecmp(user_io_get_core_name(), "apple-ii"))
		{
			ret = dsk2nib(name, sd_image + index);
		}
.....

int dsk2nib(const char *name, fileTYPE *f)
{
	int len = strlen(name);
	int po = 0;

	if (len > 3 && !strcasecmp(name + len - 3, ".po"))
	{
		po = 1;
	}
	else if (!(len > 4 && !strcasecmp(name + len - 4, ".dsk")) && !(len > 3 && !strcasecmp(name + len - 3, ".do")))
	{
		return 0;
	}
.....

	else if(!state) begin
		if((cur_track != track) || (fdd_mounted && ~img_mounted[0])) begin
			cur_track <= track;
			fdd_mounted <= 0;
			if(img_size) begin
				track_sec <= 0;
				lba_fdd <= [b]13[/b] * track;
				state <= 1;
				sd_rd[0] <= 1;
				cpu_wait_fdd <= 1;
			end
		end

-- Writing
-- STA $C08F,X set write mode
-- ..
-- LDA DATA
-- STA $C08D,X load byte to write
-- STA $C08C,X write byte to disk
--
-- Data bytes must be written in 32 cycle loops.
--
-- There are 70 phases for the head stepper and and 35 tracks,
-- i.e., two phase changes per track.
--
-- The disk spins at 300 rpm; one new bit arrives every 4 us
-- The processor's clock is 1 MHz = 1 us, so it takes 8 * 4 = 32 cycles
-- for a new byte to arrive
--
-- This corresponds to dividing the 2 MHz signal by 64 to get the byte clock
--
-------------------------------------------------------------------

-- Dual-ported RAM holding the contents of the track
track_storage : process (CLK_14M)
begin
if rising_edge(CLK_14M) then
if ram_we = '1' then
track_memory(to_integer(ram_write_addr)) <= ram_di;
end if;
ram_do <= track_memory(to_integer(track_byte_addr(14 downto 1)));
end if;
end process;

cathrynmataga wrote: ↑Thu Oct 07, 2021 3:30 pmThe 'phase' stuff in here is pretty weird. Not sure what's going on.

cathrynmataga wrote: ↑Thu Oct 07, 2021 7:02 pm I'd have thought, the thing going into 'track_memory' to tell it where to index would be the same for both read and write. Since the position of the head for both would be the same. It's got to land in exactly the right spot for write, with read it goes bad, whatever, but with write it'll trash other data if it's not perfect. Maybe it's not really simulating the spinning disk, but trying to estimate where it's reading/writing some other way?

track_memory(to_integer(ram_write_addr)) <= ram_di;
ram_do <= track_memory(to_integer(track_byte_addr(14 downto 1)));

cathrynmataga wrote: ↑Thu Oct 07, 2021 7:02 pm I'd have thought, the thing going into 'track_memory' to tell it where to index would be the same for both read and write.

cathrynmataga wrote: ↑Thu Oct 07, 2021 7:02 pm Maybe it's not really simulating the spinning disk, but trying to estimate where it's reading/writing some other way?

RedskullDC wrote: ↑Thu Oct 07, 2021 9:56 pmIf writes are enabled, the old track data (the track we have just left) needs to be saved before loading the new track.
MAIN supports this, just need some extra code in Apple-ii.sv to read the old track data out.

Only problem I can see is that there needs to be some *extra* mechanism (apart from changing tracks) to ensure that the very last track written to by the Apple II hardware is saved back to the image file.
You can't guarantee that a track change will occur (triggering a track write back to the image) before powering off the MISTer.

ExCyber wrote: ↑Thu Oct 07, 2021 10:37 pm Would it be sufficient to additionally trigger the save logic when the spindle motor turns off? I suppose nothing technically stops software from just spinning the disk indefinitely, but I would hope that there isn't much software that does this after a write operation.

Newsdee wrote: ↑Fri Oct 08, 2021 5:27 am It's a bit of a stretch since it replaces the whole disk on load, but I do like the idea in that it preserves the original disk files.

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?

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.

  -- 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.

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

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

Sorgelig wrote: ↑Mon Oct 18, 2021 6:19 pm Better to keep per track loading/writing. The same is done in other cores too. Write/read a whole disk at once is time consuming operation.