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

So that explains the keycoding, I found a MM5740 datasheet and one of the tables has:

CTRL+SHIFT+P makes NUL,
CTRL+SHIFT+M makes GS,
CTRL+SHIFT+N makes RS

I don't know why they duplicated lines in the datasheet, though for M and N where it doesn't have the different SHIFT+CTRL.



duplicate lines for P

After using the apple 3 driver for awhile I became frustrated with the lack of auto-repeat on the keyboard. Retyping lines by hitting the right arrow key repeatedly 30 times is just something the dude cannot abide.

So let's scarf some code from the apple2 driver:

src/mame/includes/apple3.h

add a timer callback for ay3600_repeat
and a write line member for ay3600_ako_w (any key out)


a couple of variables to hold the anykeydown state and repeat delay


src/mame/drivers/apple3.cpp

src/mame/machine/apple3.cpp



After I copied the code from the apple2 driver it just didn't work. Finally I realized that I had to set the data_ready_line to true! Then I got my auto repeat working.

I know it isn't exact, but hey it works 8-) The dude can now go back to abiding.



Supposedly it's supposed to go faster if the solid apple key is held and the arrow keys do 2 speed stages or something:

https://www.wap.org/a3/a3library/a3beginninglll.html

"Every key is equipped with an automatic repeat. Holding down the key causes the letter or number to be repeated until the key is released. Some of the special character keys have a two speed repeat. The longer the pressure on the key, the faster the character is repeated. This is advantageous when moving the cursor and drawing lines or dots."

https://archive.org/details/Apple_3_Data_Sheet_A3/page/n3

"All keys have automatic repeat; Four directional-arrow keys with two-speed repeat"

https://archive.org/details/DTCA3DOC-012_review_apple_3_byte_1982-09/page/n5



Apple III Review - PCW - August 1980.pdf



edit:

Apparently the arrow keys are "double action" switches:

https://deskthority.net/viewtopic.php?t=17354

I was finally able to see the Silentype's font 1 and font 2. You have to use the BIG.DRIVER from the silentype disk and get that integrated into your SOS.DRIVER file. But the latest mame's got floppy corruption problems, every time I try to write a disk it seems to clobber it. Claudette Clobber...

So I thought, why not go back in time, and try an old mame version, I tried a few but was able to get 0178 to compile. Thank you NOWERROR=1! And that version seemed to be able to write the SOS.DRIVER to the floppy.

git checkout mame0178

I discovered the Apple3 "ready to run" hd setup and was able to integrate the BIG.DRIVER silentype driver into bosboot.dsk (after deleting APPLE2.INTERP because it was so full).

and typing

OPEN #1,".SILENTYPE"
FOR I=0 TO 2: PRINT #1 CHR$(27)"F"CHR$(I) " FONT "I:FOR J=32 TO 127 : PRINT #1 CHR$(J) : NEXT : PRINT #1 : NEXT

FONT 0 is the normal font (80 chars per line, 5 pixels + 1 pixel gap)
FONT 1 is the compact font (96 chars per line, 4 pixels + 1 pixel gap)
FONT 2 is the roman font(60 chars per line, 7 pixels + 1 gap)


3x size




Yay! I've been trying so long to get that to work!

Since I read about the keyzone spectragram I've been trying to find any information and the only program that I could find that mentions it is Gazelle.

"Gazelle permits the online display of Viewdata frames in high-quality colour if you
have a IIGS and an analog RGB monitor. Viewdata frames can be displayed
offline in colour with a //e or //c double Hi-Res colour display. They may also be
viewed offline in colour on the //e by using a Keyzone Spectragram colour card
and RGB monitor."

If I run the gazelle communications program and put in a watchpoint for the c0f0-c0ff range (for slot 7) it gets hit at 4b17. (wp c0f0,f,rw)
Next thing it starts peeking at c0f2, so let's (find 0,bfff,f2,c0)

And we can find some code where it wants to write to c700 (which makes sense as the keyzone would sit in slot 7)




Knowing from an article that the keyzone has 8 bit color (2 bits blue, 3 bits for r and b) that these bit values seem to be initializing a color table.
If we take the upper 2 bits middle 3 and lower 3, this table translates to:

