mbucchia wrote on 2025-02-23, 09:24:

digger wrote on 2025-02-22, 17:17:

wondow wrote on 2025-02-05, 00:11:

I am also very interested. Does it support UMB?

I'm wondering the same thing. I don't see any reference to UMB support on GitHub, but it shouldn't be too difficult to add, right?

I have been looking at adding UMB support after seeing your message. I did a little bit of prototyping today and I have something that works using USE!UMBS. It needs a little bit of polishing, but overall yes I am confident we can offer UMB with the no-wait-state memory. I am not sure yet on the exact amount we can support. We have about 320KB of available RAM on top of the 640K already emulating conventional memory. That should be more than what we need 😀

Do you have a specific scenario I can test? Right now I have only tested loading a simple TSR in UMB (DOSKEY) and confirmed that it loads high and does relinquish some memory back to DOS programs.

Gentle ping @digger 😀
I have a UMB driver/firmware working with our no-wait-state memory and I'd like to do as much testing as possible before merging it to our main branch.

Your input is appreciated!

mbucchia wrote on 2025-02-28, 03:46:

Gentle ping @digger :) I have a UMB driver/firmware working with our no-wait-state memory and I'd like to do as much testing as […]
Show full quote

mbucchia wrote on 2025-02-23, 09:24:

digger wrote on 2025-02-22, 17:17:

I'm wondering the same thing. I don't see any reference to UMB support on GitHub, but it shouldn't be too difficult to add, right?

I have been looking at adding UMB support after seeing your message. I did a little bit of prototyping today and I have something that works using USE!UMBS. It needs a little bit of polishing, but overall yes I am confident we can offer UMB with the no-wait-state memory. I am not sure yet on the exact amount we can support. We have about 320KB of available RAM on top of the 640K already emulating conventional memory. That should be more than what we need 😀

Do you have a specific scenario I can test? Right now I have only tested loading a simple TSR in UMB (DOSKEY) and confirmed that it loads high and does relinquish some memory back to DOS programs.

Gentle ping @digger 😀
I have a UMB driver/firmware working with our no-wait-state memory and I'd like to do as much testing as possible before merging it to our main branch.

Your input is appreciated!

@mbucchia Happy to test, but I need to order a design from a PCB manufacturer! 😅 I haven't gotten around to it yet this week. I hope to place an order this weekend, perhaps this evening.

@MicroCoreLabs I'll let you know if I run into any issues with that, as you've offered. Thanks again!

And then of course I have to wait for it to be delivered to me.

At least I have already received the ISA adapter from Australia, so I should be able to plug the card into my Tandy 1000 EX. 🤞🏽

digger wrote on 2025-02-28, 14:21:

mbucchia wrote on 2025-02-28, 03:46:

Gentle ping @digger :) I have a UMB driver/firmware working with our no-wait-state memory and I'd like to do as much testing as […]
Show full quote

mbucchia wrote on 2025-02-23, 09:24:

Do you have a specific scenario I can test? Right now I have only tested loading a simple TSR in UMB (DOSKEY) and confirmed that it loads high and does relinquish some memory back to DOS programs.

Gentle ping @digger 😀
I have a UMB driver/firmware working with our no-wait-state memory and I'd like to do as much testing as possible before merging it to our main branch.

Your input is appreciated!

@mbucchia Happy to test, but I need to order a design from a PCB manufacturer! 😅 I haven't gotten around to it yet this week. I hope to place an order this weekend, perhaps this evening.

No worries, I meant "Do you have a specific scenario I can test?" As in what is going to be your usage for the UMB, any specific app, so I can try to test that app now?

mbucchia wrote on 2025-02-28, 15:44:

No worries, I meant "Do you have a specific scenario I can test?" As in what is going to be your usage for the UMB, any specific app, so I can try to test that app now?

Ah, okay!

In my specific use case, I want to max out the RAM (conventional+UMB+EMS) in my Tandy 1000 EX. I've already ordered (and received) an aftermarket ISA riser card for its proprietary bus interface, so I can install 8-bit ISA expansion cards in that system.

The 1000 EX has 256KB of RAM out of the box, the lower 128KB of which is special, since it's shared with the on board graphics controller, allowing certain (mostly PCjr-compatible) improved graphics modes over regular CGA (notably 320x200 16 color mode, which is supported in many games).

