Apple II Core

[breiztiger]

hi very good to see improvment to apple iie core

just a question, do you think to support woz format ? or can someone tell me how to convert a woz to a nib for exemple ?

i want to test https://www.pouet.net/prod.php?which=88669

thanks in advance

[breiztiger]

perhaps a bug

https://www.pouet.net/prod.php?which=75630

this doesn't restart correctly after one run, have scramble caracters at buttom

run well in core 21.10.18

[RedskullDC]

Hi,

perhaps a bug
https://www.pouet.net/prod.php?which=75630

this doesn't restart correctly after one run, have scramble caracters at buttom

run well in core 21.10.18

Thanks for the bug report.
I've identified an issue with the ALTZP switching.

Will post a fix when sorted.

Thanks,
Red

[breiztiger]

hi

https://www.pouet.net/prod.php?which=81035

when it's start (no always) it crash after some time

[thorr]

RedskullDC, thank you so much for picking up the work on this core. There are some glaring issues that are probably easily resolved that I mentioned previously:
1) Several of the keys on the Apple keyboard are not available (open apple, closed apple, reset, perhaps others). It would be great if all keys were emulated so everything could be used properly.
2) The backspace should print a checkered square when pressed. Right now it is acting like the left arrow key.
3) I am pretty sure the colors are not correct. There are two gray's in GR mode (and DHR) and I think they look pretty close to identical, but on the MiSTer, they don't. I have an actual Apple IIc if you need me to take pictures comparing the two.

Thanks again!

[akeley]

I have an actual Apple IIc if you need me to take pictures

(cough)

[thorr]

I have an actual Apple IIc if you need me to take pictures

(cough)

Two birds with one stone...

[Newsdee]

3) I am pretty sure the colors are not correct. There are two gray's in GR mode (and DHR) and I think they look pretty close to identical, but on the MiSTer, they don't. I have an actual Apple IIc if you need me to take pictures comparing the two.

The colors in the core were taken from this newsgroup post:
https://groups.google.com/g/comp.sys.ap ... XDxQhWi1AJ

[ExCyber]

2) The backspace should print a checkered square when pressed. Right now it is acting like the left arrow key.

I'm torn on this. The Apple II keyboard layout is somewhat odd in that:

1) The left arrow key effectively is a backspace key (produces 0x08, used to correct typos)

2) The delete key (0x7F) is positioned where modern keyboards have a backspace key

I don't think it's clear that one mapping for the backspace key is fundamentally more correct than the other; it's basically a question of whether priority should be given to the modern key name/function vs. its physical position.

In any case, there probably ought to be some way to press the delete key, which relates more to your prior point about missing keys.

3) I am pretty sure the colors are not correct. There are two gray's in GR mode (and DHR) and I think they look pretty close to identical, but on the MiSTer, they don't. I have an actual Apple IIc if you need me to take pictures comparing the two.

The colors in the core were taken from this newsgroup post:
https://groups.google.com/g/comp.sys.ap ... XDxQhWi1AJ

