Previous Thread
Next Thread
Print Thread
Page 6 of 6 1 2 3 4 5 6
#95672 - 08/26/14 03:20 PM Re: That Apple /// thread (was -bitb 119200 etc) [Re: datajerk]  
Joined: Mar 2001
Posts: 15,550
R. Belmont Offline
R. Belmont  Offline

Very Senior Member

Joined: Mar 2001
Posts: 15,550
USA
Emulating the Titan card's on my long-term list of things to do. It's too perverted not to at least attempt.

I've seen (and now heard, on the podcast) mentions of an SOS driver for the LIRON card and UniDisk 3.5. That's certainly an emulatable thing if the driver is findable (I haven't seen it anywhere, but I haven't looked very hard either).

I played some Dung Beetles on the emulation post-fix and it's fine aside from being monochrome. I'm fairly certain they don't have a IIgs-style NTSC artifact emulator in the /// and hi-res is monochrome, but confirmation is always good.

#95828 - 09/05/14 10:56 PM Re: That Apple /// thread (was -bitb 119200 etc) [Re: datajerk]  
Joined: Feb 2014
Posts: 27
datajerk Offline
Member
datajerk  Offline
Member

Joined: Feb 2014
Posts: 27
New bug with latest SVN. It doesn't matter what you pass -flop2 -flop3, etc... in from the Apple /// POV .D2, .D3, .D4 have the same content as .D1. Using the menu to change disks has no effect. Always the same as .D1. Older build from around April do not have this bug.

#95830 - 09/05/14 11:08 PM Re: That Apple /// thread (was -bitb 119200 etc) [Re: datajerk]  
Joined: Jul 2014
Posts: 10
paulhagstrom Offline
Member
paulhagstrom  Offline
Member

Joined: Jul 2014
Posts: 10
I was digging around a little bit to try to locate the drive content problem. The Apple /// drive select soft switches are a bit strange, it uses three bits to select the drive, one bit is just .D1 yes/no, and the other two select among .D2-.D4. This is handled in wozfdc.c, but it's still what I'm suspicious of. For one thing, it looks to me like the C0D4 and C0D5 behaviors are reversed (for selecting and deselecting the internal .D1 drive), which I could imagine leading to this effect (since selecting .D1 overrides any other drive), except simply changing 0 to 1 and 1 to 0 didn't eliminate the problem. Still looking at it though.

#95831 - 09/05/14 11:55 PM Re: That Apple /// thread (was -bitb 119200 etc) [Re: datajerk]  
Joined: Jul 2014
Posts: 10
paulhagstrom Offline
Member
paulhagstrom  Offline
Member

Joined: Jul 2014
Posts: 10
Ok, got it, or at least worked around it. I don't know how to do a pull request, but at the very end of wozfdc.c, adding

a3_update_drive_sel();

before appleiii_fdc::control_dx returns will recognize the drives correctly again. Still not sure about C0D4 and C0D5 but I left them alone and it seems to work fine. It just seems that the drive selection was being done but then not "committed."

#95832 - 09/06/14 12:33 AM Re: That Apple /// thread (was -bitb 119200 etc) [Re: datajerk]  
Joined: Mar 2001
Posts: 15,550
R. Belmont Offline
R. Belmont  Offline

Very Senior Member

Joined: Mar 2001
Posts: 15,550
USA
Thanks, I'll commit that smile

#95854 - 09/07/14 06:38 AM Re: That Apple /// thread (was -bitb 119200 etc) [Re: datajerk]  
Joined: Jul 2014
Posts: 10
paulhagstrom Offline
Member
paulhagstrom  Offline
Member

Joined: Jul 2014
Posts: 10
I tried out the most recent update, which swapped C0D4/C0D5 and did the commit, but it's still coming up with the disk image for .D1 showing up in all four drives when I do this: boot BOS 1.0 into an installed program switcher, go to the System Utilities, device commands, list installed devices.

There is a second set of soft switches that controls internal/external drive selection, which are C0EA (I/O Select internal) and C0EB (I/O Select external). SOS 1.3 seems to access these at the same time as it uses the motor switches (C0D4/C0D5), but maybe the System Utilities doesn't. Right now C0EA/C0EB are basically unhandled. I made the following hacky change and it worked:

