- Clean up sound implementation and test sound on real hardware again. It's been two months since I have and Rodney noted some bugs. I will see what I can do about this. 22KhZ sound effect mixing is also messy and buggy and I would like to fix that, then there is also an issue where some sound channels disapear. This is hard to debug because it involves interrupts and martypc does not do soundblaster. The idea I have is that since I cant easily write to a debug file in interrupts, I will probably write data into a ring buffer in a UMB (E0000) and try and quit out when I detect the issue and use debug to look at the data in there.
It's great to read more interesting details about your work on RealDOOM, which is really progressing Patrick!
I have followed your updates on GitHub to test with all the recent code updates I noticed, today I will again download and test the latest builds you uploaded.
I can report one difference I noticed already which has been that the game demo is now again running correctly where the gameplay as followed in the demo now progresses correctly into the game again. So the timing is right again in the game demo playback. Which is pretty cool to see because when I run your demo as a stability test in my development system, I can see the demo game go through the entire level which just looks really cool.
Earlier I have tested the sound though the SFX were still missing. Of course, I am hopeful that as a result of your updates the sound effects will come back, I will let you know right away if I find this. As I understand this is much more difficult for you to test and verify since the emulator doesn't simulate the sound card. So it's much more involved to be needing to be near the hardware, and in addition to need to transfer the updated files to the physical drive each time.
Indeed, we have discovered quite a few things involving the memory management and timing for achieving higher speeds and efficiency, which is similarly relevant for all types of RAM.
I am currently working on the first FPGA design phase of our 286 PC/AT system where we will be able to apply much more dedicated really fast logic for creating new system control, and in addition to that we will be able to make use of the pipeline timing of the 286 address bus which provides us with much more time to setup the memory address lines and this will get us closer to 0ws on the FPGA system as well. I will be working on featuring a "PCI" type slot connector where we can work on new types of hardware, and possibly enabling a much larger range of existing faster VGA cards to work with the 286 CPU.
Currently I have seen VGA card example implementations in hardware code for a complete PC system implementation such as the ao486 which may some day be possible to be split out and convert that adapter to work with the 286 16 bit bus as well.
With FPGA technology we also may be able to create hardware that doesn't exist yet, like possibly even a GL type of graphics adapter. There is a lot of work out there being done with FPGA technology by really talented people.
After finishing the first FPGA mainboard, we also could work on creating a slot VGA adapter card with a dedicated FPGA and fast modern RAM purely for generating the graphics. The FPGA may also be able to offer a super fast dual port caching memory system to allow much faster transfers into the VGA memory window because the cache memory can be written to and read at the same time without delaying any operations on both sides. So imagine doing continuous VGA transfers with 0WS at 30MHz and higher which would be at least as fast as the system memory, without getting delayed by IOCH_RDY occurrences. With FPGA technology there is a huge potential for speeding up the system in different areas.
And if someone would develop a 286 CPU code in VHDL or Verilog, when this code runs in the FPGA, it may be able to run at really high clock speeds far above the physical chip speed. And having a really fast FPGA interfaced with a 286, that system may very well already be able to run faster than time period systems as well.
Anyway, I am developing the hardware step by step, and with each progression we will be able to make big improvements in the clock speed and efficiency.
And of course, the goal will be to keep supporting RealDOOM on each subsequent new system from now on!
Thanks for your continued great work on the project Patrick, it's much appreciated!
Kind regards,
Rodney
