I've added the UART interface (with IRQ handler), and wrote a simple monitor program that I can use to dump memory, fill memory, load programs (binary and Intel hex), and jump to them. The UART interface is configurable between the CPU and the FPGA trace logic. If you now type ^C, the UART is disconnected from the CPU, UART interrupts are disabled, single stepping is enabled, and the UART shows the memory trace instead. Typing ^D switches it back to CPU control, and lets the CPU run full speed again.

Using the intel hex loader, I loaded Klaus' test suite in external SRAM, and ran it. I had to set ROM_vectors to 0, otherwise the hex loader would overwrite the IRQ vector, and that would mess up my UART interrupts, and I had to move the zeropage data a little bit to avoid collision with my own data, but apart from that, I ran it unmodified. Every few seconds I would use the trace logic to see where it was, and after a few times, it was stuck in the 'success' loop.

Cool... I moved my monitor code from F000-FFFF to E000-EFFF, so it wouldn't interfere with other software that might want to load in the Fxxx space. However, because I still want to use IRQ in my monitor, I have added a feature based on the "Vector Pull" signal. During a fetch of any of the vectors, the address is quietly rerouted to my internal monitor code. Works great... and much easier to do this on an FPGA instead of discrete logic.

I modified the Atom OS ROM to perform read/write character I/O through the UART instead of the keyboard/screen, and loaded it into the sandbox board. The software designers did a pretty good job of keeping the BASIC separated from the operating system. The only violation of the abstraction I found in the basic ROM where it directly polls the ESC key by looking at a PIA register.

Demo program from the manual, running on the board: (note how the code only works for 20th century)


Of course, without video, the number of things you can do is rather limited

Working on SPI flash interface for CPU now. I'm making a very simple CPU interface with a memory mapped data register. Writing to the data register causes a byte to be shifted out over the SPI interface, and another byte to be shifted in at the same time. Later, I'll also add a read-only register that will cause $FF to be shifted out, and another byte to be shifted in, just by reading the register.

I'm using a 24 MHz SPI clock (main clock divided by 4), and because the CPU clock is 8 MHz, it takes less than 3 CPU cycles to shift a byte in or out. So, basically, the CPU can read serial flash data just as fast as it can access SRAM. Of course, you still need to set up the starting address, but as long as you read, say, 256 bytes at a time, that's not going to cost much.

Here's a picture from the scope (top=data, bottom= clock), as a result of this code:

A write to $b110 causes the SPI byte to be written, and it's no problem to do back to back writes. I could even map the register in zero page.

Why did you choose this speed for the FLASH device? I've not looked at the Numonyx datasheet for the IC you're using, but surely it goes up to 80MHz like it's competitors.

_________________
65Org16:https://github.com/ElEctric-EyE/verilog-6502

You are right, I have a copy of an older version of the datasheet that only mentions 25 MHz operation. The newer ones go to 75 MHz. I'll modify the code to use a 48 MHz SPI clock instead.

Here's the same thing, but now running with 48 MHz SPI clock. I've added the PHI2 signal for reference. Of course, when the 65C02 is driving the SPI interface, the higher speed is pointless, but it could become useful when the FPGA is driving the flash directly.

Flash is responding to read ID command:

Top trace is clock, middle is MOSI, bottom is MISO. Flash responds with $20, $20, $14, as stated in datasheet. I don't have a CPU interface for read data yet, so this is just hand decoded from the scope screen

Like when a faster core is used, Or...
Would it be difficult to create a state machine for the SPI interface? Maybe then the WDC65C02 could take advantage of this "hardware" instead of performing the function by software?

_________________
65Org16:https://github.com/ElEctric-EyE/verilog-6502

The state machine itself would be fairly straightforward. A block read from flash memory is just a matter of writing 8 command bits, followed by 24 address bits, and 8 dummy bits, and then you can read bytes until you're done. But since there's not really a fast I/O peripheral (like video) on board, the current solution is good enough for now.

The ADV7391 may be an interesting alternative. It provides signals for composite, s-video and component video, just like the CS4954, but offers higher resolutions and non-interlaced (progressive) outputs. At the same time, it still uses an 8 bit digital interface which is attractive to minimize the FPGA pin requirements.

Disadvantage is the tricky package.

For a quick hack, I've added a simple video output to my existing board. I'm using 3 resistors attached to 3 GPIO pins, and combined the signals into a single output. This signal can be fed into the composite input (or the Y input of the component input), resulting in simple grayscale video. In theory, this could also be used for crude color, but I'll just keep it grayscale.

Of course, it's no substitute for a real video output, but it's good enough to test some designs, including an SRAM video interface. It is also good enough to support some retro graphics/text modes.

Here's a test with grayscale bars.

And the signal on the scope:

As you can see, the steps aren't spaced evenly. I just used a 330 Ohm, 680 Ohm and 1.2k resistor (all 5%), and tried different combinations of '0', '1' and 'Z' outputs to get a few usable levels between 0.3V (black) and 1.0V (white), as well as 0V for sync.

Cool!

That other IC looks like it has much more potential. Regarding the package, is that similar to QFN?

_________________
65Org16:https://github.com/ElEctric-EyE/verilog-6502

Yes, but it's got a little 'lip' around the side. The leads are accessible from the side, but are also visible on the bottom of the package. I ordered a sample, and took a picture. Behind the chip you can see a ruler with 1/16" markers.
Since the leads extend to the side, it should be possible to hand solder this thing. The only worry would be the possibility of solder bridging two leads on the bottom side of the IC.

Edit: there's also a big ground pad on the bottom of the IC, but I could make a big plated hole under the part so it can be soldered through the PCB. Reflow soldering is also an option, but that would require a stencil. No problem for a small batch of boards, but it makes a single prototype a bit expensive.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

Here's a full screen picture with different checker board patterns.
Resolution is 640x256 pixels, which results in about 2:1 aspect ratio for individual pixels. This is equivalent to the old Amiga high res, non interlaced mode. On an old TV, the bottom band with 1x1 pattern is solid gray. On my new LCD monitor/TV, the individual pixels on the bottom can still be discerned, but you can also see some banding patterns over the screen, probably because the LCD TV is all digital and uses a sampling frequency that's not identical to my pixel clock, resulting in moiré patterns.

For a monochrome bitmap, it would take 20kB for this resolution, which is getting close to what an 8 bit CPU can handle.