Most of those colors seem reasonably close to what I see from the core, but the "gray" colors (#5 and #10) are very obviously different from each other, and neither looks even close to a 50% gray, at least on my monitor+eyes.

[pgimeno]

I'm a firm believer that the keyboard layouts of cores should physically correspond as much as possible to the layouts of the original keyboards. That is hard in some computers (e.g. Sharp MZ) but it's straightforward in this case. Not doing so leads to problems like having some keys unmapped, or having to use weird combinations where none were necessary in the original computer. I already had these problems with the SAM Coupé core and had to fix them myself; the Sharp MZ core, to my knowledge, still has keys that can't be pressed. Also those who have muscle memory can locate keys easily.

So in my opinion, the host Backspace key should be Del, and the host LAlt/RAlt should be the apple keys.

Edit: And scancode 61h should be mapped to the < > key next to the left shift key in some international keyboards, see https://deskthority.net/wiki/File:B_201 ... _IIC_1.JPG

[cathrynmataga]

Maybe for the UK cores, the keyboard layout is 'part of the thing,' but with Apple 2, there were all kinds of keyboard layouts, and they eventually evolved towards the PC style layout in the end. I prefer the PC layouts myself. The PC emulators I use mostly use PC layouts, and it's a quirk of mister, hunting around in oddball cores to find where the '*' key is. If there's an option to select the 'PC Keyboard' I pick it first thing. I think COCO2 core has this.

That said, left, right alt for open and closed apple, makes sense. F11 for reset?

https://apple2history.org/wp-content/up ... yboard.jpg

[alanswx]

Maybe for the UK cores, the keyboard layout is 'part of the thing,' but with Apple 2, there were all kinds of keyboard layouts, and they eventually evolved towards the PC style layout in the end. I prefer the PC layouts myself. The PC emulators I use mostly use PC layouts, and it's a quirk of mister, hunting around in oddball cores to find where the '*' key is. If there's an option to select the 'PC Keyboard' I pick it first thing. I think COCO2 core has this.

That said, left, right alt for open and closed apple, makes sense. F11 for reset?

https://apple2history.org/wp-content/up ... yboard.jpg

I like the idea of having an option to switch it to a PC layout. I will look at this. I find it really hard to use the cores in the original layout when you just want to play a few games. If you want it as a replacement for the original, then the original layout makes a bit more sense.

If someone wants to make another mapping, it shouldn't really require much vhdl / verilog knowledge.

https://github.com/MiSTer-devel/Apple-I ... d.vhd#L190

I will take a look at making it work..

Alan

[ExCyber]

Reset is currently mapped to the user button and LAlt+LCtrl+RAlt (by default; there are a few options in MiSTer.ini). I think on the original Apple II and II+ the reset key alone asserted the reset signal (which it does on the current core), while later models required the combination of Ctrl+Reset to prevent accidental resets (and Ctrl+open apple+Reset to do a full reboot or Ctrl+closed apple+Reset to run the self-test). The user button mapping is kind of a conundrum because there's a clash between MiSTer conventions and Apple IIe conventions.

The open/closed apple keys are interesting, and I wonder if they were omitted when overhauling the core because in a sense, they weren't new to the IIe. Under the hood, they're just wired to the paddle/joystick button inputs, so there are no new key codes or register bits involved with them (and yes, it's possible to use the joystick buttons to do a full reboot or run the self-test). It's probably not a big deal to add the necessary stuff to the keyboard controller, but it's a bit more than just adding new key codes.

[RedskullDC]

The open/closed apple keys are interesting, and I wonder if they were omitted when overhauling the core because in a sense, they weren't new to the IIe.

Keyboard code only emulates the ASCII keys.
The keyboard.mif file contains the ROM code from the original Apple //e keyboard: "341-0150A"

Makes sense to use left and right ALT for the open and closed Apple keys respectively.

Easy enough to detect the left ALT key (code 11) and bring it out and OR it with bit 1 of"GAMEPORT" in apple2_top.vhd

At the moment, the keyboard code only handles single byte keycodes (as far as I can see).
That complicates detecting the right ALT key , which is a multi-byte code: E0 11.
That will require some extra work on the keyboard controller.

I'll look at that once the disk write code is working.

Still working on the SDRAM code at the moment, having problems with the "auto-refresh" not running often enough, and then the memory corrupts.

Regards,
Red

[thorr]

On US keyboards, is there a way to detect left and right alt? Is right alt called "Alt Gr"? If I go to https://www.keyboardtester.com/ both Alt's highlight when I press either. I would be willing to get a different keyboard for the MiSTer if I have to as long as most of the other keys are still the same. (US International keyboard?) Any recommendations? Edit: I was able to set up my keyboard as US International in Windows 10, and now when I press right Alt, it highlights Ctrl-Alt on the keyboardtester website. I assume this means I can change my keyboard type on my MiSTer and get right-alt to work.

I definitely appreciate the help in getting this better. In my opinion, each key should act as it should (backspace should be the printed cursor). Every key should be available on the keyboard (not the user button). Left and Right Alt seems perfect, except on US keyboards. Perhaps have a second option for the right alt / closed apple key in case people have US keyboards. Function keys seem like a good option:
F1 - Reset
F2 (and left Alt) - Open Apple
F3 (and right Alt) - Closed Apple
F4 - 80/40 (this is a toggle switch on my Apple IIc, not sure about IIe)
F5 - Keyboard (this is a toggle switch on my Apple IIc, not sure about IIe)

[ExCyber]

At the moment, the keyboard code only handles single byte keycodes (as far as I can see).
That complicates detecting the right ALT key , which is a multi-byte code: E0 11.
That will require some extra work on the keyboard controller.

I haven't tried this out yet, but I think the framework handles the E0 byte and sets ps2_key[8] to indicate its presence.

On US keyboards, is there a way to detect left and right alt?

Yes, there is. The framework already knows how to do this for its own key combinations (user button emulation and MiSTer reset), but the core's keyboard controller currently can't handle those scan codes. Web pages use an ad-hoc enumeration made up by the browser vendors, not the codes produced by the keyboard itself.

[thorr]

Here is a comparison of my Apple IIc and my MiSTer taken with the same camera with the same settings. My Apple IIc has a slightly warmer picture, but it should still serve as a good comparison to show how the colors look. The two grays (5 and 10) are indeed different from each other. A number of colors on the MiSTer are wrong (at least on my CRT TV). The most obvious is yellow and brown. I included a reference chart that I found on the internet. The Apple IIc matches pretty closely in most cases, and the MiSTer does not. It could be my TV's calibration, but I don't think so.

Another major issue is when in graphics mode, the text is supposed to look like graphics with whites, purples and greens, not perfect black and white text (see the RUN's at the bottom)

EDIT: I tried the MiSTer on my other TV and the colors were much better. Ignore the MiSTer colors in this photo, but you can use the Apple IIc ones for reference.

OCx80Nw.jpeg (1.76 MiB) Viewed 18049 times

[Newsdee]

the text is supposed to look like graphics with whites, purples and greens, not perfect black and white text (see the RUN's at the bottom)

I'd say that is a feature, not a bug

Also, can you try using the Gamma options? When I compared my MiSTer to Applewin, I got pretty close to ha e the.same colors using a high (170+) gamma filter.

[Newsdee]

F4 - 80/40 (this is a toggle switch on my Apple IIc, not sure about IIe)
F5 - Keyboard (this is a toggle switch on my Apple IIc, not sure about IIe)

My (French) IIe has only one keyboard switch, that changes it from US to French version by changing the character set. Not sure what the switch does in a US or UK machine, though.

That said, these switches are better as OSD options. They don't need to be toggled often.

One thing that would be nice to have is mouse support. Not many games/programs support it but it would be neat to be able to run MouseDesk.

[thorr]

Also, can you try using the Gamma options? When I compared my MiSTer to Applewin, I got pretty close to ha e the.same colors using a high (170+) gamma filter.

Thanks. I tried and it does adjust the colors a bit, but yellow is never yellow and gray is still blue.

[akeley]

Here is a comparison of my Apple IIc and my MiSTer taken with the same camera with the same settings.

That's a pro-level comparison, well done. Alas, I think the reason might be because we're using connections closer to true RGB while Apple II uses composite?

https://nerdlypleasures.blogspot.com/20 ... -ntsc.html

The artifacting (like on the text you mention) is also gone on MiSTer on eg ZX Spectrum core, while present on my real machine - and colours might also differ somewhat.

[Newsdee]

we're using connections closer to true RGB while Apple II uses composite?

I translated the hex RGB values from the reference post by Linard Ticmanis...

There are some slight differences (darker hue for sRGB) but the difference is nowhere as dramatic as the one posted above.
I wonder if something is wrong in the core that cause the colors to be so much darker?

palettes.png (12.47 KiB) Viewed 18687 times

[Newsdee]

I should add that the logic for generating colors in the code is documented here:
http://www.cs.columbia.edu/~sedwards/pa ... puting.pdf

Interpreting colors is the bigger challenge in converting the Apple II+ output to color VGA signals. Unlike VGA, which
conveys separate red, green, and blue signals, composite (color) NTSC video consists of three signals modulated together. To a high-bandwidth luminance (brightness only) signal (about 3 MHz) called Y, NTSC adds two lower-bandwidth color signals (“I” and “Q”) that are quadrature modulated at 3.579545 MHz. A color television demodulates and combines linear ratios of these signals to recover red, green, and blue intensities.

The Apple II+ uses a trick to generate the modulated signal: it produces a digital signal that switches at 14.31818 MHz—exactly four times the colorburst frequency. Figure 4(a) depicts a small patch of this digital video output interpreted as black and white pixels. The sixteen different period-four waveforms (i.e., whose fundamentals are at the 3.58 MHz colorburst frequency) each produce a different color (two produce gray). All 0’s is black and all 1’s is white since neither has any high-frequency information; the television interprets them as purely luminance. Other patterns produce different levels of Y, I, and Q, and thus different colors. NTSC demodulation and YIQ-to-RGB colorspace conversion is a linear process, albeit a time-varying one because quadrature modulation uses phase to distinguish two signals.

So the digital video signal the Apple II+ produces can be though of as a linear combination of four square wave signals that differ only in their phase. Thus, interpreting groups of four bits as one of sixteen colors produces a reasonable display, especially for solid regions.

[thorr]

I think the reason might be because we're using connections closer to true RGB while Apple II uses composite?

Definitely not. On an Apple II, text looks perfect in text mode like the Run picture on the right. Text in graphics modes gets colored like the picture on the left. It is a neat "feature" on the MiSTer that it has perfect text when graphics are enabled, but it is not accurate to the original hardware. It would be cool to have both options. The reason for the colors in text on graphics modes is likely similar to when Hires is enabled. The bits that are used to create the pixels affect what colors are displayed, and this causes unwanted artifacts. You can say you want white pixels, but end up with different colors depending on what pixels you pick and what other pixels are around it.

[thorr]

we're using connections closer to true RGB while Apple II uses composite?

I translated the hex RGB values from the reference post by Linard Ticmanis...

There are some slight differences (darker hue for sRGB) but the difference is nowhere as dramatic as the one posted above.
I wonder if something is wrong in the core that cause the colors to be so much darker?


palettes.png

Some colors are just plain wrong while others are close on the MiSTer. It would be interesting to see if other people are seeing what I am seeing, of maybe my CRT calibration is off. I will have to try my other TV when I get a chance.

[thorr]

BIG EDIT: Ok, I tried my other TV and the colors look much closer to the ones Newsdee posted. I will definitely need to work on the calibration of my Sony TV.
With that being said, I still question the validity of the proposed colors (particularly number 7 - Light Blue, and the two grays seem correct on Newsdee's but not my reference chart so they should be ok). My Apple IIc is the real deal. There is a knob inside the monitor that affects the colors and when I started, I adjusted it to try to match the colors in the reference photo I posted. The result is what you see.

[akeley]

I think the reason might be because we're using connections closer to true RGB while Apple II uses composite?

Definitely not. On an Apple II, text looks perfect in text mode like the Run picture on the right. Text in graphics modes gets colored like the picture on the left. It is a neat "feature" on the MiSTer that it has perfect text when graphics are enabled, but it is not accurate to the original hardware. It would be cool to have both options. The reason for the colors in text on graphics modes is likely similar to when Hires is enabled. The bits that are used to create the pixels affect what colors are displayed, and this causes unwanted artifacts. You can say you want white pixels, but end up with different colors depending on what pixels you pick and what other pixels are around it.

My point was that AII's color comes entirely from composite artifacting, that machine was never meant to output stuff that MiSTer does natively (HDMI/RGB). So some things might be lost in transaltion, so to speak. I'm not sure if it'd be possible to make this coloured text happen via coding or filter feature (like Composite Blend on Genesis) or only by using a composite adapter.

Goes without saying I'd love to see the original & accurate display version implemented if possible, Apple's crazy colour tricks are a part of its unique character

[thorr]

The color artifacting should be reproducible on the MiSTer. It is well documented and reproduced on AppleWin. It is not analog composite that causes it. It's the digital bits inside the memory and their relationship to adjacent bits/pixels. Then when it gets to the monitor, composite displays it the best it can which adds its own additional layer of mucking with it.

[ExCyber]

The absence of color artifacts in the text part of mixed modes seems pretty straightforward and was probably a deliberate enhancement by the original author. I can't speak to the accuracy of the output, though (questionable eyes + using the scaler on a relatively old, budget TN monitor).

[akeley]

The absence of color artifacts in the text part of mixed modes seems pretty straightforward and was probably a deliberate enhancement by the original author. I can't speak to the accuracy of the output, though (questionable eyes + using the scaler on a relatively old, budget TN monitor).

Amazing! It works, and vs AppleWin it's either very nearly 1:1 or 1:1.