Reply 540 of 2397, by SA1988
wrote:It's been a busy week! […]
It's been a busy week!
To answer some questions:
Yes, I will add a keybinding for the Brazilian key to generate that scancode. I'm also up for adding a configuration option in DOSBox on what to do with F13-F24.
The TVGA8900 just arrived at my place according to Ebay, so I might get around to checking to make sure the card works and testing it this weekend.
I'm not sure I implemented the Read Capacity command correctly, because documentation is so sparse on the internet. It might be best at this point to add a test routine in DOSLIB's IDE utility to use the command and see what happens. Not sure if that has anything to do with NT and CD-ROM.
At this time there's no such _EGA_LINE_DOUBLE constant in DOSBox-X, I'll see what differs between DOSBox-X and DOSBox SVN. Expect the two projects' VGA emulation to diverge quite a bit because I think there's a lot about DOSBox's VGA raster emulation that needs to be cleaned up.
The problem with setjmp/longjmp is that if you jump out of a function using C++ objects on the stack those objects are not given a chance to free (unless you jump back). Using setjmp/longjmp with C++ is not a good idea. At the same time I would agree some of the throw/catch stuff is not quite the right way to do things, and I need to clean that up. There needs to be a way for the CPU to decode instructions according to virtual memory with potential for page misses, without page faults and recursion interrupting CPU instructions out of the blue. I think that if CPU instruction decoding were written to be restartable, while using variations of mem_readb() that could return boolean false instead of going through with a page fault, that might allow better design, then the page fault mode would not need to throw an exception the way it does.
nvm, I have fixed it alone 😉