Hello everyone. I am back. Being a glutton for punishment, I am building a new board based on XC3S700AN.

This time I am integrating 1MB of fast static RAM that can be configured as 32 bits x 256K words or 16 bits x 512K words. With a little muxing it should be possible to use the RAM in 8 bit mode, or two 16-bit cores can be assigned to the two SRAMS.

The board also has a keyboard/mouse PS2 port (can be used with a splitter), a 6-bit VGA port, a micro-sd card socket, and a headphone connector for 2-channel 1-bit delta-sigma output. There is also a pushbutton and an LED. For IO I have a serial port, an 8-bit PMOD connector, 5 lines wired to pads and 58-IO lines wired to a high-density connector. Power comes from a mini-USB connector.

It should be possible to implement many retro-machines with just the basic board, and there is a lot of room for expansion via the mezzanine connector. I am looking forward to trying the 16 and 32-bit variants of Arlet's core.

I just started testing the first board. The FPGA is recognized by Impact, which is a pretty good start...

_________________
In theory, there is no difference between theory and practice. In practice, there is. ...Jan van de Snepscheut

Great to have you back. Looking forward to following your newest project.

_________________
Michael A.

Yes, great to see you back, enso! That unit looks like it might be a nice flexible soft-core host for the 65Org32, or maybe even my 65m32, if I ever manage to punch my way through the final few rounds of spec. revisions, and get my simulator to compile. Oh yeah, and I need to finish my native ML monitor and my port of Dr. Brad's CamelForth too! I know there's more, but my mind is overwhelmed at the moment with a heavy dose of real-life.

Mike B.

Rockin'! The option for 32-bit wide memory sounds alright to me!

_________________
In 1988 my 65C02 got six new registers and 44 new full-speed instructions!
https://laughtonelectronics.com/Arcana/ ... mmary.html

And I am blinking an LED... Could it be that the first board has no dumb errors? Well, the headphone jack footprint I made is backwards, but other than that...

_________________
In theory, there is no difference between theory and practice. In practice, there is. ...Jan van de Snepscheut

Blinken lights are always good!

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

Now that "it works", I am trying to write the blinky configuration to the internal flash. Oh boy, it is a lot harder than I imagined... Finally got to the point where Impact writes something, with errors...

I remember now something in ug322 about setting the done pin for 3AN devices... Too tired now, will continue tomorrow.

It was a pretty good day. Thanks for your encouragement.

_________________
In theory, there is no difference between theory and practice. In practice, there is. ...Jan van de Snepscheut

Finally saving the bitstream in the internal flash. Now it's time to test the rest of the system.

_________________
In theory, there is no difference between theory and practice. In practice, there is. ...Jan van de Snepscheut

I've been banging my head against the wall for almost a week now. I implemented a CHOCHI-like bitstream, but for some reason can't get anything longer then helloworld to execute. ehbasic and forth both lock up tight. At first I thought it was a memory-related bug, but after implementing a checksum and a couple of rudimentary memory tests, it appears that the code is actually there, and intact... Moving helloworld around in RAM also seems to work fine. Go figure.

I guess I will try harder. I'll start with forth and put serial output in to see how far it gets... I really thought it would take a couple of hours to get CHOCHI code to run on RetroStation. Blargh.

_________________
In theory, there is no difference between theory and practice. In practice, there is. ...Jan van de Snepscheut

Hmm - you have some spare pins to help you see what's going on inside?

Hi Enso,

A bit of a random guess, but in my experience sometimes strange problems like this can be caused by the Xilinx trying to switch too many outputs and the same time. This, can be made worse if the decoupling is not adequate.

One thing to try in your UCF file is to all the edges down, by adding | SLEW=SLOW | DRIVE = 2 to all your outputs.

Dave

I suspected decoupling at first, and stuck some extra capacitors on. SLEW and DRIVE did not help.

It's one of those weird things. I filled the RAM with bcs *+2 followed by the working "hello world" code (after an stc), and it runs through the entire RAM without locking up... I tried tracing into figforth, but it gets convoluted. I am trying to come up with a simple test case that fails.

_________________
In theory, there is no difference between theory and practice. In practice, there is. ...Jan van de Snepscheut

Do you suspect that big mother lode of a BGA? Maybe a possible single pin not connecting?

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

At this point I am suspicious of everything, mostly myself. It _seems_ to work fine out of the BRAM mapped from $FC00 to 03FF. I've concocted a monitor in the upper RAM and haven't had a glitch with it yet. It seems to have something to do with SRAMs, although I cannot currently imagine what.

_________________
In theory, there is no difference between theory and practice. In practice, there is. ...Jan van de Snepscheut

Have you tried hammering the RAMs with worst case data and address patterns? Reading or writing all zeros and all ones alternately, accessing the lowest and the highest address alternately? It should provoke decoupling bugs.