GLaBIOS compatibility questions #1

640-KB · 2023-07-02T20:24:00Z

Hi Rodney,

First of all congrats on releasing this - it looks extremely cool and is something I'd definitely like to build. :)

Anyway, I'm the author of GLaBIOS and i387DX on TRW Discord suggested maybe we connect about hardware/BIOS compatibility? I'm always adding hardware support for new projects so would love to be part of this.

Happy to talk here, or are you on Discord?

640KB

rodneyknaap · 2023-07-03T06:04:53Z

Hi 640KB,

Thanks for your interest and getting in touch, that's very kind of you.
I also responded on the dosreloaded.de forum.

I am also interested in your BIOS. I really hope the GLaBIOS could work on my system because I love the work and I saw many customizations in the source code.
That kind of work is really modern and I feel it matches with my hardware.

About my design, it basically uses the same keyboard circuits as the original IBM 5160 and Turbo XT clones made in Taiwan.
There is no keyboard controller, it's all done in the 8255 PIO chip and the 74LS322 just as in the IBM designs.
The keyboard I use is a Cherry G80-1000 with the dipswitch in "XT" mode.

I am not sure why the TOGGLE.COM causes the strange configuration of the keyboard to input numbers on the prompt instead of the arrow key function. It almost seems as it's confusing scancodes of the arrow keys with the number keys in the numerical section of the keyboard. TOGGLE.COM only changes the typing mode to CAPS and enables the numerical keys by default. On the XT I did notice before that TOGGLE.COM works in a strange way with the phatcode BIOS too, because it does turn on CAPs typing and numlock, however the LEDs do not turn on. I guess doing that requires an actual keyboard controller on the mainboard, I am not sure.

After taking TOGGLE.COM out of my AUTOEXEC.BAT, I could see that DOSKEY functioned normally to recall previous DOS commands instead of showing numbers on arrow presses. So TOGGLE.COM seems to confuse the keyboard routines somehow.

About my UMB memory, it is very simple, it's enabled with two jumpers in my memory decoder. The jumpers are on which means that the memory is accessible in the D0000 and E0000 memory regions. CLEARMEM.SYS zeroes out the area and USE_UMBS.SYS initializes it for usage as UMB RAM. The commands are as follows:

DEVICE=C:\DOS62\CLEARMEM.SYS D000 2000
clears the area starting at D0000h for a 20000h section of RAM.

DEVICE=USE_UMBS.SYS
initializes the UMB blocks. This driver works best when initializing an entire 128KB block.

I am not sure how the driver works, but I did find the source code, which might help you understand what happens:

;-------------------------------------------------------------------
;
; PROGRAM   Use!UMBs.sys - UMB manager for PC/XT/ATs
;
; PURPOSE   This program creates a device driver that will handle
;           calls for Upper Memory Blocks. In doing so, it gives
;           you the possibility to save conventional memory by
;           storing device drivers and resident programs in the
;           UMBs and hence save conventional memory.
;
; REQUIRES  It will work on any PC/XT/AT or higher, either with or
;           without extended memory. What you obviously *must* have
;           are UMBs, and MS-DOS Version 5.0.
;
; AUTHOR    Marco van Zwetselaar    Phone: **-31-30-313128
;           Oorsprongpark 5         FidoNet: Marco van.Zwetselaar
;           3581 ES Utrecht                  NetMail 2:281/701
;           The Netherlands         Utrecht, 7 Nov 1991
;
;-------------------------------------------------------------------
;
; IMPORTANT NOTE to the programmer
;
; I am only a beginner in assembly language, and haven't found out
; as yet how to create a .com file. When you recompile this program,
; take care you do that as a com file, and then rename it to a .sys
; file.
;
; I used an alternative method that you may use as well: I compiled
; it to .exe format and then removed the first (half?) sector. In
; fact, the first bytes in the final file should be:
;
; FF FF FF FF 00 E0 ...
;
; which are the bytes that start at nextDev. (Almost any device
; driver file should start with the first two words being FFFF (-1)).
;
;====================================================================
;
; THE ACTUAL ASSEMBLY CODE
;
;---------------------------------------------
; This is the structure of the request header; not stored in file
;
rh              segment at 0
org     02h
rh_cmd          db      ?               ;command-code
rh_status       dw      ?               ;return-code
org     0Eh
rh0_brk_ofs     dw      ?               ;end of driver offset
rh0_brk_seg     dw      ?               ;end of driver segment
rh              ends
;
;--------------------------------------------
; The driverheader


org     0h
zwetsUMB        segment public
assume  cs:zwetsumb, es:rh, ds:nothing


; any device driver will start with the following info:


next_dev        dd      -1
attribute       dw      0E000h
strategy        dw      strat
interrupt       dw      intr
dev_name        db      'I_LOVE_M'


;--------------------------------------------
; Storage space for pointer to Request Header


hdrptr  label   word
dw      ?,?


;--------------------------------------------
; Strategy: store pointer to Request Header:


strat   proc    far
mov     [hdrptr],bx
mov     [hdrptr]+2,es
retf
strat   endp


;--------------------------------------------
; Interrupt: The routine that fires the installrequest


intr    proc    far


push    ax
push    bx
push    es
pushf


les     bx, dword ptr [hdrptr]  ;point es:bx to ReqHeader
mov     [bx].rh0_brk_seg, cs    ;and already return the seg


; Remember that the device will only answer the init-request
; which is called by dos as it installs the driver.
; Any later calls will be ignored - they are not needed anyway.


mov     al, es:[bx].rh_cmd      ;commandcode into al
or      al, al                  ;is it 0 (=init)?
jnz     other                   ;   no => get off
jmp     inst                    ;   yes => install


other:  cmp     al, 10h                 ;is it legal call?
jbe     short dos               ;   yes => "Sorry"
mov     ax, 8003h               ;   no => "Unknown command"
jmp     short exit


dos:    xor     ax, ax                  ;"Sorry - not implememented"


exit:   or      ax, 0100h               ;Set done bit
mov     es:[bx].rh_status, ax   ;set return code


popf
pop     es
pop     bx
pop     ax


retf                            ; back to dos


intr    endp


;------------------------------------------------------
; Storage space for the addresses of free umb blocks


umb     struc
start   dw      ?
len     dw      ?
umb     ends


;you can add to the following list, as long as the last one is 0,0


free    umb     <0D000h, 1FFFh>   ;my only block (at d000, length 1fff)
umb     <0, 0>            ;space for extra block
umb     <0, 0>            ;and another block
umb     <0, 0>            ;The end of the blocks is marked
; with 0,0 DON'T REMOVE THIS!!!!!


;------------------------------------------------------
; This is the code for the actual UMB memory provider


umbreq  proc    near


push    ds
push    si
push    cx
push    bx


push    cs
pop     ds


mov     si, offset free
xor     cx, cx                  ;clear dx and use it to compare
xchg    dx, cx                  ;to largest found as yet - cx=size


search: lodsw                           ;read startsegment into ax
or      ax, ax                  ;is it 0
jz      fini                    ;   then buzz off
mov     bx, ax                  ;   otherwise store into bx
lodsw                           ;read length in ax
cmp     bx, 0FFFFh              ;is startsegm=ffff=given away
je      search                  ;   yes: then find next block
cmp     dx, ax                  ;   no: larger than largest upto now?
jae     szchk                   ;       no: check size
mov     dx, ax                  ;       yes: mark as largest


szchk:  cmp     cx, ax                  ;will it fit?
ja      search                  ;   no: search next


; YEAH! Found a block


mov     [si-4], 0FFFFh          ; mark as used
mov     dx, ax                  ; put blocksize in dx
mov     ax, 1                   ;say Succes
pop     cx                      ;still had bx on stack
jmp     short return


fini:   xor     ax, ax                  ;no fitting UMB
or      dx, dx                  ;is dx=0?, so largest found=0
jnz     sizerr                  ;   if not: problem with size
pop     bx                      ;   if yes: BH should stay intact
mov     bl, 0B1h                ;       and BL signals: out of UMBs
jmp     short return


sizerr: pop     bx                      ;BH remains intact
mov     bl, 0B0h                ;BL signals: there are smaller ones


return: pop     cx
pop     si
pop     ds
popf
retf


umbreq  endp


