Apple II Core

[thorr]

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

NIB images would be good enough I would think. The main thing is being able to write. Hopefully the other issues I mentioned previously can be fixed too. I haven't tried this lately. I have a real Apple IIc with a MockingBoard 4c soundcard and Floppy Emu and I love it. Hopefully someday the MiSTer core will be equal to it.

[cathrynmataga]

Saving, at least works works to HDV. I tried saving a basic program to floppy and prodos gives endless 'path not found' errors. 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.

[akeley]

Hdv saving works but it seems only on prodos converted games? I did experiment a bit with it, but my Apple knowledge is next to nothing and it's not easy to find any info about it.

The .po programs, eg Maniac Mansion, did save correctly but some earlier stuff, like Scott Adams' games (which I "converted" via grabbing files from some other formats than .po) failed.

[cathrynmataga]

I just see HD saving works from basic on Apple. I can write little toy programs and save them, worked fine. I don't know if DOS 3.3 even worked with hard drives, and I'm not sure if games were really converted to prodos on Apple? Most of these games on these hard disks look like simple 'load and go' type games, where everything goes into RAM and that was it. Probably to play Ultima, or Wizardry someone is going to have to untangle the floppy write issue

[RedskullDC]

Hi cathrynmataga, et al.

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

No, nothing so fancy.

Take a look at the code in Main_MISTer/DiskImage.cpp
Lines 3183 (as of writing) onwards are dedicated to the Apple][ disk routines.

Code: Select all

#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

Each raw track is assumed to be $1A00 bytes long (6656 decimal).
35 tracks == 6656 x 35 = 232960 bytes in length, which is your standard 35 track NIB images size.

If you look at the source code for AppleWin for example, it's pretty straight forward.
Writing a byte to the disk][ hardware just saves the byte in the buffer, bumps the pointer into the current track, and wraps when it passes track[6655].

That doesn't allow fancy protection schemes (half tracks, missing bits etc.) to work, but it will allow most software to work.
--------------------------

The disk_ii.vhd module in the Apple][ core is read-only, and only deals with one track at a time, which is fed by the hps_io module.

That's the module that needs to be changed to support writes.

Regards,
Red

[cathrynmataga]

That sounds like really useful information. I was wondering myself where the Apple2 disk code was myself, didn't realize it was in Main_MiSTer. You'd be surprised how much time of with programming goes into 'finding the file with the code in it.'

This guy here is talking about Mac disk encoding, why maybe this missing for the Mac core also
https://www.bigmessowires.com/2011/10/0 ... g-schemes/

And someone in the comments referenced this.
http://www.apple-iigs.info/doc/fichiers ... prodos.pdf

It's Appendix C of this where it starts to get interesting. It sounds like all this nibble-izing happens in the software, that'll be in the embedded DOS3.3 or whatever that's in the games. So that's what the hardware is going to see?

[cathrynmataga]

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.

[RedskullDC]

Hi Cathrynmataga, et al.

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.

Putting it simply, yes!

The '.NIB' image format has been around for a very long time, more on it here:
https://stason.org/TULARC/pc/apple2/emu ... O-NIB.html

--------------------------

How it works at the moment (Main_MISTer:user_io.cpp)

When the user tries to mount a disk image in a given core, MAIN has a chance to intercept.
If the core name is "apple-ii" (as defined in the config string), the dsk2nib() function is called to translate to NIB format internally:

Code: Select all

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);
		}
.....

----------------

dsk2nib() (MAIN:DiskImage.cpp) looks for a match on the image name string to selectively convert.

".po", ".dsk", ".do" are all converted to a NIB image "vdisk" (at least that's how it looks to me...)

No conversion is attempted on other image types, such as ".nib".

Code: Select all

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

---------------------------------------------

As we said prior, each NIB track is $1A00 (6656) bytes long.

Rather conveniently, 13 x 512 byte sectors (on the host SD Card) = 6656 bytes too.

Code on the Apple II core side converts the current track number to a logical block address into the NIB image on the host side.
Each time disk head is moved in or out, the LBA is re-calculated:

In Apple-II_MISTer:Apple-II.sv (line 491)

Code: Select all

	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

Hope this helps clarify?

Cheers,
Red

[cathrynmataga]

The guts of this are in disk_ii.vhd, looks like. Maybe it does simulate a spinning track, basically. The 'phase' stuff in here is pretty weird. Not sure what's going on.

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

di is disk write and do is disk read looks like? It does look like someone at least started on disk write,but maybe hit a problem some point.

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

I tried quote and list, what are you using for the code quotes?

[ExCyber]

The 'phase' stuff in here is pretty weird. Not sure what's going on.

It's a simulation of the stepper motor that moves the head between tracks. In this context, "phase" is stepper motor jargon for a set of coils that are energized. The motor won't actually complete a "step" without an appropriate sequence of phases being energized. The Disk II card exposes the individual stepper phases to the CPU (because of course it does), so the core needs to interpret them to figure out when the head has moved to a new track.

[cathrynmataga]

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)));

[RedskullDC]

Hi,

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)));

Code quoting the the icon that looks like "</>".

Dealing with a NIB doesn't simulate a spinning disk.
It just assumes that the head is in the right place when switching between read/write.
Every READ/WRITE just advances a pointer in the track buffer, before wrapping back to zero at 6656.

Real Apple disk has all manner of "self-sync" bytes to keep the software synchronised to each byte on disk.
Beyond the scope of discussion here, recommend you take a look at "Beneath Apple DOS" for a very thorough treatise.
https://archive.org/details/beneath-app ... rodos-2020

That is not necessary when dealing with a NIB image, since the "hardware" is always aligned to a byte.

