MiSTer FPGA Forum

Posted: **Fri Oct 08, 2021 9:49 am**

Newsdee wrote: ↑Fri Oct 08, 2021 5:27 am It's a bit of a stretch since it replaces the whole disk on load, but I do like the idea in that it preserves the original disk files.

I don't think that's a real concern since the "original" disks are already copies - you can make many more and they are all over the net.

Also, some programs need to be write-enabled to work at all.

Posted: **Fri Oct 08, 2021 2:10 pm**

I don't think the SRAM framework is a great fit for floppies, especially on Apple II. The key thing is that there isn't necessarily a 1:1 relationship between program disk and save disk the way that there is for cartridge and SRAM. Some programs only save user data to the program disk itself, some only save to a separate save disk, and some can save to either. I don't recall specific examples, but I think a few programs require a separate disk for each "save slot". Some programs span multiple original disks that share save disks, and I think some Ultima and Wizardry games allow transferring a character from a previous game. Trying to fit all of this variation into the SRAM framework seems likely to cause more problems than it solves.

Posted: **Sat Oct 09, 2021 10:16 am**

Good point, I could accomplish the same backup operation if I put the floppy images in the /saves/ folder, so they get synced with the base script

Proper write support would be great to have, this core is almost perfect as is except for it.

The only other features I could think of are mouse support and ability to print to an image file, but those are really marginal features and not needed by most games or programs in the library.

Posted: **Sun Oct 10, 2021 5:29 am**

ExCyber wrote: ↑Thu Oct 07, 2021 10:37 pm It's been a while since I studied this code (and I did so with the primary goal of adding a second drive, not write support), but I do think it simulates the spinning disk, albeit fudging it a bit. I believe the position increments based on a counter expiring or when the CPU reads the data register. I'm not sure why there are two conditions; maybe it's for compatibility with routines that were developed on emulators or that take the wrong amount of time on a 65C02?

That's nice, to me, I find the idea of the system simulating the spinning disk aesthetically pleasing. Though ideally, it should spin that disk, it shouldn't care what data registers the CPU looks at or anything, no hacks, no nothing -- if the 6502 doesn't read it in time, the byte is just lost. I assume that's what the real hardware does. 6502 with no interrupts is pretty deterministic, and any code that was developed on emulators that doesn't time this properly has every right to break. This is Mister, and this stuff should be correct, is kind of the spirit of this I feel. Besides, all these games out there with embedded DOS 3.3 in them, who knows what they're doing, what weird hacks are lurking out there.

Posted: **Sun Oct 10, 2021 4:03 pm**

cathrynmataga wrote: ↑Sun Oct 10, 2021 5:29 amThat's nice, to me, I find the idea of the system simulating the spinning disk aesthetically pleasing. Though ideally, it should spin that disk, it shouldn't care what data registers the CPU looks at or anything, no hacks, no nothing -- if the 6502 doesn't read it in time, the byte is just lost. I assume that's what the real hardware does. 6502 with no interrupts is pretty deterministic, and any code that was developed on emulators that doesn't time this properly has every right to break. This is Mister, and this stuff should be correct, is kind of the spirit of this I feel. Besides, all these games out there with embedded DOS 3.3 in them, who knows what they're doing, what weird hacks are lurking out there.

I basically agree, although that line of thought probably ends with implementing a flux transition buffer, simulating the MC3470, and supporting WOZ 2.0 images. I'm not opposed to that, but I also don't expect enough developer interest to actually see it happen.

Removing the register access condition breaks floppy reading, so I guess either the spin delay is wrong or something else is missing. I don't really understand how the code behavior corresponds to the Disk II state machine. There's a comment that might be related to this, but I think I'd need to study the Disk II in more detail to really understand it:

Code: Select all

  -- Lower bit indicates whether disk data is "valid" or not
  -- RAM address is track_byte_addr(14 downto 1)
  -- This makes it look to the software like new data is constantly
  -- being read into the shift register, which indicates the data is
  -- not yet ready.

