MiSTer PCXT

[thisisamigaspeaking]

Checking out the notes it also mentions Tandy as yet to be implemented but it is already available?

Maybe the (S)VGA implementation could be copied from ao486? Is the difference between VGA and SVGA just the supported clocks? It should support all the EGA modes too right?

It doesn't, you need to remember what the ao486 is. It's a translation of the Bochs AI-32 instruction set to verlilog done by automated tools and it's been heavily optimized with large amounts of cache and some pipelining to run at acceptable speeds. Most of its modules work ok now but are not all that accurate to real hardware.

This project has different goals and to be as cycle accurate as possible is one of them.

Ah, good to know. I am totally new to MiSTer. Didn't know that about ao486.

I definitely like the idea of a cycle accurate XT. Tandy graphics and sound cover 75%+ of what I'm looking for.

[flynnsbit]

I have multiplied the speed of uart_clk by 4, now it is possible to change the script to work up to 460.8Kbps

Attached binary.

Pretty big difference. Note if you were using my bios file I posted before it is hard coded to 115.2 so you need to go back to the one in the repo. I'll redo it tonight. It's 4x as fast for sure. Noticeable difference. Not sure if that stabilized some things or if it just feels more stable. Need more testing.

Before:

Before.png (362.75 KiB) Viewed 3430 times

After

Screenshot 2022-07-13 153347.png (72.81 KiB) Viewed 3436 times

[pgimeno]

"make_boot_with_tandy.py" does not work. I went to the "http://retrograde.inf.ua/files/T1K_0101.ZIP" link directly in a web browser, but this site did not open and I could not receive the file. There seems to be something wrong. Are you guys all right? I'm sorry, but I would appreciate it if you could send me boot.rom with tandy bios by message.

archive.org is your friend.

http://web.archive.org/web/202005020635 ... K_0101.ZIP

[pgimeno]

After everything is completed with this core with Tandy which will be totally awesome, I hope we can get a 286 core. There are some games that work great on 286/12 and 286/16, and anything else needs to be slowed down because it runs too fast. What I really would like is a selection of any CPU, graphics card, etc., like in PCEM, with cycle accuracy.

Don't dream too far. If there is a 286 core ever, it's going to be a different core for sure. This project focuses on low(ish)-level emulation of the hardware of the 8088/8086, which is very different to that of the 286. What you're requesting amounts to many cores in one, and I doubt there's enough room for more than two; even two might be troublesome.

[thorr]

Yeah, a core for each generation with configurable hardware that was available for it at that time would be awesome. PCXT is the first. It sounds like Next186 might be for the 286. Having cycle accurate versions of each PC generation is the dream. It may take years or decades, but that's ok. PCXT with Tandy is the most important in my opinion because ao486 works for most other things with some workarounds.

[Malor]

After everything is completed with this core with Tandy which will be totally awesome, I hope we can get a 286 core. There are some games that work great on 286/12 and 286/16, and anything else needs to be slowed down because it runs too fast. What I really would like is a selection of any CPU, graphics card, etc., like in PCEM, with cycle accuracy.

Also, I am hoping that Tandy digital sound support will be supported: https://youtu.be/kbp094HDZ20?t=210

Configurability tends to be hard on FPGA, because the core has to carry every circuit for every option. It might be easier to stop development on this specific core when the XT is fully implemented, and then fork it to start on the AT.

Among other things, the AT has many more IRQs, which was done by cascading a second interrupt handler chip off IRQ2. Doing both that and the XT's simpler one-chip IRQ handler in the same core could be hairy. Implementing both 16-bit ISA and 8-bit ISA might be annoying. The IDE controller, for instance, would need to be both 8-bit and 16-bit. Real IDE controllers could do that, but it's a bunch of extra work that could be avoided here. The XT controller can be purely 8-bit, and the AT controller can be purely 16-bit, as the devs know for sure that they're not going to be plugged into random clone computers.

PCEM's ability to give you a ton of toggles and massive changes to the underlying hardware is a feature of software emulation. Hardware emulation is much easier if you just pick a few things and stick with them.

In effect, you'd be asking for them to build a motherboard that was both an XT and an AT at the same time, which AFAIK was never done in real life.

[thorr]

Agreed. Separate cores makes the most sense for sure. Anyway, I am greatly looking forward to watching PCXT continue to improve and eventually be a fully released core. I have a lot going on at the moment so I am happy to just sit back and watch the progress and when I eventually have time to try using it, I am sure many of the remaining basic things to implement will already be finished. If I find my old 5.25" floppies, I might have to see if I can read them and get my GW Basic programs off of them. I think I have a PC with a 5.25" drive around somewhere buried in dust in my garage. I also want to play some Pango, Mean 18 Golf, Rogue, and Silent Service.

[Malor]

Just FYI, the Amiga has Silent Service, and I think it's a really good version. It's in the MegaAGS collection, so it's easy to find and run.

[Newsdee]

Between the PCXT and the ao486 cores we will probably be able to cover most cases needed for DOS games.