;------------------------------------------------------
; Storage space for old XMS-handler. The first byte stores WHETHER there
; was an XMS handler already (that didn't provide UMB services).
; The next two words specify its location.


isoldx  db      00h


oldxms  label word
dw ?,?


;------------------------------------------------------
; This is the small XMS manager that we install. It will only react
; to requests for UMBs (so when AH=10h). If not, it *should* pass
; control to the existing XMS manager - provided there is one. Or
; otherwise inform the caller that there is no eXt memory.


assume es:nothing, ds:nothing


umbctrlr:


jmp     short hookch            ;MUST be a *short* jmp
nop                             ; The nops are there because
nop                             ; a himem handler always start
nop                             ; with 5 special bytes.


hookch: pushf
cmp     ah, 10h                 ;is it a UMB request?
je      umbreq                  ;  yes: execute it
cmp     [isoldx], 0h            ;  no: is there an XMS-handler?
jz      Xreq1                   ;     no: give response like it
popf                            ;     yes: jump to old handler
jmp     dword ptr cs:[oldxms]


; Below is the code that will respond to non-UMB (and thus XMS-)
; requests when no XMS-manager is present. To nearly all requests
; (there are 11h) it will answer with AX=0000, meaning failure
; and BL=80, which gives the errormessage: not implemented.
; Only fns 00h and 08h are treated specially (as well as fn 10h, but
; that has been filtered out above - it's the UMB-request).


Xreq1:  cmp     ah, 0h                  ;req 00h = get XMS version
jnz     Xreq2
mov     bx, 0h                  ; ->internal revision nr=0
mov     dx, 0h                  ; ->HMA not present
jmp     short byebye


Xreq2:  cmp     ah, 08h                 ;req 08h = query extended mem
jnz     Xreq3
mov     dx, 0h                  ; ->0k extended memory


Xreq3:  mov     bl, 80h                 ; ->error: not implemented


byebye: mov     ax, 00h                 ; ->failure (always the case)
popf
retf


;------------------------------------------------------
; Storage space for old interrupt vector 2f


old2f   label   word
dw      ?,?


;-------------------------------------------------------
; This is the code that is chained to the front of interrupt 2f.
; It will handle requests nrs. 4300 and 4310, and leave all others
;    to the existing code.


handl:  pushf


cmp     ah, 43h                 ;is request for HIMEM?
jne     not4me                  ; no: pass on


cmp     al, 10h                 ; is request: where is handler?
jne     mustbe                  ;    if not, then must be al=00


mov     bx, offset umbctrlr     ; put handler's ofs in bx
push    cs                      ; and its segment
pop     es                      ; in es
jmp     short getout


mustbe: mov     al, 80h                 ;al <>10 so must be 00, so request
;is: is there handler? Yes => 80h
getout: popf
iret


not4me: popf                            ;request wasn't for me
jmp     dword ptr cs:[old2f]    ;so give back to old handl


;=================================================================
;
; NON-RESIDENT PART
;
; The part that follows now will not remain resident. It will be
; executed only once: at the time the driver is installed by
; DOS' bootprocedures.
;
; This code takes care of (1) hooking our intercepting code to
; int 2f, (2) hooking our small XMS-manager to the already installed
; one - provided there is one, (3) and if not, installing the
; the response-robot that will inform callers that there's no eXt
; memory.
;


;-------------------------------------------------------
; Installation routine. Called once.


assume  ds:zwetsUMB, es:rh




inst:   push    cx                      ;save em
push    dx
push    ds


push    cs                      ;and set ds to cs
pop     ds


mov     ah, 09h
mov     dx, offset hello1$      ;say welcome
int     21h
mov     dx, offset empty$
int     21h
mov     dx, offset hello2$
int     21h
mov     dx, offset empty$
int     21h
mov     dx, offset hello3$
int     21h
mov     dx, offset hello4$
int     21h
mov     dx, offset empty$
int     21h
mov     dx, offset autho1$
int     21h
mov     dx, offset autho2$
int     21h
mov     dx, offset empty$
int     21h


mov     ax, 4300h               ;check if there is an XMShandler
int     2Fh                     ;already
cmp     al, 080h                ;is it there?
jne     SetVec                  ;  no: go further


mov     [isoldx],01h            ;signal yourself there is one
mov     ax, 4310h               ;get its address
int     2Fh
mov     [oldxms], bx            ;and store it
mov     [oldxms+2], es


mov     ah, 09h                 ;tell user
mov     dx, offset found$
int     21h
mov     dx, offset empty$
int     21h


mov     ah, 10h                 ;check if it services UMBs by
mov     dx, 0FFFFh              ;trying to allocate FAR TOO much
call    dword ptr [oldxms]
cmp     bl, 80h                 ;error: not implemented?
jz      SetVec                  ; then good - continue


mov     ah, 09h                 ;otherwise: get off,
mov     dx, offset oops$        ;you're not needed.
int     21h
les     bx, dword ptr [hdrptr]
xor     ax,ax
mov     es:[bx].rh0_brk_ofs, ax
jmp     short dexit


SetVec: mov     ax, 352Fh               ; get vector 2f
int     21h
mov     [old2f], bx             ;and store it
mov     [old2f]+2, es


mov     ax, 252Fh               ;set it to our own
mov     dx, offset handl
int     21h


mov     ah, 09h
mov     dx, offset instok$      ;say we did it
int     21h


mov     ax, offset inst         ;upto inst it should stay
les     bx, dword ptr [hdrptr]  ;  resident, which we tell
mov     es:[bx].rh0_brk_ofs, ax ;  dos via the rqhdr.
xor     ax,ax                   ;0 no errors


dexit:  pop     ds
pop     dx
pop     cx
jmp     exit


hello1$ db  0Dh,0Ah,'ÕÍÍÍÍÍÍÍÍÍÍÍÍÍÍµ   Use!UMBs   ÆÍÍÍÍÍÍÍÍÍÍÍÍÍ¸',0Dh,0Ah,'$'
empty$  db          '³                                           ³',0Dh,0Ah,'$'
hello2$ db          '³        Upper Memory Block - Manager       ³',0Dh,0Ah,'$'
hello3$ db          '³   Works on any PC/XT/AT, either with or   ³',0Dh,0Ah,'$'
hello4$ db          '³    without Extended or Expanded Memory!   ³',0Dh,0Ah,'$'
found$  db          '³     * found extended memory manager *     ³',0Dh,0Ah,'$'
autho1$ db          '³        Author: Marco van Zwetselaar       ³',0Dh,0Ah,'$'
autho2$ db          "³   dedicated it to the Public Domain 1991  ³",0Dh,0Ah,'$'
instok$ db          'ÔÍÍµ Version 2.0 ÆÍÍÍÍÍÍÍÍÍÍµ Installed! ÆÍÍ¾',0Dh,0Ah,0Ah,'$'
oops$   db          'ÔÍµ Not Installed!  UMBs Managed Already! ÆÍ¾',0Dh,0Ah,0Ah,'$'


zwetsUMB   ends
end

What is happening with Norton Commander is even more confusing because I can't really see what is happening there. The program opens and shows the directory windows as expected, however it's not possible to do any operations in the program. However it's not frozen or anything, I can hear some sounds while pressing keys on the keyboard. Only after further crashing I saw the PC finally halted.

The schematic is here in the root directory so you can see there how I have done this design.
If you need me to explain anything please let me know.

Functionally it's the same as a Turbo XT PC, and there is no PC chipset present, it's all done in logic ICs.

The turbo mode should be enabled at POST, which is done by outputting PB2 to high level in my hardware. This also lights up the turbo LED
I believe this is somewhat standard because it worked on the phatcode BIOS without any modification.

I have done further testing by including the HD floppy BIOS into my EPROM image, and this now works properly to read, write and format all types of floppy disks. Nice to see that the HD floppy BIOS seems to work better with the GLaBIOS and nice to see the two floppy drives detected message. Switching between the HD and DD floppy BIOS also can be seen in the BIOS messages to change the floppy drive type.

The program TEST!UMB.EXE from the same maker as USE_UMBS.SYS does indicate it finds RAM at "paragraph" D000 until EFFF, only the USE_UMBS.SYS doesn't initialize any UMB blocks anymore.

I have tested by disabling the UMBs by removing the jumpers, this does not change anything with the Norton Commander problem.
I have tested with MSD which does not complete the "examining your system" phase.

What I know about the Norton Commander is that it needs at least a V20 CPU to function.
Using an 8088, Norton Commander doesn't work.

Turbo switching works properly, I have tested this with a CPU speed test, and I also can see the LED go on and off which definately also shows that the fast CPU clock is switched on and off properly. The default to enable turbo mode is also correct at power on.

The LAN adapter, SCSI disk and CDROM access and windows 3.0 all work properly.

So at the moment I am only experiencing problems with the TOGGLE.COM program, Norton Commander and USE_UMBs.SYS.
Also, MSD doesn't seem to complete its examination of the system and keeps flashing the message it's still examining.

I am using the file "GLABIOS_0.2.4_VT.ROM" in my tests.

If you have any questions, please feel free to ask me.

Thanks for offering your help, I appreciate it very much.

Rodney

640-KB · 2023-07-03T15:47:46Z

Hi Rodney,

Thanks for all of the info. So, to summarize the issues:

High density floppy support. Yes, that's correct, HD floppy support just isn't practical to fit into an 8KiB BIOS and so you generally either have a floppy controller with an external BIOS (like Multi-Floppy or a vintage DTK or something such) or there are TSRs are well. https://github.com/640-KB/GLaBIOS/wiki/High-Density-Floppy. This is actually something I've had on my list for a while to make an option ROM for it, however not very high since it would effectively be what Multi-Floppy does and that works well and is so widely used.
Enhanced keyboard support. All of those things you describe are the expected behavior when using an enhanced keyboard with a BIOS with standard XT support. The way IBM did it for backward compatibility is that all of those additional keys added in the 101 keyboard work but aren't treated any differently than the related keys on the original XT 83 keys, so the dedicated arrow keys duplicate the numeric arrow keys and the right-side left/right ctrl and alt keys are the same as the left side one. The function of the lights is also part of the enhanced keyboard support (though some adapters like the AT2XT can attempt to emulate that behavior as well). The only 8 KiB XT BIOS I know of that implements enhanced keyboard is the Turbo/Anonymous one -- IBM's 1986 and 8088_bios do as well though are 16 KiB. All that said - implementing that is something that's been on my list (Enhanced/Extended (101-key) keyboard support 640-KB/GLaBIOS#10) though again still lower just because it hasn't really come up too much in terms of being asked for. Now... this might just be the reason to go ahead and push forward on it so maybe now is the time to revisit it! :)
UMA: That one is a big perplexing to me since I use USE!UMBS is used a lot with GLaBIOS on new hardware (micro_8088/NuXT), vintage (Turbo XT's with UMB memory cards) and emulators. On an XT it's just that the BIOS really had no touch points to UMA since it's just address space in the hardware that gets utilized by DOS after boot... so I'm a bit at a loss at the moment (especially since this is the first report of it not working). Can you take some screenshots of exactly what error it reports, maybe we can start from there?
Norton Commander/MSD: Also a little bit of a mystery because I've used both of those myself and have spoken to others that have also. Can you tell me the exact versions of both that you are using, so I can try to replicate?

Can you tell me everything you are using on yours: like CPU, clock speed, video adapter, DOS version, etc? I just want to get as close as possible to your setup. Also, the GLABIOS_0.2.4_VT.ROM is dated 04/11/2023 right?

Thanks for all of the feedback and reports. I'm sure we can get this all worked out!

640KB

rodneyknaap · 2023-07-03T18:42:27Z

Hi 640KB,

Thanks for your reply.

About HD floppy drives, that's up to you if you want to dive into that issue. Though if you did get around to it, you could do pretty much anything in terms of how you wish to implement it. Basically that's why I did my own XT design, so I can implement it in the best way according to my own perspective on the matter. I imagine when programming, that could be a great challenge and liberty of the programmer.
This aspect is however solvable by adding Sergey's HD floppy BIOS to the ROM. There is plenty of space, so not a problem.

I never checked the Super PC/Turbo XT BIOS source code to check whether they have special support for an "enhanced keyboard". I never researched into keyboard support though I did pick up bits of information as I was developing the project. My dipswitch on the bottom of my keyboard notes "PC/XT" next to the setting, I wonder if there is actually any difference between my keyboard in XT mode and an actual XT-only keyboard.

About expected behaviour, that is not exactly the way I see it, since I had the experience of this functioning before, I was expecting to see no difference when testing the GLaBIOS. Probably when studying the phatcode sources there could be a clue for the reason. I really can't solve this or point to the reason because I have zero PC programming experience unfortunately, I would love to help but in a programming matter I can't at the moment. Though if the TOGGLE.COM program can't work, since my keyboard works fine otherwise in all conditions so far, it's not really a big deal for me to prevent me from using your BIOS. On the other hand, since the PC is a standard, I think there is value to be found in adhering to the standard as closely as possible. Compatibility is a big thing with PCs. I know your work is super complicated, I saw the platforms you are supporting which is surely a huge work and accomplishment to do it, I definately can appreciate that! I can ignore the TOGGLE.COM problem if otherwise all keyboard functions are supported just like in the phatcode BIOS.

About the UMB driver, this is however an important issue and a problem. I have studied the source code comments of USE!UMBS which I quoted to you and I am seeing that the driver is answering certain types of system calls to be able to provide UMB memory to any program which tries to request it. I think the source code will have more resonance with you than with me at this moment since you are regularly programming in assemby with much experience of course. Understanding code is certainly much easier for you. I am not sure how much of these calls are hooking into BIOS routines at the machine level and how much is hooking into the DOS components which are running in memory after booting, so in the operating system level. Or perhaps both are involved. I don't have any programming experience and certainly not a full understanding of the DOS environment such as software interrupts, system calls etc., though of course it's incredibly interesting none the less because these things are heavily involved in the functioning of a PC, and also reflect the brilliance of IBM engineers of the PC project. I am not a programmer so I can't solve this matter myself. I hope one day I may find the time to get into deeper programming work in assembly for PCs, super interesting and attractive!

What I am doing with the UMB memory blocks is however my field of expertise and really simple and straightforward work. I simply made the memory decoding logic to provide 128KB of RAM in the D0000-EFFFF area of the CPU memory map. My second RAM has even more areas available, if I wanted to enable those, I could have but the area is often occupied by expansion cards so I left it alone. Basically there is 1MB of RAM on my mainboard of which only 768KB is used. In this respect it couldn't be simpler, there is no page translation going on or dynamic loading or anything, simply static memory which is present in a fixed area. The D0000 until EFFFF is mostly free unless the user installs some kind of EMS card. Of course, the complexity in using UMBs is occurring in the DOS handling of this RAM to provide UMB memory, which is a software matter. However in the phatcode BIOS it is working. Also here there is a difference in function, which must have a reason for it. I am hoping it is an issue which can be resolved.

Not having UMBs is really a big deal for me because it disables a part of my mainboard design. I can't skip over this point. I changed the BIOS and I am seeing no UMB memory. The driver is however loaded into memory. So the cause must be found in the BIOS code. I also realise that the USE!UMBS driver is not entirely a finished well rounded software at any level such as your BIOS, however it does work with the phatcode BIOS, so there must be some difference in the GLaBIOS preventing it to work.

My mainboard is not functionally that different from other XT PCs which do not use chipsets. The mainboard is not odd or different in any way from the design perspective. It is most closely similar to the Taiwanese clone XT mainboards, except there is no refresh and parity checking going on. I would argue that chipset mainboards could be much more different from the original XT than my design since the chipset manufacturer may be integrating various registers for configuration which might alter the configuration. In fact, for the most part my mainboard functions the same as any original XT. I was careful in my research and design to make sure of this for compatibility reasons. The only difference in function is where I added extra things, such as the UMB RAM, which have been reliably tested with the phatcode BIOS since my first revision. After getting it to work, it never failed to function. What I did find is that if you try to load less UMB for example only 64KB, it doesn't work. But today I found a clue to this because the size seems fixed to 128KB in the source code, which is also what I seemed to observe before.

What I am using is

a Video7 VGA adapter flashes Wang message in colors at power on, V1.14, headland GC205-PC.
clock speed of the CPU is 8Mhz
DOS version is MS-DOS 6.22
I used the BIOS at your github release section from this link:
https://github.com/640-KB/GLaBIOS/releases/download/v0.2.4/GLABIOS_0.2.4_VT.ROM

From my intuition, I would say that the initialization of MSD doesn't happen because of 2 possible reasons:

The UMB area is there but not being fully hooked into the system calls or not hooked in the proper way.
a different, similar problem to what is happening with Norton Commander. Both do not work but the PC is not exactly frozen either.

Norton commander starts, but then doesn't respond to anything, it's just sitting there, and when typing keys I hear some slight beeping on the speaker which confirms that the keyboard is sending scancodes and those are not accepted by the PC it seems. Also there is a mouse cursor on Norton Commander, but clicking anything doesn't result in any response of the Norton Commander screen.

Norton Commander is version 5.0, the date in the help file is may 5th, 1993.

I also hope you can work everything out so I can use your GLaBIOS as my "daily driver" BIOS on my XT!
I appreciate anything you could do, and keep wishing I have some programming experience so I can help you in troubleshooting this.

Kind regards,

Rodney

rodneyknaap · 2023-07-03T18:56:42Z

Hi 640K,

I just did some more testing, and when bypassing config.sys, I can at least load MSD.EXE normally.
So that would indicate that the USE!UMBS driver which is loaded into memory but not providing any actual UMBs is the reason for MSD,EXE not fully loading. So that is a matter you can ignore since it is likely to be resolved when the UMB area is functional.

I have tested Norton Commander with FreeDOS which shows the same problem, no response from keyboard or mouse, but I am hearing soft key beeps from the speaker. If I keep typing a lot, there will be a system halt and I need to reset to get out of it, CTRL-ALT-DEL is not working then anymore. Before the system halt I can CTRL-ALT-DEL to get out of Norton Commander.

Kind regards,

Rodney

rodneyknaap · 2023-07-03T19:35:51Z

Hi 640K,

I have burned an EPROM with a Phoenix XT BIOS Version 2.27 from 1986 after I prepared a 5,25 inch DD boot floppy and wired the floppy drive as A:.

What I found is that the USE!UMB driver works properly with this Phoenix BIOS, which is the same as with the phatcode BIOS.

On the other hand, the TOGGLE.COM doesn't work properly with the Phoenix BIOS either. So it seems that only the phatcode implements the keyboard in a way which is compatible with TOGGLE.COM.

It's a little hard to test with the Phoenix BIOS which is extremely limited, I only can access a DD floppy disk.
And I need to swap the floppy cable and the BIOS chip to be able to add files on the floppy disk.
XT-IDE and the HD floppy BIOS are not initialized.
I will attempt to test Norton Commander but I am not sure the DD floppy disk has sufficient space, probably not.

I received this Phoenix BIOS on my example Taiwanese XT mainboard when I bought it.

Kind regards,

Rodney

rodneyknaap · 2023-07-03T20:00:08Z

Hi 640KB,

I just tested Norton Commander with the Phoenix XT BIOS by swapping the boot floppy disk, and I found it also is not able to be operated with the keyboard. I am also hearing soft beeps when typing various keys trying to exit Norton Commander.

So this issue also exists in the Phoenix BIOS. It's pretty strange because as I saw before, the mouse cursor is moving on the screen, but clicking on exit doesn't exit the program. So it's not purely related to keyboard control in this case, the program is simply sitting there and not responding. When typing random keys, suddenly Norton Commander popped up a dialog saying it can no longer read the disk. So it seems to be not functional in various levels including no longer being able to access a floppy disk.

Kind regards,

Rodney

640-KB · 2023-07-04T01:54:38Z

I just did some more testing, and when bypassing config.sys, I can at least load MSD.EXE normally.
So that would indicate that the USE!UMBS driver which is loaded into memory but not providing any actual UMBs is the reason for MSD,EXE not fully loading. So that is a matter you can ignore since it is likely to be resolved when the UMB area is functional.

Yeah, I get the feeling that there's probably a series of issues one leading to the next, and when we figure out the root one everything will work just right! :) I'm going to work on setting up both a real hardware and an emulated setup as similar to yours as possible and see if perhaps I can reproduce this.

Could you try using the 8088 build of the same version and see if you get the same? It's not very different but just want to eliminate a possibility that the VT ROM may be a bad build or something...

https://github.com/640-KB/GLaBIOS/releases/download/v0.2.4/GLABIOS_0.2.4_8T.ROM

Thanks so much for all of the rest of the info - I'll do some digging on this and see what I can come up with.

640KB

rodneyknaap · 2023-07-04T08:29:58Z

Hi 640KB,

I have tested the Standard Turbo 8088 version you mentioned, the UMB support is also not working in that version.
Just like on the V20 version, the driver loads as a TSR however doesn't provide any UMB memory.

Additionally, this 8088 version reports a POST error 400 - DMA.
After the error there is a normal boot from XT-IDE however.
I have tested DMA and verified that DMA is working properly without any problems.
On a warm reboot there is no DMA POST error reported until I reset the PC.

I have another comment/request.
In my ATX XT mainboard Revision 3 project I am attempting to offer the most complete XT experience.
What I mean is to include everything possible.

I noticed in your source code that somewhere there are notes about when using the 5150 with tape support, other functions would be disabled to stay within the 8kb limit.

I understand the necessity in case of the 5150, however since my design has 64kb of ample ROM space, I would appreciate to have all the functions available without needing to exclude certain things to save space. In fact, I would rather have a 16kb GLaBIOS if that meant I would have more functions and a more elaborate BIOS. More would be better!

I am also very interested in your GLaTICK project and have plans to include it in the future.
But first I will need to make a test adapter card which is on my future todo list.

If you need me to do something on my system, feel free to ask.
Such as creating some kind of memory dump or doing something in debug if that would be helpful.

Thanks again,

kind regards,

Rodney

640-KB · 2023-07-04T16:55:29Z

Thanks for trying that other rom at least - just trying to eliminate things.

I'll take you up on the memory dump if that's no trouble. Possible to do one with GLaBIOS and one with another bios to compare?

Can you do a screenshot or give me the exact error the UMB driver gives? Want to make sure I can see the same exact message if I can reproduce it.

Thanks!

640-KB · 2023-07-05T19:07:50Z

Hi Rodney,

Want to try to eliminate a few things so made this build that may shed some additional info:

GLABIOS_0.2.5_VT_RK1.zip

Would you mind trying this one? Also, is it possible to use a different EPROM than you were before for the other GLaBIOS? Again, trying to eliminate things...

640-KB · 2023-07-05T19:23:39Z

And to confirm you are using CLEARMEM.SYS before USE!UMBS.SYS and same result both ways?

rodneyknaap · 2023-07-05T19:50:38Z

Hi 640KB,

I have a large number of Texas Instruments 1Mbit EPROMs I am using, a blank one for each test. Those EPROMs are high quality and most only programmed once when new. And my programmer is a professional one, Galep-III, it always verifies after an EPROM burn. In other words, the EPROM being the problem is 100% surely not going to be a factor, so let's skip that.

The method I am loading USE!UMBS.SYS with is 100% verified and I am using it for almost a year. Yes, first CLEARMEM.SYS, then USE!UMBS.SYS, that's correct.

Only after swapping in the GLaBIOS I am experiencing problems. When using the Phoenix BIOS, UMB is working again. In short, the problem is definately in the BIOS. I know it's puzzling, to me too. There is no factor changing, only the BIOS. It must be in the BIOS can be the only conclusion because no other factor changed. Perhaps it's something obscure. I have no clue in what direction to search.

I will test that BIOS as well and report back here.

I thought dumping memory in DEBUG.EXE would be easy but I found it's too limited.
I searched for a while to find a program and method but so far no good one.
How do you recommend I do a memory dump?
I will keep looking I also have a large number of DOS utils which I am searching through.

Kind regards,

Rodney

rodneyknaap · 2023-07-05T20:02:01Z

Hi 640KB,

Thanks for making this 0.2.5 version BIOS, I really appreciate your work.

Unfortunately still the same result, I keep hoping it will work and we can move beyond the UMB stuff.

I will keep searching for a memory dump method and dump it when I found one.
I want to dump the entire 1MB memory space of the V20 CPU.

Kind regards,

Rodney

640-KB · 2023-07-05T21:49:28Z

Rodney,

I wrote a quick little program that should dump the entire memory address space into a file called MEMDUMP.BIN:

MEMDUMP.zip

Would it be possible to send me copies of USE!UMBS.SYS and CLEARMEM.SYS that you are using and also the corresponding lines in your CONFIG.SYS? Are you using DOSMAX or SHELLMAX after it? What does MEM /C report for upper memory?

And just want to make sure, when USE!UMBS loads during boot it appears to be working correctly (gives no error or anything) but using any UMBs result in the machine just locking up?

Or do you perhaps have a bootable disk image with everything that you could post and share?

640-KB · 2023-07-06T02:43:23Z

Last thought of the night... are you using the 2.2 version of USE!UMBS with all of the fixes from Krille? (The source code version you posted above was for the old 2.0 version). If not, can you give it a try so we're both using the same?

USEUMBS22.ZIP

rodneyknaap · 2023-07-06T08:48:16Z

Hi 640KB,

Thank you for your updates. By the way I love it that your new BIOS is showing more info about the HD Floppy BIOS!
This kind of thing I really like, very professional information.

Great program your memdump, I will attach a few dumps following this message with the relevant information per dump.

I will post my config.sys and autoexec.bat so you can see the details.

When I load USE!UMBS.SYS it loads normally and does not report any errors.
I have tested with the 2.2 version, it's the same result, loads normally but no UMBs in MEM/C.

I just cleaned up my config.sys and I discovered a problem, I cannot use the keyboard to select blocks of text in DOS EDIT.
When I hold down SHIFT and use the cursor keys, the cursor moves but no text is being selected/highlighted.
Using the mouse, I can see the selection highlighting happening and EDIT functions as normal.

Kind regards,

Rodney

rodneyknaap · 2023-07-06T09:02:44Z

Hi 640KB,

My first test is with the 0.2.5. BIOS, with the following config.sys and autoexec.bat:

CONFIG.SYS:

DOS=UMB
DEVICE=C:\DOS62\CLEARMEM.SYS D000 2000
DEVICE=C:\DOS62\USEUMB22.SYS D000-F000
BUFFERS=20
FILES=40
STACKS=12,256
LASTDRIVE=Z
DEVICE=C:\DOS62\DOSMAX.EXE /H+ /P- /R-
SHELL=C:\COMMAND.COM /E:512 /P
REM COREL SCSI DRIVER FOR NCR 53C400
DEVICEHIGH=C:\DOS62\ASPILS_D.SYS 
REM ADAPTEC ASPI SCSI FIXED DISK DOS VOLUME DRIVER
DEVICEHIGH=C:\DOS62\ASPIDISK.SYS
REM COREL UNIVERSAL ASPI CDROM DRIVER
DEVICEHIGH=C:\DOS62\CUNI_ASP.SYS /D:MSCD001

AUTOEXEC.BAT:

@ECHO OFF
PATH C:\DOS62;C:\NORTON;C:\WINDOWS;C:\NET;C:\TSCSI
SET SOUND=C:\SBPRO
SET BLASTER=A220 I7 D1 T4
C:\SBPRO\SBP-SET /M:12 /VOC:12 /CD:12 /FM:12 /LINE:12
LH C:\DOS62\CTMOUSE.EXE
REM XT KEYBOARD CAPSLOCK AND NUMLOCK (LEDS NOT SUPPORTED)
REM C:\DOS62\TOGGLE.COM /C+ /N+
REM LOAD CD IF CONNECTED TO SCSI
LH C:\DOS62\MSCDEX.EXE /D:MSCD001 /L:K 
SET COMSPEC=C:\COMMAND.COM
LH C:\DOS62\DOSKEY.COM

REM GOTO END
REM INITIALIZE MTCP LAN PACKET DRIVER
LH C:\DOS62\PNPPD.COM
REM PORT 340 IRQ3 
SET MTCPCFG=C:\DOS62\MTCP.CFG
C:\DOS62\DHCP.EXE

REM XT SYSTEM CLOCK SET BY SNTP 
SET TZ=UTC-1CDT
REM C:\DOS62\SNTP -SET pool.ntp.org
C:\DOS62\SNTP -SET pool.ntp.org
REM ntp1.nl.net

REM DHCP RENEW LEASE WITH CORRECT TIME
C:\DOS62\DHCP.EXE

:END

Result from MEM /C:

Modules die geheugen gebruiken onder 1 MB:

  Naam          Totaal       =   Conventioneel  +   Upper Memory
  --------  ----------------   ----------------   ----------------
  MSDOS       67,005   (65K)     67,005   (65K)          0    (0K)
  USEUMB22       208    (0K)        208    (0K)          0    (0K)
  ASPILS_D     3,824    (4K)      3,824    (4K)          0    (0K)
  CUNI_ASP    24,944   (24K)     24,944   (24K)          0    (0K)
  COMMAND      5,520    (5K)      5,520    (5K)          0    (0K)
  CTMOUSE      3,104    (3K)      3,104    (3K)          0    (0K)
  MSCDEX      27,952   (27K)     27,952   (27K)          0    (0K)
  DOSKEY       4,144    (4K)      4,144    (4K)          0    (0K)
  PNPPD        4,672    (5K)      4,672    (5K)          0    (0K)
  Beschikb   513,824  (502K)    513,824  (502K)          0    (0K)

Geheugensamenvatting:

  Geheugentype       Totaal    =  Gebruikt  +    Vrij
  ----------------  ----------   ----------   ----------
  Conventioneel        655,360      141,536      513,824
  Upper                      0            0            0
  Gereserveerd               0            0            0
  Extended (XMS)             0            0            0
  ----------------  ----------   ----------   ----------
  Totaal geheugen      655,360      141,536      513,824

  Totaal onder 1 M     655,360      141,536      513,824

  Maximum omvang uitvoerbaar programma          513,472   (501K)
  Maximum beschikbaar upper memory block              0     (0K)

I am including the memory dump and the drivers you mentioned.
MEMDUMP.zip
CLEARMEM USEUMB22.zip

(I renamed USE!UMBS.SYS version 2.2 to USEUMB22.SYS because I want to keep the previous ones for testing and comparison.

As I wrote, USE!UMBS just shows the load message and on the bottom right of the message it writes "Installed!".
And it reports no upper memory with MEM /C.

For my next test I will boot the same configuration, after only swapping the BIOS EPROM, everything else will be exactly the same.

Kind regards,

Rodney

rodneyknaap · 2023-07-06T09:16:40Z

Hi 640KB,

Here is the result of my test, same as previous configuration files, except this time with the phatcode XT BIOS:

MEM /C output:

Modules die geheugen gebruiken onder 1 MB:

  Naam          Totaal       =   Conventioneel  +   Upper Memory
  --------  ----------------   ----------------   ----------------
  MSDOS       47,773   (47K)     47,773   (47K)          0    (0K)
  USEUMB22       256    (0K)        256    (0K)          0    (0K)
  COMMAND      5,520    (5K)      5,520    (5K)          0    (0K)
  DOSMAX         240    (0K)          0    (0K)        240    (0K)
  ASPILS_D     3,824    (4K)          0    (0K)      3,824    (4K)
  CUNI_ASP    24,992   (24K)          0    (0K)     24,992   (24K)
  FILES        2,096    (2K)          0    (0K)      2,096    (2K)
  FCBS           272    (0K)          0    (0K)        272    (0K)
              10,656   (10K)          0    (0K)     10,656   (10K)
  LASTDRIV     2,304    (2K)          0    (0K)      2,304    (2K)
  STACKS       3,824    (4K)          0    (0K)      3,824    (4K)
  INSTALL        160    (0K)          0    (0K)        160    (0K)
  CTMOUSE      3,104    (3K)          0    (0K)      3,104    (3K)
  MSCDEX      27,952   (27K)          0    (0K)     27,952   (27K)
  DOSKEY       4,144    (4K)          0    (0K)      4,144    (4K)
  PNPPD        4,672    (5K)          0    (0K)      4,672    (5K)
  Beschikb   644,464  (629K)    601,600  (588K)     42,864   (42K)

Geheugensamenvatting:

  Geheugentype       Totaal    =  Gebruikt  +    Vrij
  ----------------  ----------   ----------   ----------
  Conventioneel        655,360       53,760      601,600
  Upper                131,104       88,240       42,864
  Gereserveerd         262,112      262,112            0
  Extended (XMS)             0            0            0
  ----------------  ----------   ----------   ----------
  Totaal geheugen    1,048,576      404,112      644,464

  Totaal onder 1 M     786,464      142,000      644,464

  Maximum omvang uitvoerbaar programma          601,504   (587K)
  Maximum beschikbaar upper memory block         42,688    (42K)

MEMDUMP.zip

Kind regards,

Rodney

rodneyknaap · 2023-07-06T09:24:49Z

Hi 640KB,

When I power on my PC, the Turbo LED lights up, and Turbo speed is enabled.
Indeed, it's the same as the phatcode BIOS.

Since my XT PC is always on Turbo speed, I use the Turbo LED as the power LED.

When the LED is on, the faster clock signal is going into the CPU.

Kind regards,

Rodney

rodneyknaap · 2023-07-06T09:28:02Z

Hi 640KB,

Just for your peace of mind, with every new test, I am using a different EPROM which was before not used.

I will also browse through the phatcode.net BIOS source code to see if I notice anything remarkable.
Definately something is going on with the keyboard routines too since I am also noticing differences with the EDIT program.

Kind regards,

Rodney.

rodneyknaap · 2023-07-06T09:32:02Z

Hi 640KB,

I am seeing in my source code for the 3.1 version phatcode.net BIOS:

ENHANCED_KEYB = 1 ; Define for Int 9h enhanced (101-key) keyboard support

I am also seeing a SHIFT+ NAV KEYS fix since version 2:

* Optional define for 101-key keyboard shift+nav keys work-around (KEYB_SHIFT_FIX)
So that explains that my NAV keys in combination with SHIFT work with EDIT using the phatcode BIOS.

The support for enhanced keyboards is important, so I will be needing it in the future when you get around to it.
I would prefer it to have a 16kb BIOS rather than skipping/losing functionality for the sake of staying below 8k.
With the phatcode this is also an issue and compiling fails there on many tries to change options, but my mainboard has the whole F0000-FFFFF segment available in ROM space.

As I said, after I get around to testing, and tests are positive, I will be adding the GLaTICK BIOS image as well.

Kind regards,

Rodney

rodneyknaap · 2023-07-06T10:05:26Z

Hi 640KB,

The phatcode BIOS does contain some enhancements for UMBs specifically.

In other areas (such as the enhanced keyboard) I see that some functionality is enabled by default, even if the relevant compile option is not specified to be enabled before compiling. I didn't change any compile options regarding UMBs because it was working by default. In my BIOS, CLEAR_UMA was not enabled.
I will not get any parity errors because the parity circuits are not needed and removed from my design.

I suspect something is going on in the phatcode BIOS code related to UMB support and clearing, besides what CLEARMEM.SYS is doing.

I just tested with the phatcode BIOS, and even without using CLEARMEM.SYS, USEUMB22.SYS still installed correctly and the UMB memory is available and working properly. This may be also thanks due to the nature of using SRAM though.

Kind regards,

Rodney

640-KB · 2023-07-06T13:40:41Z

When I power on my PC, the Turbo LED lights up, and Turbo speed is enabled. Indeed, it's the same as the phatcode BIOS.

Since my XT PC is always on Turbo speed, I use the Turbo LED as the power LED.

When the LED is on, the faster clock signal is going into the CPU.

Okay great. Some boards read the turbo state from the PPI as the opposite - some say high as turbo speed and some say low is turbo speed... it just varies board to board. I've found most boards I've tested work the way yours does, so that's why it's set the way it is by default. Not related to anything else but just occurred to me to ask and make sure.

640-KB · 2023-07-06T13:50:04Z

Hi 640KB,

The phatcode BIOS does contain some enhancements for UMBs specifically.

In other areas (such as the enhanced keyboard) I see that some functionality is enabled by default, even if the relevant compile option is not specified to be enabled before compiling. I didn't change any compile options regarding UMBs because it was working by default. In my BIOS, CLEAR_UMA was not enabled. I will not get any parity errors because the parity circuits are not needed and removed from my design.

Yeah, the Phatcode BIOS does have a build-time option to clear memory in the UMA area to prevent parity errors, though it's disabled on the default build (which you said you were using). If it were enabled it would do exactly what CLEARMEM does (and the 2.2 version of USEUMBS also) where it clears the memory before reading too, so the Phatcode feature wouldn't be necessary anyway. Also, as you say you don't have parity checking anyway so it wouldn't ever make a difference. One of the things in that test version I sent you was that parity checking is entirely disabled so even if the board did trigger an NMI it wouldn't do anything... but that didn't change anything so can rule that out too.

The mystery here is the BIOS itself just has nothing at all to do with UMA... the driver just runs in DOS which reads/writes to the memory directly. There must just be something else in play where the UMA is the symptom not the cause. I've discussed this at length with several other experts and nobody can even come up with a theory yet... it's just going to be one of those really odd things where something unrelated leads to something else probably!

Thanks for sending those MEMDUMPs. I'll do a binary diff and see if there's anything significantly different between the two.

640KB

640-KB · 2023-07-06T13:58:13Z

Hi 640KB,

I am seeing in my source code for the 3.1 version phatcode.net BIOS:

ENHANCED_KEYB = 1 ; Define for Int 9h enhanced (101-key) keyboard support

I am also seeing a SHIFT+ NAV KEYS fix since version 2:

* Optional define for 101-key keyboard shift+nav keys work-around (KEYB_SHIFT_FIX) So that explains that my NAV keys in combination with SHIFT work with EDIT using the phatcode BIOS.

The support for enhanced keyboards is important, so I will be needing it in the future when you get around to it. I would prefer it to have a 16kb BIOS rather than skipping/losing functionality for the sake of staying below 8k. With the phatcode this is also an issue and compiling fails there on many tries to change options, but my mainboard has the whole F0000-FFFFF segment available in ROM space.

As I said, after I get around to testing, and tests are positive, I will be adding the GLaTICK BIOS image as well.

Kind regards,

Rodney

Yep, enhanced keyboard support has been on my TODO list for a while. If the BIOS has standard XT support only, the net effect is just going to be that the extra keys added between the XT 83 key keyboard and the 101 key (dedicated arrow keys, separate Insert, Home, etc) will behave as their standard equivalents rather than keys with different behaviors. So for the dedicated arrow keys they would just be read by the program as the numeric keypad arrows. That's just the way IBM designed the enhanced keyboard interface for the AT so as to be (mostly) backwards compatible with the existing base of computers. They eventually backported it into the final 1986 release of the XT BIOS. The only XT clone BIOS that I'm aware of that ever supported it (at the moment :) ) is the Phatcode one (which is something added to it in recent years).

Long story short, all of the behaviors you are seeing are what would be expected so we can come back to this once everything else is squared away!

640-KB · 2023-07-06T15:42:12Z

Do you have a bootable floppy with all of the UMB config.sys and your version of DOS that you've used to test before (such as the Phoenix test)? Could you image that and send it to me?

rodneyknaap · 2023-07-06T20:18:50Z

Hi 640KB,

I performed the test with your DD floppy disk.

The result is partial, it does create UMB memory, however not the full amount of 128KB.
It's around 92KB.

Here is the mem /c result:

Modules using memory below 1 MB:

  Name           Total       =   Conventional   +   Upper Memory
  --------  ----------------   ----------------   ----------------
  MSDOS        9,981   (10K)      9,981   (10K)          0    (0K)
  USE!UMBS       320    (0K)        320    (0K)          0    (0K)
  COMMAND      4,992    (5K)      4,992    (5K)          0    (0K)
  DOSMAX         240    (0K)          0    (0K)        240    (0K)
  FILES        1,504    (1K)          0    (0K)      1,504    (1K)
  FCBS           272    (0K)          0    (0K)        272    (0K)
  BUFFERS     10,656   (10K)          0    (0K)     10,656   (10K)
  LASTDRIV       720    (1K)          0    (0K)        720    (1K)
  INSTALL        160    (0K)          0    (0K)        160    (0K)
  Free       719,728  (703K)    639,984  (625K)     79,744   (78K)

Memory Summary:

  Type of Memory       Total   =    Used    +    Free
  ----------------  ----------   ----------   ----------
  Conventional         655,360       15,376      639,984
  Upper                 93,296       13,552       79,744
  Reserved             299,920      299,920            0
  Extended (XMS)             0            0            0
  ----------------  ----------   ----------   ----------
  Total memory       1,048,576      328,848      719,728

  Total under 1 MB     748,656       28,928      719,728

  Largest executable program size        639,968   (625K)
  Largest free upper memory block         79,744    (78K)

And the memory dump file of this test:
MEMDUMP.zip

Kind regards,

Rodney

rodneyknaap · 2023-07-06T20:28:32Z

Hi 640KB,

Since there was some UMB memory showing I decided to do a test with only USE!UMBS.SYS version 2.0 as included on the DD disk and indeed it is providing 128KB of UMB memory!

Here is the output of MEM /C:

Modules using memory below 1 MB:

  Name           Total       =   Conventional   +   Upper Memory
  --------  ----------------   ----------------   ----------------
  MSDOS       60,925   (59K)     60,925   (59K)          0    (0K)
  USE!UMBS       272    (0K)        272    (0K)          0    (0K)
  COMMAND      4,992    (5K)      4,992    (5K)          0    (0K)
  Free       720,112  (703K)    589,056  (575K)    131,056  (128K)

Memory Summary:

  Type of Memory       Total   =    Used    +    Free
  ----------------  ----------   ----------   ----------
  Conventional         655,360       66,304      589,056
  Upper                131,056            0      131,056
  Reserved             262,160      262,160            0
  Extended (XMS)             0            0            0
  ----------------  ----------   ----------   ----------
  Total memory       1,048,576      328,464      720,112

  Total under 1 MB     786,416       66,304      720,112

  Largest executable program size        588,992   (575K)
  Largest free upper memory block        131,056   (128K)

And I have attached the memory dump of this situation as well:

MEMDUMP.zip

I will do some follow up testing to see if this 2.0 version of USE!UMBS.SYS is working on my harddisk boot of DOS 6.22.

Kind regards,

Rodney

640-KB · 2023-07-06T20:30:11Z

Hi 640KB,

I performed the test with your DD floppy disk.

The result is partial, it does create UMB memory, however not the full amount of 128KB. It's around 92KB.

Here is the mem /c result:

Modules using memory below 1 MB:

  Name           Total       =   Conventional   +   Upper Memory
  --------  ----------------   ----------------   ----------------
  MSDOS        9,981   (10K)      9,981   (10K)          0    (0K)
  USE!UMBS       320    (0K)        320    (0K)          0    (0K)
  COMMAND      4,992    (5K)      4,992    (5K)          0    (0K)
  DOSMAX         240    (0K)          0    (0K)        240    (0K)
  FILES        1,504    (1K)          0    (0K)      1,504    (1K)
  FCBS           272    (0K)          0    (0K)        272    (0K)
  BUFFERS     10,656   (10K)          0    (0K)     10,656   (10K)
  LASTDRIV       720    (1K)          0    (0K)        720    (1K)
  INSTALL        160    (0K)          0    (0K)        160    (0K)
  Free       719,728  (703K)    639,984  (625K)     79,744   (78K)

Memory Summary:

  Type of Memory       Total   =    Used    +    Free
  ----------------  ----------   ----------   ----------
  Conventional         655,360       15,376      639,984
  Upper                 93,296       13,552       79,744
  Reserved             299,920      299,920            0
  Extended (XMS)             0            0            0
  ----------------  ----------   ----------   ----------
  Total memory       1,048,576      328,848      719,728

  Total under 1 MB     748,656       28,928      719,728

  Largest executable program size        639,968   (625K)
  Largest free upper memory block         79,744    (78K)

And the memory dump file of this test: MEMDUMP.zip

Kind regards,

Rodney

That's actually normal and expected once DOSMAX and SHELLMAX is loaded - and consistent with what I've always seen and lots of people have reported (https://forum.vcfed.org/index.php?threads/loading-dos-high-on-a-xt.32320/page-3#post-1293622). Those upper memory blocks are there and are being used but for whatever reason aren't reported in the total when they're used to move MS-DOS high.

If you compare this to the MEM /C's from that you posted earlier where it says 131,104 total, the size for MS-DOS is reported as 47,773 bytes whereas on this one it's reported as 9,981 bytes - which is the exact difference between the 131,104 and 93,296. So in that case I'm not sure if it's the version of DOS, or the specific versions of the other software you're using (DOSMAX/SHELLMAX) that accounts for that.

So this is very good news - we appear to have found something that changes the equation! If you could make me a bootable image of yours, I can cross-verify it and maybe then I can finally reproduce it and get to the answer once and for all!

640-KB · 2023-07-06T20:33:44Z

Hi 640KB,

Since there was some UMB memory showing I decided to do a test with only USE!UMBS.SYS version 2.0 as included on the DD disk and indeed it is providing 128KB of UMB memory!

Here is the output of MEM /C:

Modules using memory below 1 MB:

  Name           Total       =   Conventional   +   Upper Memory
  --------  ----------------   ----------------   ----------------
  MSDOS       60,925   (59K)     60,925   (59K)          0    (0K)
  USE!UMBS       272    (0K)        272    (0K)          0    (0K)
  COMMAND      4,992    (5K)      4,992    (5K)          0    (0K)
  Free       720,112  (703K)    589,056  (575K)    131,056  (128K)

Memory Summary:

  Type of Memory       Total   =    Used    +    Free
  ----------------  ----------   ----------   ----------
  Conventional         655,360       66,304      589,056
  Upper                131,056            0      131,056
  Reserved             262,160      262,160            0
  Extended (XMS)             0            0            0
  ----------------  ----------   ----------   ----------
  Total memory       1,048,576      328,464      720,112

  Total under 1 MB     786,416       66,304      720,112

  Largest executable program size        588,992   (575K)
  Largest free upper memory block        131,056   (128K)

And I have attached the memory dump of this situation as well:

MEMDUMP.zip

I will do some follow up testing to see if this 2.0 version of USE!UMBS.SYS is working on my harddisk boot of DOS 6.22.

Kind regards,

Rodney

I have a suspicion the difference is going to be between the versions of DOSMAX somehow. I might also suggest changing the REPORT parameter to /R+ since that will show more verbose information when it runs, and also remove the /H+ parameter because according to (https://www.pcorner.com/list/UTILITY/DOSMAX21.ZIP/DOSMAX.DOC/) that option is deprecated anyway.

rodneyknaap · 2023-07-06T20:55:37Z

Hi 640KB,

I just did some more testing with my C boot still using the 0.2.5 version of GLaBIOS, and I am now having UMB area with both the 2.0 version and 2.2 version of USE!UMBS.SYS.

And what's even more strange, I am no longer getting the DMA error 400 on the cold boots.

Somehow the problem seems to be gone for the moment, which I can't explain. I didn't modify anything on the PC, I only swapped in the EPROM with GLaBIOS 0.2.5 instead of the phatcode for testing.

So what I thought at first was something in the floppy disk boot, appears to be something different entirely.

Here is the MEM /C output of the C boot with USE!UMBS.SYS version 2.0 from the floppy disk image:

Modules die geheugen gebruiken onder 1 MB:

  Naam          Totaal       =   Conventioneel  +   Upper Memory
  --------  ----------------   ----------------   ----------------
  MSDOS       47,773   (47K)     47,773   (47K)          0    (0K)
  USEUMB20       320    (0K)        320    (0K)          0    (0K)
  COMMAND      5,520    (5K)      5,520    (5K)          0    (0K)
  DOSMAX         240    (0K)          0    (0K)        240    (0K)
  ASPILS_D     3,824    (4K)          0    (0K)      3,824    (4K)
  CUNI_ASP    24,992   (24K)          0    (0K)     24,992   (24K)
  FILES        2,096    (2K)          0    (0K)      2,096    (2K)
  FCBS           272    (0K)          0    (0K)        272    (0K)
              10,656   (10K)          0    (0K)     10,656   (10K)
  LASTDRIV     2,304    (2K)          0    (0K)      2,304    (2K)
  STACKS       3,824    (4K)          0    (0K)      3,824    (4K)
  INSTALL        160    (0K)          0    (0K)        160    (0K)
  CTMOUSE      3,104    (3K)          0    (0K)      3,104    (3K)
  MSCDEX      27,952   (27K)          0    (0K)     27,952   (27K)
  DOSKEY       4,144    (4K)          0    (0K)      4,144    (4K)
  PNPPD        4,672    (5K)          0    (0K)      4,672    (5K)
  Beschikb   644,384  (629K)    601,536  (587K)     42,848   (42K)

Geheugensamenvatting:

  Geheugentype       Totaal    =  Gebruikt  +    Vrij
  ----------------  ----------   ----------   ----------
  Conventioneel        655,360       53,824      601,536
  Upper                131,088       88,240       42,848
  Gereserveerd         262,128      262,128            0
  Extended (XMS)             0            0            0
  ----------------  ----------   ----------   ----------
  Totaal geheugen    1,048,576      404,192      644,384

  Totaal onder 1 M     786,448      142,064      644,384

  Maximum omvang uitvoerbaar programma          601,440   (587K)
  Maximum beschikbaar upper memory block         42,672    (42K)

And the memory dump as well:

MEMDUMP.zip

I'm perplexed about this, I will do more testing to see if I can discover anything.

Maybe there is some evidence in the comparison of the previous memory dumps, but I don't know where to look for it.

Kind regards,

Rodney.

640-KB · 2023-07-06T21:00:39Z

Hi 640KB,

I just did some more testing with my C boot still using the 0.2.5 version of GLaBIOS, and I am now having UMB area with both the 2.0 version and 2.2 version of USE!UMBS.SYS.

And what's even more strange, I am no longer getting the DMA error 400 on the cold boots.

Somehow the problem seems to be gone for the moment, which I can't explain. I didn't modify anything on the PC, I only swapped in the EPROM with GLaBIOS 0.2.5 instead of the phatcode for testing.

So what I thought at first was something in the floppy disk boot, appears to be something different entirely.

Here is the MEM /C output of the C boot with USE!UMBS.SYS version 2.0 from the floppy disk image:
Modules die geheugen gebruiken onder 1 MB:

  Naam          Totaal       =   Conventioneel  +   Upper Memory
  --------  ----------------   ----------------   ----------------
  MSDOS       47,773   (47K)     47,773   (47K)          0    (0K)
  USEUMB20       320    (0K)        320    (0K)          0    (0K)
  COMMAND      5,520    (5K)      5,520    (5K)          0    (0K)
  DOSMAX         240    (0K)          0    (0K)        240    (0K)
  ASPILS_D     3,824    (4K)          0    (0K)      3,824    (4K)
  CUNI_ASP    24,992   (24K)          0    (0K)     24,992   (24K)
  FILES        2,096    (2K)          0    (0K)      2,096    (2K)
  FCBS           272    (0K)          0    (0K)        272    (0K)
              10,656   (10K)          0    (0K)     10,656   (10K)
  LASTDRIV     2,304    (2K)          0    (0K)      2,304    (2K)
  STACKS       3,824    (4K)          0    (0K)      3,824    (4K)
  INSTALL        160    (0K)          0    (0K)        160    (0K)
  CTMOUSE      3,104    (3K)          0    (0K)      3,104    (3K)
  MSCDEX      27,952   (27K)          0    (0K)     27,952   (27K)
  DOSKEY       4,144    (4K)          0    (0K)      4,144    (4K)
  PNPPD        4,672    (5K)          0    (0K)      4,672    (5K)
  Beschikb   644,384  (629K)    601,536  (587K)     42,848   (42K)

Geheugensamenvatting:

  Geheugentype       Totaal    =  Gebruikt  +    Vrij
  ----------------  ----------   ----------   ----------
  Conventioneel        655,360       53,824      601,536
  Upper                131,088       88,240       42,848
  Gereserveerd         262,128      262,128            0
  Extended (XMS)             0            0            0
  ----------------  ----------   ----------   ----------
  Totaal geheugen    1,048,576      404,192      644,384

  Totaal onder 1 M     786,448      142,064      644,384

  Maximum omvang uitvoerbaar programma          601,440   (587K)
  Maximum beschikbaar upper memory block         42,672    (42K)
And the memory dump as well:

MEMDUMP.zip

I'm perplexed about this, I will do more testing to see if I can discover anything.

Maybe there is some evidence in the comparison of the previous memory dumps, but I don't know where to look for it.

Kind regards,

Rodney.

I'd suggest maybe try the version of DOSMAX (with the params I used) and SHELLMAX from my boot disk and see what that changes. Becoming more and more convinced that's the culprit!

rodneyknaap · 2023-07-06T21:04:00Z

Hi 640KB,

I have tested with USE!UMBS.SYS version 2.1, which is also now working with your GLaBIOS 0.2.5.
So apparently 2.0, 2.1 and 2.2 all work now.

I have no idea why before I was getting the DMA error 400 message on cold boot and now not anymore.
But it's possible that the symptoms of DMA error 400 and UMB not working have some kind of correlation.

I will do more testing with DOSMAX and SHELLMAX, I can integrate them into my C boot.
But I even turned off the PC and cold booted from the harddisk, both the DMA error 400 and the UMB problems have disappeared for the moment. I tried what I could to reproduce the UMB problem but so far I can't.

Kind regards,

Rodney

640-KB · 2023-07-06T21:09:22Z

I have tested with USE!UMBS.SYS version 2.1, which is also now working with your GLaBIOS 0.2.5. So apparently 2.0, 2.1 and 2.2 all work now.

I have no idea why before I was getting the DMA error 400 message on cold boot and now not anymore. But it's possible that the symptoms of DMA error 400 and UMB not working have some kind of correlation.

I will do more testing with DOSMAX and SHELLMAX, I can integrate them into my C boot. But I even turned off the PC and cold booted from the harddisk, both the DMA error 400 and the UMB problems have disappeared for the moment. I tried what I could to reproduce the UMB problem but so far I can't.

Interesting. I can't see how they would be related exactly, but that's also good that it stopped doing that! Can you post your DOSMAX/SHELLMAX for me? If I can reproduce the issue with those then I could maybe get to the bottom of what might have been throwing it off. :)

640-KB · 2023-07-06T21:30:52Z

I have no idea why before I was getting the DMA error 400 message on cold boot and now not anymore.
But it's possible that the symptoms of DMA error 400 and UMB not working have some kind of correlation.

What that error means is that after starting the DMA DRAM refresh at the beginning of POST, by the end the DMA controller had still not hit TC0 (which is should have by then). This is a self-test use in the original IBM BIOS to "verify that the TC0 status bit in the 8237 DMA controller chip is on" (https://minuszerodegrees.net/5160/post/5160%20-%20POST%20-%20Detailed%20breakdown.htm) and only performed on COLD boot. I also know that the Phatcode BIOS does not perform this test so that's why if it is an actual issue you might have never seen it before.

The reason you might not see it with the 0.2.5 build I sent us because it has DRAM refresh is disabled entirely including that test (since it's intended to check that the refresh is working properly).

Since you don't use DRAM refresh, do you have PIT channel 1 connected to DREQ0 on the DMA chip? If not, that means it wouldn't actually ever start the DMA and thus never finish so makes sense that it would never reach TC0!

rodneyknaap · 2023-07-06T22:15:53Z

Hi 640KB,

I was mistaken, I checked my previous messages.
Only the 8088 version of the 0.2.4 BIOS was reporting the DMA error 400.
Indeed because of the DMA cycle with the refresh logic not happening.

So it's indeed normal on this 0.2.5 BIOS that the DMA error is not showing.

About how my XT is wired,
timer channel 0 is connected to IRQ0 on the 8259, I think that's the system timer?
timer channel 1 output is not connected to anything. that's right.
There is only a signal label but no other connection in my design.

My mainboard works fine with the refresh turned off in the GLaBIOS 0.2.5 we are testing with.
I wonder, would that perhaps offer a performance increase to have no refresh happening in DMA channel 0 requests?
It would seem so.

I also tested the Trident VGA card which appeared to need refresh, but actually it only needs the DACK0 to be connected which is inactive state, logic level 1. So the Trident VGA only needs a DACK0 to be connected, but doesn't depend on DACK0 being actually active which is what I assumed before. Also a Realtek VGA card works fine as normal.

So I can confirm that the refresh not being active has no noticable effect at all.

Thanks for your very helpful comment about TC0, it also made me realise this fact and check with a scope that the DMA channel 0 is actually indeed inactive. DACK0 just stays inactive. Before I thought still something of a refresh might be happening in BIOS software. At the time I didn't have a scope yet and since I wasn't experiencing any problems, I didn't have any reason to check it.

I have done a thorough job of removing all refresh in logic, as I assumed those circuits are not needed. I am just glad that no other ill effects happened from these mods. At the time I always took into account that my design might have problems from doing that, but thankfully it never did. It's a nice feature to also have the refresh routines turned off in the BIOS.

However I am still thinking about the UMB problem which disappeared. It defies logic at this moment.
All I can do is keep testing however I can't reproduce the UMB problem so far.

Kind regards,

Rodney

640-KB · 2023-07-06T22:29:55Z

I was mistaken, I checked my previous messages. Only the 8088 version of the 0.2.4 BIOS was reporting the DMA error 400. Indeed because of the DMA cycle with the refresh logic not happening.

So it's indeed normal on this 0.2.5 BIOS that the DMA error is not showing.

About how my XT is wired, timer channel 0 is connected to IRQ0 on the 8259, I think that's the system timer? timer channel 1 output is not connected to anything. that's right. There is only a signal label but no other connection in my design.

My mainboard works fine with the refresh turned off in the GLaBIOS 0.2.5 we are testing with. I wonder, would that perhaps offer a performance increase to have no refresh happening in DMA channel 0 requests? It would seem so.

You'd normally notice a measurable speed bump with refresh disabled, though if the timer line isn't connected then the DMA wouldn't be starting, so in reality you've had that all along.

I also tested the Trident VGA card which appeared to need refresh, but actually it only needs the DACK0 to be connected which is inactive state, logic level 1. So the Trident VGA only needs a DACK0 to be connected, but doesn't depend on DACK0 being actually active which is what I assumed before. Also a Realtek VGA card works fine as normal.

So I can confirm that the refresh not being active has no noticable effect at all.

Thanks for your very helpful comment about TC0, it also made me realise this fact and check with a scope that the DMA channel 0 is actually indeed inactive. DACK0 just stays inactive. Before I thought still something of a refresh might be happening in BIOS software. At the time I didn't have a scope yet and since I wasn't experiencing any problems, I didn't have any reason to check it.

I have done a thorough job of removing all refresh in logic, as I assumed those circuits are not needed. I am just glad that no other ill effects happened from these mods. At the time I always took into account that my design might have problems from doing that, but thankfully it never did. It's a nice feature to also have the refresh routines turned off in the BIOS.

Glad to hear that we've at least solved one thing! We'll just remember to disable refresh for your builds which is normal for emulators and boards with SRAM. I may want to make another build for you at some point down that road to make it closer to standard since I had disabled a number of other things for testing, but that can wait until later.

However I am still thinking about the UMB problem which disappeared. It defies logic at this moment. All I can do is keep testing however I can't reproduce the UMB problem so far.

So have you gone back to your complete old configuration and versions and it isn't doing it now? I'd suggest just sticking with the newest USE!UMBS (2.2) and DOSMAX (2.1).

What's next? GLaTICK? Did you tell me what kind of RTC you have?

rodneyknaap · 2023-07-06T23:21:19Z

Hi 640K,

I just did some more testing and I found the problem was in the config files.
After restoring the previous files, I got the problem back.
After some tweaking I found the right configurations.

Just for good measure, here are the correct config files which work properly:

CONFIG.SYS:

DOS=UMB,HIGH
DEVICE=C:\DOS62\CLEARMEM.SYS D000 2000
DEVICE=C:\DOS62\USEUMB22.SYS D000-F000
BUFFERS=20
FILES=40
STACKS=12,256
LASTDRIVE=Z
REM DEVICE=C:\DOS62\DOSMAX.EXE /H+ /P- /R-
DEVICE=C:\DOS62\DOSMAX.EXE /P- /R-
SHELL=C:\COMMAND.COM /E:512 /P
REM COREL SCSI DRIVER FOR NCR 53C400
DEVICEHIGH=C:\DOS62\ASPILS_D.SYS 
REM ADAPTEC ASPI SCSI FIXED DISK DOS VOLUME DRIVER
DEVICEHIGH=C:\DOS62\ASPIDISK.SYS
REM COREL UNIVERSAL ASPI CDROM DRIVER
DEVICEHIGH=C:\DOS62\CUNI_ASP.SYS /D:MSCD001

AUTOEXEC.BAT:

@ECHO OFF
PATH C:\DOS62;C:\NORTON;C:\WINDOWS;C:\NET;C:\TSCSI
SET SOUND=C:\SBPRO
SET BLASTER=A220 I7 D1 T4
C:\SBPRO\SBP-SET /M:12 /VOC:12 /CD:12 /FM:12 /LINE:12
LH C:\DOS62\CTMOUSE.EXE
REM XT KEYBOARD CAPSLOCK AND NUMLOCK (LEDS NOT SUPPORTED)
REM C:\DOS62\TOGGLE.COM /C+ /N+
REM LOAD CD IF CONNECTED TO SCSI
LH C:\DOS62\MSCDEX.EXE /D:MSCD001 /L:K 
SET COMSPEC=C:\COMMAND.COM
LH C:\DOS62\DOSKEY.COM

REM GOTO END
REM INITIALIZE MTCP LAN PACKET DRIVER
LH C:\DOS62\PNPPD.COM
REM PORT 340 IRQ3 
SET MTCPCFG=C:\DOS62\MTCP.CFG
C:\DOS62\DHCP.EXE

REM XT SYSTEM CLOCK SET BY SNTP 
SET TZ=UTC-1CDT
REM C:\DOS62\SNTP -SET pool.ntp.org
C:\DOS62\SNTP -SET pool.ntp.org
REM ntp1.nl.net

REM DHCP RENEW LEASE WITH CORRECT TIME
C:\DOS62\DHCP.EXE

:END

The DOS=UMB,HIGH line if turned off disables the UMBs for example.
So I believe the problem with UMBs is now solved by the correct config files.
And just using the latest version of USE!UMBS.SYS, version 2.2

Kind regards,

Rodney

rodneyknaap · 2023-07-06T23:46:01Z

Hi 640KB,

I am currently not using any RTC, but I would like to use the DS12885 because I bought many of these chips before. That was what I was using on my first revision mainboard.

Before I could not get this DS12885 RTC to work at all, I tested with lots of different programs but no data came back from the RTC.

Perhaps my 32.768kHz clock was not working or something like that, I will use the same tried and tested clock circuit as the AT this time with a separate CMOS inverter, and then feed that clock pulse into the Dallas RTC. If the Dallas won't work, I can swap it for the 146818 if need be.

What kind of configuration would you recommend, which I/O port for example?
is there any reference schematic which you know to be working?

So we solved the UMB problem, still remaining is the enhanced keyboard support, SHIFT+ARROW key fix for being able to select and copy text, and I need to look at the Norton Commander 5.0 still not working, this is a frequent use program of mine. I could check for older versions or alternatives. Basically to copy, move and view files is already a big help for daily use. I can do anything in DOS of course, but it takes more time than using Norton Commander. I will test more different programs.

I really hope that in the future, an "all-included" version of GLaBIOS could be created which has some bonus stuff for my ATX system which makes use of 16k of ROM space, where more is possible than in 8k. Including all the stuff which is perhaps disabled to save space.

Since my ATX system is a modern comfortable system and not a classic, the recommended keyboard is the full enhanced keyboard. This poses no limitations in using and controlling all programs which make use of any of the "enhanced" keys.

I am all for "no limitations" and the most ease of use possible in a PC.
Maybe you were thinking of other ideas before which you discarded because of needing to stay within 8KB?

Kind regards,

Rodney.

rodneyknaap · 2023-07-07T00:16:49Z

Hi 640KB,

I have done some testing:

Norton Commander 4.0.57 is working.

So for the moment that's at least helpful, though it's slower than 5.0.
I will test more versions, perhaps 5.5 will be working.

I will be testing more software soon, and looking at your source code to see what kind of options there are. Like perhaps a small delay for readability. Personally, I prefer a BIOS which is more informative where you can have a moment to see all the information that's on the screen showing the version number, the hardware, etc. If it flashes and disappears before you can read it, I always feel that is less informative.

Do you have any thought about when you could find time for the enhanced keyboard support?
I mean, if this is something you want to add on coming releases.

Thanks for all your help so far.

Kind regards,

Rodney

640-KB · 2023-07-07T14:00:04Z

I am currently not using any RTC, but I would like to use the DS12885 because I bought many of these chips before. That was what I was using on my first revision mainboard.

Before I could not get this DS12885 RTC to work at all, I tested with lots of different programs but no data came back from the RTC.

Perhaps my 32.768kHz clock was not working or something like that, I will use the same tried and tested clock circuit as the AT this time with a separate CMOS inverter, and then feed that clock pulse into the Dallas RTC. If the Dallas won't work, I can swap it for the 146818 if need be.

What kind of configuration would you recommend, which I/O port for example? is there any reference schematic which you know to be working?

Some of those RTC datasheets have fairly complete example circuits but I feel like that one didn't. It also seems like if it was working but not oscillating you could read it but the time would never advance (I had that problem with a MSM5832 that had a bad crystal).

Typically you find those chips at ports 70h, 240h, or 2C0h (though there can be others). Some are configurable, some aren't. We've used GLaTICK thoroughly on both the NuXT and the RTC8088 (https://github.com/spark2k06/RTC8088) and it works great. The RTC8088 has a full schematic and is GPLv3 so you could reference it with credit given.

So we solved the UMB problem, still remaining is the enhanced keyboard support, SHIFT+ARROW key fix for being able to select and copy text, and I need to look at the Norton Commander 5.0 still not working, this is a frequent use program of mine. I could check for older versions or alternatives. Basically to copy, move and view files is already a big help for daily use. I can do anything in DOS of course, but it takes more time than using Norton Commander. I will test more different programs.

Glad to hear it's working. When you say not working, you mean just the keyboard shortcuts - not that it's crashing/locking up like it was before, right?

Since my ATX system is a modern comfortable system and not a classic, the recommended keyboard is the full enhanced keyboard. This poses no limitations in using and controlling all programs which make use of any of the "enhanced" keys.

Yes, enhanced keyboard is a project (and a bit of an overdue one 640-KB/GLaBIOS#10) that's been started but just need to finish it. I can't really commit to a time frame, but it's now interesting enough to me to make it one of the next bigger things I work on!

I really hope that in the future, an "all-included" version of GLaBIOS could be created which has some bonus stuff for my ATX system which makes use of 16k of ROM space, where more is possible than in 8k. Including all the stuff which is perhaps disabled to save space.

I am all for "no limitations" and the most ease of use possible in a PC. Maybe you were thinking of other ideas before which you discarded because of needing to stay within 8KB?

Most of the standard functionality of the BIOS will fit just fine in the standard 8K of space -- including the enhanced keyboard support which I have reserved the space to implement. All of the core "fun features" fit just fine in the 8K size on the standard/Turbo build that you are using.

The only real exception is the 5150 cassette port interface which is a bit of an outlier because it is incompatible with the XT and later motherboards due to different wiring to the PIT and DIP switches. For example, on the 5150 the PB2 that you use to control turbo is used as the selector for reading high/low SW1, which was moved to PB3 on XTs and all later clones. Then on 5150 the PB3 is wired to the tape motor relay and PC4 is wired to the input of the tape interface. Since those addresses are all part of the IBM cassette interface code they aren't changeable in software. The bottom line is you can't really have a standard XT with a cassette port and realistically very few clones (if any) ever implemented it after the 5150. Even then, the only things that are disabled if cassette support is included is the randomized tagline and the hard disk size and geometry display (which doesn't work if you use XUB due to it's late initialization at INT 19h).

The idea is that further "enhanced" functionality be implemented as option ROMs, which have several benefits:

All BIOS images remain compatible with standard XTs that utilize 8K ROMs
It becomes very modular and you can easily pick and choose which features you actually need
They can be used with any BIOS - not just GLaBIOS

So, by simply including them in your EPROM image (the way you are doing with Multi-Floppy and XUB) you get to exactly the same place as building a monolithic 16K BIOS, with the benefits of above. Make sense?

640KB

640-KB · 2023-07-07T14:22:30Z

I will be testing more software soon, and looking at your source code to see what kind of options there are. Like perhaps a small delay for readability. Personally, I prefer a BIOS which is more informative where you can have a moment to see all the information that's on the screen showing the version number, the hardware, etc. If it flashes and disappears before you can read it, I always feel that is less informative.

Yes, I do agree! The Multi-Floppy and XUB can be a bit verbose and take up a good amount of the screen. I'm not sure if there's an option to build them with less, but that would be an interesting research project.

GLaBIOS was designed to fit into a single screen even with the maximum amount of information. For example, here is a standard boot screen without third-party ROMs:

There are some option ROMs being made by other developers, such as the Hakfoo CH37x BIOS (an alternative to CF-IDE/XUB that uses a USB drive instead of a CF card) that implement the GLaBIOS POST screen layout which makes it a lot more seamless. For example:

Now... if you just find that the Multi-Floppy BIOS text is just too much, you could alternatively use the 2M-XBIOS that provides the same high density drive support but as a DOS TSR. It requires being loaded in CONFIG.SYS, but with all of your UMB it won't take up any low memory at all.

I guess keep testing software and let me know if you see anything else. Otherwise, is there anything else outstanding at the moment, or are you good for now?

640KB

rodneyknaap · 2023-07-07T16:53:34Z

Hi 640KB,

About Norton Commander 5, it never locked up the PC. What I see is the program starts and shows the directory panels, however it is not responding to the keyboard. On keypresses you can heer a faint beep in the speaker as if the keyboard buffer is overflowing. The mouse cursor moves but can't activate any menu's. The PC is definately not frozen, however the Norton Commander is in a condition which you can't get out of. Definately it's not a lock up situation. After much typing it might throw an error and halt the PC finally.

Norton Commander 4 works however it is super slow compared to 5 before. And 5.5 wants a 286 so it's not an option. I will look around for similar programs of different makers, maybe I find one that works well.

Thanks for your consideration for the enhanced keyboard support, I really appreciate it. The big issue is also the SHIFT + arrow key text selection for example in EDIT which needs some fixing. Moving sections of text around is a really handy feature rather than retyping it, or using the arrow keys on the number pad.

Ah, about the cassette port. I know exactly what you mean because long ago in my first revision I have looked at this from the schematics because I actually wanted to include it as a cool feature in my PC design. Why remove a cool feature which is very retro after all? However quickly I also discovered that in the 5160 they used the cassette output of the 8255 for other purposes. It's a real shame by IBM to have done that and I was not happy to discover it. So this conflict basically makes it impossible to include the 5150 cassette interface. I would have found it so cool to hook up a cassette player to my XT and load up some software from a tape, how cool would that have been? Of course, you know the cassette port for the 5150 well because you made the BIOS to support it. If perhaps you might have thought of some idea to include the port on an alternate I/O address, I might be tempted to build an interface for it. :)

Okay, I see what you mean, if the 8k segment approach is the concept you feel would be better, I understand that. Well there is definately something to be said for standards, as long as they don't restrict the possible cool options and features. At the same time I am also thinking, if you make the software yourself, it would be nice to do extra stuff too and not only implement the default functionality. But that also could be done in 8k segments of course. This is very much in line with ROM structure of the better XTs of course.

Like on my design, I decided to add a proper reset circuit because I felt it was missing. Even on the 286 AT it was nonexistent. And I added a ATX control circuit to provide comfortable toggle button power on and off. And I modified the turbo circuits and clock generators to provide a better and more stable technology. This kind of "artistic freedom" is also the charm of making my own design because there is less design constriction. Just like I love it what you did when you interacted with the information in the HD floppy BIOS to show the number of drives. A step further could be to show your own version of the drive overview. Nicely spaced instead of in a single line. The phatcode BIOS also tried to show a more readable overview of detected hardware. Your screenshots with more drive information like even the drive sizes are also what I like the most.

A while ago I designed and built a Z80 ATX mainboard which runs CP/M. This page shows the mainboard itself. The BIOS ROM system is made by Wayne Warthen, who approached it from a universal build method. You could make a custom config which lists the BIOS modules to include and their port configuration, then just compile the ROM and burn an EPROM. His software is really amazing, it includes console switching with multi consoles, boot selection menu and many more cool options. This raises the Z80 almost to PC level. They used the modular approach in a different way by defining the modules in the config files for compiling and activating them with the compile options, very interesting and I even modified the BIOS by myself in some situations because I knew the intricate BIOS structure. Anyway, just a side note.

Yes, I love the information from your BIOS examples, the screenshots look even more great, this is what I would love too. Perhaps by disabling the messages in the option ROMs or reducing the info to a footnote, and reading the info with GLaBIOS to output the information in a single standard notation. After all, for example XT-IDE universal BIOS and HD-floppy BIOS by Sergey are not going to change fundamentally anymore I believe. So the method to read their config could be relatively stable. Also, to divide the information in a few sections, like a system section and drives section, with an empty line or some other separator for clarity would be nice to see. And I also like it to see the memory address of BIOS segments which is where, very cool. I remember I saw it somewhere.

For my issues,

the SHIFT + ARROW key feature is something which I use frequently. Hopefully this can get fixed after you finish the enhanced keyboard additions.
Norton commander 4 is an alternative but very slow compared to 5. I will look around and report it here if I find a good solution.
more detailed information on the screen would be great since you are making the code yourself. I love the Hakfoo version because it contains more info.

I am loving the colorful GLaBIOS screens, and the GLaBIOS boot simply gives me a responsive and direct, very efficient feeling. This definately benefits a slow XT class computer to look more developed and modern.

Great to talk with you about these things, it's always good to exchange ideas and impressions!

Thanks so far,

kind regards,

Rodney

640-KB · 2023-07-07T17:41:21Z

Ah, about the cassette port. I know exactly what you mean because long ago in my first revision I have looked at this from the schematics because I actually wanted to include it as a cool feature in my PC design. Why remove a cool feature which is very retro after all? However quickly I also discovered that in the 5160 they used the cassette output of the 8255 for other purposes. It's a real shame by IBM to have done that and I was not happy to discover it. So this conflict basically makes it impossible to include the 5150 cassette interface. I would have found it so cool to hook up a cassette player to my XT and load up some software from a tape, how cool would that have been? Of course, you know the cassette port for the 5150 well because you made the BIOS to support it. If perhaps you might have thought of some idea to include the port on an alternate I/O address, I might be tempted to build an interface for it. :)

Yeah, the cassette is definitely fun from a retro perspective. I bought a tape player and adapter cable for my 5150 that I used during testing and it works nicely! While fun, the utility is fairly limited since it's useful largely in ROM BASIC and only (to the best of my knowledge) two or three programs ever used it (one of them was IBM's standard diagnostics). Sure, you could use an alternate I/O port, wire it differently and modify the BIOS for that, though it would only work on that modified BIOS - not IBM's if someone tried to use that. I also know that IBM ROM BASIC is fairly touchy when it comes to timing and has issues running faster than 4.77MHz (or even V20 running at 4.77). I'm not 100% sure what problems (if any) it causes but more just something I kind of recall (and I may be totally wrong about that too).

Thanks for your consideration for the enhanced keyboard support, I really appreciate it. The big issue is also the SHIFT + arrow key text selection for example in EDIT which needs some fixing. Moving sections of text around is a really handy feature rather than retyping it, or using the arrow keys on the number pad.

the SHIFT + ARROW key feature is something which I use frequently. Hopefully this can get fixed after you finish the enhanced keyboard additions.

Yes, those are just what you'd expect with using an enhanced keyboard on an XT keyboard BIOS. It is noticeable on DOS EDIT as well, selecting text because they also assign different behaviors to the enhanced arrow keys versus the keyboard ones. One workaround you could maybe try is to use the numeric keypad arrows in place of the dedicated arrows and see what that does. I know it's not a good long term solution and isn't as intuitive, but that's what makes DOS EDIT work so maybe NC will as well?

Okay, I see what you mean, if the 8k segment approach is the concept you feel would be better, I understand that. Well there is definately something to be said for standards, as long as they don't restrict the possible cool options and features. At the same time I am also thinking, if you make the software yourself, it would be nice to do extra stuff too and not only implement the default functionality. But that also could be done in 8k segments of course. This is very much in line with ROM structure of the better XTs of course.

My thinking is really just comparing the PROs to the CONs. Where I really have yet to find a case where those larger features that are generally out of scope of a standard XT BIOS as option ROMs wouldn't work. To me it's the best of both worlds because you have effectively an existing standard for "plugins" that are universally compatible with virtually all XT BIOSes. The XT BIOS is just really packed, and fitting all of the required functionality AND maintaining the "compatibility" fixed ISR offsets can be a challenge where you are literally re-arranging code to use every single possible byte -- it may start to get really messy to deal with relocating large amounts of code conditionally for different build targets. While it is about maintaining as much compatibility as possible, there is an aspect of the challenge of working within the constraints of the time -- while at the same time trying to give it a bit more of a modern feel, if that makes sense!

Yes, I love the information from your BIOS examples, the screenshots look even more great, this is what I would love too. Perhaps by disabling the messages in the option ROMs or reducing the info to a footnote, and reading the info with GLaBIOS to output the information in a single standard notation.

The challenge there is just that the BIOS isn't in charge when those option ROMs are running and displaying their info. You literally just jump to the routines in their ROM and cross your fingers and hope that they jump back to you (the BIOS). So whatever they do or write is their doing and I have no control over that. I did place the display of it where it was intentionally - after the parts of the BIOS where an option ROM would have no influence (CPU, RAM, etc) but before things like displaying number of drives that an option ROM could enable or change. The only way though for an option ROM to adhere to the GLaBIOS display would be if it specifically writes to the screen that way, as Hakfoo did. I have thought about creating a "POST screen API" (to use a modern term) to make that easier (though of course still require that the option ROM's author implement it). We'll see!

And I also like it to see the memory address of BIOS segments which is where, very cool. I remember I saw it somewhere.

So I have an optional feature slated for the next real release where it will show option ROMs locations that are found and their corresponding sizes. It will also show if there was an error with the ROM checksum and what the checksum actually was, rather than silently skip it to the next.

Note: I also re-arranged the hard drive size and geometry into two columns which I think looks a bit cleaner and makes better use of the space... what do you think?

I am loving the colorful GLaBIOS screens, and the GLaBIOS boot simply gives me a responsive and direct, very efficient feeling. This definately benefits a slow XT class computer to look more developed and modern.

Great to talk with you about these things, it's always good to exchange ideas and impressions!

Thanks! I'm really glad to hear that you enjoy it! And same to you as well, it's been great talking with you and especially letting me know about things that aren't working so we can make it better. I have learned a lot more about USE!UMB, DOSMAX and all so it's been very informative and helpful!

640KB

640-KB · 2023-07-07T17:58:19Z

If you want to try with those above features, here is a more standard V20/Turbo 0.2.5 "pre-release" build with three options:

No DRAM refresh/DMA TC0 check (DRAM_REFRESH = 0)
No parity checking at all (RAM_PARITY = 0)
Doesn't require you to press a key if there's a POST error (POST_ERR_WAIT = 0). I think you said you may not have a floppy drive so that will prevent you from having to hit a key to dismiss the error.

GLABIOS_0.2.5_VT_RK2.zip

640KB

rodneyknaap · 2023-07-07T19:10:24Z

Hi 640KB,

I see about the basic usage, it sounds unstable and not fully developed at a stable level. Thanks for your elaboration on that. I didn't have any chance yet to try out this basic version. When I was still in the "imagination" phase of my XT project, I fantasized about being able to load programs from tape into memory and then saving them to disk, and vice-versa. Just using the tape connection as an extension to the PC itself, not basic. But it sounds like if I wanted that, it would be something entirely new that doesn't exist yet. I just read about a cassette port on a PC, and thought that is really cool to have. But basic only is more limited of course. Perhaps this is not something to include in a BIOS but more something for a separate DOS application to be developed that doesn't use BIOS extensions. I will remember this project for another day, it is kind of cool to be using a simple audio tape for a DOS storage medium.

Indeed, the numerical arrow keys work with text selection, I have verified this. However it's just awkward and not the way I was used to working in DOS. It's the fun retro feeling which I am trying to keep in using my PC, so I hope it can provide the right arrow functions one day.

I just tested Norton Commander with the numerical arrow keys, it didn't work either. I also noticed that using the arrow keys doesn't create any buffer overflow faint beeps, but after the buffer fills, it starts to signal the overflow with the beeps.

From your explanation that sounds like really difficult work to get the code to fit. I also read in the phatcode notes that it's hard to code because many calls are fixed in memory, which tends to create a sort of spaghetti structure of code to keep the right entry addresses. Indeed if a build differs and you need to rearrange the code locations for that, it's hard to do automatically I imagine. I see your challenges, I understand.

I see, so using the messages from options ROMS requires a higher collaboration between projects. Or just use a fixed version and use the "good luck" approach you described.

The option ROM feedback you describe sounds really great too, I hope it can make it into the next release, exciting stuff!
I love those screenshots showing the ROM size, very professional.

Indeed, arranging into colums is much more clear than just listing it in one line behind eachother. I love it. This kind of thing really stands out and provides much more clear messages. Also the colorful nature is really great, this is something distinct of your BIOS and adds to the clarity of display. Once users see the screen more often, they will quickly know which info is where and it will be even more easy to read.

I have also learned more from these tests, when I first started to use USE!UMBS.SYS, I already found it was quirky, but after using it more, I could appreciate it more and more. Later I found DOSMAX and started testing with that too. Your latest addition of DOS=UMB,HIGH was the icing on the cake to even further reduce the MSDOS part in conventional RAM to 9KB.
When I retried the original configs I saw the problem again and I was actually glad because at least I could find the actual problem and not have some undetermined cause.

Thanks for making the new BIOS version, very cool, I appreciate that! I will try it now!

And thanks for the explanations of your work, nice to know some inside stuff, I am always very interested to learn more.

Kind regards,

Rodney

rodneyknaap · 2023-07-07T19:34:28Z

Hi 640KB,

I have tested the new ROM, very cool to see the ROM addresses.

I wrote down a list of the address hex values in my EPROM, it is like this:

FE000 - FFFFF GLaBIOS
FC000 - FDFFF XT-IDE
FA000 - FBFFF HD-FDD

The rest is blank for the moment.

I see the structure to list the option ROM, then displaying the ROM messages following.

I attached a photo.

Very nice!

Kind regards,

Rodney

640-KB · 2023-07-07T19:54:51Z

I see about the basic usage, it sounds unstable and not fully developed at a stable level. Thanks for your elaboration on that. I didn't have any chance yet to try out this basic version. When I was still in the "imagination" phase of my XT project, I fantasized about being able to load programs from tape into memory and then saving them to disk, and vice-versa. Just using the tape connection as an extension to the PC itself, not basic. But it sounds like if I wanted that, it would be something entirely new that doesn't exist yet. I just read about a cassette port on a PC, and thought that is really cool to have. But basic only is more limited of course. Perhaps this is not something to include in a BIOS but more something for a separate DOS application to be developed that doesn't use BIOS extensions. I will remember this project for another day, it is kind of cool to be using a simple audio tape for a DOS storage medium.

In actuality the tape services provided by the BIOS in INT 15h (read / write) could absolutely be used by any program, so for sure you could write something that uses it for storage. Of course, with forward-only reading/writing you'd have to come up with an application where that's okay. Plus the data rate is not exactly quick... but could be done! Here's someone who took a fairly different approach but used the jack to load DOS from a record with custom software.

Indeed, the numerical arrow keys work with text selection, I have verified this. However it's just awkward and not the way I was used to working in DOS. It's the fun retro feeling which I am trying to keep in using my PC, so I hope it can provide the right arrow functions one day.

I just tested Norton Commander with the numerical arrow keys, it didn't work either. I also noticed that using the arrow keys doesn't create any buffer overflow faint beeps, but after the buffer fills, it starts to signal the overflow with the beeps.

Yep, totally get it! It's in the works. :)

From your explanation that sounds like really difficult work to get the code to fit. I also read in the phatcode notes that it's hard to code because many calls are fixed in memory, which tends to create a sort of spaghetti structure of code to keep the right entry addresses. Indeed if a build differs and you need to rearrange the code locations for that, it's hard to do automatically I imagine. I see your challenges, I understand.

Yeah, you really have to fight for every single byte to get everything that needs to happen in the BIOS inside 8K (plus adding all of the POST screen and color stuff that wasn't there in the originals). There's nothing automatic at all... every byte is placed exactly where you decide it must go! It's been a fun learning experience in pure, brual optimize-for-minimal-code-size at all costs. You have to make hard decisions like "can I get away with it saying 'PAR' instead of 'PARITY' error?" or "RAM" instead of "Memory" just to make it build. As time went on some of those error messages got shortened too for the same reason...I believe much earlier the DMA error said "DMA TC0" (or something like that) which might have actually been helpful!

I have tested the new ROM, very cool to see the ROM addresses.
I see the structure to list the option ROM, then displaying the ROM messages following.

Yeah, it's sort of too bad that XUB does the late drive initialization after POST is done, so you lose the size and hard drive info that would normally be shown.

Indeed, arranging into colums is much more clear than just listing it in one line behind eachother. I love it. This kind of thing really stands out and provides much more clear messages. Also the colorful nature is really great, this is something distinct of your BIOS and adds to the clarity of display. Once users see the screen more often, they will quickly know which info is where and it will be even more easy to read.

Glad you like it! When I looked at those screenshots as I was writing to you I just thought... why didn't I make those on another column... it would look so much better. Though it adds 9 bytes of additional code to do it... but I think it's worth it. 👍

I have also learned more from these tests, when I first started to use USE!UMBS.SYS, I already found it was quirky, but after using it more, I could appreciate it more and more. Later I found DOSMAX and started testing with that too. Your latest addition of DOS=UMB,HIGH was the icing on the cake to even further reduce the MSDOS part in conventional RAM to 9KB.
When I retried the original configs I saw the problem again and I was actually glad because at least I could find the actual problem and not have some undetermined cause.

Yeah, those settings can be touchy and confusing for sure. I think I just found a formula that worked a while ago and stuck with it. I certainly couldn't explain off the top of my head why DOS=UMB,HIGH works and DOS=UMB doesn't.

And thanks for the explanations of your work, nice to know some inside stuff, I am always very interested to learn more.

Likewise! Keep me posted on that board and if anything else comes up.

640KB

rodneyknaap · 2023-07-07T20:59:18Z

Hi 640KB,

Definately when talking about the cassette routines and how they could be used, I am seeing the charm and attraction of assembly coding on the XT. I definately should learn it and combine that with designing hardware. Right now I totally can't find the time but I hope later I will be able to. Very cool that DOS vinyl record. I was also thinking about plugging a phone into the PC and playing some audio file, and ending up with a program on the XT. And similar stuff. It would be cool to have a DOS handler which could create files from an audio input. And vice-versa, record some audio and it contains a file. I still like this idea a lot.

I see what you mean about the tricks to shorten the code when compiling it. I suppose it's also about where in the ROM space the code needs to be, if there is more or less space there. Sounds like a huge interconnected puzzle. There is definately an element of challenge in doing that. But it's a little like my circuit and PCB design and debugging, if you don't know the huge work that went into planning and executing this kind of project, no one can really fully appreciate the work, only knowledgeable peers could.

Oh, I see about XUB, it only does the detection after the POST is already finished, a sort of last-second process. So getting information on the screen can only be done by the XUB itself.

It must be frustrating sometimes to be able to do anything code-wise, but not being able to implement it space-wise in the BIOS. The result feels like a bit of an artwork to get the most into the creation.

Very interesting, I have some new inspiration to get into coding some day and perhaps experimenting with tape interfaces.

Nice talking to you, see you next time,

kind regards,

Rodney

rodneyknaap · 2023-07-20T20:31:55Z

Hi 640KB,

I just realised something, since we are working to achieve full compatibility with my mainboard, I also should raise one more point. My mainboard contains two 8259 interrupt controllers which have been put in a cascade mode connection, similar to how it is done in the 286 and following AT systems. However, when I put the second 8259 into my mainboard, it freezes the POST. I suspect that the second 8259 is not properly initialized by the BIOS. I don't know of course if initializing the second 8259 needs a lot of code, or even if it is difficult to implement, anyway, I just want to raise the issue to talk about if it could be supported. To have a full complement of IRQs would be a pretty big improvement for me. Of course, I don't know how much code would be needed for this, whether it's possible within the ROM memory space. If you have any idea or suggestion how this could be implemented, also in terms of ROM space which I know is limited with 8kb, I would love to know about it.

Kind regards,

Rodney

GLaBIOS compatibility questions #1

GLaBIOS compatibility questions #1

Comments

640-KB commented Jul 2, 2023

rodneyknaap commented Jul 3, 2023

640-KB commented Jul 3, 2023 • edited Loading

rodneyknaap commented Jul 3, 2023

rodneyknaap commented Jul 3, 2023 • edited Loading

rodneyknaap commented Jul 3, 2023

rodneyknaap commented Jul 3, 2023

640-KB commented Jul 4, 2023

rodneyknaap commented Jul 4, 2023

640-KB commented Jul 4, 2023

640-KB commented Jul 5, 2023

640-KB commented Jul 5, 2023

rodneyknaap commented Jul 5, 2023

rodneyknaap commented Jul 5, 2023

640-KB commented Jul 5, 2023 • edited Loading

640-KB commented Jul 6, 2023 • edited Loading

rodneyknaap commented Jul 6, 2023

rodneyknaap commented Jul 6, 2023 • edited Loading

rodneyknaap commented Jul 6, 2023

rodneyknaap commented Jul 6, 2023 • edited Loading

rodneyknaap commented Jul 6, 2023

rodneyknaap commented Jul 6, 2023 • edited Loading

rodneyknaap commented Jul 6, 2023 • edited Loading

640-KB commented Jul 6, 2023

640-KB commented Jul 6, 2023

640-KB commented Jul 6, 2023

640-KB commented Jul 6, 2023 • edited Loading

rodneyknaap commented Jul 6, 2023

rodneyknaap commented Jul 6, 2023

640-KB commented Jul 6, 2023

640-KB commented Jul 6, 2023

rodneyknaap commented Jul 6, 2023

640-KB commented Jul 6, 2023

rodneyknaap commented Jul 6, 2023

640-KB commented Jul 6, 2023

640-KB commented Jul 6, 2023 • edited Loading

rodneyknaap commented Jul 6, 2023

640-KB commented Jul 6, 2023 • edited Loading

rodneyknaap commented Jul 6, 2023

rodneyknaap commented Jul 6, 2023 • edited Loading

rodneyknaap commented Jul 7, 2023

640-KB commented Jul 7, 2023

640-KB commented Jul 7, 2023 • edited Loading

rodneyknaap commented Jul 7, 2023 • edited Loading

640-KB commented Jul 7, 2023 • edited Loading

640-KB commented Jul 7, 2023 • edited Loading

rodneyknaap commented Jul 7, 2023

rodneyknaap commented Jul 7, 2023

640-KB commented Jul 7, 2023

rodneyknaap commented Jul 7, 2023 • edited Loading

rodneyknaap commented Jul 20, 2023

640-KB commented Jul 3, 2023 •

edited

Loading

rodneyknaap commented Jul 3, 2023 •

edited

Loading

640-KB commented Jul 5, 2023 •

edited

Loading

640-KB commented Jul 6, 2023 •

edited

Loading

rodneyknaap commented Jul 6, 2023 •

edited

Loading

rodneyknaap commented Jul 6, 2023 •

edited

Loading

rodneyknaap commented Jul 6, 2023 •

edited

Loading

rodneyknaap commented Jul 6, 2023 •

edited

Loading

640-KB commented Jul 6, 2023 •

edited

Loading

640-KB commented Jul 6, 2023 •

edited

Loading

640-KB commented Jul 6, 2023 •

edited

Loading

rodneyknaap commented Jul 6, 2023 •

edited

Loading

640-KB commented Jul 7, 2023 •

edited

Loading

rodneyknaap commented Jul 7, 2023 •

edited

Loading

640-KB commented Jul 7, 2023 •

edited

Loading

640-KB commented Jul 7, 2023 •

edited

Loading

rodneyknaap commented Jul 7, 2023 •

edited

Loading