|
Re: The MoDapple Thread was Re: An emulator concept... [message #331251 is a reply to message #331216] |
Thu, 03 November 2016 02:21 |
Steve Nickolas
Messages: 2036 Registered: October 2012
Karma: 0
|
Senior Member |
|
|
http://3.buric.co/modapple016.zip
I started getting a bit greedy and broke the Curses driver, so I had to
roll it way back to get it working again... I was working on the 80-column
text mode at the time.
The Alt keys work as expected with the SDL driver, but since they can't be
read directly with pdcurses, I came up with an alternative method to set
them up: press Alt-F1 to toggle Open Apple, and Alt-F2 to toggle Solid
Apple. You'll get an aural feedback and "OA" and/or "SA" will appear at
the bottom of the window. (Also, since pdcurses can't display graphics,
when hi-res mode is engaged, "HGR" will appear at the bottom of the window
to let you know that you're not seeing the correct display mode.)
I've implemented the Apple //e bankswitching to the best of my ability,
but something's not right and I can't get to the bottom of it.
-uso.
|
|
|
|
|
|
|
|
Re: The MoDapple Thread was Re: An emulator concept... [message #331387 is a reply to message #331306] |
Fri, 04 November 2016 17:16 |
Steve Nickolas
Messages: 2036 Registered: October 2012
Karma: 0
|
Senior Member |
|
|
http://3.buric.co/modapple019.zip
I fixed the reset order so that the CPU reset happens at the end. Also
silenced the "wrong ROM size" error when testing an Apple //e ROM (it
tries to open it as a ][+ ROM, then when that fails the size test, it
opens it as a //e ROM instead; it's always worked that way).
Also I tried to see if I could fix issues with 5.25" disk images by using
someone else's emulation. ...didn't help. There's two different disk ][
plugins now.
-uso.
|
|
|
Re: The MoDapple Thread was Re: An emulator concept... [message #331401 is a reply to message #331387] |
Sat, 05 November 2016 01:57 |
Steve Nickolas
Messages: 2036 Registered: October 2012
Karma: 0
|
Senior Member |
|
|
So as I was starting to write some new code, I got to thinking.
When writing this new emulator, it has been my intention to emulate things
at a lower level than I'm used to, and the results have been...mixed.
My attempt to try to get the display right, so I can implement
"monitors"...that hasn't flown very well. My implementation of monochrome
GR...garbage. Half pixel shift? I think the "F" fell off. And so forth.
It makes me half want to abandon the approach of trying to be "accurate"
and go back to just making it work. But I was hoping I would encourage
someone else to step up to the plate, and take my program where it needed
to go, as with my earlier Apple ][ emulators.
Anyway, you can kind-of see where I was trying to go with the SDL console
DLL: it would have generated the screen, in monochrome, one scanline at a
time, in 480i30 (you can occasionally see this interlacing effect in the
emulator), and then a separate DLL would take this input scanline by
scanline, add NTSC color, phosphorescence, or whatever floats your boat,
and passes it back to the console module to display. I didn't quite
achieve that, but that's what I was trying to do.
-uso.
|
|
|
Re: An emulator concept... [message #331447 is a reply to message #331005] |
Sat, 05 November 2016 10:00 |
ol.sc
Messages: 211 Registered: January 2013
Karma: 0
|
Senior Member |
|
|
Hi Steve,
> [...] and planning to implement slot devices
> as DLLs, allowing people to rewrite pieces of the emulation, or to add new
> components [...]
I don't know if it is interesting to you and/or if you already know
but this idea is actually pretty exactly 20 years old:
https://groups.google.com/forum/#!msg/comp.emulators.apple2/ GMOIzd7pvIY/4-hULnKZlGgJ
Shortly before I handed AppleWin over to Tom I had experimented with
it myself. I was especially concerned with a "pluggable user
interface" as most devices require some user configuration (think of
some mass storage device needing to know which image file to mount). I
figured out that it was possible to create a Windows tabbed dialog
from tabs provided by different DLLs. So the tabbed configuration
dialog you see in AppleWin today is a visible witness of the second
time this idea was tried ;-)
Regards,
Oliver
|
|
|
Re: The MoDapple Thread was Re: An emulator concept... [message #331529 is a reply to message #331387] |
Sun, 06 November 2016 05:43 |
Steve Nickolas
Messages: 2036 Registered: October 2012
Karma: 0
|
Senior Member |
|
|
http://3.buric.co/modapple020.zip
PLEASE NOTE THAT WHILE 80-COLUMN SUPPORT IN THE KERNEL OF MODAPPLE WORKS,
THE DRIVERS HAVE NOT ENTIRELY KEPT PACE, AND AS SUCH, EXPECT LOTS OF
VISUAL BUGS AND ISSUES WHEN 80-COLUMN MODE IS ENGAGED. This is a known
issue and is being worked on.
We now return you to your regular scheduled Usenet post.
I made a few minor changes under the hood, but the big change came when I
found the code the Apple //e ROM uses to detect the presence of an
80-column card.
There's some serious architectural issues in both of my video drivers, but
stuff seems to work mostly all right on the Apple //e side. Which
is...well, it's mixed news. It's good news in that some stuff which was
formerly broken now works. It's bad news in that some stuff that derped
gracefully now derps a lot harder.
-uso.
|
|
|
|
|
*incoherent screaming* Re: The MoDapple Thread was Re: An emulator concept... [message #331607 is a reply to message #331579] |
Mon, 07 November 2016 01:20 |
Steve Nickolas
Messages: 2036 Registered: October 2012
Karma: 0
|
Senior Member |
|
|
My SDL code for MoDapple is a bust.
My attempt to rewrite the SDL code for MoDapple is a bust.
I'm currently going through some hairy code I wrote 10 years ago and
trying to salvage something from it, and half thinking I should just track
down the last version of the original Dapple before I swapped out the CPU
core, and try to port that over.
For now, the only video driver that is working properly is the Curses one,
and that can't do graphics.
I've already gone further than I was ever able to on my own, and what
started out easy and simple is now driving me up a wall. I'm tempted to
throw in the towel on writing graphics support and simply say, if someone
else can get it to work, by all means, please do...I'm losing what's left
of my mind. :(
ON THE PLUS SIDE...
Although some stuff is still very much nonfunctional (AppleWorks 2.1 won't
boot, for example, and the built-in memory test fails)...
80-column text works in the Curses driver.
*Double lo-res* works in the Curses driver, although things become very
slow for some reason.
HOWEVER...
Implementing sound code outside of MS-DOS (where the Apple ][ "tick the
speaker manually" method actually works) breaks my brain, so this
emulator's gotten further than any of my others without ever growing sound
support.
I'm continuing to hope to find someone else who might be able to write a
superior replacement for the current modules, mod_ttysdl and mod_diskii,
which are giving me grief, so I can fight with other matters, like putting
together working emulations of other hardware, and give MoDapple its
actual point.
-uso.
|
|
|
Re: The MoDapple Thread was Re: An emulator concept... [message #331616 is a reply to message #331579] |
Mon, 07 November 2016 05:55 |
Steve Nickolas
Messages: 2036 Registered: October 2012
Karma: 0
|
Senior Member |
|
|
Here's some tests I've run on the //e support. I used the libcurses
module because it's the only one that still works right.
Infocom Z3 Interpreter (tested with Zork 1) version M:
Works, but can't detect the 80-column card on an Enhanced //e.
Infocom Z5 Interpreter (tested with homebrew WARP!) version A:
Works.
AppleWorks 2.1 (tested from hard drive device):
Splash screen displays, then crash into the monitor at DE02.
FrEdWriter 4.4 (tested from hard drive device):
Works.
ProDOS 2.0.3 Selector (tested from hard drive device):
Works; because MouseText is not supported, it displays folders as
inverted XY.
Beagle Graphics DGR:
Works, but runs slowly.
MECC Computer Inspector:
Detects only 64K with the Enhanced //e ROM, but full 128 with the
original. Functionality which is present in the emulator otherwise works.
I'm curious about why the Enhanced and EDM firmwares make a difference as
to detection of the auxiliary memory. I also wonder what's up with the
DE02 crash in AppleWorks, as that's the most useful program that would run
under such a limited environment.
I'm also wondering what manner of bug fixes would be necessary to get
MoDapple to pass the firmware tests.
Also, I'm still frustrated with the issues I'm having with the SDL code,
and think it would probably be better at this point if someone other than
me attempted to write a graphical front end DLL for this. :/
-uso.
|
|
|
Re: The MoDapple Thread was Re: An emulator concept... [message #331796 is a reply to message #331616] |
Wed, 09 November 2016 11:13 |
Steve Nickolas
Messages: 2036 Registered: October 2012
Karma: 0
|
Senior Member |
|
|
ftp://ftp.apple.asimov.net/pub/apple_II/images/games/collect ions/san_inc_prodos/word.munchers%20PRODOS%20(san%20inc%20pack)%20-%20Copy.po
Here's a program that tickles a bug in my //e support. (It's an 800K disk
so it would be used with the hard drive module, which is more reliable
under MoDapple than the floppy module.)
The regular 1.4 version, on 5.25" disk, also tickles the bug, and is
probably easier to find. I don't know exactly what copy my disk is since
I've had it for years.
Enable the SDL plugin, since it runs in hi-res mode.
Load an Apple //e ROM - any of them (apple2e.rom, apple2ee.rom or
edm.rom).
Select:
Do you want to play Word Munchers with a joystick? - No.
1. Word Munchers
Do you want instructions? - Yes.
Then space through until you get to the demo, and it will be corrupted.
It works fine in ][+ mode, which means the bug has to do with my
implementation of 128K (Word Munchers will cache itself in auxiliary RAM
if found).
-uso.
|
|
|
Re: The MoDapple Thread was Re: An emulator concept... [message #331802 is a reply to message #331796] |
Wed, 09 November 2016 14:12 |
qkumba
Messages: 1584 Registered: March 2013
Karma: 0
|
Senior Member |
|
|
> Then space through until you get to the demo, and it will be corrupted.
> It works fine in ][+ mode, which means the bug has to do with my
> implementation of 128K (Word Munchers will cache itself in auxiliary RAM
> if found).
Looks to me like a banking issue.
$AB0B calls the code that displays the "/a/ as in cake" type of text, but right before it is BIT $C08B.
If in AppleWin I patch the code to BIT $C083, then I see similar graphical corruption to what ModApple displays.
|
|
|
Re: The MoDapple Thread was Re: An emulator concept... [message #331803 is a reply to message #331802] |
Wed, 09 November 2016 14:45 |
Steve Nickolas
Messages: 2036 Registered: October 2012
Karma: 0
|
Senior Member |
|
|
On Wed, 9 Nov 2016, Peter Ferrie wrote:
>> Then space through until you get to the demo, and it will be corrupted.
>> It works fine in ][+ mode, which means the bug has to do with my
>> implementation of 128K (Word Munchers will cache itself in auxiliary RAM
>> if found).
>
> Looks to me like a banking issue.
> $AB0B calls the code that displays the "/a/ as in cake" type of text, but right before it is BIT $C08B.
> If in AppleWin I patch the code to BIT $C083, then I see similar graphical corruption to what ModApple displays.
>
So I probably misimplemented the LC. When I get back to my main computer
I'll check that out.
-uso.
|
|
|
Re: The MoDapple Thread was Re: An emulator concept... [message #331815 is a reply to message #331802] |
Wed, 09 November 2016 15:07 |
Steve Nickolas
Messages: 2036 Registered: October 2012
Karma: 0
|
Senior Member |
|
|
On Wed, 9 Nov 2016, Peter Ferrie wrote:
>> Then space through until you get to the demo, and it will be corrupted.
>> It works fine in ][+ mode, which means the bug has to do with my
>> implementation of 128K (Word Munchers will cache itself in auxiliary RAM
>> if found).
>
> Looks to me like a banking issue.
> $AB0B calls the code that displays the "/a/ as in cake" type of text, but right before it is BIT $C08B.
> If in AppleWin I patch the code to BIT $C083, then I see similar graphical corruption to what ModApple displays.
>
Hm.
The code for handling the virtual LC on the //e matches the behavior of
the code for handling the *actual* LC on the ][+, which I would describe
by this grid:
0123456789ABCDEF
Alt XXXXXXXX
Read X XX XX XX X
Write X X X X X X X X
Although MAME calculates this a different way, it seems to match my
implementation. o.o
I mapped "alt" D000.DFFF to 0000-0FFF on the LC (or equivalently,
C000-CFFF in the 128K RAM array in //e mode), and "no alt" to
1000-1FFF/D000-DFFF. The remainder is mapped 2000-3FFF/E000-FFFF, thus
using a single contiguous memory buffer for the entire LC area.
"alt" is checked after read/write, and only for D000-DFFF.
https://git.redump.net/mame/tree/src/devices/bus/a2bus/a2lan g.cpp
There is a note there saying the //e implementation doesn't require two
reads. That doesn't make a difference.
-uso.
|
|
|
Re: The MoDapple Thread was Re: An emulator concept... [message #331816 is a reply to message #331803] |
Wed, 09 November 2016 15:07 |
qkumba
Messages: 1584 Registered: March 2013
Karma: 0
|
Senior Member |
|
|
> So I probably misimplemented the LC. When I get back to my main computer
> I'll check that out.
Yes, there's a critical LC problem: bank-switching does not work.
*C083 C083 D000: 1 2 3 4 ND000L
shows 1 2 3 4 as expected, but
*C08B C08B D000L
also shows 1 2 3 4.
|
|
|
|
Re: The MoDapple Thread was Re: An emulator concept... [message #331818 is a reply to message #331816] |
Wed, 09 November 2016 15:34 |
Steve Nickolas
Messages: 2036 Registered: October 2012
Karma: 0
|
Senior Member |
|
|
On Wed, 9 Nov 2016, Peter Ferrie wrote:
>> So I probably misimplemented the LC. When I get back to my main computer
>> I'll check that out.
>
> Yes, there's a critical LC problem: bank-switching does not work.
> *C083 C083 D000: 1 2 3 4 ND000L
> shows 1 2 3 4 as expected, but
> *C08B C08B D000L
> also shows 1 2 3 4.
>
Hm. And the ][+ side works right.
....aha! It's a missing "return;" at line 557 of modapple.c. ;) DERP!
-uso.
|
|
|
Re: The MoDapple Thread was Re: An emulator concept... [message #331819 is a reply to message #331818] |
Wed, 09 November 2016 15:41 |
Steve Nickolas
Messages: 2036 Registered: October 2012
Karma: 0
|
Senior Member |
|
|
On Wed, 9 Nov 2016, Steve Nickolas wrote:
> ...aha! It's a missing "return;" at line 557 of modapple.c. ;) DERP!
>
> -uso.
Oh, and guess what?
Not only is Word Munchers no longer derping, but AppleWorks runs.
Computer Inspector still doesn't see 128K on EDM or the Enhanced //e ROM.
I'll put together a release in a bit.
-uso.
|
|
|
|
|
|
|
|
|
Re: The MoDapple Thread was Re: An emulator concept... [message #331842 is a reply to message #331833] |
Wed, 09 November 2016 21:24 |
Steve Nickolas
Messages: 2036 Registered: October 2012
Karma: 0
|
Senior Member |
|
|
On Wed, 9 Nov 2016, Peter Ferrie wrote:
>> Computer Inspector still doesn't see 128K on EDM or the Enhanced //e ROM.
>
> $C017 is returning $8x instead of $0x, which is causing a bypass of the
> RAM detection.
Hm. That's "c3override".
Currently I have no effect on mapping from c3override being enabled (write
to C00B) or disabled (write to C00A; the state currently defaulted to on
reset, as I get an MMU error if I enable it on reset). The C300-C3FF
portion of the //e ROM is simply *always* banked in.
The old Dapple code seems to return "empty slot" if the flag is enabled,
and the ROM if it's off. The default state is on.
I've now been able to get the firmware tests to pass and consistently so,
which at least is a start.
-uso.
|
|
|
Re: The MoDapple Thread was Re: An emulator concept... [message #331843 is a reply to message #331842] |
Wed, 09 November 2016 21:43 |
qkumba
Messages: 1584 Registered: March 2013
Karma: 0
|
Senior Member |
|
|
>> $C017 is returning $8x instead of $0x, which is causing a bypass of the
>> RAM detection.
>
> Hm. That's "c3override".
>
> Currently I have no effect on mapping from c3override being enabled (write
> to C00B) or disabled (write to C00A; the state currently defaulted to on
> reset, as I get an MMU error if I enable it on reset). The C300-C3FF
> portion of the //e ROM is simply *always* banked in.
Then I don't think that it means what you think it does.
The ROM can be banked in and the value can still be $0x.
I suspect that other content can be banked in instead of the regular ROM, and then the value must be set for software to know that that is the case.
> The old Dapple code seems to return "empty slot" if the flag is enabled,
> and the ROM if it's off. The default state is on.
>
> I've now been able to get the firmware tests to pass and consistently so,
> which at least is a start.
>
> -uso.
|
|
|
Re: The MoDapple Thread was Re: An emulator concept... [message #331846 is a reply to message #331843] |
Thu, 10 November 2016 00:59 |
Steve Nickolas
Messages: 2036 Registered: October 2012
Karma: 0
|
Senior Member |
|
|
On Wed, 9 Nov 2016, Peter Ferrie wrote:
>>> $C017 is returning $8x instead of $0x, which is causing a bypass of the
>>> RAM detection.
>>
>> Hm. That's "c3override".
>>
>> Currently I have no effect on mapping from c3override being enabled (write
>> to C00B) or disabled (write to C00A; the state currently defaulted to on
>> reset, as I get an MMU error if I enable it on reset). The C300-C3FF
>> portion of the //e ROM is simply *always* banked in.
>
> Then I don't think that it means what you think it does.
> The ROM can be banked in and the value can still be $0x.
> I suspect that other content can be banked in instead of the regular ROM, and then the value must be set for software to know that that is the case.
Yeah - like some other sort of card.
(To be fair, I force an Extended 80-Column Card into slot 3 in //e mode -
the only time I force a card, because I don't force the Language Card in
][+ mode.)
That said, I don't think it was ever common to put anything other than the
80-Column Card or the Extended 80-Column Card (or an enhanced clone such
as a RAM Works or the like) into Slot 3.
I think the official name of the switch is INTC3ROM/SLOTC3ROM, in which
case my understanding of how the switch works is backward, but the current
setting lets PR#3 work, so...
-uso.
|
|
|
Re: The MoDapple Thread was Re: An emulator concept... [message #331850 is a reply to message #331846] |
Thu, 10 November 2016 05:23 |
Steve Nickolas
Messages: 2036 Registered: October 2012
Karma: 0
|
Senior Member |
|
|
I'm thinking that the next thing I want to do (besides squash bugs) is add
more peripherals.
The easiest one to add would be, obviously, a parallel card. I've got
code for that and it's known working code.
Some other things I'd like to add which may be harder:
* Super Serial Card (with telnet modem emulation)
* Mockingboard
* Sprite board
* CPU cards which do not impede the 6502 (so, not Softcard-type)
* Joystick (I have the Windows-side code, need to translate to Apple
format)
Always a later goal...RAM Works emulation (the last thing I contributed to
emu][)...
-uso.
|
|
|
Re: The MoDapple Thread was Re: An emulator concept... [message #331865 is a reply to message #331820] |
Thu, 10 November 2016 09:29 |
Steve Nickolas
Messages: 2036 Registered: October 2012
Karma: 0
|
Senior Member |
|
|
http://3.buric.co/modapple023.zip
Back to baby steps, for now.
I am now using mod_carameldisk.dll as the default floppy disk driver as
it's a little more stable than mod_diskii.dll. It's a little more limited
- think it only does DO images, not NIB and such that the other driver
does - but the ability to switch disk images at runtime WORKS, which is
more than can be said of the old driver, which locks up the emulator when
that is attempted.
I've added printer support to the emulator; the driver is called
mod_lpt.dll.
-uso.
|
|
|
|
Re: The MoDapple Thread was Re: An emulator concept... [message #331867 is a reply to message #331866] |
Thu, 10 November 2016 09:47 |
Steve Nickolas
Messages: 2036 Registered: October 2012
Karma: 0
|
Senior Member |
|
|
On Thu, 10 Nov 2016, BLuRry wrote:
> I found Airheart to be the hardest button to button. Give that one a try.
>
I got a long way to go before Airheart's worth trying, because of the
issues I'm having with mod_ttysdl and the double resolution (TXT80, DGR,
DHGR) modes (I haven't even TRIED to implement DHGR, although TXT80 and
DGR are working great in ttycurses), and the fact that I don't know enough
about the joystick interface on the low level. :/ (I can normalize the
Windows joystick to -127..127. That doesn't really help though - since
feeding that data into the paddle ports isn't going to give the right
output to PDL(0) and PDL(1).
Only part of the joystick code is in the released source and it's dummied
out.
-uso.
|
|
|
|
|
Re: The MoDapple Thread was Re: An emulator concept... [message #331874 is a reply to message #331873] |
Thu, 10 November 2016 11:52 |
Steve Nickolas
Messages: 2036 Registered: October 2012
Karma: 0
|
Senior Member |
|
|
On Thu, 10 Nov 2016, Bill Garber wrote:
> "Bill Garber" wrote in message news:o0283s$he0$1@dont-email.me...
> "Peter Ferrie" wrote in message
> news:d05a4979-2ffa-4950-80d1-6f47c1c49058@googlegroups.com...
>
>>>> http://3.buric.co/modapple022-refresh.zip
>>>>
>>>> Does this help?
>>>
>>> Yes, that's working now. Thanks.
>>
>> Works for me now, too, except 80 column wraps at 40, and displays the rest
>> of the 80 columns on the next line.
>
> Update: 40 column is displaying in 80 column sized text, then PR#3 brings
> out the 80 column support.
Huh. Well, that's what the Curses library's supposed to do, but the SDL
one shouldn't be doing that...(and for me, doesn't)
-uso.
|
|
|
Re: The MoDapple Thread was Re: An emulator concept... [message #331893 is a reply to message #331874] |
Thu, 10 November 2016 13:00 |
Bill Garber
Messages: 507 Registered: December 2011
Karma: 0
|
Senior Member |
|
|
"Steve Nickolas" wrote in message
news:alpine.BSF.2.02.1611101150440.2564@frieza.hoshinet.org...
On Thu, 10 Nov 2016, Bill Garber wrote:
> "Bill Garber" wrote in message news:o0283s$he0$1@dont-email.me... "Peter
> Ferrie" wrote in message
> news:d05a4979-2ffa-4950-80d1-6f47c1c49058@googlegroups.com...
>
>>>> > http://3.buric.co/modapple022-refresh.zip
>>>> >
>>>> > Does this help?
>>>>
>>> Yes, that's working now. Thanks.
>>>
>>> Works for me now, too, except 80 column wraps at 40, and displays the
>>> rest of the 80 columns on the next line.
>>
>> Update: 40 column is displaying in 80 column sized text, then PR#3
>> brings out the 80 column support.
>
> Huh. Well, that's what the Curses library's supposed to do, but the SDL
> one shouldn't be doing that...(and for me, doesn't)
Did I not just say that Curses is working now. Stay with
the program. After all, it 'is' your program. LOL 8>)
Bill Garber * http://www.sepa-electronics.com *
|
|
|