MiSTer PCXT

[Sorgelig]

Once we have more or less updated the framework with all the features that interest us, I will make pull request to sorgelig to include it in the official version of MiSTer

I don't know how your claim consist on our conversation in github. MiSTer already provides all bits in framework to implement IDE/FDC. You may find many cores implementing both hard and floppy drives. So there won't be such thing as "serdrive". Serial port has its own use and there is no plans to add such weird option as HDD over UART. Serial port can be used in core as either modem/midi/communication channel.

[Sorgelig]

There is one more still perverted but way not requiring framework modification. Serial port data in/out can be sent/received over EXT_BUS. It will require custom support in Main. Some cores like Minimig and ao486 use EXT_BUS. In this mode you don't need serial module implementation, just send and receive serial register communication over EXT_BUS.
But honestly, i don't thing PC XT core really need such customization. I think core should re-use existing IDE implementation. As for FDC, it should be a standard WD177x controller which is implemented in Atari ST, or uPD765 implemented in ZX/Amstrad cores.

[Sorgelig]

After reviewing the changes i found misunderstanding what "framework" is. Usually by framework i mean the "sys" folder in core. This was my main concern about changes. While in this thread the Main is called as framework.
Well, such changes *can* be accepted, but i still suggest to re-think toward standard IDE/FDC implementation/reuse.
Code added to Main i think is bigger than customization for ao486+Minimig+AtariST all together. I don't think it's a good idea to add such huge code for a small very old system like PC XT. It also will have problem to maintain. And at some point it may still need IDE and normal FDD anyway.
Btw, Main is not multithread safe. I see a separate thread for serial disk i/o which may have racing condition if some Main functions are used inside the thread.

[Newsdee]

try it with assign CLK_VIDEO = clk_56_875; instead of clk_28_636

Thanks, I already did that in my latest build

Looks like the problem is MDA needs a different frequency altogether (18.432) than CGA. It also sems ao486 has some special way to handle multiple resolutions which may be needed here.

[Newsdee]

We really need to get away from serdrive and have standard FDD/HDD support... so it will fix disk access speed and free up COM for other uses (mouse?)

[dmckean]

We really need to get away from serdrive and have standard FDD/HDD support... so it will fix disk access speed and free up COM for other uses (mouse?)

It's the most important thing at this point but we need to recruit someone to do it because it seems to be beyond the abilities of everyone currently working on the core.

[spark2k06]

After reviewing the changes i found misunderstanding what "framework" is. Usually by framework i mean the "sys" folder in core. This was my main concern about changes. While in this thread the Main is called as framework.
Well, such changes *can* be accepted, but i still suggest to re-think toward standard IDE/FDC implementation/reuse.
Code added to Main i think is bigger than customization for ao486+Minimig+AtariST all together. I don't think it's a good idea to add such huge code for a small very old system like PC XT. It also will have problem to maintain. And at some point it may still need IDE and normal FDD anyway.
Btw, Main is not multithread safe. I see a separate thread for serial disk i/o which may have racing condition if some Main functions are used inside the thread.

Yes, sorry for the confusion, by framework I did indeed mean Main, I will name it well from now on. My final intention is not to use serdrive, neither as an application nor as a subprocess of Main, my intention was to provide a more comfortable way for the user to mount images, until FDD/IDE is implemented, which is out of my scope.

Thanks for all the comments, I'm sure it will come in handy for any developer who is able to implement it, and in this way we can make the core to be widely used.

It will still require some improvements to the chipset, but @kitune-san has worked on it and I'm sure he will continue to do so, and I will also contribute as much as I can.

[Newsdee]

So I tried to derive a clock that fits the MDA standard, from the basic CLK_VIDEO now set at clk_56_875.

It almost works... it seems to make the MDA fit at CGA resolutions... but the image is very unstable.
It looks like having very bad RF noise. Probably it needs something else to stabilize it.

Code: Select all

reg [27:0] mdaclk   = 18432000; 
reg [27:0] videoclk = 56875000; 

reg ce_mda;
always @(posedge clk_56_875) begin
	reg [27:0] mdasum = 0;
	ce_mda = 0;
	mdasum = mdasum + mdaclk;
	if(mdasum >= videoclk) begin
		mdasum = mdasum - videoclk;
		ce_mda = 1;
	end
	ce_pixel <= mda_mode ? ce_mda : clk_14_318; 
