Jump to content

Leaderboard

Popular Content

Showing content with the highest reputation on 05/31/21 in all areas

  1. 2 points
  2. Hey, great stuff! Yeah multiprocessing can be a bit iffy, it could be that much time is spent passing the data set across different processes to work on it, and passing the results back. To avoid this, multi threading could help, but then you're sometimes constrained by Python's Global interpreter lock. I want to take a look at your code and see if I can tweak it a bit to make it faster! (for reference it runs in 5 minutes 30 seconds on my Ryzen 2700x)
    2 points
  3. The foreground layer can use any of the 256 colors, while the background layer can only use the first 16 colors, but both foreground and background must be set. My script determines a palette and finds the best solutions using that palette. Improvements could be made finding a better/different palette. See a few examples below:
    2 points
  4. I am new to the 8 bit computing world but I am very excited for this project and to learn more! My first computing experience was Windows 2000 so forgive my ignorance lol
    1 point
  5. Hi, following up on the brief discussion in this thread I wanted to see how far I can get with image to double PETSCII conversion. As a first step I wrote a converter to single PETSCII in Python. It works very well and takes about 6 seconds on my machine to find a very good solution. It can pick a custom color palette that works well for the input image. As the second step, I wanted to write a brute force double PETSCII search and see how far I can optimize it. My brute force method tries all possible combinations of foreground and background characters and picks the closest colors from the palette for each of them, respectively, and picks the best combinations. Albeit being very inefficient, this is the gold standard to compare other double PETSCII conversion algorithms against. A naive single-threaded implementation takes about 25 minutes to convert an image. I am afraid that none of the parallelization techniques I tried worked as well as I hoped. Even with 8 processes on my machine with 8 CPUs it still takes more than 10 minutes to complete. It seems that on my laptop, the search algorithm is severely memory bandwidth limited. (I tried the python modules "threading", "multiprocessing" and also "ray", and I found no significant difference in performance between them). Anyway, find the script plus supporting files in the attachment. To run it, you need Python3 with the following packages installed: numpy, pillow, scipy, matplotlib brute_force_double_petscii.zip
    1 point
  6. You should check out the "double PETSCII" threads.
    1 point
  7. What you're talking about involves "racing the ray". You'd need one 8x8 tile for the tile map, repeated over and over. This tile would have eight colors indices, one for each column. Then as the "ray" is drawing a single line across the screen you would have to stay 4 to 7 pixels ahead of it, changing those 8 palette colors after a pixel is drawn but before the one 8 pixels over is drawn. It is possible but difficult; if your timing is off even a little bit then the image is garbage. For every pixel on the screen you'd need to push two bytes to the color palette, so for a 640x480 image that's 600kb; you'd need to break the image up into probably ten files and include load times of only 140kb per second; it wouldn't be possible to race the ray for that much data, even for a 320x240 image.
    1 point
  8. I doubt the limiting factor is data transfer between the processes, as the parallelization is almost trivial. And in fact, I think that each process holds a copy of all the relevant variables (I think they are even initialized in every process, e.g. the image is loaded, the palette determined etc... but I am not totally sure about that) -- so there is no communication necessary, except for the final results. I have tried parallelization with the "ray" library, which claims to solve issues with large numeric datasets and accessing identical data from multiple processes, but it didn't help. I have thought the same about splitting the problem up differently. I.e. doing more in-place computation and less memory-intensive tasks. One obvious way to achieve this would be to compute each 8x8 pixel tile individually. That way, all necessary variables could fit into CPU cache, so memory accesses should be a lot faster. With that in mind, I ran a few tests on a very simple problem earlier, but couldn't find any noticeable difference between different ways of splitting it up. I guess the present version is roughly as efficient as I can make it. Improvements will be about using better algorithms. Well, if there *is* an example where you can actually see different performance for different ways of splitting it up, I will be happy to see it!
    1 point
  9. And now you're just trolling. Have fun.
    1 point
  10. It might be possible to write a CP/M 8080 emulator for X16, just like there exists one for C64, which I tested some years ago. I tested the following 8080 emulator with CP/M on Raspberry Pi in 2014: https://nanochess.org/emulator.html This source code is rather difficult to understand, but one could write an Intel 8080 emulator from scratch that has the same instructions for peripheral operations and then the rest of the files should work. Not all CP/M software works on 8080 since Zilog Z80 was more common. I have PCs with V20 and V30 CPUs (80186 super set) that can emulate 8080 in hardware and there was also CP/M-80 for PCs that used that 8080 emulation. My Amstrad PC1512 had originally 8086 CPU, but I switched it to V30. I found a tutorial on how to write an 8080 emulator: http://emulator101.com/
    1 point
    Looks like a bunch of Christmas cards and some music that is good for 8 bit era. And some multi colored text at the bottom.
    1 point
    Classic game like the original. I got close to beating the first level on my second or third try.
    1 point
  11. I've just released a new 7.0-beta2 version of the compiler https://github.com/irmen/prog8/releases/tag/v7.0-beta2 This version will likely be very close to the final 7.0 release because I'm not considering adding or changing anything new from now on (except bug fixes). Some of the most important fixes/changes since the previous beta release: string encoding and string interning bug fixes various compiler crashes fixed %asminclude fixed (scopelabel argument removed as well) repeat loop code gen optimized some more Once again: the CommanderX16 target targets the upcoming "V39" of the cx16 emulator and roms. Programs targeting the cx16 compiled with this new Prog8 version may no longer work on the previous version of the emulator (although if you're not using floating point and bank switching, they will likely still work) Detailed change list will be added when this 7.0 version is finalized, which will probably be shortly after the "V39" of the commanderx16 is officially released as well.
    1 point
  12. Hi! First time posting here. So basically I have a game project coming that targets a retro machine with quite capable graphics and sound. Which I found this system to be a good start. However, the current x16-docs hardware reference is quite hard to navigate and lacking in some details. Inspired by hardware references I usually use for Gameboy and SNES programming, I decided to spend few weeks and write my own X16 hardware reference. Which is now available in both (printable) HTML and plain text here: https://ayce.dev/emptyx16.html https://ayce.dev/emptyx16.txt Note that this will be updated once I can confirm more details and a hardware itself is finalized (no, please don't reply about that leak here). So please look forward to it. The document's source is also available here and everyone is welcome to contribute.
    1 point
  13. I'm just starting to get into retro computers and I'm looking forward to the X16 both for learning how to use this type of system without bothering a 40ish year old computer (also their hard to find). but also a project like this intrigues me immensely and I cannot wait to see the fruits
    1 point
    This game is pure evil! I had to get my 13 y/o to try and get past level 5 needless to say he rubbed it in mercilessly. However you have done a wonderful job propagating it to the x16!
    1 point
  14. Update: I've uploaded version 3.9.3 of VolkfsForth that applies the above and should work in R39 and proto2 just as well as in R38 and proto1. An updated version of cc64 will follow soon.
    1 point
×
×
  • Create New...

Important Information

Please review our Terms of Use