ZackAttack

I meant a timer in the arm mcu. The arm will be running off a much faster clock so it should have enough timer resolution to discern between pal and ntsc 6507 clock speeds. To make the measurement more accurate we could fill a command buffer with many write wsync commands and time how long it takes until the next irq is triggered. 100 wsync commands would be 7600 6507 cycles, that should make for a pretty big time difference between pal and nstc variants.

can't the 6507 be timed to see how long it takes to execute a set of commands? Since pal runs at a higher clock rate than ntsc it should execute the set in less time. Then you simply set the frame rate, scanline count and palette accordingly.

It turns out that using the addressbus changes to clock the fpga state was an awful idea. I've reworked that part of the design so the sequential logic in the fpga will be clocked by a real clock running at 50MHz or more. Each command will have its own vhdl entity which will implement a finite state machine (FSM). The DataBus outputs from all the commands will be combined with AND gates since driving the bus low is the only thing that has any effect. Here's the state diagram for the ResetVector command. This command will be what send the CPU to $1000 for its first instruction to execute. Transition labels define the condition to transition to the next state. Each state has a label followed by the output conditions. It looks pretty simple now, but it took me a long time to get there. All the other commands will follow the same basic pattern of Idle->Start->Data Sequence->Finish->Idle. Write and read commands will need to build up the expected address for states that correspond to non-ROM accesses. They will also need to interface with the buffer manager to pull in parameters.

Thinking some more about the scan line differences between pal and ntsc it occurred to me that there's no reason a game can't be compatible with both by simply auto-detecting which format and adjusting the command stream accordingly. This should work really well with games that have vertical scrolling since it would be trivial to fill the extra scan lines in pal mode.

Just to clarify. The software decides how many scan lines per frame. The size of the fpga buffers will not impact that. Thanks for pointing this out. I will need to keep that in mind when it comes time to design the framework software. Eventually I'll need to find someone with a pal setup to help me test it.

The FPGA will use two small buffers that can only hold a few commands. The exact size will depend on the fpga. Minimum size will be 32 commands though. That way each buffer can hold a full scanline worth. There's two approaches to how the full frame buffer is stored in the MCU. Either commands could be buffered or a bitmap. If commands are buffered then each IRQ can simply copy as many commands as the buffer holds in the fpga. If a bitmap is used the irq will have to convert the pixel data into commands. A good estimate for actual command size is 1 byte per CPU cycle. So a 3 cycle write will have a 3 byte command. There are 192 scan lines with 76 cycles each. A frame buffer of commands would take up about 15kb of ARM RAM. So 30kb total since it would be wise to double buffer the command frames. The best pixel kernel I'm aware of can do 48 pixels non-interlaced. Bus-stuffing might bump that up a bit though. These kernels are monochrome so only 1bpp. So a pixel buffer would be less than 3kb even with interlacing doubling the horizontal resolution. I agree that the smart/lazy devs will want to program to buffer abstractions. A good framework should do nicely for that. Keep in mind that those who want to push things to the limit would still be free to build their own framework which handles the creation of each command. I suspect a hybrid approach will be useful too. Similar to bB where the playfield is a bitmap and the sprites would be drawn via commands. Btw, the ARM MCU will be a Atmel sam4s variant. They can have 64, 128, or 160 KB or ram. Even triple buffering commands should be no problem.

bandicam has a free version

The toxic blood is a nice touch. You may want to reduce the max height that the cloud fruit can be placed by a couple pixels. Every once in a while it's a bit too high to reach unless you jump at the exact moment it's at the lowest point in the animation. I was in shield mode when the wasp flew over and stung me. That caused the moth to be released and it happen to hit and kill the wasp. Wish I was recording for that one. Did you know the wasps are suicidal? lol

