Apple II Core

thorr
Top Contributor
Posts: 1099
Joined: Mon Jul 06, 2020 9:37 pm
Has thanked: 535 times
Been thanked: 252 times

Re: Apple II Core

Unread post by thorr »

Some of the keys are not mapped correctly:
- I can't find the open and closed apple keys
- The \ and | are being mapped to ` and ~
- The ` and ~ are recognized but I am not sure what they are
- The backspace should be printing a cursor but it is acting like the left arrow

I wrote the following program to test the keys:
10 K=PEEK(-16384)
20 PRINT K
30 GOTO 10
RUN
Press control alt del to break out of it

Also, I think the colors are wrong. Two of the colors should be gray and look the same. I wrote the following program to test the colors:
10 GR
20 FOR X = 1 TO 15
30 COLOR = X
40 PLOT X,X
50 NEXT X
cathrynmataga
Posts: 109
Joined: Fri Aug 06, 2021 5:30 pm
Has thanked: 140 times
Been thanked: 18 times

Re: Apple II Core

Unread post by cathrynmataga »

Looks like the Apple II HDD support made it in the main line. Looking forwards to seeing it. This was a nice improvement. (Waiting on a long update_all.sh right now...)
User avatar
Moondandy
Top Contributor
Posts: 535
Joined: Mon May 25, 2020 2:14 am
Location: Edinburgh, Scotland
Has thanked: 32 times
Been thanked: 97 times

Re: Apple II Core

Unread post by Moondandy »

Am I right in thinking that none of the Apple cores have RTC implemented? Seems odd that none of them utilise this.
zorrobandito
Posts: 76
Joined: Thu Feb 25, 2021 10:19 pm
Has thanked: 64 times
Been thanked: 18 times

Re: Apple II Core

Unread post by zorrobandito »

Just dropping a note to say thanks for the Apple 2 core. I never had one back in the day and, though I was aware of their place in gaming's pantheon, I never had the chance to play one. I've just spent a couple of hours playing Prince of Persia and Airheart and I'm really impressed with both the games and the Apple 2 itself. I'm also very grateful that we have the MISTer and its dev community creating this amazing environment where dipping into computing and gaming history is so convenient!
cathrynmataga
Posts: 109
Joined: Fri Aug 06, 2021 5:30 pm
Has thanked: 140 times
Been thanked: 18 times

Re: Apple II Core

Unread post by cathrynmataga »

I've been playing with this also. Definately some interesting games on this system, and some of the earliest.

I discover "POKE 48984,192" and then "-[filename]" to get some games to run from Prodos hard disk image, the ones that complain about buffers. Also CHDIR on Prodos is PREFIX. and DIR is CATALOG. Not sure now, did I know this stuff one time or not? I used Apple 2 a little, but was never a heavy user. I'm not sure why you'd ever set "Pixel Clock" to anything other than double, but this seems to make 80 column work correctly with pr #3. Still not sure how to catalog with wildcards but this is me, not the core.

Definately has some interesting games on this system, really, I've just been rummaging through the apple-2.com images myself.
User avatar
LamerDeluxe
Top Contributor
Posts: 1160
Joined: Sun May 24, 2020 10:25 pm
Has thanked: 798 times
Been thanked: 257 times

Re: Apple II Core

Unread post by LamerDeluxe »

