Yipiee! Malban was not so tired after all, some enhancements were done!
The first of the additional tools was done, the one in the vide menu:
Yes, right – now on a popup you can convert images (png, bmp, gif and jpg) to vectrex raster images, but I wouldn’t get my dreams up to high, image results in resolutions greater than about 150×100 “pixel” are probably out of the 30000 cylce limit! Malban hacked the raster display routine together yesterday afternoon, so you are invited to get more performance out of it!
Here you can see the actual conversion “tool”. As you see it is not completly finished, but it will probably stay the way it is implemented now for quite some time.
Not implemented is the “vertical” raster image, which Malban hasn’t tried yet, but in theory it should look quite similar.
The image to convert is taken from the right clicked popup from above, the size is displayed.
On the left side you can see a “generated” vector image (the left slider zooms in/out), below the vector display you can give the resulting size – with this it is possible to resize the image any way you like.
You can chose what information you would like to take for vector generation, the “color”- strength of a pixel (r+g+b/3) or the alpha channel. The slider on the right/bottom can be used to enter a threshold at what value a vector will be generated.
Also taken into account (although this could be optimized) is the fact, that shift register values are actually 9 bits instead of 8 (the last bit is repeated), the displayed vector list is updated with every change.
There used to be an option to include “brightness” data for the vector list. The generation routine is still in the code but disabled, since it performs so very badly, that Malban can’t seem to find any use for it.
Using the checkboxes to the left and the create button to the right generates code (and an example main program). The actual data looks like:
The data is output in binary form, that way (with some fantasy) you can still discern your image, although this is made more difficult with each alternating line, since the display routine is bidirectional, meaning the data of every second line is stored “backwards”.
Here two more images, one of vide displaying the raster image and one of an actual vectrex:
Some other things were also implemented since last update:
- corrected/clarified undo/redo in dissi emulation
- bug where dissi was not updated when new lables were added
- bug in dissi, where dissi would not recognize DP-dependend variables (RAM locations)
- in dissi added $CA, $CB to DP menu
- vedi now saves split screen positions
- vecxi emulation correcter, now the last output shift register is “shown” (blank signal) twice, one complete shift takes 18 cycles instead of 16, 2*8 + 2
- assi error implemented, when trying to optimize forward references, this resulted in bad code, option is switched off and generates an error instead!
- in order to emulate analog DAC offsets, a vectrex “generation” can now be configured, some dac timings were implemented along the way
- ana now displays the “analog” DAC signal rather than VIA_ORA (as usual, analog hardware can be some cycles “off”)
- glow again a tiny little bit nicer, vectors with a line width >2 now have “rounded” edges.
- quite a lot of documentation was done (mainly configuration and breakpoint, but some others as well)
- variables (ram locations) can be added to dissi (as new variables), this can be done via the vari window (a “+” button at the top), this can be usefull if (in unkown code) ram locations are addressed via dp register. Dissi, while disassembling, may not know the DP register and thus can not figure out by itself where the location belongs to.