I assumed that you were busy rather than disinterested. Hopefully, you are able to work intensively on Planck over Christmas or some time before then. Even if you only able to work on it intensively for two weeks or so per year, the extended periods of reflection will lead to the most elegant design and the least bodging.
SoftwareDespite me being a practical hardware lamer - who is far behind you and almost every other active participant of the forum - I try to make my work compatible with yours. I have been encouraging ABI compatibility among actively developed 6502 systems. The intention is that people can share as little or as much as they want about their base system but the software gets particularly interesting when it reaches GETCHR and PUTCHR. Unfortunately, there are inordinate ways to implement an ABI and this delves a little into memory maps whether we like it or not. I have suggested a layout to drogon which I believe is already compatible with Planck hardware and software. Working backwards from the end of the memory map:-
- Second half of page $FF: RESET, NMI and IRQ vectors. Remainder may be either 65816/65134/65265 vectors, Commodore/Acorn vectors, monitor program or I/O.
- First half of page $FF: Monitor program, arbitrary software or I/O, such as Planck Bus.
- Page $FE: Acorn/Ruby I/O or arbitrary software.
- Page $FD: Acorn I/O, re-located Commodore vectors or arbitrary software.
- Page $FC: Acorn I/O or arbitrary software.
- Page $FB: re-located Acorn vectors or arbitrary software.
- First eight bytes of page $01: Magic byte sequence to explicitly identify ABI.
Page $FF is quite crowded but it is perfectly reasonable to identify multiple systems with CPLD address decode schemes which place I/O anywhere from 63-64KB. This category includes Planck. It also happens to be compatible with Ruby and Acorn. There are constraints and consequences for design choices but it is possible for Planck to have its own arbitrary operating system while supporting a subset of foreign operating system calls. Furthermore, it is possible for static bindings in an application to determine if it is running on Planck, Ruby, Commander X16, Foenix C256, Commodore, Acorn or other system. Hopefully, it is possible to extend this to Apple, Atari and Steckschwein but I have not investigated in detail.
Increased software compatibility may aid the objective of Planck being a cost effective, open system. Most immediately, it may be possible to use Ruby's graphical client with Planck to aid boot-strap or reduce system cost.
HardwarePeople on the 6502 Forum have great success with dual port RAM but you should definitely stick with FPGA. plasmo's VGA in a RAM socket is scalable and may aid debug on Planck. However, it has zero registers which is simultaneously an advantage and a disadvantage. Agumander's dual port RAM sample playback and dual port RAM audio co-processor are impressive and particularly suited to multi-media. It may be possible to adapt some of Agumander's GameTank design to Planck. Regardless, I predict that clock stretched FPGA serial will be increasingly significant. As noted by Alan Kay, the best way to predict the future is to invent it. Well, I've been working on clock stretched serial networking and it is particularly suited to FPGA implementation, for example, as commonly found on Planck.
I followed the 74x161 datasheet to extend your variant of the clock stretching circuit. The most significant result for you is that future iterations of Planck may have a processor which exceeds 20MHz while retaining 6522 compatibility. I adapted an extension of this design to one bit audio DAC. It should be possible to fit discrete chips for stereo sample playback onto one Planck Card and/or add similar functionality to the video FPGA.
I have one trick and I'm going to try it everywhere. I tried square wave generation for video without success. In the unlikely event that I get discrete video working, iCE40 FPGA remains the most sensible, most open, cheapest, most reliable and most compact choice for video. Even Radical Brad, with 30 breadboard video design, concedes that FPGA is more practical and portable.
Please consider quad SPI as a board or in FPGA. An eight discrete chip design incorporates your clock stretching circuit. Alternatively, you might be able to flash one FPGA as an open, low cost, one chip audio/video/co-processor/SPI system.
Currently, flashing anything beyond Arduino Uno/Nano/Due is beyond me but you give me very strong incentive to improve my practical skills. Hopefully, I'll be more than a hardware theoretician when you return.
Login
Register
FAQ
Search