end

[suww37]

Is adlib sound currently output as normal on pcxt core? I tested it with an adlib music player and checked that the sound was mixed with noise. Fortunately, unlike the ao486, the custom drum set sounds seem to be relatively well implemented. I'm not sure if this noise is a problem with Jotego opl2 or pcxt core. I also want to transplant Jotego's opl2 sound in ao486.

[MrMartian]

I will toss my hat in and say I'm working on adding true IDE support compatible with XT-IDE to this. VHDL/Verilog I understand, the MiSTer framework for accessing data I'm still reading through...

[jordi]

I will toss my hat in and say I'm working on adding true IDE support compatible with XT-IDE to this. VHDL/Verilog I understand, the MiSTer framework for accessing data I'm still reading through...

you are all incredible

[Chol]

I've got the case of an old Commodore PC-I in which I plan to put my MiSTer. Is it possible to load its BIOS into the PCXT core? The ROM files are here: http://www.zimmers.net/anonftp/pub/cbm- ... index.html

[Mills]

Is adlib sound currently output as normal on pcxt core? I tested it with an adlib music player and checked that the sound was mixed with noise. Fortunately, unlike the ao486, the custom drum set sounds seem to be relatively well implemented. I'm not sure if this noise is a problem with Jotego opl2 or pcxt core. I also want to transplant Jotego's opl2 sound in ao486.

There is something wrong with volume I think, sometimes I also hear noises.

[Newsdee]

Is it possible to load its BIOS into the PCXT core?

No, it isn't. Right now only the XTIDE ROM is supported, and supporting other BIOS may be difficult as it has features needed to make the HDD work with the core.

Your best best to run such BIOS would be to use PCEm

[Chol]

No, it isn't. Right now only the XTIDE ROM is supported, and supporting other BIOS may be difficult as it has features needed to make the HDD work with the core.

This does not seem to be true. In the SW-Folder there are 3 make_boot_with_*.py scripts from which I could generate BIOS files (like the IBM 5160). Having success with booting these was basically the reason for my question to support another BIOS.

[breiztiger]

Yes i think also it’s possible

? Spark2k06

[spark2k06]

No, it isn't. Right now only the XTIDE ROM is supported, and supporting other BIOS may be difficult as it has features needed to make the HDD work with the core.

This does not seem to be true. In the SW-Folder there are 3 make_boot_with_*.py scripts from which I could generate BIOS files (like the IBM 5160). Having success with booting these was basically the reason for my question to support another BIOS.

As long as it is 64Kb or less, you can try it. Join the files and fill with zeros at the beginning, or you can also use the 12Kb of XTIDE at the beginning, in this case I see that it is possible.

Another thing is if it works later, not all BIOSes work, and it would be necessary to find out why. For example, the IBM 5150 BIOS doesn't work, nor does the PCjr BIOS.

[Malor]

BIOSes were, in effect, very early drivers; they were done custom for each machine, to give DOS an interface to the motherboard devices.

Running an alien BIOS doesn't really make sense. It's like trying to use the wrong driver in Windows. Each BIOS is customized per-machine, and while you can sometimes use a specific ROM on a different motherboard, there are just about zero reasons to do so. It would almost never be better, and would almost always be worse.

What this team is doing is, more or less, picking the BIOS and then creating the hardware to support it, rather than the other way around, but the same thinking applies; trying to use a Commodore BIOS to drive the Mister FPGA hardware is extremely unlikely to improve matters in any way, and is very likely to be useless.

AFAIK Commodore BIOSes were fine; nothing special, but nothing bad. But they're intended for each specific Commodore model, and they're going to be trying to run hardware that's not there.

[dmckean]

Yeah, trying to get the PCjr BIOS going and adding cartridge support would be one thing. But trying to support every clone BIOS that ever existed is way outside the scope of this core.

[Mills]

Thanks to flynnsbit's 500MB image, I was able to make one of my by-year collections specially for this core. It contains all the games from years 1981-1986, and most of 87, based on Total Dos Collection from last year.

There are a lot of games up to 1992 that will work well even on 4.77, for example cool croc twins (and it has tandy support )