Posted: **Sun Oct 10, 2021 11:04 pm**

http://www.mac.linux-m68k.org/devel/iwm.php Found this link on APple 2 disk.

It looks from this, if you run off only a timer that Q6 should go to + after a read, and then go to -(the data) after the next timer tick? I guess NIB files only have negative values? If Q6 never goes positive, the code will read in duplicate values until the next timer tick. I looked at disk_ii.vhd, and I don't see evidence of this, though I'm not sure.

Code: Select all

	LDA Q7		;insure read mode
	R1	LDA Q6		;ready yet?
		BPL R1		;if not, try again
		STA DATA1	;got a valid byte, so save it
	R2	LDA Q6		;repeat ad nauseam...
		BPL R2
		STA DATA2
	R3	LDA Q6
		BPL R3
		STA DATA3

I guess on real hardware, it depends on the state machine to collect the bits, but I think mostly that doesn't matter for us right now. The hope is if we can get rid of the dependence on (read_disk = '1' and PHASE_ZERO = '1') that maybe we'd be closer to getting the data pointer in the correct position for write also.

Posted: **Mon Oct 11, 2021 1:42 am**

Hi All,

Had a tinker with the Apple II core over the weekend.
Got the write working ok in the disk ii module.
Was able to write a sector using CIA utilities and read it back ok.

Though it might make more sense to download the whole NIB disk image to RAM, rather than a track at a time.
Tried that, but there are not enough free 10K RAM blocks available

That makes saving the image file back out a bit more complicated.

Will keep at it...

Cheers,
Red

Posted: **Mon Oct 11, 2021 5:40 pm**

Ooh, that sounds really promising. Looking forwards to seeing the diff.

Posted: **Thu Oct 14, 2021 10:45 am**

RedskullDC wrote: ↑Mon Oct 11, 2021 1:42 am Hi All,

Had a tinker with the Apple II core over the weekend.
Got the write working ok in the disk ii module.
Was able to write a sector using CIA utilities and read it back ok.

Though it might make more sense to download the whole NIB disk image to RAM, rather than a track at a time.
Tried that, but there are not enough free 10K RAM blocks available
That makes saving the image file back out a bit more complicated.

Will keep at it...

Cheers,
Red

Fantastic! Keep us informed, it's very important implement this feature!

Posted: **Thu Oct 14, 2021 12:24 pm**

RedskullDC wrote: ↑Mon Oct 11, 2021 1:42 am Hi All,

Had a tinker with the Apple II core over the weekend.
Got the write working ok in the disk ii module.
Was able to write a sector using CIA utilities and read it back ok.

Though it might make more sense to download the whole NIB disk image to RAM, rather than a track at a time.
Tried that, but there are not enough free 10K RAM blocks available
That makes saving the image file back out a bit more complicated.

Will keep at it...

Cheers,
Red

Great work!
Since you only need the ram for storing the image and not doing anything that is time sensitive, you may want to look at maybe using DDR ram for storing the image.

Posted: **Mon Oct 18, 2021 6:19 pm**

Better to keep per track loading/writing. The same is done in other cores too. Write/read a whole disk at once is time consuming operation.

Posted: **Sat Oct 23, 2021 7:34 am**

Keyboard is better with 21/10/18 build. Makes it possible to type now. Just, is it intentional that the \ and ` keys are swaped on my USA keyboard? \ prints ` and | show ~.

Posted: **Sun Oct 24, 2021 9:27 pm**

I'm not sure about the details, but I think the scan code lookup table and character ROM built into the core are for a UK keyboard. SHIFT+3 produces a pounds sign instead of a number sign, for example.

Posted: **Tue Oct 26, 2021 1:27 am**

Actually I googled this a little, and though I didn't find a real source on this, it looks like `~ \| keys are just weird across different international keyboards. Really, it's not a problem

