How odd - the current datasheet does indeed say that on p54. I checked the first doc I found - this document (Programmer's manual, WDC, 2007) or something very like it, before I wrote what I did.

Thanks for the correction. The moral is: don't believe everything you read even in a recent WDC document. Plan for the worst!

Cheers
Ed

Hi lordbubsy,

I think you have a serious memory bandwidth problem. 320 Pixels aka 320 bytes per line and 400 display lines means that you consume more than 50% of the memory bandwidth for your VGA signal. As you are stealing the cycles from the CPU during VGA display you more or less block the CPU for 50% of the time. Worse during the display of a line, that is during 320*67.8ns which is more than 21usec, you completely stop the CPU from doing virtually anything. So your computer performance will be that of a 6502 running at 3.8MHz. I'm convinced nyef is right. You need to create a 16-bit data path from RAM to the FPGA. I hope you have some pins (you need at least 9) left on the FPGA then you could piggy-pack a second AS6C4008 onto the existing SRAM and connect the the data bus and the /CE of the SRAM to the additional Pins of the FPGA. Use A0 from the CPU to select between the existing and the piggy-packed SRAM and then you can nicely use the old and proven interleave access to RAM (during PHI1 VGA reads and during PHI2 memory belongs to the CPU).

In fact that is what I did about twenty years ago, when a 4MHz G65SC816 was the fastest I could get hold on but Video Bandwidth required a throughput of about 7Mbyte with just some GALs and it works perfect.

Cheers

Peter

Actually, your mistake is completely understandable, as the Eyes and Lichty manual doesn't correctly clarify this with the '816. They discuss the 6502 and 65C02 but neglect to mention that the '816 will respond to RDY on a write cycle.

Also, according to E-mail that I have exchanged with Bill Mensch on the '816's response to ABORTB, this statement on page 446 in the Eyes and Lichty manual is incorrect:

The ABORT’ input pin, when it is asserted, causes the current instruction to be aborted. Unlike an interrupt, none of the registers are updated and the instruction quits execution from the cycle where the ABORT’ signal was received.

As stated, the computational results of the instruction are not saved, but the instruction executes to completion—it does not terminate.

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

The use of 55ns RAM is also a limiting factor, as it effectively prohibits clcking the '816 much faster than about 10 Mhz without resorting to wait-stating memory accesses.

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

What does seem odd is that changing the timing of RDY got things to work a bit better, even though we now think writes are not non-stalling.

If the CPU can stall on a write, that adds a requirement that the DMA is able to do a read from the RAM even when the CPU is holding RnW low. Clearly the RnW for the RAM needs to be muxed between two sources: the VGA system and the CPU.

Ed

The 65C816 will definitively stall on writes when RDY is pulled low. And it does not matter if he is in a series of writes (pushing a return address), he will just continue with the task he was doing when RDY is released again. That MARC-2 is crashing when accessing IO (UART) is for me like an indication, that the same location is accessed twice. That is the CPU is halted but read and/or write and/or chip-select enable signals are created twice for the same memory address the CPU is trying to access. For a memory this does not impose any problem. On IO devices this is not ok. Pulling RDY low is not enough, you must make sure that during this time you do not select a device. Just an idea what could be the problem. I have not gone through the ABEL files in detail so far (by the way are those attached in the first post the current ones?)

Peter

My best guess is still the pipelining - RDY affects the following cycle.

I know, the original plan was for composite video which only needs one byte per PHI2 clock cycle. I'm certainly not willing to sacrifice the '816 CPU time for VGA.

Let's see if I understand what you're suggesting:

CPU to SRAM, even addresses are used in one SRAM and odd addresses in the other SRAM?
CPLD to SRAM, read 16 bit at once while both SRAM's are selected. How could I select both addresses at the same time while reading with the CPLD?

I've got 16 unused, and it's actually a CPLD XC95288XL.

That's indeed the plan, regardless of choosing to need one or two bytes per PHI2 clock cycle. I'm also considering 16 colors or using composite video. But for now I'd like to understand the 16 bit data path option.

The irony is that I need to write each line twice to get 200 lines per screen. :-/

I think you're referring to 18.18MHz / 2? During reset the ATMega1284P writes to the SRAM with 14.7456MHz, and reading from it for the VGA happens also at that speed.



To pursue the problem I have with stopping the CPU:

I made a simple loop which toggles a VIA pin to visually check if the computer keeps on running.

Dividing the problem into a few smaller ones, I'll first try to halt the system and release it after a given time, and see if the program keeps on running.

with the analyzer I'll monitor A0, D0, PHI2, a VIA pin, RDY and R/W.

I made a 10 bit counter to test with PHI2.



This will halt the clock and release it alternatively. I've tested this with the VIA toggle program, which seems to have no problem with it.








Now that it's clear that I don't have to wait three cycles before I can use the bus, I'm trying to halt the system using RDY. RDY is synced with the rising edge of PHI2. However, that works for about two seconds.



What could I try next?

_________________
Marco

I wonder if RDY is changing too quickly on the phi2 clock edge. It's sampled by the CPU on phi2 so it should be stable shortly before and remain stable for a little while.

Are you able to clock out RDY on the opposite edge?

When fetching for the CPU, CPU A0 indicates which SRAM output-enable to trigger, along with which set of 8 data lines to use. When fetching for the VGA, both SRAM output-enables get triggered, and all 16 data lines get used. You feed the same address (A1 and up) to both SRAMs. Similar logic for writing to RAM as well.

Specifically, the '816 timing diagram indicates that RDY is sampled on the fall of the clock. The '816 halts with all buses held in their current state (ditto for RWB) and stays that way until RDY is released. This smacks of a basic timing problem.

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

As far as I read your ABEL equations the CPU databus and the RAM databus are separate, that is the data-pins of the CPU or not connected to the data-pins of the RAM. What you need to do is change mapping of CPU addresses (CA0...CA15) to your RAM addresses. Today you map CA0...CA15 to RA0..RA15, now you need to map CA1...C15 to RA0...RA14 of both RAMs. And the latched CA16..CA19 to RA15..RA18 of both RAMs. So both RAMs share addresses A1...A19 of the CPU (and VGA controller) and the A0 (even/odd) selects which RAM is holding the correct byte. CA0 will now be a select signal for a 2:1 8-bit wide MUX with the inputs being the now 16-bit wide data of your RAM, this is just for reads. So when the CPLD reads from the RAM (regardless whether it is reading video data or passes data to the CPU) it always reads 16-bits but only one depending on CA0 is sent to the CPU. On writes you just send the same data of the CPU to both RAMs but only assert /WE resp. /CE of one of them (again using A0 to decide, make sure you take the same as when reading ). As you now read 16-bits at a clock rate of 7.6MHz you have enough video data for a complete PHI2 cycle. Of course you need to latch all 16-bits internally and use another 8-bit wide 2:1 MUX to output the lower or upper byte to the RAMDAC, here you can use PHI2 as the select signal. So the difference to your current setup is that the data-path between RAM and CPLD is 16-bit.

Peter

OK, I just tried a test program which doesn’t use I/O. The program toggles A12 0.7s high and 0.7s low.

You can see that RDY toggles at ca. 2.2s high and 2.2s low. At the third time, A12 goes mad.

OK, but I'm still don't know what I could do about it.



This is the ABEL code responsible for RDY:


I've tried with PHI2 on the rising edge, falling edge and even on a quarter period.

This is the little test program:





Still not clear how to get 16 bit at once, I guess I'm not Vulcan enough

Thanks for your thorough explanation! I think I got it now for 98%. This could work, but first I have to get working: reading a byte while PHI2 is low.

I'll keep on trying different timings. Perhaps getting BE involved?

_________________
Marco

Hmm, can you show just a half-dozen clock cycles centered around the leading edge of that third RDY pulse?

Sure:
This is a little bit zoomed in at the rise of the third pulse.


This is what you asked.


This is the rise of the second pulse.

_________________
Marco