For the Command State Manager I think the address bus can be compared to an expected value in order to generate a clock signal that synchronizes everything. During power on the initial state will be a hard coded collection of commands that emulate a reset vector, load $FF into the 6502 Y register and then stay in an infinite loop of branching to $1000 until the MCU signals that buffer 0 is initialized. From that point on the state will toggle between buffer 0 and buffer 1. This is a rough idea of what the execution of the 3 cycle register write command will look like. PC => DB = $84 (STY) !PC => PC++; PC => DB = Param0; ZPAddress = Param0; !PC => PC++; ZPAddress => DB = Param1 !ZPAddress => Next Command The FPGA will have it's own copy of the 6502 PC which it will keep in sync on it's own. When the PC matches the address bus (PC => the STY opcode will be activated on the data bus. Then when the PC stops matching the address (!PC =>) bus the PC is incremented. When the PC matches the address bus again the commands first parameter, Param0, is activated on the data bus. Param0 is also stored in the ZPAddress register inside the FPGA. When the PC stops matching the address bus again PC is incremented so it will be correct for the next command. At this point the ZPAddress will be compared to the address bus instead of the PC register. Once they match (ZPAddress =>) the second parameter, Param1, will be activated on the data bus. This will be a bus-stuffing operation since the STY operation being executed by the 6502 will be triggering a write of the $FF stored in the Y register to whatever ZP address that was provided. Finally once the ZPAddress stops matching the address bus the next command will be setup and the process will repeat. If the command was the last one in the buffer the buffers will be switched and the IRQ to the MCU will be activated. High Level State Machine Diagram:

I'm not really sure how I'd trigger the scope on the address bus changing from the snooped address. Maybe the only way to do it is by bringing out a signal for it to one of the FPGA I/O pins? It might be easier to program the FPGA to serve double duty as a data logger and just log the data and address bus values for a few hundred cycles after the snooped address is detected. If the data logger can be clocked at 100MHz or more I think it would produce a good picture of what the timing really looks like.

The LEDs do reflect the garbage that's on the data bus for half a CPU cycle or so. However when the address changes the value is latched. So as long as the data is still valid when the address changes the latched data will be correct. This must be happening since the LEDs reflect the latched value for all but that 1/2 CPU cycle where the latch is transparent. I should probably include facilities to update the FPGA in the final design just in case variations in the 245's cause problems down the road. I think the fact that the data bus is being pulled high with 10K resistors will help ensure that the address bus change happens faster than the data bus change. Honestly I thought those pull up resistors were going to cause timing problems. Thanks again for all the feedback. It's been very helpful to discuss these potential design issues. Thanks. Sounds like you're well on your way.

I upgraded the bios and still no luck. I think my encore is to blame though. I tried older versions and also "the deep" and all of them just hang on the loading animation. Titan Axe Beta played fine though. So I guess DPC+ just doesn't work on my setup. Sorry I won't be able to help you test the beta on real hardware.

Encore v1.05

My harmony cart gets stuck on the loading icon when I select GIZZLEWAPdpc64beta.bas.bin. Any other game works fine. Perhaps your harmony is fine after all?

If the VHDL code is doing what I think,it should already be latching the snooped data. I don't think it's a problem because the address bus changes before the data bus. When the address bus changes the data is latched. I could be completely wrong though. regarding the ink and sticker. That was a $3 TV from the thrift shop. I suppose I could remove the price tag.

Nice. Hopefully I can try it out on my six switch in the next day or two. Looking forward to it!

SUCCESS! Tonight I verified that both bus-stuffing and snooping work as intended. The next step will be to design the command interface and get the microcontroller hooked up to it. The picture is pretty noisy, but that's expected considering my complete disregard for proper RF shielding and what not. Here's a video of it in action. The vertical bars correspond to a bit being changed by the bus-stuffing circuit and the green LEDs correspond to the SWCHA value being snooped of the data bus. Enjoy! http://youtu.be/gstmU4IBK5s bees.asm VHDL: --------------------------------------- -- driver (ESD book figure 2.3) -- -- two descriptions provided ---------------------------------------- library ieee; use ieee.std_logic_1164.all; ---------------------------------------- entity Light is port( SW: in std_logic_vector(17 downto 0); LEDR: out std_logic_vector (17 downto 0); LEDG: out std_logic_vector (7 downto 0); GPIO_0: inout std_logic_vector (28 downto 0); FL_WE_N: out std_logic; FL_CE_N: out std_logic; FL_OE_N: out std_logic; FL_RST_N: out std_logic; FL_DQ: in std_logic_vector(7 downto 0); FL_ADDR: out std_logic_vector(21 downto 0) ); end Light; ---------------------------------------- architecture behv1 of Light is begin process(SW) begin --Enable reading from flash memory FL_WE_N <= '1'; FL_RST_N <= '1'; FL_OE_N <= '0'; FL_CE_N <= '0'; --Only using the lowest 4KB block of flash memory FL_ADDR(21 downto 12) <= "0000000000"; if GPIO_0(28) = '1' then --Fetch a byte from ROM and throw it on the data bus FL_ADDR(11 downto 0) <= GPIO_0(27 downto 16); GPIO_0(7 downto 0) <= FL_DQ; else --Disable data bus driver since this is outside of ROM address space GPIO_0(7 downto 0) <= "11111111"; end if; --Snoop value of SWCHA and display it on green LEDs if GPIO_0(28 downto 16) = "0001010000000" then LEDG <= GPIO_0(15 downto ; end if; --Stuff in values on switches when PF1 is written to if GPIO_0(28 downto 16) = "0000000001110" then GPIO_0(7 downto 0) <= SW(7 downto 0); end if; end process; end behv1; ------------------------------------------

I'm sure you're right about the mile long wires. lol. Fortunately, I think I'll be able to get away with it for the prototype. Those are some good points about the PCB. I'm not really sure what to do about that yet. I'm certainly not equipped to solder those BGA parts. Maybe using some prototype pcb service would be possible. Though that might price it out of reach for many.

The good news is my Atari survived the night. The bad news is that I spent most of the night troubleshooting with a faulty multi-meter and ran out of time. Eventually I got Quartus to play nice and also figured out that I forgot to wire up one of the power bus strips on the breadboard. Doh! The voltage level converters are working in both directions. I think the circuit to interface the Atari and FPGA is complete at this point. The next step will be to program the FPGA for a basic bus-stuffing test. Here's a shot of the circuit in action. The switches are wired to the red LEDs and then to the databus driver circuit. The green LEDs are wired to the input from the databus. Verilog: module light (SW, LEDR, GPIO_0, LEDG); input [17:0] SW; inout [35:0] GPIO_0; output [17:0] LEDR; output [7:0] LEDG; assign LEDR = SW; assign LEDG[7:0] = GPIO_0[15:8]; // 15:8 is DataBusIn assign GPIO_0[7:0] = SW[7:0]; // 7:0 is DataBusOut endmodule

The Harmony connects the ARM core directly to the 6507 bus. My design relies on custom hardware in the FPGA to interface with the 6507 busses. This allows the ARM to spend more time running user code and removes the need for any assembly programming. Even if someone implemented bus-stuffing on the Harmony, there wouldn't be that much ARM cycles available to calculating what to stuff in.

That's a great idea! Now more people just need to read this.

Finished wiring up the FPGA to the Atari. Just need to write a test program and some VHDLto see if the bus-stuffing circuit works. Then it's on to designing the FPGA portion. U1 is two 74LS245 for the address bus and one 74HCT541 for the data bus. (It's what I had laying around) R1 is 1K. D1 is the 3.3V Zener Diode that's built into the Altera DE2 FPGA dev board U2 is two 74LS125 R2 is 10k

Thanks for the encouragement and welcome to the forums! The best I've found so far is this. I figure 5V parts are going to keep getting harder to find so it would be good for future proofing to not have to rely on any special ICs. I also should have mentioned that the design took into consideration which ICs I have in my parts bin so I could get started right away. Funny you say that. I was thinking it might be possible to run a modified version of stella on the ARM MCU to allow the cart to play non-arm games too. But first I need to sacrifice a few Atari 2600s to bus-stuffing experiments.