MiSTer FPGA Forum

spark2k06 wrote: ↑Sun Aug 21, 2022 5:56 pm I have added a second COM2 port (2F8h) experimentally, it now works on the USER_IO but I think a mouse could be implemented there... I would have to try to figure out how to do it:

Caldor wrote: ↑Sun Aug 21, 2022 6:34 pm

spark2k06 wrote: ↑Sun Aug 21, 2022 5:56 pm I have added a second COM2 port (2F8h) experimentally, it now works on the USER_IO but I think a mouse could be implemented there... I would have to try to figure out how to do it:

I have thought about a solution to begin with, until IDE support has been added, could be to just have the option whether to use COM2 for a floppy drive or for a mouse?

I think the Minimig and AO486 core both have a customizable COM port, that is used for MIDI, Modem and such, but you cannot do more than one at a time. Might be simpler to do the same here, with the floppy drive and mouse? I am guessing it would otherwise cause conflicts or something if you try having 2 COM2 ports at the same time. I suspect the software, the DOS OS itself and such expects it to be one thing... but hard to say how it might turn out if its two different memory areas.

flynnsbit wrote: ↑Sun Aug 21, 2022 8:26 pm Dropped a bug here with PKUNZIP. Can someone else test and see if they are also getting CRC errors? you can just use PKUNZIP -T file.zip to test the archive. Works fine on AO486 and bombs for lots of zips on PCXT.
https://github.com/MiSTer-devel/PCXT_MiSTer/issues/6

flynnsbit wrote: ↑Sun Aug 21, 2022 8:26 pm Dropped a bug here with PKUNZIP. Can someone else test and see if they are also getting CRC errors? you can just use PKUNZIP -T file.zip to test the archive. Works fine on AO486 and bombs for lots of zips on PCXT.
https://github.com/MiSTer-devel/PCXT_MiSTer/issues/6

NML32 wrote: ↑Sun Aug 21, 2022 8:50 pm

flynnsbit wrote: ↑Sun Aug 21, 2022 8:26 pm Dropped a bug here with PKUNZIP. Can someone else test and see if they are also getting CRC errors? you can just use PKUNZIP -T file.zip to test the archive. Works fine on AO486 and bombs for lots of zips on PCXT.
https://github.com/MiSTer-devel/PCXT_MiSTer/issues/6

I'm getting the same error, I tried MS DOS 6.22 and IBM DOS 7.1.

Goingdown wrote: ↑Sun Aug 21, 2022 5:46 pm

Daniel8b wrote: ↑Sun Aug 21, 2022 11:25 am I noticed an issue with the keyboard not reacting properly to shift/capslock keys. Should I report it here or at Github?

Are you using keyb to load non-us keyboard layout? That does not work properly yet.

spark2k06 wrote: ↑Mon Aug 22, 2022 4:18 am

NML32 wrote: ↑Sun Aug 21, 2022 8:50 pm

flynnsbit wrote: ↑Sun Aug 21, 2022 8:26 pm Dropped a bug here with PKUNZIP. Can someone else test and see if they are also getting CRC errors? you can just use PKUNZIP -T file.zip to test the archive. Works fine on AO486 and bombs for lots of zips on PCXT.
https://github.com/MiSTer-devel/PCXT_MiSTer/issues/6

I'm getting the same error, I tried MS DOS 6.22 and IBM DOS 7.1.

I've already responded to the issue, I'm sure the problem is with the UART module timings but I'm not so sure we should invest a lot of time in solving it (unless we identify a simple solution)... because, in the long run, we'll discard it when we have IDE and floppy.

spark2k06 wrote: ↑Mon Aug 22, 2022 4:18 am I've already responded to the issue, I'm sure the problem is with the UART module timings but I'm not so sure we should invest a lot of time in solving it (unless we identify a simple solution)... because, in the long run, we'll discard it when we have IDE and floppy.

Looking at the MiSTeR PCXT output, I think I can spot what's causing some of those display issues...
6845 start address latching isn't implemented; on the real chip (and all clones) new start addresses don't take effect until the next CRTC cycle.
The ±VIDEO bit in the Mode Select register is also not implemented (port 3D8h bit 3); when it's clear all VRAM reads should be treated as 0s, i.e. black in text mode and the background color in graphics mode.
No overscan, although as far as I'm aware no other CGA emulator handles this properly either. Resizing and repositioning the active raster won't work as intended.
And nope, 86box certainly does not implement CGA's overscan resolution, or the H/V sync position registers for that matter...

MicroCoreLabs wrote: ↑Mon Aug 22, 2022 8:17 pm

Looking at the MiSTeR PCXT output, I think I can spot what's causing some of those display issues...
6845 start address latching isn't implemented; on the real chip (and all clones) new start addresses don't take effect until the next CRTC cycle.
The ±VIDEO bit in the Mode Select register is also not implemented (port 3D8h bit 3); when it's clear all VRAM reads should be treated as 0s, i.e. black in text mode and the background color in graphics mode.
No overscan, although as far as I'm aware no other CGA emulator handles this properly either. Resizing and repositioning the active raster won't work as intended.
And nope, 86box certainly does not implement CGA's overscan resolution, or the H/V sync position registers for that matter...