It would really be handy if cores had an extra tab in their menu, with a bit of text giving some hints on how to use that system (including the core's MiSTer hot keys), so I don't have to memorize or look it up for each core.
akeley
Top Contributor
Posts: 1303
Joined: Mon May 25, 2020 7:54 pm
Has thanked: 416 times
Been thanked: 399 times

Re: Apple II Core

Unread post by akeley »

The core is great for casual use, but the lack of floppy save feature is a big stumbling block. Hope some good soul will sort it out one day.
rhester72
Top Contributor
Posts: 1107
Joined: Thu Jun 11, 2020 2:31 am
Has thanked: 13 times
Been thanked: 169 times

Re: Apple II Core

Unread post by rhester72 »

Has anyone had any luck at all with running in Karateka? With analog input, I can't seem to make the smooth necessary transition from Up to Right. :/
cathrynmataga
Posts: 109
Joined: Fri Aug 06, 2021 5:30 pm
Has thanked: 140 times
Been thanked: 18 times

Re: Apple II Core

Unread post by cathrynmataga »

akeley wrote: Fri Oct 01, 2021 1:18 pm The core is great for casual use, but the lack of floppy save feature is a big stumbling block. Hope some good soul will sort it out one day.
Lack of floppy write is a bit of a joy killer, since much of Apple 2 culture was floppy based and I guess the floppy write code is baked into the games, so the hardware has to be right maybe? I saw the comments on this. This might need someone with good understanding of low-level disk operation on Apple 2, and willing to work with FPGA, and that person may not exist. We'll see.
User avatar
RedskullDC
Posts: 29
Joined: Fri Jul 03, 2020 2:10 pm
Has thanked: 4 times
Been thanked: 25 times

Re: Apple II Core

Unread post by RedskullDC »

Hi All,
cathrynmataga wrote: Fri Oct 01, 2021 3:30 pm Lack of floppy write is a bit of a joy killer, since much of Apple 2 culture was floppy based and I guess the floppy write code is baked into the games, so the hardware has to be right maybe? I saw the comments on this. This might need someone with good understanding of low-level disk operation on Apple 2, and willing to work with FPGA, and that person may not exist. We'll see.
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
thorr
Top Contributor
Posts: 1099
Joined: Mon Jul 06, 2020 9:37 pm
Has thanked: 535 times
Been thanked: 252 times

Re: Apple II Core

Unread post by thorr »

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
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
Posts: 109
Joined: Fri Aug 06, 2021 5:30 pm
Has thanked: 140 times
Been thanked: 18 times

Re: Apple II Core

Unread post by 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
Top Contributor
Posts: 1303
Joined: Mon May 25, 2020 7:54 pm
Has thanked: 416 times
Been thanked: 399 times

Re: Apple II Core

Unread post by 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
Posts: 109
Joined: Fri Aug 06, 2021 5:30 pm
Has thanked: 140 times
Been thanked: 18 times

Re: Apple II Core

Unread post by 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
User avatar
RedskullDC
Posts: 29
Joined: Fri Jul 03, 2020 2:10 pm
Has thanked: 4 times
Been thanked: 25 times

Re: Apple II Core

Unread post by RedskullDC »

Hi cathrynmataga, et al.
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.
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
Posts: 109
Joined: Fri Aug 06, 2021 5:30 pm
Has thanked: 140 times
Been thanked: 18 times

Re: Apple II Core

Unread post by 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
Posts: 109
Joined: Fri Aug 06, 2021 5:30 pm
Has thanked: 140 times
Been thanked: 18 times

Re: Apple II Core

Unread post by 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.
User avatar
RedskullDC
Posts: 29
Joined: Fri Jul 03, 2020 2:10 pm
Has thanked: 4 times
Been thanked: 25 times

Re: Apple II Core

Unread post by RedskullDC »

Hi Cathrynmataga, et al.
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.
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
Posts: 109
Joined: Fri Aug 06, 2021 5:30 pm
Has thanked: 140 times
Been thanked: 18 times

Re: Apple II Core

Unread post by 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
Posts: 217
Joined: Sun May 24, 2020 3:33 pm
Has thanked: 11 times
Been thanked: 66 times

Re: Apple II Core

Unread post by ExCyber »

cathrynmataga wrote: Thu Oct 07, 2021 3:30 pmThe '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
Posts: 109
Joined: Fri Aug 06, 2021 5:30 pm
Has thanked: 140 times
Been thanked: 18 times

Re: Apple II Core

Unread post by 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)));
User avatar
RedskullDC
Posts: 29
Joined: Fri Jul 03, 2020 2:10 pm
Has thanked: 4 times
Been thanked: 25 times

Re: Apple II Core

Unread post by RedskullDC »

Hi,
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)));
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 :shock:

Cheers,
Red
ExCyber
Posts: 217
Joined: Sun May 24, 2020 3:33 pm
Has thanked: 11 times
Been thanked: 66 times

Re: Apple II Core

Unread post by ExCyber »

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.
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.
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?
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?
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.
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.
User avatar
RedskullDC
Posts: 29
Joined: Fri Jul 03, 2020 2:10 pm
Has thanked: 4 times
Been thanked: 25 times

Re: Apple II Core

Unread post by RedskullDC »

Hi,
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.
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
User avatar
Newsdee
Top Contributor
Posts: 830
Joined: Mon May 25, 2020 1:07 am
Has thanked: 98 times
Been thanked: 209 times

Re: Apple II Core

Unread post by 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
Top Contributor
Posts: 1303
Joined: Mon May 25, 2020 7:54 pm
Has thanked: 416 times
Been thanked: 399 times

Re: Apple II Core

Unread post by akeley »

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.
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
Posts: 217
Joined: Sun May 24, 2020 3:33 pm
Has thanked: 11 times
Been thanked: 66 times

Re: Apple II Core

Unread post by 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.
User avatar
Newsdee
Top Contributor
Posts: 830
Joined: Mon May 25, 2020 1:07 am
Has thanked: 98 times
Been thanked: 209 times

Re: Apple II Core

Unread post by 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 :mrgreen:

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
Posts: 109
Joined: Fri Aug 06, 2021 5:30 pm
Has thanked: 140 times
Been thanked: 18 times

Re: Apple II Core

Unread post by cathrynmataga »

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?
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
Posts: 217
Joined: Sun May 24, 2020 3:33 pm
Has thanked: 11 times
Been thanked: 66 times

Re: Apple II Core

Unread post by ExCyber »

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