Would adding RReady, the Rendition Verité wrapper, for Dosbox or Dosbox-X be allowed for Speedy3D (DOS Rendition)?
RReady is closed source, but I'm hoping to produce a GLiDOS style update to support Speedy3D. I know closed source is evil.
The staging guys didn't want to have anything to do with it (https://github.com/dosbox-staging/dosbox-stag … iscussions/3156). So I just thought I'd ask before attempting anything. This time I'm not even going to play around with the source until I know for sure.
Thanks guys and sorry if I'm offending you with a closed source wrapper.
By "allowed" I'm assuming you are wanting gpl code added to those projects to use the closed source wrapper but not code added to dosbox that is not GPL. Main problem is due to dosbox changes ensuring that nothing broke with the wrapper would be difficult......same as with forks that use glide wrappers.
Official dosbox doesn't use any wrappers for the main reason that the maintenance burden is too high for too little gain for a small number of dos games.
The license allows it so likely best case for now is fork the code, assuming that the games you support work except for the required wrapper then if the patch is minimal it probably wouldn't be too much of a burden to maintain the fork. It may not be ideal but at least there would be something there for someone in the future to work on something more open source friendly.
Last edited by DosFreak on 2023-12-01, 12:28. Edited 3 times in total.
DosFreakwrote on 2023-12-01, 11:49:By "allowed" I'm assuming you are wanting gpl code added to those projects to use the closed source wrapper but not code added t […] Show full quote
By "allowed" I'm assuming you are wanting gpl code added to those projects to use the closed source wrapper but not code added to dosbox that is not GPL. Main problem is due to dosbox changes ensuring that nothing broke with the wrapper would be difficult......same as with forks that use glide wrappers.
Official dosbox doesn't use any wrappers for the main reason that the maintenance burden is too high for too little gain for a small number of dos games.
The license allows it so likely best case for now is fork the code, assuming that the games you support work except for the required wrapper then if the patch is nimal it probably wouldn't be too much of a burden to maintain the fork.
Thanks @DosFreak. That's what I was hoping for. I'll fork the code.
Sorry guys. I realise you have other things to deal with but,
I've got a slight problem with heavy debug. I modified it to dump all instructions irrespective of breakpoints by modifying DEBUG_HeavyLogInstruction to store all instructions in a vector and DEBUG_HeavyIsBreakpoint to log them.
The problem is I get dumps like this (registers info. truncated):
The new bits here are
//if (logHeavy)
DEBUG_HeavyLogInstruction();
#if LOG_TO_FILE
if(fullLog.size() > 2000)
DEBUG_HeavyWriteLogInstructionRendition();
#endif
:
Make sure you are using the core=normal setting, as the instruction pointer skipping around could be due to the dynamic core that executes blocks of instructions where the debugger can only be active between blocks.
Make sure you are using the core=normal setting, as the instruction pointer skipping around could be due to the dynamic core that executes blocks of instructions where the debugger can only be active between blocks.
ripsaw8080wrote on 2023-12-10, 00:40:FYI, segment 0xF000 is the system BIOS region, segment 0xC000 is the video BIOS region (for EGA/VGA). […] Show full quote
FYI, segment 0xF000 is the system BIOS region, segment 0xC000 is the video BIOS region (for EGA/VGA).
Use phys_write to write to BIOS (read-only) regions, because mem_write cannot.
Yup that's what I needed. The code reads mem address f00009fc and compares a 32 bit value there . I don't know what that value represents. The value there is Anded (test), checked for less than, on fail compared to 79h.
Need to see what a actual rendition setup returns.
The address 0x9fc with segment 0000 is returned in a video rom bios call int 10h ax=158dh on physical hardware . I *think* this is rendition specific. The net suggests this returns display adapter parameters, but doesn't list anything specific. The segment is offset with 0xf000.
Also there was a bug with my Turbo C code in that it didn't correctly preserve registers.
It appears to return
1CX=some fixed address dependent on the card 2DX=C000
On further analysis the actual address games use are:
0x000C0A2C (for a Rendition V2200 reference bios) (Once I get feedback from an actual V1000 board with the new test app, I expect to get CX=0x9FC and DX=C000)
vQuake appears to add 0xF0000000
for an address of 0xF00C0A2C
and Rendition DMATest uses
0x000C0A2C
So PhysMake should be correct. But this isn't the video BIOS. It keeps incrementing the address until it encounters 0x79. If it doesn't it just keeps going.
The V2200 reference BIOS indicates that the address (0xC0000A2C) contains 3 bytes, "Rendition Reference Board", more bytes followed by 'y' (0x79).
V1000 bios indicates that the address (0xC00009FC) contains a chunk of bytes, "PCIRc", more bytes, "Rendition Reference board", more bytes and then 'y'.
[EDIT] It also appears to count how many bytes into the block it took to encounter byte 0x79.
Unless I'm missing something , 0x000C0000 isn't the video bios [EDIT2](unless maybe in real mode).
Video BIOS is at C000:0000, linear address 0xC00000. My example with PhysMake was based on real mode segment and offset for the system BIOS. Perhaps the apps you are looking at use protected mode, and thus reference 32-bit offsets within a descriptor.
The disassembly appears to show register access to eax, ebx and so on, which I think indicates protected mode.
I *don't* know. x86 assembler was never my forte. I did dabble with VESA BIOS extensions with Turbo C and direct writes to video RAM. I no longer have the source for any of that, though I do have some leftover binaries.