Typical sequence from a NIB image:

DEAAEBFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFD5AA96BEFBAAAAAFAEBBFFDEAAEAD2FFFFFFFFFFFFFFD5AAADA7AC9A

"DEAAEB" is the end of the previous sector.
"D5AA96" is the start of a sector header.
"D5AAAD' is the start of the matching sector data.

-----------------------
disk-ii.vhd maintains a single track buffer of NIB data.

At the moment, when the hardware steps a track, the next track data is loaded into that buffer for the Apple II to look at.

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

I've forked the Apple-II core, if I get time will have a look on the weekend

Cheers,
Red

[ExCyber]

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.

Those expressions probably would be similar in a version of the code that supports floppy writes. As it is now, the write path exclusively handles the top-level core filling the track RAM with data from the image file, while the read path exclusively handles the Apple II system reading data from the simulated track. For floppy write support, the Apple II system would need the addition of write behavior that modifies the current track position, while the top-level core would need the addition of read behavior that can sequentially dump the track RAM to write back to the image file.

Maybe it's not really simulating the spinning disk, but trying to estimate where it's reading/writing some other way?

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?

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

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.

[RedskullDC]

Hi,

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.

Yep, I was thinking something like that.

If write signal is turned on while the drive is enabled, set a "track_dirty" signal.
When the drive is de-enabled, if the track_dirty signal is set *OR* the current track changes, write the track data back out to SD.

Having the "track_dirty" signal also does away with unnecessary writes back to the SD card on track changes when no data was written.

Needs a little bit of work in both disk-ii.vhd and appl-ii.sv.

Cheers,
Red

[Newsdee]

I forgot who mentioned this first, but one idea that I thought was interesting is to treat disks like console SRAM, and the floppy disk like a read-only ROM image. That means the MiSTer would dump .sav files with the disk contents, that gets reloaded when loading a .dsk/.nib.

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.
It also makes it easy to backup your files as there is a standard script that syncs the MiSTer /saves/ folder to google drive.

In many console cores the .sav file is written when you open the OSD. Minor annoyance, but at least it would be consistent with console cores.

[akeley]

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.

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.

[ExCyber]

I don't think the SRAM framework is a great fit for floppies, especially on Apple II. The key thing is that there isn't necessarily a 1:1 relationship between program disk and save disk the way that there is for cartridge and SRAM. Some programs only save user data to the program disk itself, some only save to a separate save disk, and some can save to either. I don't recall specific examples, but I think a few programs require a separate disk for each "save slot". Some programs span multiple original disks that share save disks, and I think some Ultima and Wizardry games allow transferring a character from a previous game. Trying to fit all of this variation into the SRAM framework seems likely to cause more problems than it solves.

[Newsdee]

Good point, I could accomplish the same backup operation if I put the floppy images in the /saves/ folder, so they get synced with the base script

Proper write support would be great to have, this core is almost perfect as is except for it.

The only other features I could think of are mouse support and ability to print to an image file, but those are really marginal features and not needed by most games or programs in the library.

[cathrynmataga]

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?

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]

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.

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.

Removing the register access condition breaks floppy reading, so I guess either the spin delay is wrong or something else is missing. I don't really understand how the code behavior corresponds to the Disk II state machine. There's a comment that might be related to this, but I think I'd need to study the Disk II in more detail to really understand it:

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.

[cathrynmataga]

http://www.mac.linux-m68k.org/devel/iwm.php Found this link on APple 2 disk.

It looks from this, if you run off only a timer that Q6 should go to + after a read, and then go to -(the data) after the next timer tick? I guess NIB files only have negative values? If Q6 never goes positive, the code will read in duplicate values until the next timer tick. I looked at disk_ii.vhd, and I don't see evidence of this, though I'm not sure.

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

I guess on real hardware, it depends on the state machine to collect the bits, but I think mostly that doesn't matter for us right now. The hope is if we can get rid of the dependence on (read_disk = '1' and PHASE_ZERO = '1') that maybe we'd be closer to getting the data pointer in the correct position for write also.

[RedskullDC]

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

[cathrynmataga]

Ooh, that sounds really promising. Looking forwards to seeing the diff.

[AmintaMister]

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

Fantastic! Keep us informed, it's very important implement this feature!

[Flandango]

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!
Since you only need the ram for storing the image and not doing anything that is time sensitive, you may want to look at maybe using DDR ram for storing the image.

[Sorgelig]

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.

[cathrynmataga]

Keyboard is better with 21/10/18 build. Makes it possible to type now. Just, is it intentional that the \ and ` keys are swaped on my USA keyboard? \ prints ` and | show ~.

[ExCyber]

I'm not sure about the details, but I think the scan code lookup table and character ROM built into the core are for a UK keyboard. SHIFT+3 produces a pounds sign instead of a number sign, for example.

[cathrynmataga]

Actually I googled this a little, and though I didn't find a real source on this, it looks like `~ \| keys are just weird across different international keyboards. Really, it's not a problem

[RedskullDC]

Hi Sorgelig et al.,

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.

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.

If the full disk is loaded to memory it is time consuming, sure, but it only has to happen the once for read, and again if the user saves the image back to disk.

I'll play around and see how it goes.

Progress so far:

All main/aux/ram card memory has been moved across to SDRAM.
This will free up more block ram to allow two drives.

Will also allow a bigger RAM card to be emulated.
An Apple //e is better off with a 1MB "Slinky", or something like a "Ram Factor" card.
Saturn 128K belongs in a ][+.

https://github.com/RedskullDC/Apple-II_MiSTer

Next steps:
Get 2 drives working
Get disk writes working.
Add menu option to save disks back to the SD Card.

Cheers,
Red