colinlm
Joined 3 years ago
Joined 3 years ago
It's not about business (or being bought). It's about my hobby. This is the email they sent me:
--- Your BurgerDisk project is an ingenious way to modernize Apple II storage, showcasing your expertise.
This is Emily from PCBWay. I'd like to sponsor your projects with free PCB prototyping. A brief review would be appreciated in return.
Would you be interested? ---
This is my reply:
--- OK, why not, as long as my review is my own and honest :) What is the budget ? ---
I then published my post without them pre-screening it. It's a honest, factual review about how it goes to have PCBWay make an assembled PCB. They didn't even ask me to share it on any social media.
What I got out of it is a few hours of fun (because this is my hobby) routing a (rather simple) PCB, and a batch of twenty modules that I didn't have to use my pocket money for.
This is all. Don't overthink it.
I do sell my device. It's mostly as a service to the community members who don't have the equipment, time or skill to assemble it themselves, as it is a free software, open hardware project; it's not going to replace my salaried job in any foreseeable timeframe, and it's not the goal.
Hope that clears things up,
Colin
(Decoding and dithering are done in two passes for memory reasons and space on floppy disk reasons but it brings auto-levelling)
It's about 450 cycles per pixel for decoding QT100 (1200 for QT150), and 230 cycles per pixel for dithering.
Without the mouse IRQ, if one wants to support the whole line of Apple II computers, one has to vapor lock on the II+, remember that the IIgs's $C019 high bit means the inverse than the IIe, and the //c requires more trickery around it. (cf https://github.com/cc65/cc65/blob/master/libsrc/apple2/waitv...)
On the splash screen, it's just an image, made with Gimp and converted to HGR.
So on an 1MHz 6502, I think it'd be minutes just for handshaking.
Monochrome only, and it downscales. Only 1/4th of the pixels' IDCTs are computed, for "speed". It is also hardcoded for 640x480 images, again, for "speed" :-)
It's based on picojpeg, heavily reworked to get rid of about all intermediate buffers, core decoder functions rewritten in assembly.