We don't need to cram everything in PCXT; things like SVGA, 286 instructions, or even VGA are best left for other cores.

It's already fantastic to have an original 8088 core with features specific to this early era (CGA, Tandy, maybe even Hercules one day). Those features don't really belong in ao486, which aims to offer compatibility with 386 and 486 era machines.

Also, I'm not sure how many people know this, but ao486 has a feature whereby you can control core settings from a DOS command line.

Which means you can have a VHD that boots and automatically sets the core at a desired speed (say to match a 286 AT).

I havent yet tested how different speeds compare to various PC models, but we could give it a try for those games that don't really fit in PCXT at 7Mhz or the default ao486 settings.

(sure, in time we may have more cores, but my interest here is curating lists of games that fit each era, to make dedicated VHDs, so splitting in 2 or 3 groups conceptually is already interesting to me)

[thisisamigaspeaking]

Between the PCXT and the ao486 cores we will probably be able to cover most cases needed for DOS games.

We don't need to cram everything in PCXT; things like SVGA, 286 instructions, or even VGA are best left for other cores.

It's already fantastic to have an original 8088 core with features specific to this early era (CGA, Tandy, maybe even Hercules one day). Those features don't really belong in ao486, which aims to offer compatibility with 386 and 486 era machines.

Also, I'm not sure how many people know this, but ao486 has a feature whereby you can control core settings from a DOS command line.

Which means you can have a VHD that boots and automatically sets the core at a desired speed (say to match a 286 AT).

I havent yet tested how different speeds compare to various PC models, but we could give it a try for those games that don't really fit in PCXT at 7Mhz or the default ao486 settings.

(sure, in time we may have more cores, but my interest here is curating lists of games that fit each era, to make dedicated VHDs, so splitting in 2 or 3 groups conceptually is already interesting to me)

The nagging issue for me in all that is EGA, but I am not sure how many games have 320x200x16 EGA and not Tandy. I seem to remember that there were some.

Very interested in a curated ~Tandy-ish collection.

[Newsdee]

The nagging issue for me in all that is EGA, but I am not sure how many games have 320x200x16 EGA and not Tandy. I seem to remember that there were some.

I'd expect those EGA games to work on ao486. Is there an EGA specific feature that it is missing?

[Newsdee]

I can boot and play games from this hdd, but PCXT core does not recognise it. I have boot.rom & serdrive in the games directory, also tried different names and edited the script, but it's not being detected.

Sorry, I should have posted a setup example to save you some hassle... I used dos 6.2 floppies with ao486, which recognize the blank VHD and format it in a few minutes. After that I just tweak config.sys to disable memory settings not supportrd by PCXT.

The inages use default geometry settings, so the mount script should not specify a -g flag. If you are using one, try removing it.

[dmckean]

The nagging issue for me in all that is EGA, but I am not sure how many games have 320x200x16 EGA and not Tandy. I seem to remember that there were some.

I'd expect those EGA games to work on ao486. Is there an EGA specific feature that it is missing?

The VGA standard supports all the official documented modes of MDA, CGA and EGA. But the same way that there are a bunch of games on this core using undocumented CGA modes there is a handful of EGA games that do the same. This will probably never be the right core for those games and ao486 might not ever be either.

[thorr]

Also, I'm not sure how many people know this, but ao486 has a feature whereby you can control core settings from a DOS command line.

Which means you can have a VHD that boots and automatically sets the core at a desired speed (say to match a 286 AT).

I did not know this. I found the details on the ao486 github page. You need sysctl.exe. This will be great to use in bat files for individual games. I am working on making my own collections of games and keep running into speed issues and this should help solve it. Thanks!

[suww37]

Also, I'm not sure how many people know this, but ao486 has a feature whereby you can control core settings from a DOS command line.

Which means you can have a VHD that boots and automatically sets the core at a desired speed (say to match a 286 AT).

I did not know this. I found the details on the ao486 github page. You need sysctl.exe. This will be great to use in bat files for individual games. I am working on making my own collections of games and keep running into speed issues and this should help solve it. Thanks!

I know how to adjust the speed using the "sysctl.exe" and the l1,l2 cache option, but I don't think it's the actual speed of the XT pc and 286 pc at the time. Therefore, I think 286 core is also needed and 386 core is also needed.

[spark2k06]

I update the prebeta 1.4 branch with the following change:

https://github.com/spark2k06/PCXT_MiSTe ... 682bb10ffb

• UART port speed increase to 921.6Kbps

It is now possible to configure the disk image with serdrive at the following speeds:

19200, 38400, 115.2K, 230.4K, 460.8K and 921.6K.

Although, at least for me, the speed that is working for me is 460.8K, therefore, in the repository I have updated the script for serdrive to mount the hdd image at this speed... however, you can try the maximum and use it if it works for you.

Even at 460.8K, we're talking about up to a 4x increase in loading speed, so you'll see a very interesting increase in loading speed for games and programs:

hdd_benchmark.jpg (117.88 KiB) Viewed 3164 times