Since part of the lower conventional RAM is used for shared memory, it's even more relevant for a machine like this to have UMBs, to compensate for the reduced maximum available conventional memory. So ideally, I'd like the conventional memory to be maxed out, added support for EMS memory, and (apart from the page frame required for EMS to work) for every bit of unused upper memory space to be mapped to usable upper memory on the card. I read somewhere that the Tandy 1000 EX potentially supports a lot more upper memory compared to the (otherwise very similar) Tandy 1000 HX, since the HX has DOS 2.x integrated in ROM. Between having a specific (older) DOS version integrated in ROM and just having a lot more upper memory available to load newer DOS versions (as well as mouse drivers and such) high in, I obviously prefer the latter.

Is this enough info for you to work out a testable scenario for? You might need a Tandy 1000 EX to be able to actually test it. Although 86Box should be able to emulate that system in software, if that would help you with debugging.

And of course I'm happy to help you test it on real hardware, once I've acquired an XTMax board. 🙂

Let me know if you need any more info, or need help and inspiration to brainstorm other possible scenarios and uses cases.

Thanks.

So being able to:
- create as many UMB as possible in every unused address space region (our driver based on USE!UMBS does that, and can grab any address up to 0xF0000, currentlt on-going testing)
- being able to set DOS=UMB
- use DEVICEHIGH and LOADHIGH for drivers

I don't believe you will be able to load DOS=HIGH. Because our card is 8-bit ISA, we cannot put our memory as HMA (that require A20 which isn't routed to ISA 8-bit cards). I could be wrong on that matter though!

OK @digger, I don't have a Tandy 1000 but a PS/2 Model 30 (286).

This is me trying my luck at creating as much RAM as possible from the XTMax. Full screenshots from MSD (diagnostics) and MI at the bottom of the post.

Conventional memory

Note that the PS/2 won't let me remove RAM on the motherboard below 512KB. As a result, I am only using XTMax conventional memory to fill out the 512->640KB range. However there is still 512KB allocated on the XTMax for the systems that have less conventional memory to begin with. So it is possible to fill out the entire 640KB of conventional RAM if needed. All at 0-wait state.

Note that XTMax will auto-detect what ranges need to be filled to reach 640KB. So you don't need to configure anything.

UMBs

I used our UMB driver to fill out the gaps in the address space above 640KB. I'm using this command line with our driver:

1DEVICE=A:\XTUMBS.SYS A000-B800 C000-CE00 CF00-D000

