BigDumbDinosaur wrote:
Can you please post a monochrome version so I can read it? Thanks.
Attachment:
r16.pdf [81.63 KiB]
Downloaded 78 times
drogon wrote:
Based on my own '816 board, I'd suggest putting IO in Bank 0. For no other reason that you can use LEDs on the VIA pins as a boot/debug aid which you can control in 6502 emulation mode at power on time, or '816 native mode without going to the hassle or using either data-bank fiddling or 24-bit load/store instructions.
Thanks for the tip, not only would that be more useful for testing, but I could also take advantage of the movable direct-page as size optimization if I want to unroll an IO-intensive sequence. The reason I had the IO starting in bank $80 is because I had the A23 line as an IO selector line to emulate the dual-address-space system on the Z80, but I do see how that's a little ridiculous with only 512K of SRAM at the moment (I do intend to upgrade to Garth Wilson's 4M module eventually when I feel that I am pushing the limits of 512K). With that said, I have decided to adopt your $00.FE00 IO page into my memory map.
drogon wrote:
leaving the top 256 bytes in bank 0 for 'rom' vectors, the rest (of the 512K) is RAM. (It's actually all RAM, no ROM)
What exactly does this mean? Were the vectors loaded by the software? How did you achieve bootstrapping?
cjs wrote:
Can you explain in detail the logic behind how this works? I'm looking at the schematic, but not quite geting it.
In the "address decoding" segment of the schematic, there's a JK flip-flop with the /K input tied high and the J input connected to a "ROM_OFF" label that doesn't actually go anywhere. If it were connected to a VIA, the system would be able to turn off the ROM by asserting ROM_OFF, killing the AND chain that powers the ROM selector and completely disabling ROM.
BigEd wrote:
An advantage of using a CPLD is that you will be able to iterate on your glue logic, so long as you have enough signals available: that is, so long as the CPLD has all the inputs it will need.
After posting this, I saw the forum post about the ATF150x series being pin-compatible with the EPM7xxx series CPLDs and decided to switch to that in order to avoid using a 3.3V regulator. I'll still need to use one eventually if I go the SD route, but that's more of a stretch goal at the moment. Even though I originally wrote that I would use an EPM7032 (equivalent ATF1502), I realized that 32 macrocells is probably not enough to replace all of the glue logic considering some experiments I did with a VGA timer on a CPLD a couple of months ago.
-----------------------------------------------------------------------
Now that I've decided to use a CPLD, I've started on writing some Verilog to handle some glue logic. The ultimate goal right now is to replace all 7400-series logic except for the latch and bus-transciever, as a) their job is too mundane to be worth consolidating IMO, and b) as 74ABT chips, they are probably faster than what the equivalent would be on a CPLD. Here's what I've written so far:
Code:
module eeprom_waitstate (
input rom_sel, phi2, resb,
output reg rdy
);
always @(posedge phi2, negedge resb) begin
if (!resb) rdy <= 1;
else rdy <= rom_sel || !rdy;
end
endmodule
Code:
module addr_decoder (
input [23:0] address,
input phi2, resb, vda, vpa, rom_off,
output ram_sel, rom_sel, via1_sel, via2_sel, uart_sel
);
reg [4:0] state;
reg rom_en;
always @(posedge phi2, negedge resb) begin
if (!resb) begin
state <= 5'b00000;
rom_en <= 1'b1;
end else begin
if (rom_off) rom_en <= 1'b0;
if (vda || vpa) begin
if (address < 16'h00C000) state <= 5'b00001;
else if (address < 16'h00FE00) begin
if (rom_en) state <= 5'b00010;
else state <= 5'b00001;
end
else if (address < 16'h00FE10) state <= 5'b00100;
else if (address < 16'h00FE20) state <= 5'b01000;
else if (address < 16'h00FE30) state <= 5'b10000;
else state <= 5'b00001;
end else state <= 5'b00000;
end
end
assign ram_sel = !state[0];
assign rom_sel = !state[1];
assign via1_sel = !state[2];
assign via2_sel = !state[3];
assign uart_sel = !state[4];
endmodule
I have not yet written any controller for the /OE, /WE lines, as well as the /CE line on the 74ABT245. Here's the intended memory map from the address decoder:
Code:
ADDR. RANGE | FUNCTION
----------------|----------
$000000-00BFFF | ONBOARD SRAM (512K)
$00C000-00FDFF | BOOTSTRAP ROM/ONBOARD SRAM (SWITCHABLE BY TRIGGER)
$00FE00-00FE0F | VIA1 REGISTERS
$00FE10-00FE1F | VIA2 REGISTERS
$00FE20-00FE2F | UART REGISTERS
$00FE30-00FEFF | BOOTSTRAP ROM/ONBOARD SRAM (RESERVED FOR EXPANSION)
$00FF00-00FFFF | BOOTSTRAP ROM/ONBOARD SRAM (VECTOR AREA)
$010000-FFFFFF | ONBOARD SRAM (MIRRORS AT BANK $10, $20, ETC.)
One problem I've already discovered is that all of the IO lines I intend to use don't fit on the 36 IOs of the 44-pin EPM7064 and therefore ATF1504. While Atmel does make a 64-IO 84-pin ATF1504, it's an original design and is therefore not supported by Quartus II 13.0. I thought of some possible options:
- If I get really clever, I would be able to use the 36-IO chip by chopping off the least-significant nibble of the address line and removing the ROM_OFF line, pushing the design into using exactly 36 IOs. Instead, I would replace the ROM_OFF line with VPA && VDA && A16, meaning that execution has transferred over to the program loaded in bank 1. This is the least flexible option, and is also probably the least kosher.
- Make custom Quartus II definitions so that I could use the 84-pin Atmel chip. I don't even know if this is possible.
- I don't really know much about ProChip Designer, but I submitted a license application. Is the software free? If so, this is probably the best option.
- Translate the project to CUPL. I don't really know much about CUPL, but it doesn't seem like it's nearly as friendly for sequential logic as Verilog.
-----------------------------------------------------------------------
Lastly, I just have a couple of questions about the future of the design. I understand that the memory map is very basic, but just how extensible is it? How advanced of a system could I build with this setup? What bells and whistles could I add to fill up the entire address space? In addition, would you add any IO chips other than the VIAs and the UART?
Login
Register
FAQ
Search
