Commander X16

I realize that bsd and unix likes as a whole aren't a target currently but since the only dependency was sdl2 I figured I'd give compiling it a shot.

 

it actually compiled with gnu make without any errors, "Sweet!" I thought.

 

then I try to run it and I get a segmentation fault. No problem, I know my way around a C code base.

So I pop it in gdb and find out that the literal 2nd line of code ran fails.

451    char *base_path = SDL_GetBasePath();

the app doesn't check if SDL returns a valid pointer, so that's a bug! I just added two lines to fix it...

452    if (!base_path)

453        base_path = SDL_strdup("./");

then I copied over a "x16emu" to a copy of the current linux release (kyoto), just to have the rom.bin, and I run into the next issue.

 

I really don't know how to fix this next one, the app is just stuck on a blue screen. it's like everything works but the main logo and basic prompt just don't load. any advice?

I'm..... not even sure what you're doing.....

Are you actually compiling BSD into a bin and putting it into the X16 emulator as one of its ROM banks?????

Is that even DOABLE??

I mean... how does BSD only compile down to 16K in the first place...?

 

OH!   You're trying to build the EMULATOR on BSD!

Whew!

 

Blue screen means it's the wrong version of the ROM.  If you're building the most recent commit of the emulator, then you also need to build the most recent commit of the ROM.  I've attached it here, but if the emulator updates further and you compile it again and it goes back to a blue screen then you'll need to recompile the ROM.


rom.bin

1 hour ago, rje said:

I'm..... not even sure what you're doing.....



Are you actually compiling BSD into a bin and putting it into the X16 emulator as one of its ROM banks?????



Is that even DOABLE??



I mean... how does BSD only compile down to 16K in the first place...?

Back in the late 80s I think it was, there was this company that got a bit of press for developing what they called "Web Compression". This is before there was a world wide web. Anyway, it had the "interesting" property that it had 16 to 1 lossless compression on any data exceeding 64K. So you could take 1G of data and compress it down to 64M. Then you could feed that in and get it down to just 4M! Then 256K! Then one more time to exactly 16K!

I think if they found a way that data could be compressed iteratively until they got it under 64K, that algorithm could do just about anything, up to and including running x86-64 builds of an operating system on a 65C02. ?

31 minutes ago, Ender said:

Blue screen means it's the wrong version of the ROM.  If you're building the most recent commit of the emulator, then you also need to build the most recent commit of the ROM.  I've attached it here, but if the emulator updates further and you compile it again and it goes back to a blue screen then you'll need to recompile the ROM.



rom.bin 112 kB · 2 downloads

I feel like an idiot, this seems so obvious. They even tell you in the documentation.

 

I'll probs add a pull request for the two line fix just so they can advertise that OpenBSD is a supported platform.

20 hours ago, Scott Robison said:

Back in the late 80s I think it was, there was this company that got a bit of press for developing what they called "Web Compression". This is before there was a world wide web. Anyway, it had the "interesting" property that it had 16 to 1 lossless compression on any data exceeding 64K. So you could take 1G of data and compress it down to 64M. Then you could feed that in and get it down to just 4M! Then 256K! Then one more time to exactly 16K!

I believe FORTUNE has an entry related to that:

 

Quote

rm -rf *: 100% compression!

 

I decided to test this myself using a virtual machine. After successfully building and running the emulator on OpenBSD, I wanted to see if it was possible on FreeBSD. I discovered that the emulator also runs on FreeBSD, and doesn't require any modifications to function.



Strangely, neither OpenBSD nor FreeBSD is able to open the SD card image in "r+b" mode. Changing the mode to "rb" allows the SD card to be used. This may be an issue with SDL.