Apple II Core
-
- Top Contributor
- Posts: 1144
- Joined: Mon Jul 06, 2020 9:37 pm
- Has thanked: 567 times
- Been thanked: 260 times
Re: Apple II Core
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
- 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
-
- Posts: 112
- Joined: Fri Aug 06, 2021 5:30 pm
- Has thanked: 145 times
- Been thanked: 19 times
Re: Apple II Core
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...)
-
- Posts: 76
- Joined: Thu Feb 25, 2021 10:19 pm
- Has thanked: 64 times
- Been thanked: 18 times
Re: Apple II Core
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!
-
- Posts: 112
- Joined: Fri Aug 06, 2021 5:30 pm
- Has thanked: 145 times
- Been thanked: 19 times
Re: Apple II Core
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.
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.
- LamerDeluxe
- Top Contributor
- Posts: 1181
- Joined: Sun May 24, 2020 10:25 pm
- Has thanked: 829 times
- Been thanked: 266 times
Re: Apple II Core
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.
-
- Posts: 112
- Joined: Fri Aug 06, 2021 5:30 pm
- Has thanked: 145 times
- Been thanked: 19 times
Re: Apple II Core
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.
- RedskullDC
- Posts: 29
- Joined: Fri Jul 03, 2020 2:10 pm
- Has thanked: 4 times
- Been thanked: 25 times
Re: Apple II Core
Hi All,
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
Last time I looked, code to do the DSK => NIB conversion is done on the Linux side.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.
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
-
- Top Contributor
- Posts: 1144
- Joined: Mon Jul 06, 2020 9:37 pm
- Has thanked: 567 times
- Been thanked: 260 times
Re: Apple II Core
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.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
-
- Posts: 112
- Joined: Fri Aug 06, 2021 5:30 pm
- Has thanked: 145 times
- Been thanked: 19 times
Re: Apple II Core
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.
-
- Top Contributor
- Posts: 1315
- Joined: Mon May 25, 2020 7:54 pm
- Has thanked: 429 times
- Been thanked: 415 times
Re: Apple II Core
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.
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.
-
- Posts: 112
- Joined: Fri Aug 06, 2021 5:30 pm
- Has thanked: 145 times
- Been thanked: 19 times
Re: Apple II Core
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
- Posts: 29
- Joined: Fri Jul 03, 2020 2:10 pm
- Has thanked: 4 times
- Been thanked: 25 times
Re: Apple II Core
Hi cathrynmataga, et al.
Take a look at the code in Main_MISTer/DiskImage.cpp
Lines 3183 (as of writing) onwards are dedicated to the Apple][ disk routines.
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
No, nothing so fancy.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.
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
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
-
- Posts: 112
- Joined: Fri Aug 06, 2021 5:30 pm
- Has thanked: 145 times
- Been thanked: 19 times
Re: Apple II Core
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?
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?
-
- Posts: 112
- Joined: Fri Aug 06, 2021 5:30 pm
- Has thanked: 145 times
- Been thanked: 19 times
Re: Apple II Core
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
- Posts: 29
- Joined: Fri Jul 03, 2020 2:10 pm
- Has thanked: 4 times
- Been thanked: 25 times
Re: Apple II Core
Hi Cathrynmataga, et al.
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:
----------------
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".
---------------------------------------------
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)
Hope this helps clarify?
Cheers,
Red
Putting it simply, yes!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.
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
Cheers,
Red
-
- Posts: 112
- Joined: Fri Aug 06, 2021 5:30 pm
- Has thanked: 145 times
- Been thanked: 19 times
Re: Apple II Core
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.
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.-- 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
--
-------------------------------------------------------------------
I tried quote and list, what are you using for the code quotes?-- 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;
Re: Apple II Core
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 wrote: ↑Thu Oct 07, 2021 3:30 pmThe 'phase' stuff in here is pretty weird. Not sure what's going on.
-
- Posts: 112
- Joined: Fri Aug 06, 2021 5:30 pm
- Has thanked: 145 times
- Been thanked: 19 times
Re: Apple II Core
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)));
track_memory(to_integer(ram_write_addr)) <= ram_di;
ram_do <= track_memory(to_integer(track_byte_addr(14 downto 1)));
- RedskullDC
- Posts: 29
- Joined: Fri Jul 03, 2020 2:10 pm
- Has thanked: 4 times
- Been thanked: 25 times
Re: Apple II Core
Hi,
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
Code quoting the the icon that looks like "</>".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)));
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
Re: Apple II Core
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 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.
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: ↑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?
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 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.
- RedskullDC
- Posts: 29
- Joined: Fri Jul 03, 2020 2:10 pm
- Has thanked: 4 times
- Been thanked: 25 times
Re: Apple II Core
Hi,
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
Yep, I was thinking something like that.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.
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
- Top Contributor
- Posts: 830
- Joined: Mon May 25, 2020 1:07 am
- Has thanked: 98 times
- Been thanked: 209 times
Re: Apple II Core
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.
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.
-
- Top Contributor
- Posts: 1315
- Joined: Mon May 25, 2020 7:54 pm
- Has thanked: 429 times
- Been thanked: 415 times
Re: Apple II Core
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.
Re: Apple II Core
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
- Top Contributor
- Posts: 830
- Joined: Mon May 25, 2020 1:07 am
- Has thanked: 98 times
- Been thanked: 209 times
Re: Apple II Core
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.
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.
-
- Posts: 112
- Joined: Fri Aug 06, 2021 5:30 pm
- Has thanked: 145 times
- Been thanked: 19 times
Re: Apple II Core
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?
Re: Apple II Core
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.
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.