I think we are feature- and bug-complete for the first part of the #vtracker UI, which is the pattern editor. I'll get this ready for release and push master.
This makes vtracker a bit more usable, but it still needs an instrument editor and track editor before it has a complete user interface.
New post on the motivation behind my vale8x64 #homebrewcomputer project, and an overview of its technical details: http://www.mahnke.tech/blog/2019-04-09-introducing-the-vale8x64-computer.html
I just had one of my favourite classic-sounding quotes brought to mind: "What is man? A miserable little pile of secrets" from Castlvania: Symphony of the Night.
BUT I JUST FOUND OUT IT ISN'T.
Or at least not originally. It wasn't in the original Japanese at all, it was added by the English translator, AND they copied it word for word from a 1967 book by the French writer André Malraux.
While cool, I'm still a tiny bit disappointed.
Via the EXCELLENT Legend's of Localization: https://legendsoflocalization.com/lets-investigate-a-miserable-pile-of-secrets/
@vertigo I also noticed the Wikipedia entry has a very nice overview of the internals https://en.wikipedia.org/wiki/Forth_(programming_language). And the Forth-79 standard seems pretty digestible, at 50 pages https://pages.physics.wisc.edu/~lmaurer/forth/Forth-79.pdf.
Regarding implementing a Forth, that is still some months away, but I've started to look into it. I've been reading the source code for JonesForth, and intend to take notes on the fig-forth source code as well. @vertigo, any other recommended material on understanding Forth's internals?
I have enough of the 65C22 emulated to drive the character LCD from an assembly language program: https://privatebin.net/?47c2cc0bea08e32a#2vLoq8E6VRZazTrHwekmjRUet5HTjdQyp4TwqxuKNJNH
Time to wrap up a few small things and quit for the day.
I don't know of such a standard, but I'd be interested if one exists. I'm gluing them together in C code.
I'm emulating a hardware computer I'm building around the 65C02 processor. The goal in this case is to be able to test ideas as thoroughly as possible in the software emulator before moving them to the hardware.
6502 primer shows a circuit to extend the number of input bits for the 65C22 shift register, which is just what I need to handle 11-bit PS/2 keyboard scan codes. After I integrate this and the LCD with the 65C02, all the hardware is in place for a complete user I/O loop.
Then I'll start work on my first piece of software for this new machine: a forth environment. I've begun reading through JonesForth to prepare.
Having covered the theory behind OpenGL the last two days (https://adrian.geek.nz/graphics_docs/opengl.html ), I know want to start studying how Mesa3D implements it.
To keep things clear (for both myself and all of you) I will only describe the drivers for X86 & Radeon Graphics, which I chose because that's what my laptop has.
I will cover it in top-down order of the following days. And while it should quickly become irrelevant, I'm being guided by some trivial sample code of their's.
I have 2 keyboards that fall back to PS/2 compatibility when connected through a USB-to-PS/2 adapter, which I happened to have. I confirmed they are sending their make/break signals.
Next is to communicate with the keyboard using the 65C22. It seems using the VIA's shift register is the best way to do that.
I've confirmed the 65c02 is successfully starting and executing a program I wrote to EEPROM.
The next thing I want to do is support a 20x4 character LCD. I'll do that through the 65c22 VIA. First, I need to figure out how to use the VIA. I'll do some VIA experiments from an Arduino first, then add it to the system.
Plugging these ribbon cables into pin header and then taping around the end makes a pretty solid-feeling, breadboard compatible ribbon cable. https://www.amazon.com/GenBasic-Solderless-Dupont-Compatible-Breadboard-Prototyping/dp/B01L5UJ36U/ref=sr_1_3?keywords=breadboard+ribbon+cable&qid=1572046470&sr=8-3
Last year, I made my own cables by soldering pin header onto wires. That worked well, but was too labor-intensive. I think this new method will work well.
@vertigo I think I came across some of your posts on 6502 forum while looking into this.
I have most of my minimum viable 65C02 circuit breadboarded, but I noticed yesterday there is a maximum clock rise/fall time of 5ns. I don't think I can meet that slew rate with anything I have. The 555 timer is way too slow. My Arduino Uno is just a bit too slow at 5.6-6ns. 1 MHz half can oscillator is on order.
*Update on the Mu computer*
I just wrote up a summary of state of Mu, in two parts.
Part 1 summarizes the past year as a sequence of major design decisions:
Part 2 is a sketch of what I plan to build next, again structured as a sequence of design decisions:
(The flow from design constraints to decisions is inspired by Christopher Alexander: https://en.wikipedia.org/wiki/Notes_on_the_Synthesis_of_Form)
Any and all feedback appreciated. I'd like it to be clear to any programmer.