The online community for MiSTer FPGA enthusiasts
https://misterfpga.org/
kitune-san wrote: ↑Tue May 31, 2022 1:39 pmI will not modify the refresh, but increasing the parameter time may stabilize the operation.
Unfortunately, it seems to work worse.kitune-san wrote: ↑Tue May 31, 2022 2:51 pm Changed KFSDRAM.sv to always call auto refresh when not reading or writing.
https://github.com/kitune-san/KFSDRAM/b ... KFSDRAM.sv
Code: Select all
;-------------------------------------------------------------------------
; Test first 32 KiB (MIN_RAM_SIZE) of RAM
mov al,e_low_ram_test
out post_reg,al
xor si,si
xor di,di
mov ds,di
mov es,di
mov dx,word [warm_boot+biosdseg*16] ; save soft reset flag to DX
mov ax,55AAh ; first test pattern
mov cx,MIN_RAM_SIZE*512 ; RAM size to test in words
rep stosw ; store test pattern
mov cx,MIN_RAM_SIZE*512 ; RAM size to test in words
.1:
lodsw
cmp ax,55AAh ; compare to the test pattern
jne low_ram_fail
loop .1
xor si,si
xor di,di
mov ax,0AA55h ; second test pattern
mov cx,MIN_RAM_SIZE*512 ; RAM size to test in words
rep stosw ; store test pattern
mov cx,MIN_RAM_SIZE*512 ; RAM size to test in words
.2:
lodsw
cmp ax,0AA55h ; compare to the test pattern
jne low_ram_fail
loop .2
xor di,di
xor ax,ax ; zero
mov cx,MIN_RAM_SIZE*512 ; RAM size to test in words
rep stosw ; zero the memory
jmp low_ram_ok ; test passed
low_ram_fail:
mov al,e_low_ram_fail ; test failed
out post_reg,al
;-------------------------------------------------------------------------
; Low memory error: beep - pause - beep - pause ... - 400 Hz
mov al,0B6h
out pit_ctl_reg,al ; PIT - channel 2 mode 3
mov ax,pic_freq/400 ; 400 Hz signal
out pit_ch2_reg,al
mov al,ah
out pit_ch2_reg,al
in al,ppi_pb_reg
.1:
or al,3 ; turn speaker on and enable
out ppi_pb_reg,al ; PIT channel 2 to speaker
mov cx,0
.2:
nop
loop .2
and al,0FCh ; turn of speaker
out ppi_pb_reg,al
mov cx,0
.3:
nop
loop .3
jmp .1
All right, don't be in a hurry. Thank you.kitune-san wrote: ↑Tue May 31, 2022 11:36 pm I will add precharge(PALL) before the refresh command.
Sorry. I will try after work so it takes time.
OK. I will always test at 4.77Mhz at first.kitune-san wrote: ↑Tue May 31, 2022 11:45 pm > Sometimes the test failed, but only under 7.16Mhz system clock.
This seems to be another problem.
Does the CPU bus cycle really support 7.16 MHz?
Let's make it a priority to run at 4.77 MHz.
https://github.com/kitune-san/KFSDRAM/b ... KFSDRAM.svkitune-san wrote: ↑Tue May 31, 2022 11:36 pm I will add precharge(PALL) before the refresh command.
Sorry. I will try after work so it takes time.
I confirm that with this change you have made, it now works as it did at the beginning, it passes the first test but does not start the BIOS.kitune-san wrote: ↑Wed Jun 01, 2022 11:09 amhttps://github.com/kitune-san/KFSDRAM/b ... KFSDRAM.svkitune-san wrote: ↑Tue May 31, 2022 11:36 pm I will add precharge(PALL) before the refresh command.
Sorry. I will try after work so it takes time.
Continuing, I will look for any timing issues that may have occurred when the refresh was inserted.
kitune-san wrote: ↑Sat May 28, 2022 4:26 pm A bug was found in RAM.sv of KFPC-XT.
The RAM access range was 00000h-9FFFFFh, but it was 00000h-7FFFFFh.
An error may have occurred when accessing 80000h-9FFFFFh.
https://github.com/kitune-san/KFPC-XT/c ... 4cfde55893
Yes, that change is applied, but even just 32Kb from segment 0 would be enough for the BIOS to work, just fill 256 bytes with the interrupt vectors, plus a few other values, and set the stack on that same segment. As I said, the funny thing is that the initial test is done correctly but then these small "random" reads/writes necessary for the BIOS to work no longer work.kitune-san wrote: ↑Wed Jun 01, 2022 3:17 pm Have you already done the following changes?
kitune-san wrote: ↑Sat May 28, 2022 4:26 pm A bug was found in RAM.sv of KFPC-XT.
The RAM access range was 00000h-9FFFFFh, but it was 00000h-7FFFFFh.
An error may have occurred when accessing 80000h-9FFFFFh.
https://github.com/kitune-san/KFPC-XT/c ... 4cfde55893
I have found that with the default settings the refresh time exceeds 64 ms.spark2k06 wrote: ↑Wed Jun 01, 2022 4:05 pmYes, that change is applied, but even just 32Kb from segment 0 would be enough for the BIOS to work, just fill 256 bytes with the interrupt vectors, plus a few other values, and set the stack on that same segment. As I said, the funny thing is that the initial test is done correctly but then these small "random" reads/writes necessary for the BIOS to work no longer work.kitune-san wrote: ↑Wed Jun 01, 2022 3:17 pm Have you already done the following changes?
kitune-san wrote: ↑Sat May 28, 2022 4:26 pm A bug was found in RAM.sv of KFPC-XT.
The RAM access range was 00000h-9FFFFFh, but it was 00000h-7FFFFFh.
An error may have occurred when accessing 80000h-9FFFFFh.
https://github.com/kitune-san/KFPC-XT/c ... 4cfde55893
Perfect, no problem. We leave in stand-by the SDRAM integration, I for my part will try to advance in the boot even from UART, for it I will integrate this module and I will do some tests... for the moment we will continue with 256KB of BRAM memory available as conventional RAM.kitune-san wrote: ↑Thu Jun 02, 2022 11:23 am > I think I would wait to research until the MiSTer arrives at my home.
s/wait/suspend/
Code: Select all
DB9 MiSTer
1 - DSR
2 - N/C
3 - TX
4 - RTS
5 - VCC (5V)
6 - CTS
7 - RX
8 - GND
9 - DCD
Shield - DTR
@kitune-san, Can you think of any improvements in this area that would make the read/write correct... it seems to be a synchronism issue:
Code: Select all
wire [7:0] uart_readdata;
uart uart1
(
.clk (peripheral_clock),
.br_clk (clk_uart),
.reset (reset),
.address (address[2:0]),
.writedata (internal_data_bus),
.read (~io_read_n),
.write (~io_write_n),
.readdata (uart_readdata),
.cs (uart_cs),
.rx (uart_rx),
.tx (uart_tx),
.cts_n (uart_cts_n),
.dcd_n (uart_dcd_n),
.dsr_n (uart_dsr_n),
.rts_n (uart_rts_n),
.dtr_n (uart_dtr_n),
.ri_n (1),
.irq (uart_interrupt)
);
Code: Select all
logic prev_io_read_n;
logic prev_io_write_n;
logic [7:0] write_to_uart;
logic [7:0] uart_readdata_1;
logic [7:0] uart_readdata_2;
logic [7:0] uart_readdata;
always_ff @(negedge clock) begin
prev_io_read_n <= io_read_n;
prev_io_write_n <= io_write_n;
end
always_ff @(negedge clock) begin
if (~io_write_n)
write_to_uart <= internal_data_bus;
else
write_to_uart <= write_to_uart;
end
uart uart1
(
.clk (clock),
.br_clk (clk_uart),
.reset (reset),
.address (address[2:0]),
.writedata (write_to_uart),
.read (~io_read_n & prev_io_read_n),
.write (io_write_n & ~prev_io_write_n),
.readdata (uart_readdata_1),
…
);
// Timing of the readings may need to be reviewed.
always_ff @(negedge clock) begin
if (~io_read_n & prev_io_read_n) begin
uart_readdata <= uart_readdata_1;
else
uart_readdata <= uart_readdata;
end
You're a genius... now I can actually boot the OS. I can't test much now but the Army Moves game at 4.77Mhz works finekitune-san wrote: ↑Sun Jun 05, 2022 9:17 am As I have written before, the ao486 bus does not seem to be designed for long write/read signals.
I think that long write/read signals need to be converted to short signals.
Hi,spark2k06 wrote: ↑Thu May 19, 2022 5:11 am An additional fact. MCL86 can be used in maximum and minimum mode. I have not found examples of use in maximum mode, I have only seen examples in minimum mode, which is how I use it in the initial phase of this project, where, at the execution and operational level, this module works correctly.
So, unless I'm wrong, it's the first time it's been used in maximum mode.
Thanks, yes, I managed to integrate it, with the help of kitune-san, the author of the also great KFPC-XT project.MicroCoreLabs wrote: ↑Sun Jun 05, 2022 6:21 pm
Hi,
This is Ted Fried, the developer of the MCL86 core. Yes, the MCL86 has been used in both maximum mode (IBM 5150/5160) and minimum mode (IBM PCjr), but I believe I only posted a simple minimum-mode example to GitHub. I could post the maximum mode example if it would help you, however it appears that you already have it running to a large degree. I am impressed with how fast this integration is progressing. Please let me know what I can do to help!
Thanks,
-Ted
Understood, thanks for the suggestion. I'll try to take a look at what you say, many of the errors I'm sure are due to a lack of detailed knowledge of both worlds, FPGA hardware design and the PC architecture itself.MicroCoreLabs wrote: ↑Mon Jun 06, 2022 5:17 am When running the MCL86 micro sequencer core at 100Mhz and the bus interface at 4.77Mhz you should achieve cycle accuracy. I glanced at your code and it appears that you are instantiating it correctly, so one thing to check is the number of wait-states that are being generated or recognized. If your READY signal is not available at the correct clock edge then it will result in and additional 4.77Mhz clock cycle which will slow things down. This is the first place I would look - at the number of 4.77Mhz clocks for every BUI bus cycle. Perhaps the wait-state logic needs some attention.