A nice Commodore 64 almost compatible with extensions. Better graphics modes with 128kB of video memory, 512kB of paged system memory, 40kB of main memory, a good emulator, 8 channel FM sound and an FPGA graphics solution.
Good 6502 development tools are available and the ROMs are open source. You can buy nice USB keyboards to help support the project. The 8-bit guy does many YouTube videos on classic microcomputer technology. He has good support of the retro community and if it were not for a design constraint of using as much off the shelf older parts then it would be a single chip thing. But part of it is the hands on experience, as the emulator on a Raspberry Pi would work.
The physical hardware is still under construction. As an 8-bit system without an accelerator it is suitable for new code or conversions of old. The main goal is to prevent scrap by the off shelf requirements and make an easier to code for machine than the Pi. One person can understand it all given time.
I’m doing a factor analysis of the hardware docs now to check how I’d use it. I think a scan limited 512 by 448 graphics 4 bits per pixel mode is one I could use for games and other software development. I’m sure a nice palate of colour can be made for the index and offset constraints of the graphics.
It has 16 hardware sprites and more of the system is becoming finalized. The sound was recently tested and works after sorting out some 8MHz timing issues. Some IO is still in design but it is looking good.
As far as tools to look into Millfork, cc65 and the open repositories such as the VSCode plugin are on my list. It’s all looking quite nice. Getting the directory prepared and a suitable subdirectory for the development of a great library and demo template is going to be handy. It can be kind of a clone of the emulator binary directory as this is where the default loading and saving takes place for the emulator.
This will also keep the emulator relevant for the demo, and updates will be easier to not have to fix things without a schedule as could happen if the “latest” emulator was the default. This also manages postponement of “ROM changes” sufficient for not getting sucked into regression or editing other source and having to wait for pull requests to be merged.
The CTRL+SHIFT+P combination for the VSCode command palette gets access to build commands for millfork with the right configuration. This onlt has to be done for the project once, and a blank main.mfk makes a blank main.prg and so it kind of is setup for further progress. Putting all the right things in the git repo helps to keep the path statement unmodified. The settings are enough to get started.
Here is where I intend to put my development tools and first developments as they become what they become. The low memory and low speed of the system makes for some interesting challenge of design and implementation approximations that will be full of creative potential. Nice!
Happy coding.
UPDATE 2019-10-30: Going quite well. The Millfork works well, and after some errors (simple if you know what the compiler is trying to do), mainly obvious for people who have done assembly. It does indicate that context parsing is done after a dead code tree. The next up is likely a bit of colour in the font, and some file loading of a bitmap.