This creates 3 UMB regions, totaling 156KB of UMBs. All at 0-wait state.
Explaining the layout:
- A0000-B7FFF is UMB (96KB)
- B8000-BFFFF is VRAM
- C0000-CDFFF is UMB (56KB)
- CE000-CEFFF is XTMax BIOS ROM
- CF000-CFFFF is UMB (4KB)
- D0000-DFFFF is the page frames for EMS
- E0000-FFFFF is PS/2 BIOS (yes, it's a large BIOS)

However the XTMax has a total capable UMB capacity of 320KB, all at 0-wait state. If you don't have BIOS at E0000 like me, you could add another 64KB there. If you don't use VGA, you can also add another 32KB. If you don't want to use XTMax' SD Card, you can disable (or relocate) the BIOS ROM. If you don't want EMS, you can reclaim another 64KB...

The configuration is entirely done with the CONFIG.SYS line used to load the driver.

EMS

I have 2x PSRAM chips on the XTMax giving me 16MB of EMS. All that's needed is to load the driver:

1DEVICEHIGH=A:\XTEMM.EXE /N

You can also add a parameter to relocate the EMS page frame anywhere you want (default is D0000-DFFFF). If you omit loading the driver, then the page frame is not allocated at all, and you can use the additional 64KB for UMB by modifying the UMB driver command line (further above).

End result

See the attached picture. This is everything maxed out on my system with XTMax.

mbucchia wrote on 2025-03-02, 18:29:

So being able to: - create as many UMB as possible in every unused address space region (our driver based on USE!UMBS does that, […]
Show full quote

So being able to:
- create as many UMB as possible in every unused address space region (our driver based on USE!UMBS does that, and can grab any address up to 0xF0000, currentlt on-going testing)
- being able to set DOS=UMB
- use DEVICEHIGH and LOADHIGH for drivers

As many UMB as possible indeed, but if possible while still also allowing EMS (so still reserving the necessary page frame in the upper memory space, and then backfilling any remaining unused upper memory space with RAM).

And this on top of completely maxed out conventional memory (640KB), of course.

And all this RAM (conventional+UMB+EMS) with 0 wait states.

I don't believe you will be able to load DOS=HIGH. Because our card is 8-bit ISA, we cannot put our memory as HMA (that require A20 which isn't routed to ISA 8-bit cards). I could be wrong on that matter though!

Indeed. As I understand it, DOS=HIGH would require a 286 machine with extended memory, and control of the A20 gate. The Tandy 1000 EX is an 8088 system (I upgraded it with a NEC V20 CPU), so I didn't expect it to ever be able to have access to the High Memory Area, but with enough UMBs, I think it should still be enough for the system to be able to run any real mode application or game that supports the Tandy 1000 16-color graphics mode or at least CGA graphics. That's my goal for this system.

Note that the PS/2 won't let me remove RAM on the motherboard below 512KB. As a result, I am only using XTMax conventional memory to fill out the 512->640KB range. However there is still 512KB allocated on the XTMax for the systems that have less conventional memory to begin with. So it is possible to fill out the entire 640KB of conventional RAM if needed. All at 0-wait state.

Note that XTMax will auto-detect what ranges need to be filled to reach 640KB. So you don't need to configure anything.

That's great. Looking forward to testing that in my Tandy 1000 EX.

However the XTMax has a total capable UMB capacity of 320KB, all at 0-wait state. If you don't have BIOS at E0000 like me, you could add another 64KB there. If you don't use VGA, you can also add another 32KB. If you don't want to use XTMax' SD Card, you can disable (or relocate) the BIOS ROM. If you don't want EMS, you can reclaim another 64KB...

Ah yes, of course, I forgot that: I would indeed like it to have a bootable SD drive, so I would have to enable the BIOS ROM for that at least. I'd like to have EMS too, so I wouldn't be able to reclaim that 64KB either.

On the other hand, since the Tandy 1000 uses some of the the lower 128KB for shared memory for its PCjr-compatible graphics adapter, and I would like to use it with its native graphics capabilities, that means I would be able to use that 32KB that would otherwise be needed for a VGA BIOS. 🙂

EMS […]
Show full quote

EMS

I have 2x PSRAM chips on the XTMax giving me 16MB of EMS. All that's needed is to load the driver:

Copy code to clipboard

1DEVICEHIGH=A:\XTEMM.EXE /N

You can also add a parameter to relocate the EMS page frame anywhere you want (default is D0000-DFFFF). If you omit loading the driver, then the page frame is not allocated at all, and you can use the additional 64KB for UMB by modifying the UMB driver command line (further above).

16MB of EMS. Sweet. ☺️

Oh, another question: the BIOS for the bootable SD card, is that based on the XTIDE BIOS? And would it be possible to have both an 8088 variant and an 186+/V20-optimized variant?

I upgraded my Tandy 1000 EX with a V20 CPU, and from what I understood from the XTIDE BIOS, there is a variant that takes advantage of the additional instructions in the 186 and later (and V20/V30) CPUs, which is quite a bit more performant than the 8088/8086-compatible variant of the BIOS.

Thanks again, and great work!

I'm going to stop talking the talk and order an XTMax board at a PCB manufacturer this evening after work! 😃

^DOS=HIGH does have an effect on an PC/XT in MS-DOS 6.22, if USE!UMB.SYS was being loaded. I tried myself, with a non-intelligent UMB card.
I tried it together with UMB setting: DOS=HIGH, UMB

Of course, there's no HMA in XTs, but MS-DOS 6.22 does upload more DOS data into UMB if the HIGH setting is set additionally.
It will also complain with a message similar to "HMA not available, use lower memory", which can be ignored.

Jo22 wrote on 2025-03-03, 13:04:

^DOS=HIGH does have an effect on an PC/XT in MS-DOS 6.22, if USE!UMB.SYS was being loaded. I tried myself, with a non-intelligen […]
Show full quote

^DOS=HIGH does have an effect on an PC/XT in MS-DOS 6.22, if USE!UMB.SYS was being loaded. I tried myself, with a non-intelligent UMB card.
I tried it together with UMB setting: DOS=HIGH, UMB

Of course, there's no HMA in XTs, but MS-DOS 6.22 does upload more DOS data into UMB if the HIGH setting is set additionally.
It will also complain with a message similar to "HMA not available, use lower memory", which can be ignored.

Cool! I didn't know that. Thanks for sharing that tip!

Quite weird and unintuitive that `DOS=UMB` doesn't make maximum use of UMB, but `DOS=HIGH,UMB` does.

But when you take a step back, it makes you wonder why Microsoft never made MS-DOS smart enough to detect and take optimal advantage of all this automatically.

@Jo22 do you happen to know whether DR-DOS handled this more intelligently, or at least more consistently?

digger wrote on 2025-03-03, 09:57:

the BIOS for the bootable SD card, is that based on the XTIDE BIOS? And would it be possible to have both an 8088 variant and an 186+/V20-optimized variant?

I upgraded my Tandy 1000 EX with a V20 CPU, and from what I understood from the XTIDE BIOS, there is a variant that takes advantage of the additional instructions in the 186 and later (and V20/V30) CPUs, which is quite a bit more performant than the 8088/8086-compatible variant of the BIOS.

It is not based on XT-IDE. The 8088 vs V20 flavor is not necessary. The SD Card controller uses memory-mapped I/O (MMIO), which enables the use of "REP MOVSW" instructions, which should already be the optimum way on both 8088 and newer CPUs (well, "optimum" without DMA, but that's another story). The restriction on instruction set only applies when using I/O ports instead of MMIO, because the 8088 doesn't support "REP INSW"/"REP OUTSW". We moved away from that model in order to provide a single, unified, optimized BIOS.

mbucchia wrote on 2025-03-03, 16:10:

It is not based on XT-IDE. The 8088 vs V20 flavor is not necessary. The SD Card controller uses memory-mapped I/O (MMIO), which enables the use of "REP MOVSW" instructions, which should already be the optimum way on both 8088 and newer CPUs (well, "optimum" without DMA, but that's another story).

This is a smart way to handle it, and REP MOSVW is likely indeed the fastest way to transfer data on the 8088. Nevertheless, the 8088 isn't that fast at REP MOVSW either, and the V20 is a significant upgrade in that regard. I have a ST-01 SCSI interface card in my Turbo XT that uses REP MOVSW for data transfer, and the SCSI throughput as measured by coretest is (if I remember correctly) around twice as high with the V20 compared to an 8088. The 1GB HDD (sorry for putting that into an XT, I don't have a smaller working SCSI drive at hand...) is fast enough to not be the bottleneck.

mkarcher wrote on 2025-03-03, 23:22:

mbucchia wrote on 2025-03-03, 16:10:

It is not based on XT-IDE. The 8088 vs V20 flavor is not necessary. The SD Card controller uses memory-mapped I/O (MMIO), which enables the use of "REP MOVSW" instructions, which should already be the optimum way on both 8088 and newer CPUs (well, "optimum" without DMA, but that's another story).

This is a smart way to handle it, and REP MOSVW is likely indeed the fastest way to transfer data on the 8088. Nevertheless, the 8088 isn't that fast at REP MOVSW either, and the V20 is a significant upgrade in that regard. I have a ST-01 SCSI interface card in my Turbo XT that uses REP MOVSW for data transfer, and the SCSI throughput as measured by coretest is (if I remember correctly) around twice as high with the V20 compared to an 8088. The 1GB HDD (sorry for putting that into an XT, I don't have a smaller working SCSI drive at hand...) is fast enough to not be the bottleneck.

Thanks! BTW are you the mkarcher who forked the LTEMM driver for TOPCAT!? If so, you are credited in our EMS driver 😉

https://github.com/mbucchia/XTMax/blob/6cc961 … LTEMM.ASM#L3532

The memory-mapped I/O solution indeed sounds more efficient. Glad this offers an optimal solution for both 8086/8088 and V30/V20 CPUs. Thanks for the explanation.

Update from my attempt to have an XTMax card fully assembled by a European PCB manufacturer:

I uploaded XTMAX_PCB.zip to the sandbox on the AISLER website, and it appeared to process the PCB design correctly, but under the "components" tab, it gave me a message that the project had no components. And it also doesn't allow me to upload the separate spreadsheets containing the BOM and the pick-and-place (top and bottom) data.

Instead, AISLER expects such information to be embedded in the (Gerber and/or Kicad?) project files somehow.

I guess this is where AISLER is a bit more restricted/limited than the other (Chinese) on-line PCB manufacturers. I sent an email message to AISLER, asking for assistance with this. Maybe they might still be able to help me out in having a fully-assembled XTMax card shipped to me. If not, I'll just go with JLCPCB as the PCB manufacturer, as @MicroCoreLabs initially suggested.

I'll keep you updated!

mbucchia wrote on 2025-03-04, 00:02:

Thanks! BTW are you the mkarcher who forked the LTEMM driver for TOPCAT!? If so, you are credited in our EMS driver 😉

Yes, I am. That driver should work, but it still misses an interesting feature of the TOPCAT chipset: The TOPCAT chipset allows mapping of big parts of the main memory, which can be exposed by the EMS 4.0 API, but that is not implemented yet. I'm unsure whether I get around to add this feature.

mkarcher wrote on 2025-03-04, 06:25:

mbucchia wrote on 2025-03-04, 00:02:

Thanks! BTW are you the mkarcher who forked the LTEMM driver for TOPCAT!? If so, you are credited in our EMS driver 😉

Yes, I am. That driver should work, but it still misses an interesting feature of the TOPCAT chipset: The TOPCAT chipset allows mapping of big parts of the main memory, which can be exposed by the EMS 4.0 API, but that is not implemented yet. I'm unsure whether I get around to add this feature.

Nice! I primarily looked at your changes in order to remove the 8-bit limitation and allow the page addresses to use 16 bits (to enable >4MB memory).

No support for EMS 4.0 backfilling in XTMax, though it _could_ be done, but it looks like a fairly niche scenario for the amount of work it needs (IMO).

Well, it's fancy seeing you here, small world 😁

mkarcher wrote on 2025-03-04, 06:25:

mbucchia wrote on 2025-03-04, 00:02:

Thanks! BTW are you the mkarcher who forked the LTEMM driver for TOPCAT!? If so, you are credited in our EMS driver 😉

Yes, I am. That driver should work, but it still misses an interesting feature of the TOPCAT chipset: The TOPCAT chipset allows mapping of big parts of the main memory, which can be exposed by the EMS 4.0 API, but that is not implemented yet. I'm unsure whether I get around to add this feature.

And to support TOPCAT 386 DX too.
mkarcher's adaption just was developed for my TOPCAT 386 SX motherboard to see about the 32 MB support of this board (16 MB 386 SX address space + 16 MB rest for EMS, and a test with almost 32 MB EMS too).
However, for testing I recommend to use SRDISK's SRDEMS.SYS driver too.

Question for those familiar with the XTMax PCB design:

I imported the KiCad PCB project file of the XTMax project in the AISLER sandbox, and it appears to have successfully parsed the BOM and pick-and-place data from it, along with the PCB schematic.

It still requires me to manually assign most of the parts, but most of these I can figure out by searching for the part number and form factor.

However, one of the "components" listed in the BOM is "BUS_ISA_8bit" . This is a bit confusing, since this is basically just the edge connector of the PCB itself, right?

Maybe it was marked as a "component" in KiCad, even though it's not actually a separate component to be mounted or soldered on the board?

See screenshot.

Thanks for clarifying.

digger wrote on 2025-03-12, 12:47:

Maybe it was marked as a "component" in KiCad, even though it's not actually a separate component to be mounted or soldered on the board?

That's exactly how it works in KiCad: Everything that can be connected to traces is modelled as component, this includes edge connectors. If you care only about the PCB and pick&place instructions, you can ignore the "component" BUS_ISA_8bit. If you want to import the schematic into another electronic CAD tool, you need to find out how that tool models edge connectors, if it doesn't model them as "component".

mkarcher wrote on 2025-03-12, 21:24:

That's exactly how it works in KiCad: Everything that can be connected to traces is modelled as component, this includes edge connectors. If you care only about the PCB and pick&place instructions, you can ignore the "component" BUS_ISA_8bit. If you want to import the schematic into another electronic CAD tool, you need to find out how that tool models edge connectors, if it doesn't model them as "component".

Thank you. That makes sense. Since the ISA card edge connector does appear to be rendered probably in the schematic viewer under the "PCB" tab, it does look like I can just ignore that "component" then. Under the "BOM" tab, I have the option to "hide" or "exclude" a part. I think that will do the trick.

I posted an XTMax demonstration video to YouTube:

https://youtu.be/nfCe-_dZ8yY