In machine/apple3.c, in apple3_c0xx_w and apple3_c0xx_r, I added EA and EB to the Dx case list, so they'd be sent to read_c0dx/write_c0dx as well, and commented them out of the Ex case list (though that's kind of irrelevant). In wozfdc.c, I added case 10 to case 4 and case 11 to case 5 so that either C0D4 or C0EA would do the same thing, and likewise C0D5/C0EB. Just doing that solved it, now all four drives are independent.

What's mystifying about that is that the committed version actually doesn't call a3_update_drive_sel on C0EA/C0EB because it's protected from doing so by a conditional that I forgot to disable. But it still fixed the problem I was seeing. Removing the conditional (so allowing a3_update_drive_sel to be called for C0EA/C0EB as well) didn't change anything, the problem was still just as fixed.

Anyway, maybe this is helpful. It does seem to have worked around the problem for me. C0EA/C0EB are conceptually not the same as C0D4/C0D5 -- C0D4/C0D5 are motor controls, and C0EA/C0EB appear to be something to do with which lines the data travels along, but that's not a distinction that is currently represented in the emulator code as far as I can tell (and collapsing them both into a "drive select" seems to work).

Also, mostly unrelated: when I run the confidence test 1.1 machine configuration subtest on the most recently committed version (with or without these changes I just described), I get a shift register error on the first 6522. I'd never tried this on earlier commits so I don't know if that's a long-standing error signal or not. Things still seem to be working, regardless.

Last edited by paulhagstrom; 09/07/14 06:42 AM.
#95866 - 09/07/14 02:08 PM Re: That Apple /// thread (was -bitb 119200 etc) [Re: datajerk]  
Joined: Mar 2001
Posts: 15,550
R. Belmont Offline
R. Belmont  Offline

Very Senior Member

Joined: Mar 2001
Posts: 15,550
USA
WIth 31968 I can catalog 4 disks fine in System Utilities.

#95881 - 09/07/14 10:49 PM Re: That Apple /// thread (was -bitb 119200 etc) [Re: datajerk]  
Joined: Jul 2014
Posts: 10
paulhagstrom Offline
Member
paulhagstrom  Offline
Member

Joined: Jul 2014
Posts: 10
Sorry, still not quite working for me, at 31976. If I put bosboot.dsk in flop1 and something else in flop2, do a System Utilities device list, I get /BOS.STARTUP listed in all four drives. However, in the file section of System Utilities, I can list files on .D2 and get the list of files from .D2. Strange.

This fixed it for me: in machine/apple3.c, in a3_update_drive_sel, the condition under which floppy0 should be chosen only needs to care about the I/O select (which I see has been added now) and not about the motor state. So, either replacing the || with && or just testing for !external_io_select on its own will fix the device list and allow all four drives to be cataloged.

#95882 - 09/08/14 12:05 AM Re: That Apple /// thread (was -bitb 119200 etc) [Re: datajerk]  
Joined: Mar 2001
Posts: 15,550
R. Belmont Offline
R. Belmont  Offline

Very Senior Member

Joined: Mar 2001
Posts: 15,550
USA
Thanks, works even better in my testing. Applied at 31978.

#95884 - 09/08/14 05:24 AM Re: That Apple /// thread (was -bitb 119200 etc) [Re: datajerk]  
Joined: Jul 2014
Posts: 10
paulhagstrom Offline
Member
paulhagstrom  Offline
Member

Joined: Jul 2014
Posts: 10
Great, looks good here now too. Thanks!

Page 6 of 6 1 2 3 4 5 6

Who's Online Now
2 registered members (Robbbert, Llaffer), 48 guests, and 3 spiders.
Key: Admin, Global Mod, Mod
Shout Box
Forum Statistics
Forums9
Topics8,318
Posts107,539
Members4,734
Most Online225
May 26th, 2014
Powered by UBB.threads™ PHP Forum Software 7.6.0
Page Time: 0.026s Queries: 15 (0.007s) Memory: 5.0220 MB (Peak: 5.2470 MB) Zlib enabled. Server Time: 2017-04-27 03:18:52 UTC