I should have started with the publicly available output of the project in the first place. It is reachable at https://github.com/frenchie68/Z79Forth. It remains a work in progress, of which I am not completely proud of. For now, the 2.1 schematics feature a blatant bug in the the CPU clock generation path. This is extremely embarrassing to me. Yet I am working on the 2.2 generation of the electronics design. A number if issues will eventually be fixed in that new release but that is not what I want to talk about right now.
In my opinion, hardware design should evolve from basic functionalities and the system itself will eventually grow to become the concept you had in mind to begin with. This is the typical bottom-up approach which the Forth language also encourages. In Forth, you tend to think of a project as a problem to be solved and you will deal with it by thinking about it in terms of high level functions that needs to be broken down into increasingly smaller, more manageable tasks. So, in thinking the Forth way, you will have to think in a top down manner but implement your code in a bottom up fashion.
I think this what an effective hardware design effort should aim at as well. Build things from the ground up: let there be light! You need a power supply. I did start with an external PSU and it worked nicely for quite some time and allowed me to make accurate current consumption measurements. After light has been turned on, you need a pulse to get the MPU going. A suitable clock generation circuitry for the 6309 can be trivial--or not, depending on one's ultimate objectives.
My original clock generation circuitry was rated for the official rating of the HD63C09E: 3 MHz. It was based on an off the shelf D-type latch based design I got from Wikipedia. Back then, I never intended to support 1 MHz devices. This turned out to be something that would come back and haunt me a couple of years down the road. More on that later eventually.
So now we are at a point where we have light and a heart beat. Nice, but not good enough. This is address decoding time. Here as well, the system's design has undergone a lot of changes in terms of address space interpretation. Initially, I had only one bit of address decoded to indicate an I/O access (EEPROM access was through a different 8 KB address block). I/O meant ACIA access, the SRAM was not even assumed to be working. I was at the point where I could blink an LED by accessing I/O space--joy could not even begin to describe it!
Interfacing a 32 KB SRAM was quite easy at this point. Just another output line of the '138 first stage decoder. Then I turned to software development (the 'BIOS') and porting my Z80 1984 Forth implementation.
I spent quite a lot of time there (no further I/O address space decoding) and continued on until it became obvious that Forth block support would require additional hardware support.
Comments
Post a Comment