Some good insights on the VCF forum which may help with the PCXT core:

https://forum.vcfed.org/index.php?threa ... st-1272175

kitune-san wrote: ↑Sun Aug 21, 2022 3:42 pm FDC Progress Report

Floppy Disk Controller is now recognized.
Read has not been confirmed yet. I'm sleepy and will try tomorrow.

2022-08-22 003828.png

Also, the .WIDE setting for hps_io was changed to .WIDE(1).

Daniel8b wrote: ↑Mon Aug 22, 2022 8:12 am There is also a problem with Caps Lock LED not registring, but this is present regardless the KEYB issue.

However, some flicker artifacts have appeared (they are clearly visible from minute 2:25 onwards in this video), as the message left by the author of Graphics Gremlin warns, but, at least for this demo, it is worth using. As it can cause these flicker artifacts, I will add an option in the OSD menu, in the video section, to activate it or not... until we find a better solution, for the moment I attach a prerelease with this one always active.

MicroCoreLabs wrote: ↑Mon Aug 22, 2022 8:12 pm Is this UART literally a UART? Meaning TX and RX signals, and not some emulated UART which uses registers and not discrete signals?

If it uses TX/RX signals then are we also using the flow-control signals or inserting/sensing XON/XOFF? Without any type of flow-control you will get corrupted and lost data.

	
	wire iorq_uart = (io_write_n & ~prev_io_write_n) || (~io_read_n  & prev_io_read_n);
	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),
		.cs                (uart_cs & iorq_uart),

		.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)
	);

	
	// Timing of the readings may need to be reviewed.
	always_ff @(posedge clock) begin
		if (~io_read_n)
			uart_readdata <= uart_readdata_1;
		else
			uart_readdata <= uart_readdata;
	end

MicroCoreLabs wrote: ↑Tue Aug 23, 2022 6:26 am .cts_n (uart_cts_n),
.rts_n (uart_rts_n),

As long as these signals are connected between UART endpoints you should be ok with the hardware flow control, but it might be something worth checking or adding to SignalTap to make sure they are being respected and data does throttle.

	
	
	...
	
	cyclonev_hps_interface_peripheral_uart uart
(
	.ri(0),
	.dsr(uart_dsr),
	.dcd(uart_dsr),
	.dtr(uart_dtr),

	.cts(uart_cts),
	.rts(uart_rts),
	.rxd(uart_rxd),
	.txd(uart_txd)
);
	...
	
	.UART_CTS(uart_rts),
	.UART_RTS(uart_cts),
	.UART_RXD(uart_txd),
	.UART_TXD(uart_rxd),
	.UART_DTR(uart_dsr),
	.UART_DSR(uart_dtr),
	
	...
	
	

However, some flicker artifacts have appeared (they are clearly visible from minute 2:25 onwards in this video), as the message left by the author of Graphics Gremlin warns, but, at least for this demo, it is worth using. As it can cause these flicker artifacts, I will add an option in the OSD menu, in the video section, to activate it or not... until we find a better solution, for the moment I attach a prerelease with this one always active.

wark91 wrote: ↑Tue Aug 23, 2022 9:11 am With your last main and the prerelease, when a FDD is loaded on the OSD, the name of the FDD is present also at on "Load BIOS (F000) Alley cat".
Is it normal ?

wark91 wrote: ↑Tue Aug 23, 2022 9:23 am Ok I see.
It is for convenience. It could be done by symlink or replace the file.

spark2k06 wrote: ↑Tue Aug 23, 2022 8:43 am

However, some flicker artifacts have appeared (they are clearly visible from minute 2:25 onwards in this video), as the message left by the author of Graphics Gremlin warns, but, at least for this demo, it is worth using. As it can cause these flicker artifacts, I will add an option in the OSD menu, in the video section, to activate it or not... until we find a better solution, for the moment I attach a prerelease with this one always active.

After adding the option in the OSD I realised that the reason for the flicker artefacts in our case is not because of the video_enabled associated to the register, but because of the timings at 4.77MHz... because if you put it in turbo mode they don't happen anymore.

https://github.com/MiSTer-devel/PCXT_Mi ... 7913241f0c

However, associating video_enabled to registration gives good results for the demo, and I have also seen that the latch I applied on start address was correct, because without it other glitches occur, therefore, the user of that forum was right in everything. This release I've done would be fine in every way

P.D. I accidentally edited the previous message where I commented on the problem, but well.... I'm putting it back here, attaching again the RBF that would be the correct one, no need to make more changes in the Graphics Gremlin module.

kitune-san wrote: ↑Mon Aug 22, 2022 11:45 pm

kitune-san wrote: ↑Sun Aug 21, 2022 3:42 pm FDC Progress Report

Floppy Disk Controller is now recognized.
Read has not been confirmed yet. I'm sleepy and will try tomorrow.

2022-08-22 003828.png

Also, the .WIDE setting for hps_io was changed to .WIDE(1).

I am checking using the ao486 profile .
It appears to be communicating well with the mgmt_* signal.
However, there is apparently a problem with the DMA terminal count that will take some time to correct...

kitune-san wrote: ↑Tue Aug 23, 2022 1:35 pm
Passed the read!
The next step is to rebase to the main branch.