Closed moononournation closed 1 year ago
Yo need to set the RPi model that you are targetting and recompile both circle SDK and the faux86-remake source code. Edit the Config.mk
files located within the circle and faux86/pi folders and set RASPPI ?= 3
to
target the RPi model 3. Both the circle SDK and faux86 code need to be rebuilt when changing the target model.
To make it easier and quicker I create 4 seperate builds of the circle SDK for each model. This way I do not have to rebuild the full circle sdk everytime I recompile the faux86 emulator for another RPi model.
both set, any other parameters need to change?
Have you rebuilt both the circle and faux86 code after changing the RASPPI ?= 3
in the Config.mk files?
Are you using the latest source code ? I updated it a few days ago and the config.txt within the root of the sd-card was updated. The first few lines should read like this:
# FAUX86 RPi Config File
[pi4]
kernel=kernel7l.img
[all]
# Composite Test Mode in Seconds
#test_mode=2
# Disable rainbow splash screen
# Fixes CTRL-ALT-DEL Black Screen
disable_splash=1
I already changed both config from 1 to 3 at the first build success. But failed to boot after overwrite the kernel3 file.
Well I have no idea unless you can provide some log output. All debug info is sent over serial port from the TX/RX pins on the pi. To debug over serial port using terminal screen command before booting the pi:
screen -L -Logfile serial.log /dev/ttyUSB0 115200
I think the problem is with the build of circle that you are using. I used the develop branch of circle and it contains some display updates. Download the circle SDK from the develop branch.
Or you could simply comment out the mouse section lines in CircleHostInterface.cpp
CircleHostInterface::resize
function:
void CircleHostInterface::resize(uint32_t desiredWidth, uint32_t desiredHeight)
{
log(Log, "[CircleHostInterface] resize %lu x %lu", desiredWidth, desiredHeight);
if ( (screen->GetWidth() == desiredWidth) && (screen->GetHeight() == desiredHeight) ) return;
//COMMENT THIS IF NOT USING DEVELOP BRANCH
//if (mouse) {
//mouse->Release();
//}
screen->Resize(desiredWidth, desiredHeight);
vm->config.resw = desiredWidth;
vm->config.resh = desiredHeight;
//COMMENT THIS IF NOT USING DEVELOP BRANCH
//if (mouse) {
// mouse->Setup(desiredWidth, desiredHeight);
//}
}
I am using Faux86-remake master and circle develop branch. I will try to read the serial log tonight.
Just checked your release have normal serial output, but my build (kernel8-32.img) does not have any serial output at all. And I found the image file size have a little different, your release is 456KB but my build is 465KB. 9KB larger. Is it any further changes of Config.mk parameter in your build?
Is there any serial output from the pre-compiled release build ? If not then your serial wiring is incorrect. If there is no serial log output and the display is blank without a flashing cursor then something wrong with your build toolchain. I would start by compiling a simple circle blink kernel or one of the examples to check that the circle sdk is compiled correctly.
It have normal serial output using your relase. And also it have serial output if using circle ./makeall output kernel8 image.
Have you commented out the mouse code lines from the CircleHostInterface::resize
function shown in my previous post above ? Compiling one of the circle sample programs should produce kernel8-32.img
and not kernel8.img
Are you certain that using the circle develop branch here: circle sdk develop branch
Yes, the image full file name is kernel8-32.img Yes, I am using circle sdk develop branch. The master cannot compile success.
Well, if you can compile and run one of the circle example kernels fine then the problem is with the faux86 compile. This compiles and builds fine on my system so something you may have changed in the code or config files.
I am using your master branch
Do the following:
Copy the Config.mk
file from the faux86/pi folder into the root of the circle sdk folder.
Edit the Rules.mk
file within the root of the circle sdk folder.
Change the lines near the top to look like this:
-include $(CIRCLEHOME)/Config.mk
#-include $(CIRCLEHOME)/Config2.mk # is not overwritten by "configure"
Recompile circle and then faux86 source and should build and boot fine.
The Rules.mk
in the circle folder is where the target Rpi model is set but I use a custom Config.mk
file to change target model.
Thanks! It works now! Seems copy Config.mk is the key, below are my latest step:
git clone -b develop https://github.com/rsta2/circle.git
git clone https://github.com/ArnoldUK/Faux86-remake.git
docker run -ti -v ~/git:/git tianon/raspbian:bullseye bash
apt update && apt install -y make gcc-arm-linux-gnueabihf gcc-arm-none-eabi
cd /git/Faux86-remake/pi && make clean && make libs && make
Great! I will add your build steps to the docs as I do not have any build instructions. Faux86-remake BUILD
Thx.
I found most Arudino frame buffer tuning can also apply to RPi, the preliminary test already improve much screen response time.
Ok, can I see your modifications ? Have you forked it ?
the code with #if defined(ARDUINO)
Yes I see the changes from int32 to int16. I will give it a try this weekend and create a pull or merge request. Thanks for updating the performance, I've done as much as I can but I think using multicores should improve things even more.
I've tested your updates and the RPi build response times have certainly increased, thanks! I'm not sure if I should create a new branch to add your updated code or simply merge them all into a single main branch. I've done some more updates to the RPi build to fix some keyboard and audio timing issues. I'm also working on streamling and improving the Adlib/Soundblaster code.
Still a change not yet applied. A vga_framebuffer is a big memory allocation, it should be an option allocate in main program and pass the buffer to the framebuffer class.
Still a change not yet applied. A vga_framebuffer is a big memory allocation, it should be an option allocate in main program and pass the buffer to the framebuffer class.
Yes, I agree but I had to use a large enough buffer for the highest resolution supported in EGA/VGA DOS mode which is 720x400 so used 800x800 buffer. Sure it's possible to dynamically create it with a custom size passed from main program.
I've updated the ADLIB OPL classes to use either Nuked OPL or DOSBox OPL. Nuked OPL uses more memory and is quite slow in emulation but the DOSBox OPL class is very fast and uses less memory.
So before I upload the updates, would you prefer seting the framebuffer size and pixel format from the settings file and dynamically create the framebuffer ? Do you think adding an uint8_t
8-bit pixel framebuffer would increase the performance any further ?
You mean indexed color? When I modifing 4bit color mode, I want to ask is it store in some sort of indexed color.
No, I've tried using DEPTH 8-bit mode with the SDK but performance is no difference and requires too much re-compiling to be worth the effort. I have all your updates and many many more merged now so will try upload tonight. Moved all defines to main config file so not scattered around in many units.
Hi Mrs Arnold, i would like to buy a Raspberry and install Faux86-Remake bare metal, in order to test various 80' PCs, and among them the boot discs of Tandy1000EX, and also the Gary Kindall's DR-DOS 3.41 and 5.0. You think it is possible to boot these particular computers? And i also have another question about boot. I know a Raspberry Pi 3 can boot from USB, and some people prefere boot like that. In your opinion is it possible do that for Faux86-Remake? Thanks Gianni
Firstly, I prepared the latest Faux86-remake ARM-PRi release to the Micro-SD card and able boot on RPi 3B.
Then I tried to build the ARM-PRi
docker run -ti -v ~/git:/git lpenz/raspbian-trixie-armhf bash
apt install make gcc-arm-linux-gnueabihf gcc-arm-none-eabi
cd /git/circle/ && ./configure -f -r 3 && ./makeall
cd /git/Faux86-remake/pi && make clean && make
It is boot failed after overwrite the kennel file, do you know what I have missed?