00 = 000
07 = 001
c0 = 100
C7 = 101
38 = 110
00 = 000
FF = 111
C7 = 101
00 = 000
00 = 000
00 = 000
FF = 111
00 = 000
3F = 011
F8 = 110
FF = 111

It looks like these would be 8 colors with each R G or B component set to 1 or 0, which would match the teletext colors, since that's what Gazelle was designed to view.






Left alt will bring up the menu.

If it finds a keyzone card it puts a nonzero value in 4aa5, if we set 4aa5=1 it will draw different bit patterns in the double hi-res space. Maybe the keyzone displays 140x192 without artifacts?

So it's most curious, just wish I could find a keyzone disk image/manual somewhere.

Here's a weird bug with regards to autorepeat and the User-initiated break:

Bring up the apple2e driver with the debugger active, hit the tilde/backtick key for a user-initiated break, keeping the focus on the apple2e window, then type a bunch of keys like asdf jkl;, then switch to the debugger window and give a go command and now your auto repeat will never stop repeating no matter what key you press except for the backtick. Offset $17 in the x_mask keeps getting stuck to $40, which you can see in the debugger memory window:

You can manually set the $40 to zero in the memory view, but it will get set right back to $40.

The only way to get it to stop repeating is to do another user initiated break which will unstick the key.

I using Ubuntu if that makes any difference?



emu.keypost("`") won't unstick the ` key.

Please release me, let me go...

Regarding the original apple2 and apple2plus "two part" keyboard, it uses a GI AY-5-3600 custom mask 931 part (which does internal keycode->ascii translation), which has not been completely dumped or decapped yet. Someone at VCF-east I spoke to had done a partial table of it by hand and was planning to use an arduino or similar to dump the full table out of it. This mask 931 part uses the mask option where pins 1, 2 and 3 are internal oscillator, pin 4 is AKO and pin 5 is B10. (B10 is incorrectly called "BIO" on parts of the datasheet, it's an extra data output bit to the computer side).

The Apple IIe and IIc use the AY-5-3600-PRO part, which was a mask sold by GI which is well-documented on datasheets (intended to use an external EPROM for keycode->ascii translation, as apple did in this case), so we know what the mask contents are for every possible key combination. The AY-5-3600-PRO has pins 1, 2 and 3 masked for internal oscillator, pin 4 is LO/RO and pin 5 is AKO

LN

GC: debugger keys also being visible to the emulation is a known, and very annoying, problem. It's not at all Linux specific. I think it's related to the emulation seeing keys you use while navigating the Tab menu.

LN: Known, we of course emulate the PRO part on the IIe and IIc and use Apple's own external layout PROM to translate the layout.

The MOS MM5740 is the chip in the original Datanetics keyboards used in Apple I and early Apple II models. The point being that the keyboard encodings were inherited from the Teletype ASR 33 (which is also tied to the origin of ASCII ) and only a few keys had any special function for Ctrl-Shift combinations.

Found my notes: The guy at vcf east who was working on dumping the keyboard controller stuff was Eric Rangell: https://github.com/erangell/
He had a replica-1 apple1 clone at vcf, and had a "The Keyboard Company" 2-part keyboard for it which used a 331-0931-B // KR3600-070 // SMC // 8151 chip on it, which I'm 99% sure (due to sharing the "931" part number) is a second source of the ay-5-3600-931 (or, given the 'B', perhaps a minor bugfix of it) used on the later II and II+ and europlus, so running it connected to an apple1 is a bit of a hack? Then again the apple1 does want ascii input, so maybe it's really not a hack...

semi-offtopic: I'm curious if it is possible to use a common ay-5-3600-pro and an eprom on a tiny daughterboard to replace the very rare ay-5-3600-931/331-0931-B on the 2-part keyboard from the later II and the II+, if we had the 931 mask rom data (or just a digital truth table)... Obviously pin 5 from the pro has to be swapped in place of pin 4 from the 931, since the AKO (any key output) pin is used by the AppleII and the mask options moved it to a different pin. Do the appleII/II+ need the B10 output pin at all?

LN

I would think it's possible, given that's effectively how our Apple II/II+ keyboard emulation work. Our AY-5-3600 emulation behaves like the PRO version, and the array Golden Child corrected acts as a translation PROM.