MiSTer FPGA Forum

Hello
anyone tried this core ?

I saw that it was necessary
preload the basic.hex file to launch basic programs. But it seems to work without

Apple I shipped with a minimal ROM monitor (sometimes called the "Woz monitor"). It's only 256 bytes, so it has no assembly support, essentially just hex peek/poke/jump. This is what you get by default when booting the core. Here's a simple "HELLO, WORLD" example using the ROM monitor (hand-assembled, of course...):
(I spent some time being confused about why that "300" before "R" is necessary when the smoke test sample in the manual does an "R" right after a block dump, which led me to believe that it would run from the beginning of the block rather than the end. The trick seems to be that the "last examined" byte in that case is a 00, which is a BRK instruction. The IRQ/BRK vector is 0000, which is where you're told to assemble the program. I guess this is a hack to make the program shorter.)

The two biggest issues I found with it is that there seems to be some sort of off-by-one bug in the PC (try the Hello World demo code to see what I mean) and the screen refresh rate is *WAY* too fast for real life (it's been quite a while, but I remember it being on the order of like 1200 baud-ish).

The lack of a cassette interface (virtual or otherwise) is kind of a bummer, that was one of the joys (I say that somewhat laughingly) of the platform.

rhester72 wrote: ↑Wed Jul 08, 2020 11:10 pmthere seems to be some sort of off-by-one bug in the PC (try the Hello World demo code to see what I mean)

I just tried it again to make sure that the version I posted actually worked (I went through several revisions with broken versions as I worked on the post, so the risk of inadvertently posting a broken version was definitely there), and I'm not sure what you mean. The only thing that seems to fit is the output after entering the "300:" line on a freshly loaded core:
This could be interpreted as improperly pointing to the 00 byte that you just wrote to 0301, but it's actually the 00 that was at 0300 before the write occurred. if you enter "300" again immediately afterward, it will indeed print
This is a side effect of how the monitor processes commands, and definitely confused me a little bit at first (as did the input buffer being at 0200-027F; silly me thinking "obviously only 0000-01FF have a special meaning on 6502, so of course I can start my program at 0200").

Ignore the off-by-one comment...I just looked and the mass-conversion script I wrote to a MiSTer .TXT format was what was dropping one byte during conversion. Sorry about that.

Also an earlier correction, the proper video rate looks to be 600 baud (60cps).

rhester72 wrote: ↑Wed Jul 08, 2020 11:10 pm The two biggest issues I found with it is that there seems to be some sort of off-by-one bug in the PC (try the Hello World demo code to see what I mean) and the screen refresh rate is *WAY* too fast for real life (it's been quite a while, but I remember it being on the order of like 1200 baud-ish).

The lack of a cassette interface (virtual or otherwise) is kind of a bummer, that was one of the joys (I say that somewhat laughingly) of the platform.

I believe the Apple I original FPGA code has cassette support. It should be possible to hook up on mister fairly easily. PorkChop sent me a cassette adapter for my mister, but I haven't hooked it up yet. I suggest you take a look at the original repo, and some of the other MiSTer cores that support cassette. It probably is just a few wires.

Is there any way to modify the core so that it has a full 64K of RAM available to it, and/or add the ability to swap out ROM files that would enable the use of pre-compiled ROM banks that include other utilities, such as the Krusader ASM editing package?