Thanks for letting me know, @MicroCoreLabs

[Newsdee]

I know how to adjust the speed using the "sysctl.exe" and the l1,l2 cache option, but I don't think it's the actual speed of the XT pc and 286 pc at the time. Therefore, I think 286 core is also needed and 386 core is also needed.

Made a new thread, let's discuss it here:
viewtopic.php?p=55983#p55983

[Malor]

I know how to adjust the speed using the "sysctl.exe" and the l1,l2 cache option, but I don't think it's the actual speed of the XT pc and 286 pc at the time. Therefore, I think 286 core is also needed and 386 core is also needed.

I did some very quick looking around, and I'm not sure anyone has done an open source 80286 or 80386 for FPGAs. I see mention of a closed-source 286 project for a different chip, but with no hints of a public code release. I do see an 80186 project, but I'm not sure how much of that design could be used.

Both the 286 and 386 should, at least hypothetically, be doable on the Mister, but they'd be a heck of a lot of work. The 286 has 134K transistors, where the 386 has 275K. Those are big projects, perhaps big enough not to be fun anymore.

[spark2k06]

To implement IDE and FDD, if you don't need a low level compatibility (i think BIOS level should be enough for games, right?) then you can go much simpler way. You don't need IDE and FDD HW handling in BIOS. Just define your own ports close match to sd_* signals of hps_io module and directly read/write sectors from mounted images.

I prefer the use of original BIOS to custom ones, for many reasons. Especially, maintenance and support of model-specific video modes, like Tandy.

Better an initial effort to have a faithful IDE/floppy implementation, and 0 BIOS maintenance afterwards.

[spark2k06]

The IDE implementation must be compatible with XTIDE Universal BIOS, which is the one currently in use. It is a solid and mature BIOS for this purpose.

[thisisamigaspeaking]

I do see an 80186 project, but I'm not sure how much of that design could be used.

Sounds like Next186, the MiST version of which is being adapted to MiSTer currently.

[thisisamigaspeaking]

I prefer the use of original BIOS to custom ones, for many reasons. Especially, maintenance and support of model-specific video modes, like Tandy.

Better an initial effort to have a faithful IDE/floppy implementation, and 0 BIOS maintenance afterwards.

The IDE implementation must be compatible with XTIDE Universal BIOS, which is the one currently in use. It is a solid and mature BIOS for this purpose.

This is a good approach. Thanks for your work on this, I plan on trying it out this weekend.

[Newsdee]

The IDE implementation must be compatible with XTIDE Universal BIOS, which is the one currently in use. It is a solid and mature BIOS for this purpose.

Isn't XTIDE open source? Maybe it can be expanded to allow a use case for MiSTer with the necessary changes to ease integration?

[spark2k06]

The IDE implementation must be compatible with XTIDE Universal BIOS, which is the one currently in use. It is a solid and mature BIOS for this purpose.

Isn't XTIDE open source? Maybe it can be expanded to allow a use case for MiSTer with the necessary changes to ease integration?

Right, it's Open Source... you could modify it, but you can also make an IDE module that works directly with this BIOS. The question is, which is easier in this case? What is "untouchable" in any case is the original BIOS of the PC system.

[dmckean]

I think it's best if we try to recruit someone that's capable of modifying the 16-bit IDE module in the ao486 core to work in this core. I'm not sure who that would be though or I probably would have talked to them already.

[Malor]

From what I've seen, the AO486 IDE isn't very good. I was kind of hoping that your work here might be expanded to 16 bits and ported to their core, as it definitely seems to need work.

[akeley]

I think it's best if we try to recruit someone that's capable of modifying the 16-bit IDE module in the ao486 core to work in this core. I'm not sure who that would be though or I probably would have talked to them already.

@Flandango / dshadoff /alanswx ? These devs have done some serious work regarding microcomputers and are still more or less active.

[jordi]

The IDE implementation must be compatible with XTIDE Universal BIOS, which is the one currently in use. It is a solid and mature BIOS for this purpose.

Isn't XTIDE open source? Maybe it can be expanded to allow a use case for MiSTer with the necessary changes to ease integration?

If I understood correctly, the suggestion is to connect one *PC_XT port* directly to to sd_* signals of hps_io module and directly read/write sectors from mounted images.

Maybe to port 300h (IDE) directly? Or replacing COM1 source code of XT IDE source code to read instead of 0x3F8 for an unused port and adapt the interface to the expected by sd_* signals

[jordi]

I think it's best if we try to recruit someone that's capable of modifying the 16-bit IDE module in the ao486 core to work in this core. I'm not sure who that would be though or I probably would have talked to them already.

@Flandango / dshadoff /alanswx ? These devs have done some serious work regarding microcomputers and are still more or less active.

Unfortunately, mentions do not work on this forum

[spark2k06]

In a nutshell, what is needed if you want to use IDE with XTIDE, is to use the default 300h port by implementing an 8bit IDE interface that reads from a VHD image. As "simple" as that