MiSTer PCXT

[Caldor]

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.

[spark2k06]

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.

You don't have to do any of that. COM1 is already used for serdrive, both HDD and FDD, that's not the problem. As far as I can see, COM2 can be used for mouse, what I have to figure out or get from another core, is to get the PS/2 signals to this serial port somehow, or so I think.

[pgimeno]

My understanding is that if you want to use the serial port for a mouse, the serial port needs to be emulated rather than physical, and that emulation should probably be enabled through the menu. I might be wrong, though.

[flynnsbit]

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

[AmintaMister]

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

Me too I've tried TDL small: same bug.

[NML32]

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.

[Caldor]

I have had several read and write errors where programs just suddenly could not read or write to a drive. Often it might then work a moment later after doing an abort on the first operation.

[spark2k06]

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]

I bring back the loader feature of custom BIOS or XTIDE, for the moment in prerelease, as it requires modification in Main to ignore the PC model during reset. PR already requested:

https://github.com/MiSTer-devel/Main_MiSTer/pull/684

PRERELEASE.jpg (136.21 KiB) Viewed 10038 times

Ideal for testing new ROMs before they are assigned to a machine model, for diagnostics ROMs or simply for development. In any case, the model-specific ROM will always be loaded at the first boot.

I attach in this post the RBF and Main so that you can try it out.

[Daniel8b]

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.

Yes, exactly. As far as Im aware of shift key fails when using KEYB to load a different layout.

There is also a problem with Caps Lock LED not registring, but this is present regardless the KEYB issue.

[Caldor]

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.

Yeah... I think the simple solution for now, is either to mainly do file management on a computer or another possible workaround is to make a RAM disk for certain things, like if you use 4DOS you could store the cache on a RAM disk. With games I guess its a bit complicated to ensure that they save to a RAM disk and then move the file back to the real storage later. I guess that might actually work since most PCXT games are less than 2MB in size, so they probably could just be moved to a RAM disk. Which is currently 2MB in size? Maybe a RAM disk is not an option, so far it has only given me errors when I try to make one.

A tool I can recommend is Volkov Commander. Its a Norton Commander clone, except its written fully in assembly and has a very small memory footprint. Even then though I did have some trouble saving the settings, anything that might save to the disk seems to have a pretty high risk of errors.

Its small size is useful, and I have made it part of a bootdisk I made for the AO486 core
Link:
https://vvv.kiev.ua/download/

I am working on a FreeDOS compilation for the PCXT core. There is a fork from FreeDOS called SvarDOS which has a goal of staying 8086 compatible.
http://svardos.org

[dmckean]

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.

It still might be worthwhile to track it down in case there was ever a reason someone might want to use the UART module either in this core or ao486.

[MicroCoreLabs]

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.

[MicroCoreLabs]

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

[suww37]

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

I think this would be the reason why pcxt core can't output 15khz normally on the crt screen.

[kitune-san]

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]

There is also a problem with Caps Lock LED not registring, but this is present regardless the KEYB issue.

This core does not send commands to the keyboard except at reset.
Therefore, the keyboard LEDs are not controlled.

[spark2k06]

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.

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

[spark2k06]

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.

UART is literally UART, with their signals:

Code: Select all

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

kitune-san adding a latch on uart_readdata, but has already left a warning that the timings need to be revised... this could be the reason:

Code: Select all

	
	// 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

About inserting/sensing XON/XOFF, I have no idea how to do it.

[MicroCoreLabs]

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

[spark2k06]

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

These signals come from the top module of the project:

Code: Select all

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

[spark2k06]

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.

[wark91]

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 ?

[spark2k06]

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 ?

Yes, I have noticed that detail, but I am still waiting for sorgelig's approval of the pull request, and he doesn't seem to be very convinced about it.

I say this because this bug would also have to be corrected in Main, and I don't know yet if we will continue along this line to cover this need.

https://github.com/MiSTer-devel/Main_MiSTer/pull/684

[wark91]

Ok I see.
It is for convenience. It could be done by symlink or replace the file.

[spark2k06]

Ok I see.
It is for convenience. It could be done by symlink or replace the file.

Now that I think about it, I think I will be able to solve it from the core itself, but in any case let's wait to see how the pull request is solved, which will also be necessary for it to work correctly.

[suww37]

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.

Unfortunately, this issue was not the solution to my problem. Crt 15khz is not output normally.

[kitune-san]

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

Passed the read!
The next step is to rebase to the main branch.

2022-08-23 223300.png (203.78 KiB) Viewed 9248 times

[kathleen]

Passed the read!
The next step is to rebase to the main branch.

Great news.
Arigato kitune-san !

[kitune-san]

I noticed during the process of working on it that it needs some more improvement for stable operation.
Freeze occurs during disk read.

The image is when trying to read FreeDOS x86BOOT.img.

2022-08-23 232256.png (112.77 KiB) Viewed 9193 times

I will create a temporary branch.
Please help!