Posted: **Thu Nov 11, 2021 12:21 am**

Hi Sorgelig et al.,

Sorgelig wrote: ↑Mon Oct 18, 2021 6:19 pm Better to keep per track loading/writing. The same is done in other cores too. Write/read a whole disk at once is time consuming operation.

With the current setup, each track is re-read from the SD card , decoded to NIB, processor halted while the track mem is updated each time the drive head is moved. This can have quite an impact.

If the full disk is loaded to memory it is time consuming, sure, but it only has to happen the once for read, and again if the user saves the image back to disk.

I'll play around and see how it goes.

Progress so far:

All main/aux/ram card memory has been moved across to SDRAM.
This will free up more block ram to allow two drives.

Will also allow a bigger RAM card to be emulated.
An Apple //e is better off with a 1MB "Slinky", or something like a "Ram Factor" card.
Saturn 128K belongs in a ][+.

https://github.com/RedskullDC/Apple-II_MiSTer

Next steps:
Get 2 drives working
Get disk writes working.
Add menu option to save disks back to the SD Card.

Cheers,
Red

Posted: **Thu Nov 11, 2021 9:42 am**

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

Posted: **Thu Nov 11, 2021 9:43 am**

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

Posted: **Thu Nov 11, 2021 11:31 am**

Hi,

breiztiger wrote: ↑Thu Nov 11, 2021 9:43 am 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

Posted: **Fri Nov 12, 2021 4:31 pm**

hi

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

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

Posted: **Fri Nov 12, 2021 5:52 pm**

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!

Posted: **Fri Nov 12, 2021 6:12 pm**

thorr wrote: ↑Fri Nov 12, 2021 5:52 pmI have an actual Apple IIc if you need me to take pictures

(cough)

Posted: **Fri Nov 12, 2021 7:12 pm**

akeley wrote: ↑Fri Nov 12, 2021 6:12 pm
thorr wrote: ↑Fri Nov 12, 2021 5:52 pmI have an actual Apple IIc if you need me to take pictures
(cough)

Two birds with one stone...

Posted: **Sat Nov 13, 2021 2:39 am**

thorr wrote: ↑Fri Nov 12, 2021 5:52 pm 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

Posted: **Sat Nov 13, 2021 3:27 am**

thorr wrote: ↑Fri Nov 12, 2021 5:52 pm2) 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.

Newsdee wrote: ↑Sat Nov 13, 2021 2:39 am
thorr wrote: ↑Fri Nov 12, 2021 5:52 pm 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.

Posted: **Sat Nov 13, 2021 12:40 pm**

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

Posted: **Sat Nov 13, 2021 3:24 pm**

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

Posted: **Sat Nov 13, 2021 5:10 pm**

cathrynmataga wrote: ↑Sat Nov 13, 2021 3:24 pm 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

Posted: **Sat Nov 13, 2021 5:18 pm**

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.

Posted: **Sun Nov 14, 2021 5:40 am**

ExCyber wrote: ↑Sat Nov 13, 2021 5:18 pm 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

Posted: **Sun Nov 14, 2021 3:53 pm**

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)

MiSTer FPGA Forum

Apple II Core

Re: Apple II Core

Re: Apple II Core

Re: Apple II Core

Re: Apple II Core

Re: Apple II Core

Re: Apple II Core

Re: Apple II Core

Re: Apple II Core

Re: Apple II Core

Re: Apple II Core

Re: Apple II Core

Re: Apple II Core

Re: Apple II Core

Re: Apple II Core

Re: Apple II Core

Re: Apple II Core

Re: Apple II Core

Re: Apple II Core

Re: Apple II Core

Re: Apple II Core

Re: Apple II Core

Re: Apple II Core

Re: Apple II Core

Re: Apple II Core

Re: Apple II Core

Re: Apple II Core

Re: Apple II Core

Re: Apple II Core

Re: Apple II Core

Re: Apple II Core