Still, it can be quite fun to browse, though the main issue is now the boot speed - it takes nearly 2 minutes, which is a pain when a game doesn't respond to CTRL+X / Q or some other way to go back to DOS and you need to restart

Most games will exit with ESC, CTRL+X / Q and F10. Also you can look for game manuals just in case they use another method.

[Mills]

BIOSes were, in effect, very early drivers; they were done custom for each machine, to give DOS an interface to the motherboard devices.

Running an alien BIOS doesn't really make sense. It's like trying to use the wrong driver in Windows. Each BIOS is customized per-machine, and while you can sometimes use a specific ROM on a different motherboard, there are just about zero reasons to do so. It would almost never be better, and would almost always be worse.

What this team is doing is, more or less, picking the BIOS and then creating the hardware to support it, rather than the other way around, but the same thinking applies; trying to use a Commodore BIOS to drive the Mister FPGA hardware is extremely unlikely to improve matters in any way, and is very likely to be useless.

AFAIK Commodore BIOSes were fine; nothing special, but nothing bad. But they're intended for each specific Commodore model, and they're going to be trying to run hardware that's not there.

I tried award bios from 1986 and it booted ok, you just have to insert the xtide at the start for it to load vhd images

[Malor]

Yeah, trying to get the PCjr BIOS going and adding cartridge support would be one thing. But trying to support every clone BIOS that ever existed is way outside the scope of this core.

Real clone makers didn't do anything of the sort.... they made a clone with a specific BIOS for that model, and that was it. PCEM/x86Box tries to emulate a lot of those motherboards, but that kind of thing is much easier in software.

As FPGA devs, you folks are much closer to being an original clone designer. You just need to get *one* BIOS and motherboard working, not all of them. If you happen to have toggles for Tandy 1000/PCjr/IBM XT modes, that's fine, but that's all extra credit.

[akeley]

There are a lot of games up to 1992 that will work well even on 4.77, for example cool croc twins (and it has tandy support )

I know, but I could only squeeze 81-87 A-S into 500MB. The TDL image goes up to 1988, because it uses zips. I'm sure eventually we will be able to use all kinds and sizes of hdd images. When that happens, I'll probably just make one 81-92 image to have as a repository, this range takes ~4GB, sans CDs. But, I think browsing later years game-by-game (my prefered way to check out libraries) makes more sense on ao486.

[Chol]

Thanks for your input so far. I had no success with the CBM PC-I, but I got the CBM PC-10 BIOS to boot after padding the file with 32kb of zeros at the beginning:

pcxt-pc10.jpg (284.75 KiB) Viewed 8232 times

So that was half a success. I learned that this is not a good idea at all and will stop further approaches.

[AmintaMister]

Sorry, is this core runnable on CRT 31khz VgA monitor?

Thanks!

[akeley]

Sorry, is this core runnable on CRT 31khz VgA monitor?

Thanks!

Haven't tried it myself yet, but if it isn't perhaps using the old VGA modelines from ao486 would work.

[wark91]

since last updates, the core provided 15KHz on output so normally no modelines are needed for consumers TV.

[akeley]

since last updates, the core provided 15KHz on output so normally no modelines are needed for consumers TV.

15KHz has worked from the beginning. Aminta Mister is asking about 31KHz on PC VGA monitors.

[thorr]

Sorry, is this core runnable on CRT 31khz VgA monitor?

Thanks!

If it works on CRT TV's, then forced_scandoubler=1 will probably make it work on VGA monitors.

[Malor]

So that was half a success. I learned that this is not a good idea at all and will stop further approaches.

If you really do want to emulate a specific Commodore PC (I owned one, they were decent), then X86Box, the new fork of PCEM after it was discontinued, is probably the spot to look. They emulate a lot of old hardware and BIOSes, and they might have versions for some Commodore models. It will be somewhat higher latency than a Mister solution, but DOS games mostly aren't that latency sensitive. You should be able to emulate much faster CPUs, if you wish, and would certainly see better compatibility than AO486 or PCXT as it currently stands.

It may also be worth pointing out that DOSBox-X has expanded on original DOSBox a great deal, and offers built-in MUNT and Fluidsynth for MIDI games, and can even run Windows 95 and 98 if you create a hard drive image. (they don't like the DOSBox filesystem driver.)