Home Page Forums MAME MAME 8bit Apples - Apple I, II, /// and the 16 bit GS

The site What Is The Apple IIgs? put together a hard disk image of all of MECC's educational software for the Apple II that boots into a menu. Yes, Oregon Trail is included

I've converted it to CHD for the CFFA2 card here: https://mega.nz/#!8iRhHbwK!lcOVKK_BTo1wVvQFfRjZmPRgyulEFQisOnmrtUnXKSI

You can run it like so:

mess64 apple2ee -sl7 cffa2 -hard1 MECC.chd

Or if you want to risk some games being a bit fast:

mess64 apple2gs -sl7 cffa2 -hard1 MECC.chd

As a bonus, load times are far, far faster on the CFFA2 than even a mechanical HDD, and it blows floppies out of the water.

I thought I'd try the MECC.chd and it's pretty cool.

A couple of problems though, on the apple2gs for some reason the auto repeat doesn't work for the arrow keys. The arrow key repeat works fine on the apple2ee. This makes the menu really hard to navigate as you can't get to the bottom of the list without pressing down arrow over and over. I did find that the open-apple or closed-apple plus arrow keys moves by a page in the menu.

And I can't seem to get the apple2gs into the text control panel with ctrl+open apple+escape. I tried everything I could think of, but it just won't go. (I was able to get into the text control panel by holding down closed apple on booting and choosing 1 for control panel)

On the apple2ee the Word Munchers game has all kinds of horizontal glitching on the screen when you're on the word grid. I don't see the horizontal glitching when run on the apple2gs driver.

I'm finding out that I'm not very good at matching the vowel sounds in word munchers. Guess I need some remedial practice.

I'm a bit of a noob with mame and the apple drivers so sorry if these are dumb questions.


Pics of the horizontal glitch on apple2ee on ubuntu 16.04 and mame185 compiled from source:

The 8-bit drivers are more modern and complete than the apple2gs driver, which dates to 2005 and has pretty much just been hacked to death since then. The 8-bit drivers support raster splits in order to (not always successfully) support the French Touch demos; the IIgs driver doesn't attempt to support 8-bit raster effects because they were basically unknown in 2005. My guess is the issue with Word Munchers is that it's inadvertently causing that support to engage when it shouldn't, I'll take a look.

I'm writing a new IIgs driver when I have time, which isn't often. It emulates the IIgs at a lower level than any existing emulator, and so progress is slower than I want it to be, but it's IMO necessary to do it that way.

This thread

http://forum.classic-computing.de/index.php?page=Thread&postID=123001#post123001

contains a link to a book with hardware descriptions and circuit diagrams of the German Apple II clone maker, IBS.

I couldn't immediately find that link, but all of the IBS hardware seems to be exact clones, not enhanced or modified so it's all good.

The glitching might be caused by the game touching the graphics soft-switches while already in graphics mode, as a II+ compatible refresh-polling.
Canyon Climber did exactly that. I have fixed the driver for that case.

I just cloned current git and compiled it and I saw some glitching when doing hgr while in 80 column mode on the apple2e driver.

Just start up, interrupt the boot with CTRL+F12, PR#3, HGR, and then hitting enter repeatedly causes the text screen to scroll and while it's scrolling, there's a bunch of glitching. Once the scroll stops, the glitching disappears.

It's likely to be same issue, but caused by another switch access which I overlooked.

Cool. Thanks for looking into the glitching issue.

On another note, I was having some trouble getting a printout from applesoft basic using the ssc and pr#1.

I can get it to output to a file, but the high bit on each byte seems to be set. A quick "tr '\200-\377' '\000-\177' " will strip the high bit from the output file but I was wondering if that's normal.

./mame64 apple2e -sl1 ssc -sl1:ssc:ssc_rs232 printer -printout outputfile.bin

and making sure that the printer and the ssc are using the same bps of 9600 in the Dip Switches and Machine Configuration menus

and then PR#1 and PRINT "HELLO" and PR#0


cat outputfile.bin | hexdump -C
00000000 8d 8a dd d0 d2 c9 ce d4 a0 a2 c8 c5 cc cc cf a2 |................|
00000010 8d 8a c8 c5 cc cc cf 8d 8a 8d 8a dd d0 d2 a3 b0 |................|
00000020

cat outputfile.bin | tr '\200-\377' '\000-\177' | hexdump -C
00000000 0d 0a 5d 50 52 49 4e 54 20 22 48 45 4c 4c 4f 22 |..]PRINT "HELLO"|
00000010 0d 0a 48 45 4c 4c 4f 0d 0a 0d 0a 5d 50 52 23 30 |..HELLO....]PR#0|
00000020

cat outputfile.bin | tr '\200-\377' '\000-\177'

]PRINT "HELLO"
HELLO

]PR#0

It's normal AFAIK for PR#1 to output Apple high-ASCII since the text screen requires the high bit to be set. Changing the SSC DIP switches to a 7-bit data format might help, assuming the serial printer device can also be changed to that format.